Draft stays draft
A candidate is visible as a candidate — including everything an agent proposes. Nothing becomes binding because somebody wrote it down and nobody objected.
What governs now
See what is currently binding without reading everything.
The question is not where to write specifications. You have been avoiding that for years and you were mostly right to. The question is how to know, in one look, which of the things already written still hold.
- Draft, Approved, Authority, Retired
- Conflicts block Authority
- Every change with its reason
WHAT GOVERNS NOW
FR-7C21A4RequirementAuthority
DEC-3A91F0Decisionaccepted
MCPAgent contextbinding only
TC-0B72E5Test casepassed
ST-118D4CStoryPR merged
Four states, one question
A record either governs or it does not, and the system knows which.
Everything the platform does with a record follows from the state it is in. That is a small idea, and it is the one the rest of the product is built on.
Authority means binding
An Authority record is what the agent must follow. It needs acceptance criteria, and it cannot sit in an open conflict with another binding record.
Retired does the real work
When a record is retired it stops reaching the agent at that moment. It is not deleted — it stays readable as history and stops being an input.
Replaced, not overwritten
A new record replaces an old one with an explicit relation, so the reader sees both what holds now and what it succeeded.
Reasons survive the change
Changing an Authority record asks for a reason, kept with the change. You can see why something moved without reopening the decision.
Reviewed on a board
Requirements move Draft → Approved → Authority on a review board under the same rules as the form. Tenants can require a second approver.
What a record carries
Enough structure for an agent, not so much that people stop writing.
Ten record types cover intent, requirements and constraints. Each is a short statement with its reasons and its criteria, connected to the rest explicitly.
From objective to constraint
Objectives; business, stakeholder, functional, non-functional, technical and project requirements; product, business and project constraints — each with its own code.
Acceptance criteria as items
Criteria are listed one by one, so work covers them, tests verify them and an agent reports against each.
Relations with meaning
Refines, realizes, constrains, depends on, replaces, conflicts with. The chain from a requirement up to its objective is always one click away.
Decisions, standards, glossary
Architecture decisions with their consequences, tenant-wide standards and a shared glossary sit next to the records they govern.
Explorer
Every record type of a project side by side, filtered by state, to see the whole picture at once.
History on every record
Who changed what and when — a person, an agent, GitHub or CI — with field-level before and after.
The first question worth answering
Which decisions in your repository are still in force?
Most teams cannot answer that, and the agent cannot either — which is why it keeps following the ones that are not.