--- title: The four deterministic views of one .gram file · r0 description: A guide to Project, Journal, Operations and Knowledge views, their evidence and time axes. Archived revision r0 (2026-10-14) of /guides/view-templates/. url: https://docs.thegram.one/guides/view-templates/revisions/0/ lang: en tier: legacy source: https://docs.thegram.one/sources/view-templates/revisions/0.gram revision_of: https://docs.thegram.one/guides/view-templates/ revision: 0 date_published: "2026-10-14T07:58:14.270Z" 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 --- # 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](/guides/view-templates/).
## One source, several useful views {#h0-1} 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 {#h0-3} - **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 {#h0-5} 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 {#h0-8} 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 {#h0-11} 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 {#h0-13} 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 {#h0-15} This article summarizes the canonical projection contract, not a claim about service deployment or availability.