Skip to content

COOL IDEAS™: distinguish checkpoint facts from declaration occurrences #290

Description

@flyingrobots

Classification

COOL IDEA™ — semantic/history model made visible by the real Echo-backed checkpoint slice.

Observation

Jim's checkpoint proposition is content-addressed by its semantics: worldline, basis head, and reason. Declaring the same proposition again therefore produces the same checkpoint identity.

Echo admission is a different fact of history. Each admitted request can have its own opaque receipt and admitted tick, including a re-declaration after restart.

Those are both truthful statements:

  • “this semantic checkpoint is the same proposition”; and
  • “the proposition was declared/admitted on these distinct occasions.”

A consumer that treats checkpoint ID as an event ID will collapse meaningful history. A consumer that treats every receipt as a new semantic checkpoint will fabricate duplicates.

Evidence

The idea

Expose a bounded, Echo-backed observation that presents:

  1. the stable Jim checkpoint proposition; and
  2. the zero-or-more Echo admission occurrences that witness declarations of it.

Prefer deriving occurrences from Echo causal history, installed-operation receipts, and ticks. Add a separate Jim occurrence/association proposition only if the history model cannot answer the query without one.

Semantic questions to settle

  • Does an identical request always receive a new admission occurrence, or may Echo return an idempotent/no-op outcome?
  • What makes an occurrence discoverably associated with the checkpoint proposition?
  • Which receipt/tick fields are stable public evidence versus internal scheduler detail?
  • How are pruned or partially retained occurrences represented?
  • Does a redeclaration after restart differ from replay recovery?
  • What ordering is promised across worldlines, if any?

Constraints

  • Do not change checkpoint proposition identity merely to make events look unique.
  • Do not reproduce Echo digests or identity algorithms.
  • Do not create a TypeScript event ledger or rely on process-local correlation maps.
  • Runtime projections must reconstruct from Echo history/WAL after restart.
  • A checkpoint remains distinct from a CausalAnchor.
  • Missing or pruned evidence must be explicit, bounded, and typed.

Acceptance criteria

  • Document checkpoint proposition identity separately from declaration-occurrence identity.
  • Provide a bounded native observation keyed by opaque checkpoint ID.
  • Return opaque Echo receipt/tick evidence for each retained occurrence.
  • Distinguish first declaration, identical redeclaration, replay recovery, and unavailable/pruned history.
  • Prove restart reconstruction without a process-local checkpoint→occurrence map.
  • Prove repeated declarations do not mint fake checkpoint propositions.
  • Give timeline consumers an unambiguous rule for grouping versus listing occurrences.
  • Keep TypeScript as a projection/caller layer only.

Related, not duplicate

Metadata

Metadata

Assignees

No one assigned

    Labels

    causal-ropeCausal rope text authority roadmapenhancementNew feature or requestsliceImplementable roadmap slicetext-authorityText authority and storage invariantswork-in-progressCycle or PR is intentionally in progress and not ready to merge

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions