Skip to content

CRI-CORE v0.14.0 — Strict-by-default evaluation

Latest

Choose a tag to compare

@Wright-Shawn Wright-Shawn released this 09 Sep 00:05
3b6d2ee

CRI-CORE 0.14.0 makes strict enforcement the default for public evaluation APIs and retains advisory evaluation only through explicit mode="local".

Published from reviewed merge 3b6d2eea61dbd79e26297f593d256480ea7cf69d, with reviewed tree 064dcff039f6a1674796a93843dd8dd760470ee5. The repository changelog and citation record candidate preparation on 2026-09-07; this GitHub release publishes those reviewed contents on 2026-09-08. PyPI publication and fresh external installation remain pending.

Behavior and migration

  • Omitted mode selects "strict". Missing integrity or publication sections block the strict commit decision.
  • Advisory evaluation requires an explicit mode="local" function argument. Advisory commit_allowed results must never authorize mutation.
  • Only exact "strict" and "local" strings are accepted. Invalid declarations raise ValueError with CRI_MODE_INVALID; conflicting function/context declarations raise CRI_MODE_CONFLICT before policy evaluation. Context cannot downgrade strict mode. Callers must block execution on configuration errors.
  • Callers relying on omitted mode or context-only local selection must migrate explicitly. Existing policy checks are unchanged.
  • The shadowed src/cricore/api.py is removed. The canonical cricore.api package and root exports expose the same supported API, including evaluate_structured.

Evidence boundary

This release does not implement CRI #4. Existing integrity/publication stages still accept empty mappings. That behavior does not establish cryptographic provenance or verify published authority. Historical artifact/finalization specifications are not guarantees of the current structured pipeline. Guard's separate Ledger authority verification remains unchanged; no environmental bypass guarantee is introduced.

Runtime dependencies remain empty and Python >=3.10 remains supported. No enforcement-stage, schema, contract-meaning, or product expansion is included.

Validation and compatibility

Fresh final wheel and sdist were built from the exact merge and tested from source and clean installations on Python 3.10 and 3.14. Release gates include strict/default/local behavior, early invalid/conflicting-mode rejection, compilation, strict Twine checks, metadata/content integrity, canonical imports, dependency consistency and audits.

Compatibility is verified with published waveframe-guard==0.18.0 from PyPI, installed without cache, then replacing only its resolved CRI dependency with this final wheel. Modern Ledger v2/v3 and repository evaluation/mutation paths retain their expected behavior; unsupported repository operations fail closed. All 11 retained legacy Guard entrypoints reject with GUARD_LEGACY_EXECUTION_UNSUPPORTED, with zero legacy callbacks and zero allowed events. No Guard source runtime or permissive migration changes were used.

CRI #2 stays open pending PyPI publication and external installation. Guard #39 stays open until a fresh published Guard 0.18.0 installation resolves published CRI 0.14.0. CRI #4 remains open and unchanged.

The attached wheel and sdist are the exact validated final artifacts. No PyPI upload or deployment was performed during this GitHub release.

Exact final assets

Filename Bytes SHA-256
cricore-0.14.0-py3-none-any.whl 45877 11a22b4fb15137a0e535b8dd71bf927260800559221f0e10512029d59fb18702
cricore-0.14.0.tar.gz 41727 458c5f4742a041a3ed2e334fbe57b4e5bb85bf50b85aa56871537d58d9503dec

Each CRI source/wheel/sdist suite passed 670 tests with 3 established skips on both Python versions. Published-Guard acceptance: 341 passed / 79 skipped on Python 3.10/Ledger 0.7; 401 passed / 19 skipped on Python 3.14/Ledger 0.8. Guard skips reflect platform/privilege limitations and v3 availability with minimum Ledger. Both dependency audits found zero known vulnerabilities in published validation dependencies; the unpublished CRI candidate itself was reviewed locally.