SREI e ITN-04: 14 Melhorias para a Interoperabilidade do Registro Eletrônico de Imóveis

Contexto

A ITN-04 padroniza a escrituração e o compartilhamento de dados do SREI por meio de schemas JSON (JSON Schema Draft 2020-12), organizados em Anexos. A consistência desses schemas é o que sustenta a interoperabilidade que o SREI, e o Provimento CNJ 213/2026, buscam: matrículas, situações jurídicas e certidões trafegando entre cartórios, ONR, Judiciário e mercado sem ambiguidade.

Este artigo reúne os achados de uma implementação de referência dos Anexos III, IV, V, VII e VIII, conduzida pela equipe de engenharia da Mupi Systems (empresa de tecnologia responsável pelo desenvolvimento do RI-Online). São 14 pontos, cada um com evidência reproduzível, análise de impacto e uma proposta de correção. A intenção é somar ao trabalho de padronização do SREI: nenhum achado vem sem um caminho concreto de solução.

Na prática, um schema só se confirma correto quando uma implementação independente consegue gerar e validar documentos contra ele sem erros.

Como os achados foram levantados

Boa parte das inconsistências de uma especificação só aparece na tentativa de implementá-la de ponta a ponta. A equipe da Mupi Systems desenvolveu um gerador e validador de documentos SREI rodando contra os schemas oficiais (JSON Schema Draft 2020-12). O resultado foi um DocumentoSituacaoJuridicaImovel (Anexo VII) que valida com 0 erros contra o schema publicado.

Até chegar a esse resultado, vários pontos exigiram contorno manual ou só funcionaram após correção. Registramos cada um com a evidência que o tornou observável, o impacto sobre a interoperabilidade e uma proposta de correção. Todos são reproduzíveis a partir dos arquivos de schema publicados no pacote ITN-04.

Os 14 achados a seguir foram re-conferidos contra a versão v1.1 do pacote (publicada em 27/05/2026, identificada pelo campo x-version presente nos schemas principais de todos os anexos). A republicação resolveu uma lacuna anterior, a falta do schema principal do Anexo V (Livro 2), que agora é distribuído e contra o qual nossa implementação já gera o DocumentoAto schema-válido. Parte dos achados (incluindo os dois últimos) foi confirmada de forma independente compilando os schemas com o ajv, um validador conforme do ecossistema JavaScript. Os 14 pontos abaixo permanecem em aberto na v1.1.

Cada achado a seguir segue o mesmo formato: Evidência → Impacto → Proposta.

Resumo dos 14 achados

#	Achado	Severidade
1	Recurso referenciado ausente de todo o pacote (ListaCondicaoResolucaoIneficacia)	Alta
2	Namespaces auxiliares (ClassesAuxiliaresGerais, TiposBasicos) não distribuídos como recursos	Alta
3	Listas sob namespaces compartilhados, mas referenciadas sob o namespace do anexo (refs não resolvem; ex.: 63/63 no Anexo V)	Alta
4	URIs com host divergente (http://lsi-tec.org.br) e protocolo http	Alta
5	$schema (dialeto) malformado em arquivos de lista	Alta
6	Números modelados como string com pattern (vírgula decimal)	Média
7	Representação inconsistente de booleanos ("sim/não" vs boolean)	Média
8	ListaMunicipioUF como enum de 5.572 valores embutido	Média
9	Typos / inconsistência de capitalização em $ref vs $id	Média
10	Schemas tropeçam crawlers de $ref conformes (ex.: referencing/Python)	Média
11	Domínios de lista divergentes entre ONR e SREI sem tabela de equivalência	Média
12	pattern com expressão regular inválida no modo unicode (ECMA-262)	Média
13	allOf em posição inválida, schema reprovado pelo meta-schema	Média
14	Anexo VIII embute o documento do Anexo VII por cópia (não por $ref)	Baixa

Os 14 achados em detalhe

1. Recurso referenciado ausente do pacote — Alta

Evidência. O schema do Anexo VII referencia ~49 listas e tipos auxiliares. No pacote completo da v1.1, cada anexo distribui suas próprias listas (48 no VII, 47 no VIII, 9 no Livro 1, 63 no Livro 2), com conteúdo idêntico entre namespaces (0 divergências de enum na verificação cruzada). Apesar disso, a ListaCondicaoResolucaoIneficacia — referenciada duas vezes pelo schema principal do VII (em CondicaoResolucaoAtoIneficacia) — não existe como arquivo em nenhum anexo.

Impacto. Documentos que usem ListaCondicaoResolucaoIneficacia só validam se o recurso for criado manualmente (um stub), já que ele não está no pacote.

Proposta.

• Garantir que toda lista referenciada exista como arquivo no pacote (incl. ListaCondicaoResolucaoIneficacia).
• Publicar, por anexo, um manifesto (index.json) mapeando $id → arquivo, resolvível offline.

2. Namespaces auxiliares não distribuídos como arquivos — Alta

Evidência. Os namespaces auxiliares https://ridigital.org.br/ClassesAuxiliaresGerais e https://ridigital.org.br/TiposBasicos são referenciados por fragmento (#/$defs/Vigencia, #/$defs/CEP, #/$defs/Booleano…), mas não são distribuídos como arquivos: existem apenas embutidos como $defs no schema principal. Vale distinguir do achado 3: aqui falta o documento-raiz do namespace ClassesAuxiliaresGerais; as listas cujo $id usa o caminho ClassesAuxiliaresGerais/ListaX existem como arquivos.

Impacto. Montar um resolver de $ref requer reconstruir ClassesAuxiliaresGerais e TiposBasicos a partir dos $defs do schema principal — foi o que automatizamos, sintetizando os dois namespaces.

Proposta.

• Distribuir ClassesAuxiliaresGerais e TiposBasicos como arquivos-recurso com $id próprio, não apenas embutidos no schema principal.

3. Listas e namespaces: duplicação e referência cruzada — Alta

Evidência. A mesma lista controlada aparece, com conteúdo idêntico, sob múltiplos $id. Exemplo, ListaTipoLogradouroNome existe como: …/Pessoa/ListaTipoLogradouroNome, …/Imovel/ListaTipoLogradouroNome, …/ClassesAuxiliaresGerais/ListaTipoLogradouroNome, …/SituacaoJuridica/ListaTipoLogradouroNome. O mesmo ocorre com dezenas de listas (Estado Civil, Regime de Bens, Município/UF, Natureza Jurídica, etc.).

Além do drift, esse arranjo também afeta a resolução por $id. Em vários anexos, o $ref aponta para a lista sob o namespace do próprio anexo, enquanto o arquivo é publicado sob um namespace compartilhado. No Anexo V (Livro 2) mapeamos o caso completo: os 63 $ref de lista do schema principal apontam para …/AtoLivro2RegistroGeral/ListaX, mas as 63 listas declaram $id em outros namespaces — ClassesAuxiliaresGerais (29), Imovel (26), Pessoa (6) e AtosAberturaMatriculaTransporte (1). Por resolução estrita de $id, esses $ref não encontram o recurso correspondente.

Impacto. Dois efeitos. O primeiro é o risco de divergência (drift): a mesma lista pode evoluir em um namespace e não no outro. O segundo, mais imediato, é de resolução: um validador conforme não localiza um $ref cujo $id nenhum arquivo declara, então documentos do Anexo V passam a validar quando as listas são alinhadas ao namespace esperado — o ajuste que automatizamos. Há ainda o custo de manutenção multiplicada e o tamanho do pacote.

Proposta.

• Definir um namespace canônico único para listas compartilhadas (p.ex. https://ridigital.org.br/Listas/... ou consolidar em ClassesAuxiliaresGerais).
• Os anexos referenciam o canônico por $ref; proibir cópias re-$id-adas.
• Garantir que todo $ref use exatamente o $id que algum arquivo declara — verificável de forma automática (ver seção de sugestões de processo).

4. URIs: host e protocolo divergentes — Alta

Evidência. A imensa maioria dos $id usa https://ridigital.org.br, mas um conjunto deles usa http://lsi-tec.org.br, com outro host e protocolo http. Todos são variações de ListaMunicipioUF:

http://lsi-tec.org.br/Pessoa/ListaMunicipioUF
http://lsi-tec.org.br/ClassesAuxiliaresGerais/ListaMunicipioUF
http://lsi-tec.org.br/Livro1Protocolo/ListaMunicipioUF
http://lsi-tec.org.br/CertidaoSituacaoJuridica/ListaMunicipioUF

Impacto. A inconsistência de base authority impede a resolução do $ref e sugere que esse recurso foi gerado por outro processo. O http também foge ao padrão https do restante do pacote.

Proposta. Padronizar toda a base authority em https://ridigital.org.br e o protocolo em https. Adicionar verificação automática (lint) de host/protocolo.

5. $schema (dialeto) malformado — Alta

Evidência. Na v1.1, cinco arquivos ListaMunicipioUF.schema.json (Anexos V, VI, VII, VIII e IX) declaram:

"$schema": "https://json-schema.org/draft/2020-12/ListaMunicipioUF"

em vez do dialeto correto https://json-schema.org/draft/2020-12/schema. Há ainda mistura de protocolo: 238 arquivos usam http://…/schema e apenas 2 usam https://…/schema.

Impacto. Um validador estrito não reconhece o dialeto e pode não aceitar o recurso. A mistura http/https atrapalha caches e a meta-schema resolution.

Proposta. Corrigir o $schema para https://json-schema.org/draft/2020-12/schema em todos os arquivos. Padronizar protocolo. Validar na publicação.

6. Números modelados como string com pattern — Média

Evidência. Nove primitivos numéricos são type: "string" com pattern, não números JSON: NumeroReal, NumeroNatural, NumeroInteiro, NumeroInteiroPositivo, NumeroReal2C, NumeroRealComPonto, NumeroRealNaoNegativoComPonto, NumeroSERP, NumeroCAR. Ex.: NumeroReal = ^-?(0|[1-9][0-9]*)(,[0-9]+)?$ — decimal com vírgula. Assim, FracaoDireito e áreas trafegam como "100,0" (string), não como 100.0.

Impacto. (a) Impede validação/normalização numérica (minimum, maximum, multipleOf); (b) força formatação locale-específica (vírgula), incomum em JSON e em interoperabilidade internacional; (c) é propenso a erro de ponto vs vírgula, em que de fato tropeçamos.

Proposta. Preferir type: "number"/"integer" com minimum/multipleOf. Se a precisão decimal exata for requisito (valores monetários), usar string com ponto decimal e documentá-la explicitamente, mantendo um único padrão.

7. Representação inconsistente de booleanos — Média

Evidência. Existe o tipo Booleano = ^(sim|não)$ (string), porém DescricaoDireitoReal.PropriedadePlena usa um boolean JSON nativo (true/false). Ou seja, há duas convenções de booleano no mesmo schema.

Impacto. Implementadores precisam saber, caso a caso, se um “sim/não” é string ou boolean. Foi fonte de erro para nós: enviamos "sim" onde se esperava true.

Proposta. Adotar uma convenção (preferencialmente boolean nativo) e aplicá-la a todos os campos lógicos; reservar "sim/não" apenas para enumerações de domínio textual com semântica própria.

8. ListaMunicipioUF como enum gigante — Média

Evidência. ListaMunicipioUF é um enum de 5.572 valores no formato textual "NOME EM MAIÚSCULAS-UF" (ex.: "SÃO PAULO-SP"), embutido em cada anexo.

Impacto. Frágil a renomeações/criação de municípios; volumoso; o nome textual maiúsculo é fonte de divergência (acentuação, grafia). Concentra também os bugs de host/dialeto (achados 4 e 5).

Proposta. Referenciar o código IBGE de 7 dígitos do município (chave estável) com a denominação como atributo derivado; ou publicar a lista como recurso externo versionado (não embutido), atualizável sem reeditar os schemas.

9. Typos e capitalização em $ref — Média

Evidência. O schema do Anexo VIII referencia …/CertidaoSituacaoJuridica/ListaNaturezaJuridicaPessoaJuridicanome (minúsculo) enquanto o recurso canônico é …ListaNaturezaJuridicaPessoaJuridicaNome (maiúsculo). O mesmo typo persiste no Anexo V (Livro 2) na v1.1: o $ref aponta para …ListaNaturezaJuridicaPessoaJuridicanome, mas o arquivo é …Nome.schema.json. Ainda no Livro 2 há um descasamento singular/plural: a branch de DetalhamentoAto usa a chave EstruturaGenericaAtoTransmissoesDireitosReais (plural) enquanto o $def correspondente é EstruturaGenericaAtoTransmissaoDireitosReais (singular); todas as demais branches são singulares.

Impacto. O $ref não resolve por diferença de capitalização, e o problema só aparece em runtime. Tivemos de aplicar fallback case-insensitive no Anexo VIII e no Anexo V. O descasamento singular/plural obriga o gerador a usar exatamente a chave plural só nesse ato, uma fonte provável de erro.

Proposta. Uma verificação automática de integridade, conferindo que cada $ref tenha um $id correspondente com a mesma capitalização, apontaria esse tipo de typo antes da publicação.

10. Compatibilidade com bibliotecas conformes — Média

Evidência. Ao montar o registry de $ref do Anexo VII, a biblioteca referencing (ecossistema jsonschema/Python, conforme 2020-12) falha no crawl do schema ('list' object has no attribute 'get'). A validação lazy funciona, mas o crawl eager não.

Impacto. Ferramentas conformes podem falhar ao pré-carregar os schemas, elevando o custo de adoção.

Proposta. Validar os schemas publicados contra múltiplas implementações de referência (ex.: ajv [JS], jsonschema+referencing [Python], hyperjump) como gate de publicação.

11. Equivalência ONR ↔ SREI — Média

Evidência. Domínios divergem entre normas: ListaEstadoMatricula (SREI) tem 4 valores (ativa/encerrada/bloqueada/cancelada) enquanto a situação da matrícula no ONR-CAD (ITN-03) tem 5 (inclui anulada/inexistente). O CNS é formatado NN.NNN-N no SREI e como 6 dígitos no ONR.

Impacto. Quem implementa ambos (caso comum) precisa adivinhar a correspondência (mapeamos anulada → cancelada, p.ex.). Risco de inconsistência entre ITN-03 e ITN-04.

Proposta. Publicar uma tabela oficial de equivalência ONR↔SREI para os domínios compartilhados (estado da matrícula, CNS, tipos de ato, regime de bens).

12. pattern com regex inválida no modo unicode — Média

Evidência. Ao compilar o schema principal do Anexo V com o ajv (2020-12), a compilação para em um pattern cuja expressão regular não é válida no modo unicode do ECMA-262. A classe de caracteres usa escapes como \,, \& e \/, que não são permitidos com o flag u, gerando Invalid regular expression: Invalid escape.

Impacto. O JSON Schema 2020-12 adota regex ECMA-262 e um validador conforme compila pattern com o flag u. Com a regex inválida, a compilação do schema é interrompida antes mesmo de qualquer validação de dados.

Proposta. Ajustar os pattern para regex válida em modo unicode (dentro de uma classe de caracteres, ,, & e / não precisam de escape) e compilar cada pattern com o flag u na etapa de publicação.

13. allOf em posição inválida (schema reprovado pelo meta-schema) — Média

Evidência. Ainda no Anexo V, o ajv reporta data/$defs/CondicoesPagamento/properties/allOf must be object,boolean: sob properties, onde o meta-schema espera subschemas, há um allOf que não é um subschema válido. O documento, portanto, não passa na validação contra o próprio meta-schema do Draft 2020-12.

Impacto. Um validador conforme valida o schema contra o meta-schema ao carregá-lo; com essa construção inválida, o schema é recusado antes de chegar à validação de documentos.

Proposta. Mover o allOf para o nível de schema correto e incluir a validação contra o meta-schema no pipeline de publicação, que detecta esse tipo de construção automaticamente.

14. Anexo VIII embute o Anexo VII — Baixa

Evidência. O DocumentoCertidaoSituacaoJuridicaImovel (VIII) contém o DocumentoSituacaoJuridicaImovel (VII) embutido por cópia como subcampo, em vez de referenciá-lo por $ref.

Impacto. Versionar a Situação Jurídica exige reeditar a Certidão; risco de divergência entre as duas cópias.

Proposta. A Certidão (VIII) deve referenciar o documento da Situação Jurídica (VII) por $ref, mantendo uma única fonte da verdade.

Sugestões de processo (transversais)

Vários achados compartilham uma causa comum e poderiam ser detectados de forma automática antes da publicação dos schemas. As sugestões a seguir vão nessa direção e podem ser incorporadas ao fluxo já existente:

1. Validação automatizada dos schemas na etapa de publicação:
   • resolução de todos os $ref (sem órfãos; case-sensitive);
   • $schema/dialeto e host/protocolo padronizados;
   • validação cruzada em ≥2 bibliotecas conformes;
   • validação dos exemplos preenchidos (golden) de cada anexo contra o schema.
2. Pacote de distribuição auto-contido por anexo + manifesto $id → arquivo.
3. Namespace canônico único para listas compartilhadas (anti-drift).
4. Versionamento semântico de schemas e listas, com changelog.
5. Tabela de equivalência ONR ↔ SREI para domínios compartilhados.

Priorização sugerida

• Curto prazo (correções pontuais): achados 1 (lista ausente), 4 (host), 5 ($schema), 9 (typo), 12 (regex) e 13 (allOf). São correções de baixo esforço que já desbloqueiam a compilação por validadores conformes.
• Médio prazo (consistência): achados 3 (canônico), 6 (números), 7 (booleano), 11 (equivalência ONR), além da validação automatizada.
• Longo prazo (arquitetura): achados 8 (Município por código IBGE), 14 (VIII por $ref), 10 (compatibilidade multi-lib).

Conclusão

O SREI só cumpre seu propósito quando uma matrícula gerada em um cartório é lida, validada e processada sem ambiguidade em qualquer outro ponto da rede: outro cartório, o ONR, o Judiciário ou um sistema de mercado. Em cada um dos 14 achados acima, essa garantia hoje depende de contornos individuais de cada implementador, e não de uma especificação testável e auto-contida.

A maior parte é corrigível com baixo esforço. Vários deles (referências órfãs, dialeto malformado, host inconsistente, typos em $ref, regex inválida, allOf malformado) poderiam ser detectados automaticamente por uma etapa de validação na publicação dos schemas, antes de chegarem a quem implementa.

Os achados foram documentados pela equipe de engenharia da Mupi Systems e publicados de forma aberta, para que possam ser verificados, contestados ou incorporados por quem mantém a especificação. É uma contribuição técnica ao SREI: um padrão mais sólido reduz o custo de adoção e aumenta a confiabilidade do registro eletrônico brasileiro.

Críticas, correções e dúvidas sobre qualquer um dos achados são bem-vindas em suporte@mupisystems.com.br.

Todos os achados deste artigo são reproduzíveis a partir dos arquivos de schema publicados no pacote ITN-04 v1.1 (27/05/2026, conferido pelo campo x-version de cada schema), com base em implementação de referência dos Anexos III, IV, V, VII e VIII.