[ AxiomCore · Documentation ]
FAQ
Short answers about adopting AxiomCore with an existing stack, artifacts, signatures, runtimes, CI, telemetry, Cloud, and planned products.
Short answers to the questions developers ask most when they evaluate AxiomCore. Each answer links to the page with the details.
Adoption
Do I have to build the frontend in Acore?
No. Existing web, React, and Flutter applications can use generated clients, and any application can keep its own networking code while using AxiomCore for contract review, mocks, tests, and release evidence. Acore UI is an optional Alpha path. See Use your existing stack.
Do I have to write my backend in Acore?
No. FastAPI extraction is Available, Go extraction is Alpha, and the OpenAPI and SQL bootstrap paths are Experimental. You can also write the contract by hand. Acore describes and composes the contract; it does not require you to rewrite your backend code.
Does backend extraction run my service?
Yes, partly. The FastAPI extractor imports your application's own modules and runs their top-level code to get the application object, so keep that code safe: move production connections, migrations, and worker startup behind explicit entry points. The extractor bundles FastAPI, Starlette, and Pydantic and replaces other third-party imports with placeholders, so your project's packages do not need to be installed to extract (they are still needed to run the service). Constraints that FastAPI enforces on path parameters, and checks inside Go handlers, are not carried into the contract. See How extraction works.
Do I need an Axiom Cloud account?
No, not for local work. Authoring, checking, building, testing, mocking, and
running locally work without an account. Commands that contact Axiom services
first need a private alpha referral code (axiom join requests one).
Releasing to Axiom Cloud and pulling private contracts also need
axiom login.
Which platforms does the CLI run on?
The CLI 0.149.1 release has archives for macOS arm64, Linux amd64, and Linux arm64. There is no native Windows download. The documented walkthroughs are checked on macOS arm64. See Install the Axiom CLI and Support and availability.
Artifacts and trust
Are .axiom and .axiomapp the same kind of file?
No. An .axiom file carries a compiled contract or package. An .axiomapp
file is a target application artifact that contains the verified Acore UI
payload and target host material. Both are non-source artifacts with their own
manifests and verification rules.
Does a signature make a contract secure?
No. A signature proves that exact bytes came from the holder of a key. It does not prove backend authorization, source correctness, privacy, compatibility, or test coverage. Use locks, semantic diff, security analysis, tests, and release policy as separate controls. See Artifact trust.
Where should authentication secrets live?
In the application's secure or session storage, or in a scoped runtime configuration channel. A contract can declare where authentication is attached, but never commit production credentials in Acore source, generated clients, locks, mocks, screenshots, or source control.
Runtime behavior
Do browser and native requests behave the same?
They share the contract concepts but use different network, cache, lifecycle,
and framework bridges. Browser CORS, cookies, and sessionStorage differ from
native HTTP and the optional native Sled store. Run end-to-end tests on every
target you ship.
Is ATMX "zero JavaScript"?
No. ATMX includes a JavaScript integration layer and a WebAssembly runtime. Its DOM scanner can reduce application glue code, but startup, framework code, browser policy, and some declarative expression evaluation remain JavaScript.
What happens when the backend violates a response contract?
Where the selected runtime and endpoint validate responses, the operation returns a structured validation or decoding error. Your UI still has to render the error state and decide whether a retry or fallback is safe. See Runtime errors.
Tooling
Can I use AxiomCore in CI?
Yes, for headless commands such as axiom check, axiom test, axiom build,
lock verification, semantic diff, security checks, and selected UI checks.
Install the extractor binary (see
Backend extractors), pin
the tool and contract versions, avoid interactive prompts, and fail the job on
a non-zero exit. See
CI checks.
Does the CLI send usage data?
Only for commands that contact Axiom services, from an installation registered
with a referral code. Local commands such as check, build, run, test,
and ui send nothing. The data is minimal: an installation ID, command name,
success or failure, duration, CLI version, OS family, and a broad failure
category. It never includes arguments, paths, project names, contract
contents, or credentials. Set AXIOM_TELEMETRY=0 to turn it off. See
Benchmarks for details.
Products and scope
Is the Axiom Marketplace available?
Not yet. Typed package formats and lock tooling are Alpha, but a supported catalog for browsing and installing packages is Coming soon. Axiom Studio and Acode are also Coming soon; the existing dashboard, language server, and editor extensions are not those products.
Can Axiom Cloud replace GitHub and my CI/CD today?
No. Axiom Cloud manages Axiom contracts and their release evidence, channels, environments, tests, reviews, and runtime observability. General repository hosting and arbitrary CI/CD are outside its current scope.