Support and feedback

Use this page to choose where to report a problem, build a diagnostic bundle that is safe to share, and contribute a documentation fix. Never put credentials or sensitive customer data in a public report.

Choose a channel

Create a safe diagnostic bundle

Start with read-only diagnostics:

axiom --version
axiom doctor --json --strict > axiom-doctor.json
axiom ui doctor --target web --json > axiom-ui-web.json

The doctor report never contains tokens, keys, or contract contents, but it does include your local project path. Before you attach anything, remove:

• tokens, cookies, and authorization headers;
• private URLs, DSNs, and sandbox keys;
• signing material;
• request and response bodies and cache payloads; and
• customer identifiers and local usernames or paths.

Debug logs are not automatically safe to share. If a contract's shape is private, do not attach the artifact; give its SHA-256 and the smallest synthetic reproduction instead.

Report a product failure

Preserve the first structured error and name the failing boundary: extraction, evaluation, build, proof, pull, runtime, target host, or Cloud. Check Troubleshooting before you collect broad debug output; later framework errors often hide the original condition.

Include:

Never attach signing private keys, bearer tokens, cookies, DSNs, sandbox credentials, or raw sensitive payloads.

Report a documentation defect

Say which kind of problem it is:

Link the narrowest implementation evidence you can. Do not use internal milestone names in a public title or reproduction.

Contribute to the documentation

Documentation changes are product changes: a command, API, compatibility, or availability claim must come with the evidence that supports it.

Before you edit:

1. Identify the owning repository and the implementation behind the claim.
2. Reproduce the behavior with the current tool or a test.
3. Choose the exact status from the support matrix.
4. Decide whether the change belongs in a concept, guide, reference, or product-direction page.

Planned products must use Coming soon and must not include runnable installation steps. Do not publish internal workstream labels.

Build and check the site from the repository's docs directory:

cd docs
corepack enable
pnpm install --frozen-lockfile
pnpm check
pnpm static:check

pnpm check validates the packaged examples, content metadata and navigation, internal links, public terminology and example safety, TypeScript and MDX compilation, a production build, and HTTP smoke tests for the public discovery routes. For a quick check on a focused edit, run:

pnpm lint:content
pnpm types:check

Every claim and example in your change must:

• record the versions, commands, results, and source or test evidence in the contribution (maintainers reconcile capability evidence during review);
• state the target, framework, command, artifact, or host boundary;
• separate a successful build from real backend or consumer behavior;
• use synthetic data and clearly non-production placeholders;
• use repository-relative paths, never a developer's home path;
• say when extraction imports or runs application code;
• treat semantic output as review evidence, not a universal guarantee;
• keep the approved dark theme and check desktop and narrow layouts, code copy controls, diagram text alternatives, and table overflow; and
• follow docs/AGENTS.md: keep useful information, write concise prose with descriptive code captions, and avoid em dashes and private implementation details.

Each page is published in several forms. Check that statuses and boundaries survive all of them:

• rendered HTML and the search index;
• the processed /docs/<path>.mdx output;
• llms.txt, llms-full.txt, and agents.json;
• sitemap.xml and robots.txt; and
• the page's Open Graph image and metadata.

The repository's CONTRIBUTING.md has the maintainer release procedure and the commands for changes that also touch examples or implementation code.