# 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)