Schemas and storage

All documents generated and validated within the DPO2U ecosystem follow rigid JSON schemas to enable programmatic validation by Audit Agents and AI models.

LGPD context

The Brazilian Lei Geral de Proteção de Dados (LGPD — Law 13.709/2018) establishes 11 principles that govern personal data processing. The dpo2u/lgpd/v1 schema is designed to map directly to these regulatory requirements:

#	Principle	LGPD Article	Schema mapping
1	Finalidade (Purpose)	Art. 6, I	data_categories — declares what data is collected and why
2	Adequação (Adequacy)	Art. 6, II	data_categories — processing must match declared purpose
3	Necessidade (Necessity)	Art. 6, III	data_categories — minimum data for stated purpose
4	Livre acesso (Free access)	Art. 6, IV	dpo_contact — channel for data subject requests
5	Qualidade dos dados (Data quality)	Art. 6, V	last_review — forces periodic accuracy reviews
6	Transparência (Transparency)	Art. 6, VI	privacy_notice document (CID on IPFS)
7	Segurança (Security)	Art. 6, VII	On-chain Attestation — cryptographic proof of security controls
8	Prevenção (Prevention)	Art. 6, VIII	dpia document — Data Protection Impact Assessment
9	Não discriminação (Non-discrimination)	Art. 6, IX	Auditor Agent validates fairness in processing rules
10	Responsabilização (Accountability)	Art. 6, X	Immutable CID + on-chain Attestation = verifiable accountability
11	Consentimento (Consent)	Art. 7, I	consent_mechanism — explicit opt-in mechanism

Schema design principles

The schema fields were not chosen arbitrarily — each maps to a specific legal requirement:

• retention_days — LGPD Art. 15 requires data to be deleted when it is no longer necessary. This field enforces a declared retention period that the Auditor Agent validates against the stated purpose
• consent_mechanism — LGPD Art. 7 requires a legal basis for processing. opt-in-explicito satisfies the strictest basis (explicit consent)
• dpo_contact — LGPD Art. 41 requires organizations to designate a Data Protection Officer. This field ensures the DPO is reachable
• last_review — LGPD Art. 6, V requires data quality. Periodic reviews (this field) ensure policies are not stale

The dpo2u/lgpd/v1 schema

The default structure emitted by the LGPD Kit Generator aligns with the v1 version of the protocol schema. This consistency allows any agent in the network to know exactly where to find consent definitions and data retention periods.

Structure

{
  "schema_version": "dpo2u/lgpd/v1",
  "company_id": "cnpj:XX.XXX.XXX/XXXX-XX",
  "generated_at": "2026-03-01T14:30:00Z",
  "policy": {
    "retention_days": 365,
    "data_categories": ["identificacao", "financeiro"],
    "consent_mechanism": "opt-in-explicito",
    "dpo_contact": "dpo@empresa.com.br",
    "last_review": "2026-02-15"
  },
  "documents": [
    { "type": "privacy_notice", "cid": null },
    { "type": "dpia", "cid": null }
  ]
}

Mandatory fields

For a policy to be considered valid and accepted by an Auditor Agent, it must contain all four mandatory fields: retention_days, consent_mechanism, dpo_contact, and last_review. Submissions missing any of these fields are rejected before scoring begins.

Field reference

Field	Type	Required	Description
schema_version	string	Yes	Must be "dpo2u/lgpd/v1"
company_id	string	Yes	Hashed company identifier (CNPJ format)
generated_at	string	Yes	ISO 8601 timestamp of kit generation
policy.retention_days	number	Yes	Maximum data retention period in days
policy.data_categories	string[]	Yes	Categories of personal data processed
policy.consent_mechanism	string	Yes	Legal basis for processing (e.g., opt-in-explicito)
policy.dpo_contact	string	Yes	Email address of the Data Protection Officer
policy.last_review	string	Yes	Date of last policy review (YYYY-MM-DD)
documents[].type	string	Yes	Document type (privacy_notice, dpia, etc.)
documents[].cid	string	No	IPFS CID after upload (null before storage)

Storage flow

The schema progresses through a pipeline from generation to on-chain attestation:

Step by step

1. Generation — the Expert Agent generates the kit locally or remotely, producing policy.json conforming to the dpo2u/lgpd/v1 schema
2. IPFS upload — the payload is sent to the Lighthouse Network (IPFS). The Lighthouse SDK (@lighthouse-web3/sdk) pins the file and returns a unique CID
3. CID injection — the CID is injected back into the schema's documents[].cid fields, providing immutable links to the underlying documents
4. Validation — the Auditor Agent retrieves the schema and CIDs, validates all mandatory fields, and scores compliance (0-100)
5. Attestation — the score and CID are wrapped in a zk-SNARK proof and submitted to ComplianceRegistry.compact on the Midnight blockchain

Validation rules

The Auditor Agent applies the following validation logic before scoring:

Rule	Check	Failure behavior
Schema version	Must equal "dpo2u/lgpd/v1"	Rejected — unknown schema
Mandatory fields	All 4 required fields present and non-null	Rejected — incomplete submission
Retention period	retention_days > 0 and ≤ 3650 (10 years)	Warning — flagged for review
Consent mechanism	Must be a recognized value (opt-in-explicito, contrato, legitimo-interesse)	Warning — non-standard basis
DPO contact	Must be a valid email format	Rejected — unreachable DPO
Last review	Must be within the last 365 days	Warning — potentially stale policy
Document CIDs	If present, must be valid IPFS CIDs	Warning — unverifiable documents

Only after passing all mandatory checks does the Auditor proceed to scoring. Warnings do not block scoring but are included in the Attestation metadata.

What's next

• Architecture — where schemas fit in the system layers
• Agents and contracts — how the Auditor Agent processes schemas
• About DPO2U — the full protocol lifecycle