Annotation · not proposed UISpec ii 4.1 and ruling D-ii-6(a), decided 2026-08-24 · the different-person rule is server-enforced and universal. attestedBy must differ from enteredBy, enforced at the API rather than in the client. The PM kept the rule for every workspace with no small-tenant exception, so a workspace with a single administrator needs a second user before any confirmation can complete. State 1 is therefore the permanent state of such a workspace until a second admin exists, which is why the copy names the next action instead of only refusing.

Annotation · not proposed UISpec ii 4.1 · the confirmation stores a digest of the exact confirmed content, unit included. The digest covers numerator, denominator, UNIT, scope, methodology, period, and provenance. Unit was added to the field list and to the digest in spec v2.2, at this wireframe round, because this drawing showed a unit inside "exactly what you are confirming" while the spec's digest list did not carry it: a unit changes what a number means, so a unit outside the digest would have let 3,120 t become 3,120 kg without the confirmation noticing. The dialog above is therefore contract-true as drawn. Divergence is detectable; no user action depends on the digest, which is why it appears in this wireframe set only in scaffolding.

Annotation · not proposed UISpec ii 4.1 · immutability and revisions. A fact row becomes immutable once confirmed. An edit creates a new revision row, the prior revision is retained with a supersededByRevision pointer, and confirmation is cleared on the new revision. Acceptance case 9.5 covers the whole chain: different-actor enforced, edit-after-confirmation creates a new unconfirmed revision, and the digest matches the confirmed content.

Annotation · not proposed UISpec ii 4.1 · roles and access. Entering a fact is the entry role; confirming a fact and administering the relationship-type codes are the admin role. Framework access is NOT required for these endpoints, because the value chain and stakeholder bones are framework-agnostic. Lookups are tenant-scoped {_id, companyId} with cross-tenant 404. Both people in this flow hold the admin role, which is what makes confirmation possible at all.

Annotation · not proposed UITwo details this page used to raise as questions, both now stated in the contract. (1) The refusal constant for the different-person rule is ATTESTATION_ACTOR_INVALID, 422, named in the spec ii 6.6 error contract and deliberately distinct from a role 403 so a client can tell "you lack the role" from "you cannot confirm your own entry". The disabled state above still carries words rather than the constant, because the person reading it is a site administrator, not an integrator. (2) The rule binds PER REVISION, and the SAME second person MAY confirm a later revision: spec ii 4.1 says so in as many words, precisely so the build does not invent a fresh-pair rule. Priya Nair confirming revision 2 after confirming revision 1 is legal, as long as she did not enter it.