17 requirements · evidence first
Product roadmap
A requirement-by-requirement view of what exists, what is only partially qualified, and what still needs engineering.
Current boundary (October 4, 2026): Axiom exposes only paper-derived basic and multilevel matching through one Durable/Service path. Packed is graph storage, not a third matcher. Hosted Linux resource qualification currently fails: Multilevel runs out of memory during startup; Basic completes one million updates at ~9,054/s but fails during disk-pressure recovery replay. Durable external IDs are supported for the fixed vertex universe; dynamic vertex lifecycle is not implemented. These are not passing gates. The 10k/s target remains unproven. Hardware power-loss is deferred; billion-vertex support is unproven.
“Partial” means only the evidence stated exists; it does not imply the full requirement is met. Historical native-engine results do not qualify Basic or Multilevel.
| # | Status | Requirement | Evidence and remaining work |
|---|---|---|---|
| 1 | Partial | Paper-engine performance hardening | Recursive deepcopy is removed; recent work indexes I3 crossings, H-tilde sources, and Extend projections. Remaining graph-sized snapshots, hierarchy work, and aggregate memory budgets still need migration and qualification. |
| 2 | In qualification | Durable basic and multilevel modes | Durable and Service select one of the two persisted paper modes. The former native matching engine is removed; exact recovery, failure-path and per-mode performance qualification remain. |
| 3 | Partial | Repeatability, skew and adversarial qualification | Earlier power-law and 60-second rates are historical results from the removed native matcher and do not qualify Basic or Multilevel. Repeatable paper-mode uniform/skewed, adversarial, hierarchy-boundary and recovery matrices remain. |
| 4 | Partial | Service and deployment qualification | Paper-backed local recovery, bounded-resource tests and operational guidance exist. Deployment supervision, broader skew/burst and explicit quota/alert policy remain. Hardware power-loss testing is deferred. |
| 5 | Partial | Durable external vertex IDs | Typed string, UUID, and signed-64-bit integer mappings persist in SQLite and are never reused. Installed-package, corruption, sustained lookup, and lifecycle qualification remain. |
| 6 | Not done | Dynamic vertex lifecycle | The vertex universe is fixed at construction; durable add/remove semantics are absent. |
| 7 | Implemented; qualification active | Atomic batch updates | Durable Service has bounded atomic submit_batch with one SQLite commit boundary, exact retry and rollback tests. Installed-release and workload qualification remain. |
| 8 | Implemented, bounded | Atomic multi-query read snapshots | Service.read_snapshot returns immutable partner and edge-membership answers under one committed version with a 4096-query cap, stale-version rejection and serialized owner execution. This is not long-lived MVCC or historical topology retention. |
| 9 | Not done | First-class bipartite API | No typed partitions or same-side edge rejection contract exists. |
| 10 | Not done | Event subscriptions | Versioned change delivery, bounded subscriber queues and backpressure semantics are absent. |
| 11 | Partial | Observability | Service admission/group counters and benchmark histograms exist. Stable metrics/exporter, storage/recovery health and alert contracts remain. |
| 12 | Partial | Deterministic replay and historical debugging | Durable/Service history exports bounded retained operations with versions and chained digests; recovery replays and verifies state. Public import/replay verification and historical graph queries remain. |
| 13 | Not done | Match explanations | There is no version-linked explanation of partner changes or algorithm repair evidence. |
| 14 | Partial | Cross-platform packaging | CI/release matrices define 20 CPython wheels across five platform targets; hosted evidence is pending. Windows verifies native/paper APIs only because POSIX Durable/Service are unsupported there. Windows ARM64 and musllinux are excluded. |
| 15 | Not done | Network transport | Service is local and threaded; authenticated HTTP/gRPC transport and end-to-end network semantics are absent. |
| 16 | Future scope | Weighted and constrained matching | Weighted, maximum-cardinality and capacity-constrained matching remain separate future engine contracts. |
| 17 | Partial | Machine-enforced release gates | Research, quality and packaging gates exist. Paper-mode durable qualification and complete mode-specific release gates do not. |
Implementation-level decisions and benchmark artifacts are maintained alongside this roadmap in the repository. A claim is complete only when its stated gate passes on the relevant engine and packaging path.