Compliance Jobs.

1Problem Statement

Compliance programs fail at audit time because evidence is assembled retrospectively. Someone exports logs, reconciles them by hand, and asserts that nothing was altered — an assertion the logs themselves cannot support.

Three specific gaps recur. Audit trails have no tamper-evidence, so there is no cryptographic reason to believe a record was not edited. Retention is a policy document rather than an enforced behaviour, so data outlives its lawful basis. And erasure requests are handled in one system while copies persist in vector stores, archives, and workflow histories.

This service makes the evidence continuous and mechanical. Every module maps to numbered requirements — Merkle publishing, Ed25519 signing, retention and legal hold, GDPR cascade, annual attestations, and NAIC adverse-action population — and runs on a schedule rather than on request.

2Architecture

app/main.py is the entrypoint. A lifespan context manager calls ensure_dirs() and db.init(), pre-warms the signing key, then launches four asyncio tasks that are cancelled cleanly on shutdown.

Scheduler Behaviour

• Merkle loop — fires at minute :05 and always targets the closed hour, so a root is never published over a still-open window.
• Retention loop — archives to gzipped JSONL before deleting, and honours active legal holds that pause deletion for named scopes.
• Annual loop — _annual_due() implements "keep at least one report covering last year", firing on never_run, stale_>365d, unparseable_last_run, or no_run_for_target_year.
• NAIC listener — scans governance and security audit databases for adverse-action event types and generates one artifact per event, with INSERT OR IGNORE idempotency keyed on event_id.
• Audit databases are opened read-only, trying immutable=1 first and falling back to mode=ro, so read-only mounts work correctly.
• Schema migrations are additive and idempotent, applied by introspecting PRAGMA table_info at startup.

3Requirements

Requirement identifiers follow the REQ-RCA series referenced throughout the module docstrings.

4Interfaces

A REST surface over the four job domains, plus signing and dashboard endpoints. Every scheduled job also has a run-now trigger for operators.

5Integration Points

The service reads from upstream audit stores and writes evidence outward.

• Governance and runtime-security audit databases — mounted read-only and scanned for events; the default AUDIT_BUS_DBS names a governance audit.db and a security audit_bus.sqlite.
• Qdrant — targeted by the DSR erasure cascade and covered by a retention class.
• Compliance portal — the human-facing surface for the evidence this service produces.
• External anchoring — MERKLE_PUBLISH_URL optionally POSTs each root to a third party, so chain integrity can be corroborated off-system.
• Postgres and n8n execution history appear as declared retention targets in policy.

6Repository

Application modules are organised one per compliance domain, with policy separated from orchestration.

View source on GitHub

7Implementation Notes

Deployment constraints and one documentation discrepancy worth flagging.

• The README describes Postgres, but the code is SQLite. config.py exposes SQLITE_PATH with no Postgres DSN and db.py is pure sqlite3. Treat SQLite as the actual storage engine.
• Docker runs with --workers 1, which is required — the schedulers are in-process asyncio tasks and additional workers would duplicate every job.
• Audit database mounts are expected read-only; where the security bus is read-only, retention archives but reports cannot_delete=true rather than failing.
• Retention sweeps only the audit_events/forensic_events tables of the mounted audit databases. Merkle roots are held in separate write-once files (chmod 0o444, never overwritten), so a retention sweep cannot sever chain continuity.
• Signing keys are generated on first run into SIGNING_KEY_DIR. There is no external KMS integration.
• NAIC deduplication depends on a non-empty event_id on the source event.
• The seven-year retention horizon is set in whole years via AUDIT_RETENTION_YEARS and EVIDENCE_RETENTION_YEARS, both defaulting to 7, so it can be shortened per deployment without a code change.