This matrix maps the proposed invariants in Sect. 8.1 of the paper to the evidence available in the companion artifact set. It is a coverage and evidentiary map, not a certification result, maturity score, or substitute for the invariant definitions in the paper.
The Machine-checkable clauses column describes only the deterministic
clauses exercised by icla-spec 0.1.0. Supporting artifacts are
non-normative schemas and constructed records. Executable tests identify
the checks that replay positive and negative paths. The final column preserves
the semantic or institutional judgment that the companion deliberately does
not automate. Conformance profiles are omitted because their cumulative
membership is fixed by Table 7 of the paper and mirrored by
ConformanceProfile in the reference implementation: Core covers ICLA-1–7
and ICLA-10, Governed adds ICLA-8–9, and Evolving adds only ICLA-11.
Event-linked impact analysis, candidate adjudication, and successor rollback
therefore remain ICLA-9 checks rather than implicit Evolving-profile
requirements.
The combined trace scope is bounded: oauth-042 exercises the ICLA-Governed
resolution-to-succession path and the ICLA-11 pre-institutional boundary;
auth-evolution-formation exercises governed formation from a submitted
proposal through identity assignment, complete initial CKC v1 append, a formed
state without an active pointer, and separate activation. Automatic discovery,
promotion quality, organizational effectiveness, production integration, and
distributed-operation properties remain outside machine assessment.
| Invariant | Machine-checkable clauses | Supporting artifacts | Executable tests | Governed-judgment remainder |
|---|---|---|---|---|
| ICLA-1 - Institutional capability identity | Capability identifiers are unique. Every active capability records id, owner, lifecycle, and an exact versioned active_ckc pointer. Formation cannot reuse an existing identity. |
capability.schema.yaml; capability-registry.schema.yaml; OAuth capability-registry.yaml; formation registry-before.yaml, registry-formed.yaml, and registry-active.yaml |
test_icla_1_capability_identity.py; duplicate-identity and replay cases in test_auth_evolution_formation.py |
Whether the capability boundary is institutionally meaningful, the owner is accountable, and the chosen lifecycle state is appropriate. |
| ICLA-2 - Canonical capability contract | Active pointers identify exact CKC versions. CKCs declare knowledge scope, operational relations, obligations, authorities, governed evidence schema, evaluation metrics with units, collection conditions, thresholds, interpretation rules and representative-case basis, governance, projection rules, source bindings, and immutability. | ckc.schema.yaml; OAuth ckc-verify-v10.yaml; formation ckc-auth-evol-v1.yaml |
test_icla_2_active_ckc.py; schema and successor-lineage cases in test_oauth_042.py; initial-CKC cases in test_auth_evolution_formation.py |
Semantic adequacy and completeness of scope, obligations, authority, projection rules, metrics, and the representative-case or coverage basis. |
| ICLA-3 - CEE boundary and governed authority | Intent, assembly, execution, and evidence records preserve the situated CEE boundary and relevant configuration. The assembly mandate is execution-scoped, grants no canonical-change authority, limits disclosure to the evidence contract, and does not require step-wise Registry control. Candidate CEE outputs cannot directly mutate canonical state. | intent.schema.yaml; assembly.schema.yaml; evidence-bundle.schema.yaml; OAuth intent.yaml, assembly.yaml, and evidence-bundle.yaml |
test_icla_3_distributed_authority.py; CEE-boundary and candidate-authority cases in test_oauth_042.py; test_mandate_and_materialization.py |
Adequacy of the admitted boundary and configuration, appropriateness of delegated authority, and whether the evidence contract requests sufficient but not excessive disclosure. |
| ICLA-4 - Registry navigation | Registry entries expose the required metadata, lifecycle, policy, conditions, exact active pointers, and typed relations with known endpoints. The OAuth pre-resolution history links an identified change event to affected capabilities and a declared source-impact relation path. | capability-registry.schema.yaml; OAuth capability-registry.yaml and resolution.yaml |
Registry filtering in test_resolution_and_assembly.py; pre-resolution impact-path replay in test_oauth_042.py; explicit Core coverage in test_profiles.py |
Semantic relevance and usability of metadata and relations, completeness of impact paths, and whether navigation results support the institutional decision at hand. |
| ICLA-5 - Intent and execution traceability | Resolution and assembly retain the intent, situated CEE boundary and configuration, Registry snapshot, matcher identifier/version, explicit confidence semantics, exact capability-to-active-CKC map, constraints, rationale, and one of the canonical admitted, rejected, or escalated outcomes. An admitted selection is nonempty; rejected and escalated outcomes may be empty and cannot be assembled. The RequiredCovered trace retains its applied method and applicable validator, model, or review-policy version. ConflictsResolved retains every applicable conflict, assembly-compatible resolution outcome, and policy identifier/version; an unresolved conflict prevents an authoritative assembly. |
intent.schema.yaml; resolution.schema.yaml; assembly.schema.yaml; OAuth intent.yaml, resolution.yaml, and assembly.yaml |
Matcher/version, confidence, canonical outcome, nonempty-admission, method/reference, conflict-outcome, and policy-basis checks in test_icla_5_intent_traceability.py; admitted, rejected, escalated, and unresolved-conflict cases in test_resolution_and_assembly.py; generated/reference trace agreement in test_oauth_042.py |
Semantic adequacy of capability coverage, suitability of matching, assessment, and conflict-resolution methods, legitimacy of the policy basis, ranking rationale, calibration quality, and the substantive correctness of admission decisions. |
| ICLA-6 - Assembly lineage | Assemblies pin exact selected CKC versions, evaluation-contract lineage, bound source versions, policies, and projection transformations. Cross-artifact checks reject an assembly whose CKC snapshot differs from the admitted resolution. The immutable assembly contains no later CEE-side materialization state. | assembly.schema.yaml; OAuth resolution.yaml and assembly.yaml |
test_icla_6_assembly_lineage.py; exact CKC, source-version, projection-transformation, and end-to-end lineage cases in test_oauth_042.py |
Completeness and relevance of the selected sources and contracts, semantic compatibility of their combination, and adequacy of the resulting assembly. |
| ICLA-7 - Contract/projection separation | Materialization is a first-class immutable record created after, and linked to, its immutable assembly; an assembly cannot embed later MAT state. Every MAT identifies its situated CEE, pins local substrate and transformation versions, and retains evaluation/evidence bindings. The local transformation is distinct from assembly projection transformations. Its representation is CEE-controlled and payload retention is policy-dependent; preserves_assembly_semantics and preserves_assembly_authority are mandatory. A MAT cannot be canonicalized as a CKC. |
assembly.schema.yaml; materialization.schema.yaml; OAuth assembly.yaml, materialization-agent.yaml, and materialization-review.yaml |
First-class-record, no-retrospective-embedding, trace, local-transformation, representation, semantic-preservation, authority-preservation, and binding negatives in test_icla_7_contract_projection_separation.py and test_oauth_042.py; explicit local-transformation input and CEE-side access-handle cases in test_mandate_and_materialization.py |
Whether a local representation actually preserves the assembly’s meaning and authority bounds, and whether proposed reuse changes canonical commitments sufficiently to require governance. No institutional ownership of a local payload is inferred. |
| ICLA-8 - Evidence and measurement separation | Evidence must use an identified submission path and retain assembly and execution lineage. When a versioned transformation is used to construct the submitted report, provenance retains its identifier and version. Governed measurements reference governed definitions; non-standard measurements are excluded from comparison and threshold decisions. The Gateway records schema conformity and measurement conformity separately from qualification, so a schema-valid bundle can still be rejected for insufficient governed evidence. | evidence-bundle.schema.yaml; OAuth evidence-bundle.yaml and governance-decision.yaml |
Conditional transformation-reference checks in test_icla_8_evidence_separation.py; schema-valid rejection and threshold-result separation in test_evidence_gateway.py; candidate-authority, evidence-lineage, and report-provenance cases in test_oauth_042.py |
Schema conformity and transformation traceability do not determine substantive correctness, semantic fidelity of the transformation, evidential sufficiency, measurement interpretation quality, or the institutional relevance of evidence; these remain qualified and governed judgments. |
| ICLA-9 - Governed revision and activation | Canonical change requires an impact record and approved decision. Impact propagation identifies the assessment scope without mutating, invalidating, or blocking canonical state by itself. Succession appends a complete immutable successor and decision-linked delta only when its predecessor is the latest appended CKC; stale predecessors are rejected without creating a branch or moving the active pointer. Activation remains a separate exact pointer transition. An eligible retained CKC can become current only through a new approved reactivation decision, without claiming a new append; the resulting snapshot preserves unrelated capability entries and pointer mappings. | governance-decision.schema.yaml; ckc.schema.yaml; OAuth capability-registry.yaml, governance-decision.yaml, and ckc-verify-v10.yaml |
Structural decision/append/reactivation checks in test_icla_9_governed_activation.py; stale-predecessor rejection, append, activation, separately authorized reactivation, pointer-map preservation, and immutability cases in test_activation.py; non-mutating impact scope in test_lineage_and_impact.py; governed replay in test_oauth_042.py |
Completeness of impact assessment, whether policy or governance makes an affected item inadmissible, legitimacy of decision authority, substantive adequacy of the successor and delta, and appropriateness of activation or reactivation. |
| ICLA-10 - Reproducibility | Retained assemblies pin CKC and evaluation-contract versions and retain source, policy, projection-transformation, access, and retention metadata. Every retained execution identifies a separate CEE-side MAT whose record retains assembly/CEE references, local substrate/transformation, hash/access metadata, and versioned evaluation/evidence bindings. Append-only storage and activation tests preserve earlier snapshots and references. No disposal operation is claimed by the companion. | assembly.schema.yaml; materialization.schema.yaml; OAuth assembly.yaml, materialization-agent.yaml, materialization-review.yaml, evidence-bundle.yaml, and historical records embedded in capability-registry.yaml |
Separate materialization identity, hash/access, interpretation-binding, and execution-reference positives and negatives in test_icla_10_reproducibility.py and test_oauth_042.py; test_storage.py; historical-snapshot and rollback cases in test_activation.py |
Whether retained metadata is sufficient to explain, reproduce, and interpret the assembly and measurement report under applicable access and retention policy; authorization and consequences of later disposal after protection expires. |
| ICLA-11 - Governed capability formation | Candidate and submitted proposals remain pre-institutional and identity-free; their lifecycle states cannot be assigned to an institutional CAP-* identity. Proposals retain general supporting-record references and may carry directional proposed relations to existing capabilities without preassigning the future identity. Submission does not itself require a positive continuity judgment. Formation/promotion requires a submitted proposal with a justified expectation that the responsibility will recur or remain institutionally required over a declared horizon; that justification may be observed, prospective, or mixed. Promotion also requires an authorized review decision, assigns one new identity, records approved capability metadata and proposal-traceable capability-to-capability relations, appends one complete immutable CKC v1 with retained origins, preserves a formed state without an active pointer, and performs initial activation separately. The formed Registry relation set must equal the prior relation set plus the approved relations; activation preserves it. |
capability.schema.yaml; capability-registry.schema.yaml; capability-proposal.schema.yaml; governance-decision.schema.yaml; ckc.schema.yaml; OAuth candidate capability-proposal.yaml; complete history-driven auth-evolution-formation trace |
Proposal/identity, supporting-record provenance, promotion-time continuity, approved-metadata/relation, and institutional-lifecycle boundary checks in test_icla_11_formation_authority.py; model-vocabulary checks in test_resolution_and_assembly.py; profile-boundary cases in test_profiles.py; positive, negative, no-partial-effect, general-record, locator-resolution, Registry-relation, lineage, and activation cases in test_auth_evolution_formation.py |
Proposal-generation or discovery effectiveness where used; adequacy and semantic trustworthiness of supporting records and their provenance, the continuity expectation, and declared horizon; responsibility boundary, ownership, overlap, value, relation appropriateness, and promotion judgments; longitudinal organizational benefit. |