§Documentation

Docs live with the system that enforces them

This page is the public map. Implementation detail stays in the owning repo, with the system that enforces it.

The architecture

The core and encoder now connect an explicitly selected candidate to a verifiable local bundle and a real engine response. This is a working development checkpoint; admission and publication remain separate work.

ImplementedLocal development path · core + encoder

  1. Caller

    Select the source

    Candidate + dependencies

    Choose a candidate RuleSpec file and every dependency module explicitly. The caller supplies the root and module targets.

    No automatic dependency inference.

  2. axiom-encode

    Export exact bytes

    BuildSpec

    The export command preserves the source text in a bounded JSON file and reports its digest. It does not parse, repair, or compile the RuleSpec.

    Assurance: unvalidated_candidate

  3. axiom-core + rules engine

    Build and verify

    Unsigned bundle

    The pinned Axiom compiler builds the explicit module closure. The bundle retains sources and executable bytes. Offline verification checks the caller’s expected digest, engine identity, and a local rebuild.

    Assurance: development_unsigned

  4. axiom-core + rules engine

    Execute and explain

    Execution receipt

    The real engine executes a strict native request. Optional rule pins change the scenario while preserving the stored baseline. CLI and Python return the full native result, metadata, and explanation traces.

    Private context + native response

A matching digest establishes integrity against the caller’s expected bytes. It does not authenticate an author, establish legal correctness, or admit a candidate for publication. Keep the original CLI binary and private input data for replay; receipts contain private context and traces.

Planned integrationBeyond this local checkpoint

  1. Signed source intake

    Connect core bundles to the existing signed corpus releases and their source evidence.

  2. Independent workload

    Bind execution to separately authorized expected results and explicit comparison evidence.

  3. Admission and publication

    Record and sign admission decisions, then select the builds to publish.

Merged implementation: core bundles and execution, explicit encoder export, and real encoder/core integration tests.

The broader pipeline

This conceptual map follows source intake, corpus, encoding, RuleSpec, and the rule graph to application surfaces. Its illustrative compile seal does not represent a signed or admitted core bundle. The implemented and planned boundaries are shown above.

Repository ownership

The repo split is part of the documentation model: engineering docs live in the repo that owns the code or contract, and a doc moves only when the owning system moves.

axiom-corpus

Corpus source text, anchors, hierarchy, tables, hashes, source claims, and signed source releases.

axiom-encode

Candidate generation, harness and proof validation, eval suites, and explicit BuildSpec export. Export does not change signed apply or acceptance-test trust.

axiom-core

Local development bundle identity, pinned compilation, offline verification, strict execution receipts, and the thin Python transport.

axiom-oracles

Oracle adapters, comparison workloads, and evidence used to evaluate candidate behavior against external implementations.

axiom-rules-engine

RuleSpec language, compiler, runtime, test runner, and executable semantics.

rulespec-*

Jurisdiction RuleSpec corpora: checked-in .yaml rules and companion .test.yaml cases.

axiom.org

Public site, Axiom app shell, docs index, and cross-system presentation.