Skip to content

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 purpose annotation)
  • Write
  • Export

Tier 3 data

  • Read (always; with purpose + lawful_basis ref)
  • 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