Pattern Binding Contract

Teleology

Binding pattern rows to source-backed evidence

pattern_binding_contract binds each pattern row to a source-available bundle, public runtime ref, authority handle, scope boundary, and secret-exclusion result record, with synthetic rows allowed only as controls. pattern_binding_contract is the public root component that binds pattern rows to source-available source bundles, public runtime refs, authority-chain handles, scope boundaries, and secret-exclusion result records. Synthetic rows are allowed only as regression controls or negative cases; they are not product evidence.

Purpose

Why a lone pattern row cannot self-publish

A mined pattern row reads like a finished insight, so this component exists to decide whether it can be admitted to the public surface and under exactly what evidence and ceiling. A mined engineering pattern is a tempting thing to publish on its own. It reads like a self-contained insight, so it is easy to lift a single row out of a private ledger and present it as a finished public claim. This component exists to stop that. It answers one question: can a given pattern row be admitted to the public surface, and if so, under exactly what evidence and what ceiling?

Binding, not display

The check binds rather than displays: every row must name a source bundle, governing standard, and scope boundary, while duplicates, overclaims, and standalone-leaf rows are rejected and negative cases run alongside. The check is binding rather than display. Every pattern row must name a source bundle that points at a real public runtime ref or regression-harness ref, a governing standard, and an scope boundary. A row that lacks any of these, duplicates another row's id, or claims to be a standalone public leaf is rejected. The same validator runs deliberate negative cases alongside the positive control. The result record shows that good rows pass and that each known failure mode is still caught.

Truth accounting and route-readiness

Truth accounting separates runtime-metadata rows from real pattern-ledger imports so accepted-row counts are not read as system progress, and route-readiness keeps selection component-first and fixture-bound. The less obvious idea is truth accounting. When an exported bundle is validated, the component separates rows that merely describe runtime metadata from rows that represent a real pattern-ledger import, and records that a high accepted-row count is not the same as system progress. This guards against the quiet inflation where counting accepted rows starts to read like a measure of how much real work has landed. The route-readiness layer closes the matching gap on the selector side: a row can look selectable in isolation, but it is only admitted through the component that owns it, its fixture contract, and a gate that refuses to let hard no-standalone rows appear as selectable targets.

Public contract

The four validators and their result records

validate_pattern_bindings, validate_source_capsules, validate_reference_capsules, and the authority-chain and ceiling checks run over one fixture and write command-owned result records. validate_pattern_bindings checks required binding fields, rejects duplicate pattern ids, and flags a row that overclaims source authority or public-leaf readiness. validate_source_capsules and validate_reference_capsules check that each bundle names a runtime ref and keeps its body out of the result record. validate_authority_chain_handle_resolver rejects an unsupported handle that still implies authority, and validate_authority_ceiling records whether the two overclaim negative cases were actually observed. validate runs these checks over one fixture and writes command-owned result records under receipts/first_wave/pattern_binding_contract/.

Route-readiness closes the selector gap

The exported bundle carries the route-readiness overlays as public bodies, and validate_substrate_bundle recomputes the four checks then validates the selector so a row cannot look selectable without opening its owning component. The exported system bundle also carries the source route-readiness selector overlays as public source-open bodies: examples/pattern_binding_contract/exported_route_readiness_bundle/. validate_substrate_bundle recomputes the same four checks over the imported pattern ledger, then calls validate_route_readiness_bundle against the route-readiness audit, row-to-component router, route cards, fixture specs, decision matrix, dependency DAG, internal routing graph, and copied source validation report. This closes the old gap where a mined pattern row could look selectable without opening the component bundle that owns it.

Which command answers selector admission

For selector admission rather than generic binding, cold readers run microcosm pattern-route-readiness validate-bundle, with the older validate-route-readiness-bundle action kept as a compatibility route. Cold readers should use microcosm pattern-route-readiness validate-bundle against examples/pattern_binding_contract/exported_route_readiness_bundle/ when the question is selector admission rather than generic pattern binding. The older pattern-binding validate-route-readiness-bundle action remains a compatibility route to the same validator.

Shape

flowchart LR subgraph Inputs["Pattern-binding inputs"] Patterns["Pattern rows id, governing standard, scope boundary, source refs, projection posture"] Bundles["Source bundles metadata-only refs to public runtime or regression harness"] Handles["Authority-chain handles resolver result records"] end Validator["pattern_binding_contract required fields, duplicate ids, bundle resolution, secret-exclusion scan"] subgraph Negative["Refusal floor"] Dup["Duplicate id rejected"] Leak["Private body leak rejected"] Overclaim["Public-leaf overclaim rejected"] Unsupported["Unsupported authority handle not upgraded"] end subgraph Bundle["Exported-bundle path"] Truth["Truth accounting runtime-metadata rows vs real pattern-ledger import"] RouteReadiness["Route-readiness selector component-first admission, fixture contract, hard no-standalone gate"] end Result records["Result records refs, digests, counts, verdicts; body text omitted"] Patterns --> Validator Bundles --> Validator Handles --> Validator Validator --> Negative Validator --> Bundle Truth --> RouteReadiness Negative --> Result records Bundle --> Result records

Evidence binding

Accepted component row: core/organ_registry.json::implemented_organs[pattern_binding_contract]. Accepted component row: core/organ_registry.json::implemented_organs[pattern_binding_contract]. Evidence class: core/organ_evidence_classes.json::organ_evidence_classes[pattern_binding_contract] with rank 5 semantic-validator authority. The runtime locus is src/microcosm_core/organs/pattern_binding_contract.py, with focused coverage in tests/test_pattern_binding_contract.py.

Paper bundle authority: core/paper_module_capsules.json#paper_module.pattern_binding_contract. Paper bundle authority: core/paper_module_capsules.json#paper_module.pattern_binding_contract. Mechanism source: core/mechanism_sources.json#mechanism.pattern_binding_contract.validates_public_pattern_bindings.

Reader evidence routing

Start with paper_modules/pattern_binding_contract.json for the bundle payload, then open standards/std_microcosm_pattern_binding_contract.json to check the required fields, public/private boundary, source-open body import floor, route-readiness rules, and result record expectations. Start with paper_modules/pattern_binding_contract.json for the bundle payload, then open standards/std_microcosm_pattern_binding_contract.json to check the required fields, public/private boundary, source-open body import floor, route-readiness rules, and result record expectations.

Use core/fixture_manifests/pattern_binding_contract.fixture_manifest.json before inspecting fixtures or exported bundles. The manifest and the source_module_manifest.json files name the copied source body floor; result record payloads carry source refs, digests, anchors, counts, verdicts, and omission result records rather than inlining body text. Use core/fixture_manifests/pattern_binding_contract.fixture_manifest.json before inspecting fixtures or exported bundles. The manifest and the source_module_manifest.json files name the copied source body floor; result record payloads carry source refs, digests, anchors, counts, verdicts, and omission result records rather than inlining body text.

Prior Art Grounding

Pattern-language lineage

The component follows the software pattern-language tradition of making reusable engineering structures explicit and reviewable, with the Hillside patterns library as its direct prior-art family. This component follows the software pattern-language tradition of making reusable engineering structures explicit, named, and reviewable. The Hillside patterns library is the direct prior-art family for treating patterns as shared vocabulary rather than loose implementation notes.

Provenance and supply-chain attestation

The binding layer borrows provenance and supply-chain attestation shapes from W3C PROV, SLSA, and in-toto, applied to pattern rows and route-readiness selectors rather than launch certification. The binding layer also borrows from provenance and supply-chain attestation patterns. W3C PROV motivates the source/ref/evidence relation shape, while SLSA and in-toto motivate digest-bound artifact claims and step-level metadata. Microcosm applies those ideas to pattern rows and route-readiness selectors, not to launch certification.

Re-entry condition: if copied source bodies, route-readiness overlays, or negative-case rules change, rerun the validate, validate-system-bundle, and validate-route-readiness-bundle commands under Validation Result record Path and update this paper module plus standards/std_microcosm_pattern_binding_contract.json from the new result record fields. Re-entry condition: if copied source bodies, route-readiness overlays, or negative-case rules change, rerun the validate, validate-system-bundle, and validate-route-readiness-bundle commands under Validation Result record Path and update this paper module plus standards/std_microcosm_pattern_binding_contract.json from the new result record fields.

Validation Result record Path

From microcosm-substrate/, reproduce this page's proof boundary with temporary result records:

What a pass shows

A pass means the fixture, system-bundle, and route-readiness result records all show status: pass with metadata-only authority handles, with Scope limit stating what it does not certify. A pass means the fixture, system-bundle, and route-readiness result records all show status: pass with metadata-only authority handles; see Scope limit for what a pass does and does not certify.

Inspect result record fields, not markdown constants

The current authority is the runtime result record set, and cold readers should read result record fields such as status and secret_exclusion_scan rather than markdown constants or a separate sign-off result record. The current authority is the runtime result record set under receipts/first_wave/pattern_binding_contract/; do not cite a separate pattern-specific sign-off result record unless an sign-off-lane artifact is actually present. Cold readers should inspect result record fields rather than markdown constants: status, secret_exclusion_scan, source_open_body_imports, truth_accounting, route_readiness_summary, selection_contract, and source_manifest.