Principles

These are the product’s principles, written as rules. Each one explains a behavior you will meet in the portal.

1. The decision and the thing decided stay in the same place

Any part of the product you can see can also show you what put it there. An item links to its commitment, the commitment to the revision the team agreed to, and the revision to everyone who answered it.

In practice: “who decided this, and when?” is a click, not an archaeology project.

2. State the rule where it bites

When something is blocked, refused or carried forward, the screen says why at that moment, not on a help page. An objection shows as blocked, with the rule beside it. An import that is too long says which limit it hit and what to send instead.

In practice: a refusal tells you the next move. Nothing is quietly trimmed to fit.

3. Never present a draft as an answer

Machine-written content is labeled as a first pass. The questions it left unanswered sit above it, not behind a link. About seven in ten imports are a draft a person would keep, and the product says so.

In practice: you always read and edit a draft before the team sees it. See Reviewing a draft.

4. A read is one moment

Everything assembled from the model is stamped with a single ledger position. One screen never mixes the model from one moment with proposals from another.

In practice: when you act on what you read, you are acting on one consistent state. If the project moved in the meantime, the action is refused and tells you where to catch up from.

5. Append, never overwrite

History is the product. A revision is never edited away, an answer is never silently replaced, and a commitment is never cancelled.

In practice:

• Editing a proposal in review adds a revision.
• A commitment the team no longer wants is replaced by a new one, and the old one keeps its status as a historical fact.
• Retiring something is itself a decision: propose “retire X”, gain consent, and deliver it.

The rules that follow

• Consent, not voting. The question is not “do most of us like this?” but “does anyone have a reasoned objection?”. An objection must name a risk and what would resolve it. It is input for the next revision, not a permanent veto. See Consent.
• Everyone on the project counts. Acceptance needs an answer from every current project member. Someone who joins mid-review is asked too. An organization admin who is not on the project is not counted.
• Agents read; people decide. See Agents read, people decide.