Capabilities and release status
Status of version 0.10.0: capabilities, boundaries and roadmap.
Version and distribution
This documentation describes 0.10.0, which adds point-estimate convergence certificates to the 0.9.0 baseline. The package index lists the installable releases; 0.9.0 was not published separately.
Current capability boundaries
| Capability | Current state |
|---|---|
| Graph modeling and structural dispatch | Implemented; eligibility depends on declared laws and supported structural analysis. |
| Exact Gaussian and general NUTS posterior | Implemented, with numerical and convergence requirements. |
| Typed tasks, Results, provenance and codec | Implemented for five task kinds; each route retains its own domain. |
| Predictive and fixed/posterior simulation | Implemented within the diagonal-Gaussian observation interface. |
| Prior simulation | Samples the graph's declared distributions where their sampling methods exist. |
| Point-estimate convergence certificate | minimize and fit optionally bound the local Newton decrement; a usable curvature floor is required. See certificate scope. |
| Model checking | Implemented with applicability, conclusion and optional-input distinctions. |
| Analytic evidence | Implemented for whole-graph exact linear-Gaussian models under normalization and x64 requirements. |
| Residual numerical EvidenceTask execution | Deferred integration; compiled problem and adapter code do not enable the public route. |
| Non-Gaussian recycling and cumulants | Experimental composition primitives; overlap, truncation and generation limits remain explicit. |
| Amortized posterior task execution | Reference estimator/encoding exists; no completed public execution route. |
| General workflow/agent control plane | Roadmap; the schema seams precede the full controller. |
| TRIS scientific recovery | Research validation, not a package-wide release guarantee. |
Roadmap
The normative design defines nine stages. The status column is read from the tree: a stage counts as delivered when its modules and tests exist, and open items are named rather than folded into a verdict.
| Stage | Goal | Status |
|---|---|---|
| R0 | Freeze the graph core, exact inference, marginal terms, diagnostics and the NumPyro bridge into a trusted baseline. | Delivered |
| R1 | A common vocabulary: the Task family, reports, Refusal, fingerprints and lineage, without changing any number. | Delivered |
| R2 | Raise "the posterior runs" to "the posterior is checkable, predictable and comparable". | Delivered |
| R3 | A general model-checking and calibration layer that judges Results and decides no algorithm. | Delivered. The action registry it points at belongs to R7. |
| R4 | Lift the marginal-likelihood pieces to a graph-level EvidenceTask. | Delivered for one structure class: a whole-graph exact linear-Gaussian plan under float64. Chain and campaign evidence, and a discrete route, remain refused. |
| R5 | Numerical evidence for the residual problems that do not collapse in closed form. | In progress. The compiled residual problem, the oracle, the optional extras and the nested-sampler adapter exist; the public residual route does not, because the backend lookup still returns nothing and the execution branch behind it is unwritten. |
| R6 | Widen structural recognition once the protocol is stable. | Not started as a stage. |
| R7 | A replayable, constrained workflow seam: ledger, state, action registry, budgets. | Not started. No module exists; the existing Tasks, Results and reports are its seams. |
| R8 | 1.0 and ecosystem maturity. | Not started. Its completion gate requires consumers this repository does not control. |
The design document is the source for the goals; this page is the source for what exists. Where they disagree, the tree is right and this row is stale. See principles and verification for how each stage's claims are checked.
Compatibility policy
The baseline preserves the supported public APIs and artifact schemas. Experimental primitives retain the limits listed above. Public breaking changes need migration instructions; correcting a numerically wrong answer can still break a consumer that relied on it and must be documented.
The deprecated bayesmith.evidence aliases migrate to bayesmith.marginal. The old namespace must never be reused for different task-level evidence semantics. Backend-native objects have weaker portability than bayesmith's typed artifacts.
Release acceptance sequence
- Resolve architecture and API findings, then have independent reviewers reassess the final changes.
- Run source fast/full checks, lint, Linux wheel and extracted-sdist verification; record commands, exit codes, skips and numerical stack.
- Have the downstream consumer run its suite against the candidate revision. A previous green report is not a verification of a new candidate.
- Build this site strictly, execute tutorials, inspect mobile and keyboard behavior, and verify API coverage.
- Align version, changelog, migration notes and artifact compatibility; preserve the tested candidate manifest.
- Publication requires a separate release decision.
These are acceptance requirements, not claims that this documentation build has executed them. The existing design's 1.0 milestone has additional ecosystem and workflow requirements; stabilizing a 0.x release does not silently satisfy them.