tegwick
92981698d8
FLEX-WP-0029: publish the second stance-register edition across five rows (a third scope axis, not a converging two — tenant-engine scopes on engine-reachability, not security-zone), record Finding 1 as resolved by gate-house doctrine rather than by either side, and note Finding 3 as still open in secrets-engine's file. First edition marked superseded, not amended. SCOPE.md's G3 gap closed accordingly. FLEX-WP-0031: correct cadence.yaml to declare one heartbeat per rare load-bearing class instead of a single combined class (tests pass unchanged). Acknowledged audit-core's AUDIT-IN-0006 reply on T02 and recorded its corrections; the remaining work (drain, reconciliation, PVC rollout, G2 closure) stays wait/blocked pending the founder's attended OpenBao mint and gate-house's atomicity ruling, so the workplan moves to blocked. FLEX-WP-0027: marked blocked — the sole remaining task needs the operator's own signed-in account, an irreducible human action. FLEX-WP-0020: recorded net-kingdom's T04 update (NK-WP-0039-T02 done, runtime.yaml digests current) and replied with no objection to their ADR-0015 values-pointer proposal for the drifted runtime.yaml reference. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: sonnet Assistant-Process: 250108@bnt-lap001 Assistant-Session: bab3d5bd-b0bb-42d0-bf80-94ed6fc2b08a
133 lines
7.3 KiB
Markdown
133 lines
7.3 KiB
Markdown
# Stance-register review, second edition — five rows, one axis question resolved by doctrine
|
|
|
|
Status: published
|
|
Date: 2026-09-27
|
|
Standard: `security-layer-model_v0.7` §6.4 obligation 3, §13.1 (v0.8 `proposed`,
|
|
reviewed and assented in `FLEX-DEC-2026-011`, not yet accepted)
|
|
Reviewer: flex-auth (Engine / PDP)
|
|
Supersedes: `docs/stance-register-review.md` (2026-09-06), which stays
|
|
unamended per `FLEX-DEC-2026-008`
|
|
Workplan: `FLEX-WP-0029`
|
|
|
|
**This is still not a §13.1 register.** gate-house owns the register. This is
|
|
one reviewer's reading of the rows in it.
|
|
|
|
## What changed since the first edition
|
|
|
|
| | 2026-09-06 (v0.7 §13.1) | 2026-09-27 (v0.8 §13.1) |
|
|
| --- | --- | --- |
|
|
| Rows | 2 | **5** — `ops-warden`, `user-engine`, `tenant-engine`, `secrets-engine`, `ops-mason` |
|
|
| `unknown` divergence | open, reported as observation | **ruled**: v0.8 §6.4 obligation 3 requires `unknown` to resolve to `fail_closed` |
|
|
| Marked non-conformant | none | two rows — `ops-warden`'s `unknown` cell, `ops-mason`'s absent map |
|
|
|
|
The first edition's closing line predicted a third row would arrive; five
|
|
arrived instead. That landing is itself part of this edition, not a footnote.
|
|
|
|
## Finding 1 — the `unknown` divergence was resolved in `secrets-engine`'s
|
|
direction, by doctrine, not by either side persuading the other
|
|
|
|
flex-auth reported the split as an observation and explicitly asked for no
|
|
change. gate-house answered the open question anyway: v0.8 §6.4 obligation 3
|
|
states `unknown` is not a zone and MUST resolve to `fail_closed`, because being
|
|
unclassifiable must not buy permissiveness. `secrets-engine`'s
|
|
`unknown: fail_closed` was already conformant; `ops-warden`'s `unknown:
|
|
fail_open` now is not.
|
|
|
|
`ops-warden` **assented to the rule and deliberately did not flip the cell.**
|
|
Verified against `ops-warden/pep-stance.yaml` (2026-09-27): 0 of its 3 signing
|
|
targets resolve to a zone. Converting `unknown` to `fail_closed` 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. That
|
|
is `ADR-0006`'s rejected configuration reached by another route, and the
|
|
refusal is correct. `WARDEN-WP-0040` is the route: classify the continuity
|
|
path, raise coverage, then convert.
|
|
|
|
§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. flex-auth did not cause the rule and does not get credit for it — the
|
|
finding is that the estate resolved a disagreement flex-auth only surfaced.
|
|
|
|
## Finding 2 — re-run across five rows: the axis is not converging, and the
|
|
count of distinct axes went up, not down
|
|
|
|
The first edition found two incommensurable axes (`security-zone` vs.
|
|
`catalog-stage`) and warned the cost would grow with a third row. Reading all
|
|
five files directly (not carried forward from the workplan's draft table,
|
|
which had this wrong):
|
|
|
|
| Repository | Scope axis (as published) | `unknown` |
|
|
| --- | --- | --- |
|
|
| `ops-warden` | `security-zone` | `fail_open` (non-conformant, assented) |
|
|
| `user-engine` | `security-zone` | `fail_closed` |
|
|
| `tenant-engine` | `engine-reachability` (not `security-zone`) | `fail_closed` |
|
|
| `secrets-engine` | `catalog-stage`, explicitly interim "pending zone membership as a claim" | `fail_closed` |
|
|
| `ops-mason` | no map published | n/a — marked non-conformant by absence |
|
|
|
|
That is **three** distinct scope axes in play (`security-zone`,
|
|
`catalog-stage`, `engine-reachability`), not the two-converging-to-one the
|
|
workplan draft assumed. `tenant-engine`'s axis is a genuine third shape: it
|
|
scopes on whether the engine can be reached and what it said, not on a
|
|
property of the target resource, and every cell of its map is `fail_closed` —
|
|
so it is trivially conformant on `unknown` but not comparable to a zone-scoped
|
|
row at all. The alarm from the first edition does not weaken at five rows; it
|
|
sharpens, because a third axis appeared rather than the two converging.
|
|
|
|
flex-auth's boundary claim from 2026-08-19 stands and is restated here: zone
|
|
**membership** compiles into the registry snapshot flex-auth already consumes,
|
|
while per-zone **stance** belongs to the consumer. If zone membership arrives
|
|
as a claim on the decision, `secrets-engine`'s catalog-stage axis can converge
|
|
onto zones without either side inventing a stage-to-zone mapping.
|
|
`tenant-engine`'s reachability axis does not converge under that boundary at
|
|
all — it is answering a different question (was the PDP reachable and what did
|
|
it say) than a zone-scoped map answers (what should happen to this target).
|
|
That distinction is worth gate-house's attention on its own; this review notes
|
|
it rather than resolving it.
|
|
|
|
On `ops-mason`'s absent row versus the axis question: an absent map is the
|
|
more useful subject. A published map that scopes on the "wrong" axis is still
|
|
reviewable, inventoriable, and testable against its own code — `ops-mason`
|
|
having none means §13.1 cannot even ask it what its `unknown` residue is. The
|
|
absence costs the estate more than the axis mismatch does, because the axis
|
|
mismatch is at least visible.
|
|
|
|
## Finding 3 — `secrets-engine`'s map still cites the shelved artifact name
|
|
|
|
Read directly from `secrets-engine/pep-stance.yaml` on 2026-09-27: line 35
|
|
still defines `fail_closed` as "no protected side effect without a durable
|
|
**access-engine / `ActionAuthorization`** record." `ActionAuthorization` was
|
|
shelved on the PEP consumption path by `GH-DEC-2026-005`, accepted by
|
|
flex-auth in `FLEX-DEC-2026-006`. This is an **open item, not a new finding
|
|
and not a resolved one** — the stance itself is unaffected (`fail_closed`
|
|
still means no protected side effect without a durable record, and the
|
|
records exist under their current names: `approval-engine`'s approval claim
|
|
and flex-auth's `DecisionEnvelope`), but the file's prose has not been
|
|
corrected since the first edition reported it. `secrets-engine` owns the file;
|
|
flex-auth can only keep verifying.
|
|
|
|
## Corrections to the record this edition makes
|
|
|
|
- `SCOPE.md` already states five rows and the `unknown`/axis findings
|
|
accurately; no change was needed there.
|
|
- `INTENT.md` carries **no `standard_version` field at all** — the earlier
|
|
premise that it declares `"0.7"` and must not be bumped does not match the
|
|
file. There is nothing to avoid bumping. The version-scoped state that does
|
|
exist lives in `docs/conformance/security-layer-conformance.md`, which
|
|
correctly does not assert v0.8 acceptance.
|
|
- The first edition is not listed in `SCOPE.md`'s `contract`/`orientation`
|
|
capability blocks, so this edition does not invent one either.
|
|
|
|
## What flex-auth is not claiming
|
|
|
|
- No stance is wrong by virtue of being non-conformant. `ops-warden`'s
|
|
`unknown: fail_open` is a measured, reasoned, tracked exception with a route.
|
|
- No change is requested of any repository. `WARDEN-WP-0040` owns the order
|
|
for `ops-warden`'s cell and flex-auth agreed the order is right;
|
|
`secrets-engine` owns its own file's prose.
|
|
- This is not a §13.1 register and does not attempt to be one.
|
|
|
|
## Out of scope (carried from the workplan)
|
|
|
|
- Adopting v0.8 as flex-auth's declared standard version.
|
|
- gate-house's A-16 / A-17 (`DISTINGUISHABLE ROUTES`, and `unknown` vs.
|
|
`absent` as two meanings behind one runtime behaviour) — noted as adjacent
|
|
to Finding 2's third axis, not absorbed here.
|