Core concepts
These are the words the portal and these docs use. Each one names a single, specific thing.
The canonical model
Section titled “The canonical model”The canonical model is the single source of truth for what the product is. It is a map of typed items connected by links. Its picture in the portal is the model map. Every item records the commitment that created it, so any part of the product can be traced back to the decision that produced it.
| Kind | What it is |
|---|---|
| Direction | A strategic intent: where the product is going. It is a goal or a bet, not a shippable thing. A direction is completed by delivery or replaced; it is never deleted. |
| Capability | Something the product can do, stated from the user’s side rather than as an implementation. Every capability lives under exactly one direction. |
| Constraint | A boundary the product must respect, such as a compliance, performance or principle rule. A constraint constrains the items it applies to. |
An item is in one of four states. Active means agreed, with delivery pending. Delivered means its commitment was verified. Replaced means a newer item took its place. Withdrawn means it was retired without a replacement.
- lives under: a capability and its direction.
- constrains: a constraint and the item it limits.
- replaces: a newer item and the one it replaced. This is the model’s own history of change.
- supports: one item furthers another. Someone writes this link by hand; nothing creates it automatically.
- contradicts: two items in recorded tension. The model allows an unresolved conflict rather than hiding it.
The flow
Section titled “The flow”Proposal : A suggested change to the model. It starts as a private draft and becomes visible to the team when it is sent for review. It ends accepted or rejected.
Revision : Each version of a proposal under review. Revisions are numbered and never rewritten. Editing a proposal appends the next one.
Material edit : A revision that changes what the proposal means. It clears every answer already given, and the team decides again. A typo-level revision keeps the answers, which are marked as carried. Changing what kind of proposal it is always counts as material.
Consent : A reviewer’s answer on the current revision. There are three: consent (“no reasoned objection; safe enough to try”), abstain (stand aside), and objection (a reasoned block that names the risk and what would resolve it).
Commitment : What acceptance creates: a promise to deliver, pinned to the exact revision the team agreed to. It moves from not started to in delivery to verified. A commitment is never cancelled. If the team changes its mind, a new commitment replaces it.
Baseline : The import that brings an existing product into an empty project. It is a proposal of its own kind, and the team consents to it like any other.
Signal : What raised a proposal and why, ideally in the words of whoever raised it: an idea, meeting notes, a pain point, something observed, or a requirement.
The record
Section titled “The record”Ledger : The project’s append-only history. Every transition (proposed, revised, answered, accepted, rejected, started, verified, replaced) is a ledger entry that names who acted: a person, an agent or the system.
Reading position : Every read of the model is stamped with the ledger position it was taken at. Everything on one screen describes a single, consistent moment.
Audit : The check run before a proposal opens for review. It looks for duplicates, crossed constraints and delivered work being undone. Its findings are flags to clear, not verdicts.
Model credits : The team’s monthly allowance for model work: drafting on the web, imports, and the audit. It refills on the first of the month.