atelier/domains/compliance/first-principles.md

Compliance — First Principles

Framework-agnostic per D-024. These principles derive from core Security (a subset of C1 Correctness), Observability, and Reversibility. They apply across regulations — NIST CSF, SOC 2, GDPR, CCPA, HIPAA, PCI-DSS, ISO 27001 — without prescribing any regulation-specific implementation. Regulation names appear here only as examples of what the principles support; the principles themselves are engineering rules, not legal controls.

1. The Principles

P1. Audit Logs are Append-Only

Audit records are immutable once written. Deletion or mutation of an audit record is itself an auditable incident — the tampering is the signal, not just the underlying event. An audit log that can be edited is not an audit log; it is a draft. Append-only is enforced structurally (write-once storage, immutable buckets, hash-chained records), not by policy alone. This is the compliance angle on domains/observability/logging.md: structured logs that cannot be rewritten are the substrate of accountability.

P2. Every Significant Action is Logged

The set of auditable actions is defined a priori, in code, before the action ships — not retrofitted after an incident. Authentication changes, authorization decisions, data access, configuration changes, policy changes, and deletions are all significant. "We forgot to log it" is a violation, not an excuse. The auditable-action catalog is itself versioned and reviewed. A significant action with no log line is a C7 (Observability) defect and a C1 (Correctness) defect: the system's behavior is invisible, and accountability is impossible.

P3. Retention is Policy, Not Storage

Data lifetime is declared and enforced as policy, not left to the storage layer's defaults. Deletion at end-of-life is a feature, not a failure. Retention rules live as code (lifecycle rules, scheduled deletion jobs, tiered storage transitions), they are reviewed, and they are auditable. "We kept it because the bucket was cheap" is a violation; "we deleted it because the policy said to" is correct. Retention is distinct from backup: a backup is a recovery mechanism, a retention rule is a deletion mechanism. Keeping them conflated produces data that survives both the deletion policy and the disaster — which is the opposite of compliance. Cross domains/data/migrations.md for the schema-lifecycle discipline.

P4. Policy is Code

Compliance policy is expressed in versioned, reviewable, testable code (OPA / Rego, AWS Cedar, HashiCorp Sentinel, Kyverno) — not in spreadsheets, prose documents, or tribal knowledge. Policy in a spreadsheet is untestable, unreviewable, and undeployable; it is a wishlist, not a control. Policy-as-code inherits the disciplines of domains/infrastructure-as-code/P1 Declarative Intent: declarative intent, version control, review before merge, plan before apply. A compliance rule that is not executable is a rule that cannot be enforced, which is a rule that does not exist.

P5. Policy is Evaluated as a Gate

Policy violations block before the action, not after the audit. Enforcement happens at admission time (kubernetes admission), at pipeline time (CI/CD gates), and at provisioning time (IaC plan gates) — before the non-compliant state is realized. Detecting a violation after it ships is detection, not enforcement. A policy that is "logged but not blocked" is a postcard, not a gate. This is the compliance angle on C5 (Reversibility): a blocked action is reversible by construction; a shipped violation requires remediation, which is more expensive than prevention.

P6. Evidence is Collected Continuously

Evidence of compliance — logs, configs, scans, attestations, policy decisions, access reviews — is gathered as a byproduct of operation, not assembled manually at audit time. The audit-time scramble is the anti-pattern: it is expensive, it is incomplete, and it produces evidence that is reconstructed rather than recorded. Continuous evidence collection means the audit packet is a query over already-collected artifacts, not a forensic reconstruction. This is the compliance angle on domains/observability/tracing.md for distributed evidence and domains/observability/metrics.md for posture signals.

P7. Identity is Attributable

Every logged action traces to an authenticated, non-shared principal. Shared accounts, generic service identities, and "admin" as an actor are violations: an action with no attributable human or workload is an action with no accountability. Identity is recorded in the audit record at the time of the action, not resolved after the fact. This is the compliance angle on domains/security/authorization.md and domains/kubernetes/rbac.md: the audit subject must be the principal that acted, not a role that many can assume.

P8. Subject Access is Honored

Data-subject rights — access, export, deletion, correction — are operations with defined contracts and audit trails, not ad-hoc tickets. The system can answer "what do we have on this subject," "export it in a portable form," and "delete it and prove the deletion" as first-class operations. These are not features bolted on at the end; they are contracts the data layer implements from the start. A subject-access request that requires a forensics team is a correctness defect: the system does not know what it holds. Cross domains/data/schema-design.md for the data shapes that make subject access computable.

P9. Secrets and Sensitive Data are Redacted in Audit

Audit logs themselves must not leak secrets, credentials, PII, or other sensitive data. Redaction is structural — applied at the logging boundary, before the record is written — not opportunistic scrubbing after the fact. A secret that appears in an audit log is a C1 (Correctness) violation (the log is now a secret store) and a security violation (domains/security/secrets.md). The redaction policy is itself auditable: which fields are redacted, by what rule, in which log stream. Once a secret is in an append-only log, the remediation is expensive — rotate the secret and rewrite the log's access scope — so redaction-at-source is the only sound position.

P10. Compliance Posture is Observable

The system reports its own compliance state: drift from policy, open violations, retention status, evidence freshness, policy-evaluation counts. Silent non-compliance is the bug. A compliance posture metric is a first-class signal (domains/observability/metrics.md), alertable, and dashboarded. "We didn't know we were non-compliant" is not a defense; it is a C7 (Observability) defect. The posture is queryable at any time, not only at audit time. This is the compliance angle on domains/infrastructure-as-code/P3 State is Truth: the compliance state is a versioned, queryable truth, not a vibe.

2. Core Principle Trace

Each compliance P-rule derives from one or more core C-rules (C1–C8). The matrix extension lands in P4 of the v0.3 plan; the traces below are authoritative.

P-rule	Core	Why
P1 Audit Logs are Append-Only	C1, C5	Correctness of the record; reversibility of tamper detection
P2 Every Significant Action is Logged	C7, C1	Observability of behavior; correctness of a-priori audit scope
P3 Retention is Policy, Not Storage	C5, C8	Reversibility of data lifetime; economy of storage as policy
P4 Policy is Code	C6, C2	Composability of versioned policy; clarity of executable intent
P5 Policy is Evaluated as a Gate	C1, C5	Correctness of pre-action enforcement; reversibility of blocked actions
P6 Evidence is Collected Continuously	C7, C3	Observability of compliance state; simplicity of audit-by-query
P7 Identity is Attributable	C1, C7	Correctness of accountability (security subset); observability of who acted
P8 Subject Access is Honored	C1, C5	Correctness of the data-subject contract; reversibility of deletion
P9 Secrets and Sensitive Data are Redacted in Audit	C1, C3	Correctness of not leaking (security subset); simplicity of structural redaction
P10 Compliance Posture is Observable	C7, C1	Observability of posture; correctness of self-reported state

3. What Violates These Principles

Violation	Principle Breached
An audit log stored on a mutable filesystem with no write-once protection	P1 Audit Logs are Append-Only
A DELETE on an audit record to "clean up a typo"	P1 Audit Logs are Append-Only
An auth change with no audit log line	P2 Every Significant Action is Logged
"We'll add logging after we ship the feature"	P2 Every Significant Action is Logged
Data kept indefinitely because "the bucket is cheap"	P3 Retention is Policy, Not Storage
A retention rule in a spreadsheet, not in code	P4 Policy is Code
A policy that logs violations but does not block the action	P5 Policy is Evaluated as a Gate
Evidence assembled by hand the week before an audit	P6 Evidence is Collected Continuously
A shared admin account as the audit actor	P7 Identity is Attributable
A subject-access request that requires a forensics team	P8 Subject Access is Honored
A secret visible in an audit log entry	P9 Secrets and Sensitive Data are Redacted in Audit
No dashboard for compliance posture between audits	P10 Compliance Posture is Observable

4. Relationship to Other Domains

Compliance is the accountability layer that crosses domains/security/ (it audits security actions), domains/observability/ (audit logs are structured logging; posture is metrics; evidence is traces), domains/data/ (retention and subject access are data-layer contracts), and domains/infrastructure-as-code/ (policy-as-code parallels declarative IaC; compliance state parallels state-as-truth). Cross- links are one-directional (per D-026 extended):

• domains/security/authorization.md ← P7 (attributable identity)
• domains/security/secrets.md ← P9 (redaction)
• domains/security/supply-chain.md ← P6 (signed attestations as evidence)
• domains/observability/logging.md ← P1, P2 (audit logs = structured logging)
• domains/observability/metrics.md ← P10 (compliance posture metrics)
• domains/observability/tracing.md ← P6 (evidence from distributed traces)
• domains/data/schema-design.md ← P3, P8 (retention and subject-access shapes)
• domains/data/migrations.md ← P3 (retention migration discipline)
• domains/infrastructure-as-code/P1 Declarative Intent ← P4 (policy-as-code)
• domains/infrastructure-as-code/P3 State is Truth ← P10 (compliance posture truth)
• domains/kubernetes/rbac.md ← P7 (audit subject identity)
• domains/devops/ci-cd.md ← P5 (policy as a pipeline gate)
• domains/devops/first-principles.md ← P4 (policy as configuration-as-code)