DATA
SERVICE CONTRACT · VIEW: GOV
Axiom
Example
Constraints
MUST: Cite specific regulation or standard for data governance claims MUST: Distinguish between data controller and data processor obligations MUST NOT: Present anonymization as absolute — cite re-identification risks
COVERAGE: 255/255
SPEC
Domain Declaration
DATA = PRIVACY_STANDARD × CANONIC
= Structure(privacy) × (C1, C2, Temporal, Relational, C5)
= owned data/privacy vertical
Lattice Formula
DATA = C1 ∩ C2 ∩ Temporal ∩ Relational ∩ C5
= PATENT (#57)
Data/Privacy typically lacks structural standard because:
- C1: Privacy policies must be stated
- C2: Consent and processing must be documented
- Temporal: Retention periods, deletion timelines
- Relational: Jurisdiction determines applicable law
- C5: Regulators enforce (DPAs, FTC)
- No universal data structure standard (varies by domain)
Axioms
1. Data Subject Rights
Individuals MUST be able to access, correct, delete, and port their personal data.
Example: A user requests deletion of their account. The system must: identify all personal data, delete from active systems, remove from backups within retention period, and confirm deletion to the user within 30 days.
2. Lawful Basis
Personal data processing MUST have a documented lawful basis.
Example: Collecting email addresses for marketing requires: consent (opt-in checkbox), record of consent (timestamp, IP, text shown), and mechanism to withdraw consent (unsubscribe link).
3. Purpose Limitation
Personal data MUST be collected for specified purposes and not processed incompatibly.
Example: Data collected for order fulfillment (shipping address) cannot be used for targeted advertising without separate consent. Each purpose requires its own lawful basis.
4. Data Minimization
Only personal data necessary for the specified purpose MUST be collected.
Example: A newsletter signup should collect email address only. Requesting phone number, address, and date of birth violates minimization unless each is necessary for the stated purpose.
5. Cross-Border Transfer
Personal data transferred across jurisdictions MUST have appropriate safeguards.
Example: Transferring EU personal data to US requires: Standard Contractual Clauses, transfer impact assessment, and supplementary measures. The transfer mechanism must be documented and maintained.
Subdomains
| Subdomain | Regulation | Formula | Jurisdiction |
|---|---|---|---|
| European Union | GDPR | 5 governance checks | EU/EEA |
| California | CCPA/CPRA | 5 governance checks | California |
| Brazil | LGPD | 5 governance checks | Brazil |
| Canada | PIPEDA | 5 governance checks | Canada |
| Virginia | VCDPA | 5 governance checks | Virginia |
| Colorado | CPA | 5 governance checks | Colorado |
Pattern: All privacy laws (PATENT #57)
Regulatory Mapping
| Framework | Lattice | Key Requirements |
|---|---|---|
| GDPR | 5 governance checks | Consent, rights, DPO, breach notification |
| CCPA/CPRA | 5 governance checks | Opt-out, deletion, disclosure, CPPA enforcement |
| LGPD | 5 governance checks | Consent, DPO, ANPD oversight |
| PIPEDA | 5 governance checks | Consent, access, OPC complaints |
| Children (COPPA) | 5 governance checks | Parental consent, FTC enforcement |
| Health (HIPAA) | 5 governance checks | See /MEDICINE/ domain |
Example: GDPR Compliance Vertical
DECLARE(GDPR) = GDPR_REGULATION × CANONIC
Where:
GDPR provides Requirements:
- Lawful basis (Art. 6)
- Data subject rights (Art. 15-22)
- Data protection principles (Art. 5)
- Accountability (Art. 24)
CANONIC provides Governance:
- C1: Privacy policy, ROPA
- C2: Consent records, DPIA
- Temporal: Retention schedules, breach timelines
- Relational: Jurisdiction, transfer mechanisms
- C5: DPO, supervisory authority
Result:
GDPR = PATENT (#57)
Compliance Lifecycle:
Map — Data inventory
Assess — DPIA completed
Implement — Controls deployed
Document — ROPA maintained
Enforce — DPO oversight
Example: Data Subject Request Handling
DECLARE(DSR) = DATA_RIGHTS × CANONIC
Where:
Data Rights Framework:
- Access (Art. 15)
- Rectification (Art. 16)
- Erasure (Art. 17)
- Portability (Art. 20)
CANONIC provides Governance:
- C1: Request received, scope defined
- C2: Identity verification, data located
- Temporal: Response deadline (30 days)
- Relational: Jurisdiction, exceptions
- C5: Fulfillment, confirmation
Result:
DSR = PATENT (#57)
Request Lifecycle:
Receive — Request logged
Verify — Identity confirmed
Scope — Data identified
Fulfill — Action completed
Confirm — Response sent
Data Processing Records
| Record Type | Lattice | Purpose |
|---|---|---|
| Processing Activity | (#26) | ROPA entry |
| Consent Record | (#22) | Lawful basis proof |
| DPIA | (#23) | Risk assessment |
| Transfer Mechanism | BUSINESS | Cross-border safeguard |
| Breach Record | BUSINESS | Incident documentation |
| DSR Log | BUSINESS | Request tracking |
Validators
| Validator | Checks | Example Failure |
|---|---|---|
| C1 | Privacy policy exists | No cookie consent notice |
| C2 | Consent records maintained | Missing opt-in timestamp |
| Temporal | Retention limits enforced | Data kept beyond period |
| Relational | Jurisdiction identified | No transfer mechanism |
| C5 | DPO appointed (if required) | Missing breach notification |
Application
To create a CANONIC data/privacy vertical:
- Identify applicable regulations (GDPR, CCPA, etc.)
- Create scope with CANON.md inheriting /DATA/
- Define privacy principles as axioms
- Document processing activities (ROPA)
- Establish retention schedules (temporal limits)
- Map data flows (jurisdictional boundaries)
- Implement subject rights (access, deletion)
- Appoint oversight (DPO if required)
Result: Owned data/privacy vertical with regulatory compliance.
LEARNING
ROADMAP
VOCAB
| Term | Definition |
|---|---|
| AWS | Governed term in this scope vocabulary. |
| CCPA | Governed term in this scope vocabulary. |
| CPRA | Governed term in this scope vocabulary. |
| CSV | Governed term in this scope vocabulary. |
| DAMA | Governed term in this scope vocabulary. |
| DATA | Governed term in this scope vocabulary. |
| DCAT | Governed term in this scope vocabulary. |
| DPIA | Governed term in this scope vocabulary. |
| DPO | Governed term in this scope vocabulary. |
| EU | Governed term in this scope vocabulary. |
| FAIR | Governed term in this scope vocabulary. |
| FHIR | Governed term in this scope vocabulary. |
| FIX | Governed term in this scope vocabulary. |
| FLSA | Governed term in this scope vocabulary. |
| FRCP | Governed term in this scope vocabulary. |
| GDPR | Governed term in this scope vocabulary. |
| HIPAA | Governed term in this scope vocabulary. |
| IRS | Governed term in this scope vocabulary. |
| ISO | Governed term in this scope vocabulary. |
| JSON | Governed term in this scope vocabulary. |
| MDM | Governed term in this scope vocabulary. |
| MISMO | Governed term in this scope vocabulary. |
| NIST | Governed term in this scope vocabulary. |
| PI | Governed term in this scope vocabulary. |
| PROV | Governed term in this scope vocabulary. |
| RFC | Governed term in this scope vocabulary. |
| SP | Governed term in this scope vocabulary. |
| US | Governed term in this scope vocabulary. |
| VII | Governed term in this scope vocabulary. |
| ZIP | Governed term in this scope vocabulary. |
INHERITANCE CHAIN
INDUSTRIES
INDUSTRY is the variable. SERVICE = PRIMITIVE(s) + INDUSTRY. Each vertical defines INTEL, CHAT, COIN.
MUST: Every INDUSTRY wires INTEL + CHAT + COIN MUST: Standards mapped to governance dimensions MUST: LANGUAGE cascades from MAGIC — no per-industry DESIGN.md MUST NOT: Create INDUSTRY without SERVICE proof
MAGIC
INTEL. CHAT. COIN. — Three primitives. One governed economy.
MUST: CANON.md in every scope
MUST: Services compose primitives — never duplicate
MUST: Primitive structure is fixed — industry is the only variable
MUST: Primitives compose into services — never duplicate
MUST: Services connect through SHOP.md and VAULT.md projection files
MUST: SHOP.md = public projection file (filesystem-discoverable, UPPERCASE per LANGUAGE)
MUST: VAULT.md = private projection file (filesystem-discoverable, auth-gated, UPPERCASE per LANGUAGE)
MUST: Instance = service projected through user governance context
MUST: Instance directories live at USER scope ({USER}/{PLURAL}/), not nested in SERVICES/
MUST: Service directories (SERVICES/{SINGULAR}/) define schemas — instances hold content
MUST: Every .md compiles to .json with the same name (direct mapping)
MUST: CANON.md = axiom + universal constraints only (no service names, no paths, no implementation)
MUST: README.md = how to run the CANON only
MUST: {SCOPE}.md = SPEC — the interface (purpose, routes, projections, ecosystem)
MUST NOT: Hardcode service names in CANON constraints (law speaks universals)
MUST: Inheritance resolves upward — scopes compose by directories
MUST: Tier algebra is canonical — DESIGN.md is the single source (COMPLIANCE tier algebra)
MUST NOT: Expose dimension internals to users or developers
MUST NOT: Hardcode outside governed contracts
MUST: Nonprofits get enterprise for free
MUST: ORG is the container; USER is the repo (`github.com/{org}/{user}`; duplicates across orgs allowed)
MUST: MARKET/ SALES/ GTM/ exist (META self-closure; one primitive each)
MUST: Each META sub-scope maps exactly one primitive (INTEL, CHAT, COIN)
MUST NOT: Add META business knowledge outside MAGIC/ scope
MUST NOT: Remove META sub-scope without replacing its primitive coverage
MUST: `{SCOPE}.md` is the scope contract surface; it MUST NOT be treated as a generic filename placeholder
MUST: LEARNING.md is the terminal — governance evidence, patterns, epoch rotation
MUST: LEARNING/ is the IDF directory — machine-generated individual data files
MUST: LEARNING.md rotates at epoch boundaries — frozen epochs archive as LEARNING-{EPOCH}.md at scope root
MUST: LEARNING.md is always the current epoch — active, append-only
MUST: Epoch boundary = EVOLUTION signal in LEARNING.md (named, dated, sourced)
MUST NOT: Delete archived LEARNING epochs — append-only history
MUST: MAGIC defines the triad interface directly:
MUST: COMPLIANCE/ + GALAXY/ + SURFACE/
MUST NOT: Define conflicting tier algebra in downstream scopes; downstream must inherit this contract
FOUNDATION
SPEC = {SCOPE}. The LANGUAGE. The v0 discovery.
MUST: LANGUAGE defines all governance primitives MUST: Every scope inherits from FOUNDATION MUST: Triad (CANON.md + VOCAB.md + README.md) in every scope MUST NOT: Define terms outside VOCAB.md MUST NOT: Hardcode outside the kernel SHOULD: Vocabulary closure — every term resolves to a definition