A Fictional Project Memory Workflow from Question to Linked Records

@gram 2
doc blog-project-memory-workflow
t A Fictional Project Memory Workflow from Question to Linked Records
d A worked fictional import-preview project shows how decisions, evidence, requirements, tasks, risks and events can form a useful .gram memory.
tag examples
view document
::rich
# 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

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

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

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?

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.

[[src-scenario-fictional]]
[[src-memory-policy]]
[[src-format-guidance]]
[[prj-northstar]]
[[goal-preview]]
[[dec-local-preview]]
[[evd-local-review]]
[[req-duplicate-columns]]
[[evd-duplicate-case]]
[[ev-import-check]]
[[task-date-cases]]
[[risk-large-file]]
[[knowledge-example]]
::end
SRC src-scenario-fictional
t Fictional Northstar scenario
d This is an invented teaching scenario written for this article; it is not external evidence or a real project.
SRC src-memory-policy
t Project memory policy
d Public local integration guidance on durable decisions, evidence, tasks and risks.
ref https://github.com/clab-one/thegram-mcp/blob/3a1411a/policy.md
SRC src-format-guidance
t Typed document and link guidance
d Internal format reference reviewed at revision 625edec; not publicly available.
PR prj-northstar
t Northstar Cooperative CSV preview (fictional)
d Invented project used only to illustrate a linked memory workflow.
x active
source src-scenario-fictional
G goal-preview
t Preview CSV imports locally (fictional)
d The fictional team wants a local preview before a human confirms the import.
x active
part-of prj-northstar
source src-scenario-fictional
D dec-local-preview
t Keep processing local until confirmed (fictional)
d The fictional team accepts local processing and requires human confirmation before commit.
x accepted
part-of prj-northstar
source src-scenario-fictional
E evd-local-review
t Local-only preview review fixture (fictional)
d In the scenario, a fictional privacy review supports local processing with a confirmation step; it is not a real report.
supports dec-local-preview
source src-scenario-fictional
R req-duplicate-columns
t Detect duplicate column names (fictional)
d The fictional import preview must detect duplicate headers before confirmation.
x accepted
part-of goal-preview
source src-scenario-fictional
E evd-duplicate-case
t Duplicate-header fixture (fictional)
d An invented small fixture is said to exercise duplicate column detection; no external result is asserted.
supports req-duplicate-columns
source src-scenario-fictional
V ev-import-check
t Duplicate-header check event (fictional)
d The fictional test event recorded the small fixture result and implements the duplicate-header requirement only.
at 2026-10-12T10:00:00Z
implements req-duplicate-columns
part-of prj-northstar
source src-scenario-fictional
T task-date-cases
t Add regional date-format fixtures (fictional)
d The fictional team has not verified date parsing across regional formats; this is an open example task, not real work.
x open
part-of goal-preview
source src-scenario-fictional
X risk-large-file
t Large-file behavior remains unverified (fictional)
d A small fictional fixture does not establish behavior for a 20,000-row import; this open example risk blocks the preview goal.
x open
part-of prj-northstar
blocks goal-preview
source src-scenario-fictional
K knowledge-example
t Keep evidence, decisions and work distinct
d In this fictional scenario, evidence supports a decision or requirement, while tasks and risks describe separate unresolved work.
source src-memory-policy