How it works

[ AxiomCore · Documentation ]

How AxiomCore works

The AxiomCore mental model, from source and evaluation to contracts, locks, consumers, Inspector and Cloud.

AxiomCore turns application declarations into a versioned contract: a typed description of models, operations and policy that every other tool reads. This page explains that path and the nouns you will meet in the rest of the docs.

From source to contract to every consumer
From source to contract to every consumer
Diagram source
flowchart LR
  A[Acore source] --> C[Evaluate and validate]
  B[Extracted backend] --> C
  C --> D[.axiom contract and lock]
  D --> E[Client SDKs]
  D --> F[Acore UI .axiomapp]
  D --> G[Server runtime]
  D --> H[Database schema]
  D --> I[Axiom Inspector]
  D --> J[Axiom Cloud release]
  1. Source. You write .acore files in Acore, or you extract declarations from an existing FastAPI or Go backend. Acore is optional at supported integration edges: an existing backend and framework can keep their code.
  2. Evaluation. The Axiom CLI parses the source, resolves imports and amendments, and checks types and validation rules.
  3. Contract and lock. axiom build writes a canonical .axiom artifact. A manifest (AxiomDeps.toml) states which contracts a consumer wants; a lock pins the exact bytes by SHA-256 digest.
  4. Consumers. Generated clients, Acore UI applications, the server runtime and database migrations all read the same contract. None of them receives backend author code through it.
  5. Review and release. Axiom Inspector explains what the application declares and can reach. Axiom Cloud stores immutable, signed releases.

Key terms

TermWhat it isStatus
AcoreThe declarative language for contracts, backends, UIs and databasesAlpha
.acoreEditable Acore sourceAlpha
ExtractionGenerating reviewable declarations from a FastAPI or Go backend; OpenAPI and SQL bootstrap a domain modelFastAPI Available, Go Alpha, bootstrap Experimental
.axiomA canonical, versioned contract or package (service, theme, component library, database schema, extension, application policy)Alpha
Manifest and lockDependency intent, and the pinned artifact, version and digest a build usedAlpha
.axiomappA deterministic Acore UI application artifact for one or more targetsAlpha
Contract runtimeThe engine that loads a contract and executes requests in a clientWeb Available, React and Flutter Alpha, Swift Experimental
Server planThe private .server.json file axiom build writes next to a backend artifactExperimental (managed logic)
Database contractAcore database source built into a server-only schema package and applied as migrations to PostgreSQL or SQLiteExperimental
Axiom InspectorA local, queryable model of facts and relationships in your applicationAlpha
Axiom CloudHosted projects, environments and signed releasesAlpha

See Support and availability for the full matrix.

Boundaries

  • A contract describes an interface. It does not contain the backend implementation or make extracted code trustworthy.
  • A local build can be unsigned. Production Acore UI builds reject unsigned contracts; Cloud releases add signatures.
  • Every target runtime shares the contract model but has its own storage, network and lifecycle. Test each target you ship.
  • Executable extensions are separate, sandboxed WebAssembly modules with their own trust chain. See Extensions.

Next steps

Observability

Send runtime traces to an Axiom Cloud project, read traffic, logs, traces and alerts, and control the separate CLI adoption telemetry.

Contracts and artifacts

How editable .acore source, .axiom packages, manifests, locks and .axiomapp builds relate to each other.

On this page

Key termsBoundariesNext steps