Consent Ledger Orientado a Eventos (Prisma + PostgreSQL)

Implementação técnica de consentimento quando a base legal da atividade é o consentimento (Art. 7º, I ou Art. 11, I, e Art. 14, § 1º para crianças).

Quando usar: apenas para finalidades efetivamente baseadas em consentimento (ex.: comunicações de marketing sem legítimo interesse aplicável, cookies/trackers não essenciais, opt-in biométrico facultativo). Não crie registros de "consentimento" para atividades cuja base real é execução de contrato (Art. 7º, V) ou obrigação legal (Art. 7º, II).

Arquitetura: sequência de eventos imutáveis

Em vez de mutar uma linha ou misturar grantedAt/revokedAt no mesmo campo de ordenação, modele o consentimento como uma sequência cronológica de eventos (ConsentEvent):

• GRANTED — consentimento concedido para (subjectId, purpose, policyVersionId) com hash de evidência;
• REVOKED — consentimento revogado pelo titular/responsável (Art. 8º, § 5º), referenciando o evento original via rootConsentId;
• SUPERSEDED — substituído quando uma mudança material de finalidade/política invalida o consentimento anterior (Art. 8º, § 6º);
• EXPIRED — expirado quando a concessão possuía TTL explícito (expiresAt).

Cada evento possui:

• occurredAt: DateTime + seq: BigInt @default(autoincrement()) — ordenação monotônica determinística (orderBy: [{ occurredAt: "desc" }, { seq: "desc" }]), evitando que uma revogação no mesmo milissegundo de um grant mantenha o consentimento ativo por erro de ordenação;
• rootConsentId — linhagem direta até o GRANTED original;
• policyVersionId + evidenceHash + channel — preenchidos em todos os eventos (sem omissão de campos obrigatórios do Prisma).