Overview
CoreTex improves a versioned, content-addressed memory release: six optional pipeline hooks, their parameters and capabilities, and any safe derived artifacts that release needs. What miners improve is that shared behavior, not anyone's private store.
There is one canonical CoreTex. A frontier composition maps three profile
slots — conversational preferences (conv.pref.v1), document tooling
(doc.tool.v1), and structured events (event.schema.v1) — onto the accepted
releases that currently occupy them. Those names are slots in one state, not
competing versions.
The chain stores compact commitments and transition order. The full runtime, release manifests, transition artifacts, and evaluation reports remain off chain and are addressed by their hashes. A miner or validator obtains the committed bytes from the public artifact surface and verifies them locally.
Each accepted submission answers one question:
Does this candidate improve the exact parent occupying its target slot, under the active evaluation law and epoch context, while preserving safety and resource constraints?
The coordinator fetches that parent release and module and scores the candidate against it on the same cases, in a bounded, networkless worker. A candidate that does not beat the live parent is refused. In 1.1.0, each profile starts from its release-bound initial module. The reference runtime still defines the protected genesis floor; it is distinct from the module a miner must beat.
A candidate that passes is converted into a coordinator-authorized mining receipt. The rig operator broadcasts that receipt. The mining contract checks rig eligibility and receipt continuity, the CoreTex verifier checks the CoreTex-specific commitments, and the registry advances the state root.
The normal improvement loop is:
read current state -> build candidate -> dry-run -> submit -> evaluate
-> accepted receipt -> broadcast -> new current state
All later miners, validators, and portable installations start from the newly accepted state.