Skip to content
Thegram Docs

A Fictional Project Memory Workflow from Question to Linked Records · r1

Archived revision r1, recorded 2026-10-12T13:08:42.624Z. Current page: A Fictional Project Memory Workflow from Question to Linked Records.

This worked example is entirely fictional. Northstar Cooperative is an invented team, every project fact and record below is made up for instruction, and the dates are illustrative. Nothing here reports an actual customer, release, test result or product commitment. The point is to show how a team can connect readable prose to typed, queryable records instead of leaving decisions as disconnected meeting notes.

Start with the question, then the document

Section titled “Start with the question, then the document”

Imagine Northstar is considering a preview that imports a partner’s CSV into a local workspace. A useful project document begins with an Overview, Architecture, Plan, Decisions and Log. The Overview states the intended outcome and scope; Architecture explains the data path; Plan lists unresolved work and risks; Decisions records accepted trade-offs; Log records events that actually happened. A document can remain readable while its records support queries and explicit relations.

An example prompt for an agent is: “In the fictional Northstar project, what decision governs where imported rows are processed, what evidence supports it, and what blocks the preview goal?” The answer should retrieve the project and goal, read the decision with its linked evidence, and inspect risks that block the goal. It should distinguish the accepted local-only decision from the unresolved large-file risk. The agent must not invent evidence from the prose or infer a relation just because two descriptions sound similar.

Connect each claim to the right record

Section titled “Connect each claim to the right record”

The fictional project is Northstar Cooperative. Its goal is a local preview for CSV import. Its accepted decision is to keep preview processing on-device until a person confirms before commit. A fictional privacy review supports that decision. A separate requirement says the import must detect duplicate column names; a fictional test event records a passing duplicate-header fixture and implements that requirement. These records distinguish rationale from an implementation event.

The example also keeps two open questions visible. A task asks for regional date-format fixtures because the team has not checked that behavior. A risk says a small test fixture does not establish behavior for a 20,000-row import and blocks the preview goal. The task is not evidence for the risk, and the risk does not invalidate the accepted local-processing decision. Keeping them separate helps a reader answer “What did we choose?” and “What remains unverified?” without conflating certainty and work.

Use links as a small model

Section titled “Use links as a small model”

In this graph, the goal belongs to the project; the decision and risk belong to the project; the requirement belongs to the goal; the evidence supports its decision or requirement; and the test event implements the requirement. The task belongs to the goal but has no fabricated dependency on a completed test. The risk blocks the goal. A source record explicitly labels the whole scenario as fictional rather than claiming that an external document verifies it.

The prompt can be narrowed to an actionable follow-up: “List the open Northstar task and risk, state which one blocks the goal, and do not mark either complete.” A real team can then ask a human owner to verify the work and update status only after evidence exists. A record’s status is not a substitute for reading its description or checking its links.

Why keep both prose and records?

Section titled “Why keep both prose and records?”

The body tells a new teammate how the pieces fit together; typed records let a tool retrieve the accepted decision, the evidence relation, the open task and the blocker separately. Source and evidence provenance remain distinct: a fictional source identifies a teaching example, while actual source records in a real project should cite the material inspected. Statuses apply to this fictional scenario only. If adapting the pattern, replace invented details with verified facts, link real evidence, identify responsible people only when known, and read back the rendered document after writing.

The example does not prescribe a single ontology for every team. A tiny project may need only a project, decision, source and task. A regulated workflow may require stronger review and access controls outside the memory file. Explicit relations improve traceability but can expose more context to a reader; inspect links before sharing a copy. The document should make uncertainty visible rather than decorate it with confident labels. For an actual Core-written revision transition, see the history walkthrough; for local, Vault, and Drive access boundaries, see Storage permissions.

Source: Fictional Northstar scenario

This is an invented teaching scenario written for this article; it is not external evidence or a real project.

Source: Project memory policy

Public local integration guidance on durable decisions, evidence, tasks and risks.

Reference: https://github.com/clab-one/thegram-mcp/blob/3a1411a/policy.md

Source: Typed document and link guidance

Internal format reference reviewed at revision 625edec; not publicly available.

Project: Northstar Cooperative CSV preview (fictional) · In Progress

Invented project used only to illustrate a linked memory workflow.

Goal: Preview CSV imports locally (fictional) · In Progress

The fictional team wants a local preview before a human confirms the import.

Decision: Keep processing local until confirmed (fictional) · Accepted

The fictional team accepts local processing and requires human confirmation before commit.

Evidence: Local-only preview review fixture (fictional)

In the scenario, a fictional privacy review supports local processing with a confirmation step; it is not a real report.

Requirement: Detect duplicate column names (fictional) · Accepted

The fictional import preview must detect duplicate headers before confirmation.

Evidence: Duplicate-header fixture (fictional)

An invented small fixture is said to exercise duplicate column detection; no external result is asserted.

Event: Duplicate-header check event (fictional)

The fictional test event recorded the small fixture result and implements the duplicate-header requirement only.

task: Add regional date-format fixtures (fictional) · This task is still open

The fictional team has not verified date parsing across regional formats; this is an open example task, not real work.

Risk: Large-file behavior remains unverified (fictional) · Open

A small fictional fixture does not establish behavior for a 20,000-row import; this open example risk blocks the preview goal.

Knowledge: Keep evidence, decisions and work distinct

In this fictional scenario, evidence supports a decision or requirement, while tasks and risks describe separate unresolved work.

Source and renderer evidence

Canonical source SHA-256
7aac5725a2ea5146990bc15c9556c22f8aff50ff1facc965eb9be1fda0beb88a
Selected revision
r1 · sha256:13e2b509480fd2c8008953eb17cc938a4cd47c3ccb1a2b8cef823bc5497dcc23
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: 1.gram