The platform

Legal sources, reasoning services and a caseworker UI, in three layers.

{{product.name}} is a set of open-source services for planning and approval procedures. Each service runs on its own, and the bundled UI is one way to use them.

A procedure with {{product.name}}

An applicant's documents arrive. {{product.name}} parses them, reads scanned pages and indexes every section for search.

How it is built

Each layer can be used without the one above it.

The UI calls the services, the services read the graph and the data stores, and the graph is built from official legislation. Select a layer to see what it holds.

{{product.name}} architecture. A caseworker UI of seven modules sits on standalone services for document intake, norm matching, legal reasoning, decision drafting, AI governance and workflow. The services share data stores, and reach a LiteLLM gateway and official legislation sources outside the cluster. Caseworker UI 1 Case ReviewProcedure PortalReport PortalAdmin DecisionObjectionsObjection SubmissionComment PortalShell and login Served from one origin. Optional: every module calls a REST API. Services 2 Document intakeOCR, chunks, searchNorm matchingCitations, graph, vectorsLegal reasoningSubsumption, risk noticesDecision draftingDraft, render to PDFAI governanceExplain, feedback, testsWorkflowDeadlines, requests, comments FastAPI, one Helm release each. Model calls go through the gateway. PostgreSQL, Neo4j graph, Qdrant, RabbitMQ, MinIO 3 Outside the cluster 4 LiteLLM gatewayNeuRISgesetze-im-internetlegislation.gov.ukLégifrance (PISTE)XÖV messages Model calls and legislation fetches are the only traffic that leaves.
    • A shell loads seven modules, each in its own frame, all served from one origin.
    • Built with React, TypeScript and IBM Carbon, with Keycloak login over OIDC.
    • English only today. German and French are on the roadmap, with English as the default.
    • 23 deployable FastAPI services, each with its own Dockerfile, Helm chart and REST API.
    • Every model call goes to a LiteLLM gateway by alias. No model is trained in house.
    • Most services that call an LLM screen their inputs for prompt injection.
    • A few services verify the login token today; the rest are kept off the network edge. Authentication on every backend is on the roadmap.
    • Neo4j holds the legal knowledge graph, behind its own graph API.
    • Qdrant stores document vectors, and PostgreSQL holds each service's own database.
    • RabbitMQ carries asynchronous work, and MinIO stores uploaded files.
    • German law from NeuRIS and gesetze-im-internet, and UK law from legislation.gov.uk.
    • French law from Légifrance through the PISTE API. Extraction for France is on the roadmap.
    • One LiteLLM gateway serves the chat and embedding models.
Ways to deploy

It runs on Kubernetes with Helm today.

So far {{product.name}} has been deployed to a development environment on Azure Kubernetes Service. Staging and production workflows are defined but have not run, and other hosting has not been tested.

Live in dev

The full stack on Azure Kubernetes Service.

What you get
Every service, the caseworker UI and the data stores, deployed with Helm.
How it is built
Terraform and Terragrunt for the infrastructure, and GitHub Actions with Azure OIDC for builds and deploys.
Status
Running in a development environment. Staging and production are defined but have never run.
Standalone services

Only the services you need, inside your own platform.

What you get
Individual services with REST APIs, each with its own Dockerfile and Helm chart.
Fits when
You already have a case system and want document intake, norm matching or the knowledge graph behind it.
Status
The services are designed for this. So far they have only been deployed together, in the development environment.
Untested

Another Kubernetes cluster, or your own data centre.

What changes
The infrastructure code targets Azure, and Helm values exist only for the development environment.
Model access
The services need a LiteLLM gateway. Which models sit behind it is your choice.
Status
[Replace: supported hosting options, once one has been tested.]

Six principles shape how {{product.name}} is built.

They come from the code and the team's own engineering guidance. Where one is not fully met yet, we say so.

Services stand alone.

Each backend has its own project, Dockerfile and Helm chart, and can be used without the UI.

The model is swappable.

Services name models by gateway alias, so changing a model is a gateway change, not a code change. Two settings still bypass the gateway today.

Only parsing is per jurisdiction.

Fetching and parsing legislation differ by country. The graph model, extraction and storage are shared, so a new country needs a parser and a registry entry, not a fork.

People review the AI.

Every AI step is meant to be explainable and reviewable by a caseworker. Explainability and feedback services, in development, support that.

Inputs are screened.

Most services that call an LLM pass inputs through a prompt-injection check, based on OWASP LLM01, before they reach the model.

Events are logged for audit.

Business events go through bizlog, a structured audit-logging library. Durable storage for the audit trail is in progress.

See {{product.name}} on your own work.

Book a walkthrough with the team. We show you the services that fit your procedures, and what is still on the roadmap.