Everything behind a provable answer.

Getting started

Corvair unifies licensed expertise, your own content, vetted external sources, and each user's personal files into one trust-scored base, keeps it current, and answers in plain language with a citation and a signed record behind every word. It sits above any retrieval service and beneath any agent, adding the visibility, governance, provenance, and proof they do not provide.

Who this is for

These docs serve four audiences. Business and knowledge users will want Using the substrate and the preview. Knowledge stewards, administrators, and auditors will want Roles and governance. Technical evaluators will want Architecture and Security and compliance. Developers and partners building on the platform will want the API guide and the knowledge format.

The four ways in

The substrate is more than a knowledge base with a chat box. Four capabilities behave as one system over the same governed content, with the same attribution and the same proof, reached identically by people and by agents.

Core concepts

A handful of ideas recur throughout the product and these docs. Each links to where it is treated in full; the glossary defines every term in one place.

Trust tiers

Trust is not a feeling. Each source carries a tier, and the tier travels into every answer.

The Validity Warrant

A signed, replayable record attached to every answer and every governed decision, in five parts: the question, the knowledge it rested on (tiers, freshness, the pinned as-of snapshot), the reasoning (retrieval and the premise chain), the authority (who or what asked and the policy bounds they stayed within), and a signature that is timestamped so it can be replayed and verified after the fact. Open it months later and the decision still verifies. The cryptographic design is summarised under Architecture.

Knowledge as code: the recipe

A base is defined by a recipe, a declarative file stating its intent, scope, sources, trust, freshness, access, and curation policy. Hydrate it and you get a running, governed base; hydrate it again and you get an equivalent one, reproducible and auditable like software.

# recipe: what the base is, not how it is built
base: Risk & Compliance
intent: "Model risk, prudential, and AI governance for a regulated lender"
sources: [ licensed.foundation, intranet.policy, regulators.t1, news.vetted ]
trust: { regulators: T1, internal_policy: T2, vendor: T3 }
freshness: { regulators: 30d, policy: on_change }
curation: { low_risk: auto, consequential: steward_approval }

The two graphs

The substrate runs two distinct graphs, co-located so one query can use both: a retrieval graph that grounds the words of an answer, and a Causal Substrate that governs trust and produces the premise chain. See Architecture for the full model.

FrameGraph and the Canvas

Apply a selectable analytical framework (5W1H, PESTEL, SWOT, Ecosystem, Jobs-to-be-done and more) over a topic graph to produce a navigable, reusable, exportable view. Read the concept, see how it works inside the app as the Canvas, or browse the frameworks behind it in the Frames Library. A frame also produces deliverables, including the coverage report.

Using the substrate

For most people the face of the substrate is the Virtual Expert: a domain assistant that answers from one governed base, grounded and warranted. The capabilities below are the same content, the same governance, and the same proof, whether reached by a person or an agent.

Roles & governance

No one role can do everything, and that is the point. The separation is the assurance. Each role sees only what it should, and every action, by a person or an agent, is recorded for audit.

A fifth role, the domain partner, authors and packages virtual-expert packs for subscription. See the roles, recipes and federation page and the partner view.

Platform

How the substrate is built, secured, and represented. These pages are written for technical evaluators, security reviewers, and implementers.

Develop & integrate

One governed surface serves both people and agents. The REST API is the contract; a set of lean MCP servers is a thin, governed cover over it, generated from the same contract so the two cannot drift.