The compliance register
The register answers one question: what does this item still owe?
It gathers every task the item or any of its types requires, and shows the state of each. It is the same structure as a checklist — the name changes because when the types are a standard and the instance is a company, the checklist is the compliance register.
The five status words, and what they actually mean
All five mean something other than what they appear to say, and quoting them without that distinction is how a register misleads the person reading it.
| Status | What it actually means |
|---|---|
done | Somebody marked it done. Not the same as the requirement being met — the evidence still has to be read. |
resolved | Answered at type level, on every instance's behalf. Everything nested under it is hidden from instance lists. |
not_applicable | Declared not applicable. A justification should exist; ask for it. |
missing | Inherited from a type and nobody has taken it on. Says nothing about whether evidence exists — it often does, unlinked. |
pending | Somebody took ownership of it. Not the same as work having been done. |
missing is computed, never stored. It is the difference between what a type requires
and what the instance has.
Roll-up
Each row carries a count of what is beneath it — 0/4, 2 missing. A row can be
marked done while obligations remain open underneath it, and when that happens the
register keeps showing the tally rather than hiding it. The contradiction belongs on
the page, not behind it.
Reconciliation
A register that cannot add up is not evidence. Every register reports its own arithmetic and whether it holds:
Reconciliation: 69 + 29 = 98 vs summary total 98 [reconciled]
Requirements plus what is rolled up beneath them should equal the summary total. The badge says whether it does. Check it before quoting any number off the register — including in a report, where the number will outlive the session that produced it.
Over the API and the MCP endpoint the same check is one parameter:
reconcile=true returns the counts with the arithmetic already done.
Getting it out
Register CSV and Register XLSX export the whole thing, with a provenance header
naming the database, the item counts, the last write, the configuration revision, the
time of export, and the reconciliation result. The rows carry row_type, item, code,
check, status, what is beneath, and the origin type each requirement came from.
The origin column is the one people underestimate: it says which standard, library or predecessor put this obligation here.
The inverted register
The register asks: does this instance have what its types require?
The inverted checklist asks the mirror question: for each task this instance has, is it reflected back in any of its types? A lesson that stays on a single instance is a lesson lost — it will not reach the next project.
