Changelog

This changelog records documentation-visible release changes for the core mixle package. Distribution metadata, tags, and the coordinated family manifest must be updated before a public release is cut.

The changelog is intentionally narrower than the full repository history. It summarizes user-visible documentation, public API coverage, validation expectations, and migration guidance. Use Release Notes for the detailed current-release narrative and the git history for exact implementation commits.

0.8.2

A patch release of 0.8.1 with the same public surface. It repairs the 99 findings the ten adversarial reviews of the 0.8.1 candidate deferred (release-checklists/0.8.2-followups.md, decision D-0213) and the release-process defects the 0.8.1 publication exposed. Several repairs replace a silent wrong result with an error – estimators refuse observations outside their support, optimize refuses an empty batch and delta=0, a mixture refuses a likelihood-factor component – so existing code can start raising where it used to fit quietly: see Migrating to 0.8.2.

A second ten-pass adversarial review ran on the 0.8.2 candidate itself. Its seven blocking defects are repaired – among them quantile refusing an out-of-domain level on every family, every support-limited family mixable, terminal-state HMM readouts honouring the full restriction, every data verb reading a table as rows, and how='ensemble' correct at its default budget – along with its documentation findings. The remaining findings are recorded in release-checklists/0.8.3-followups.md (decision D-0217).

0.8.1

The first published release of the 0.8 line: the 0.8.0 candidate tree plus the post-candidate fixes recorded in CHANGELOG.md (the bounded log-series series, the independent-tester findings, the shape-clamp disclosure, the README links, and the rehearsal fixes). 0.8.0 was never published; see decision D-0212 in release-checklists/0.8.2-decisions.md. Migration guidance is unchanged from 0.8.0: see Migrating to 0.8.1.

0.8.0

See Release Notes for the full release-branch summary.

Added

  • Task and agentic distillation documentation for teacher/student workflows, tool-call traces, planning traces, and task-serving economics.

  • DOE documentation for distillation and cross-modal training selectors.

  • PPL, mixture, missing-data, stability, and automatic-inference release notes tied to the current hardening work.

  • Release-readiness checklist for supported environments, package artifacts, behavior gates, documentation gates, and coordinated family evidence.

  • Family release coordination guide covering package roles, version policy, support matrix evidence, co-install checks, publication order, and rollback expectations.

  • Support policy for runtime floors, effective support matrix, dependency bounds, compatibility/deprecation, and reproducibility evidence.

  • Security and data-boundary guidance for examples, artifacts, credentials, missing-data semantics, and decision-support claims.

  • Validation guidance for wheel installs, import sweeps, numerical stress checks, PPL lowering routes, strict Sphinx builds, and partial evidence labels.

  • Architecture notes covering core contracts, capabilities, workflow layers, extension guidance, and compatibility expectations.

Changed

  • Generated API pages are supported by narrative guides for core models, inference, PPL, DOE, data, reasoning, and production surfaces.

  • The generated API reference is treated as a broad public module map rather than a substitute for workflow documentation.

  • Public-facing docstrings have been edited to remove internal planning labels and to state caller-visible behavior, failure modes, and validation expectations directly.

Documentation Quality Bar

Release documentation should satisfy the following standard before publication:

  • every top-level guide in the navigation explains when to use the surface and what validation evidence matters;

  • generated API pages exist for public modules added by the release branch;

  • high-level menu items use stable names such as “Release Notes” rather than a version-specific title;

  • release-specific details live in release notes, changelog entries, or validation records rather than scattered across conceptual pages;

  • examples use public imports and avoid private data, local paths, credentials, and undocumented optional services; and

  • docstrings exposed through autodoc are accurate, professional, and free of notes-to-self or internal planning shorthand.

Release Gate

A public release is not complete until the package version, built artifacts, strict Sphinx build, wheel install/import sweep, tests, examples, notebooks, and coordinated family manifest all refer to the same commit.

For documentation-only release work, the minimum local gate is a strict Sphinx build with warnings treated as errors. That gate does not replace wheel, example, notebook, or full-test evidence for the release itself; it only proves that the documentation source is internally consistent.

Review Guidance

Documentation changes should stay tied to verifiable behavior. When a guide mentions a public model, estimator, PPL construct, DOE selector, or production artifact, the generated API reference, examples, and validation record should name the same surface. Release notes should distinguish stable APIs from experimental workflow guidance so users can choose an appropriate validation standard.

Reviewers should also scan for claims that imply publication has already happened when the branch is still a release candidate. Until tags, package metadata, built artifacts, and family manifests are aligned, use “release candidate”, “release branch”, or “pre-publication evidence” rather than phrases that imply a published package.