[finding] The ADR-0091 D5 recertification columns (`last_certified_at` / `certified_by`) are declared on both grant tables and nothing writes or reads them

[os-project-manager]

Restart-when: closed #9054

Measured while running the declared-security-key enumeration oracle for #8894. Filed unassigned; observation-class. ⛔ Deliberately not fixed there — #8894 measures the class, and repairing an instance is a different card with a different owner.

The four keys

packages/plugins/plugin-security/src/objects/sys-user-permission-set.object.ts and its sibling sys-user-position.object.ts both declare the ADR-0091 D5 attestation pair:

• last_certified_at — "[ADR-0091 D5] When this grant was last attested in a recertification review. Null = never certified."
• certified_by — "[ADR-0091 D5] Reviewer who last attested this grant." (a sys_user lookup)

The measurement

A whole-tree search over packages/, apps/ and examples/ (all .ts/.tsx, tests included) returns occurrences of either name in exactly three places:

1. the two .object.ts declarations themselves;
2. the generated i18n bundles (translations/*.objects.generated.ts — label/description strings, four locales);
3. CHANGELOG prose recording the columns being added.

There is no producer and no consumer. Nothing stamps last_certified_at on a review, nothing reads it to decide anything, and no surface computes "never certified" or "certification stale". These are not the sibling ADR-0091 columns: valid_from / valid_until are enforced by isGrantActive at three resolve-authz-context.ts call sites, and reason / delegated_from are read by the delegated-admin gate. The D5 pair alone is inert.

Why this is the ADR-0049 class rather than a missing feature

The declared surface is what an author reads as a capability catalogue. A Last Certified At column with a description promising it records a recertification review tells an admin — and tells an AI agent authoring against this model — that access recertification is a thing the platform does. It is not. That is the "false sense of compliance" ADR-0049 was written about, and access recertification is a compliance surface specifically (SOX/ISO access reviews), so the misreading is the expensive kind.

The disposition is the usual ADR-0049 three-way, and it is a real question rather than a foregone one:

• enforce — build the recertification review (a producer that stamps the pair, plus a staleness read). Real work, and there is no measured pull for it today.
• experimental — mark the columns declared-but-not-enforced so authoring them is a known no-op.
• remove — drop the columns; ADR-0087 conversion applies if they are considered authorable surface.

Note the closest precedent points at withdraw the claim rather than build the feature: for sys_capability.active the maintainer ruled (2026-08-13, #8535) that putting the capability registry on the authorization hot path was an architectural change needing its own designed card, so the false promise was withdrawn in the prose instead. The D5 pair is quieter — no confirmation dialog asserts anything — but the field description makes the same shape of claim.

Corroboration that this is not a search artifact

The same sweep found the other declared keys on these two objects all resolve to real producers or consumers, so the search was not systematically blind: granted_by is read at packages/plugins/plugin-sharing/src/sharing-plugin.ts:873, valid_until at packages/plugins/plugin-security/src/delegated-admin-gate.ts:477, reason in packages/lint/src/validate-security-posture.ts. Only the D5 pair comes back empty on both sides.

⚠️ Scope of the negative claim: this repo only. Per the evidenceScope discipline in packages/spec/liveness/README.md, a cross-repo look at objectui was not taken, and a designer preview that renders these two columns to a human would count as a consumer under the 2026-08-10 ruling — though not as enforcement, and not as a producer for a value nothing ever writes.

Refs: #8894 (the measurement that surfaced it) · #8535 (the sys_capability.active precedent) · #8811 · ADR-0049 · ADR-0091 D5.

---

Generated by Claude Code

---

Generated by Claude Code

[os-project-manager]

Finding first-touch grading: hold → pm:on-hold (finding removed, same write); domain:identity (the columns live in packages/plugins/plugin-security/src/objects/); type Task.

Hold record (2026-08-16, graded by the triage seat — seat grading, not a maintainer ruling):

• Reason: the disposition here is the ADR-0049 three-way (enforce / experimental / remove) on a compliance-adjacent declared surface, and open decision card [Decision] ADR-0049's declaration surface has two halves and only one is governed — platform-object row columns on security objects have no liveness ledger, and both #8894 ground-truth instances live there #9054 is currently asking the maintainer exactly how this class — platform-object row columns on security objects with no liveness ledger — is to be governed. Grading this instance before that ruling would either pre-empt it or need re-doing under it.
• Named restart condition: the maintainer's ruling lands on [Decision] ADR-0049's declaration surface has two halves and only one is governed — platform-object row columns on security objects have no liveness ledger, and both #8894 ground-truth instances live there #9054. Whichever seat records that ruling should re-open this card's grading in the same round (it is named in a cross-reference comment on [Decision] ADR-0049's declaration surface has two halves and only one is governed — platform-object row columns on security objects have no liveness ledger, and both #8894 ground-truth instances live there #9054), applying the ruled mechanism; absent a class-level mechanism, the instance default per the sys_capability.active is read by nothing — the Deactivate action tells the admin grants stop resolving, and they do not #8535 precedent is withdraw the claim in prose rather than build recertification nobody has pull for.
• Not needs-user-decision: the decision already has a live anchor ([Decision] ADR-0049's declaration surface has two halves and only one is governed — platform-object row columns on security objects have no liveness ledger, and both #8894 ground-truth instances live there #9054); a second card asking the same class question would duplicate the inbox entry.

本评论来自分诊座位(scheduled fire ~08:09Z 2026-08-16,session session_015RsmSaKJXEy45yxFRnC2KA)。

---

Generated by Claude Code

[os-project-manager]

Hold released → pm:queue (type Task). The named restart condition — the #9054 ruling — fired 13:03Z today: ruled Option A (no ledger is built; ⛔ Option C permanently off the table), and the ruling itself directs that this card be re-graded on its own merits as an enforce-or-remove instance, not a ledger question.

Re-graded scope accordingly: last_certified_at / certified_by on both grant tables are declared-with-zero-producers-and-zero-readers. Work the ADR-0049 enforce-or-remove decision for this pair concretely — either something writes/reads them (D5 recertification actually implemented, which is a feature and would need its own appetite ⇒ if the implementer lands there, that is a fork to escalate, not to build), or the columns retire through the standard removal route with its ledger/registry discipline. Removal is the expected outcome absent new pull; the spec-property-retirement playbook's platform-object-row analog applies.

Dispatch note: re-verify both columns are still producer-less on the merged ref at claim time (git grep the pair on origin/main) — #9054's enumeration is from 08-16 morning.

Triage: this comment comes from the triage seat Routine; not a claim.

---

Generated by Claude Code