CAIR

Related · CAIR

CAIR — the authoritative program ontology

Canonical Authoritative Intermediate Representation

Most languages assume program ≈ text source. CAIR does not delete text — it demotes it to one projection among many, and moves version, governance, write-back and verification onto a single authoritative ontology that text, graphs, grids, natural language and AI candidates all point at. EML appears inside CAIR as the intent / spec-normalization layer.

Version: v1.0.0
Package: cair-mvp==1.0.0
Stable API: /api/v1
CAIR Schema: 1.0.0
DB schema: 1000
Stable operations: 105
JSON Schemas: 75
Regression tests: 88
Status: Stable / capped
License: none declared

The problem

Four places where “program = text source” stops holding

The classic pipeline — parse, lower, compile, execute — has not failed. It simply no longer describes a system shaped by AI generation, agent workflows, visual editing, tensor graphs and automated governance at the same time.

The upstream is no longer formal syntax

Systems now start from requirements, conversations, example I/O, diagrams, tables, domain rules, AI candidates, or an already-running state — inputs that carry ambiguity and undecided items, and cannot simply be equated with an authoritative program.

The editors are no longer only human

Developers, optimizers, models, agents, runtimes, hardware adapters, policy engines and remote governance nodes all propose changes. So the system has to answer: who may generate, who may verify, who may commit, who may execute, who may revoke.

The structure is no longer linear

A tensor program is naturally an operator graph; an agent system is a capability/permission graph; distributed governance is an event chain with signatures. Forcing all of them to use file paths and line numbers as identity means constantly flattening and re-inflating them.

Automation amplifies control and liability

When an agent can generate code, call tools, mutate data, deploy services and change persistent world state, “the output looks reasonable” is not enough to justify execution. Permissions, blast radius, risk level, provenance, verification, commit record and rollback are required.

Core relation

The ontology is not the surface

CAIR’s one-line thesis is an inequality. The authoritative program ontology P* carries nodes, edges, regions, types, effects, constraints, governance, history and provenance; every text, graph, grid, natural-language or execution view is a projection π_i of it. Identity never depends on screen layout, line numbers or a particular model.

P*  ≠  P_i

P*  =  (N, E, R, T, F, C, G, H, M)
       nodes, edges, regions, types, effects,
       constraints, governance, history, metadata

π_i :  P*    ->  P_i        project  (text / graph / grid / NL / tensor / governance)
ρ_i :  P_i   ->  P*         parse back
δ_i :  ΔP_i  ->  ΔP*_c      write back  — as a CANDIDATE, never a commit

h_semantic  ≠  h_layout     moving a node on screen must not change meaning

Layout and semantics get separate fingerprints, and a pure layout operation is required to leave the authoritative content fingerprint untouched. Dragging a box is not a program change; rewiring a capability edge is — even though the pixel diff is far smaller.

Projections

Four grades of projection

A projection has to declare how much it can carry back. Conflating a lossless text DSL with an AI-written summary is exactly how information disappears silently.

Lossless & reversible

ρ_i(π_i(P*)) = P*. CAIR’s structured text DSL targets this inside its supported subset.

Conditionally reversible

Reversible only on a declared subset D_i. Outside it, round-tripping is not guaranteed and must not be assumed.

Lossy summary

Natural-language summaries, simplified architecture diagrams, statistics. Useful for understanding; not write-back-enabled by default.

Generative

π_θ,Ctx depends on model and context, so it must label model + version, the context used, the authoritative source, inference vs. fact, what was omitted, and whether it may produce candidates at all.

Write-back

Nothing edits the authority directly

The hard part of a multi-projection system is not showing one program in many views — it is safely changing one program from many views. Every edit, from any actor, becomes a candidate that must survive type, effect, permission, policy, risk and invariant validation before it can become a version.

projection edit

candidate proposal

validate

semantic diff

impact preview

commit version

controlled execution

certificate

The invariants this buys: AI may generate but not silently commit; a drag may propose but not pollute semantics; natural language may form candidates but must show what it presumed; governance changes get reviewed independently; and an uncommitted proposal cannot mutate the authoritative version. Execution output likewise never writes back — it has to raise a new proposal.

Architecture

Eight layers — and where EML sits

CAIR v1.0 defines S = (L_I, L_E, L_C, L_N, L_P, L_G, L_X, L_V). The second layer is named EML: multi-surface semantic input and spec normalization, the place where intent is separated into goals, constraints, resources, acceptance criteria and unresolved items before anything becomes authoritative.

Layer	Name	Role
L_I	Intent input	Requirements, conversation, examples, diagrams, existing state — ambiguity allowed here and nowhere downstream.
L_E	EML semantic translation	Normalizes intent into I = (G, C, R, V, U) and must distinguish human-specified, system-default, AI-inferred, AI-completed, undecided and conflicting.
L_C	CAIR authoritative ontology	Nodes, edges, ports, regions, types, effects, constraints, governance, history — the single source of identity.
L_N	NOVA tensor / operator	Tensors, operators, shapes, devices, layouts, effects and certificates as first-class authoritative structure.
L_P	Multi-projection	Text, graph, grid, natural language, tensor, governance and diff views over the same version.
L_G	Control & governance	Capabilities, region policy, risk ceilings, multi-party approval, policy-as-code.
L_X	Controlled execution	Isolated Skill backends, whitelisted NumPy, resource budgets, external adapters (OCI, Sigstore, OPA).
L_V	Verification & certificates	Validators, versions, execution certificates, transparency log, snapshots.

Read L_E as an architectural role, not a wiring claim: CAIR v1.0 (cair-mvp==1.0.0) does not bundle this site’s EML-P toolchain. What the two share is the position EML occupies — the semantic entry point that must never let an AI’s reasonable guess be written down as the user’s original intent.

What v1.0 ships

One closed loop, four clusters

CAIR grew through M0–M6 and v0.5–v0.9 with every stage keeping the previous stage’s regressions — 7 tests at M0–M1, 88 at v1.0. These are the capabilities that reached code + tests + artifact + acceptance.

Ontology, projections & versions

Pydantic v2 authoritative model: nodes, edges, ports, regions, constraints
Canonical JSON + SHA-256 content fingerprint, layout/semantic split
Text DSL round-trip, graph and grid projections sharing one fingerprint
Change proposals, stale-proposal blocking, semantic diff, impact closure
SQLite versions; restore creates a NEW version instead of overwriting history

AI candidates & NOVA

Rule-based structured candidate generation with reasons, confidence, assumptions
Unsupported intent degrades safely to unresolved instead of guessing
Tensor shape inference: named dims, broadcasting, matmul, reduction, reshape, transpose, ReLU
Whitelisted NumPy execution, network effects refused, resource budgets
Execution certificates binding program hash, input hash, output hash, backend, limits

Governed Skills

Skill as H = (domain, input, output, capability, permission, validator, failure policy)
Four simultaneous checks: actor capability ∧ region policy ∧ skill capability ∧ risk ceiling
Human approval forced when the region requires it and the actor is an autonomous agent
Process-isolated (python -I) and Docker backend abstraction with timeout/CPU/memory/IO caps
Network and filesystem denied by default

Supply chain & distributed governance

.cairskill / .cairpolicy signed packages: file manifest, SHA-256, Ed25519
Signer identity separated from key generation; active / retired / revoked
Trust needs all three: signature valid ∧ signer trusted ∧ package enabled
Append-only transparency log, checkpoints, Merkle root, witness quorum
Multi-party approval requiring role coverage AND organization diversity
Governance replication, anti-entropy, signed LWW-map CRDT, verifiable snapshots

CAIR’s own completion test is Code ∧ Tests ∧ Artifact ∧ Acceptance. An adapter existing is not conformance; a Dockerfile existing is not a verified image build.

Boundaries

What v1.0 explicitly does not claim

This list is not a disclaimer added afterwards — it is written into the release itself, and it is the reason the rest of the page can be read literally.

Not a distributed database

SQLite is each node’s local authoritative database. Program rollback and database restore are different operations.

Not consensus

`local-quorum` is a threshold check. It is not Raft, Paxos, BFT, or a linearizable replicated state machine — operations needing real consensus must use an external adapter.

CRDT has a scope

The signed LWW-map fits mergeable, low-risk state. It does not fit key revocation, asset transfer, unique ownership, one-shot capabilities or irreversible operations.

Process isolation is not a strong sandbox

v1.0 states plainly that process isolation cannot safely run arbitrary hostile Python. Third-party code needs containers, Wasm, microVMs or separate hosts.

No external-standard conformance claimed

OCI conformance, full online Sigstore verification, Rekor inclusion-proof validation, Fulcio X.509 path validation, RFC 9162, SLSA levels, in-toto and TUF are all explicitly not claimed. When a tool or trust material is missing, CAIR reports `unavailable` rather than success.

Not formally proven

There are structure, type, effect, policy and property tests, but CAIR is not a formally verified language core, and the cross-language canonicalization corpus does not exist yet.

Not performance-tuned

The v1.0 acceptance target was the semantic and governance loop. Very large graphs, very large tensors, high-throughput multi-node deployment and production penetration testing are all out of scope.

Roadmap

v1.1 – v2.0 capability gates

A capability plan, not a calendar. CAIR’s own judgement is that the next node is usability, not consensus: v1.1 succeeds when someone unfamiliar with the internals can build, review, approve, commit and restore an authoritative program through the Workbench and still see exactly what every projection, plugin, Skill and remote decision was permitted to do.

Version	Theme	Gate	Status
v1.1	Workbench & conformance baseline	Program explorer, proposal review, complete semantic diff, version timeline, canonicalization test vectors.	planned
v1.2	Multi-user platform	Identity, organizations, RBAC + capability, PostgreSQL repository, object storage, audit events.	planned
v1.3	Plugin ABI & isolation	.cairplugin manifest, Wasm Component Model, five isolation profiles, capability broker. Draft spec exists; no stable plugin API in v1.0.	draft
v1.4	Agent interoperability	MCP and A2A adapters — pinned to real stable versions, isolated behind adapters, never written into CAIR Core.	planned
v1.5	Observability	Tracing and metrics over proposals, validation, execution and governance decisions.	planned
v1.6	Supply-chain conformance	Where SLSA / in-toto / Sigstore claims could become real — only after actual build-platform controls exist.	planned
v1.7	Distributed state	Beyond threshold checks toward genuine replicated authority.	planned
v1.8	World-state programming	Persistent state and its permitted transitions as first-class program structure.	planned
v2.0	Distributed authoritative ontology	The only version allowed to change v1.0’s stable contract — after a v1.9 candidate proves it.	planned

Ten items on v1.0’s do-not-change list protect this path: the package name, /api/v1 semantics, CAIR Schema 1.0.0, the migration history of DB schema 1000, the 105 stable operations, existing schema field semantics, the canonical JSON profile, program fingerprint identity, and the proposal base-version check.

Source documents

The frozen v1.0 document set

This page is a readable summary. These are the normative documents behind it, each with its own content fingerprint. CAIR fixes an authority order for conflicts: release artifacts first, then the executable stable contract, then acceptance/operations docs, then whitepapers, and drafts last — a draft may never overwrite v1.0 stable behavior.

CAIR v1.0 技術白皮書：多重投影程式系統與權威計算本體

sha256:bb40a1e1…

The main external document: what CAIR is, and how EML, CAIR, NOVA, projections, governance and execution fit together.

CAIR 規範白皮書：權威 IR、多重投影與語義回寫

sha256:da58fe9d…

The implementer’s anchor: core model, canonical JSON profile, projection certificate, change operations, validators, versioning, conformance profiles. Also states that the v1.0 fingerprint is not RFC 8785 JCS and change operations are not RFC 6902 JSON Patch.

CAIR 治理與供應鏈安全白皮書

sha256:9b7ec3f1…

Signed packages, signer/key model, dependency locks, governance, transparency, witnesses, the OCI / Sigstore / OPA adapter boundaries, replication and execution security.

CAIR v1.0 系統實作與部署手冊

sha256:91131113…

Wheel / source / offline install, systemd, Uvicorn, Nginx, Docker, SQLite migration, online backup, restore, multi-node topology, anti-entropy, incident handling.

CAIR v1.1–v2.0 發展路線圖

sha256:ee6c5c36…

The capability-gate plan summarised in the roadmap table above. Explicitly not a calendar and not completed capability.

CAIR 插件與生態系統規範 v1.0-draft

draft · targets v1.3

Plugin manifest, entry points, Wasm components, capability broker, publisher/catalog. Must not be read as an implemented stable plugin API.

CAIR v1.0 發行總結與研究交接報告

zip sha256:29b8144d…

The handoff baseline: full engineering history M0–v1.0, the frozen contract, the do-not-change list, known limits, and the minimum reading order for restarting the work. It also keeps the failure records — npm 503s, unavailable Docker/Podman, untested external Cosign/Fulcio/Rekor — on the grounds that failure records are part of the engineering boundary.

CAIR is currently a research and engineering archive. Its v1.0 package ships no license file and declares none in its metadata, and the release documents reference no public repository — so nothing here is a download link. If that changes, this page gets the links.

ICNS

Interpretation-Complete Numeral Specification

`0.91` is not a number. It is a surface string whose semantics have not been declared — it can be 0.91, (0,91) or (0,9,1), and no amount of prefixing fixes that.

MNVP

Multi-layer Numerical Visualization Protocol

A number being correctly represented is not the same as a number being correctly understood. Every display is a projection — MNVP makes that projection declare what it kept, what it dropped, and whether it is still faithful.

All related projects