Nonconformity and corrective action

What this service already did, and what was missing

Failures here have always been found, corrected, and receipted. Every hotfix in the change record is one: a fault named plainly, a fix, and a dated deployment. Every incident carries a cause and a receipt. That is most of what the clause asks for.

What was missing was the middle step. None of it was classified as a nonconformity, and none of it retained a cause analysis distinct from the description of the fix. A list of corrections is not a corrective-action process, because nothing in it distinguishes a one-off slip from a pattern that will happen again.

What counts as a nonconformity

Three sources. A control that does not operate as this policy set says it does. A commitment in a published document that turns out to be untrue of the running service. A defect found in the service that has a security, privacy or integrity consequence, whether found by the operator or reported through the public intake at /docs/.

Deliberately not nonconformities: a recorded gap and an accepted residual risk. A gap is a control that was never claimed, and an accepted residual is a decision already recorded in the risk assessment. Treating either as a nonconformity would flood the process with items that have already been through it, and would make the ones that matter harder to see.

The procedure as operated

React first. Contain the effect and correct the thing itself. Where the service is affected, an incident is opened and appears at /status/#incidents with its cause; where a control action is involved, a receipt enters the chain at the moment it happens.

Then classify. Each nonconformity is recorded as one of: a documentation fault, where the service was correct and the description of it was not; a control fault, where the control did not operate; or a design fault, where the control operated as designed and the design was inadequate. The distinction decides what corrective action is worth taking, and it is the step that was previously skipped.

Then determine the cause and whether it can recur elsewhere. This asks one specific question rather than inviting an essay: what else in this service has the same shape as the thing that failed? That question is what turned a single incorrect statement about the capture log into a check of every document making a similar claim.

Then act, verify, and record the outcome. Corrective action ships as a deployment in the change record. Where the action changes a control's status, the register moves in the same deployment.

The nonconformities recorded so far

N-01, documentation fault, closed. The AI policy's account of the steering rules was incomplete: it described fewer inputs than the code actually uses. Cause: the document was written from the design intent rather than from the implementation. Action: corrected against the code, and the practice of writing a control description from source rather than from memory was adopted for the rest of the set. Recurrence check: every other statement about the AI system was re-read against the code in the same pass.

N-02, documentation fault, closed, and the most instructive of these. Two documents stated that the capture log distinguishes computer-controlled sharks from players. It does not — it contains no such rows at all. Cause: a claim was made once and then copied into a second document without being checked at either point. Action: both corrected. Recurrence check: this is the fault that established the rule that a claim repeated in two documents must be verified in both, because copying is exactly how an unverified statement acquires the appearance of corroboration.

N-03, control fault, closed. The privacy retention rule was not the clean ninety days the security policy described. A profile holding a best score is retained indefinitely, because deleting it would remove entries from a published leaderboard. Cause: a policy written to a round number that the implementation had good reason not to honour. Action: the policy was corrected to state what the service does and why, and the remaining shortfall was recorded as open risk R-12 rather than argued away. This one is deliberately not closed on the register: A.5.34 stays partial because the erasure route still does not exist.

N-04, control fault, closed. A public write route was operating undocumented, so a route that accepted input from anyone was outside the API reference the register cites as its account of the attack surface. Cause: the reference was maintained by hand against a route table that had moved on. Action: documented, and the surface re-walked route by route.

N-05, control fault, closed, and found by the control that exists to find it. The first restore drill failed: the state digest covered the moment of capture as well as the state, so no two exports of the same data could ever match and no drill could ever have passed. Cause: a digest specified over the whole export envelope rather than over the state it carries. Action: the digest was narrowed to state, and the drill passed. The failing drill and the passing ones are both on the public receipt chain, in that order, because a record that showed only the pass would be describing a different service.

Where the records are

The classification and cause analysis for each item is the section above, which is a published record superseded only by a deployment. The correction is the change record entry that shipped it, at /status/#delivery. The dated, tamper-evident trace of any control action taken along the way is the receipt chain at /status/#control-history.

Nothing here is retained privately. If a nonconformity were ever found that could not be published — because publishing it would describe a live weakness — it would be recorded as an incident with its cause stated at the level that can be published, and the register would say so rather than the item quietly not existing.