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

---
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"
state_hub_workstream_id: "f9a657ce-67b4-5d25-9933-e0fcb2c20b1c"
---

# 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
state_hub_task_id: "05c6a85d-ee3d-5875-bea4-e9a9c5382e2e"
```

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
state_hub_task_id: "fc61c8a7-347b-59d2-b6a6-a72c5c1cdb08"
```

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
state_hub_task_id: "8ee5baf9-b364-5d3e-9c49-d0c9eb014c10"
```

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.