System overview — v2 (proposed)

Proposed evolution of the current system overview: partner systems get a credentialed, API-key-authenticated route to create and query processes without a browser session, and ai-service grows its own data layer — Qdrant for vector search and MongoDB for document storage — instead of borrowing Postgres. Nothing on this page is built. It's the target shape these two changes are heading toward, kept as one diagram so the two don't get designed in isolation from each other.

The public API is deliberately its own deployable, not a new route bolted onto the backend instance. It's the one surface built to accept credentials from untrusted external parties over the public internet — a fundamentally different trust boundary than the session-authenticated internal API or the MCP server (which is only ever reached by ai-service, a trusted first-party service, over the private network). Keeping it separate follows the same shape already used for ai-service: its own process behind Traefik, its own scaling and rate-limiting, its own deploy/rollback cadence, and a blast radius that stops at its own process instead of extending into session-signing secrets, the JWKS private key, and the full domain layer.

Proposed: a credentialed public Processes API alongside the session-based internal API, and ai-service backed by its own Qdrant + MongoDB data layer.

What's new versus the current system

• Public Processes API, as a separate deployable. Partners reach /api/public/processes at the same Traefik origin, but the request lands on its own process (:8020), not the backend instance. It holds its own API-key secrets, never connects to Postgres, and calls the internal API over the private network with a short-lived, scoped internal token — the same JWT-issuance shape already used for ai-service, so Core still enforces domain logic and tenancy for every request regardless of which surface it came through. See Public Processes API for the full design and open questions.
• ai-service gets its own data layer. Qdrant (vector search, for retrieval over case documents and precedent) and MongoDB (document storage, for the artifacts ai-service produces — drafts, extraction results) sit behind ai-service directly. Postgres stays the backend's — ai-service doesn't get a second path into it beyond the JWKS fetch it already does.

Open questions

• Internal token issuance. Who mints the scoped token the public API presents to Core, and how — a private, network-restricted endpoint on Core (mirroring ForwardAuth), or a shared internal secret? Either way it must be a distinct credential from the session-signing and JWKS keys, so a compromise of the public API can't forge internal or ai-service tokens.
• Network exposure. The public API's own port must only be reachable from Traefik and Core on the private network, never directly from the internet — Traefik stays the only public origin, same as today.
• Qdrant/MongoDB tenancy. Postgres enforces row-level tenancy today; whichever collection/index scheme Qdrant and MongoDB use needs the same per-company isolation guarantee before any real case data reaches them.
• Operational surface. Two new stateful services means two new backup/restore stories, and — unlike Postgres — neither has an existing runbook in this repo.
• Resource naming, scope model, rate limiting and versioning for the public API are tracked in Public Processes API.

Exploration, not a decision. If any part of this graduates from proposed to committed, it should get its own PRD before implementation starts.