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.
Where a register comes from
A register is not a document somebody fills in and keeps up to date. It is derived, on every read, from two things: the item — a company, a project, a product — and its types.
A type is an ordinary item that another item points at as this is based on that: a standard, a product line, a previous project. It can be decomposed into components, can carry tasks and events of its own, and can have types itself. Nothing is copied when the link is made. Each time the register is opened, KF walks the item together with its types and works out what the types declare that the item does not have.
That is why a requirement added to a standard today appears as a gap on every item that
claims it, immediately — no re-issue, no migration, nothing to keep in step. And it is
why missing is computed and never stored: it is the difference between what a type
requires and what the instance has.
Everything that arrives this way is marked with the type it came from — its origin —
and given a status by inheritance. not_applicable and resolved are carried down from
the type verbatim; every other status becomes missing. A type's done deliberately
does not carry down, because it says the work was finished for that item alone. The
checklists page explains why those two are the exceptions.
Requirements and headings
The register is a flat table, and each line is a pair: an item, and one thing that item owes. The item is not always the one you asked about — components are flattened into the same table, as deep as the structure goes. The thing owed is a check: an action to perform, or an object or a document to deliver. What makes something a check is the link that puts it there, not the kind of item it is; there is no "requirement" flag anybody sets.
Two kinds of line follow, and the whole difference between them is whether the line carries a check.
- A requirement carries one. It has a status, a code, an origin, and a count of what is beneath it. An item owing four things produces four requirement lines, and is named on the first of them.
- A heading carries none. It names the item that the lines under it belong to — a section of a standard, a sub-assembly, a clause whose obligations are its children — and owes nothing itself. An entry that owes nothing is still a line, because the register is the complete statement of what the item is, not a list of open points.
A heading has no status at all, deliberately. It is not pending: nobody owes
anything on it, and a heading that reported a status would inflate every tally on the
page by the number of headings. On screen a heading is set in bold and labelled; in the
exports it is marked in a column of its own, because a spreadsheet gets sorted and
filtered, and a heading that looks like a requirement with a blank status is the fastest
route to a wrong count.
| Item | Code | Check | Status | Beneath | Origin | Row type |
|---|---|---|---|---|---|---|
| Bicycle Model A | B-01 | Homologation dossier | pending | 2/3, 1 missing | requirement | |
| Frame | R08 | Paint inspection | missing | Frame type | requirement | |
| R09 | Material certificate | resolved | Frame type | requirement | ||
| Brakes | R21 | Re-torque the caliper bolts ← Brake fade | done | requirement | ||
| Wheels and tires | heading | |||||
| Battery (missing) | R33 | Cell qualification report | missing | Bicycle type | requirement |
Wheels and tires is a component that owes nothing — a heading. Battery is a component
the bicycle does not have at all: its type requires it, so both it and everything it
owes read missing. The re-torque task arrived through an event, and the event is shown
as provenance on the cell, not as a column of its own — a task is a task whether or
not an event stands between it and its item; the event says why the work is owed, not
who owes it.
The code is the requirement number as it is cited — R08. Where the check has a
code of its own the register shows that one in preference to the holder's: the check's
code is what a requirement is cited by, the holder's code is only where it sits.
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.
A task is one cell however much work it contains, and the cell is never split, so this count is the only thing that says how much a single line stands for. Under a task everything is work — its components, their components, its sub-tasks, and the tasks its events carry — and the number on the cell is exactly what the page behind the cell reports.
Reconciliation
A register that cannot add up is not evidence. Every register reports its own arithmetic and whether it holds:
79 rows · 69 requirements · 10 headings · 29 beneath Reconciliation: 69 + 29 = 98 vs summary total 98 [reconciled]
The list of rows and the summary above it are two counts of the same walk, and they count differently: a task is one row however much hides beneath it, while the summary counts the roll-ups. So exactly one relation ties them together —
requirements + everything rolled up beneath them = the summary total
— and the server states it, does it, and shows both compared numbers, agreeing or not. A bare not reconciled would tell a reader that something is wrong and nothing about what.
Check it before quoting any number off the register — including in a report, where the number will outlive the session that produced it. If it does not reconcile, neither count may be used as the population until the difference is explained.
Reconciliation is a consistency check, not a verification. It says the two counts of one walk agree; it says nothing about whether the statuses in them are true.
Over the API and the MCP endpoint the same check is one parameter:
reconcile=true returns the counts with the arithmetic already done.
Reading the numbers
Four things a register is routinely read as saying, and does not.
1. Not every line is a requirement. Count the requirements, never the rows. Ten of
the 79 lines above are headings.
2. missing is not "no evidence exists". It means nobody drew the link. Search by
subject before writing up a gap — in a reference audit, 16 of 36 minor
nonconformities turned out to be content already in the QMS and simply not linked.
3. done is not conformity, and pending is not progress. One is a tag somebody
applied; the other means somebody took ownership and nothing has been done.
4. A closed line can hide an open subtree. Read the beneath column: a done cell
with four missing obligations under it is not four-fifths 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 page, the two exports and the API all come from one walk of the structure, deliberately: a register and its summary drift apart exactly when one of them is given a walk of its own.
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.
