Memory State
CoreTex exposes three top-level commitments:
| Commitment | Meaning | When it changes |
|---|---|---|
coreVersionHash |
The CoreTex bundle: evaluator law, scorer, counter and resource law, renderer, schemas, runtime/miner ABIs, benchmark law, and replay runtime | When an admission-critical protocol or runtime component changes |
liveStateRoot |
The current accepted M1-M6 releases, parameters, composition, and canonical derived-state commitments | On an accepted memory improvement |
epochContextRoot |
The evaluation context for an epoch, including the corpus and benchmark commitments used to judge work | When a new epoch context is installed |
For ordinary mining, coreVersionHash remains fixed while liveStateRoot
advances. A miner binds a candidate to both the current bundle and its exact
parent state. If another accepted candidate moves the parent first, the stale
candidate must be rebased and evaluated again.
Canonical events and derived state
An end user's local memory contains canonical events: messages, observations, documents, tool activity, corrections, validity intervals, and provenance. These records remain off chain under that user's scope.
M1, M2, and M3 may produce derived annotations, relations, conflict records, summaries, clusters, or consolidation artifacts. The canonical event log remains the source of truth. Derived state must be provenance-linked and either content-addressed by the accepted release or deterministically rebuildable from the canonical events under that release.
The on-chain state commits to generalized memory behavior. Each installation keeps its private memories locally. After synchronization, two installations using the same accepted release apply the same mechanisms to their own event logs.
Profiles and composition
The three profile names are slots in the current composition, not alternate CoreTex versions. A conversational preference store, a document/tool store, and a structured event store may use different ranking or packing strategies, and each slot holds its own accepted M1-M6 release.
The frontier manifest maps each slot to its active release root and records shared components once. A candidate names the one slot it is improving; the other two slots remain the parent's. After admission, only the named slot moves.
Profile selection is controlled by the application and fixed before query-time serving. The evaluator applies the benchmark and composition rules for the declared slot, executing that slot's exact parent on the same cases as the candidate.