Arquitetura

O Silo e composto por componentes funcionais com responsabilidades claras. A Interface e o hub frontend; o Motor e o backend central de jurisprudencia e reasoning; a Resolucao Legislativa cuida do grounding legislativo document-first; e o Pipeline de Doutrina fornece artefatos doutrinarios internos. Os diagramas abaixo resumem essa divisao.

Visao Geral do Silo

O frontend e os agentes entram por superficies diferentes, mas a camada canonica de backend fica no Motor. A Resolucao Legislativa e o Pipeline de Doutrina alimentam esse backend com grounding especializado, sem disputar o papel de frontend ou de backend juridico central.

O diagrama abaixo e uma visao de fronteiras e ownership. Os bancos a direita pertencem ao Silo, enquanto a Resolucao Legislativa e o Pipeline de Doutrina continuam como fornecedores upstream com runtimes e pipelines de dados proprios. Eles entram por contratos de ingestao e grounding, em vez de acoplarem diretamente a camada interna de storage.

REST e MCP sao superficies paralelas de entrada para a mesma camada de servico do Motor. O protocolo do cliente muda, mas o ownership do sistema nao: os dois alcancam a mesma orquestracao, retrieval, verificacao e reasoning por baixo.

graph TB
    subgraph Interfaces
        USERS[Advogados e times]
        AGENTS[LLMs e agentes]
    end

    subgraph "Interface"
        JUCA[Frontend hub<br/>briefing, canvas, leitura]
    end

    subgraph "Motor"
        API[REST API]
        MCP[MCP]
        AUTH[OAuth 2.0 + PKCE]
        ORCH[Camada de servico<br/>roteamento e orquestracao]
        CHAT[Chat pipeline<br/>draft, criticos, revisao]
        INGEST[Adaptadores de grounding<br/>ingestao e handoff]
        RETRIEVAL[Graph-led retrieval]
        REASONING[Verificacao + reasoning]
    end

    subgraph "Fornecedores internos"
        LECI[Resolucao Legislativa<br/>legislacao document-first<br/>runtime e storage proprios]
        DOUTO[Pipeline de Doutrina<br/>artefatos doutrinarios<br/>pipeline local e corpus proprio]
    end

    subgraph "Stores do Silo"
        PG[(PostgreSQL)]
        QD[(Qdrant)]
        N4J[(Neo4j)]
        RD[(Redis)]
    end

    USERS --> JUCA
    AGENTS --> MCP
    JUCA --> API
    API --> AUTH --> ORCH
    MCP --> AUTH
    ORCH --> CHAT
    ORCH --> INGEST
    ORCH --> RETRIEVAL
    ORCH --> REASONING
    LECI --> INGEST
    DOUTO --> INGEST
    INGEST --> PG
    INGEST --> QD
    INGEST --> N4J
    RETRIEVAL --> PG & QD & N4J & RD
    REASONING --> PG & N4J

Pipeline de Busca

A arquitetura atual do Motor e graph-led: o grafo juridico virou caminho primario de descoberta, enquanto busca lexical e semantica rodam em paralelo para complementar resultados e garantir degradacao graciosa. A resposta final pode incluir verificacao, grounding adicional e reasoning chain.

flowchart LR
    Q[Pergunta juridica] --> ENTRY[Entrada no Motor]
    ENTRY --> GRAPH[Neo4j traversal + graph retrieval<br/>path primario]
    ENTRY --> SEARCH[Busca lexical e semantica paralela<br/>complemento e fallback]
    GRAPH --> FUSE[Fusao e calibracao]
    SEARCH --> FUSE
    FUSE --> GROUND[Grounding e verificacao<br/>Resolucao Legislativa e Pipeline de Doutrina quando aplicavel]
    GROUND --> EXPLAIN[Reasoning chain rastreavel]
    EXPLAIN --> RESULT[Resposta via REST ou MCP]

Papeis por componente

Camada de dados do Silo

• PostgreSQL para documentos, metadados e estado operacional
• Qdrant para busca semantica vetorial
• Neo4j Aura para retrieval graph-led, explicabilidade e relacoes juridicas (programa Neo4j for Startups)
• Redis para cache e controle operacional

Ver a documentacao canonica de arquitetura →