AUDIT-LOG — Access + Action Audit Trail¶
Status: live · Version: 1.0.0 · Camada: 8 · Rule 24 (canonical) — Audit Chain inviolable
Purpose¶
Every meaningful action that touches data or decisions emits an audit event. The chain is append-only, tamper-evident, and queryable. Used for compliance, incident response, and operational debugging.
What gets logged¶
Always¶
- Capsule create / accept / reject
- Skill invocation (id, capsule, agent, outcome)
- Resource lock acquire / release
- Memory write (any tier)
- ADR creation / acceptance
- Phase 3 gate fail
- Constitutional violation
- Veto exercise (security-orch, qa-orch)
Tier 2 data¶
- Read (with
purposeannotation) - Write
- Export
Tier 3 data¶
- Read (always; with
purpose+lawful_basisref) - Write
- Display (even masked)
- Export
- Deletion (NEVER delete the deletion event itself)
Event format¶
event_id: evt_a1b2c3d4
timestamp: '2026-05-23T14:32:18.123Z'
event_type: data.read # taxonomy: data.*, agent.*, capsule.*, system.*
actor:
type: agent # agent | human | system
id: backend-python-specialist
capsule_id: cap_xyz789
trace_id: 4f8c2e9a-...
subject: # what was acted upon
resource_id: oauth_refresh_families/12345
data_classification: 3
purpose: 'process refresh request'
lawful_basis_ref: TOS-2026-04 §4.2
result: success # success | failure | denied
chain_link:
prev_event_id: evt_prev_x9y8z
signature: sha256:abcdef... # tamper-evident
Tamper-evidence¶
Each event includes:
- chain_link.prev_event_id — previous event in chain
- chain_link.signature — HMAC over (event_payload + prev_signature) using rotating key
Verification: replay the chain; if any signature breaks, integrity is compromised.
Storage¶
- v1.0: append-only file
_framework/audit/YYYY-MM/audit.jsonl - v1.5: dedicated audit DB with WORM (write-once-read-many) semantics
- v2.0: external compliance audit service
Retention¶
| Tier | Minimum retention |
|---|---|
| Tier 0 events | 90 days |
| Tier 1 | 1 year |
| Tier 2 | 3 years |
| Tier 3 | 7 years (or jurisdiction maximum) |
Retention is per-jurisdiction; COMPLIANCE-REGISTER overrides defaults where required.
Query patterns¶
"Who touched this user's data in the last 30 days?"¶
SELECT * FROM audit_events
WHERE subject.resource_id LIKE 'users/12345/%'
AND timestamp > now() - interval '30 days'
ORDER BY timestamp DESC
"All Phase 3 gate failures by agent in last 7 days"¶
SELECT actor.id, count(*)
FROM audit_events
WHERE event_type = 'phase3.gate_failed'
AND timestamp > now() - interval '7 days'
GROUP BY actor.id
Failure modes¶
| Mode | Mitigation |
|---|---|
| Audit storage down | agent BLOCKS (don't proceed without audit; Rule 24) |
| Chain integrity broken | INCIDENT SEV1; forensic investigation |
| Log fills disk | rotation + offsite copy; alert at 75% |
| PII inadvertently in audit | re-hashing pass; identify source agent |
Cross-references¶
- PRIVACY-CONSTITUTION Principle 7 (sibling) — audit inviolability
- DATA-CLASSIFICATION (sibling) — what tier triggers what
- AGENT-PERMISSIONS (sibling) — every access also audited
- DATA-BREACH-RESPONSE (sibling) — audit is the forensic record