coulomb/audit-core
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

AUDIT-WP-0009-T09 — re-price approval-engine registration low → high
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details

Browse source 
glas-harness reports approval-engine production startup now requires audit
delivery, putting sender registration on the deployment critical path. The
task's note read the dependency backwards: audit-core is not waiting for a
producer to emit, the producer is waiting for a sender identity.

T03 is promoted with it. §9.4 makes approval evidence load-bearing and there
is nowhere to record that until evidence_kind exists; registering ahead of T03
would admit a load-bearing source into a system that would silently treat it
as attributive, which is the defect §9.6 names.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0185wifnLzCxjEY2MT1XbK7L

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 713962@bnt-lap001
Assistant-Session: 2718d99d-d3ff-478f-83a2-3a30f01a02fc
This commit is contained in:
tegwick 2026-09-06 20:36:02 +02:00
parent 948e8a3e8f
commit e2620312a0
1 changed files with 23 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

25
workplans/AUDIT-WP-0009-evidence-role-conformance.md
View file

@ -182,7 +182,7 @@ is worth asserting in `tests/`.
```task ```task
id: AUDIT-WP-0009-T09 id: AUDIT-WP-0009-T09
status: todo status: todo
priority: low priority: high
state_hub_task_id: "fd4a4ac3-e525-57c1-9179-e0fcd0226913" state_hub_task_id: "fd4a4ac3-e525-57c1-9179-e0fcd0226913"
``` ```
Register `approval-engine` as a distinct source under §9.4 and `AUDIT-IN-0001`: Register `approval-engine` as a distinct source under §9.4 and `AUDIT-IN-0001`:
@ -190,7 +190,28 @@ sender registration, the four event classes (issuance, use, supersession,
revocation), tenancy mapping, retention profile, `secret_policy`, and revocation), tenancy mapping, retention profile, `secret_policy`, and
`evidence_kind: load-bearing` from T03. Onboarded under INTENT principle 4 — `evidence_kind: load-bearing` from T03. Onboarded under INTENT principle 4 —
declared ownership, retention, access, export and evidence policy, not merely declared ownership, retention, access, export and evidence policy, not merely
events arriving. Not blocking: `approval-engine` is not yet emitting. events arriving.
**Re-priced low → high, 2026-09-06.** `glas-harness` reports (message
`85c68e66`) that `approval-engine` production startup now *requires* audit
delivery, putting this on the deployment critical path. The old note — "not
blocking: `approval-engine` is not yet emitting" — read the dependency
backwards: audit-core is not waiting for a producer, the producer is waiting
for a sender identity. Corrected.
What this does not change: T09 still depends on **T03**, because §9.4 makes
approval evidence load-bearing and there is nowhere to record that until
`evidence_kind` exists. Registering the sender ahead of T03 would admit a
load-bearing source into a system that would silently treat it as attributive
— the precise defect §9.6 names. T03 is therefore promoted with it. Cadence
and reconciliation (T04/T06) remain open gates on the *detection* half and are
not prerequisites for admission; they bound what may be claimed of the stream
once it flows, and `approval-engine` should be told so rather than discovering
it later.
Token provisioning goes by the approved custody path
(`approval-engine/approval-engine-audit`, key `audit-token`) via `warden
route`; no sender token passes through Git, State Hub, or a workplan.
```task ```task
id: AUDIT-WP-0009-T10 id: AUDIT-WP-0009-T10