AlpOS

AlpOS is the platform layer. Ingestion, ontology, analytics, AI copilot, and workflow engine in one installable system, deployed inside the institution’s perimeter.

What it is

AlpOS unifies the five layers an institution needs to make decisions defensibly:

1. Ingest — connectors for the systems the institution actually runs: core banking, SCADA, MES, EHR, content stores, unstructured archives. Ingestion is observable, policy-aware, and rebuildable from source.
2. Ontology — the governed object model decisions resolve against. See Ontology.
3. Analytics and AI — SQL, search, RAG over the ontology, and an in-perimeter copilot. Every output cites its sources.
4. Decisioning — propose / approve workflows with signed audit trails. See Governance model.
5. Action — pre-built integrations into the operator’s existing ticketing, identity, and case-management stack.

The five layers ship as one platform image with a single update channel. AlpOS is not a constellation of micro-products that the customer integrates; it is one system the customer deploys.

Status

AlpOS 1.0 is generally available. The five-layer architecture is shipping. Specific capability depth — for example, the geospatial and video-understanding modules — is on a published roadmap.

What ships in the 1.0 image

• Ingest engine with the connector library
• Ontology engine with sector-specific starter templates
• Analytics layer (SQL, faceted search, RAG, translation)
• Workflow engine with signed approvals
• Action library with ticketing / identity / SIEM integrations
• Operator console and admin console
• Customer-managed encryption with external KMS support
• All four deployment postures supported by the same image

What it is not

AlpOS is not a hosted SaaS product, and it is not a model. It is the operating layer the institution runs. The models it consumes are open weights or partner closed-weights deployed inside the perimeter — Davion does not require routing inference to a vendor service.

It is also not a low-code application builder. Operators who want to assemble dashboards and workflows do so against the ontology, not against a builder UI; the ontology is the single source of truth that keeps applications consistent over time.

When to choose AlpOS

When the institution’s problem is “we need to make operational decisions on data that cannot leave our perimeter, defensibly, and within months not quarters.” If the problem is narrower — for example, only classifying what is safe to feed into a third-party copilot — DAIMO is the more focused fit.