flex-auth/decisions/decisions.md

# Decision records

## FLEX-DEC-2026-001 — Assent to GH-DEC-2026-001: Engine framing, access-engine rename, authoring/evaluation split

```yaml
id: FLEX-DEC-2026-001
kind: decision
title: 'Assent to GH-DEC-2026-001: Engine framing, access-engine rename, authoring/evaluation
  split'
status: resolved
origin: cross-repo
origin_ref: gate-house GH-DEC-2026-001
standard: net-kingdom/canon/standards/security-layer-model_v0.1.md
intake_ref: FLEX-IN-0001
owner: flex-auth
affects:
- flex-auth
- gate-house
- net-kingdom
- ops-warden
- secrets-engine
- zone-engine
requested_dispositions:
- assent
- revise
- reject
created: '2026-08-28T19:43:38.443788Z'
updated: '2026-08-28T19:44:29.505314Z'
rationale: 'Assent to all three items of GH-DEC-2026-001. Item 1: flex-auth is Engine-layer
  and the sole decision point; the INTENT reframe at fe46122 stands. flex-auth accepts
  one conformance debt of its own — DecisionProvenance carries no registry snapshot
  digest, so a decision turning on registry content is not replayable from its own
  provenance (standard section 6). Item 2: access-engine is the right name; execution
  is a separate governed migration, conditioned on renaming repository identity and
  runtime identity in separate revertible steps (the enforcing ops-warden pin binds
  tokens to the protected-system name flex-auth, and a single-step rename would 401
  every warden sign) and on FLEX-WP prefix ownership staying with the repository.
  Item 3: the authoring/evaluation split is accepted; gate-house authority ceilings
  must reach the decision as input claims or as rules in the versioned policy package
  so their application is reconstructable from the decision record — the same section
  6 test flex-auth applied to zone-engine and now to itself. FLEX-WP-0017-T03/T05
  stay wait: the design half is re-routed to gate-house, the durable storage half
  remains unowned and is raised as an engine gap.'
decided_by: flex-auth (reviewing side)
decided_at: '2026-08-28T19:44:29.505314Z'
state_hub_decision_id: "c990e442-77c2-4556-a40b-61f65eded10b"
```

## Context

`gate-house` asked flex-auth, via `FLEX-IN-0001`, to assent to the three items
ratified in `GH-DEC-2026-001`. The request follows the estate precedent that a
boundary is drawn on review by the other side rather than asserted — the
precedent flex-auth itself set when it reviewed a `zone-engine` draft and ruled
that flex-auth is the policy decision point and stays the only one.

This record is flex-auth's answer. It is written from the reviewing side: the
questions asked were not "is this flattering to flex-auth" but "does this hold
against what flex-auth actually is, and does flex-auth actually conform".

## Disposition

**Assent to all three items, with one accepted conformance debt and two
conditions on the rename.** Nothing here revises or rejects any part of
`GH-DEC-2026-001`.

### Item 1 — Engine framing and the sole decision point: assent

flex-auth is Engine-layer under §3.3 and §4 of the standard. The defining
property holds: the same authoritative input state yields the same result. The
INTENT reframe is applied at `fe46122` and is correct as written — "control
plane" is dropped as Staff vocabulary, and the exclusive decision-point role of
§6 is stated.

The generalization in §6 is the ruling flex-auth drew against `zone-engine`,
applied to the estate. flex-auth cannot consistently hold that boundary against
another repository and decline it as a general rule.

**Accepted conformance debt — registry provenance.** §6 states that compiled
data determining an outcome is still deciding, and that provenance must remain
reconstructable from the engine's decision. flex-auth does not fully satisfy
this today. `DecisionProvenance` (`pkg/api/canonical.go`) carries the evaluator,
mode, policy package, policy version, and a directory ETag — but no digest of
the registry snapshot that supplied resource, subject, and relationship facts.
A decision that turned on registry content therefore cannot be replayed from
its own provenance.

flex-auth accepts this as its own gap rather than claiming conformance it does
not have. It is the same argument flex-auth made to `zone-engine` — zone
*membership* compiles into the registry snapshot, per-zone *stance* belongs in
the versioned policy package, precisely because registry content is absent from
decision provenance. The clean fix is to make registry content provenanced, and
a workplan will carry it. Until it lands, the flex-auth position that
outcome-determining content belongs in the versioned policy package stands
unchanged, and stands for gate-house's inputs on the same terms (item 3).

### Item 2 — The `flex-auth` → `access-engine` rename: assent to the name, not yet to execution

`access-engine` is the right name. The rejection of `auth-engine` is correct —
`key-cape` owns authentication, and `auth-` preserves exactly the ambiguity the
rename exists to remove. The §8 lane/rule demarcation is an acceptable cost and
flex-auth adopts it: `ops-warden` and `ops-mason` own access lanes, flex-auth
owns access rules.

flex-auth agrees the rename is a separate governed migration and does not treat
`GH-DEC-2026-001` as authorizing it. Two conditions, from the consumer side
rather than the documentary side:

1. **Repository identity and runtime identity must be renamed in separate,
   independently revertible steps, repository first.** The name `flex-auth` is
   not only a repo slug: it is a deployed service, an in-cluster DNS name, a
   chart and image name, and — since `FLEX-WP-0016` moved the ops-warden pin to
   `callerAuth.mode: enforce` — a protected-system identifier that inbound
   tokens are bound to. A single-step rename would make every `warden sign` a
   401, including the certificate the `ops-bridge` tunnels depend on. This is
   the same dependency shape that caused `ops-warden`'s `ADR-0006` to defer
   `policy.enabled` permanently.
2. **`FLEX-WP` prefix ownership stays with the repository across the rename.**
   Existing `FLEX-WP-0001..0018` identifiers are referenced by State Hub
   records, by consumer repositories, and by decision provenance in shipped
   audit records. They are not renamed retroactively; whether new work takes a
   new prefix is a question for the migration record, not for this assent.

The migration also touches State Hub identifiers, `ops-warden`'s routing
tables, `zone-engine`'s boundary text, and `secrets-engine` integrations, as
`GH-DEC-2026-001` states. flex-auth will not begin any of it under this record.

### Item 3 — The authoring/evaluation split: assent, with the §6 test applied symmetrically

The split is correct and flex-auth gives up the authoring half willingly:
gate-house owns the doctrine, the invariants, the authority ceilings, the
operating modes, and the authority context; flex-auth owns evaluation
exclusively plus the policy-as-code mechanism; policy *content* stays with the
protected system's owner.

flex-auth draws one boundary back, which is the §6 test applied to gate-house's
inputs on the same terms flex-auth applies it to `zone-engine` and to itself:

> An authority ceiling that determines an outcome must reach the decision as
> either an input claim on the request or a rule in the versioned policy
> package — and its application must be reconstructable from the decision
> record. A ceiling that resolves an outcome before evaluation runs has decided
> early, and gate-house is Staff, where §6 forbids a decision point.

Concretely: gate-house authors the ceiling; flex-auth renders it. The principal
/actor/runtime triple, the mandate, and the operating mode arrive as input
claims and appear in the decision binding. Where a ceiling constrains an
outcome, it is expressed in the versioned policy package so that the policy
version in provenance identifies the ceiling that applied. This is not a
restriction on gate-house's authorship; it is what keeps the authorship
auditable at decision time.

**Effect on `FLEX-WP-0017`.** The split resolves the overlap and re-routes the
design half of the blocked work: gate-house designs the approval contract,
flex-auth validates approvals at decision time. It does not unblock
`FLEX-WP-0017-T03` — the durable approval object, authenticated approval
entries, and atomic supersession still need an owner for *storage and
lifecycle*, which is neither gate-house's (Staff holds no state another layer
depends on at runtime, §3.4) nor flex-auth's (flex-auth does not own the
organizational approval lifecycle). T03 and T05 stay `wait`, with the design
half now addressed to gate-house. That unowned half is flagged to gate-house as
an engine gap under §5, not solved locally.

## Consequences

- The standard's §11 blocker "flex-auth reframed as an Engine … not yet
  assented" is answered for flex-auth. `kings-guard` and `ops-warden` assent
  remains outstanding and is not flex-auth's to give.
- `INTENT.md` records the assent and the registry-provenance debt.
- A workplan will carry the registry snapshot digest into `DecisionProvenance`.
- The rename is not started, and must not start before a migration record
  exists that satisfies the two conditions above.

## FLEX-DEC-2026-002 — Review of security layer model v0.4: assent with findings, one rule contested

```yaml
id: FLEX-DEC-2026-002
kind: decision
title: 'Review of security layer model v0.4: assent with findings, one rule contested'
status: resolved
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.4
standard: net-kingdom/canon/standards/security-layer-model_v0.4.md
intake_ref: FLEX-IN-0002
owner: flex-auth
affects:
- flex-auth
- gate-house
- net-kingdom
- ops-warden
- approval-engine
- maturity-engine
requested_dispositions:
- assent
- revise
- reject
created: '2026-08-29T00:41:21.171665Z'
updated: '2026-08-29T00:42:13.009799Z'
rationale: 'Assent to security-layer-model v0.4, with one rule contested and two capability
  assignments not accepted as assented. Section 9.3 conflicts with shipped assented
  behavior: it rules engine-unreachability fallback into the engine, where it cannot
  live, and collides with ops-warden ADR-0009''s per-zone consumer PEP map. Section
  13 names access-engine as intended owner of containment (accept as proposed owner
  only, pending per 9.2) and of authentication/assurance evidence (declined as stated;
  the identity layer and audit-core own that). Three consistency defects: frontmatter
  status proposed contradicts section 14 ''accepted''; the adoption count reads seven
  of fifteen with remaining eight against sixteen estate-authored repositories and
  nine listed; section 14 says three repositories above a table of four. FLEX-IN-0002
  answered: the approval boundary unblocks T03 design, T05 additionally needs the
  approval claim bound to the NewDecisionBinding request digest and a named owner
  and ordering for single consumption; the maturity claim route is practical as a
  request claim but not as registry content until the self-declared provenance digest
  gap closes.'
decided_by: flex-auth (reviewing side)
decided_at: '2026-08-29T00:42:13.009799Z'
state_hub_decision_id: "2e96321d-c7bf-4127-9c30-f3def32e5bee"
```

## Context

`FLEX-IN-0002` asked flex-auth to review v0.3. By the time of review the current
text is **v0.4** (plus the in-place §11 amendment at `2aaf46c`), which supersedes
v0.3. This record reviews v0.4 and answers the two questions `FLEX-IN-0002` put.

Three versions have landed since `FLEX-DEC-2026-001`, which answered **v0.1**.

## Disposition

**Assent to v0.4, with one rule contested, two capability assignments not
accepted as assented, and three consistency defects.** Nothing here blocks
adoption; §9.3 needs correction before it is relied on.

### What v0.4 gets right, from flex-auth's side

§6.2 adopts flex-auth's boundary from `FLEX-DEC-2026-001` in substance and binds
gate-house on the same terms. §9.4 upholds the self-dealing objection: the
evaluator does not own the object it evaluates, `access-engine` consumes
approvals as input claims and never mutates them. §13 attributes the
registry-snapshot digest gap to flex-auth as self-declared, which is correct.
§9.5's guardrail — a maturity level MUST NOT gate a decision directly — is §6.1
applied to a new engine, and flex-auth endorses it.

### Contested — §9.3 conflicts with shipped, assented behavior

> *"The deterministic fail to reduced authority default is `access-engine`'s,
> applied when it cannot reach its own inputs."*

Two different failure cases are conflated:

1. **access-engine is reachable but cannot reach its own inputs.** The fallback
   is flex-auth's, it is deterministic, and §9.3 is right. flex-auth accepts it.
2. **access-engine is not reachable at all.** The engine applies nothing,
   because it is not running. Whatever happens next is the consumer's behavior,
   necessarily. flex-auth has held since 2026-08-19 that **fail-open is not
   expressible by a PDP at all** — not as a preference, but because there is no
   evaluator in the path to express it.

§9.3 as written rules case 2 into the engine, where it cannot live. It also
collides with shipped behavior in a repository that has assented to this
standard: **ops-warden `ADR-0009`** (accepted 2026-08-22, superseding `ADR-0006`)
retires the global `policy.enabled` and `policy.fail_closed` and replaces them
with a **total per-zone map in the consumer PEP** — fails open for
`z0-experimental`, `z1-operational`, `z2-protected`, `z2-continuity` and
`unknown`; fails closed for `z3-critical`. That map is a Staff-layer
degraded-mode fallback, and it is the correct design: the alternative makes
flex-auth a hard dependency of every `warden sign`, including the SSH
certificate the ops-bridge tunnel carrying the policy call depends on.

Proposed correction: §9.3 should rule the **input-degradation** fallback into the
engine and state that **engine-unreachability residue is the consumer's**,
bounded by a requirement that the consumer's stance be declared per zone and
auditable — which `ADR-0009` already satisfies. The sentence *"engine-unavailable
is not grounds for a Staff break-glass path"* is sound and should be kept: a
bypass path around a **reachable** engine is a second decision point. A consumer
choosing its own behavior when there is no engine to ask is not.

### Not accepted as assented — two capability assignments

v0.4's frontmatter lists `flex-auth FLEX-DEC-2026-001` under `assented_by`, and
§14 presents it as adoption of the current text. That record answered v0.1.
Since then §13 names `access-engine` as intended owner of two capabilities
flex-auth has never reviewed:

| Gap row | Position |
| --- | --- |
| Containment surface → `access-engine` + runtime engines | Plausible and consistent with §8's posture asymmetry — rendering reduced authority is what a PDP does. Not yet reviewed, and §9.2 marks it pending anyway. Record it as **proposed owner**, not owner. |
| Authentication / assurance evidence → `user-engine`, `access-engine` | **Declined as stated.** flex-auth consumes assurance claims as input and never re-defines them; `INTENT.md` is explicit that the identity layer owns authentication. Evidence *of authentication* belongs to the identity layer and `audit-core`. flex-auth owns evidence of the **decision**, which it already emits. |

An `intended_owner` in a gap register is a proposal to the named repository, not
an assignment to it — §2 keeps what a repository owns in that repository's own
`INTENT.md`. flex-auth suggests §13 gain a column distinguishing a proposed owner
from an assented one, so the register does not accumulate silent assignments the
way §14's assent row nearly did.

### Consistency defects

1. **Frontmatter `status: proposed` contradicts §14 "Status is accepted."**
   Material, because §2 makes this standard the authority for layer assignment.
   The change log records v0.2 as accepted and v0.3/v0.4 as proposed, so §14
   appears to be a carryover.
2. **§14's adoption count does not add up.** "seven of fifteen" and "the
   remaining eight" against a §4 catalog of 17 rows, 16 of them estate-authored
   (`OpenBao` excepted by §11's own who-must-declare rule). Seven declared plus
   the nine repositories actually listed is sixteen. Should read **seven of
   sixteen** and **the remaining nine**.
3. **§14 says "All three repositories whose boundaries moved"** above a table of
   four. `audit-core` is the fourth.

## Answers to FLEX-IN-0002

**(1) Is the boundary enough to unblock `FLEX-WP-0017` T03/T05 design?**
Yes for T03. Not quite for T05, which needs two things specified in
`approval-engine`'s contract first:

- **Claim shape must bind to the request digest flex-auth already computes.**
  The approval claim should carry the approval id plus the digest of the action
  it approves, computed over the same canonical binding as
  `NewDecisionBinding` (`FLEX-WP-0017-T01`). Otherwise "approved" and "approved
  *for this exact request*" are not distinguishable at decision time, and T05's
  wrong-action/lane/stage/targets proofs have nothing to compare against.
- **Single consumption needs an owner and an ordering.** flex-auth never mutates
  approvals, so consumption is `approval-engine`'s. But the decision precedes the
  action, and the action precedes consumption — so an allow rendered against an
  approval that is then never consumed, or consumed twice by a racing caller, is
  a gap neither engine closes alone. Naming who marks consumed and at what point
  relative to the decision belongs in the contract before T05, not after.

**(2) Is the maturity claim route practical from where flex-auth sits?**
Yes, with one caveat that is flex-auth's own fault rather than
`maturity-engine`'s. A level reaching flex-auth as a **request claim** is
practical today and lands in the decision binding. A level reaching flex-auth as
**registry content** is not reconstructable, because `DecisionProvenance` carries
no registry-snapshot digest — the gap flex-auth self-declared in §13. Until that
closes, maturity levels should arrive as request claims or versioned policy
rules, never compiled into the registry snapshot. This is the same constraint
flex-auth placed on zone stance, for the same reason.

## Consequences

- `FLEX-IN-0002` is closed; the assessment covers v0.4 rather than v0.3.
- flex-auth's assent now attaches to **v0.4** for §§1–8, §9.1–9.2, §9.4–9.6,
  and §§10–16, and to §9.3 only in its input-degradation half.
- `FLEX-WP-0017` T03/T05 stay `wait` on `approval-engine`, with the two contract
  items above raised as prerequisites for T05.
- `SCOPE.md` cites ops-warden `ADR-0006` as current; it is superseded by
  `ADR-0009`. Correcting that is flex-auth's own housekeeping.

## FLEX-DEC-2026-003 — Review of security layer model v0.6 and companion v0.1: assent, two answers, five findings

```yaml
id: FLEX-DEC-2026-003
kind: decision
title: 'Review of security layer model v0.6 and companion v0.1: assent, two answers,
  five findings'
status: resolved
origin: cross-repo
origin_ref: net-kingdom security-layer-model_v0.6 + companion_v0.1
standard: net-kingdom/canon/standards/security-layer-model_v0.6.md
owner: flex-auth
affects:
- flex-auth
- gate-house
- net-kingdom
- info-tech-canon
- ops-warden
- approval-engine
requested_dispositions:
- assent
- revise
- reject
created: '2026-08-29T08:18:39.602701Z'
updated: '2026-08-29T08:19:41.832549Z'
rationale: 'Assent to v0.6 and companion v0.1, with two answers and five findings,
  none blocking. Q1: section 6.4.2 is right but collides with 9.7.1''s session-bound
  allow, needs the request digest as its mechanical replay test, and should rule explicitly
  on deny-caching. Q2: the visibility deadline does land on a PDP and harder than
  at a PEP, but must be per input class rather than one number, and it makes flex-auth''s
  registry-provenance gap load-bearing rather than untidy. Findings: 6.4''s stance-map
  register does not exist in section 13 and neither document says where a map is published;
  the companion omits it too, which is the sufficiency gap gate-house asked for; section
  17 puts the decision-record schema in Taxonomy when it is the PDP''s output artifact,
  inverting the section 2 rule flex-auth used to decline authentication evidence;
  sections 17-19 are H1 outside the hierarchy; section 19 grades the document it lives
  in and will age.'
decided_by: flex-auth (reviewing side)
decided_at: '2026-08-29T08:19:41.832549Z'
state_hub_decision_id: "def6a31b-4cd7-4474-8cfa-339b0fc9fcc6"
```

## Context

gate-house published v0.5 (answering `FLEX-DEC-2026-002`), then v0.6 with a new
two-page companion, and asked flex-auth to review two rules specifically. This
record reviews **v0.6 + companion v0.1** and answers both questions.

Every finding in `FLEX-DEC-2026-002` was honored: §9.3 rewritten along the two-
owner split, §13 given an owner-status column with containment recorded as
*proposed* and authentication/assurance evidence as *declined* with flex-auth's
reasoning, all three consistency defects fixed, and both T05 answers folded into
`approval-engine`'s INTENT and `GH-WP-0002-T06`. gate-house also recorded
plainly that v0.4 had ruled against shipped assented behavior and that neither
it nor ops-warden caught it. That is the loop working.

## Disposition

**Assent to v0.6 and companion v0.1**, with two answers and five findings. None
blocks adoption.

The Engine typing in §3.3 is a real improvement and flex-auth endorses it,
particularly *"a new engine is a PIP unless this standard is amended"* — that
sentence is the structural form of §6, and it forecloses the drift §6 was
written to prevent.

### Answer to question 1 — §6.4.2, no local recaching of the verdict

**The rule is right and flex-auth supports it.** Caching the answer is deciding
early at the consumer; caching an input claim under its own freshness rule is
not. Three refinements, one of which is a genuine collision:

**(a) It contradicts §9.7.1 as written.** §9.7.1 permits an allow bound to *"a
session or obligation that ends."* A session-bound allow is used across later
requests by construction — that is what binding to a session means. §6.4.2
forbids replaying a stored verdict *"for a later request."* Taken together, a
session-bound allow is both permitted and prohibited. The fix is small: scope
§6.4.2 to requests **outside the decision's own stated binding and lifetime**,
which preserves the rule and legalizes exactly the case §9.7.1 already intends.

**(b) "Later request" needs a mechanical test, and flex-auth already ships one.**
A PEP retrying an identical action after a transport failure is not a later
request, but nothing in the standard says how to tell. flex-auth computes a
canonical request digest over the normalized subject, action, resource, and
context (`NewDecisionBinding`, `FLEX-WP-0017-T01`), and it is already in every
decision binding. flex-auth offers it as the normative test: **replay is
permitted iff the request digest matches and the decision's lifetime holds.**
That makes §6.4.2 checkable rather than a matter of implementer judgment, and it
costs the estate nothing new.

**(c) Deny-caching is the one real pattern the rule outlaws without naming it.**
A consumer caching a *deny* under load cannot manufacture authority — §8's
asymmetry holds, and it protects the PDP from retry storms, which is a real
operational need. But it does breach §6.4.4: an action refused with no decision
record naming that request is not reconstructable, and a stale deny is an
availability failure that will be misdiagnosed as a policy one. flex-auth's
recommendation is to **rule on it explicitly** rather than leave implementers to
infer: permit short-lived negative caching only where the refusal is still
recorded, or forbid it in terms. Either is defensible; silence is not, because
this is the pattern an implementer under load reaches for first.

### Answer to question 2 — §9.7.2, does the visibility deadline land on a PDP

**Yes, and it lands harder on the PDP than on the PEP** — but one number is the
wrong shape for a decision point.

A PEP has one boundary and can state one deadline. A PDP's revocation visibility
is **per input class**, because a decision is a join over sources with unrelated
refresh behavior: approval-claim freshness from `approval-engine`, registry
snapshot cadence, policy package activation, and directory ETag. A single
flex-auth number would be either a fiction or the worst case, and the worst case
is the registry snapshot — which is the slowest and the least visible. Proposed:
**§9.7.2 requires a per-input-class deadline at a PDP and a single boundary
deadline at a PEP.**

The consequence for flex-auth is worth stating plainly, because it changes
flex-auth's own priorities. §9.7.2 makes the self-declared registry-provenance
gap **load-bearing rather than untidy**. Without a snapshot digest in
`DecisionProvenance`, nobody can determine after the fact which snapshot a
decision read, so a stated visibility deadline for registry-borne facts is
unfalsifiable — the deadline and the digest are the same gap seen from two
sides. flex-auth accepts that this raises the gap from housekeeping to a
conformance prerequisite and will plan it as one.

### Finding 1 — §6.4's stance-map register does not exist

§6.4 requires every PEP-shaped consumer to publish its stance map and requires
those maps to be *"inventoried — in `maturity-engine` once it exists, in §13
until then."* **§13 contains no stance rows and does not mention stance maps.**
Neither document says where a map is published or in what form.

This matters for precisely the reason §6.4 gives: without the register,
*"`z0`–`z2` and unknown fail open"* is the estate's effective policy with nobody
having compiled it. `ops-warden` `ADR-0009` is cited three times across the two
documents as the reference shape and appears in no register. flex-auth has a
direct interest here — the aggregate of consumer stances is the estate's real
authorization behavior, and flex-auth is the only repository positioned to
notice when it diverges from what the policy packages say.

### Finding 2 — the companion omits it too, which answers the question asked

gate-house asked what would show the companion is not sufficient on its own.
Companion §5.3 says *"publish your unreachable-engine stance"* but never says
**where**, and omits the inventory obligation entirely. A repository satisfying
the companion faithfully would publish a stance map into its own repo and
believe itself conforming, and no register would learn of it. On every other
point reviewed the companion is faithful to the statute; this is the one gap.

### Finding 3 — §17 puts the decision-record schema in the wrong layer

The four artifacts are the right four, and Taxonomy is right for three of them.
The **request-claim schema** is genuinely cross-engine vocabulary and belongs
there; so do the gap-record and emission-cadence artifacts.

The **decision-record schema** does not. A decision record is the PDP's output
artifact — the one thing in the estate that only `access-engine` produces — and
§2 keeps what a repository owns in that repository's own `INTENT.md`. flex-auth
already publishes its shape: the `binding` in `DecisionEnvelope`, the request
digest, and `schemas/action_authorization.schema.json`. Taxonomy authoring the
schema for an artifact only flex-auth emits inverts the ownership rule the
standard applies everywhere else.

This is the same §2 argument flex-auth used to decline authentication and
assurance evidence in `FLEX-DEC-2026-002`, and gate-house accepted it there.
Symmetry requires flex-auth to apply it against its own interest as well as for
it: proposed split is **claim / gap-record / emission-cadence to Taxonomy,
decision-record schema to `access-engine` as a published contract**, with
Taxonomy holding only the shared field vocabulary the claim schema needs to
reference. flex-auth will publish that contract; it should not receive it.

### Finding 4 — §§17–19 are H1, outside the section hierarchy

They use `#` where every other section uses `##`, so they render as siblings of
the document title rather than sections of it. Mechanical, but the standard asks
repositories to cite section numbers, and §§17–18 carry normative content.

### Finding 5 — §19 grades the document it lives in

A *"Verdict on fitness"* inside a standard of record makes the assessment
normative by adjacency and will age against the text it grades — v0.7 will
either restate it or leave a stale verdict in force. Suggest it live in the
2026-08-29 assessment history document and be cited from §16, where the open
questions already carry the same content as questions rather than as a grade.

## Consequences

- flex-auth's assent attaches to **v0.6 + companion v0.1**, with §6.4.2 and
  §9.7.2 read as refined above pending gate-house's disposition.
- The registry-snapshot digest gap is reclassified from housekeeping to a
  conformance prerequisite under §9.7.2, and will be planned as one.
- flex-auth offers the canonical request digest as the §6.4.2 replay test and
  offers to publish the decision-record schema as its own contract.