> ## Documentation Index
> Fetch the complete documentation index at: https://strattumai.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Data Catalog
> Data lake on-premise na infraestrutura do cliente. Organizado, governado e descobrível. Base para Memory, Knowledge e Skills.
O **Data Catalog** é o repositório de dados armazenado diretamente na infraestrutura cloud do próprio cliente — AWS S3, Google Cloud Storage ou Azure Blob Storage. Ele documenta, classifica e estabelece ownership sobre todos os datasets ingeridos pelos Data Pipelines.
Não é apenas um índice de metadados — é um data lake real, projetado para times de 1 a 5 pessoas. Os dados nunca saem do ambiente do cliente: sem vendor lock-in, sem dados em terceiros.
***
## Por que isso importa
O diferencial crítico do Data Catalog é que **os dados ficam on-premise na infra cloud do cliente**. Isso é determinante para fintechs, healthtechs e cooperativas de crédito com exigências regulatórias de localização de dados (LGPD, Bacen).
Comparado a alternativas como Databricks:
* Não exige clusters gerenciados por terceiros
* O query engine (DuckDB) roda embutido — sem custo de compute separado
* Operável por times de 1–5 pessoas sem especialista em Spark
***
## Conectar um data lake existente ou construir do zero
A Strattum se adapta à maturidade de dados da empresa. Há dois pontos de partida:
| Cenário | Como funciona |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **A empresa já tem data lake** | A Strattum opera sobre o Databricks, Snowflake, BigQuery ou Redshift existente. Sem migração, sem duplicar o dado, sem reescrever pipelines que já rodam. |
| **A empresa ainda não tem** | A Strattum entrega o Delta Lake na nuvem do cliente (AWS, Azure, GCP, OCI), com ingestão, transformação e catálogo prontos para alimentar Memory e agentes. |
Nos dois casos o dado permanece no ambiente do cliente e o catálogo — descrição, ownership, linhagem e políticas de acesso — é o mesmo.
***
## Estrutura de camadas (Medallion)
O Catalog organiza os dados em três camadas lógicas:
Dados imutáveis, exatamente como chegaram da fonte. Sem transformação. Serve para auditoria e reprocessamento histórico. Nunca é modificado após a carga inicial.
Dados normalizados, deduplicados e com chaves padronizadas (CPF, CNPJ, email). É o tronco principal que alimenta Memory (grafos), Knowledge (vetores) e as Skills (queries SQL).
Data marts pré-agregados via dbt (opcional). Consultas analíticas pré-construídas consumidas pelas Skills — ex: `fct_receita_por_cliente`, `fct_health_score`. Use quando precisar de métricas calculadas com performance.
### Quando usar cada camada
| Caso de uso | Camada |
| -------------------------------------- | ----------- |
| Auditoria de dados originais | `raw/` |
| Contexto de entidades para Memory | `clean/` |
| Indexação de documentos para Knowledge | `clean/` |
| Métricas calculadas para Skills | `semantic/` |
| Reprocessamento histórico | `raw/` |
***
## Tecnologias de armazenamento e consulta
| Componente | Tecnologia | Função |
| ----------------- | ---------------------------------- | ---------------------------------------------------------------- |
| **Armazenamento** | S3 / GCS / Azure Blob (do cliente) | Object storage do próprio cliente |
| **Formato** | Parquet + Delta Lake | ACID transactions, versionamento e schema evolution |
| **Query Engine** | DuckDB (embutido) | SQL analítico ultrarrápido direto nos arquivos — sem clusters |
| **Metadados** | PostgreSQL interno | Catálogo de datasets: descrição, owner, linhagem, schema history |
O uso do **DuckDB** é o diferencial técnico crítico: performance analítica com zero complexidade de infraestrutura, sem precisar de Spark, Databricks ou qualquer cluster externo.
***
## Navegando pelo Catalog no Console
Acesse **Data Catalog** no menu lateral para ver todos os datasets disponíveis:
A tela inicial lista todos os datasets por categoria (CRM, ERP, Helpdesk, etc.) com status de saúde, timestamp do último sync e owner.
Clique em qualquer dataset para ver:
* Schema completo (colunas, tipos, exemplos de valores)
* Linhagem: de qual conector veio e quais transformações foram aplicadas
* Histórico de sincronizações
* Políticas de acesso configuradas
Clique na aba **Clean** para ver os dados normalizados prontos para consumo. Você pode executar queries SQL diretamente via DuckDB no Console.
O gráfico de linhagem mostra o caminho completo do dado: fonte original → pipeline de ingestão → transformação dbt → dataset final.
***
## Governança e metadados
Cada dataset registrado no Catalog é um ativo de dados governado:
| Atributo | Descrição |
| ------------------------------ | ------------------------------------------------------------------------- |
| **Nome e descrição** | Nome legível e descrição em linguagem natural |
| **Owner** | Email do responsável técnico pelo dataset |
| **Linhagem** | Quais conectores originaram o dado e quais transformações foram aplicadas |
| **Políticas de acesso** | YAMLs versionados em Git que definem permissões por serviço e papel |
| **Monitoramento de qualidade** | Completude, frescor, consistência e unicidade |
### Campos PII e controle de acesso
Campos com dados pessoais (CPF, email, telefone) podem ser configurados para serem visíveis apenas para papéis autorizados. Analistas sem permissão veem os valores mascarados automaticamente.
***
## Transformations (dbt)
As Transformations permitem criar a camada `semantic/` com data marts pré-calculados. São definidas em SQL via dbt e versionadas no Workspace Git.
Para configurar uma Transformation, é necessário ter pelo menos um conector ativo. Acesse **Data Catalog → Transformations** para criar e gerenciar transformações.
Casos de uso típicos:
* `fct_health_score` — score de saúde por conta calculado de uso + tickets + NPS
* `fct_inadimplencia` — status de inadimplência por tomador
* `dim_clientes_clean` — clientes normalizados com chaves padronizadas
***
## Integrações com outros produtos
| Produto | Como o Data Catalog se conecta |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| **Data Pipelines** | Pipelines alimentam o Catalog — cada dataset ingerido é registrado automaticamente com linhagem |
| **Memory** | O Memory Worker lê tabelas normalizadas do `clean/` para extrair entidades e construir o grafo |
| **Knowledge** | Textos de documentos são parseados e salvos em `clean/`. O Knowledge Worker lê dali para gerar chunks |
| **Skills** | Scripts executados por agentes consultam data marts do `semantic/` e tabelas do `clean/` via DuckDB para métricas exatas |
| **Evals** | Métricas de qualidade dos datasets (completude, frescor) alimentam a avaliação de contexto |
| **Observability** | Monitora saúde dos datasets: fontes desatualizadas, campos faltando, schemas quebrados |
***
## Exemplos de uso
Uma fintech conecta seu sistema de originação (PostgreSQL), CRM (HubSpot) e plataforma de cobrança via Data Pipelines. O Catalog organiza tudo em `clean/dim_clientes`, `clean/fct_contratos` e `clean/fct_pagamentos`. O Memory Worker lê essas tabelas para montar o perfil unificado do tomador — sem que o analista precise consultar três sistemas diferentes.
O time de produto cria um data mart `semantic/fct_health_score` via dbt, consolidando dados de uso do produto, tickets e NPS por conta. Uma Skill consulta esse mart via SQL para investigar quais contas estão com score degradado e cruzar com o histórico de interações da Memory.
Uma cooperativa precisa demonstrar para auditoria que dados de associados são acessados apenas por serviços autorizados. O Catalog registra cada consulta (audit trail), aplica políticas de row-level security e garante que campos PII são filtrados automaticamente para papéis sem permissão.