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
Different memory workloads may use different profile releases. A conversational preference store, a document/tool store, and a structured event store may use different ranking or packing strategies. The canonical frontier manifest maps profiles to their active releases and records shared components once.
Profile selection is controlled by the application and fixed before query-time serving. A candidate declares its affected profile and components; the evaluator applies the corresponding benchmark and composition rules.