Objective

Solving and proving in one system

Automated solvers, computer algebra systems, proof kernels, and formal libraries usually expose different terms, evidence formats, and notions of acceptance. Axeyum implements these functions in one Rust workspace so a result can move from search or computation to a recorded, checked fact.

The long-term objective is repeated knowledge development. Axeyum should select a useful open statement, find or compute a result, check the relevant evidence, record the accepted fact and its assumptions, then use the changed dependency graph when selecting later work.

Applications

One reasoning substrate across several domains

The typed terms, solvers, evidence routes, kernel, and library support applications beyond formal mathematics. Each application retains its own semantics and checker requirements.

Mathematics

Exact symbolic computation, formal definitions, checked theorems, and dependency-aware library construction.

Rules, policy, and compliance

Bounded checks for consistency, coverage, thresholds, allocation, authorization, and workflow reachability in human-authored formal models.

Checked agent workflows

Models can propose rules, invariants, encodings, formalizations, or proof steps; Axeyum accepts results through the applicable checker.

System

Five native components

Each component is Axeyum's own implementation. External systems appear in benchmarks, differential tests, imports, and technical comparisons.

  1. Axeyum SAT Solver A native CDCL solver with AIG and CNF lowering and certificate support.
  2. Axeyum SMT Solver A typed SMT implementation with rewriting, theory solving, bit-blasting, models, and certificates.
  3. Axeyum CAS A proof-carrying computer algebra system for exact symbolic operations.
  4. Axeyum Kernel An independent Rust checker for a selected Lean-core term language.
  5. Axeyum Library A dependency-aware library of checked facts with explicit evidence and assumptions.

Knowledge development

Checked results change later work

A recorded fact matters when it supplies a dependency, a procedure, or evidence that later work can use. The library therefore stores dependency edges, proof routes, axiom footprints, and provenance with the proposition.

The system chooses an open statement, gathers relevant known facts, produces a candidate result, checks its evidence, records the accepted fact, and makes new work available. Openstatement Gather knownfacts Produce acandidate Check theevidence Record theaccepted fact New workis available The library grows, then the process repeats.
A checked result becomes part of the input for later work.

Foundations

Assumptions remain attached to each result

Axeyum includes a constructive mathematical base whose kernel-checked declarations can have an empty axiom footprint. Classical material remains useful, but its uses of choice, propositional extensionality, quotient soundness, or other axioms stay visible in the fact record.

The distinction applies per declaration. It does not classify mathlib as wholly classical, and an empty footprint does not make two statements equivalent when their carriers or hypotheses differ.

Compare the foundations

Next work

Broader coverage and more reusable results

Current development expands solver coverage, certificate production, kernel reconstruction, formal-library depth, and the procedures that select and reuse facts. The status reports measure those areas separately because progress in one does not establish progress in another.