@gram 2
doc blog-history-walkthrough
t A Real .gram History Walkthrough
d Follow one .gram document through actual Core history, compare recorded states, and validate the downloadable source rather than treating a revision label as decoration.
tag examples
view document

::rich
# Compare the actual initial and current states

Core revision 0 contains the proposed decision and no evidence record. Core revision 1 changes that same decision to accepted and adds the fictional evidence record with an explicit supports relation. These are the actual states replayed from this document's native History/6 journal.

## Initial state: revision 0

Replay revision 0. The decision status is proposed; the evidence record is absent. This initial source embeds only records present at revision 0.

[[decision-history-example]]

## Current state: revision 1

Replay revision 1. The same decision is accepted, and the evidence record is present and supports that decision. The evidence is fictional teaching material, not a real review result.

[[decision-history-example]]
[[evidence-history-example]]

## Validate the downloaded source

Use this page's Download source action to save the canonical .gram file. Its History/6 journal is part of the download; the HTML page is only the current rendered projection. Audit the downloaded file with Core, then call gram_state for revision 0 and revision 1 and compare the decision status, evidence record, and relation. Report the revision identity returned by each state selection; do not treat a current gram_read as historical replay.

For an MCP client, gram_state selects one revision by path and exactly one revision, recorded-time, or effective-time selector. It returns the selected revision identity and resolved state. gram_read reads the current body; it does not replay history. Use the exact downloaded path.

A historical revision is read-only. To make a change based on earlier information, update current state with a new CAS-protected operation. Do not rewrite old journal entries or paste earlier bytes over the current document.

## What this example does not prove

The scenario is fictional, and its example decision is only a teaching record. It does not demonstrate synchronization to Vault or Drive, account permission, cryptographic authorship, external reproduction, or application-wide feature availability. A successful local Core audit establishes that the downloaded bytes pass that Core's history validation; it does not establish where the file came from.

[[src-core-history]]
[[src-state-api]]
[[src-fiction]]
::end

D decision-history-example
t Require a review before accepting an example change
d Fictional teaching decision. Its status changes in a later Core patch so the document journal records an actual before/after state.
x accepted
source src-fiction
SRC src-core-history
t Core History/6 and replay contract
d Current Core history format and source replay behavior; Core generates the journal.
ref https://github.com/clab-one/thegram-format/blob/main/spec/source-history-render.md
SRC src-state-api
t Core state-selection API
d Historical state selectors and selected revision identity; see the current gram_state contract.
ref https://github.com/clab-one/thegram-format/blob/main/native/temporal.rs
SRC src-fiction
t Fictional example disclosure
d The review scenario is invented for instruction and is not real operational evidence.

E evidence-history-example
d A fictional teaching record added to demonstrate an explicit supports relation; not a real review result.
t Reviewed the example change
supports decision-history-example