diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md index 6c94ec5..dba4e44 100644 --- a/WORK-RECORDS.md +++ b/WORK-RECORDS.md @@ -11,7 +11,7 @@ | workplan | GH-WP-0001 | active | — | workplans/GH-WP-0001-foundation.md | | task | GH-WP-0001-T01 | done | — | workplans/GH-WP-0001-foundation.md | | task | GH-WP-0001-T02 | done | — | workplans/GH-WP-0001-foundation.md | -| task | GH-WP-0001-T03 | done | — | workplans/GH-WP-0001-foundation.md | +| task | GH-WP-0001-T03 | progress | — | workplans/GH-WP-0001-foundation.md | | task | GH-WP-0001-T04 | todo | — | workplans/GH-WP-0001-foundation.md | | task | GH-WP-0001-T05 | todo | — | workplans/GH-WP-0001-foundation.md | | task | GH-WP-0001-T06 | todo | — | workplans/GH-WP-0001-foundation.md | diff --git a/intakes/intakes.md b/intakes/intakes.md deleted file mode 100644 index 4aef306..0000000 --- a/intakes/intakes.md +++ /dev/null @@ -1,113 +0,0 @@ -# Intake records - -## GH-IN-0001 — Emission atomicity for approval evidence — condition of audit-core's §9.4 assent - -```yaml -id: GH-IN-0001 -kind: intake -title: Emission atomicity for approval evidence — condition of audit-core's §9.4 assent -status: open -origin: cross-repo -origin_ref: audit-core AUDIT-IN-0001 (assent-with-conditions) -priority: high -owner: gate-house -requested_by: audit-core -lane: red -description: 'audit-core assented to AUDIT-IN-0001 (security layer model v0.3 §9.4) - on condition that approval-engine guarantee emission atomicity. This intake raises - that condition as work, and asks gate-house to promote it to a GH-WP workplan before - approval-engine is built. Filed under §12: a finding that doctrine rests on an unsatisfiable - property is a success of the conformance loop, not an objection to the split. - - - THE GAP. §9.4 assigns audit-core the tamper-evident record of approvals and cites - audit-core INTENT principle 6 — manifests proving a record set was not changed, - OMITTED, or truncated — as what authenticated approval entries need forensically. - The omission half of that claim is not deliverable. A hash chain proves that accepted - records were not altered or truncated. It proves nothing about an event that was - never emitted. Against a compromised or buggy sender no append-only archive can, - and audit-core does not claim to. - - - WHY IT MATTERS FOR APPROVALS SPECIFICALLY. This is not a corner case here. A suppressed - REVOCATION is precisely the event an attacker wants missing, and it leaves the chain - perfectly intact — `verify` returns intact, the attestation matches, and the forensic - record shows an approval that was never revoked. The evidence half looks sound and - is not. Every other §9.4 event class degrades gracefully under omission; revocation - fails dangerously. - - - WHERE THE FIX BELONGS. With the emitter, not the archive. Completeness at the boundary - is approval-engine''s property. audit-core will report what it received and will - not imply that what it received is everything that happened. This cannot be discharged - by audit-core on approval-engine''s behalf, which is why it is raised here rather - than tracked as audit-core work. - - - PROPOSED WORKPLAN — promote verbatim if it fits. - - - Title: Emission atomicity for approval evidence - - Lane: red. Blocks: treating the §9.4 evidence half as load-bearing. - - - T01 — Record the doctrine finding. Amend §9.4 so it does not rest on principle 6''s - omission claim. §9.4 currently implies the audit fabric supplies completeness; it - supplies integrity. State that the evidence half is complete only insofar as the - emitter guarantees emission, and name approval-engine as the owner of that guarantee. - audit-core has already corrected principle 6 on its side to point at the docs/integrity.md - bound. - - - T02 — Specify the emission contract for approval-engine. A transactional outbox - or equivalent: an approval MUST NOT be issued, consumed, superseded, or revoked - without the corresponding audit event being durably queued in the same transaction - that mutates the object. No best-effort post-commit emission, no fire-and-forget - client. Cover retry, duplicate, and audit-core-unavailable semantics — audit-core - dedupes on event id and a replay does not fork the chain, so at-least-once delivery - into the outbox is the correct target, not exactly-once over the wire. - - - T03 — Decide the revocation failure mode explicitly, and record it. If the outbox - cannot durably queue, does revocation fail closed (refuse to revoke) or proceed - with a known evidence gap? Both are defensible; the undecided version is not. Fail-closed - makes an audit dependency into an availability risk on the revocation path; proceed-with-gap - needs a detectable marker so the gap is visible rather than silent. Note this is - a narrower coupling than §9.4 rules out — §9.4 forbids routing decision-time approval - READS through the audit fabric, which this does not do. - - - T04 — Give the gap a detection surface. Whatever T03 decides, an unemitted or stuck-in-outbox - approval event should be observable — an outbox depth or age metric, a reconciliation - between approval-engine''s object count and audit-core''s event count per class, - or both. Today nothing would surface it. audit-core INTENT principle 10 already - says dropped, delayed, blocked, or degraded audit streams are themselves audit and - operations events; this is the approval-side half of that. - - - T05 — Conformance check. §11 is mechanically checkable by design; add a check that - a repository catalogued as an evidence source under §9.4 declares its emission guarantee, - so the next engine to emit into audit-core does not reintroduce this gap silently. - - - Acceptance: §9.4 no longer claims omission-proofing from the audit fabric; approval-engine''s - contract names the atomicity requirement before implementation; the revocation failure - mode is a recorded decision rather than an implementation accident; and an unemitted - approval event is detectable by someone. - - - NOT IN SCOPE, to keep the boundary clean. The operative approval state stays approval-engine''s. - audit-core is not asking for a validity query, an in-path read, or any change to - who owns the decision. audit-core''s own side — registering approval-engine as a - distinct source, the four event classes, retention, secret_policy, and the negative - test that no approval-validity surface exists — is audit-core''s work and will be - planned there. - - - Revision or rejection welcome. If gate-house concludes the omission gap is acceptable - for approvals, say so and audit-core will record the evidence half as integrity-only - rather than continue to raise it.' -created: '2026-08-28T20:50:02.381791Z' -updated: '2026-08-28T20:50:02.381791Z' -```