The four deterministic views of one .gram file · r0

Archived revision r0, recorded 2026-10-14T07:58:14.270Z. Current page: Document views and the shared record vocabulary.

One source, several useful views

A .gram file remains the canonical source. Core resolves it with a purpose-specific template; the Viewer renders the resulting ResolvedView/1. The four built-in templates are Project Tracker, Journal, Operations and Knowledge, not separate documents to maintain. Core resolves eligibility deterministically from source records, fields and explicit signals. AI records source facts; it does not invent a screen or write a ViewSpec.

Match the source structure to the work

• Project Tracker organizes tasks, goals, progress and risks. Set each task x only when its status is sourced; otherwise leave x unset and the projection reports unknown. Link every task to its goal. Progress counts completed and done as completed and superseded, cancelled and canceled as closed_other, with all other or absent statuses in the open total; an unsourced task status still displays as unknown. Goals tally only tasks explicitly linked to them.
• Journal: prefer event records with at; dated headings still work as separate heading-derived entries, not event records. For a sourced past fact, submit it now and use revision effective_at only for when that fact took effect—not to fabricate a past revision.
• Operations eligibility requires a risk, a dated event, and at least one system, service or component; risks need sourced x status. An incident needs an explicitly linked event with an incident, outage or failure tag. A verified recovery needs a recovery, restored or restoration event linked to the risk and a supports or implements relation to an evidence record. Metrics record value, unit and observed, but are not an Operations component or eligibility signal.
• Knowledge brings events and relationships together with both event and revision history, for evidence-rich development or research narratives.

Three distinct time axes

Do not collapse event time, knowledge time and recording time:

1. Event time comes only from event at, task due or metric observed, as appropriate. Missing dates are undated; recorded_at never fills them in. A dated section heading is its own heading-derived entries[] signal, not a record event.
2. Knowledge time is the selected revision's effective_at, or unknown when absent. It answers what the file represented as true at that effective point; no date is inferred.
3. Recorded time is the revision's recorded_at. It supports reviewing when the document itself changed.

Evidence, unknown state and honest empty views

Displayed states require explicit source evidence and retain links to their basis. A risk is open only with explicit x of open, active or blocked; absent or unsupported status is unknown. Event content alone does not prove an incident. A recovery assertion without its linked evidence is not verified. Live health cannot be inferred from a record or metric: it remains unknown; an observation time may be shown as “last observed,” not as current health. If a status or relationship lacks evidence, show unknown rather than guessing.

Widgets with no supporting data are omitted; the view reports missing requirements where applicable rather than filling the space with invented values. A missing metric is not zero, and a missing event date is not a revision date.

How recommendations work

Core resolves the selected .gram and template through the embedded ViewSpec/1, returning ResolvedView/1; the Viewer renders only that result and does not re-interpret filters, sorting, grouping, aggregates or limits. Eligibility and recommendations are deterministic, evidence-based and model/network-free, with stable ties and explicit missing requirements. Users can select any built-in template in the Viewer regardless of recommendation.

Canonical contract

These behaviors follow thegram-format/spec/projection.md: “ProjectionResult/1”, “Evidence-based state”, “View resolution and ViewSpec/1”, “Dated section entries”, and the optional status_counts and progress conventions. The specification defines event_time from at/due/observed, knowledge_time from revision effective_at, and recorded_time from recorded_at; it also requires basis record IDs for derived claims and says empty evidence must not be presented as verified.

Evidence

This article summarizes the canonical projection contract, not a claim about service deployment or availability.

Source and renderer evidence

Canonical source SHA-256

dd469c194d96bf48d4ab911acc91ec5f4f07f9f0c4ca34cf1a0fa17b68cfbb6c

Selected revision

r0 · sha256:5fd4ba302a99563536232a3776c4a373b3089c541d1eb098f2a9776aed015488

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