Modelo Corporativo de Dados — Horus HAB

Código: HORUS-DAT-MCD-001 Versão: 1.0 — 2026-10-15 Escopo: Modelo conceitual unificado dos dados da SDUH: domínios de negócio, entidades mestres (MDM) — o que está em uso hoje e o que é proposta para o futuro — e o mapeamento das entidades de cada domínio para o banco operacional (PostgreSQL) e para a camada analítica (BigQuery Gold). Base: Mapeamento de 9 sistemas legados concluído em 2026-06-24.

---

Resumo Executivo

A Secretaria de Habitação opera com vários sistemas legados em SQL Server, cada um com seu próprio banco ou schema, sem modelo de dados compartilhado. Este documento estabelece o modelo corporativo unificado: os domínios de negócio, as entidades que deveriam ser compartilhadas entre eles e o mapeamento das entidades de cada domínio para o banco operacional (PostgreSQL) e para a camada analítica (BigQuery).

O modelo está organizado em 7 domínios de negócio. Cada domínio tem um schema dedicado no PostgreSQL. A maioria também tem datasets dedicados no BigQuery (Bronze → Silver → Gold) para a camada analítica — Segurança/IAM é exceção: é domínio de controle de acesso, não de negócio, e não é replicado para BigQuery (Seção 5).

Hoje não há nenhuma entidade mestre (MDM) em produção. Cada domínio ainda opera com sua própria cópia de pessoa, município, empresa, programa habitacional e empreendimento, herdada do respectivo sistema legado (Seção 3). A Seção 2 documenta essa realidade e a proposta em avaliação para o futuro (mdm_novo) — sem tratar proposta como fato consumado.

---

1. Domínios de Negócio

#	Domínio	Sistemas de origem	Schema PG	Dataset BQ
1	Regularização Fundiária	Cidade Legal	regularizacao	regularizacao_bronze/silver/gold
2	Aprovação e Certificação	GRAPROHAB	aprovacao	aprovacao_bronze/silver/gold
3	Subsídio Habitacional	CPADM (Casa Paulista)	subsidio	subsidio_bronze/silver/gold
4	Habitação Popular	Nossa Casa	habitacao	habitacao_bronze/silver/gold
5	Corporativo / Administrativo	RH	banco corporativo (dados administrativos)	corporativo_bronze/silver/gold
6	Segurança / IAM	Módulo Segurança do Horus HAB	schema seguranca	— (não aplicável; ver nota abaixo)
7	Solicitações Municipais	Horus Solicitação Municipal (SHAB Horus)	solicitacao	solicitacao_bronze/silver/gold

Segurança/IAM já está em produção como a autenticação e autorização atuais do Horus HAB (Seção 3.6) — não depende da adoção de nenhum MDM. Os demais domínios passam a usá-la conforme seus sistemas são migrados ou modernizados; até lá, cada um mantém seu próprio controle de acesso legado. É domínio de controle de acesso, não de negócio: não tem dataset no BigQuery (Seção 5) nem é analisado na camada analítica.

Regra: dados que pertencem a um único domínio vivem no schema desse domínio. Dados de referência que vierem a ser compartilhados entre múltiplos domínios devem residir no schema mdm do banco do sistema dono — hoje nenhuma entidade está nesse estado (Seção 2). Dados administrativos internos vivem no banco corporativo.

---

2. Dados Mestres (MDM) — estado atual e proposta

Dado mestre é informação de referência compartilhada entre dois ou mais sistemas, com um único sistema de registro e dono. Esta seção documenta, nessa ordem: (2.1) o que está de fato em uso hoje — nada —, (2.2) a proposta em avaliação para o futuro, e (2.3) a regra que vai valer quando uma entidade for formalmente adotada como mestre.

2.1 Estado atual: nenhum dado mestre em produção

Nenhuma entidade — Pessoa, Município, Empresa, Programa Habitacional ou Empreendimento — tem hoje um cadastro mestre compartilhado, consumido por mais de um sistema. Cada domínio opera com a cópia que herdou do seu próprio sistema legado; as tabelas reais de cada domínio estão na Seção 3.

O custo conhecido disso: a mesma pessoa física ou jurídica pode existir em registros separados e não vinculados em GRAPROHAB, CPADM, RH, Nossa Casa e Cidade Legal, sem forma sistemática de saber que é a mesma pessoa.

No schema mdm existem hoje as tabelas mdm.empresas, mdm.programas_habitacionais e mdm.empreendimentos (com tabelas satélite de identificadores e tipologias), mas nenhuma delas é fonte de dado mestre válida — não devem ser usadas por módulos novos.

LGPD: em qualquer tabela de pessoa hoje existente por domínio (Seção 3), CPF, RG, nome completo, data de nascimento, endereço e renda são campos Restritos. Nunca replicar sem mascaramento para HOM ou BigQuery — essa regra vale independente de a entidade ser ou não dado mestre.

2.2 Proposta em avaliação para o futuro: schema mdm_novo

Isto é uma proposta em discussão, não uma decisão. Está aplicada apenas em ambiente de homologação, sem nenhum dado de negócio carregado, só para avaliação técnica. Diverge de propósito da nomenclatura usada neste documento — decisão explícita de manter o tema em refinamento — e não está em uso em nenhum sistema. Só passaria a valer após revisão técnica e aprovação formal do Comitê de Dados (Doc 05 §1.2).

A proposta redesenha o cadastro mestre corporativo em 5 grupos de entidades:

Entidade proposta	Estrutura (no desenho)	Substituiria, se aprovada	Observação
Entidade (Party Model)	entidades (raiz) + especializações pessoas_fisicas / pessoas_juridicas	Pessoa e Empresa, hoje inexistentes como mestre e historicamente tratadas em tabelas separadas	Elimina o "pessoa XOR empresa" em todo consumidor; CNPJ obrigatório em pessoa jurídica, CPF obrigatório em pessoa física salvo justificativa estruturada (estrangeiro, menor sem CPF, não informado, exigindo ao menos um documento).
Município	municipios + satélites de região e geometria	Município, hoje replicado por domínio	Chave canônica (UUID) e chave natural (código IBGE), mesma lógica que já era a intenção de unificação original — ainda não implantada.
Programa Habitacional	programas_habitacionais + programas_habitacionais_subprogramas	Programa Habitacional, hoje replicado por domínio	9 programas e 13 subprogramas definidos como semente, pendentes de validação de negócio (siglas e base legal incompletas em parte dos programas).
Arquivo	arquivos	Arquivo/Mídia, hoje sem cadastro único	Atributos de tamanho e hash do arquivo propostos sem fonte oficial confirmada.
Empreendimento	empreendimentos + 8 tabelas satélite (enquadramento, responsáveis, situações, portes, valores, matrículas, identificadores de origem, fusões)	Empreendimento, hoje mantido por domínio (Seção 2.1)	Ponto/projeto com endereço completo obrigatório, sem o identificador externo da Caixa. Dono do dado ainda indefinido.

Além das 5 entidades mestras, a proposta inclui a estrutura de apoio abaixo — já desenhada e aplicada em homologação junto com as entidades:

• Tabelas de domínio/referência (8): tipos_documentos, tipos_contatos, tipos_enderecos, tipos_representacoes, naturezas_juridicas, sistemas_origem, tipos_empreendimentos e tipos_arquivos — valores fixos usados pelas entidades mestras e suas satélites (ex.: de qual sistema legado um registro veio, qual o tipo de documento ou de endereço).
• Território (3 tabelas): além de municipios, as satélites municipios_regioes e municipios_geometrias guardam agrupamento regional e geometria PostGIS do município, sem duplicar a tabela mestre.
• Schema auditoria (novo, fora do mdm): schema corporativo dedicado, com a tabela log_operacao e a função fn_registrar_operacao, para registrar operações sobre qualquer dado mestre — implementa o padrão de auditoria do Doc 04 (§7.1–7.2) sem alterar sua lógica; o mascaramento de LGPD é aplicado no próprio registro do log.

Decisões de desenho da proposta, todas pendentes de deliberação formal:

• Linhagem registrada em tabelas satélite de identificador de origem, em vez de colunas na própria tabela mestre (desvio da regra de linhagem padrão do Doc 06).
• Fusão e reversão de registros duplicados como operação formal, auditável e imutável, em vez de exclusão e recriação manual.

Enquanto a proposta não é aprovada, nenhum módulo novo deve assumir mdm.empresas, mdm.programas_habitacionais ou mdm.empreendimentos (Seção 2.1) como fonte confiável — a questão deve ser tratada como pendência aberta com o Arquiteto de Dados.

2.3 Regra de não-duplicação de dado mestre (vale a partir da adoção formal de cada entidade)

1. Toda vez que um schema de domínio (novo ou de um sistema em migração) precisar de um atributo coberto por uma entidade formalmente adotada como mestre, a referência é obrigatória por chave canônica (FK, ou FK lógica via API quando o domínio está em outro banco, Doc 06, REG-CM-18) — nunca uma tabela ou conjunto de colunas equivalente dentro do próprio domínio. Isso vale tanto para sistemas novos quanto para sistemas legados sendo migrados.
2. Se o módulo precisa de um atributo que a entidade mestre ainda não tem, a extensão correta é uma das duas abaixo — nunca uma segunda tabela paralela com estrutura equivalente à entidade mestre:
   • o atributo é genérico o suficiente para interessar a outros consumidores → vira coluna nova na própria tabela mdm.* (sujeito ao rito de aprovação do Procedimento Operacional de Modelagem);
   • o atributo é específico de poucos consumidores → vira tabela satélite no plural (mdm.{tabela_mestre}_{atributo}, ex.: mdm.municipios_geometrias) referenciando a chave canônica da entidade mestre, nunca uma cópia da entidade em si.
3. Checagem obrigatória na aprovação de qualquer schema novo (Procedimento Operacional §1.2): antes de aprovar uma tabela proposta por um módulo, o Arquiteto de Dados confere se ela não está recriando — total ou parcialmente — uma entidade já adotada como mestre. Isso vale tanto para schema desenhado do zero quanto para schema extraído/traduzido de um sistema legado.
4. Dados herdados de um sistema legado que já duplicam uma entidade mestre adotada (comum durante extração fiel de um legado, antes da tradução para o modelo alvo) não validam a duplicação — são o sinal de que, na tradução para o schema de destino, aquela tabela deve ser substituída por referência à entidade mestre, com o de-para registrado na documentação de migração do módulo.

2.4 Regras, DDL e exemplos

As regras normativas (chaves, nomenclatura, soft delete, papéis, snapshots, matriz de sobrevivência, linhagem, LGPD e auditoria) que qualquer entidade deve seguir quando se tornar dado mestre, o fluxo de decisão e a ficha arquitetural de módulo estão no Doc 06 — Padrão Técnico para Cadastro Mestre. Os exemplos de DDL e consumo do Doc 06 são hoje ilustrativos; conforme as decisões de MDM desta Seção 2 forem tomadas e implementadas, esses exemplos são substituídos pela estrutura real adotada.

---

3. Entidades por Domínio

3.1 Domínio: Regularização Fundiária (regularizacao)

Entidade	Tabela PG	Origem legado	Tipo
Núcleo habitacional	regularizacao.nucleos	sislegal.tbNucleo	Principal
Processo de regularização	regularizacao.processos	sislegal.tbRegularizacao	Principal
Etapa do processo	regularizacao.etapas_processos	sislegal.tbEtapa + workflow	Detalhe
Convênio	regularizacao.convenios	sislegal.tbConvenio	Principal
Ordem de serviço	regularizacao.ordens_servico	sislegal.OS	Principal
Medição de OS	regularizacao.medicoes	sislegal.Medicao	Detalhe
Titulação	regularizacao.titulacoes	sislegal.tbTitulacao	Detalhe
Edital	regularizacao.editais	sislegal.tbEdital	Referência

3.2 Domínio: Aprovação e Certificação (aprovacao)

Entidade	Tabela PG	Origem legado	Tipo
Processo GRAPROHAB	aprovacao.processos	graprohabdigital.tbProcesso	Principal
Certificado	aprovacao.certificados	graprohabdigital.tbCertificado	Principal
Análise técnica	aprovacao.analises	graprohabdigital.tbAnalise	Detalhe
Protocolo presencial	aprovacao.protocolos_presenciais	graprohabpresencial.*	Histórico

Decisão em aberto: fonte autoritativa entre as 3 gerações GRAPROHAB (graprohabdigital, novograprohab, graprohabpresencial) ainda não foi definida.

3.3 Domínio: Subsídio Habitacional (subsidio)

Entidade	Tabela PG	Origem legado	Tipo
Registro de interesse	subsidio.registros_interesse	casapaulista.tbRegistroInteresse	Principal
Contratação	subsidio.contratacoes	casapaulista.tbBeneficiarioContratacao	Principal
Cheque / benefício	subsidio.cheques	casapaulista.tbRegistroInteresseCheque	Detalhe
Autorização de recurso	subsidio.autorizacoes_recurso	casapaulista.tbEventoAutorizacaoRecurso	Detalhe
Imóvel / empreendimento	subsidio.empreendimentos	casapaulista.tbImovel	Própria do domínio — sem entidade mestre (Seção 2.1)

3.4 Domínio: Habitação Popular (habitacao)

Entidade	Tabela PG	Origem legado	Tipo
Empreendimento	habitacao.empreendimentos	nossacasa.Empreendimento	Própria do domínio — sem entidade mestre (Seção 2.1)
Terreno	habitacao.terrenos	nossacasa.PastaTerreno + VitrinePastaTerreno	Principal
Pré-cadastro família	habitacao.inscricoes_familias	nossacasa.PreCadastroFamilia	Principal
Adesão	habitacao.adesoes	nossacasa.PastaAdesao	Detalhe
Situação workflow	habitacao.situacoes_workflow	nossacasa.StatusWorkflow	Detalhe
Município vinculado	Cópia própria do domínio	nossacasa.Municipio	Candidato a futuro dado mestre — sem entidade mestre adotada hoje (Seção 2.1)

3.5 Domínio: Corporativo / Administrativo (banco corporativo)

Entidade	Tabela PG	Origem legado	Tipo
Servidor público	corporativo.servidores	rh.tbFuncionario	Principal
Cargo	corporativo.cargos	rh.tbCargo	Referência
Departamento	corporativo.departamentos	rh.tbDepartamento	Referência

O schema mdm (destino de qualquer futura entidade mestre) é hospedado no mesmo banco corporativo, mas hoje não tem dado mestre adotado — ver Seção 2.1. As tabelas mdm.empresas, mdm.programas_habitacionais, mdm.empreendimentos e seus satélites existem no schema, mas não são fonte de consumo válida e por isso não são listadas aqui.

3.6 Domínio: Segurança / IAM (seguranca)

Entidade	Tabela PG	Origem legado	Tipo
Usuário do sistema	seguranca.usuarios	seguranca.tbUsuario	Principal
Perfil de acesso	seguranca.perfis	seguranca.tbPerfil	Referência
Módulo / recurso	seguranca.modulos	seguranca.tbModulo	Referência
Permissão	seguranca.permissoes	seguranca.tbPermissao	Detalhe
Sistema registrado	seguranca.sistemas	seguranca.tbSistema	Referência

Já em produção, independente do MDM: a autenticação é delegada ao Gov.br (municípios) e ao CyberArk (SDUH), com sessão via Firebase Authentication. O schema seguranca mantém apenas autorização (perfis, módulos, permissões) e não armazena senha. Perfis iniciais: municipio_user, sduh_user, sduh_mgr, adm e maintainer (Doc 02, Seção 3). Sistemas e módulos passam a usar este IAM conforme são migrados ou modernizados.

3.7 Domínio: Solicitações Municipais (solicitacao)

Entidade	Tabela PG	Origem	Tipo
Solicitação municipal	solicitacao.solicitacoes	Doc 02, Módulo 2	Principal
Informações preliminares	solicitacao.informacoes_preliminares	Doc 02, req. 2.1	Detalhe
Histórico de tramitação e situação	solicitacao.historicos_situacoes	Doc 02, req. 2.5	Detalhe
Análise técnica	solicitacao.analises_tecnicas	Doc 02, req. 2.3	Detalhe
Análise de projeto	solicitacao.analises_projetos	Doc 02, req. 2.4	Detalhe
Documento da solicitação	solicitacao.solicitacoes_arquivos	Doc 02, Módulo 4	Candidato a futuro dado mestre de Arquivo — sem entidade mestre adotada hoje (Seção 2.1)
Município solicitante	Referência própria do domínio	—	Candidato a futuro dado mestre — sem entidade mestre adotada hoje (Seção 2.1)

As situações seguem os estados canônicos do Doc 02, Seção 4, requisito 2.5 (RASCUNHO, EM_ANALISE, AGUARDANDO_DOCUMENTO, HOMOLOGADO, INDEFERIDO, SUSPENSO, CONCLUIDO, CANCELADO). O isolamento entre municípios (tenant) é feito por município em solicitacao.solicitacoes.

---

4. Modelo Conceitual — Relacionamentos entre Domínios

Hoje cada domínio é uma ilha: não há entidade compartilhada ligando um domínio a outro (Seção 2.1). O diagrama mostra os relacionamentos reais dentro de cada domínio, e a proposta de MDM separada, ainda não conectada a nenhum deles.

---

5. Mapeamento Conceitual → BigQuery Gold

Entidade PG (operacional)	Tabela BQ Gold	Dataset BQ
solicitacao.solicitacoes	fato_solicitacoes	solicitacao_gold
regularizacao.processos	fato_regularizacoes	regularizacao_gold
regularizacao.ordens_servico	fato_ordens_servico	regularizacao_gold
regularizacao.convenios	fato_contratos_convenios	regularizacao_gold
aprovacao.processos	fato_certificacoes	aprovacao_gold
subsidio.registros_interesse	fato_registros_interesse	subsidio_gold
subsidio.cheques	fato_beneficios_subsidios	subsidio_gold
subsidio.contratacoes	fato_contratacoes	subsidio_gold
habitacao.inscricoes_familias	fato_inscricoes_familias	habitacao_gold
habitacao.terrenos	fato_processos_terrenos	habitacao_gold

Segurança/IAM não é replicado para BigQuery. É domínio de controle de acesso, não de negócio — não existe seguranca_gold nem dimensão de usuário na camada analítica. Município, Pessoa, Empresa e Programa Habitacional ainda não têm uma dimensão corporativa única no BigQuery — cada domínio alimenta sua própria versão hoje, quando alimenta. Uma dimensão compartilhada depende da adoção formal de um MDM (Seção 2.2). Regra: o BigQuery é somente leitura para a camada analítica. Nenhum dado é escrito diretamente no BQ por sistemas operacionais. O fluxo é: PostgreSQL → pipeline (CDC ou scheduled query) → BQ Bronze → BQ Silver → BQ Gold.

---

6. Decisões de Governança

#	Decisão	Situação	Impacto
1	Modelo mestre de Pessoa, Município, Empresa, Programa Habitacional e Empreendimento	Em avaliação	Nenhuma das cinco entidades tem dado mestre em produção hoje (Seção 2.1). Proposta completa nova (mdm_novo) aplicada em homologação só para avaliação, sem dados de negócio; aguarda revisão técnica e aprovação do Comitê de Dados (Seção 2.2).
2	Fonte autoritativa do GRAPROHAB	Em aberto	Define aprovacao.processos e critério de arquivamento das 3 gerações (graprohabdigital vs novograprohab vs presencial).
3	Estratégia de IdP/SSO (Segurança)	Resolvida e em produção	Autenticação Gov.br / CyberArk com Firebase. seguranca mantém só autorização e já é o IAM real do Horus HAB; demais módulos passam a usá-lo conforme são migrados ou modernizados — não depende do MDM.
4	SHAB-NOSSA-CASA vs. SITENOSSACASA	Em aberto	Define consolidação em schema único habitacao.
5	Padrão de integração de dado mestre entre bancos, quando houver	Resolvida (regra de desenho; sem aplicação hoje)	Caso uma entidade seja adotada como mestre, sistema em outro banco a consome exclusivamente pela API do sistema dono; referências em outros bancos são FK lógica (Doc 06, REG-CM-17 a 22).

---

7. Glossário de Termos Corporativos (Vocabulário Controlado)

O modelo de dados e o dicionário de metadados adotam estritamente o vocabulário controlado oficial da DTIC. Este quadro espelha o glossário mantido no Knowledge Catalog (Doc 05, Seção 7.4):

Termo Canônico	Termos Obsoletos / Proibidos	Definição no contexto SDUH
Município	Cidade, Mun, Localidade	Ente federativo municipal do Estado de SP com código IBGE oficial de 7 dígitos.
Situação	Status, Estado, Fase	Estado administrativo atual da solicitação ou registro (ex.: RASCUNHO, EM_ANALISE, HOMOLOGADO).
Logradouro	Rua, Endereço, Via	Espaço público reconhecido para fins de endereçamento e cadastro territorial.
Beneficiário	Cliente, Favorecido, Mutuário	Pessoa física ou jurídica atendida por programa habitacional ou de regularização da Secretaria.
Protocolo	Chamado, Ticket, Requerimento	Registro unívoco de tramitação e protocolo oficial de solicitações perante a SDUH.
Órgão	Setor, Secretaria	Unidade administrativa, colegiado ou secretaria participante do processo administrativo.
Documento	Doc, Anexo	Registro comprobatório, certidão, projeto ou arquivo técnico atrelado a um processo.
Dado Mestre (MDM)	Dado Compartilhado	Informação canônica de referência corporativa compartilhada, com dono único definido e sem duplicidade — ainda não implementada em produção para nenhuma entidade (Seção 2.1).
Domínio	Sistema	Agrupamento de entidades e processos de negócio com alta coesão, mapeado a um schema no PostgreSQL.
Golden Record	Registro duplicado, Cópia	Versão única, autoritativa e higienizada de um registro mestre.
Party Model (Papel)	Tipo de pessoa como coluna	Padrão que separa a identidade da entidade (cadastro mestre) dos papéis que ela assume em cada processo (tabela associativa no módulo).
Índice Único Parcial	Constraint UNIQUE em tabela com soft delete	Índice de unicidade filtrado por WHERE fl_excluido = FALSE, que permite reativar e recadastrar sem violar a chave.
Data Stewardship	Responsável informal	Atribuição formal da custódia, das regras de precedência e da qualidade de um dado mestre a um gestor técnico.
Departamento	Divisão	Unidade organizacional interna de RH (corporativo.departamentos), subordinada a um Órgão.
Arquivo	Mídia solta	Objeto físico armazenado no GCS; um Documento é materializado por um ou mais Arquivos.
Módulo	Sistema, Domínio	Unidade funcional de software que consome dados de um ou mais Domínios (ex.: módulo Segurança, módulo Solicitações Municipais).

Termos da proposta mdm_novo (em discussão — não adotados)

Os termos abaixo pertencem ao redesenho do MDM descrito na Seção 2.2. Nenhum foi aprovado: estão aqui para que quem ler a proposta em homologação entenda o vocabulário, não como vocabulário corporativo vigente.

Termo (proposta)	Termos que substituiria, se aprovado	Definição na proposta
Entidade (Party Model)	Pessoa e Empresa como tabelas separadas	Tabela raiz única que unifica pessoa física e pessoa jurídica num só cadastro mestre; o tipo concreto fica em uma tabela de especialização.
Especialização	— (conceito novo)	Tabela com chave própria ligada à Entidade raiz por chave estrangeira composta (id_entidade, tp_pessoa), representando o subtipo — hoje pessoas_fisicas e pessoas_juridicas.
Representação	— (conceito novo)	Vínculo formal entre duas Entidades em que uma representa a outra (ex.: procurador, representante legal), distinto de papel operacional de módulo.
Documento de Entidade	Campo de documento solto na tabela de pessoa	Identificação formal (RG, CNH, etc.) registrada em tabela satélite própria, vinculada à Entidade, podendo haver mais de um documento por Entidade.
Identificador de Origem	Colunas id_origem_externa / tp_origem_cadastro na própria tabela mestre (padrão do Doc 06)	Tabela satélite que registra o código que a Entidade ou o Empreendimento tinha em cada sistema de origem, mantendo a linhagem fora da tabela mestre. É um desvio proposto da regra de linhagem do Doc 06 (REG-CM-14), ainda sem decisão formal.
Fusão / Reversão	Exclusão e recriação manual de registro duplicado	Operação formal e registrada que une dois registros mestres reconhecidos como duplicados (Fusão) ou desfaz essa união (Reversão), guardada em tabela própria e imutável.
Exclusão de Entidade	Exclusão lógica sem rastro	Registro formal, sem dado pessoal, de que uma Entidade foi excluída logicamente — mantém rastreabilidade sem reter PII fora da tabela mestre.
Satélite	Coluna nova direto na tabela mestre, para qualquer atributo	Tabela que estende uma entidade mestre com atributos de um grupo específico de consumidores (ex.: valores e matrículas de um Empreendimento), sem duplicar a entidade — já era o padrão do Doc 06 §2.0, a proposta só amplia o número de satélites.
Sistema de Origem	— (conceito novo)	Tabela de domínio que identifica de qual sistema legado (Cidade Legal, Nossa Casa, GRAPROHAB, CPADM etc.) veio um registro, usada pelas satélites de Identificador de Origem.
Motivo de Ausência de CPF	nr_cpf sempre obrigatório	Justificativa estruturada (estrangeiro, menor sem CPF, não informado) que, se preenchida, permite uma Pessoa Física sem CPF — desde que tenha ao menos um Documento de Entidade ativo.
Schema de Auditoria	Log de alteração dentro de cada tabela	Schema corporativo dedicado a registrar operações sensíveis sobre dado mestre (quem, quando, o quê), com o mascaramento de LGPD aplicado no próprio registro de log, não só na tabela de origem.