Tudo o que respondemos numa RFP, com a prova ao lado.

Descoberta automática e perfil de cada tabela em mais de 15 tipos de fonte — warehouses, bases operacionais, SaaS, ficheiros, documentos e streaming (Kafka e Pub/Sub, ainda por instalar no SaaS). Contagens, nulos, distintos, estatísticas, distribuições e amostras limitadas, com perfil incremental em tabelas grandes.

Monitores automáticos de atualidade, volume e schema em todas as tabelas da conexão (até 500 por conexão), a partir dos metadados do catálogo e sem configuração; drift e anomalias; motor de regras; SLO por dataset. Alertas em email, Slack, Teams e webhook, com escalas de piquete e um âmbito por canal (domínios, conexões, datasets, tipos de problema).

Tipos semânticos detetados automaticamente (email, NIF, IBAN, código postal, telefone, datas, montantes, nomes, moradas) com regras de validação sugeridas. Telefones, códigos postais, NIF, IBAN e datas em formatos mistos passam à forma canónica. Campos compostos são decompostos por regras de locale PT, ES e EN: moradas (rua, número, andar, código postal, localidade, país), nomes (título, nome, apelidos), telefones com indicativo, NIF e nome na mesma coluna, datas em texto livre e montantes com moeda. Cada coluna mostra a taxa de sucesso na amostra e os formatos que falham. A normalização é proposta em SQL no dialeto da fonte e em PySpark, só de leitura, e aplicada pelo seu processo, também por pull request. Nunca escrevemos nas fontes.

Duplicados exatos e aproximados dentro de cada dataset e correspondência entre dois datasets, também de fontes diferentes, como o CRM e o ERP. As regras de correspondência configuram-se por campo: comparador (exato, normalizado, Jaro–Winkler, por palavras, numérico com tolerância ou data com janela), peso e semelhança mínima, com blocking e um limiar de correspondência e outro de revisão. Os clusters entre os dois datasets reveem-se na interface (fundir, ignorar ou repor), e a decisão fica no DataVault, no trilho de auditoria, e vale nas execuções seguintes. As regras de sobrevivência por campo (fonte prioritária, mais recente, mais completo ou mais frequente) dão um registo consolidado proposto, com a origem de cada campo, em SQL e PySpark só de leitura, que pode seguir por pull request para o processo do cliente aprovar. Num benchmark sintético rotulado, as regras sugeridas dão precisão 1,0 e recall 0,85 em 10 000 linhas. Nunca escrevemos nas fontes.

Limpeza com intervenção humana: propomos a correção — SQL e PySpark gerados, com poupança estimada e risco analisado —, abrimos um pull request no repositório do cliente e uma pessoa aprova a aplicação, num fluxo governado (proposto, aceite, aplicado, verificado no scan seguinte). Nunca escrevemos nas fontes sem essa aprovação.

Porquê: Propomos SQL/PySpark e PR no repositório; nunca escrevemos na fonte. Pedir credenciais de escrita seria a primeira objeção da sua equipa de segurança.

Propomos valores a partir de fontes de referência, cada um com a fonte, a data da consulta e a confiança: a localidade, o concelho e o distrito pelo código postal português (GeoAPI.pt, com dados dos CTT e do INE), a localidade pelo código postal espanhol (Nominatim do OpenStreetMap, que recebe só o código postal), as coordenadas pela morada (na sua própria instância Nominatim, a única que recebe moradas), o nome e a morada registados de uma empresa pelo NIF de pessoa coletiva (VIES da Comissão Europeia) e os códigos ISO de país e de moeda (listas locais). Cada proposta dá a cobertura na amostra e sai em SQL no dialeto da fonte e em PySpark: uma contagem só de leitura e um UPDATE proposto, ou um SELECT com os valores propostos, que o seu processo aplica por pull request ou SQL depois de aprovar a sugestão. Cada fornecedor externo recebe só o campo a enriquecer, depois de um administrador o autorizar no workspace; a sua instância Nominatim autoriza-se com o URL e com uma confirmação própria de dados pessoais. Nunca escrevemos nas fontes.

Catálogo automático com domínios; linhagem por chaves estrangeiras, SQL das views ao nível da coluna, manifest do dbt e OpenLineage; sensibilidade por coluna e README por dataset aprovado por um humano. Glossário de negócio nativo: termos com definição, sinónimos, owner, domínio e estado (rascunho, aprovado ou depreciado), ligados a colunas e datasets. As ligações sugeridas pelo nome, pelos sinónimos, pelo tipo semântico e pelas descrições do dbt nascem sempre como proposta, e só uma pessoa as aprova. Cada dataset pode ter owner (herdado do domínio quando está vazio) e steward, e tags por dataset e por coluna, livres ou de uma lista controlada do workspace. As alterações de owner, steward e tags, a sensibilidade posta à mão, as ligações de termos a colunas e as edições dos termos ficam no histórico (o quê, quem, quando, antes e depois), com diff entre duas datas. O histórico começa na versão que o introduziu: as alterações anteriores não foram convertidas, e a criação de termos, as sugestões automáticas e o que o datavault.yaml aplica ainda não entram. O dicionário de dados exporta-se por dataset, domínio ou workspace em CSV, JSON e Markdown, com descrições, tipos, sensibilidade, termos, tags, owner, steward, regras e SLA. Também se exporta em ficheiros para carregar no OpenMetadata (um pedido de criação de tabela por dataset; o owner, o SLA e as regras vão à parte, porque o pedido não os aceita) e no DataHub (MCPs para o datahub ingest). É um ficheiro para o seu processo carregar: não o enviamos. A pesquisa transversal encontra datasets, colunas, termos, tags e owners e respeita os domínios restritos. O owner, as tags, o histórico, o dicionário e a pesquisa usam-se pela API: ainda não têm página na app. Os veredictos de qualidade publicam-se no OpenMetadata, no DataHub e no Collibra (Import API v2, validado com transporte simulado; validação em tenant do cliente pendente).

Webhook do dbt Cloud e pacote Airflow com gate de qualidade; gate de regras e data-diff em CI; servidor MCP para agentes; configuração do workspace como código; fluxo de problemas com responsáveis, escalas e agendamentos. Validação no ponto de entrada, só de leitura: o integrador ou a pipeline mandam até 5 000 registos por pedido à API antes de os escrever e recebem o veredito de cada um com as regras que o DataVault já monitoriza no dataset (campos obrigatórios, padrões, intervalos, NIF, NISS e IBAN com dígito de controlo, listas de referência ISO e do workspace), o código do motivo de cada falha e o veredito do lote. Nada é guardado nem enviado a um LLM e a fonte não é lida: rejeitar ou pôr em quarentena fica do lado do cliente. As regras que medem o dataset inteiro (unicidade, atualidade, volume) vêm marcadas como não aplicáveis.

Relatórios por perfil (engenharia, gestão, executivo) com impacto em euros, em PDF, agendáveis e partilháveis; assistente em linguagem natural; primeiro scan ao vivo; interface em português, inglês e espanhol.