CRI-CORE Contract Compiler
The CRI-CORE Contract Compiler is a deterministic compiler for governance policies into CRI-CORE contract artifacts.
It bridges governance design and runtime enforcement by converting a human-authored JSON policy into a stable, machine-readable compiled contract. The compiled contract is a required input to CRI-CORE and defines the governance constraints evaluated at the execution boundary.
The compiler does not execute governance logic, make runtime decisions, or enforce policy. Its role is limited to producing reproducible contract artifacts with a stable structure and deterministic hash.
Installation
Compiler 0.5.0 is an unreleased candidate. The ordinary published package does not yet provide this candidate's action-policy API. For candidate review, install the validated wheel retained by CI:
pip install /path/to/cricore_contract_compiler-0.5.0-py3-none-any.whl
Requires Python 3.9 or later. See the release handoff for validation and the remaining coordinated publication gates.
Action policy API (0.5.0 unreleased candidate)
Use the distinct public API for independent file creation and modification requirements:
from compiler import compile_action_policy
policy = {
"schema_version": "action_policy.v1",
"contract_id": "repository-file-policy",
"contract_version": "2.0.0",
"action_requirements": {
"create": {
"required_role": None,
"allow": [{"match": "prefix", "value": "generated/"}],
"deny": [{"match": "prefix", "value": "generated/private/"}],
},
"modify": {
"required_role": "repository-maintainer",
"allow": [{"match": "exact", "value": "README.md"}],
"deny": [],
},
},
}
compiled = compile_action_policy(policy)
The module import from compiler.compile_action_policy import compile_action_policy
is also supported. Invalid input raises
compiler.compile_policy.PolicyCompilationError.
The result has exactly schema_version: compiled_action_contract.v1,
contract_id, contract_version, action_requirements, and contract_hash.
See the complete mixed output fixture,
create-only fixture, and
modify-only fixture.
The input is closed at every object level. It requires the exact discriminator,
a nonempty string contract ID, an X.Y.Z version, and at least one action.
The only actions are create and modify; omitted actions remain omitted.
Each present action requires exactly required_role, allow, and deny.
Roles are null or nonempty strings. Rules require exactly match (exact or
prefix) and a nonempty string value.
- An absent action or no matching allow, including an empty allow list, grants no permission. A required role is an additional requirement, never a grant.
- Deny takes precedence within the same action. Other actions' rules and roles have no effect.
- Duplicate selectors within an action's allow or deny list reject compilation. Identical allow/deny selectors within one action also reject; distinct overlapping selectors remain representable. Selectors may be reused across actions with different effects and roles.
- Target strings remain exact, including case, whitespace, Unicode, separators, and wildcard characters. Nonempty whitespace strings are literal values; the compiler performs no path validation, normalization, or wildcard expansion.
Rules sort by (match, value) in Python string order and object keys sort
lexicographically. The result contains fresh nested containers. SHA-256 covers
the entire output except contract_hash, including the schema discriminator,
using the established json.dumps(sort_keys=True, separators=(",", ":"))
UTF-8 convention (with the default ASCII escaping).
Schemas ship in the wheel and sdist and can be read without a checkout:
import json
from importlib.resources import files
schema = json.loads(files("compiler").joinpath(
"schemas/action_policy.schema.json"
).read_text(encoding="utf-8"))
schemas/compiled_action_contract.schema.json describes the output;
schemas/policy.schema.json retains the legacy input schema. The action schemas
validate structure and duplicate rules; the compiler additionally checks
allow/deny contradictions. Schema validation alone does not verify a hash.
Ledger owns authority identity, semantic provenance, policy-path grammar, and publication. Guard owns runtime enforcement, containment, and operation preconditions. This API only produces compiler contracts.
The legacy Python, file, and CLI entrypoints reject any top-level
action_requirements or explicit schema_version, including mixed inputs.
They retain historical compiled outputs and hashes for supported legacy inputs;
newly written wrappers identify the 0.5.0 producer. The CLI remains a legacy compiler; serialize action API results directly
with json.dumps when needed. The legacy artifact writer adds _compiler
metadata and does not produce the exact action output envelope.
Published 0.4.0 cannot acquire this capability retroactively. Future consumers
must require the named new API and validate its exact output; a missing API must
fail without legacy fallback. This candidate prepares package version 0.5.0 and
updates newly emitted legacy producer metadata accordingly. Distribution version
alone is not a capability check.
Legacy CLI Usage
Compile a governance policy into a compiled contract artifact:
cricore-compile-policy policy.json compiled_contract.json
The output is a deterministic JSON artifact that includes compiler metadata, compiled governance requirements, invariants, and a contract hash.
Legacy Python Usage
The compiler can also be used programmatically:
from compiler.compile_policy import compile_policy
policy = {
"contract_id": "finance-policy",
"contract_version": "1.0.0",
"authority": {
"required_roles": ["proposer", "reviewer"]
},
"approvals": {
"thresholds": [
{
"field": "amount",
"operator": ">",
"value": 1000,
"requires_role": "approver"
}
]
},
"artifacts": {
"required": ["proposal", "approval"]
},
"stages": {
"allowed_transitions": [
{"from": "proposed", "to": "approved"}
]
},
"constraints": [
{
"type": "separation_of_duties",
"roles": ["proposer", "reviewer"]
}
]
}
compiled_contract = compile_policy(policy)
Legacy Policy Input
Policies are JSON objects with a required contract identity:
{
"contract_id": "finance-policy",
"contract_version": "1.0.0"
}
The compiler currently recognizes these optional sections:
authority.required_roles: list of role names required by the contract.approvals.thresholds: list of threshold-based approval requirements.artifacts.required: list of required governance artifact names.stages.allowed_transitions: list of allowed lifecycle transition objects.constraints: list of explicit structural constraints.targets.allow/targets.deny: optional opaque target-scoping rules usingexactorprefixmatching.
contract_version must follow semantic version format: X.Y.Z.
contract_version is assigned by the policy owner and is independent of the
compiler package version.
Legacy Compiled Output
The compiled contract always includes these top-level sections:
{
"contract_id": "finance-policy",
"contract_version": "1.0.0",
"authority_requirements": {},
"approval_requirements": {},
"artifact_requirements": {},
"stage_requirements": {},
"invariants": {},
"contract_hash": "..."
}
The required core identity fields of every compiled contract are:
contract_idcontract_versioncontract_hash
These are the only identity fields emitted by the compiler. The compiler does
not emit aliases such as id or version.
The compiler maps policy fields into compiled contract fields as follows:
policy.authority.required_rolesbecomesauthority_requirements.required_roles.policy.approvals.thresholdsbecomesapproval_requirements.thresholds.policy.artifacts.requiredbecomesartifact_requirements.required_artifacts.policy.stages.allowed_transitionsbecomesstage_requirements.allowed_transitions.constraints[type="separation_of_duties"]becomesinvariants.separation_of_duties.
Empty compiled sections remain present as empty objects to keep the contract shape stable for downstream validation and hashing.
Legacy Target Scoping
Target scope defines which resources an automated action may or may not change.
{
"targets": {
"allow": [
{"match": "exact", "value": "README.md"}
],
"deny": [
{"match": "prefix", "value": "deployment/"}
]
}
}
When targets is present, it maps directly to the optional compiled section:
{
"target_requirements": {
"allow": [
{"match": "exact", "value": "README.md"}
],
"deny": [
{"match": "prefix", "value": "deployment/"}
]
}
}
Supported match types are exactly exact and literal prefix; matching is
case-sensitive against the opaque target supplied by Guard. Deny rules take
precedence over allow rules. A nonempty allow list blocks unmatched targets,
while an empty or absent allow list allows targets unless denied. Missing or
invalid execution targets fail closed whenever target_requirements exists.
The format supports neither globs nor regular expressions, and the compiler
performs no implicit or filesystem normalization. The compiler defines and
hashes these constraints, but Guard enforces them at runtime.
Contract Identity Guarantee
The compiler produces a deterministic contract identity composed of:
contract_idcontract_versioncontract_hash
The contract_hash is computed from the canonical compiled contract structure
using sorted JSON serialization.
For identical policy inputs, the compiler guarantees identical contract hashes.
This identity is used by downstream systems (e.g., CRI-CORE) to verify that a proposal references the exact contract used for evaluation. Mismatches result in enforcement failure.
Contract Pass-Through Requirement
Compiled contracts must be passed through downstream systems without modification.
In particular:
- Contract identity fields (
contract_id,contract_version,contract_hash) must not be altered. - Downstream components must not recompute or overwrite the contract hash.
CRI-CORE enforces this at evaluation time. Any mismatch between a proposal's declared contract hash and the compiled contract hash will result in a blocked decision.
Determinism
Compiled contracts are hashed with SHA-256 after canonicalizing the compiled structure using sorted JSON keys.
This ensures:
- identical policy inputs produce identical compiled outputs
- identical compiled outputs produce identical contract hashes
This determinism is required for reproducible enforcement and contract identity verification in CRI-CORE.
Written artifacts also include _compiler metadata:
{
"_compiler": {
"tool": "cricore-contract-compiler",
"version": "0.5.0",
"contract_hash": "..."
}
}
Validation
The _compiler.version field identifies the writer of a newly emitted legacy
artifact. It is wrapper metadata outside the hashed compiled contract. In this
candidate only that field changes from historical 0.4.0 artifacts; the contract
and hash stay identical. Retained artifacts and historical fixtures remain
untouched. The action API returns its exact five fields without this wrapper.
The compiler performs minimal compile-time validation for:
- Policy root type.
- Required
contract_id. - Required semantic
contract_version. authority.required_rolesas a list of strings.approvals.thresholdsas a list of threshold objects.artifacts.requiredas a list of strings.stages.allowed_transitionsas a list of transition objects.- Separation-of-duties constraints with at least two roles.
The JSON schema in schema/policy.schema.json defines the supported policy
surface. Runtime enforcement remains outside this package.
Position in the Governance Pipeline
Governance Policy
|
Contract Compiler
|
Compiled Contract
|
Proposal Normalizer
|
CRI-CORE Kernel
|
Commit Decision
The compiler sits upstream of CRI-CORE runtime enforcement. It produces the structural contract artifact that downstream systems can evaluate.
Role in the Execution Protocol
The compiler is responsible for defining governance constraints in a deterministic, machine-readable form.
Within the CRI-CORE execution model:
- The compiler defines contract identity and constraints
- The proposal normalizer constructs canonical proposals referencing the contract
- CRI-CORE evaluates whether the proposed action is admissible
The compiler does not participate in runtime evaluation. It defines the contract that runtime enforcement depends on.
Non-Responsibilities
The compiler does not:
- Execute governance validation.
- Interpret policy semantics beyond structural compilation.
- Perform runtime decision logic.
- Enforce governance rules.
- Modify or interpret proposal data at runtime.
All runtime enforcement is handled by CRI-CORE or other downstream systems.
Forward Compatibility
Compiled contracts may include additional sections beyond those currently enforced by CRI-CORE (e.g., approval requirements, artifact requirements, stage constraints, invariants).
These fields are preserved for forward compatibility and may be enforced by future versions of the execution pipeline.
Project Status
Version 0.5.0 is an unreleased candidate for independent create/modify
compilation. The CLI remains legacy-only. Ledger must require
from compiler import compile_action_policy without a legacy fallback;
downstream dependency pin changes belong to subsequent tasks.
Install requirements/ci.txt in a virtual environment with
python -m pip install --require-hashes -r requirements/ci.txt, then run
python scripts/validate.py. This checks current release metadata, the complete
source suite, repeated representative compilation, fresh sdist and wheel builds,
strict distribution checks, and a clean wheel's API, schemas, CLI, full suite,
and dependency consistency. Evidence and environments stay under .cache/.
Use --expected-commit FULL_SHA to require a clean checkout at an exact commit.
CI runs all checks on Windows/Linux with Python 3.9 and 3.14; skips fail validation.
License
Apache-2.0
Copyright 2026 Waveframe Labs.
Metadata
Release files for cricore-contract-compiler 0.5.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| cricore_contract_compiler-0.5.0.tar.gz | 85.2 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| cricore_contract_compiler-0.5.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 105.4 kB
Release files / cricore_contract_compiler-0.5.0.tar.gz
| Download URL | cricore_contract_compiler-0.5.0.tar.gz |
|---|---|
| Size | 85.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
e4140ff174b9b4a148093e93ddbb134e420c6caadc26d853d014d0971d38bef4
|
|
BLAKE2b-256 checksum How to use checksums |
2f0718488c82acb4a797703c0fc34acb2ee79c17e0bfe48dc298e9d5c2f0c2ce
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.14.4
|
Release files / cricore_contract_compiler-0.5.0-py3-none-any.whl
| Download URL | cricore_contract_compiler-0.5.0-py3-none-any.whl |
|---|---|
| Size | 20.2 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
1bc689d2885e32641ac3ade7e710a4d0fe079c089f1a2160e2d86f328bbb7c44
|
|
BLAKE2b-256 checksum How to use checksums |
ac56913d206661c95377ef222c26eb77b06a02f33fa9057607ab87f2314a65e7
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/6.2.0 CPython/3.14.4
|