Examples

A Real .gram History Walkthrough

Follow one .gram document through actual Core history, compare recorded states, and validate the downloadable source rather than treating a revision label as decoration.

Download r0 source
Explore as .gram

Download exact selected revision source

Source
r0 · Now
Document#examples

Start with the initial state

This teaching document begins at its actual Core revision 0. The decision below is proposed in this initial state. No evidence record is present yet, so this revision embeds only records that already exist.

The revision 0 decision

Inspect the decision record in the initial replay. Its status is proposed. The example is fictional and illustrates a document state, not a real product decision or review.

Decision
Require a review before accepting an example changeproposed

Fictional teaching decision. Its status changes in a later Core patch so the document journal records an actual before/after state.

Read history with Core

A current read returns the current body; it does not replay history. Use Core's state operation with a revision selector to reconstruct a historical state, and record the resolved revision identity returned by Core. Change discovery is incremental from a cursor, while a range query is bounded and is not a complete replay.

The source records below define the format, state-selection contract, and fictional-example boundary.

Source
Core History/6 and replay contract

Current Core history format and source replay behavior; Core generates the journal.

https://github.com/clab-one/thegram-format/blob/main/spec/source-history-render.md
Source
Core state-selection API

Historical state selectors and selected revision identity; see the current gram_state contract.

https://github.com/clab-one/thegram-format/blob/main/native/temporal.rs
Source
Fictional example disclosure

The review scenario is invented for instruction and is not real operational evidence.

What this example does not prove

The scenario is fictional. It does not demonstrate synchronization to Vault or Drive, account permission, cryptographic authorship, external reproduction, or application-wide feature availability. A successful Core audit establishes that the source passes that Core's history validation; it does not establish where the file came from.