secrets-engine confirmed T03, and re-verifying against the regenerated
destroy fixture found something neither repository can fix alone: a
pdp_digest recorded at issue time can never equal the request_digest of a
request that carries the claim in its context, because the claim is part
of the context that is hashed. Embedding the claim changes the very
digest the claim would need to name.
Not fixture staleness. It holds for every dual-control request whose
claim travels in context -- the shape GH-DEC-2026-008 had just ruled
mandatory. Left unresolved that ruling was unimplementable for exactly
the case it was written for, and destroy would have been permanently
un-allowable in production, failing closed forever on a check that could
never pass.
flex-auth owns the canonical request digest, so the fix is ours.
binding.approval_binding_digest is the same material with
context.approval removed, emitted only when a claim was carried. An
approval issued against a claim-free Check records that Check's
request_digest; the claim-bearing request reproduces it here.
DELIBERATELY ADDITIVE, and the reason matters. The tempting fix is to
drop context.approval from request_digest entirely. That is wrong:
request_digest is the replay identity, and two requests differing only in
which approval was presented must not share one, because their decisions
differ -- one allows, the other denies dual_control_required. Collapsing
them would let an allow obtained with a valid claim be replayed against a
request carrying none. So request_digest still covers the claim and still
moves; approval_binding_digest deliberately does not, and is documented
as not a replay identity. The tests assert the two functions DISAGREE on
a claim-bearing request, which is approval-engine's formulation of how to
defend a distinction that looks like duplication.
The fixture now demonstrates the property rather than asserting it: its
claim's pdp_digest equals the envelope's approval_binding_digest with
pdp_path true, and changing the claim's contents moved request_digest
while leaving approval_binding_digest untouched. Two files a consumer can
diff.
Also picked up approval-engine's new required binding.pdp_path via the
cross-repo schema test added yesterday -- which is the test doing exactly
what it was built for, one day later.
T03 is done. secrets-engine's own digest-material defect, which our two
real envelopes caught, is recorded in the workplan.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
approval-engine filed APPROVAL-IN-0002: secrets-engine built its PEP
validator against our ActionAuthorization schema, pointed it at
GET /v1/approvals/{id}/claim, and it rejects every response. Both
envelopes declare schema_version 0.1, so it fails late and reads like an
approval-engine outage rather than a contract mismatch.
FLEX-DEC-2026-006 accepts the deferral and argues against flex-auth's own
proposal. The composed object had the PIP republish our decision, which
crosses the same layer boundary we invoked to decline authentication
evidence and to win section 17's schema. The claim-plus-DecisionEnvelope
split drops no check; each verification lands on the layer that owns it.
approval-engine asked, before the decision, whether the open G3 finding
argues for ratifying now. It does not: G3 is already closed the other
way. FLEX-WP-0019 added lifetime to the DecisionEnvelope itself, required
on every allow by schema conditional, published 2026-09-02. The trigger
resolved by adding a field rather than by composition, so the decision
stands alone and needs no bundle.
The provenance.authority == state-hub constant is our defect and is
fixed at source. It came from examples/caring/action_authorization.json,
which contradicted the same contract's ownership section. That fixture
now names approval-engine as the approval fact's authority and flex-auth
as the decision's, and its stale secrets-engine.lifecycle pin is
corrected to the reserved coordinate from FLEX-DEC-2026-005.
The contract doc and schema are marked deferred-not-withdrawn so no
other consumer builds a validator against them. The execute-time half is
untouched: /v1/check, binding, the canonical digest, and
flex-auth.decision-record.v1 stay published.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
Two cross-repo questions arrived in the flex-auth inbox and both are
answered as decision records rather than as prose in a message.
FLEX-DEC-2026-004 answers ops-warden WARDEN-WP-0034-T05. A decision
lifetime shorter than the SSH certificate TTL is meaningful, but only as
authority to issue, never as authority to use an already-issued
certificate. The pre-sign gate is the only consumer of the shorter
lifetime: no replay past expires_at, fresh Check per sign. The lever that
shortens effective access is the requested TTL as a policy input, which
is already deployed as the ttl_out_of_bounds deny. ops-warden's section
9.7.2 window through certificate TTL is correct as written and correctly
owned by the PEP; flex-auth does not want that residue moved to the PDP.
docs/decision-input-freshness.md gains the same boundary as published
contract text, so the ruling is not only in the decision log.
FLEX-DEC-2026-005 answers secrets-engine. A real policy package is
expected and flex-auth authors it here as it does for every consumer; the
reserved coordinate is secrets-engine.catalog-lane.lifecycle v1 and it
does not exist yet. Their choice not to default the pin was correct and
is endorsed explicitly. POST /v1/check is deployed but has no
estate-wide address by design -- per-consumer cluster-local pins with
default-deny ingress -- so their 2026-09-06 probe found the design
working, not an outage.
FLEX-WP-0021 carries that work: obtain the real action vocabulary from
secrets-engine, publish the package with fixtures, confirm the digest
join against a real decision record, then stand up a
flex-auth-secrets-engine pin in warn without moving the other two pins.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
The standard was accepted at v0.7 on 2026-08-29. Four of flex-auth's review
findings are in the accepted text: 9.3's two-owner split, 6.4.2 scoped to the
decision's own binding with our canonical request digest as its mechanical test,
9.7.2 split by role, and 17 moving the decision-record schema to access-engine.
INTENT.md
- Machine-readable layer declaration in frontmatter (layer: Engine, role: PDP),
which section 11 requires and we did not have. audit-core noted our
declaration was legible only by following the decision trail.
- PDP failure semantics stated: our outage is consumer residue, not input
degradation; fail-open is not expressible by a PDP at all.
- Four owned obligations added: the decision-record schema as our contract, the
request digest as the published replay test, a lifetime on every allow, and
visibility deadlines per input class.
- A Layer Conformance section stating the state honestly: conforming with one
declared gap, no Tooling client, not PEP-shaped.
- Vocabulary correction: earlier text dropped "control plane" as Staff
vocabulary. Section 8 binds it to the Engine layer, which is why kings-guard
was asked to release it. The term is ours; we prefer "decision engine" for
precision, not boundary.
SCOPE.md
- Layer and role in the one-liner; the four obligations In Scope; five
boundaries established in review but never written down Out of Scope.
- Three capability blocks marked planned for workplans completed in May are now
current; two blocks added.
- Superseded ADR-0006 citation corrected to ADR-0009, which retires the global
flag outright rather than deferring it.
history/2026-08-29-layer-model-v0.7-alignment-review.md checks each obligation
against the code and finds six gaps. FLEX-WP-0019 closes them, with T02 before
T04 because a visibility deadline for registry-borne facts is unfalsifiable
until provenance can identify the snapshot a decision read.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012sgN4GH5ZYT8pJVkCR6dcP
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014348@bnt-lap001
Assistant-Session: a993abda-65a0-4ea8-8ccd-0fcd78c92ac0
FLEX-IN-0002 asked for review of v0.3; v0.4 supersedes it, so the assessment is
against v0.4 plus the in-place section 11 amendment.
Assent, with one rule contested:
- Section 9.3 conflates two failure cases. Input degradation inside a reachable
engine is flex-auth's fallback and is accepted. Engine unreachability is not:
there is no evaluator in the path to express anything, which is why flex-auth
has held that fail-open is not expressible by a PDP at all. As written 9.3
also collides with ops-warden ADR-0009 (accepted, superseding ADR-0006),
which retires the global flag for a total per-zone map in the consumer PEP —
the correct design, since the alternative makes flex-auth a hard dependency
of the SSH certificate the tunnel carrying the policy call depends on.
- Section 13 names access-engine as intended owner of two capabilities never
reviewed here. Containment is plausible and recorded as proposed owner only.
Authentication/assurance evidence is declined as stated: flex-auth consumes
assurance claims and never re-defines them.
- Three consistency defects: frontmatter status proposed vs section 14
"accepted"; "seven of fifteen"/"remaining eight" against sixteen
estate-authored catalog rows and nine listed; "all three repositories" above
a table of four.
FLEX-IN-0002's two questions answered: the approval boundary unblocks T03
design, but T05 needs the approval claim bound to the same request digest
NewDecisionBinding computes, and a named owner and ordering for single
consumption. The maturity claim route works as a request claim, not as registry
content, until the self-declared provenance digest gap closes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012sgN4GH5ZYT8pJVkCR6dcP
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014348@bnt-lap001
Assistant-Session: a993abda-65a0-4ea8-8ccd-0fcd78c92ac0
flex-auth answers gate-house's assent request on the three items ratified in
GH-DEC-2026-001, following the estate precedent that a boundary is drawn on
review by the other side.
Assent to all three, with one conformance debt flex-auth accepts as its own and
two conditions on the rename:
- Engine framing and sole decision point: assent. flex-auth cannot hold this
boundary against zone-engine and decline it as a general rule. But standard
section 6 also binds flex-auth: DecisionProvenance carries no registry
snapshot digest, so a decision that turned on registry content cannot be
replayed from its own provenance. Recorded as a known non-conformance rather
than claimed as conformance.
- access-engine rename: assent to the name, not to execution. Repository
identity and runtime identity must rename in separate revertible steps —
since FLEX-WP-0016 the enforcing ops-warden pin binds tokens to the
protected-system name, so a single-step rename 401s every warden sign,
including the certificate the ops-bridge tunnels depend on. FLEX-WP prefix
ownership stays with the repository.
- Authoring/evaluation split: assent, with the section 6 test applied
symmetrically — a gate-house authority ceiling that determines an outcome
reaches the decision as an input claim or as a rule in the versioned policy
package, so its application stays reconstructable from the decision record.
FLEX-WP-0017-T03 stays wait: the design half re-routes to gate-house, the
durable storage half remains unowned and is raised as an engine gap under
section 5.
Decision id follows the canon scheme {PREFIX}-DEC-YYYY-NNN.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012sgN4GH5ZYT8pJVkCR6dcP
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4014348@bnt-lap001
Assistant-Session: a993abda-65a0-4ea8-8ccd-0fcd78c92ac0
