Repository navigation
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. Advisorycommit_allowedresults must never authorize mutation. - Only exact
"strict"and"local"strings are accepted. Invalid declarations raiseValueErrorwithCRI_MODE_INVALID; conflicting function/context declarations raiseCRI_MODE_CONFLICTbefore 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.pyis removed. The canonicalcricore.apipackage and root exports expose the same supported API, includingevaluate_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.