PRIVACY-CONSTITUTION — 10 Inviolable Privacy Principles¶

Status: live · Version: 1.0.0 · Authority: Camada 8 (Privacy stack) absolute baseline · Reviewed: 2026-05-23 Distinct from docs/explanation/security-constitution.md (security = protecting the system; privacy = protecting subjects of data).

These 10 principles override convenience, deadline, or cost. Violation HALTs the offending action and escalates to security-orch.

Principle 1 — Lawful Basis Required¶

Every collection, processing, or transfer of personal data requires a documented lawful basis (consent / contract / legitimate interest / legal obligation / vital interests / public task). No basis = no data.

Principle 2 — Minimization¶

Collect the minimum data needed for the specific declared purpose. "Might be useful later" is not a purpose. Every field collected must trace to a documented need.

Principle 3 — Purpose Limitation¶

Data collected for purpose A cannot be reused for purpose B without a fresh lawful basis. "Already in the database" is not permission.

Principle 4 — Boundary Awareness (Rule 22 echo)¶

Personal data NEVER leaves the DPA-covered boundary. This includes: - No PII in LLM context that lands on third-party infra without DPA coverage - No PII in logs that ship to non-DPA observability backends - No PII in marketplace skill output (skills run inside our boundary; their outputs must be sanitized before any external call)

Principle 5 — Tiering is Absolute (Rule 23 echo)¶

The 4-tier classification (Public / Internal / Confidential / Restricted) is the basis of every access decision. Misclassification is the root cause of most privacy incidents.

Principle 6 — Right to Withdraw / Erase¶

Every data subject can revoke consent OR request deletion. The system MUST execute deletion within the timeline set by jurisdiction (LGPD: 15 days; GDPR: 30 days). Deletion = cryptographic erasure (key shredded) or physical removal.

Principle 7 — Audit Chain Inviolable (Rule 24 echo)¶

Every access to Confidential or Restricted data emits an audit event with: who/agent_id, what/data_classification, when/timestamp, why/lawful basis ref, where/destination. Tamper-evident; never edited.

Principle 8 — Synthetic Where Possible¶

Development / testing / training NEVER uses real personal data when synthetic data can serve the purpose. _framework/SYNTHETIC-DATA.md (when written) is the policy; synthetic-first is the default.

Principle 9 — Default Deny on Cross-System¶

When a new agent / pipeline / integration is created, its default permission on personal data is none. Permissions are granted explicitly (Camada 8 AGENT-PERMISSIONS) per least-privilege principle.

Principle 10 — Privacy by Design at Phase 1 (Rule 21 echo)¶

Privacy considerations enter at Phase 1 (planning), not bolted on at Phase 5 (review). Every PRD MUST address: what personal data this feature touches, what's the lawful basis, what's the retention, what's the deletion path.

Enforcement¶

Mechanism	Where it fires
Phase 1 gate	PRD acceptance: privacy section present + lawful basis declared
Phase 3 gate	Automated check: agent permissions match data tier requested
Phase 5 gate	REVIEW template: privacy checklist signed by security-orch
Runtime	Audit log emits on every Confidential/Restricted touch
Off-cycle	Quarterly compliance review (CAMADA 8 COMPLIANCE-REGISTER)

Violations¶

A violation is never an opinion call. If a principle is breached, the action halts and an INCIDENT (SEV1) opens automatically. The escalation chain: 1. Auditor-haiku flags the breach 2. security-orch acknowledges within 5 min (SLA) 3. POSTMORTEM published within 48h (Rule 9) 4. Subjects notified per jurisdiction's breach-notification timeline

What this document is NOT¶

Not a GDPR/LGPD textbook — it's our project's binding minimum
Not a substitute for the COMPLIANCE-REGISTER (jurisdiction-by-jurisdiction details land there)
Not negotiable per-project: principles 1–10 hold across all PROJECT_PROFILEs

Cross-references¶

SECURITY-CONSTITUTION (sibling, but security-focused)
CONSTRAINTS §"Compliance"
DATA-CLASSIFICATION (when implemented) — Tier definitions
AGENT-PERMISSIONS (when implemented) — per-agent allow-list
DATA-BREACH-RESPONSE (when implemented) — runbook on violation