Architecture

Silo is composed of functional components with clear responsibilities. The Interface is the frontend hub; the Core Engine is the central jurisprudence and reasoning backend; Legislative Resolution handles document-first legislative grounding; and the Doctrine Pipeline supplies internal doctrinal artifacts. The diagrams below summarize that split.

Silo Overview

The frontend and LLM agents enter through different surfaces, but the canonical backend remains the Core Engine. Legislative Resolution and the Doctrine Pipeline feed that backend with specialized grounding rather than competing to be the frontend or the central legal backend.

The diagram below is a boundary and ownership view. The data stores on the right belong to Silo, while Legislative Resolution and the Doctrine Pipeline remain upstream providers with their own runtimes and data pipelines. They contribute through ingestion and grounding contracts instead of coupling directly to the internal storage layer.

REST and MCP are parallel entry surfaces into the same Core Engine service layer. They differ in client protocol, not in system ownership: both can reach the same orchestration, retrieval, verification, and reasoning capabilities underneath.

graph TB
    subgraph Interfaces
        USERS[Lawyers and teams]
        AGENTS[LLMs and agents]
    end

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

    subgraph "Core Engine"
        API[REST API]
        MCP[MCP]
        AUTH[OAuth 2.0 + PKCE]
        ORCH[Service layer<br/>routing and orchestration]
        CHAT[Chat pipeline<br/>draft, critics, revision]
        INGEST[Grounding adapters<br/>ingestion and handoff]
        RETRIEVAL[Graph-led retrieval]
        REASONING[Verification + reasoning]
    end

    subgraph "Internal providers"
        LECI[Legislative Resolution<br/>document-first legislation<br/>own runtime and storage]
        DOUTO[Doctrine Pipeline<br/>doctrinal artifacts<br/>local pipeline and corpus]
    end

    subgraph "Silo stores"
        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

Search Pipeline

The Core Engine follows a graph-led architecture: the legal graph becomes the primary discovery path, while lexical and semantic search run in parallel to expand coverage and provide graceful degradation. The final answer may include verification, additional grounding, and a reasoning chain.

flowchart LR
    Q[Legal question] --> ENTRY[Entry into Core Engine]
    ENTRY --> GRAPH[Neo4j traversal + graph retrieval<br/>primary path]
    ENTRY --> SEARCH[Parallel lexical and semantic search<br/>support and fallback]
    GRAPH --> FUSE[Fusion and calibration]
    SEARCH --> FUSE
    FUSE --> GROUND[Grounding and verification<br/>Legislative Resolution and Doctrine Pipeline when needed]
    GROUND --> EXPLAIN[Traceable reasoning chain]
    EXPLAIN --> RESULT[REST or MCP response]

Component roles

Component	Role	Main integration
`Core Engine`	Search, verification, reasoning, canonical APIs, multi-tribunal knowledge graph (2.2M decisions), 3-stage LLM chat pipeline, and OAuth 2.0 auth. Neo4j for Startups partner.	REST API (50+ endpoints) + MCP (35+ tools)
`Interface`	User experience, briefing, and canvas	Consumes the Core Engine and, later, Legislative Resolution
`Legislative Resolution`	Document-first legislation and reliable grounding	Supplies statutes and provisions to consumers
`Doctrine Pipeline`	Local doctrine pipeline and internal artifacts	Controlled handoff into the Core Engine

Silo data layer

PostgreSQL for documents, metadata, and operational state
Qdrant for semantic vector search
Neo4j Aura for graph-led retrieval, explanation, and legal relationships (Neo4j for Startups program)
Redis for cache and operational controls

View the canonical architecture docs →