Contract pipeline

How source declarations become reviewable artifacts, generated clients, and runtime behavior.

The AxiomCore pipeline turns backend evidence and Acore declarations into a versioned contract boundary. It includes extraction, compilation, packaging, client generation, and runtime consumption; it is not one indivisible build step.

backend source or schema                     existing frontend or Acore UI
          │                                              ▲
          ▼                                              │
  extractor / bootstrap ──► Acore source ──► .axiom ──► pull / runtime
                                  │             │
                                  └── tests ────┴── inspect · diff · release

1. Establish the source boundary

You can author a service contract directly in Acore, amend supported backend source, or bootstrap a reviewable domain model from OpenAPI JSON or SQL DDL. These paths have different support levels. In particular, FastAPI extraction imports the selected application module, so its Python dependencies must be installed and module initialization must be safe in a build environment.

See Backend extraction for the exact execution boundary.

2. Evaluate and validate Acore

The Acore lexer, parser, evaluator, standard library, and validators produce a typed in-memory representation. amends composes extracted or imported input with authored declarations; it does not make the imported source inherently trusted. Run the domain and security checks required by your repository before building.

axiom domain validate axiom.acore
axiom security check axiom.acore
axiom test axiom.acore

3. Build the contract artifact

axiom build writes a local .axiom artifact and lock information. The artifact contains evaluated contract data consumed by tooling and runtimes. It is a data boundary, not a bundle of backend author code.

axiom build axiom.acore
axiom inspect axiom.axiom

A local build can be unsigned. A Cloud release adds provenance and durable release evidence; it does not turn an unchecked source change into a trusted release by itself.

4. Review change and provenance

Use semantic diff before updating consumers. Artifact hashes bind a lock to exact bytes, while a paired Ed25519 signature and public key can prove Cloud provenance. See Artifact trust.

axiom diff previous.axiom candidate.axiom --format semantic
axiom contract verify candidate.axiom --lock axiom.acore.lockfile

5. Pull a client surface

axiom pull resolves a local artifact, dependency configuration, share URL, or release reference and generates the selected framework surface. Generated code carries endpoint identity and typed model information; the runtime still owns contract loading, validation, transport policy, caching, and structured events for the capabilities implemented by that target.

axiom pull --contract organization/project/1.2.0 --framework atmx-web

6. Execute on the selected target

Native clients use the Rust runtime through their binding layer. Browser clients use the Wasm runtime and ATMX JavaScript integration. They consume the same contract model, but storage, network APIs, initialization, and framework lifecycle differ by platform. Test those boundaries in the real application.