@gram 2
doc blog-view-templates
t The four deterministic views of one .gram file
d A guide to Project, Journal, Operations and Knowledge views, their evidence and time axes.
tag viewer
view document

::rich
# 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.
::end