Worked example: a fictional export decision with an auditable handoff · r0

Archived revision r0, recorded 2026-10-12T08:08:29.062Z. Current page: Worked example: a fictional export decision with an auditable handoff.

Scenario (fictional)

Northstar Cooperative is an invented organization. Its team is deciding how to share a maintenance handoff with an external reviewer. This scenario and every result below are fictional; they are not a Thegram customer, deployment, or performance report. The team needs enough context for review while avoiding accidental disclosure of a private working file.

Decision and records

Decision: create a minimal redacted copy of handoff.gram for the reviewer, rather than upload the original file. The fictional reviewer only needs the accepted decision, test evidence, and the next owner’s task. The source document includes unrelated internal notes, so the owner keeps it local and creates a separate copy after reviewing every record and relationship.

The evidence record says the owner reopened the redacted copy and confirmed that it contains the decision, one supporting test result, and no unrelated note. The risk record identifies a possible missed relationship that could reintroduce sensitive context. A review task asks a second person to compare the copy with the intended scope before sending. The source record points to the format and renderer API documentation, because the team is comparing a file-centered share with an ephemeral browser render. Links are explicit: evidence supports the decision; risk blocks completion until review; source supports the boundary explanation.

A simplified fictional record relationship is:

D redacted-copy
t Share a reviewed redacted copy
x proposed

E reopened-copy
t Reopened the fictional redacted copy
supports redacted-copy

X missed-link
t A retained link might expose unrelated context
blocks external-handoff

T second-review
t Have a second person compare scope
x open

These values are examples only. In a real file, the person creating a record would describe observed evidence, link to the appropriate source record, and let Core write revision provenance. They would not invent a recorded timestamp, runtime actor, or chain hash in authored prose.

Action sequence

1. Identify the canonical source file and do not overwrite it with a redacted export.
2. Create a copy with a clear document identity; inspect all records, rich blocks, references, and links, not only visible prose.
3. Add separate decision, evidence, risk, and task records. Use supports from evidence to decision, and blocks from the risk to the task or release condition as appropriate.
4. Ask a second reviewer to inspect the exact outgoing copy and verify that links and referenced sources stay within the approved scope.
5. Only after that check, deliver the specific copy through the channel authorized by the owner. If using a web renderer, remember it receives the bytes and is not durable storage.

Tradeoffs and boundary

A copy reduces the chance of disclosing unrelated notes, but creates a second artifact that can become stale. The task and relationships make that cost visible: record which source revision was used and update the copy deliberately if the decision changes. A link to a browser view would not create a persistent document library. The example does not make a security guarantee; it demonstrates how to expose a risk and make a human check part of a decision.

Next-agent prompt

Inspect the fictional handoff.gram export without editing the canonical source. Verify every record, rich block, relation, and external reference against the intended reviewer scope. Report which records are included, which could expose unrelated information, and whether the second-review task is satisfied. If ambiguity remains, stop before delivery and name the exact unresolved relationship. Do not claim transmission, publication, or approval unless the owner explicitly authorizes it.

Further reading

Use the format language guide for record and relation syntax, the renderer API for what a browser submission does, and the owning storage/service contract for any account-backed share. This example is intentionally fictional and demonstrates structure, not product usage evidence.

Source

Source: .gram record and relation syntax

Reference: https://github.com/clab-one/thegram-format/blob/main/spec/language.md

Source: Web renderer API and submission boundary

Reference: https://github.com/clab-one/thegram-web-render/blob/main/docs/api.md

Source: Vault storage and authorization contract

Reference: https://github.com/clab-one/thegram-vault/blob/main/docs/SPEC.md

Decision

Decision: Share reviewed redacted copy · proposed

Northstar Cooperative is fictional; share only a separate copy after intended scope is verified.

Reference: → Supports: Fictional copy reopened and checked

Evidence

Evidence: Fictional copy reopened and checked · observed

In the invented scenario, the copy contains only the chosen decision, test, and next task.

Reference: → Supports: Share reviewed redacted copy

Risk

Risk: A retained relation may expose unrelated notes · Open

A visible prose review can miss context reachable through an explicit relation or reference.

Reference: → Blocks: Compare every outgoing record and link

Task

task: Compare every outgoing record and link · This task is still open

Second reviewer checks the exact export copy before authorized delivery.

Reference: → Depends on: Share reviewed redacted copy

Source and renderer evidence

Canonical source SHA-256

39dde1825113fb1ea0a615e1ed0e24890a37c11df6eee3e3c39ddad4469b7ad7

Selected revision

r0 · sha256:7e17a3b44d7886f34554e98ea408f3394feb4360b0ab7c8a7829ae4102488910

Local renderer

configured local Thegram renderer · API thegram-web-render/1

Core source

git+https://github.com/clab-one/thegram-format.git?rev=b16489e1d0d77d38f82d2f61776524737aa31557#b16489e1d0d77d38f82d2f61776524737aa31557

Canonical source: 0.gram