Your data stays local
Queue, index, content representation, and generation all run inside the client’s infrastructure. Nothing sensitive has to leave the environment.
ORION Core · Architecture
The architecture behind Orion Core.
Orion Core is the AI engine that runs inside the organization’s own infrastructure: it takes in documents, understands questions, and answers from them — without sensitive data ever leaving the client’s environment.
This page shows the architecture from the inside and, layer by layer, what already works today. The core is functional in a test environment; the interface is the next step.
Functional core in a test environment · TRL 4
Today the core is exercised by automated code tests, still without an end-user interface. Throughout this page, what is built and what is the next step are marked.
What it guarantees
Engineering that becomes a guarantee.
Before the architecture from the inside, what it means in practice for those who use it.
Nothing is lost on failure
Every step has recorded state and can be resumed, reprocessed, or replayed. A mid-way failure becomes a recoverable step, not lost work.
Every answer comes with its sources
The engine returns, alongside the answer, the passages and the source document it used to produce it.
Traceable end to end
Every relevant change is recorded as an event, with a runtime audit trail and metrics. The path from document to answer can be reconstructed.
Layered architecture
From the request at the edge to local data, one layer at a time.
A request enters at the edge and moves inward: validated, decided in the rules core, executed by the runtime, processed by the cognitive pipelines, and served by local-first data. Dependencies point inward — every layer above exists to serve the core.
-
1Edge and intakeFunctional
Where documents and questions arrive. The request is validated and organized before entering — the system’s front door.
-
2Rules and contracts coreFunctional
The heart of the domain: the rules, contracts, and events that define what the system can do — independent of any specific technology.
-
3Runtime and cognitive pipelinesFunctional
The engine that keeps work running: events, queues, failure recovery, and the pipelines that turn documents into answers.
-
4Local-first dataFunctional
Indexes, records, and operational memory kept inside the client’s infrastructure, close to where the data is born.
Models and components connect through swappable adapters: changing a language model or a search mechanism does not require rewriting the core.
Runtime
A persistent runtime, not a system that answers and forgets.
Explicit, recoverable states
Work is modeled with recorded states; if something fails midway, the runtime knows exactly where it stopped.
Why it matters: no ingestion or query is lost because of a crash.
Event model
Every relevant change — a document ingested, a pipeline advancing, a job completed — is recorded as an event.
Why it matters: this is what lets the system reconstruct which document each answer came from.
Persistent jobs and workers
Heavy, long-running work runs in the background, decoupled from any individual request.
Why it matters: processing a large base doesn’t block usage or depend on anyone watching.
From document to answer
How a question becomes an answer with a source.
DocumentControlled intake of files and institutional content.
PreparationExtraction, cleaning, and organization of content into units of meaning.
Search by meaningA representation of the content to locate passages by sense, not just exact words.
Combined searchSemantic and literal search together, with reranking of the most relevant passages.
Context assemblyThe strongest evidence gathered to ground the answer.
Answer with sourceFinal generation that returns the answer alongside the passages and source document.
This is one pipeline among several the runtime can execute — each a sequence of states, events, and recoverable steps.
We’re not trying to build just another AI interface. We’re building the runtime behind it.
Why this order
The core first. The next layers, in the right order.
We built the core first — the hard, invisible part, already functional in tests. From it, the engineering advances in layers, each preparing the next.
-
1Authentication and authorizationNext step
Control over who accesses what. It is the prerequisite for any real use by a client.
-
2Persistent operational memoryAfter that
Memory per session and per client — and it is what brings isolation between clients, each with their own data.
-
3Interface and verticalsThen
The product layer for healthcare, legal, and the public sector — what gives the core a face.
Deferring the interface and verticals was deliberate: a mature foundation avoids rebuilding the base for every new use case.
Next steps
See where the engineering is going — or put the Core to the test.
For the thesis and commitments behind this architecture, see the Manifesto and the Principles.