AXIOM 2026 landscape research — report
Legend: VERIFIED = fetched this session (URL + date shown). EXPECTED = from training/reasoning, not re-fetched today; treat as needing confirmation. Dates derived from npm _npmOperationalInternal.tmp epoch are ≈ ±1 day.
1. Competing / adjacent projects (2025–2026)
Section titled “1. Competing / adjacent projects (2025–2026)”1a. Spec-driven development (SDD) tools
Section titled “1a. Spec-driven development (SDD) tools”| Tool | What it is | Adoption / status | AXIOM lesson |
|---|---|---|---|
| GitHub Spec Kit (github/spec-kit) | CLI that scaffolds .specify/ (constitution, templates, bash scripts) + slash commands /specify → /plan → /tasks; spec = many markdown files per feature branch |
Widely installed; Fowler/Böckeler review (2025‑10‑15, VERIFIED https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html) says it is “spec-first, not spec-anchored”: one branch per spec, spec dies with the PR | Do NOT duplicate: markdown-workflow scaffolding. Learn: constitution = project-wide invariants, exactly what constraints {} should hold. |
| Kiro (AWS) | VS Code fork; requirements.md → design.md → tasks.md with EARS/GIVEN-WHEN-THEN; “steering” = memory bank |
Reviewer found it “sledgehammer for a nut” on small bugs (16 acceptance criteria for one bug) | Lesson: workflow must scale down. An AXIOM .axm for a 1-file change must be ~10 lines or nobody writes it. |
| Tessl Framework | Spec-as-source: *.spec.md with @generate/@test tags → tessl build emits code marked // GENERATED FROM SPEC - DO NOT EDIT, 1:1 spec↔file; CLI doubles as MCP server |
Private beta as of the review; docs URL moved (my fetch of tessl-io/tessl/docs/spec-format.md → 404) |
Closest competitor to AXIOM’s thesis. Reviewer explicitly observed non-determinism across regenerations from the same spec — AXIOM’s deterministic engine is the differentiator if it actually holds. |
| AGENTS.md (OpenAI/agentsmd) | Plain-markdown agent instructions file; now read by Codex, Copilot, Cursor, OpenHands (OpenHands release notes cite “refresh AGENTS.md guidance”, VERIFIED 2026‑09) | De-facto standard; not a spec format | Do NOT compete. AXIOM should emit an AGENTS.md section / read it as context. |
| Cursor rules / Claude Code hooks & plugins / Copilot instructions | Path-scoped instruction files + lifecycle hooks (PreToolUse/Stop) | Universal in 2026 harnesses | Hooks are where “verified apply” enforcement actually lives today. AXIOM’s checks {} should be exposable as a hook command, not only an MCP tool. |
| BMAD, Superpowers | Prompt-pack methodologies (personas, ceremonies) | Community-popular, zero determinism | Nothing to duplicate; they are the audience, not competitors. |
Böckeler’s critical arguments (all VERIFIED from the article): review-overload from generated markdown; “false sense of control” (agent ignored constitution items, duplicated existing classes); SDD is MDD reborn — “with LLMs we’re not constrained by a parseable spec language anymore… the price is non-determinism… the parseable structure had upsides we’re losing: tool support to write valid, complete and consistent specs.” That last sentence is AXIOM’s pitch, stated by a skeptic.
1b. Intent / policy / config DSLs
Section titled “1b. Intent / policy / config DSLs”| DSL | Latest (VERIFIED) | Relevance |
|---|---|---|
| OPA / Rego | v1.20.2 (Sept 2026), and/or keywords added in 1.20.0, WASM runtime moved to wazero, JSON Schema for IR + bundle manifest published in 1.17 (https://github.com/open-policy-agent/opa/releases) |
Heavyweight; Go binary 60 MB. For AXIOM’s check layer see §5. |
| Nickel | 1.17.0 (2026‑06‑03); public Rust/C/Go/Python APIs since 1.15; LSP; contracts (https://github.com/nickel-lang/nickel/releases) | Best “config-with-contracts” story; no JS/WASM runtime → poor fit for an npm-shipped engine. |
| Dhall | v23.1.0 (2025‑01‑16) — one release in 20 months (https://github.com/dhall-lang/dhall-lang/releases) | Effectively dormant. Do not build on it. |
| CUE, Pkl, KCL, Cedar | EXPECTED: CUE ~0.13–0.14, Pkl ~0.29–0.30 (JVM/native, no npm runtime), KCL ~0.11–0.12 (Rust+WASM), Cedar 4.x (Rust, @cedar-policy/cedar-wasm exists) |
Pkl/CUE are config languages, not intent languages; KCL and Cedar both ship WASM, which is the only realistic way to embed a foreign policy language in a TS engine. |
Takeaway: none of these are “intent for codegen” — they’re config/authz. AXIOM’s agent { intent … } block has no direct competitor; its constraints/checks blocks overlap with all of them.
1c. Declarative codegen
Section titled “1c. Declarative codegen”Nx generators (virtual tree + formatFiles + dry-run), Plop/Hygen (Handlebars/EJS templates), Yeoman (dead-ish), Projen (code-as-config, regenerates managed files, marks them read-only), Turborepo turbo gen, Copier 9.18.2 (VERIFIED https://pypi.org/pypi/copier/json — Jinja templates, .copier-answers.yml, template updates via 3-way merge).
Lessons for AXIOM: (1) Projen’s “regenerate + mark managed” and Copier’s “answers file + update” are the two proven patterns for keeping generated files in sync over time — AXIOM’s manifest.json should carry enough to do a Copier-style update, not just apply. (2) Nx’s virtual FS tree for dry-runs is the right shape for “plan → diff → apply”. Do NOT rebuild a template engine; embed one.
1d. Verified-apply / agent sandboxing
Section titled “1d. Verified-apply / agent sandboxing”- OpenHands v1.20.0 (2026‑09‑17, VERIFIED) — Docker conversation runtime, agent profiles scoped to MCP servers/secrets, explicit skill allow-lists, “ready-for-dev issue readiness gate”, hooks. Runtime isolation is solved here; file-write provenance is not.
- e2b, Daytona, Docker sandboxes (EXPECTED): ephemeral microVM/container per agent session; all expose “run command / write file” APIs, none expose “verify this write matches a declared manifest hash”.
- Gap confirmed: nobody offers content-addressed, manifest-verified apply as a primitive. This is AXIOM’s most defensible piece — but only as a small library/CLI/hook, not as a sandbox competitor.
2. MCP ecosystem (2026)
Section titled “2. MCP ecosystem (2026)”@modelcontextprotocol/sdk1.30.0 (≈2026‑07‑27, VERIFIED npm). Notable from the package manifest: peerzod ^3.25 || ^4.0, optional@cfworker/json-schemavalidator provider, subpath exports./server,./client,./validation,./experimental/tasks, depends onhono ^4.11and@hono/node-server, ships conformance tests (@modelcontextprotocol/conformance). Still 1.x — no 2.0 yet.- Spec revision: EXPECTED latest is 2025‑11‑25 (tasks, elicitation refinements, structured tool output, tool annotations
readOnlyHint/destructiveHint/idempotentHint/openWorldHint,outputSchema, streamable HTTP as the remote transport, SSE deprecated). Registryserver.jsonschema is dated2025‑12‑11(VERIFIED), consistent with a Nov‑2025 protocol revision. - MCP Registry (VERIFIED https://github.com/modelcontextprotocol/registry/…/generic-server-json.md):
registryType∈npm | pypi | oci | nuget | cargo (added ~June 2026) | mcpb; transportsstdio | streamable-http | sse;runtimeHint(npx,uvx,dnx); packagefileSha256for mcpb;_meta["io.modelcontextprotocol.registry/publisher-provided"]. - MCPB (
@anthropic-ai/mcpb2.1.2, VERIFIED) = zip bundle with manifest, SHA‑256 in registry, one-click install in Claude Desktop. - Shipping recommendation: publish npm with
bin(works withnpxruntimeHint, and withruntimeHintinserver.json), plus an OCI image for CI/sandbox use, plus register in the MCP registry. Skip MCPB unless targeting Claude Desktop consumers. Single-file bundling (tsdown → one.mjs) matters fornpxcold start; keep the stdio server dependency-light (do not pull Hono/express into the stdio path — the SDK already does; considerimport deferor lazy import of the HTTP transport). - Tool-design best practice for coding agents (EXPECTED consensus): few, coarse tools; annotated (
readOnlyHintonaxiom.validate,destructiveHint:false, idempotentHint:trueonaxiom.applybecause it’s hash-gated);outputSchema+structuredContentso the agent gets JSON not prose; return diffs/manifests as resources (axiom://manifest/<sha>) rather than inlining large blobs; use elicitation only for genuinely blocking choices.
3. Parser technology for the .axm DSL (TypeScript)
Section titled “3. Parser technology for the .axm DSL (TypeScript)”Versions VERIFIED on npm: chevrotain 13.2.0 (≈2026‑08‑01, Node ≥22), langium 4.4.0 (≈2026‑09‑09, depends on chevrotain ~13.2 + chevrotain-allstar + vscode-languageserver 10.1), ohm-js 17.5.0 (≈2026‑02‑13), peggy 5.1.0 (≈2026‑03‑01), @lezer/common 1.5.2 (≈2026‑04‑08), web-tree-sitter 0.27.0 (≈2026‑08‑30).
| Option | LSP | Error recovery | Bundle (EXPECTED) | Notes |
|---|---|---|---|---|
| Langium | Free: LSP server, VS Code ext scaffold, scoping, validation, formatter, hover, completion, playground | Yes (Chevrotain fault-tolerant + ALL(*) via chevrotain-allstar) | Heavy: ~1–1.5 MB min incl. vscode-languageserver; 705 files in tarball | Grammar file → generated AST types. Overkill inside the engine, ideal for the editor/LSP package. |
| Chevrotain | No (build your own) | Yes, best-in-class fault tolerance | ~250–300 KB | Fastest hand-written-speed parser in JS; what Langium runs on. |
| Ohm | No | Weak (PEG, first-failure) | ~200 KB | Beautiful for prototyping semantics; poor IDE story. |
| Peggy | No | Weak (PEG) | Tiny generated parser (~20–60 KB), zero runtime deps | Great for a frozen grammar; recovery must be hand-added. |
| Lezer | CodeMirror-native, not LSP | Excellent incremental + recovery | ~100 KB runtime + generated tables | Best if the primary editor surface is web/CodeMirror, not VS Code. |
| tree-sitter WASM | No LSP; grammars in JS DSL compiled by C toolchain | Excellent | ~200 KB WASM + grammar WASM; needs cargo xtask/emscripten to build grammar |
Highlighting/queries only; you still need a semantic layer. |
Recommendation: Chevrotain in axiom-core (engine) + Langium in a separate axiom-lsp package that reuses the same Chevrotain token definitions. Reasoning: Langium 4.4 is literally Chevrotain 13.2 underneath, so one lexer/grammar source of truth is feasible; the engine (run via npx inside MCP) must stay small and dependency-free, while the LSP/VS Code extension can afford Langium’s weight and gets completion/hover/validation nearly free. Reject Peggy (no recovery → bad agent error messages), reject Ohm (no IDE path), reject tree-sitter (build toolchain friction on Windows, no semantics). If you want the absolute smallest engine, Peggy + a post-hoc validator is acceptable for v1 but caps DX.
4. Deterministic, verifiable artifact generation
Section titled “4. Deterministic, verifiable artifact generation”Lightweight subset that pays off for an agent codegen tool:
- Content-addressed manifest (already have sha256): make it canonical — sorted paths, LF-normalised, mode bits,
sha256per file + a Merkle-style root hash over the manifest; store the inputs hash too (.axmsha + profile sha + engine version + emitter versions). This is a Nix derivation in spirit without Nix. - in-toto Statement / SLSA Provenance v1 (EXPECTED current: SLSA v1.0 provenance, in-toto attestation framework v1) as the manifest envelope:
subject[] = {name, digest.sha256},predicateType = https://slsa.dev/provenance/v1,buildDefinition.externalParameters = {axm, profile},runDetails.builder.id = axiom@x.y.z. Emitting this JSON costs ~50 lines and makes AXIOM output consumable bycosign verify-attestation, GitHub artifact attestations and OPA’sallow_net-style checks. - Signing: optional Sigstore keyless via
sigstore-js(EXPECTED ~3.x) or, cheaper,npm publish --provenancefor the engine itself (note: every package fetched above is already published via GitHub OIDC trusted publishing — the ecosystem norm in 2026). Do NOT build a PKI. - Reproducibility: forbid timestamps/random IDs in emitters; pin emitter output to
engineVersion; add a--checkmode (like Copier/Nickelformat --check) that regenerates and diffs. OPA itself just landed “improve determinism of plan/wasm bundle builds” (1.18.0, VERIFIED) — even mature tools fight this. - Skip: full Nix, TUF, Rekor self-hosting, SBOM per artifact (already have
sbom.jsonfor the tool; enough).
5. Policy / check evaluation
Section titled “5. Policy / check evaluation”| Option | Size (EXPECTED) | Expressiveness | Verdict |
|---|---|---|---|
| Custom evaluator (current) | smallest | whatever you implement; no spec, no docs, agents must learn it | Only defensible if grammar stays trivial. |
cel-js 0.8.2 (VERIFIED, ≈2025‑07‑11; deps chevrotain 11.0.3 + ramda) |
~150 KB w/ deps | Google CEL: comparisons, macros (all/exists/map/filter), string/list/map ops; well-specified, LLMs know it |
Best fit if maintained — last release 14 months ago, pre-1.0, pins old Chevrotain (dupe of your 13.x). Risk. Alternative: @marcbachmann/cel-js (EXPECTED, more active) — verify. |
JSONLogic (json-logic-js) |
~10 KB | Low; JSON-only, no strings-as-source, ugly for humans | Good as an IR, bad as the authoring surface. |
OPA WASM (@open-policy-agent/opa-wasm) |
100 KB loader + policy WASM (200 KB–2 MB) | Full Rego; needs opa build (60 MB Go binary) at authoring time |
Too heavy for the core; fine as an optional check backend for enterprise users who already have Rego. |
| Zod v4 refinements (zod 4.6.5, VERIFIED) | already a dep | Arbitrary TS predicates — but that’s code, not data; not portable to the .axm file |
Use for validating the IR/manifest schema, not for user-authored checks. |
Recommendation: keep checks data, not code — adopt CEL syntax as the check expression language (it is the de-facto policy expression standard: Kubernetes ValidatingAdmissionPolicy, Envoy, Firebase, Cedar-adjacent), compile CEL → a small JSONLogic-like IR in the manifest so the evaluation is deterministic and trivially auditable, and vendor/fork the CEL parser onto your own Chevrotain 13 tokens rather than depending on cel-js 0.8.x. Expose OPA-WASM as a plugin later.
6. Latest stable versions (all VERIFIED from registry.npmjs.org /latest, 2026‑09‑18)
Section titled “6. Latest stable versions (all VERIFIED from registry.npmjs.org /latest, 2026‑09‑18)”| Package | Version | ≈Publish date | Notes |
|---|---|---|---|
| typescript | 7.0.2 | 2026‑07‑07 | Native (Go) compiler; platform binaries as optional deps; exports now ./unstable/* API |
| zod | 4.6.5 | 2026‑09‑13 | zod/mini, zod/compile entry points |
| vitest | 5.0.1 | 2026‑09‑14 | Node ^22.12 / ^24 / ≥26; peer vite ^6.4‖^7‖^8 |
| tsup | 8.5.1 | 2025‑11‑12 | esbuild-based; slow cadence |
| tsdown | 0.23.0 | 2026‑09‑03 | rolldown-based; peer TS ^5‖^6‖^7; @tsdown/exe (single executable) — recommended over tsup |
| unbuild | 3.6.1 | 2025‑08‑14 | rollup-based; stale |
| @modelcontextprotocol/sdk | 1.30.0 | 2026‑07‑27 | see §2 |
| chevrotain | 13.2.0 | 2026‑08‑01 | Node ≥22 |
| langium | 4.4.0 | 2026‑09‑09 | on chevrotain ~13.2 |
| ohm-js | 17.5.0 | 2026‑02‑13 | |
| peggy | 5.1.0 | 2026‑03‑01 | |
| @lezer/common | 1.5.2 | 2026‑04‑08 | |
| web-tree-sitter | 0.27.0 | 2026‑08‑30 | |
| cel-js | 0.8.2 | 2025‑07‑11 | stale, pins chevrotain 11 |
| hono | 4.13.8 | 2026‑09‑14 | |
| @biomejs/biome | 2.5.14 | 2026‑09‑15 | |
| eslint | 10.10.0 | 2026‑09‑04 | flat config only |
| prettier | 3.9.8 | 2026‑09‑17 | |
| @changesets/cli | 3.0.3 | 2026‑09‑14 | new major; Node ≥26?/pnpm ≥10 in engines |
| oxlint | 1.83.0 | 2026‑09‑13 | type-aware via oxlint-tsgolint peer |
Toolchain call: tsdown + Biome + Vitest 5 + Changesets 3 + TS 7. Biome vs ESLint: Biome 2.5 covers lint+format in one Rust binary; only pick ESLint 10 if you need a niche plugin. oxlint is fast but still needs Prettier/Biome for formatting.
7. Honest view: is there a real gap?
Section titled “7. Honest view: is there a real gap?”Arguments that the gap is real
- The strongest skeptic of SDD (Böckeler, VERIFIED) concedes the exact thing AXIOM sells: parseable specs give “tool support to write valid, complete and consistent specs” and remove non-determinism; she saw Tessl regenerate differently from the same spec.
- No sandbox/runtime vendor (OpenHands, e2b, Daytona, Docker) offers manifest-verified apply; hooks in Claude Code/Copilot are where teams hand-roll it today. A small, standard “declare → generate → attest → apply-if-hash-matches” primitive is missing.
- Supply-chain norms (OIDC trusted publishing on every package above, in-toto/SLSA, MCP registry
fileSha256) show the ecosystem now expects provenance; agent-written code is the largest unprovenanced input in 2026 repos. - MCP has matured (structured outputs, annotations, registry) enough that a deterministic tool with schema’d outputs is genuinely more useful to an agent than a prose skill.
Arguments that it’s solved / won’t be adopted
- Böckeler’s MDD warning applies squarely: a custom DSL “sits at an awkward abstraction level”, and spec-as-source “might end up with the downsides of both MDD and LLMs: inflexibility and non-determinism.” AXIOM’s determinism is only real for the templated part; the moment an emitter calls an LLM, the guarantee evaporates.
- Natural-language spec + agent + tests + hooks is already the loop every 2026 harness ships; Spec Kit/Kiro/AGENTS.md are markdown precisely because markdown has zero learning curve for both humans and models. A
.axmgrammar is one more thing the model must be taught (and gets subtly wrong). - Codegen-from-declaration is a solved commodity (Nx, Projen, Copier, Hygen). The differentiated part of AXIOM is ~500 lines (canonical manifest + attestation + hash-gated apply), not a language.
- Small market: the people who want deterministic, attested agent output are platform/security teams; they already have OPA/Cedar and would rather see a Rego/CEL policy over a diff than learn AXIOM’s
constraints {}.
Net assessment: the language is the weakest bet; the verified-apply + attestation + MCP tool is the strongest. The most defensible rebuild is: (a) shrink .axm to a tiny, LSP-backed front-end (Chevrotain/Langium) that many will never write directly because agents generate it; (b) make the manifest an in-toto/SLSA statement; (c) ship axiom apply --verify as an npm bin usable as an MCP tool and as a Claude Code/Copilot hook and as a CI step; (d) use CEL for checks so policy people don’t have to learn anything; (e) accept that generation itself will be a mix of templates (deterministic, attested) and agent output (attested only), and make the manifest say which is which.
Not verified this pass (recommend a second agent confirm): exact MCP spec revision date, CUE/Pkl/KCL/Cedar current versions, cel-js alternatives’ activity, sigstore-js version, e2b/Daytona current APIs, Tessl’s current spec format (docs URL moved).