flex-auth/workplans/FLEX-WP-0029-stance-register-second-edition.md

---
id: FLEX-WP-0029
type: workplan
title: "The stance register outgrew the review that read it: five rows, and the divergence was ruled rather than resolved"
domain: infotech
repo: flex-auth
status: ready
flavor: review
owner: claude
topic_slug: netkingdom
planning_priority: P2
planning_order: 290
related_workplans:
  - FLEX-WP-0019
created: "2026-09-20"
updated: "2026-09-20"
state_hub_workstream_id: "5a11099d-b492-535c-af88-c334db5e8ee6"
---

# FLEX-WP-0029 — Stance-register review, second edition

`docs/stance-register-review.md` is `status: published`, dated 2026-09-06, and
titled *"the register has a second row"*. It is flex-auth's first exercise of the
aggregate-divergence capability it claimed on 2026-08-29, and it is now stale in
three separate ways at once.

## What changed under it

| | At publication (v0.7 §13.1) | Today (v0.8 §13.1) |
| --- | --- | --- |
| Rows in the register | 2 | **5** — `ops-warden`, `user-engine`, `tenant-engine`, `secrets-engine`, `ops-mason` |
| Scope axes in play | 2 (zone, catalog stage) | 3 by zone, 1 by stage, 1 absent |
| `unknown` divergence | open, reported as observation | **ruled** by v0.8 §6.4 obligation 3 |
| Marked non-conformant | none | two rows — `ops-warden`'s cell, `ops-mason`'s absent map |

The review's own closing sentence was *"worth recording before a third row
arrives, because the cost of two incommensurable axes is small and the cost of
five is not."* Five arrived in fourteen days. The prediction landing is itself
the finding, and a second edition that does not say so wastes it.

## The constraint this plan operates under

**Supersede; do not amend in place.** A published review that is silently
rewritten to match the world is the same defect flex-auth ruled against in
`FLEX-DEC-2026-008`: a correction a reader cannot see is not a correction. The
2026-09-06 edition stays as written, marked superseded, with the second edition
in a new file. flex-auth does not get to hold other repositories to a rule it
exempts its own artifacts from.

**This is still not a §13.1 register.** gate-house owns the register. This is one
reviewer's reading of the rows in it, and the second edition must keep saying so.

## 1. Record that Finding 1 was ruled, not resolved

```task
id: FLEX-WP-0029-T01
status: todo
priority: high
state_hub_task_id: "5a7ed269-974f-5c6a-8e80-e9aa0077f8aa"
```

Owner: `flex-auth`.

v0.8 §6.4 obligation 3 states that **`unknown` is not a zone and MUST resolve to
`fail_closed`**, with the reasoning that being unclassifiable must not buy
permissiveness. That disposes of Finding 1's open question — flex-auth asked
whether §6.4 should say anything about `unknown` specifically, and gate-house
answered yes.

Three things must be recorded accurately, because the easy summary is wrong:

- The divergence was resolved **in `secrets-engine`'s direction, by doctrine**,
  not by either repository persuading the other. flex-auth reported it as an
  observation and explicitly requested no change; the rule came from gate-house.
- `ops-warden` **assented to the rule and deliberately did not flip the cell.**
  Zero of four signing targets resolve to a zone and three are `unknown`, so
  converting today would fail closed on essentially every certificate during a
  flex-auth outage — including the certificate needed to reach the host and
  repair flex-auth. `WARDEN-WP-0040` orders it: classify the continuity path,
  raise coverage by asking owners, then convert. That is `ADR-0006`'s rejected
  configuration reached by another route, and the refusal is correct.
- §13.1 therefore marks `ops-warden`'s row non-conformant **while the row is
  right to be unconverted.** Conformance and correctness have come apart on this
  cell, and the second edition should say that plainly rather than report the
  mark alone.

Gate: the second edition states who moved, why, and that flex-auth did not cause
it. No claim that flex-auth's review produced the rule.

## 2. Re-run Finding 2 across five rows

```task
id: FLEX-WP-0029-T02
status: todo
priority: high
state_hub_task_id: "991ebb94-cdc4-574a-ba60-f8960ec885fc"
```

Owner: `flex-auth`.

Finding 2 said the register cannot answer *"what is the estate's stance for a
`z2-protected` workload?"* because two rows scoped on different axes. At two rows
that was a property worth recording. At five it is measurable, and the measurement
changed direction:

- `ops-warden`, `user-engine`, `tenant-engine` — security zone
- `secrets-engine` — catalog stage, explicitly interim *"pending zone membership
  as a claim"*
- `ops-mason` — no map at all

The axis is converging on zones, with one interim holdout and one absence. That
weakens the alarm in the first edition and strengthens flex-auth's own boundary
claim, which must be restated rather than assumed: zone **membership** compiles
into the registry snapshot flex-auth already consumes, while per-zone **stance**
belongs to the consumer. If membership arrives as a claim on the decision,
`secrets-engine`'s axis converges without either side inventing a stage-to-zone
mapping.

Also assess whether `ops-mason`'s absent row is the more useful subject than the
axis question. A published map that is wrongly valued is reviewable; an absent
one is not, and §13.1 marks both. Report which of the two costs the estate more.

Gate: the finding is re-derived from the five current rows, not carried forward
from the two-row text.

## 3. Close out Finding 3 against the current file

```task
id: FLEX-WP-0029-T03
status: todo
priority: medium
state_hub_task_id: "6dd2c9fd-8ad9-54d6-8fb1-f24e44189f00"
```

Owner: `flex-auth` to verify; `secrets-engine` owns the file.

Finding 3 reported that `secrets-engine`'s `pep-stance.yaml` defines
`fail_closed` in terms of a durable `ActionAuthorization` record, an artifact
shelved on the PEP consumption path by `GH-DEC-2026-005` (accepted by flex-auth
in `FLEX-DEC-2026-006`, against its own proposal). The stance was unaffected;
only the artifact name was stale.

Read the current file and record the outcome either way. If it still cites the
shelved name, say so as an open item rather than re-reporting it as new; if it
was corrected, say who corrected it and stop carrying the finding.

Gate: the outcome is read from the file, not inferred from the absence of a
reply.

## 4. Propagate the row count and state the version trigger

```task
id: FLEX-WP-0029-T04
status: todo
priority: medium
state_hub_task_id: "4dbadd0b-7670-5837-90c9-6201c10479d7"
```

Owner: `flex-auth`.

- `SCOPE.md` says §13.1's register *"now has **two rows** rather than the one the
  standard recorded as itself the finding."* Update to five, and keep the
  sentence's point — that the register grew past the state the standard recorded.
- `INTENT.md` frontmatter declares `standard_version: "0.7"`. **Do not bump it.**
  v0.8 is `status: proposed`; flex-auth assented to the boundary in
  `FLEX-DEC-2026-011` with four findings, all adopted. The declaration tracks the
  accepted version, and bumping it early would make the machine-readable
  declaration assert something the canon does not yet say. State that trigger
  explicitly in this plan so the next session does not "fix" it: the bump happens
  when `security-layer-model_v0.8.md` reaches `status: accepted`, and it is a
  one-line change plus the prose references in `INTENT.md`.
- Add the second edition to the `contract`/`orientation` capability blocks in
  `SCOPE.md` only if the first edition is listed there; do not invent a new
  capability for a republished review.

Gate: no file in the repo claims the register has two rows; no file claims
flex-auth has declared v0.8.

## Out of scope

- Adopting v0.8 as flex-auth's declared standard version. That follows
  acceptance, not this review.
- gate-house's A-16 / A-17 (`DISTINGUISHABLE ROUTES`, and `unknown` vs `absent`
  as two meanings behind one runtime behaviour). A-16 bears on flex-auth's own
  decision record and is a larger question than a register review; it gets its
  own workplan if it needs one. Note the adjacency in the second edition, do not
  absorb it here.
- Any request that `ops-warden` convert its cell. `WARDEN-WP-0040` owns the
  order and flex-auth agreed the order is right.