fix(decision): registry facts win over caller-supplied attributes

secrets-engine's first live request rejected our allow: binding.
request_digest is computed over material they never sent, because we
enrich subject and resource from the registry before hashing. Answering
that meant reading the enrichment path, which had a worse defect in it.

Enrichment was additive-if-absent — addAttribute wrote a registry value
only where the request had no value for that key. So where a caller
supplied a key, the caller's value won and the registry's never applied.
Every registry ceiling and allowlist was advisory. Verified against the
shipped ops-warden package, each one added key on an otherwise-denied
request:

  max_ttl_hours: 99      registry says 8    -> allowed a 12h certificate
  allowed_principals     registry allowlist -> disallowed_principal bypassed
  allowed_subjects       registry allowlist -> unknown_subject bypassed

The third is the one to read twice: a subject the registry does not know
authorized itself by naming itself in the allowlist it was being checked
against.

Not remotely reachable today — the PEP builds the CheckRequest,
ops-warden sends no resource.attributes, and enforce admits one identity.
It is a defence-in-depth failure: any path that lets attacker-influenced
data into a CheckRequest field became a full policy bypass rather than a
bounded input problem. Callers sending resource.attributes is not
hypothetical; secrets-engine does it on every request.

Registry facts now win, and diagnostics.registry_overrode names every
displaced key, because a registry that silently discards a contradicting
claim hides that a caller asserted authority it did not have.

subject.type is carved out, and the reason is a finding of its own.
Making the registry win there denied every secrets-engine allow: the
registry's type is CARING vocabulary (Human, Agent, Automation, Service)
and the request's is the protected system's actor vocabulary (service,
adm, agt, atm). Two fields sharing a name; substituting one for the other
is translation rather than identity, which GH-DEC-2026-008 ruled against.
Note what surfaced it — the registry's type had been dead data since the
field existed, because the caller's value always won.

Also publishes binding.submitted_request_digest, over the request exactly
as sent. request_digest was published as the consumer replay test and
cannot be one. Nothing is lost hashing the pre-enrichment form:
enrichment is a function of the request and the snapshot, and
registry_snapshot_digest already pins the snapshot.

Existing pins do not move. All three replay fixtures' request_digest and
approval_binding_digest values are byte-identical — those requests
contradict no registry fact. A field to add, not a value to correct.

Regression tests verified failing against the old behaviour before being
kept. FLEX-DEC-2026-012; FLEX-WP-0025 carries the residual, that a policy
still cannot tell a fact from an assertion.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 715613@bnt-lap001
Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80

workplans/FLEX-WP-0025-fact-versus-assertion.md

@@ -0,0 +1,122 @@
+---
+id: FLEX-WP-0025
+type: workplan
+title: "A policy cannot tell a registry fact from a caller assertion"
+domain: infotech
+repo: flex-auth
+status: ready
+owner: claude
+topic_slug: netkingdom
+planning_priority: P1
+planning_order: 250
+depends_on_workplans:
+  - FLEX-WP-0021
+related_workplans:
+  - FLEX-WP-0022
+  - FLEX-WP-0024
+created: "2026-09-07"
+updated: "2026-09-07"
+---
+
+# FLEX-WP-0025 — A policy cannot tell a registry fact from a caller assertion
+
+Opened by `FLEX-DEC-2026-012`. That decision closed three verified privilege
+escalations by making registry facts win over caller-supplied attributes. It did
+not close the shape that produced them.
+
+`input.resource.attributes.max_ttl_hours` reaches a Rego rule as one value in one
+map. **Nothing in that input says whether the registry asserted it or the caller
+did.** Precedence decides which value survives; it does not let a policy author
+require that a ceiling came from the registry at all.
+
+## The two residuals precedence did not close
+
+**1. A key the manifest omits is caller input.** Registry facts win only where
+the registry has a value. A package branching on an attribute its manifest does
+not declare is reading the caller, and a manifest that stops declaring a key
+silently hands that key back. Registering the resource is not sufficient — the
+specific key must be present.
+
+**2. `subject.type` is two fields sharing a name.** The registry's `type` is
+CARING vocabulary (`Human`, `Agent`, `Automation`, `Service`); the request's is
+the protected system's actor vocabulary (`service`, `adm`, `agt`, `atm`).
+Policies compare against the latter. Making the registry win here denied every
+`secrets-engine` allow, because `"Service"` is not `"service"`, so the exception
+stands — and a caller can still assert its own `subject.type` while packages
+branch on it.
+
+Note how the second surfaced: the registry's `type` had been dead data since the
+field existed, because the caller's value always won. **A defect is invisible
+while the value it produces is never read.**
+
+## 1. Decide the shape
+
+```task
+id: FLEX-WP-0025-T01
+status: todo
+priority: high
+```
+
+Owner: `flex-auth`.
+
+The obvious move is separate namespaces — `input.resource.registry.*` for facts
+and `input.resource.asserted.*` for caller input, with `attributes` retained as
+the merged view. That breaks no package on day one and lets a rule that enforces
+a ceiling opt into the fact side.
+
+Weigh against it: a third view invites a package to read the merged one by
+habit, which is the status quo with extra steps. A stricter alternative is to
+stop merging at all and require packages to name a side, accepting a breaking
+change across six published packages.
+
+Do not decide this from the shape alone. Read what the six packages actually
+branch on first, and write down which of their reads are ceilings or allowlists
+(must be facts), which are genuinely caller-proposed (`ttl_hours`, `purpose`),
+and which are ambiguous. The ambiguous set is the real design input.
+
+Gate: the chosen shape is written down with the vocabulary collision addressed,
+before any package changes.
+
+## 2. Audit every package for ceilings read from undeclared keys
+
+```task
+id: FLEX-WP-0025-T02
+status: todo
+priority: high
+```
+
+Owner: `flex-auth`.
+
+Mechanical and worth doing before T01 lands, because it is the live residual.
+For each published package, list every `input.*.attributes.<key>` read, and check
+the key is declared in the manifest for every resource that package can be asked
+about.
+
+Any ceiling or allowlist read from a key the manifest does not declare is a live
+escalation of the `FLEX-DEC-2026-012` shape. Fix by declaring the key, not by
+changing the rule.
+
+Gate: a table of package × key × declared-in-manifest, with no ceiling or
+allowlist unbacked. Add it to `docs/request-enrichment.md`.
+
+## 3. Make the review obligation enforceable rather than written
+
+```task
+id: FLEX-WP-0025-T03
+status: wait
+priority: medium
+```
+
+Owner: `flex-auth`.
+
+`docs/request-enrichment.md` now says a policy enforcing a ceiling MUST read a
+key its manifest declares. A review obligation nothing checks is the shape
+`FLEX-DEC-2026-008` was about.
+
+Extend `flex-auth validate` to report attribute keys a package reads that its
+fixtures' registry never supplies. It cannot prove intent — it does not know
+which reads are ceilings — but it can surface every read that resolves only from
+caller input, which is the set a reviewer must look at.
+
+Gate: the check runs in `validate` and flags a package whose ceiling key is
+undeclared, demonstrated against a deliberately broken fixture package.