In-flux Change types — Signals, Insights, Drivers & Proposals

# In-flux Change types — Signals, Insights, Drivers & Proposals

Four of the five [**change**](README.md) entity types are the ones still being
worked out — the rungs of the Ladder of Inference, from selected data up to a
proposed response. They are the **in-flux** half of the category; the
[ODR](organizational-decision-record.md) is the decided half.

```
signal  →  insight  →  driver  →  proposal  →  ODR  →  agreement(s)
(data)     (meaning)   (motive)   (response)  (decided)  (operational)
```

The chain is the same one the [category page](README.md) draws, and this page
covers the first four boxes. It does not end at `agreement`: a proposal is
consented into an **ODR**, and the agreements that carry that decision out are a
further rung — see [the ODR page](organizational-decision-record.md).

By MADE phase these four straddle the two the category spans: `signal` · `insight` ·
`driver` are **Assess** (reading the organization as it is), `proposal` is already
**Design** (saying what should be instead). What holds all four together on *this*
page is not the phase but the **affordance** — none of them is settled yet, which is
also why the preview groups them as one *Change conversation* layer. See
[the category page](README.md#the-phases-are-for-thinking-not-for-filtering).

They are **pins**, not markers: an in-flux entity anchors to a *position* (a board
position or a route stage) and paints a small type-colored **location pin** in the
node's top-left, distinct from the bottom FL-tint anchor-marker row. In the shared
drawer the four pin categories fold under **one contiguous super-group band** (they
share `superGroupFor(category) === 'change-conversation'`), each rendered as a
per-type sub-row with a `(count)` badge.

This document is **vendored** into the repo (from the external `dwsd-markdown`
convention spec) so downstream work is not path-dependent on the external `W:\`
source. It is the in-repo source of truth for these four types + the
value-polymorphic locator that anchors them.

## The four types (D-03 identity table)

| Type | `type` | Pin color | Glyph | Anchor field | `status` values | Body highlights |
|---|---|---|---|---|---|---|
| **Signal** | `signal` | `#e8952f` (orange) | `signal` | `observes` | *(none — a signal has no lifecycle)* | The selected datum only — **no interpretation** |
| **Insight** | `insight` | `#f2c94c` (yellow) | `insight` | `observes` | `new` \| `acknowledged` | Interpretation + optional `**Category:** … \| **Severity:** …` + `## Observations` / `## Suggested Actions` |
| **Driver** | `driver` | `#3b82c4` (blue) | `driver` | `for-domain` | `new` \| `addressed` (open string) | Condensed driver + four parts: `## Current Situation` / `## Effect` / `## Need` / `## Consequences` |
| **Proposal** | `proposal` | `#c04ba0` (magenta) | `proposal` | `for-domain` | `draft` \| `in-consent` \| `consented` \| `declined` | `## Proposal` / `## Objections` / `## Outcome` |

All four also carry the optional **`derived-from`** field linking down the ladder
(insight → signal(s); driver → insight(s); proposal → driver). It is **not a field of
these four types**: it is the [shared emergence key](README.md#derived-from--the-shared-emergence-key),
documented once for every entity that can carry it — including the `agreement` at the
far end of the chain. It stays **metadata only**. The per-type body richness (insight
Category/Severity, proposal status, the driver four-part body) is surfaced as **drawer
sub-row content** (D-02), not as separate markers.

### `signal` — a selected datum, before interpretation

A *selected* piece of data — an observation, **before interpretation**. Low on the
Ladder of Inference: something was observed and selected as worth noting, but no
meaning is attached yet. Interpreting one or more signals produces an `insight`.

```markdown
---
type: signal
observes:
  - "[[Emma Design Lead]]"
created_at: "2026-03-29"
---
# Schmidt kommt um halb sechs

Schmidt kommt um 17:30 Uhr vorbei.
```

The body is just the selected datum — often a single line. **No interpretation, no
suggested actions.** The moment meaning is added, it has become an `insight`.

### `insight` — an interpretation

Meaning drawn from one or more signals — the next rung up. What makes something an
insight rather than a signal is precisely the interpretation.

```markdown
---
type: insight
title: Cross-Team Alignment Gap
observes:
  - "[[Product Development]]"
  - "[[Platform Engineering]]"
status: acknowledged
acknowledged_at: "2026-03-25"
derived-from:
  - "[[diverging-okrs]]"
---
# Cross-Team Alignment Gap

**Category:** structural | **Severity:** warning

Product Development and Platform Engineering have diverging priorities causing friction.

## Observations
- Different OKRs with no shared metrics

## Suggested Actions
- Joint planning sessions
```

### `driver` — an organizational driver

The motive for acting: a current situation together with the effect it has and the
need that arises. The rung above an insight — `signal → insight → driver → response`.
A driver is what a response (a proposal, an agreement, an action) answers to.

```markdown
---
type: driver
for-domain: "[[Strategic Direction]]"
status: new
derived-from:
  - "[[Cross-Team Alignment Gap]]"
---
# Standard-order hand-off has no owner

Standard orders stall between Sales and Assembly because no one owns the hand-off.

## Current Situation
Orders flow Sales → Standard PMs → Assembly with no agreed acknowledgement step.

## Effect
Delivery promises slip and Sales loses visibility. Evidenced by the 2026-Q1 review.

## Need
The Standard PMs need a dependable acknowledgement and slot-confirmation protocol.

## Consequences
A clear protocol cuts idle wait time and restores Sales' visibility into intake capacity.
```

The four-part structure is DWSD's own, inspired by (not copied from) Sociocracy 3.0's
*Describe Organizational Drivers* and Flight Levels.

### `proposal` — a proposed response

A proposed response to a driver, before it is consented. The last of the four still
in flux, and already **Design** by phase. When consented it yields an
[**ODR**](organizational-decision-record.md) — the decision, recorded — and the
`agreement`s that carry that decision out follow from there. The proposal itself is
never the terminal box.

```markdown
---
type: proposal
derived-from: "[[Standard-order hand-off has no owner]]"
for-domain: "[[Strategic Direction]]"
status: consented
---
## Proposal
Introduce a Standard Order Fulfillment protocol: Sales acknowledges within 24h;
Assembly confirms a slot on intake.

## Objections
Capacity contention with custom orders may break the slot promise in peak weeks.

## Outcome
Consented 2026-05-11 → [[Standard Order Fulfillment Protocol]].
```

*How* the change is accompanied — the facilitation workflow, who acts when, how
consent is run — is an application concern, **out of scope** for this spec. The spec
defines the artifacts; the process around them lives in the tooling.

## The value-polymorphic locator

An in-flux entity anchors to a *position* through one of two fields, and the value is
**value-polymorphic** — the same string family resolves to a work system, a board
position, or a route stage depending on its shape. (The
[ODR](organizational-decision-record.md) deliberately does **not** share this: its
`for-domain` names a work system and nothing else.)

### `observes` (signal / insight) vs. `for-domain` (driver / proposal)

- **`observes`** — the entity a **signal** / **insight** is about. Points at *what was
  observed / interpreted*: an individual, a unit, a work system, or a board position.
- **`for-domain` / `for_domain`** — the **work system (domain)** a **driver** /
  **proposal** is scoped to. Points **up** to the domain whose team has the need.

Both take the shared **locator** value:

```
locator := head ('#' boardId | '#' routeName)? ('/' path)? ('::' position)?
```

- **head** — a `[[file]]` wikilink, resolved by lowercased basename (depth-independent).
- **value-polymorphic body:**
  - a **bare `[[Work System]]`** wikilink anchors to a whole **work system** (points *up*);
  - a value carrying a `#BoardName` and/or a `/kind:Name` path is a **board-position**
    locator that drills *into the detail* with `/`-chained `col:` · `lane:` · `group:` ·
    `split:` segments, e.g. `[[Sprint Board]]#Sprint Board/col:Build/split:QA::before`;
  - a value carrying a `/stage:` segment is a **route-stage** locator (see below).
- **position** — a trailing `::before` / `::in` / `::after`; **bare = `::in`**.

> **Up vs. into the detail.** `for-domain` names a **work system** (the domain — points
> *up*); a board/route locator names a **position** (points *into the detail*). A board
> is **not** a work system, so the two coexist and neither field is overloaded to mean
> both.

### `derived-from` is metadata-only

`derived-from` links one of these four down the ladder (insight → signal, driver →
insight, proposal → driver). The parser has **no `derived-from` relationship type**, so
it is preserved as **metadata only** — it is *not* a typed graph edge and does not
resolve to a marker or pin. It makes the chain visible in the source without adding a
resolution surface.

It is **not a field of these four types**. It is a key shared by every entity that can
carry lineage, documented once on the
[category page](README.md#derived-from--the-shared-emergence-key) — including on the
`agreement`, which is how a decision's bundle becomes readable at all.

## Where the pins render

| Surface | Anchoring | Pin paint |
|---|---|---|
| **Board** | `observes` / `for-domain` locator → a board position | a top-left location pin on the addressed node (column / lane / group / split / cell) |
| **Route** | `/stage:<itemType> @ <Band>` locator → a route stage | a top-left location pin at the addressed stage — **stage-only in v1** |
| **Topology** | `observes` / `for-domain` → a work-system node | a top-left location pin on the node box (`renderNavPins`, OUTSIDE the DV-3 bottom marker row) |

Across all three arms the pin color is the **per-type** registry color (above), unlike
the bottom FL-tint anchor-marker row whose glyph keeps the node's FL tint. In the
shared drawer the four categories fold under **one contiguous super-group band**
(ADD-ALONGSIDE the flat Agreements / Interactions / AI-Agents buckets), and in the
preview's filter menu they are the single **Change conversation** layer
(`change-conversation`). See the board and route [`anchors.md`](../board/anchors.md)
pages for the per-arm authoring section.

### Route: stage-only in v1

Route pins anchor to a **stage** only (`/stage:<itemType> @ <Band>`). A non-stage route
anchor (e.g. a band-level or route-level pin without a stage segment) is **v2** — it
renders **no pin** and degrades gracefully (never blanks the preview), consistent with
the shared *"show as much as possible, never blank, never break"* contract.

## See also

- [Change entities](README.md) — the category page: the full chain, the two MADE
  phases it spans, and `derived-from` as the shared emergence key.
- [Organizational Decision Record](organizational-decision-record.md) — the ODR that
  records the decision one step past `proposal`, and the agreements that follow it.
- [`types/…`](../) — the marker entity types (`agreement`, `interaction`, `ai-agent`).
- [Board anchors](../board/anchors.md) — the board pin authoring section.
- [Route anchors](../route/anchors.md) — the route stage-only pin section.
- [Locator grammar](../locator-grammar.md) — the single authoritative locator reference
  the `observes` / `for-domain` values share with `interaction-of:` / `agreement-of:`.