> ## Documentation Index
> Fetch the complete documentation index at: https://docs.unifokal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Dados cadastrais entregues

> O módulo registration_data entrega quatro campos fixos a partir das consultas de CPF do mesmo flow, com o registro de finalidade.

## Dados cadastrais entregues

O módulo `registration_data` é diferente de todos os anteriores: ele **não faz consulta nenhuma**. Ele pega o que os tiers `cpf_*` do mesmo flow já trouxeram e entrega **quatro campos, sempre os mesmos quatro**, com o registro de finalidade do tratamento ao lado. Sem um tier `cpf_*` no flow não há o que entregar. É o único módulo desta família com **contrato fechado**: aqui você pode escrever um parser estrito.

```
// registration_data: quatro campos, e o registro de finalidade
{ "module": "registration_data", "passed": true, "outcome": "approved", "score": 100,
  "data": {
    "delivered": { "name": "JOÃO SILVA",
                   "birth_date": "1992-11-04",        // ISO aqui (DD/MM/AAAA nos tiers cpf_*)
                   "registration_status": "regular",  // valor CRU da fonte, não um enum nosso
                   "deceased": false },               // null = NÃO MEDIDO, nunca "vivo"
    "purpose": { "stated_purpose": "identity_verification",
                 "controller": "client", "operator": "unifokal",
                 "legal_basis": "controller_art_7", "minimization": "art_6_iii",
                 "delivered_fields": ["name","birth_date","registration_status","deceased"],
                 "withheld_fields": ["affiliation","gender","address","contacts","companies","death_year"],
                 "policy_version": "registration-delivery@1" },
    // QUAIS tiers sustentaram os campos acima: prova de diligência, nunca dado do titular
    "coverage": ["cpf_status"] } }

// nenhum tier sustentou nenhum dos quatro campos: NÃO entregue, e o módulo sai do preço
{ "module": "registration_data", "passed": null, "outcome": "pending", "score": 0,
  "data": { "delivered": null, "purpose": { "…": "idêntico ao acima" }, "coverage": [] } }
```

**Três leituras que evitam erro.** Primeira: `deceased: null` não é `false`. `null` quer dizer que o tier comprado não carregava o campo de óbito, ou seja **não medimos**, e nunca "confirmamos que está vivo". Segunda: `registration_status` é o valor **cru da fonte**, com a capitalização dela (`Regular`, `Suspensa`, `Titular Falecido`), e vem `null` quando o tier comprado não traz situação, que é o caso do `cpf_companies`. Terceira: o bloco `purpose` viaja **mesmo quando `delivered` é `null`**, porque ele é o registro de **finalidade e minimização** do tratamento, não a prova de que houve entrega. Ele é constante por construção, então não o leia como configuração da sua conta: `withheld_fields` é a lista do que decidimos **não** entregar neste módulo, e ela é a mesma para todo mundo.

Cada um dos quatro campos é resolvido **independentemente**, varrendo os tiers do flow e ficando com o primeiro valor não nulo. Por isso `coverage` pode listar mais de um módulo: não existe um tier "vencedor" único, existe o primeiro que respondeu **por campo**. E `coverage` traz nome de **módulo**, nunca dado do titular.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.