Schemas and storage

All documents generated and validated within the DPO2U ecosystem follow rigid JSON schemas so that audit logic can be reproduced programmatically rather than inferred from prose.

LGPD context

The Brazilian Lei Geral de Proteção de Dados (LGPD — Law 13.709/2018) establishes the core principles that the dpo2u/lgpd/v1 schema maps into machine-readable fields:

#	Principle	LGPD Article	Schema mapping
1	Finalidade (Purpose)	Art. 6, I	data_categories — 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 requests
5	Qualidade dos dados (Data quality)	Art. 6, V	last_review — periodic accuracy review
6	Transparência (Transparency)	Art. 6, VI	privacy_notice document (CID on IPFS)
7	Segurança (Security)	Art. 6, VII	Attestation-backed evidence of controls
8	Prevenção (Prevention)	Art. 6, VIII	dpia document
9	Não discriminação (Non-discrimination)	Art. 6, IX	validation rules over processing claims
10	Responsabilização (Accountability)	Art. 6, X	immutable CID + attestation
11	Consentimento (Consent)	Art. 7, I	consent_mechanism

Cross-jurisdiction note

The schema starts from LGPD, but the approach is deliberately extensible. That matters because the surrounding regulatory environment is moving toward machine-verifiable attributes and narrower disclosure:

• eIDAS 2 normalizes selective disclosure in the EU digital identity stack
• AMLA increases pressure for auditable, per-decision compliance logic
• MiCAR raises the baseline for crypto-asset compliance evidence

DPO2U does not claim that dpo2u/lgpd/v1 is already a universal schema. The claim is narrower: the schema approach is compatible with cross-jurisdiction extension, rather than hard-coding a single-country model.

Schema design principles

Each field maps to a concrete legal requirement:

• retention_days — LGPD Art. 15 requires deletion when data is no longer necessary
• consent_mechanism — LGPD Art. 7 requires a legal basis for processing
• dpo_contact — LGPD Art. 41 requires a reachable DPO function
• last_review — supports data quality and policy freshness

The dpo2u/lgpd/v1 schema

The default structure emitted by the LGPD Kit Generator is intentionally compact so that any agent in the network knows where to find the decisive fields.

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 accepted by an Auditor Agent, it must contain all mandatory fields: retention_days, consent_mechanism, dpo_contact, and last_review.

Field reference

Field	Type	Required	Description
schema_version	string	Yes	Must be "dpo2u/lgpd/v1"
company_id	string	Yes	Company identifier
generated_at	string	Yes	ISO 8601 timestamp
policy.retention_days	number	Yes	Maximum retention period in days
policy.data_categories	string[]	Yes	Categories of personal data processed
policy.consent_mechanism	string	Yes	Declared legal basis
policy.dpo_contact	string	Yes	DPO email or equivalent contact
policy.last_review	string	Yes	Date of last review
documents[].type	string	Yes	Document type
documents[].cid	string	No	Immutable content reference after upload

Storage flow

Step by step

1. Generation — the Expert Agent produces policy.json conforming to dpo2u/lgpd/v1
2. IPFS upload — the payload is stored and receives a CID
3. CID injection — the CID is linked back into the schema
4. Validation — the Auditor Agent checks mandatory fields and computes a score
5. Attestation — score and references are wrapped into an attestation flow

Validation rules

Rule	Check	Failure behavior
Schema version	Must equal "dpo2u/lgpd/v1"	Rejected
Mandatory fields	All required fields present and non-null	Rejected
Retention period	retention_days > 0 and ≤ 3650	Warning / review
Consent mechanism	Must be recognized	Warning
DPO contact	Must be a valid contact channel	Rejected
Last review	Must be reasonably recent	Warning
Document CIDs	If present, must be valid	Warning

Only after passing mandatory checks does scoring proceed.

What's next

• Research — why schemas matter in a multi-jurisdiction attestation protocol
• Architecture — where schemas fit into the current stack
• Agents — how auditor agents consume these fields