ORION IMPACT
Orion Core · Architecture

The architecture behind Orion Core.

Orion Core is a product developed by Orion Impact to compose and operate AI capabilities across explicit boundaries. Its local-first architecture separates contracts, orchestration, provider integration, and execution control so the system can evolve without being tied to a single model, service, or deployment topology.

The Core already has an operational runtime, ingestion, retrieval, RAG, conversational memory, observability, and replaceable capability composition. It is in pre-release: some foundations are consolidated, while retrieval and RAG remain under active evolution.

ORION CORE
Pre-release
Current version
0.1.0
Architecture
Local-first · Ports & Adapters
License
Apache-2.0
01 — What it is

Local-first operational infrastructure.

Orion Core is an infrastructure product in pre-release, not an end-user application or a vertical. It separates contracts, use-case orchestration, provider integration, and execution control across explicit boundaries. User experience belongs to a different layer. The Core already exposes an HTTP transport API today, while its technical surface continues to evolve.

02 — Architecture

One architecture, two different flows.

Dependency direction protects the nucleus from external details. The execution path shows how an intention enters through transport and reaches a concrete capability. The two flows are not the same thing.

Dependency

Who is allowed to know whom.

Infrastructure → Adapters → Application → Core. That direction is the project’s official boundary and is already enforced by dependency gates in the code.

  1. Infrastructure Composition · Capability Registry · Runtime implementation · Configuration · Lifecycle

    Builds and wires concrete implementations, runs bootstrap, and keeps the operational machinery. Composition lives here: DIContainer, UseCaseFactory, plugin bootstrap, and the capability registry.

  2. Adapters LLM · Embeddings · Vector Store · Retrieval · Reranker · Memory · Ingestion

    Implement Ports and translate concrete technologies into Core contracts.

  3. Application Use Cases · Commands · Policies · DTOs

    Declares intent and orchestrates use cases exclusively through Core contracts. It does not select a provider.

  4. Core Contracts · Ports · Domain · Runtime contracts

    The protected center. It defines the fundamental contracts and operational models without depending on frameworks, databases, or providers.

Outside the internal boundaries

Providers are replaceable details.

  • LLM providers
  • Embedding services
  • Vector stores
  • Rerankers
  • Persistence backends
  • Telemetry

They are not part of the Core’s architectural identity. They enter through an Adapter, behind a Port, and can be swapped without rewriting the nucleus.

03 — Execution

How an intention becomes execution.

Work crosses the system on a different axis. The Execution Runtime is not a step between Adapter and Provider: it wraps the operation.

  1. HTTP Request

    An intention arrives at the transport edge.

  2. Transport

    Validates the request, builds the command, and returns the serialized response.

  3. Command / Use Case

    Application declares what should happen and under which policies.

  4. Core Port

    The stable contract through which intent leaves the nucleus.

  5. Adapter

    Translates the contract into a concrete technology.

  6. Provider / Store

    The external capability or persistence backend that executes the detail.

04 — Execution Runtime

Intent and execution are different responsibilities.

Application declares what the system should do. The Runtime contract lives in Core; the concrete implementation lives in Infrastructure. Adapters should not reinvent retry, timeout, and concurrency — the Runtime is the authority for those policies.

That separates the business decision from operational control. A use case can request durable work; the Runtime decides how that work survives failure, waiting, cancellation, and resource limits.

Execution policies

Retry · timeout · cancellation

Durable work

Jobs · queues · leases

Workers

Concurrent execution

Scheduling

Delayed and recurring work

Recovery

Reconciliation · checkpoints

Operational control

Backpressure · resource limits

Signals

Events · audit trail · tracing

05 — Capability System

Providers are resolved capabilities, not fixed dependencies.

Plugins declare capabilities. The Capability Registry is the selection authority. Composition builds and injects. Application does not choose the provider; the provider does not become the Core’s identity.

  1. Plugin registration

    An implementation declares itself as an available capability.

  2. Capability Registry

    Centralizes selection. Health and priority inform the policy; the fine-grained algorithm stays in the technical documentation.

  3. Selection

    A concrete capability is chosen without leaking that decision into the nucleus.

  4. DIContainer

    Infrastructure composes and injects the chosen implementation.

  5. Port / Adapter

    The rest of the system keeps speaking to a contract, not to a vendor.

06 — Cognitive capabilities

What the Core already runs.

The paths exist. Retrieval and RAG quality remain under evolution and evaluation.

Ingestion

Available

Document sources · Eligibility · Processing · Chunking · Embeddings · Indexing · Jobs / backpressure

Retrieval & RAG

Evolving

Semantic retrieval · Hybrid path · Reranking · Query context · Answerability · Context assembly · Evidence return. The flow includes optional contextualization, generation, and memory recording. It works; it is not finished.

Conversation Memory

Available

MemoryPort · ConversationStorePort · session scope · in-memory · SQLite/WAL. The conversational backend can already be durable.

Observability

Available

Metrics · Correlation · Tracing · Audit · Runtime events. There is an operational signal; that does not promise a perfect reconstruction of everything.

  • IngestionAvailable
  • RuntimeAvailable
  • MemoryAvailable
  • Retrieval / RAGEvolving
  • IdentityNext

See the full Development status →

07 — Limits

What Orion Core is not yet.

It is not an end-user application.

The Core exposes a technical API; user experience belongs to another layer.

Identity is not complete.

The boundary is planned and marked as Next. It is not presented as existing.

Retrieval and RAG are not finished.

They work, but remain Evolving. They are not state of the art, and this is not “advanced RAG”.

It is not a closed distribution around one provider.

Providers remain replaceable. It is not a vertical either: specialized applications belong to future layers.

08 — Principles in engineering

Principles turned into architecture.

Local-firstOperation without a mandatory external provider.
Provider neutralityPorts + Adapters + Capability Registry.
AuditabilityCorrelation + tracing + events + audit.
Long-term portabilityReplaceable contracts and providers.

These engineering commitments derive from Orion Impact’s institutional principles.

See the full Principles →

09 — Continue

Architecture explains how. The Manifest explains why.

Explore the thesis behind this architecture in the Manifest, or follow Development for a verifiable view of what exists today and where the product is heading.

Read the Manifest Follow Development