Reliable multi-tenant auto setup audit capability
tegwick
58a106aa4d
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> |
||
|---|---|---|
| .claude/rules | ||
| .forgejo/workflows | ||
| audit_core | ||
| data/capability | ||
| deploy | ||
| docs | ||
| evidence | ||
| registry | ||
| scripts | ||
| spec | ||
| tests | ||
| workplans | ||
| .custodian-brief.md | ||
| .dockerignore | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| Containerfile | ||
| INTENT.md | ||
| LICENSE | ||
| Makefile | ||
| pyproject.toml | ||
| README.md | ||
| SCOPE.md | ||
| tenancy.yaml | ||
| WORK-RECORDS.md | ||
Reliable multi-tenant auto setup audit capability
Production on railiance01 (AUDIT-WP-0005): PostgreSQL custody, digest-pinned
image, operator procedures in
docs/operator-runbook.md. Manifests live in
deploy/.
Backend contract
The pluggable backend interface, event schema (audit-core.event.v1alpha1),
retention policy, and migration path from the mock file backend are documented
in docs/audit-backend-contract.md.
Development Mock Backend
The first implementation is intentionally tiny: a replaceable audit interface with a mock file backend.
By default it writes JSONL audit events to:
/tmp/audit-core/audit-YYYYMMDDTHH.jsonl
Files older than 7 days are removed when the backend writes or when cleanup is run explicitly. This backend is for local integration and bootstrap wiring. It is not durable audit custody.
Example:
python3 -m audit_core emit \
--source openbao \
--action openbao.authenticated_readiness_proof \
--resource openbao/openbao-0 \
--outcome success \
--detail file_audit_visible=true \
--detail backend=mock-file
Cleanup:
python3 -m audit_core cleanup
Make targets:
make test
make mock-audit-smoke
make mock-audit-cleanup
Environment:
AUDIT_CORE_MOCK_DIR: override the output directory.AUDIT_CORE_MOCK_RETENTION_DAYS: override the default 7-day cleanup window.