# 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.