Change entities — working on the system
Five entity types are about changing the organization rather than being part of
it: signal, insight, driver, proposal, and the
organizational-decision-record (ODR). They are one category — change — and
this page is where the things they share are written down once.
signal → insight → driver → proposal → ODR → agreement(s)(data) (meaning) (motive) (response) (decided) (operational)That is the whole chain, end to end. It is drawn here once; the two type pages below describe their own rungs and do not redraw it with a different last box.
Live example · Proposal pin and decision-record marker on Bakery Operations — Goldcrust Bakery example →
- In-flux types —
signal·insight·driver·proposal: the four that are still being worked out, rendered as location pins. - Organizational Decision Record — the ODR: the decision once taken, rendered as its own weightier record marker.
The chain does not stop at the ODR. An ODR is a decision pinned at the domain
(for-domain — the work system it concerns); the agreement entities that
carry it out are pinned where the work happens (agreement-of — a board
position). One decision up at the system, its consequences down in the flow. That is
why the two anchor fields differ in polymorphism, and it is why an agreement is a
different rung, not the same rung about a different subject.
These documents are vendored into the repo (from the external dwsd-markdown
convention spec) so downstream work is not path-dependent on the external W:\
source. The spec is the source of truth and changes first; these pages mirror it.
Two phases of change work
The five types divide by the phase of change work they belong to — the middle two of the four MADE phases (Map · Assess · Design · Elevate):
| Phase | Types | What it does |
|---|---|---|
| Assess | signal · insight · driver | Reads the organization as it is — selected data, its interpretation, and the need that follows |
| Design | proposal · organizational-decision-record | Says what should be instead — a proposed response, and the decision once taken |
Map is the topology itself (the as-is picture). Elevate — actually moving from as-is toward to-be — is deliberately not modeled here: it is facilitation work (experiments, guides, katas), a practice artifact rather than a record, and it belongs elsewhere.
The phases are for thinking, not for filtering
The preview’s layer filter and the drawer’s grouping do not follow the phases. They follow affordance — whether something is still in flux or decided:
| Axis | Cuts by | Where it lives |
|---|---|---|
| Taxonomy | MADE phase — Assess vs. Design | this page, the model, the way one thinks about the types |
| Affordance | in flux vs. decided | the filter menu (Change conversation · Organizational decision records), the drawer grouping, the rendering |
The two cuts run across each other on purpose. A proposal is Design by phase
but still unsettled by status, so a phase-shaped filter would leave the proposal
showing and hide the driver — backwards for a filter whose whole job is “hide what
is still noise”. Neither cut is a mistake; they answer different questions.
Consequently Assess and Design never appear in the preview UI, and Change conversation / Organizational decision records never appear as categories in this reference.
derived-from — the shared emergence key
derived-from says what an entity emerged from. It is a shared key, not a
per-type field: any entity may carry it, including an
agreement, and it is documented here once rather than repeated on each
type page.
Each step of the chain may name its origin — an insight the signal(s) it interprets,
a driver the insight(s) it answers to, a proposal the driver, an ODR the proposal,
and an agreement the ODR it operationalizes. That last link is what makes an
ODR’s bundle expressible: the agreements belonging to a decision are exactly
those whose derived-from names it. No bundle field is needed — the bundle is the
reverse reading of this key. It is also what answers why does this rule apply?
long after the people who agreed it have moved on.
- Optional everywhere. An entity without
derived-fromis complete; the key adds lineage, it does not gate validity. - Single or list.
derived-from: "[[X]]"or a list, like every other relationship field. - Both spellings.
derived-from=derived_from, as everywhere else. - Metadata only. There is no
derived-fromrelationship type — the value is preserved and readable, but it resolves to no marker, no pin and no typed edge.
Readable backwards, walkable only forwards with an index. “What did this come from?” is answered by the document itself. “What came of this?” — the bundle reading — needs a reverse index over the key, the same mechanism the workspace indexer already builds for anchors and
for-domain. That index is not built today.
Why a shared key and not a per-type field. It used to be documented on each type that happened to use it, and the type that most needed it —
agreement, the one that answers “why does this rule apply?” — never got it, because a per-type field has to be remembered at every new type and eventually is not. Documented once, that whole class of omission goes away.
Where they render
| In-flux types | ODR | |
|---|---|---|
| Marker | small type-colored location pin, node top-left | distinct decision-record marker (weightier) |
| Anchor field | observes (signal · insight) / for-domain (driver · proposal) | for-domain only |
| Scope (v1) | board position · route stage · work-system node | work-system node (domain-level) |
| Drawer | one contiguous super-group band, per-type sub-rows in chain order — Signal, Insight, Driver, Proposal — whatever order the pins arrive in | its own top-level bucket, Organizational Decision Records |
| Filter layer | change-conversation (Change conversation) | decision-records (Organizational decision records) |
Neither family is part of the bottom FL-tinted anchor-marker row (agreement /
interaction / ai-agent / role) — those describe the organization; these describe work
being done on it.
See also
- In-flux types —
signal/insight/driver/proposal. - Organizational Decision Record — the ODR.
types/…— the marker entity types (agreement,interaction,ai-agent).- Locator grammar — the shared locator value form used by
observes/for-domain/interaction-of/agreement-of.
Like what you see? → Start — build your own org folder in ~2 min