flex-auth/.repo-manager/index.json

1627 lines
65 KiB
JSON
Raw Normal View History

Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
{
"schema": "repo_manager.index.v1",
"slug": "flex-auth",
"repo_root": "/home/worsch/flex-auth",
Publish approval_binding_digest: a claim cannot name the request carrying it 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
2026-09-06 14:52:33 +02:00
"head_sha": "9f3e7e363a11f611e13d4d798dba575c56168521",
"observed_at": "2026-09-06T12:52:08.174834Z",
"source_fingerprint": "a19f5aa8b0f293bbd5d768adaa50c8afff5c0f0be3757e1b7af62ac791ab228f",
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
"source_files": [
".repo-classification.yaml",
"INTENT.md",
"decisions/decisions.md",
"intakes/intakes.md",
"workplans/FLEX-WP-0001-repo-intent-and-architecture-baseline.md",
"workplans/FLEX-WP-0002-standalone-policy-as-code-core.md",
"workplans/FLEX-WP-0003-markitect-consumer-integration.md",
"workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md",
"workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md",
"workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md",
"workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md",
"workplans/FLEX-WP-0008-tenant-engine-consumer-integration.md",
"workplans/FLEX-WP-0009-user-engine-production-policy-service.md",
"workplans/FLEX-WP-0010-tenant-lifecycle-policy-actions.md",
"workplans/FLEX-WP-0011-railiance-staged-promotion-overlay.md",
"workplans/FLEX-WP-0012-credential-grant-authorization-surface.md",
"workplans/FLEX-WP-0013-restore-seven-action-tenant-engine-pin.md",
"workplans/FLEX-WP-0014-tenant-guardrail-policy-actions.md",
"workplans/FLEX-WP-0015-tenancy-posture-conformance.md",
"workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md",
"workplans/FLEX-WP-0017-action-bound-authorization-contract.md",
Answer ops-warden and secrets-engine; open FLEX-WP-0021 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
2026-09-06 01:12:50 +02:00
"workplans/FLEX-WP-0018-inbound-auth-corrections.md",
"workplans/FLEX-WP-0019-layer-model-conformance.md",
Accept ActionAuthorization deferral; fix the state-hub authority constant 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
2026-09-06 01:30:04 +02:00
"workplans/FLEX-WP-0020-repository-identity-migration.md",
"workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md"
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
],
"work_records": [
{
"kind": "workplan",
"id": "FLEX-WP-0001",
"status": "done",
"title": "Repo Intent and Authorization Architecture Baseline",
"source_path": "workplans/FLEX-WP-0001-repo-intent-and-architecture-baseline.md",
"uuid": "4dbefd19-bb7d-405c-9a50-e7dbd11cf4d9",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0001-T001",
"status": "done",
"title": "P1.1 - Define project intent",
"source_path": "workplans/FLEX-WP-0001-repo-intent-and-architecture-baseline.md",
"uuid": "5af30b01-ea72-4f87-b74e-a595fd3a5bd7",
"parent_id": "FLEX-WP-0001",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0001-T002",
"status": "done",
"title": "P1.2 - Define responsibility boundaries",
"source_path": "workplans/FLEX-WP-0001-repo-intent-and-architecture-baseline.md",
"uuid": "145ec0ec-130a-4209-9028-1ae06e3664e3",
"parent_id": "FLEX-WP-0001",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0001-T003",
"status": "done",
"title": "P1.3 - Capture open-source and enterprise landscape",
"source_path": "workplans/FLEX-WP-0001-repo-intent-and-architecture-baseline.md",
"uuid": "c52a9e3e-e264-418d-b462-d5a9d6e22b30",
"parent_id": "FLEX-WP-0001",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0001-T004",
"status": "done",
"title": "P1.4 - Establish first-consumer architecture",
"source_path": "workplans/FLEX-WP-0001-repo-intent-and-architecture-baseline.md",
"uuid": "7756c4c5-598a-4894-9352-6e7145cb3522",
"parent_id": "FLEX-WP-0001",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0002",
"status": "completed",
"title": "Standalone Policy-as-Code Core",
"source_path": "workplans/FLEX-WP-0002-standalone-policy-as-code-core.md",
"uuid": "aa60e183-9a87-4e03-99b0-15786bfa11ae",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0002-T001",
"status": "done",
"title": "P2.1 - Define canonical schemas",
"source_path": "workplans/FLEX-WP-0002-standalone-policy-as-code-core.md",
"uuid": "534e5251-8529-48fe-8cf8-b3b6bc4ec1f4",
"parent_id": "FLEX-WP-0002",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0002-T002",
"status": "done",
"title": "P2.2 - Implement local registry store",
"source_path": "workplans/FLEX-WP-0002-standalone-policy-as-code-core.md",
"uuid": "d8045124-f0ae-495d-87b5-24fd9528ef93",
"parent_id": "FLEX-WP-0002",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0002-T003",
"status": "done",
"title": "P2.3 - Implement policy package loader and validator",
"source_path": "workplans/FLEX-WP-0002-standalone-policy-as-code-core.md",
"uuid": "09be0f25-e5ba-42b5-8b2f-36fd0ef2fe6b",
"parent_id": "FLEX-WP-0002",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0002-T004",
"status": "done",
"title": "P2.4 - Implement deterministic check and batch_check APIs",
"source_path": "workplans/FLEX-WP-0002-standalone-policy-as-code-core.md",
"uuid": "f6427575-00af-4f3e-ab30-5b9a158343ef",
"parent_id": "FLEX-WP-0002",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0002-T005",
"status": "done",
"title": "P2.5 - Implement list_allowed and explain",
"source_path": "workplans/FLEX-WP-0002-standalone-policy-as-code-core.md",
"uuid": "e8fcbabd-4eb6-41d2-a4d5-6f40cc245a7e",
"parent_id": "FLEX-WP-0002",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0002-T006",
"status": "done",
"title": "P2.6 - Add local decision log",
"source_path": "workplans/FLEX-WP-0002-standalone-policy-as-code-core.md",
"uuid": "2def10c1-4b5f-44a8-8e6b-4c8592fffd43",
"parent_id": "FLEX-WP-0002",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0002-T007",
"status": "done",
"title": "P2.7 - Add CLI and service skeleton",
"source_path": "workplans/FLEX-WP-0002-standalone-policy-as-code-core.md",
"uuid": "ee9ae6dd-c31f-4d4e-b238-533a2b8040d4",
"parent_id": "FLEX-WP-0002",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0002-T008",
"status": "done",
"title": "P2.8 - Add tests and examples",
"source_path": "workplans/FLEX-WP-0002-standalone-policy-as-code-core.md",
"uuid": "6cbe572a-2877-4936-8ef3-63b79900fae2",
"parent_id": "FLEX-WP-0002",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0003",
"status": "completed",
"title": "Markitect Consumer Integration",
"source_path": "workplans/FLEX-WP-0003-markitect-consumer-integration.md",
"uuid": "c0a6c9f6-bb6b-416d-b537-f30504c63d75",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0003-T001",
"status": "done",
"title": "P3.1 - Define Markitect resource namespace",
"source_path": "workplans/FLEX-WP-0003-markitect-consumer-integration.md",
"uuid": "53f2fa67-780b-4e40-bbda-e669e4cecc32",
"parent_id": "FLEX-WP-0003",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0003-T002",
"status": "done",
"title": "P3.2 - Import Markitect resource manifests",
"source_path": "workplans/FLEX-WP-0003-markitect-consumer-integration.md",
"uuid": "90082eaf-37f5-492f-a884-ff8eec0eccaa",
"parent_id": "FLEX-WP-0003",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0003-T003",
"status": "done",
"title": "P3.3 - Define Markitect action vocabulary",
"source_path": "workplans/FLEX-WP-0003-markitect-consumer-integration.md",
"uuid": "cfc78bbb-5425-4780-a860-9109df62ea37",
"parent_id": "FLEX-WP-0003",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0003-T004",
"status": "done",
"title": "P3.4 - Implement Markitect check fixtures",
"source_path": "workplans/FLEX-WP-0003-markitect-consumer-integration.md",
"uuid": "1d5de3b2-c581-4ca3-9107-93211eb02c6b",
"parent_id": "FLEX-WP-0003",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0003-T005",
"status": "done",
"title": "P3.5 - Add Markitect adapter contract tests",
"source_path": "workplans/FLEX-WP-0003-markitect-consumer-integration.md",
"uuid": "f9297b0d-69dc-495c-a650-ca671f2c59c7",
"parent_id": "FLEX-WP-0003",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0003-T006",
"status": "done",
"title": "P3.6 - Document integration flow",
"source_path": "workplans/FLEX-WP-0003-markitect-consumer-integration.md",
"uuid": "e34b0303-4416-40a3-8b34-e0e80d644aea",
"parent_id": "FLEX-WP-0003",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0004",
"status": "completed",
"title": "Delegated PDP and Directory Adapters",
"source_path": "workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md",
"uuid": "99a82976-d376-42b0-89cc-c44e01c0bec6",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0004-T001",
"status": "done",
"title": "P4.1 - Implement Topaz adapter",
"source_path": "workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md",
"uuid": "9046418c-2b78-42c6-8bfa-76d6ed0050dd",
"parent_id": "FLEX-WP-0004",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0004-T002",
"status": "done",
"title": "P4.2 - Add relationship PDP adapter boundary",
"source_path": "workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md",
"uuid": "b77a0b70-b492-46ba-badf-8c2eebe006aa",
"parent_id": "FLEX-WP-0004",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0004-T003",
"status": "done",
"title": "P4.3 - Add rule PDP adapter boundary",
"source_path": "workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md",
"uuid": "4e4e5e45-c05a-4a31-8126-f0c7676b1e6c",
"parent_id": "FLEX-WP-0004",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0004-T004",
"status": "done",
"title": "P4.4 - Add Keycloak Authorization Services adapter path",
"source_path": "workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md",
"uuid": "8d3bbc28-985b-4dd7-9fb8-f9a858eb5a6b",
"parent_id": "FLEX-WP-0004",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0004-T005",
"status": "done",
"title": "P4.5 - Add Entra/Graph and SCIM group resolver adapters",
"source_path": "workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md",
"uuid": "4fc3fb91-8763-453e-8e54-36178cb11efd",
"parent_id": "FLEX-WP-0004",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0004-T006",
"status": "done",
"title": "P4.6 - Add delegated-mode operations docs",
"source_path": "workplans/FLEX-WP-0004-delegated-pdp-and-directory-adapters.md",
"uuid": "491260f9-b4d7-46fe-8220-d358597db33a",
"parent_id": "FLEX-WP-0004",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0005",
"status": "done",
"title": "Foundations and Topaz Alignment",
"source_path": "workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md",
"uuid": "e37d42a9-0018-4a67-a672-ff4e9716b338",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0005-T001",
"status": "done",
"title": "P5.1 - Record ADR-001 / ADR-002 / ADR-003",
"source_path": "workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md",
"uuid": "8193a278-a044-4397-a4a8-232104374cdc",
"parent_id": "FLEX-WP-0005",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0005-T002",
"status": "done",
"title": "P5.2 - Land Go project skeleton",
"source_path": "workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md",
"uuid": "8ac73c33-6d36-4963-990d-28b0d1d60947",
"parent_id": "FLEX-WP-0005",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0005-T003",
"status": "done",
"title": "P5.3 - Pin FlexAuthResourceManifest schema",
"source_path": "workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md",
"uuid": "80285e1e-16ec-4f4e-b491-1e79f200219f",
"parent_id": "FLEX-WP-0005",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0005-T004",
"status": "done",
"title": "P5.4 - Topaz alignment spike",
"source_path": "workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md",
"uuid": "b8a314c3-e98e-4093-bb11-ab8546b8d79b",
"parent_id": "FLEX-WP-0005",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0005-T005",
"status": "done",
"title": "P5.5 - Cite NetKingdom IAM Profile and pin claim consumption",
"source_path": "workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md",
"uuid": "b31dab7b-e72c-4abe-b6d5-f5875fd0c25a",
"parent_id": "FLEX-WP-0005",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0005-T006",
"status": "done",
"title": "P5.6 - Confirm ops-warden boundary",
"source_path": "workplans/FLEX-WP-0005-foundations-and-topaz-alignment.md",
"uuid": "dcd45a14-20fc-49d0-b869-08cda85fcbc5",
"parent_id": "FLEX-WP-0005",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0006",
"status": "finished",
"title": "Ops-Warden SSH Signing Policy Gate",
"source_path": "workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md",
"uuid": "bbea4049-8acc-4d7c-8cf5-3106c6b93f7f",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0006-T01",
"status": "done",
"title": "T1 - Pin the ops-warden protected-system contract",
"source_path": "workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md",
"uuid": "8831b904-dbef-4d55-8eb5-053c939c86b3",
"parent_id": "FLEX-WP-0006",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0006-T02",
"status": "done",
"title": "T2 - Author the ssh-certificate sign policy package",
"source_path": "workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md",
"uuid": "9ea206fa-f93d-46b6-8b8e-e8669dd502d4",
"parent_id": "FLEX-WP-0006",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0006-T03",
"status": "done",
"title": "T3 - Add allow and deny fixtures",
"source_path": "workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md",
"uuid": "6bf5cb9b-d46c-49cf-aec0-12f6e864a1f8",
"parent_id": "FLEX-WP-0006",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0006-T04",
"status": "done",
"title": "T4 - Verify the `/v1/check` service contract",
"source_path": "workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md",
"uuid": "077d29db-30e0-4447-90fd-620c0884306c",
"parent_id": "FLEX-WP-0006",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0006-T05",
"status": "done",
"title": "T5 - Hand off production-readiness evidence to ops-warden",
"source_path": "workplans/FLEX-WP-0006-ops-warden-ssh-signing-policy-gate.md",
"uuid": "06cac0b1-51c0-4ae0-b605-c940f7821ac7",
"parent_id": "FLEX-WP-0006",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0007",
"status": "finished",
"title": "Ops-Warden Policy Gate Production Deployment",
"source_path": "workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md",
"uuid": "358ce697-2611-4fe9-89ab-63e86ceb00fa",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0007-T01",
"status": "done",
"title": "T1 - Deploy production flex-auth runtime",
"source_path": "workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md",
"uuid": "727573fc-86a3-4f5a-abd7-40b0ccb01e68",
"parent_id": "FLEX-WP-0007",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0007-T02",
"status": "done",
"title": "T2 - Load production registry and verify real actors",
"source_path": "workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md",
"uuid": "6ec1e00c-4a3a-475b-aefb-af3961de7070",
"parent_id": "FLEX-WP-0007",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0007-T03",
"status": "done",
"title": "T3 - Publish registry sync contract with ops-warden",
"source_path": "workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md",
"uuid": "afa09ec3-516c-433d-87a7-330cb79845a8",
"parent_id": "FLEX-WP-0007",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0007-T04",
"status": "done",
"title": "T4 - Joint OpenBao + policy gate production smoke",
"source_path": "workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md",
"uuid": "32a96f1c-e0e8-4e27-baa6-7b8c445cf7a1",
"parent_id": "FLEX-WP-0007",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0007-T05",
"status": "done",
"title": "T5 - IAM subject binding for production",
"source_path": "workplans/FLEX-WP-0007-ops-warden-policy-gate-production-deployment.md",
"uuid": "65dc3c59-1e4b-4335-b6a0-db492ea9b2b5",
"parent_id": "FLEX-WP-0007",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0008",
"status": "finished",
"title": "tenant-engine Consumer Integration",
"source_path": "workplans/FLEX-WP-0008-tenant-engine-consumer-integration.md",
"uuid": "1358db95-967c-5a03-8b8c-4816dc106594",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0008-T01",
"status": "done",
"title": "Task: Define tenant-engine resource and action vocabulary",
"source_path": "workplans/FLEX-WP-0008-tenant-engine-consumer-integration.md",
"uuid": "5606408f-f94c-5d79-ba41-ed23fadac480",
"parent_id": "FLEX-WP-0008",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0008-T02",
"status": "done",
"title": "Task: Author and register the tenant-engine policy package",
"source_path": "workplans/FLEX-WP-0008-tenant-engine-consumer-integration.md",
"uuid": "bbe1a8f4-dcd9-58bb-8d82-386ee0c11a51",
"parent_id": "FLEX-WP-0008",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0008-T03",
"status": "done",
"title": "Task: tenant-engine live-lookup context adapter",
"source_path": "workplans/FLEX-WP-0008-tenant-engine-consumer-integration.md",
"uuid": "e27d24b3-0aef-5bd4-b7e3-81532cd7aa9c",
"parent_id": "FLEX-WP-0008",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0008-T04",
"status": "done",
"title": "Task: Closure review",
"source_path": "workplans/FLEX-WP-0008-tenant-engine-consumer-integration.md",
"uuid": "0f319a2f-e4bb-5ba8-92de-b693ae9a2aa3",
"parent_id": "FLEX-WP-0008",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0009",
"status": "finished",
"title": "Provide production authorization for user-engine",
"source_path": "workplans/FLEX-WP-0009-user-engine-production-policy-service.md",
"uuid": "390da58d-3c58-5102-bd3c-7133956c810e",
"parent_id": null,
"extra": {
"depends_on": [
"NK-WP-0024"
]
}
},
{
"kind": "task",
"id": "FLEX-WP-0009-T01",
"status": "done",
"title": "T01 - Pin the protected-system vocabulary",
"source_path": "workplans/FLEX-WP-0009-user-engine-production-policy-service.md",
"uuid": "4607222e-3407-59c4-b388-aa7c88f7e3ef",
"parent_id": "FLEX-WP-0009",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0009-T02",
"status": "done",
"title": "T02 - Implement and verify the policy package",
"source_path": "workplans/FLEX-WP-0009-user-engine-production-policy-service.md",
"uuid": "7ae9de35-4f71-54d8-aabb-858c1202c833",
"parent_id": "FLEX-WP-0009",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0009-T03",
"status": "done",
"title": "T03 - Deploy the cluster-local service",
"source_path": "workplans/FLEX-WP-0009-user-engine-production-policy-service.md",
"uuid": "9a1ea146-0735-5d6f-bd75-96eb78e9bd2b",
"parent_id": "FLEX-WP-0009",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0009-T04",
"status": "done",
"title": "T04 - Hand back production evidence",
"source_path": "workplans/FLEX-WP-0009-user-engine-production-policy-service.md",
"uuid": "9639adbe-4392-5f6c-a924-3771f71ab94c",
"parent_id": "FLEX-WP-0009",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0010",
"status": "finished",
"title": "Authorize tenant-engine lifecycle actions",
"source_path": "workplans/FLEX-WP-0010-tenant-lifecycle-policy-actions.md",
"uuid": "fdabae84-dc9e-5ccd-81df-8ae7e66b90b8",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0010-T01",
"status": "done",
"title": "T01 - Extend the policy package with the lifecycle actions",
"source_path": "workplans/FLEX-WP-0010-tenant-lifecycle-policy-actions.md",
"uuid": "8deb9564-658e-5eff-8ef7-94838bee05cc",
"parent_id": "FLEX-WP-0010",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0010-T02",
"status": "done",
"title": "T02 - Decide whether retirement warrants stricter authorization",
"source_path": "workplans/FLEX-WP-0010-tenant-lifecycle-policy-actions.md",
"uuid": "82d13a89-a344-5797-b10f-390d17b11b73",
"parent_id": "FLEX-WP-0010",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0010-T03",
"status": "done",
"title": "T03 - Fixtures and verification",
"source_path": "workplans/FLEX-WP-0010-tenant-lifecycle-policy-actions.md",
"uuid": "2fbceaf5-514b-5ded-adb1-f4e63ce96160",
"parent_id": "FLEX-WP-0010",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0010-T04",
"status": "done",
"title": "T04 - Closure and handoff",
"source_path": "workplans/FLEX-WP-0010-tenant-lifecycle-policy-actions.md",
"uuid": "eb2579cb-b54f-5834-abcc-81954ac34889",
"parent_id": "FLEX-WP-0010",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0011",
"status": "finished",
"title": "Bring flex-auth under the railiance staged-promotion contract",
"source_path": "workplans/FLEX-WP-0011-railiance-staged-promotion-overlay.md",
"uuid": "deda35b4-f41d-559e-954e-a75f29237f68",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0011-T01",
"status": "done",
"title": "T01 - Author the railiance overlay",
"source_path": "workplans/FLEX-WP-0011-railiance-staged-promotion-overlay.md",
"uuid": "75748946-68c0-5f33-abe1-810fcd55e93f",
"parent_id": "FLEX-WP-0011",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0011-T02",
"status": "done",
"title": "T02 - Prove the stage commands",
"source_path": "workplans/FLEX-WP-0011-railiance-staged-promotion-overlay.md",
"uuid": "4becc09f-2331-5487-a794-643c748dd1bd",
"parent_id": "FLEX-WP-0011",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0011-T03",
"status": "done",
"title": "T03 - Correct the stale drain-plan row",
"source_path": "workplans/FLEX-WP-0011-railiance-staged-promotion-overlay.md",
"uuid": "abb788fe-22a5-5226-9f08-a43e20a47ce9",
"parent_id": "FLEX-WP-0011",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0012",
"status": "finished",
"title": "Authorize railiance-platform credential-grant requests",
"source_path": "workplans/FLEX-WP-0012-credential-grant-authorization-surface.md",
"uuid": "2a6b5764-1831-5305-b46e-0991d02675df",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0012-T01",
"status": "done",
"title": "T01 - Decide where the translation lives",
"source_path": "workplans/FLEX-WP-0012-credential-grant-authorization-surface.md",
"uuid": "f8491771-be1a-5c70-a4aa-059e48536630",
"parent_id": "FLEX-WP-0012",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0012-T02",
"status": "done",
"title": "T02 - Credential-grant policy package and fixtures",
"source_path": "workplans/FLEX-WP-0012-credential-grant-authorization-surface.md",
"uuid": "685f3d70-7c50-5664-95ae-1e8c93b14073",
"parent_id": "FLEX-WP-0012",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0012-T03",
"status": "done",
"title": "T03 - Implement the decided integration and prove it end to end",
"source_path": "workplans/FLEX-WP-0012-credential-grant-authorization-surface.md",
"uuid": "045ec743-4411-5b42-b9e8-df25b0c07984",
"parent_id": "FLEX-WP-0012",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0012-T04",
"status": "done",
"title": "T04 - Closure and handoff",
"source_path": "workplans/FLEX-WP-0012-credential-grant-authorization-surface.md",
"uuid": "0dcf2e1f-baa2-5fea-9e3e-9a73795af11f",
"parent_id": "FLEX-WP-0012",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0013",
"status": "finished",
"title": "Restore the seven-action tenant-engine policy pin",
"source_path": "workplans/FLEX-WP-0013-restore-seven-action-tenant-engine-pin.md",
"uuid": "6f22ded6-a69c-531b-bfa6-2f8d5c886979",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0013-T01",
"status": "done",
"title": "T01 - Re-pin the overlay and emergency manifests",
"source_path": "workplans/FLEX-WP-0013-restore-seven-action-tenant-engine-pin.md",
"uuid": "f84b0f20-f374-5d61-aa43-d1f886ea86c3",
"parent_id": "FLEX-WP-0013",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0013-T02",
"status": "done",
"title": "T02 - Apply and prove the seven actions live",
"source_path": "workplans/FLEX-WP-0013-restore-seven-action-tenant-engine-pin.md",
"uuid": "a77ff4bb-8927-5317-a0eb-903cfeef0de5",
"parent_id": "FLEX-WP-0013",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0013-T03",
"status": "done",
"title": "T03 - Handoff and close",
"source_path": "workplans/FLEX-WP-0013-restore-seven-action-tenant-engine-pin.md",
"uuid": "832ba42f-4247-58a9-bc1b-f99648c2c188",
"parent_id": "FLEX-WP-0013",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0014",
"status": "finished",
"title": "Authorize tenant-engine guardrail actions",
"source_path": "workplans/FLEX-WP-0014-tenant-guardrail-policy-actions.md",
"uuid": "7de17bd2-5e7c-5355-ba1d-40a051a67746",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0014-T01",
"status": "done",
"title": "T01 - Extend the policy package with the guardrail actions",
"source_path": "workplans/FLEX-WP-0014-tenant-guardrail-policy-actions.md",
"uuid": "34fb239a-7f06-5e96-9f10-a6bbb85bf4c3",
"parent_id": "FLEX-WP-0014",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0014-T02",
"status": "done",
"title": "T02 - Decide how the read/write split is used today",
"source_path": "workplans/FLEX-WP-0014-tenant-guardrail-policy-actions.md",
"uuid": "8ea87d5f-883a-5d63-89bb-33a3d0963472",
"parent_id": "FLEX-WP-0014",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0014-T03",
"status": "done",
"title": "T03 - Fixtures and verification",
"source_path": "workplans/FLEX-WP-0014-tenant-guardrail-policy-actions.md",
"uuid": "1029d2ce-bb37-530e-91ef-ded86f6f5be8",
"parent_id": "FLEX-WP-0014",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0014-T04",
"status": "done",
"title": "T04 - Closure and handoff",
"source_path": "workplans/FLEX-WP-0014-tenant-guardrail-policy-actions.md",
"uuid": "b2b44215-ef08-5c50-b466-190156a88ef3",
"parent_id": "FLEX-WP-0014",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0015",
"status": "finished",
"title": "Tenancy posture declaration and inbound caller authentication",
"source_path": "workplans/FLEX-WP-0015-tenancy-posture-conformance.md",
"uuid": "43fe348c-02b9-5d5d-af37-a2d80cfc6e1d",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0015-T01",
"status": "done",
"title": "Tasks",
"source_path": "workplans/FLEX-WP-0015-tenancy-posture-conformance.md",
"uuid": "ee587988-d29c-5dd8-9417-8af73f627817",
"parent_id": "FLEX-WP-0015",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0015-T02",
"status": "done",
"title": "Tasks",
"source_path": "workplans/FLEX-WP-0015-tenancy-posture-conformance.md",
"uuid": "7c906ab5-0b3f-5a73-8561-b29d94f4e634",
"parent_id": "FLEX-WP-0015",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0015-T03",
"status": "done",
"title": "Tasks",
"source_path": "workplans/FLEX-WP-0015-tenancy-posture-conformance.md",
"uuid": "4f885922-56c9-5d89-b7ab-e61c8d69d67a",
"parent_id": "FLEX-WP-0015",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0015-T04",
"status": "cancel",
"title": "Tasks",
"source_path": "workplans/FLEX-WP-0015-tenancy-posture-conformance.md",
"uuid": "1c05032a-bcae-5a4c-8f4a-c51b30a48807",
"parent_id": "FLEX-WP-0015",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0015-T05",
"status": "done",
"title": "Tasks",
"source_path": "workplans/FLEX-WP-0015-tenancy-posture-conformance.md",
"uuid": "702e55bf-b87a-547d-9a2d-bc2ccfee9341",
"parent_id": "FLEX-WP-0015",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0016",
"status": "finished",
"title": "In-cluster ops-warden policy pin so policy.enabled can flip",
"source_path": "workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md",
"uuid": "f29f159c-c79e-5c78-b1e8-569a5b63d231",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0016-T01",
"status": "done",
"title": "Tasks",
"source_path": "workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md",
"uuid": "b2f8052e-3686-593f-9359-dfd08d530a26",
"parent_id": "FLEX-WP-0016",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0016-T02",
"status": "done",
"title": "Tasks",
"source_path": "workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md",
"uuid": "aa65f534-7401-5231-ae82-ea6e3d09b40c",
"parent_id": "FLEX-WP-0016",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0016-T03",
"status": "done",
"title": "Tasks",
"source_path": "workplans/FLEX-WP-0016-ops-warden-incluster-policy-pin.md",
"uuid": "351f502f-f0cf-5a70-86da-10b1fbe39dae",
"parent_id": "FLEX-WP-0016",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0017",
Answer ops-warden and secrets-engine; open FLEX-WP-0021 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
2026-09-06 01:12:50 +02:00
"status": "finished",
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
"title": "Action-bound authorization and durable approval contract",
"source_path": "workplans/FLEX-WP-0017-action-bound-authorization-contract.md",
"uuid": "d75b7256-8b3d-5797-911c-96c3199b8baa",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0017-T01",
"status": "done",
"title": "Bind execute-time decisions to the evaluated request",
"source_path": "workplans/FLEX-WP-0017-action-bound-authorization-contract.md",
"uuid": "e7b47e1d-58e8-503c-be89-e8f2050215b1",
"parent_id": "FLEX-WP-0017",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0017-T02",
"status": "done",
"title": "Define the durable authorization object and semantics",
"source_path": "workplans/FLEX-WP-0017-action-bound-authorization-contract.md",
"uuid": "df7984fb-c31f-5b26-bf42-193e4c3cbb9f",
"parent_id": "FLEX-WP-0017",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0017-T03",
Answer ops-warden and secrets-engine; open FLEX-WP-0021 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
2026-09-06 01:12:50 +02:00
"status": "cancel",
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
"title": "Add durable storage and authenticated approval evidence",
"source_path": "workplans/FLEX-WP-0017-action-bound-authorization-contract.md",
"uuid": "82d39961-8140-5a7f-9bd8-5164dd1742e5",
"parent_id": "FLEX-WP-0017",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0017-T04",
"status": "done",
"title": "Propagate bindings through delegated evaluators",
"source_path": "workplans/FLEX-WP-0017-action-bound-authorization-contract.md",
"uuid": "d85089ee-ad8c-502b-ba1b-be4ad23aec46",
"parent_id": "FLEX-WP-0017",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0017-T05",
Answer ops-warden and secrets-engine; open FLEX-WP-0021 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
2026-09-06 01:12:50 +02:00
"status": "cancel",
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
"title": "Consumer handoff and live destructive-action proof",
"source_path": "workplans/FLEX-WP-0017-action-bound-authorization-contract.md",
"uuid": "8c3fc0a2-0855-5ac9-afa5-d03b8b1f0bf9",
"parent_id": "FLEX-WP-0017",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0018",
"status": "finished",
"title": "Inbound caller-auth and deployment documentation corrections",
"source_path": "workplans/FLEX-WP-0018-inbound-auth-corrections.md",
"uuid": "8f301c7c-e3e2-5bd0-a6f2-0cb92c1d782f",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0018-T01",
"status": "done",
"title": "Classify rejected TokenReview credentials as unauthenticated",
"source_path": "workplans/FLEX-WP-0018-inbound-auth-corrections.md",
"uuid": "4a85c91f-6f34-5224-99b0-23b8eaa3bf7b",
"parent_id": "FLEX-WP-0018",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0018-T02",
"status": "done",
"title": "Correct NetworkPolicy egress documentation",
"source_path": "workplans/FLEX-WP-0018-inbound-auth-corrections.md",
"uuid": "5613aeb1-ad09-50e5-9933-ced39593dc54",
"parent_id": "FLEX-WP-0018",
"extra": {}
},
Answer ops-warden and secrets-engine; open FLEX-WP-0021 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
2026-09-06 01:12:50 +02:00
{
"kind": "workplan",
"id": "FLEX-WP-0019",
"status": "finished",
"title": "Layer model v0.7 conformance: provenance, lifetimes, deadlines, and the decision contract",
"source_path": "workplans/FLEX-WP-0019-layer-model-conformance.md",
"uuid": "84b9dc5a-71f2-5c70-ace6-78242b13d0f1",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0019-T01",
"status": "done",
"title": "Assert the layer declaration mechanically",
"source_path": "workplans/FLEX-WP-0019-layer-model-conformance.md",
"uuid": "f72b1305-114e-5ba2-b84c-f6cc0b524178",
"parent_id": "FLEX-WP-0019",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0019-T02",
"status": "done",
"title": "Add the registry-snapshot digest to decision provenance",
"source_path": "workplans/FLEX-WP-0019-layer-model-conformance.md",
"uuid": "7a980074-8488-5ab1-9202-60878adb261d",
"parent_id": "FLEX-WP-0019",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0019-T03",
"status": "done",
"title": "Give every allow an explicit lifetime",
"source_path": "workplans/FLEX-WP-0019-layer-model-conformance.md",
"uuid": "9d9c0e7a-56e2-5c71-9110-cea973243c22",
"parent_id": "FLEX-WP-0019",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0019-T04",
"status": "done",
"title": "State revocation visibility deadlines per input class",
"source_path": "workplans/FLEX-WP-0019-layer-model-conformance.md",
"uuid": "d5917b24-2efb-503e-9a9d-837702cafc1c",
"parent_id": "FLEX-WP-0019",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0019-T05",
"status": "done",
"title": "Publish the decision-record schema as flex-auth's contract",
"source_path": "workplans/FLEX-WP-0019-layer-model-conformance.md",
"uuid": "f7f501d7-6862-5542-88f7-78b704524706",
"parent_id": "FLEX-WP-0019",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0019-T06",
"status": "done",
"title": "Publish the request digest as the replay test",
"source_path": "workplans/FLEX-WP-0019-layer-model-conformance.md",
"uuid": "bc109ee3-14b0-5603-a655-0d7376c2a41c",
"parent_id": "FLEX-WP-0019",
"extra": {}
},
{
"kind": "workplan",
"id": "FLEX-WP-0020",
"status": "proposed",
"title": "Repository identity migration from flex-auth to access-engine",
"source_path": "workplans/FLEX-WP-0020-repository-identity-migration.md",
"uuid": "99a661a8-b36c-5c1c-b78b-1e8930bcd0a9",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0020-T01",
"status": "todo",
"title": "1. Capture immutable cleanliness and identity baseline",
"source_path": "workplans/FLEX-WP-0020-repository-identity-migration.md",
"uuid": "bb989019-50a7-5273-ba09-b2df2e2602a4",
"parent_id": "FLEX-WP-0020",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0020-T02",
"status": "todo",
"title": "2. Prepare repository metadata and work-record frontmatter",
"source_path": "workplans/FLEX-WP-0020-repository-identity-migration.md",
"uuid": "102e9dc7-4724-5e80-84c4-092e6ecfbb2b",
"parent_id": "FLEX-WP-0020",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0020-T03",
"status": "todo",
"title": "3. Decide product and runtime naming separately",
"source_path": "workplans/FLEX-WP-0020-repository-identity-migration.md",
"uuid": "5095ddbc-b69c-5a52-b97f-08fca9b610c3",
"parent_id": "FLEX-WP-0020",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0020-T04",
"status": "todo",
"title": "4. Inventory consumers and create owned handoffs",
"source_path": "workplans/FLEX-WP-0020-repository-identity-migration.md",
"uuid": "9bb138e1-5edb-5714-8d89-3b1b7039a7ce",
"parent_id": "FLEX-WP-0020",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0020-T05",
"status": "todo",
"title": "5. Renew State Hub preflight and record approval",
"source_path": "workplans/FLEX-WP-0020-repository-identity-migration.md",
"uuid": "86fecbb6-b008-5354-8d70-0f4ba5077a58",
"parent_id": "FLEX-WP-0020",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0020-T06",
"status": "wait",
"title": "6. Execute the Forgejo repository rename",
"source_path": "workplans/FLEX-WP-0020-repository-identity-migration.md",
"uuid": "aa7ccd59-ddd3-5af0-a866-30e88552fc09",
"parent_id": "FLEX-WP-0020",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0020-T07",
"status": "wait",
"title": "7. Record the State Hub identity rebind",
"source_path": "workplans/FLEX-WP-0020-repository-identity-migration.md",
"uuid": "155041ed-8cba-5e5e-ac59-fc03ef6dd0ce",
"parent_id": "FLEX-WP-0020",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0020-T08",
"status": "wait",
"title": "8. Establish and register a fresh canonical clone",
"source_path": "workplans/FLEX-WP-0020-repository-identity-migration.md",
"uuid": "c8afe078-41cf-5d8c-84d1-a49e4b618d34",
"parent_id": "FLEX-WP-0020",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0020-T09",
"status": "wait",
"title": "9. Verify identity, history, routes, builds, and deployments",
"source_path": "workplans/FLEX-WP-0020-repository-identity-migration.md",
"uuid": "fdb50a96-f7fa-5d4a-9efa-231750dcb2f1",
"parent_id": "FLEX-WP-0020",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0020-T10",
"status": "wait",
"title": "10. Exercise rollback decision points",
"source_path": "workplans/FLEX-WP-0020-repository-identity-migration.md",
"uuid": "3dc49eb4-1f39-5250-87c9-716a9a97790d",
"parent_id": "FLEX-WP-0020",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0020-T11",
"status": "wait",
"title": "11. Soak, hand off residuals, and clean up the old checkout",
"source_path": "workplans/FLEX-WP-0020-repository-identity-migration.md",
"uuid": "46d8318b-d1fb-52e3-b632-52230ed1438f",
"parent_id": "FLEX-WP-0020",
"extra": {}
},
Accept ActionAuthorization deferral; fix the state-hub authority constant 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
2026-09-06 01:30:04 +02:00
{
"kind": "workplan",
"id": "FLEX-WP-0021",
Publish approval_binding_digest: a claim cannot name the request carrying it 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
2026-09-06 14:52:33 +02:00
"status": "active",
Accept ActionAuthorization deferral; fix the state-hub authority constant 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
2026-09-06 01:30:04 +02:00
"title": "secrets-engine consumer policy package and cluster-local pin",
"source_path": "workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md",
"uuid": "b01f655e-f71a-50ae-b110-178557f07c63",
"parent_id": null,
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0021-T01",
Publish approval_binding_digest: a claim cannot name the request carrying it 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
2026-09-06 14:52:33 +02:00
"status": "done",
Accept ActionAuthorization deferral; fix the state-hub authority constant 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
2026-09-06 01:30:04 +02:00
"title": "1. Obtain the real action vocabulary from secrets-engine",
"source_path": "workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md",
"uuid": "3c191808-6fe5-5a9b-9a68-a4ce4a672dbd",
"parent_id": "FLEX-WP-0021",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0021-T02",
Publish approval_binding_digest: a claim cannot name the request carrying it 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
2026-09-06 14:52:33 +02:00
"status": "done",
Accept ActionAuthorization deferral; fix the state-hub authority constant 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
2026-09-06 01:30:04 +02:00
"title": "2. Publish `secrets-engine.catalog-lane.lifecycle` v1",
"source_path": "workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md",
"uuid": "38770813-dfcc-5711-bba3-0db50d3af135",
"parent_id": "FLEX-WP-0021",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0021-T03",
Publish approval_binding_digest: a claim cannot name the request carrying it 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
2026-09-06 14:52:33 +02:00
"status": "progress",
Accept ActionAuthorization deferral; fix the state-hub authority constant 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
2026-09-06 01:30:04 +02:00
"title": "3. Confirm the digest join against a real decision record",
"source_path": "workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md",
"uuid": "8f7e5cdd-777e-5f54-9b92-c72b79f65672",
"parent_id": "FLEX-WP-0021",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0021-T04",
"status": "wait",
"title": "4. Stand up the `flex-auth-secrets-engine` pin",
"source_path": "workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md",
"uuid": "f4e8709a-65dd-5172-97ae-e7c3432afb22",
"parent_id": "FLEX-WP-0021",
"extra": {}
},
{
"kind": "task",
"id": "FLEX-WP-0021-T05",
"status": "wait",
"title": "5. Hand the pin coordinates back and close",
"source_path": "workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md",
"uuid": "f0828871-fd65-5d8c-adfd-28b13fedd2b0",
"parent_id": "FLEX-WP-0021",
"extra": {}
},
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
{
"kind": "decision",
"id": "FLEX-DEC-2026-001",
"status": "resolved",
"title": "Assent to GH-DEC-2026-001: Engine framing, access-engine rename, authoring/evaluation split",
"source_path": "decisions/decisions.md",
Review security layer model v0.4 (FLEX-DEC-2026-002), closing FLEX-IN-0002 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
2026-08-29 02:42:28 +02:00
"uuid": "c990e442-77c2-4556-a40b-61f65eded10b",
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
"parent_id": null,
"extra": {
"record": {
"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 \u2014 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 \u2014 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)",
Review security layer model v0.4 (FLEX-DEC-2026-002), closing FLEX-IN-0002 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
2026-08-29 02:42:28 +02:00
"decided_at": "2026-08-28T19:44:29.505314Z",
"state_hub_decision_id": "c990e442-77c2-4556-a40b-61f65eded10b"
}
}
},
{
"kind": "decision",
"id": "FLEX-DEC-2026-002",
"status": "resolved",
"title": "Review of security layer model v0.4: assent with findings, one rule contested",
"source_path": "decisions/decisions.md",
Align INTENT and SCOPE to security layer model v0.7; plan conformance work 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
2026-08-29 14:43:49 +02:00
"uuid": "2e96321d-c7bf-4127-9c30-f3def32e5bee",
Review security layer model v0.4 (FLEX-DEC-2026-002), closing FLEX-IN-0002 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
2026-08-29 02:42:28 +02:00
"parent_id": null,
"extra": {
"record": {
"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)",
Align INTENT and SCOPE to security layer model v0.7; plan conformance work 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
2026-08-29 14:43:49 +02:00
"decided_at": "2026-08-29T00:42:13.009799Z",
"state_hub_decision_id": "2e96321d-c7bf-4127-9c30-f3def32e5bee"
}
}
},
{
"kind": "decision",
"id": "FLEX-DEC-2026-003",
"status": "resolved",
"title": "Review of security layer model v0.6 and companion v0.1: assent, two answers, five findings",
"source_path": "decisions/decisions.md",
Answer ops-warden and secrets-engine; open FLEX-WP-0021 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
2026-09-06 01:12:50 +02:00
"uuid": "def6a31b-4cd7-4474-8cfa-339b0fc9fcc6",
Align INTENT and SCOPE to security layer model v0.7; plan conformance work 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
2026-08-29 14:43:49 +02:00
"parent_id": null,
"extra": {
"record": {
"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)",
Answer ops-warden and secrets-engine; open FLEX-WP-0021 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
2026-09-06 01:12:50 +02:00
"decided_at": "2026-08-29T08:19:41.832549Z",
"state_hub_decision_id": "def6a31b-4cd7-4474-8cfa-339b0fc9fcc6"
}
}
},
{
"kind": "decision",
"id": "FLEX-DEC-2026-004",
"status": "resolved",
"title": "Decision lifetime does not reach past issuance: answer to ops-warden WARDEN-WP-0034-T05",
"source_path": "decisions/decisions.md",
Accept ActionAuthorization deferral; fix the state-hub authority constant 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
2026-09-06 01:30:04 +02:00
"uuid": "f6bfb02a-bbf3-4488-acf9-0e1cb57ce19d",
Answer ops-warden and secrets-engine; open FLEX-WP-0021 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
2026-09-06 01:12:50 +02:00
"parent_id": null,
"extra": {
"record": {
"id": "FLEX-DEC-2026-004",
"kind": "decision",
"title": "Decision lifetime does not reach past issuance: answer to ops-warden WARDEN-WP-0034-T05",
"status": "resolved",
"origin": "cross-repo",
"origin_ref": "WARDEN-WP-0034-T05",
"owner": "flex-auth",
"affects": [
"flex-auth",
"ops-warden"
],
"requested_dispositions": [
"answer",
"decline"
],
"decided_by": "flex-auth (access-engine / PDP)",
"rationale": "Answered, not declined. A decision lifetime shorter than the SSH certificate TTL is meaningful, but only as an authority-to-issue window, never as an authority-to-use window over an already-issued certificate. flex-auth lifetime.expires_at bounds how long that one allow may be relied on to authorise a sign; it cannot bound an artifact ops-warden issued under it, and flex-auth does not claim it does. The downstream contract that consumes the shorter lifetime is the pre-sign gate itself: no replay of an allow past expires_at, and a fresh Check per sign. The lever that actually shortens effective access is the requested TTL as a policy input, which is already deployed as the ttl_out_of_bounds deny; ops-warden section 9.7.2 window through cert TTL is correctly stated and correctly owned by the PEP.",
"created": "2026-09-05T23:08:38.877787Z",
Accept ActionAuthorization deferral; fix the state-hub authority constant 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
2026-09-06 01:30:04 +02:00
"updated": "2026-09-06T00:00:00.000000Z",
"decided_at": "2026-09-06T00:00:00.000000Z",
"state_hub_decision_id": "f6bfb02a-bbf3-4488-acf9-0e1cb57ce19d"
Answer ops-warden and secrets-engine; open FLEX-WP-0021 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
2026-09-06 01:12:50 +02:00
}
}
},
{
"kind": "decision",
"id": "FLEX-DEC-2026-005",
"status": "resolved",
"title": "secrets-engine policy package is expected but unpublished; /v1/check has no estate-wide endpoint by design",
"source_path": "decisions/decisions.md",
Accept ActionAuthorization deferral; fix the state-hub authority constant 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
2026-09-06 01:30:04 +02:00
"uuid": "f318e4e2-6195-4db8-b8c0-c71eeecad766",
Answer ops-warden and secrets-engine; open FLEX-WP-0021 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
2026-09-06 01:12:50 +02:00
"parent_id": null,
"extra": {
"record": {
"id": "FLEX-DEC-2026-005",
"kind": "decision",
"title": "secrets-engine policy package is expected but unpublished; /v1/check has no estate-wide endpoint by design",
"status": "resolved",
"origin": "cross-repo",
"origin_ref": "secrets-engine SECRETS-WP-0009-T03",
"owner": "flex-auth",
"affects": [
"flex-auth",
"secrets-engine",
"approval-engine"
],
"requested_dispositions": [
"answer"
],
"decided_by": "flex-auth (access-engine / PDP)",
"rationale": "Two answers. (1) Yes, a real package is expected, and flex-auth authors it in this repo as it did for every other consumer; the reserved coordinate is secrets-engine.catalog-lane.lifecycle at version v1, and it does not exist yet. Until it is published and pinned, secrets-engine keeping SECRETS_ENGINE_AUTHORIZATION_POLICY_PACKAGE and _VERSION as required configuration with no fallback is the correct shape and flex-auth endorses it. (2) POST /v1/check is deployed, but there is no estate-wide PDP address and there is not meant to be one: each consumer gets its own cluster-local pin whose NetworkPolicy default-denies ingress except from that one approved workload. The 2026-09-06 probe finding no reachable PDP is the design working, not an outage. A reachable endpoint for secrets-engine is a per-consumer pin that follows its policy package.",
"created": "2026-09-05T23:08:51.144287Z",
Accept ActionAuthorization deferral; fix the state-hub authority constant 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
2026-09-06 01:30:04 +02:00
"updated": "2026-09-06T00:00:00.000000Z",
"decided_at": "2026-09-06T00:00:00.000000Z",
"state_hub_decision_id": "f318e4e2-6195-4db8-b8c0-c71eeecad766"
}
}
},
{
"kind": "decision",
"id": "FLEX-DEC-2026-006",
"status": "resolved",
"title": "ActionAuthorization deferral accepted; G3 is closed and does not argue for ratifying it",
"source_path": "decisions/decisions.md",
Publish approval_binding_digest: a claim cannot name the request carrying it 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
2026-09-06 14:52:33 +02:00
"uuid": "762e5d75-2377-4e1a-bcea-c57398ef636b",
Accept ActionAuthorization deferral; fix the state-hub authority constant 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
2026-09-06 01:30:04 +02:00
"parent_id": null,
"extra": {
"record": {
"id": "FLEX-DEC-2026-006",
"kind": "decision",
"title": "ActionAuthorization deferral accepted; G3 is closed and does not argue for ratifying it",
"status": "resolved",
"origin": "cross-repo",
"origin_ref": "APPROVAL-IN-0002 / GH-DEC-2026-003",
"owner": "flex-auth",
"affects": [
"flex-auth",
"approval-engine",
"gate-house",
"secrets-engine"
],
"requested_dispositions": [
"accept",
"contest"
],
"decided_by": "flex-auth (access-engine / PDP)",
"rationale": "Accepted, and flex-auth argues against its own proposal. The composed ActionAuthorization object was never ratified; the approval-claim plus DecisionEnvelope split lands each check on the layer that owns it and drops none. approval-engine asked whether the open G3 finding (DecisionEnvelope carries no lifetime) argues for ratifying the composed object now. It does not, because 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 revisit trigger is spent, and it resolved by adding a field rather than by composition, so the decision now stands alone and needs no bundle. Separately, the provenance.authority == state-hub constant is flex-auth defect: it came from examples/caring/action_authorization.json, which contradicted our own ownership section. Corrected at source, with the schema and contract doc marked deferred-not-withdrawn so no other consumer builds a validator against them.",
"created": "2026-09-05T23:29:20.156770Z",
Publish approval_binding_digest: a claim cannot name the request carrying it 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
2026-09-06 14:52:33 +02:00
"updated": "2026-09-05T23:29:20.156770Z",
"state_hub_decision_id": "762e5d75-2377-4e1a-bcea-c57398ef636b"
}
}
},
{
"kind": "decision",
"id": "FLEX-DEC-2026-007",
"status": "resolved",
"title": "A claim cannot name the request that carries it: publish approval_binding_digest",
"source_path": "decisions/decisions.md",
"uuid": null,
"parent_id": null,
"extra": {
"record": {
"id": "FLEX-DEC-2026-007",
"kind": "decision",
"title": "A claim cannot name the request that carries it: publish approval_binding_digest",
"status": "resolved",
"origin": "cross-repo",
"origin_ref": "secrets-engine T03 re-verification / GH-DEC-2026-008",
"owner": "flex-auth",
"affects": [
"flex-auth",
"secrets-engine",
"approval-engine",
"gate-house"
],
"requested_dispositions": [
"resolve"
],
"decided_by": "flex-auth (access-engine / PDP)",
"rationale": "secrets-engine found that an approval pdp_digest recorded at issue time can never equal the request_digest of a request that carries the claim inside its hashed context, because the claim is part of the context that is hashed. The circularity is structural, not a fixture defect, and it made GH-DEC-2026-008 unimplementable for exactly the dual-control case it was written for. flex-auth owns the canonical request digest, so the resolution is ours. Publishing binding.approval_binding_digest: the same digest computed with context.approval removed, present only when a claim was carried, stable across attaching the claim, and therefore nameable by a pdp_digest recorded at issue. Deliberately additive rather than a redefinition: request_digest keeps covering the claim and remains the replay identity, because two requests differing only in which approval was presented must not share a replay identity when one allows and the other denies dual_control_required. Tests assert the two functions disagree on a claim-bearing request and agree on a claim-free one.",
"created": "2026-09-06T12:52:06.960329Z",
"updated": "2026-09-06T12:52:06.960329Z"
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
}
}
},
{
"kind": "intake",
"id": "FLEX-IN-0001",
"status": "closed",
"title": "Assent requested: Engine framing, access-engine rename, and the authoring/evaluation split",
"source_path": "intakes/intakes.md",
Review security layer model v0.4 (FLEX-DEC-2026-002), closing FLEX-IN-0002 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
2026-08-29 02:42:28 +02:00
"uuid": "01a049eb-812c-7641-8e46-8dd63b12b2a8",
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
"parent_id": null,
"extra": {
"record": {
"id": "FLEX-IN-0001",
"kind": "intake",
"title": "Assent requested: Engine framing, access-engine rename, and the authoring/evaluation split",
"status": "closed",
"origin": "cross-repo",
"origin_ref": "gate-house GH-DEC-2026-001",
"priority": "high",
"owner": "flex-auth",
"requested_by": "gate-house",
"standard": "net-kingdom/canon/standards/security-layer-model_v0.1.md",
"description": "gate-house asks flex-auth to assent to three items ratified in GH-DEC-2026-001, following the estate precedent that a boundary is drawn on review by the other side rather than asserted \u2014 as flex-auth itself did to zone-engine. (1) flex-auth is Engine-layer and is NetKingdom\u2019s only policy decision point; the INTENT reframe is already applied (commit fe46122) and can be revised or reverted if wrong. (2) The ruled rename flex-auth -> access-engine, NOT yet authorized to execute: it is a separate governed migration touching FLEX-WP prefix ownership, State Hub identifiers, ops-warden routing tables, zone-engine boundary text, and secrets-engine integrations. auth-engine was rejected because key-cape owns authentication. (3) The split: flex-auth owns evaluation exclusively plus the policy-as-code mechanism; gate-house owns doctrine, invariants, authority ceilings, operating modes, and the authority context consumed as input claims; policy content stays with the protected system owner. This resolves the FLEX-WP-0017 overlap \u2014 gate-house designs the approval contract, flex-auth validates approvals at decision time. Assent, revision, or rejection all acceptable; the standard stays proposed until this is answered.",
"created": "2026-08-28T19:30:03.602578Z",
"updated": "2026-08-28T19:45:06.001794Z",
"notes": [
{
"content": "Answered by FLEX-DEC-2026-001 (decisions/decisions.md): assent to all three items, with one accepted flex-auth conformance debt (registry snapshot absent from DecisionProvenance) and two conditions on the rename migration.",
"author": "flex-auth",
"created": "2026-08-28T19:45:04.030513Z"
}
],
"closed_at": "2026-08-28T19:45:06.001794Z",
Review security layer model v0.4 (FLEX-DEC-2026-002), closing FLEX-IN-0002 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
2026-08-29 02:42:28 +02:00
"outcome": "assented \u2014 see FLEX-DEC-2026-001",
"state_hub_intake_id": "01a049eb-812c-7641-8e46-8dd63b12b2a8"
}
}
},
{
"kind": "intake",
"id": "FLEX-IN-0002",
"status": "closed",
"title": "Review requested: security layer model v0.3 (approval-engine, maturity-engine)",
"source_path": "intakes/intakes.md",
Align INTENT and SCOPE to security layer model v0.7; plan conformance work 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
2026-08-29 14:43:49 +02:00
"uuid": "01a04afa-307b-7e9e-b210-261badabcec7",
Review security layer model v0.4 (FLEX-DEC-2026-002), closing FLEX-IN-0002 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
2026-08-29 02:42:28 +02:00
"parent_id": null,
"extra": {
"record": {
"id": "FLEX-IN-0002",
"kind": "intake",
"title": "Review requested: security layer model v0.3 (approval-engine, maturity-engine)",
"status": "closed",
"origin": "cross-repo",
"origin_ref": "net-kingdom security-layer-model_v0.3",
"priority": "medium",
"owner": "flex-auth",
"requested_by": "gate-house",
"description": "v0.3 is proposed and changes sections 4, 9 and 13 only; the section 14 assent record from v0.2 stands. Two additions concern flex-auth. (1) Section 9.4 assigns the approval object to a new approval-engine \u2014 the gap FLEX-DEC-2026-001 raised. Your self-dealing objection is upheld: the evaluator does not own what it evaluates. access-engine consumes approvals as input claims under section 6.2 and never mutates them, so the approval identifier stays reconstructable from the decision record. Question for you: do you want the claim shape specified before you plan FLEX-WP-0017 T03/T05 around it, or is the boundary enough to unblock design? (2) Section 9.5 assigns graded progression to a new maturity-engine, carrying the guardrail that a maturity level must never gate a decision directly \u2014 if a level determines an outcome it reaches access-engine as an input claim or a versioned policy rule. That guardrail is section 6.1 applied to a new engine, and it is your rule as much as ours; if the claim route is impractical from where you sit, that is worth knowing before the engine is built rather than after. Assent, revision, or rejection acceptable.",
"created": "2026-08-28T20:40:00.263659Z",
"updated": "2026-08-29T00:42:14.888434Z",
"notes": [
{
"content": "Answered by FLEX-DEC-2026-002, reviewing v0.4 (which supersedes the v0.3 this intake asked about): assent with findings, section 9.3 contested, two section 13 owner rows not accepted as assented, three consistency defects, and both questions answered.",
"author": "flex-auth",
"created": "2026-08-29T00:42:14.005210Z"
}
],
"closed_at": "2026-08-29T00:42:14.888434Z",
Align INTENT and SCOPE to security layer model v0.7; plan conformance work 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
2026-08-29 14:43:49 +02:00
"outcome": "assented with findings \u2014 see FLEX-DEC-2026-002",
"state_hub_intake_id": "01a04afa-307b-7e9e-b210-261badabcec7"
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
}
}
}
],
"events": [
{
Review security layer model v0.4 (FLEX-DEC-2026-002), closing FLEX-IN-0002 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
2026-08-29 02:42:28 +02:00
"type": "repo.command.applied",
Answer ops-warden and secrets-engine; open FLEX-WP-0021 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
2026-09-06 01:12:50 +02:00
"command": "repo.work.create_decision",
"operation": "create",
Publish approval_binding_digest: a claim cannot name the request carrying it 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
2026-09-06 14:52:33 +02:00
"correlation_id": "e76636be-b773-46de-9bef-eb962c96cf2b",
Align INTENT and SCOPE to security layer model v0.7; plan conformance work 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
2026-08-29 14:43:49 +02:00
"kind": "decision",
Publish approval_binding_digest: a claim cannot name the request carrying it 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
2026-09-06 14:52:33 +02:00
"id": "FLEX-DEC-2026-007",
Answer ops-warden and secrets-engine; open FLEX-WP-0021 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
2026-09-06 01:12:50 +02:00
"git_sha": null,
Review security layer model v0.4 (FLEX-DEC-2026-002), closing FLEX-IN-0002 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
2026-08-29 02:42:28 +02:00
"files_touched": [
Align INTENT and SCOPE to security layer model v0.7; plan conformance work 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
2026-08-29 14:43:49 +02:00
"decisions/decisions.md"
Review security layer model v0.4 (FLEX-DEC-2026-002), closing FLEX-IN-0002 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
2026-08-29 02:42:28 +02:00
],
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
"source": "repo-manager",
Publish approval_binding_digest: a claim cannot name the request carrying it 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
2026-09-06 14:52:33 +02:00
"emitted_at": "2026-09-06T12:52:08.174961Z"
Assent to GH-DEC-2026-001 (FLEX-DEC-2026-001), closing FLEX-IN-0001 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
2026-08-28 21:47:06 +02:00
}
]
}