All three v0.4 findings landed in v0.5 (local outbox, machine-readable
declaration, §14 arithmetic). §9.6's load-bearing/attributive split and
§16's ruling on approval custody both improve on what audit-core raised.
Findings, all correcting audit-core's own contribution: (1) the local
outbox closes accidental omission, not the compromised-source case §9.6
opens with — a compromised emitter can decline the insert or drop the row
before drain; §16 rests a ruling on that conflation. (2) cadence is the
only control touching the residual and is a SHOULD, and rate-based
detection is weakest for the rare negative events §9.6 says matter most —
recommend positive reconciliation for load-bearing low-volume classes.
(3) §3.3's Evidence row states an availability/independence trade as a
property of evidence engines.
Adds layer.yaml in ops-warden's reference form, per §11.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WpeL68AWHqtqPQZEXY5kFe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4040362@bnt-lap001
Assistant-Session: 4fd0fd24-2ee8-4413-bd67-43bd79ca73f1
gate-house incorporated all of audit-core's AUDIT-IN-0001 corrections and
generalized the omission bound into §9.6 as estate-wide doctrine.
Findings: (1) §9.4's emission MUST is safe only if the outbox is local;
"or equivalent" admits a synchronous emit to audit-core inside the state
transaction, which would make an audit outage an inability to revoke —
recommend one sentence requiring the queue live in approval-engine's own
store. (2) §11's new who-must-declare rule is not mechanically checkable
despite §11 claiming it is; recommend a canonical frontmatter form.
(3) §14 says "seven of fifteen" and "remaining eight" but enumerates nine;
the catalog has 16 estate-authored rows.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WpeL68AWHqtqPQZEXY5kFe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4040362@bnt-lap001
Assistant-Session: 4fd0fd24-2ee8-4413-bd67-43bd79ca73f1
gate-house proposed (security layer model v0.3 §9.4) that audit-core own
the tamper-evident record of approvals while approval-engine owns the
operative state. Assented, with two corrections and one condition.
Correction 1: INTENT principle 6 overstated the delivered guarantee.
docs/integrity.md is authoritative — an in-database chain does not
withstand a database owner without the external chain-head attestation,
and even then it is not WORM. Principle 6 now points at that bound.
Correction 2: the chain proves alteration and truncation, not omission
at source. A suppressed revocation leaves the chain intact.
Condition: approval-engine must guarantee emission atomicity, so an
approval cannot change state without the event being durably queued in
the same transaction. Not a task audit-core can discharge for it.
Boundary: no approval-validity query will be exposed — that would be
deciding early under §6.1.
Also declares audit-core's layer (Engine, not a decision point), which
§11 requires and INTENT.md was missing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WpeL68AWHqtqPQZEXY5kFe
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 4040362@bnt-lap001
Assistant-Session: 4fd0fd24-2ee8-4413-bd67-43bd79ca73f1
Regenerated by fix-consistency; adds AUDIT-IN-0001.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2564823@bnt-lap001
Assistant-Session: 2a7ed827-4928-4b9f-8613-9135c9cadfe9
Updated by fix-consistency on 2026-08-25:
- update .custodian-brief.md for audit-core
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
These workplans exist only in the retired local hub. Their random pre-ADR-007
identifiers are refused by C-06 as stale references, so they cannot be
registered. Deriving from the canonical record id takes no identity from
anything: central does not hold them and the old ids die with the cache.
Records central already holds were deliberately left untouched.
Refs CUST-WP-0068-T06
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
Updated by fix-consistency on 2026-08-25:
- update .custodian-brief.md for audit-core
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
The remote row pointed at 127.0.0.1:18000, a reverse tunnel back to the
workstation. On railiance01 the State Hub runs in the cluster on that same
machine, so the request left the box and came back to reach a local service.
Refs CUST-WP-0067-T07
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
T08 fixes two defects in our own declaration. provider.R.available quoted a
30-day horizon audit-core does not solely control: at P1 the erasure horizon is
the instance maximum across co-residents, so a co-resident declaring longer
extends what a sender's records remain recoverable for, silently. Decision 4.5.4
names this for tiers; it applies to a provider quoting a number too, and the
provider block now says so. And user-engine, the only consumer, was notified
under Decision 6.1 -- what we declared, that E4 and R4 are unreachable here, and
that the retention number is a floor rather than a ceiling.
T03 writes docs/erasure-and-audit.md: the fact/payload split, why shreddability
is not retrofittable onto a chain committing to cleartext, and why the retained
hash is a confirmation oracle over low-entropy audit records. The framework half
was already resolved as Decision 4.5.3, so what remains is our own position. The
legal basis for retaining audit facts is routed to risk-nexus, open and visible.
T06 closes the review loop with net-kingdom: five findings adopted, declaration
validates clean, and the E line will go stale on an upgrade that Decision 6.1
deliberately does not require anyone to announce.
T07 enumerates the seven dependencies on the accept path and specifies five
recovery scenarios with integrity as a pass condition. It settled one thing: V2
is not reachable from P1 as built, since platform-pg runs instances 1 and
Decision 4.6.1 makes V the minimum across synchronous providers. V1 is the
ceiling here, not the next step. The exercise needs a live window.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The framework moved from draft-5 to draft-8 while this workplan ran. No finding
was reversed, but three things changed underneath it: R moved to 2 once
rapp-postgres declared the window, a sixth axis V (availability) appeared, and
the implemented-versus-evidenced distinction became a schema field.
T03 reduces: the confirmation-oracle finding landed as Decision 4.5.3 and
question 11 is marked framework-resolved, so no amendment remains -- only our
own position document. The legal question routes to risk-nexus rather than
the-custodian, per §19.11 and policy-nexus INTENT.
T06 reduces to confirmation: all five findings were adopted and the two stale
status lines it was going to flag are already fixed.
T07 is new. V1 needs critical dependencies enumerated, restart recovery
exercised and recovery time measured. The 2026-08-16 reboot walk observed ~40s
of unreadiness but is not an exercise and does not enumerate the dependency set.
T08 is new and covers two defects in our own declaration. provider.R.available
quotes a 30-day horizon we do not solely control -- at P1 the horizon is the
instance maximum across co-residents. And under Decision 6.1, user-engine was
never told what we declared, which makes the declaration drift rather than a
completed change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Written against draft-7, which landed after the task was drafted and moved the
target. Decision 5.4 fixes the location at tenancy.yaml in the repo root rather
than docs/, and fixes the schema: current, target, reviewed, gap,
placement_exceptions, service_class, per-path detail, provider block.
Declares I1 A2 E1 P1 R1. E is quoted at 1 although T04 put the E2 mechanism on
both paths, because §13.2 states a passing CI run is not E2 evidence -- the
artifact is adversarial, compares separate tenant contexts and carries a review
date. Our cross-tenant tests are mechanical, so under §13.1 the level is not
claimable until T05. The mechanism is recorded in paths.E and the reason in
gap.E. Claiming E2 off unit tests would be the overclaim §6 prohibits, and
refusing that reasoning is what found the read-path defect.
R stays at 1: R2 needs backupRetentionDays in rapp-postgres's consumer file,
requested in T02 and not ours to declare.
Two additions draft-7 forced. A credentials gap under Decision 9.2 -- our own
finding, adopted as a rule, and it binds us: ingest credentials are static
long-lived bearer tokens, declared as a stated gap rather than a silent
exclusion. And a provides block under Decision 5.5, declaring what a sender can
reach through this service: E2 now, E3 pending ADR-0003, E4 and R4 unreachable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
_read gated on may_read alone and never called permits_tenant, so any reader
credential could read every tenant through /v1/events, /v1/events/<id>,
/v1/dead-letters and /v1/secret-findings. Deployment bounded the exposure --
the only production sender holds may_read: false -- but the boundary was not in
the code, which is the difference between E2 and E1 on the tenancy posture
enforcement ladder.
Two rules, because the surfaces divide cleanly. Event reads are filtered to the
tenants the credential may act for. Surfaces with no tenant key to filter on --
stats, integrity, dead letters, secret findings -- require full tenant scope and
are refused rather than served instance-wide facts to a scoped reader.
A cross-tenant fetch returns 404 rather than 403. A distinguishable forbidden
would confirm that an event id exists and which tenant holds it, turning the
read surface into an existence oracle. Correlation lookup is filtered rather
than refused, since a correlation id legitimately spans tenants.
_readable_by fails closed: a record with no tenant is readable only at full
scope. Three existing tests read instance-wide surfaces with a scoped
credential, which this makes a 403; bound_app now carries an unrestricted
operator identity and those reads use it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three additions after review:
Retention position is now conditional on a date. Routing multi-year custody to
data.archive is mechanically right and practically unfunded, so the position
carries a 2026-12-31 review and names P2 as the fallback if no provision is
procured. Also folds in R1 -> R2, which needs only an explicit
backupRetentionDays: 30 and a published erasure horizon.
The erasure exemption names its legal dependency. Declining to build erasure
rests on audit evidence being exempt under legal obligation or legitimate
interest; that is a legal conclusion nobody in the estate is recorded as having
reached, and T03 routes it rather than absorbing it.
T04 now runs before T01 so the published vector reads E2 on both paths from its
first commit. T02 still runs first and corrects the E2 guess by message, since
that guess is live in canon and wrong today.
Framework finding 1 amended to declare per path, quote the minimum. E3 target
carries 2027-03-31.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assesses audit-core against NetKingdom Tenancy Posture v0.1 following the
rapp-postgres review request. The guessed vector I2 A3 E2 P1 R1 is too high on
three axes; the honest reading is I1 A2 E1 P1 R1.
The E correction is a real defect rather than a bookkeeping one: the read path
in ingestion._read gates on may_read alone and never calls permits_tenant, so a
reader credential can read any tenant. Bounded today by may_read: false on the
production sender and by default-deny networking, but not enforced in code.
Also records the retention position (ceiling stays 365, multi-year belongs to
data.archive not the WAL window) and the question-11 answer: crypto-shredding
does not reach R4 here, because the chain commits to a SHA-256 of the cleartext
record, which survives key destruction as a confirmation oracle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
