Two graphs, one governed answer, portable by design.

Component model

The architecture reads as five layers. A request enters at the access layer, is served by the application layer, draws on the knowledge and AI layers, and is governed throughout. The API is the contract; the user interface is a thin client over it.

A fifth, the AI layer, supplies embeddings, document-type classification, reranking, and generation, plus web search and currency monitoring. Governance is not a layer on top; trust scoring, provenance, the veracity gate, and the warrant are part of the data path, so the substrate is governed by construction.

The two graphs

The substrate runs two distinct graphs, both co-located in the graph store, kept separate because they answer different questions and co-located so one query can use both.

The retrieval graph grounds the words of an answer; the Causal Substrate governs its trust and produces its premise chain. A query touches both: retrieval finds and grounds the passages, the substrate scores the premises and assembles the warrant. The same source feeds both during ingestion. Co-location keeps a single connection seam, one backup and restore path, and one region for residency.

The Corvair Ingestion Pipeline

Bringing a source in, and keeping it current

Triggered on new objects or on a schedule, the Corvair Ingestion Pipeline runs eight stages, batch and idempotent, safe to re-run because writes key off stable ids.

Currency is continuous: watchers detect change at sources; web and intranet discovery find new material; a trickle update applies incremental change without a full rebuild; a retraction invalidates a source and cascades through the dependency graph. Snapshots and a blue/green swap keep the served base stable.

Query and answer

How a question becomes a warranted answer, online and low-latency, over the base the ingestion pipeline has built.

Data stores

Three data tiers plus the warrant log. An export of the graph backup plus the operational store is a complete, movable substrate, and data residency follows the region across all tiers.

Snapshots and versioning are first-class: a base can be sealed into an immutable snapshot, snapshots can be diffed, and a blue/green swap promotes a new snapshot atomically.

The hybrid split

The split between the governed core and the research-and-monitor side is loosely coupled by design, not just as an on-premise special case. The core pushes out a recipe describing what to look for; research-and-monitor agents perform discovery and monitoring in the cloud and stage the files they find; the core pulls those staged files and runs them through its own security scan, veracity gate, and governance before admitting anything.

Deployment topologies

Tenancy is first-class and always present, so the same code base serves one tenant or many. An installation hosts multiple knowledge bases; every route and store is scoped by tenant and knowledge base.

The reference deployment co-locates the graph store, both Cloud Run workloads, the operational store, and the AI calls in a single region, to keep retrieval latency low and residency clear. Where serverless is unavailable, the same containers run on a hosted container platform or Kubernetes equivalent, so on-premise is never blocked. Latency and residency are the trade-offs to manage in a split: co-location minimises latency, separation adds sovereignty.

The Validity Warrant

The warrant is a signed, replayable record of what the substrate knew and how it reached an answer or a decision. One pipeline signs both the knowledge-time warrant (an answer) and the decision-time warrant (an action against a snapshot). The signed payload has five layers: the answer with its confidence; the premise chain with per-item validity and gravity; the causal edges; the source lineage with tier and passage reference; and metadata with recipe version and timestamp. Binding fields make it replayable: recipe version, snapshot id, previous-warrant hash, and a content hash for every cited source.

The signing key is generated in and never leaves Cloud KMS or an HSM; a separate governance-authority identity signs warrants; keys rotate on schedule with old public keys retained so historical warrants still verify. Algorithm agility keeps the path open to post-quantum signatures. The warrant survives right-to-erasure because it holds hashes and salted commitments, not content.

Technology stack

The reference build is Google Cloud native, using the Gemini Enterprise Agent Platform for the AI calls. Serverless-first, with a hosted or self-managed fallback for every serverless choice.

Deliberately not used in v1: a separate vector database (AuraDB is the vector store), a managed retrieval engine that keeps vectors outside the graph, and GKE or a streaming cluster (Cloud Run covers both ingestion and serving). The portability path is real: other clouds via multi-cloud AuraDB or self-managed Neo4j Enterprise; on-premise or air-gapped via self-managed Neo4j; and the AI layer reduces to three swappable calls (embed, rerank, generate) behind one retrieval interface.

Where OKF fits

The OKF bundle store in object storage is the durable system of record for ingested knowledge; the two graphs and the search indexes are rebuildable projections. Ingestion drafts OKF, one loader populates the graph from OKF, and scoring and warranting finalise the bundle. Backup, disaster recovery, and migration therefore operate on the bundles: restore them and replay the loader to rebuild the graph, with no separate graph backup to keep authoritative. See the knowledge-format page for the full design.