tegwick
0a1d1d942a
informed-decision filed three rulings before writing any architecture, with candidate answers, their costs, the self-dealing objection argued against itself, and a list of what it was not asking for. That order is what section 17 exists to produce, and KEY-WP-0013-T02 is blocked today, so it is answered now rather than queued. R1 — PEP-shaped, confirmed as proposed, not an Engine. It holds no state another layer reads at runtime for a verdict, which is the test. Its layer stays its own to declare; this settles its shape, which is what was blocking. It should build to v0.8's obligation 3 rather than v0.7's and inherit GH-DEC-2026-010's attribution gap knowingly rather than describe its validation as complete. R2 — yes, and no second catalog row. PEP and PIP are shapes a repository has; the catalog records layers it occupies. Obligation 5 forbids a PIP republishing the PDP's decision, which is a prohibition on republishing a decision, not on holding two shapes. Three limits carry the permission: the claim carries presentation and nothing else, it must never be an input to the decision it presents for, and its evidence copy reaches audit-core independently of the emitter. The last is the one that matters here, because the actor and the source are the same component. R3 — candidate (b). The binding digest is authoritative for what the request is; view_hash only for what was shown; a disagreement between them is a finding against the presenting surface, never a fact about the request. (a) is refused doctrinally rather than on the cost given: merging the two makes one repository the authority on what another layer computes over a request, which is GH-DEC-2026-008's objection to translation. (c) is refused because nesting the binding digest inside view_hash reproduces the hash cycle that made GH-DEC-2026-008 unimplementable — we paid for that lesson once this quarter. The two link by co-reference instead: the presentation record names the binding identifier and never recomputes the other layer's digest. The residual is not closed and the ruling says so, as they asked. A compromised surface can present X and attest Y. Attestation covers accident and later tampering, never a compromised source — the same disposition approval-engine's equivalent takes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012viPor8WJNCbV64ipwewrm Assistant: claude-code Assistant-Model: opus Assistant-Process: 1754332@bnt-lap001 Assistant-Session: 9c8ac536-ff5e-46a3-8ab1-a548bde25fc0
165 lines
8.2 KiB
Markdown
165 lines
8.2 KiB
Markdown
# 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: closed
|
|
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-29T00:55:21.377495Z'
|
|
notes:
|
|
- content: 'Promoted to GH-WP-0002 (approval evidence integrity), six tasks. The five-task
|
|
draft was adopted close to verbatim: T01 done in v0.4/v0.5, T02 in progress, T03-T05
|
|
as drafted. T06 added for the consumption ordering contract raised by flex-auth
|
|
in the same round. The omission gap is NOT accepted for approvals: v0.5 §9.6 now
|
|
distinguishes load-bearing from attributive evidence, approvals are load-bearing,
|
|
so emission atomicity is required and §9.4 additionally requires the outbox to
|
|
be local.'
|
|
author: gate-house
|
|
created: '2026-08-29T00:55:21.038809Z'
|
|
closed_at: '2026-08-29T00:55:21.377495Z'
|
|
outcome: promoted
|
|
state_hub_intake_id: "01a04b04-dd82-73a4-a8bf-9aeba5ef575f"
|
|
```
|
|
|
|
## GH-IN-0002 — Claim envelope on the PEP consumption path — which artifact is step 1 of GH-DEC-2026-003
|
|
|
|
```yaml
|
|
id: GH-IN-0002
|
|
kind: intake
|
|
title: Claim envelope on the PEP consumption path — which artifact is step 1 of GH-DEC-2026-003
|
|
status: closed
|
|
origin: cross-repo
|
|
origin_ref: approval-engine APPROVAL-IN-0002 (decision request)
|
|
priority: high
|
|
owner: gate-house
|
|
requested_by: approval-engine
|
|
lane: red
|
|
description: 'approval-engine asks gate-house to confirm which artifact satisfies
|
|
step 1 of the GH-DEC-2026-003 consumption sequence. secrets-engine''s PEP validator
|
|
(validate_action_authorization) expects a flex-auth ActionAuthorization envelope
|
|
but fetches GET /v1/approvals/{id}/claim, which serves approval-engine''s approval-claim.
|
|
Two different objects on one path.
|
|
|
|
|
|
GH-DEC-2026-003 already names step 1 by endpoint and by field — ''GET /v1/approvals/{id}/claim
|
|
-> valid_now (a fact, not permission)''. valid_now is an approval-claim field; ActionAuthorization
|
|
has no such field and appears nowhere in gate-house doctrine. It originates in flex-auth
|
|
docs/action-bound-authorization-contract.md as a proposed shape for durable approval
|
|
storage that the same document assigns to approval-engine; it was never ratified.
|
|
|
|
|
|
Secondary finding: the secrets-engine validator hard-requires provenance.authority
|
|
== ''state-hub'' (AUTHORITY constant, src/secrets_engine/authorization.py), while
|
|
flex-auth''s own contract holds that State Hub decision records are not the runtime
|
|
approval authority.
|
|
|
|
|
|
Requested disposition is a confirmation, not a redesign. Resolved as GH-DEC-2026-005.'
|
|
created: '2026-09-05T23:28:11.977565Z'
|
|
updated: '2026-09-05T23:28:11.977565Z'
|
|
state_hub_intake_id: "01a08762-ab47-7163-8eeb-92c3cb909db3"
|
|
```
|