# Live screen templates and panels

> The three starting templates, the six panel kinds and exactly what each one discloses, plus the panel budgets and refresh rates a published screen runs under.

Canonical page: https://anectico.com/docs/investigate/live-screen-templates/


A [live screen](/docs/investigate/live-screens) is built from a small closed set of panel kinds.
There is no free-form widget and no query box: every panel is one of the six below, and what each
one can put on a public display is fixed by its kind rather than by what its source happened to
return. Your agent chooses a template or a list of panels. The Console does not create or edit
screens.

## Ask your agent

> Create a live screen from the `engineering` template. Tell me which labels you took out of the
> project and what you did not find. Do not publish it.

| Job | MCP tool or action | CLI command |
| --- | --- | --- |
| Compose a draft from a template, or send an explicit panel list | `create_live_screen` | `anectico live screen create` |
| Replace a draft’s name and complete composition | `update_live_screen` | `anectico live screen update` |
| Render the draft as a viewer would see it | `preview_live_screen` | `anectico live screen preview` |

The agent needs `live:read` and `live:write`, and `mcp:read` and `mcp:write`. Publishing is covered in
[Put a project on a live screen](/docs/investigate/live-screens). A screen has no proof page. Its
viewing link opens the Live viewer at `/live/:screenId`, a separate path that carries a secret.

## The three templates

A template composes a **draft** from what your project actually contains. Nothing is published and
nobody is shown anything until the labels are reviewed and the screen is published.

| Template | Panels it proposes |
| --- | --- |
| `product` | Up to four trend panels built from saved insights you already saved, plus people affected and a summary note |
| `engineering` | Service health, alert state, log volume, plus people affected and a summary note |
| `combined` | Both sets, for a small team with one wall panel |

People affected is on every template. It is the one panel that answers the same question for both
audiences — how many humans is this touching — and a brand-new project can still fill it, because a
count of zero is a measurement.

Composition is bounded so that creating a screen stays one cheap call: a template inspects a limited
number of saved insights, names at most five services on a health panel, and names at most three
recorded event names in its summary. Composed panels take the slowest allowed cadence rather than the
fastest, because a template is the composition most likely to be left running unattended for months.

A template never fails because something is missing. A source you cannot read, or a project with no
saved insights, costs one panel and produces one note saying so. You get an honest screen with a
smaller set of panels, never an empty panel filling the grid — an empty panel on a wall is
indistinguishable from a broken one.

## Automatic does not mean guessing

A template discovers what a project records. It does not decide what any of it means.

- **It never invents a panel.** A panel exists because a source answered.
- **It never infers meaning from a name.** Recorded event names reach the draft's summary as names.
  Nothing decides that `checkout_completed` is a conversion, that `signup` is growth, or that a
  rising line is good news. The template says what this project records; you supply the meaning.
- **It never discloses without review.** Every string the composer took out of your project — an
  insight title, a service name, an event name — is handed back as a discovered label, and the
  draft is left unreviewed. Publishing is refused until somebody confirms that those labels are fit
  to show on a screen that does not require signing in (`labels_reviewed`). That gate applies to a
  hand-built screen too; a template is not a way around it.

That last point is the one people underestimate. Titles, event names, service names and cohort
labels are themselves disclosures: an internal project code name or a customer's name in an insight
title reaches the display verbatim. Read them before you publish.

New instrumentation never adds itself to a published screen. A discovery is a suggestion on a draft,
and a draft becomes visible only when you publish it again.

## The panel kinds

| Kind | Source | What reaches the display |
| --- | --- | --- |
| Trend | One saved insight, at an exact retained revision | The measure's unit, the total for the window, the comparison total when a comparison window is defined, and the bucket series. No participant, no contributor, no selection, no breakdown key, no query definition |
| People affected | Error impact over a window, optionally for one service | One count and its unit. Never a person, an identifier or a property |
| Service health | Service health over a window | One row per service: the service name you approved, request rate, error rate, p50 and p95 latency, and a health word (`healthy`, `degraded`, `unhealthy`) |
| Alert state | Alert states you selected | Counts per state: pending, firing, acknowledged, silenced. Never a rule name, a message or a label |
| Log volume | Log volume over a window | One row per severity, with a count. Never a log message |
| Note | Text you wrote | Exactly that text, as plain text. No links, no images, no markup |

Only a trend panel runs a product-analytics measurement. It publishes an **exact saved revision**, so
editing the saved insight afterwards does not change what the screen shows — the screen keeps serving
the revision it was published at until you publish again. A current-head reference is refused at
publish for that reason. Save the insight first; see
[Manage saved insights](/docs/investigate/saved-insights).

A trend panel's window stays the window the saved recipe defines. A relative window is resolved
afresh on each refresh; an absolute one stays absolute. A screen never substitutes its own window or
injects a filter into somebody's saved recipe.

**What no panel can carry.** The projection a display receives is a closed shape rather than a
filtered copy: measurement definitions, execution snapshots, cohort provenance, tracking-sensitivity
declarations, participants and contributors are not fields on it at all. Person and group properties,
transcripts, tool arguments, recorded sessions and memory items have no panel kind. A viewer cannot
reach them by any request, because there is nothing on the wire to reach.

Funnel and retention panels are not available yet. Save those measurements as saved insights and open
them as a dashboard page or in the [result viewer](/docs/agents/result-viewer). They are a later
addition to this list.

## Budgets

Enforced when you create or update a screen, not discovered at publish:

| Bound | Value |
| --- | --- |
| Panels per screen | 12 |
| Trend panels per screen | 4 |
| Panel title | 120 characters |
| Note text | 500 characters |

Four trend panels is not an arbitrary round number: it equals the number of product-analytics
measurements one project may run at once, so a fifth trend panel could never be current alongside the
other four. Twelve panels is a readability limit as much as a cost one — a display nobody can read
from across the room is not a display.

If a screen needs more, publish two screens. Each gets its own link, and the links are independent.

## Refresh

Each panel declares its own cadence, with a floor by kind:

| Panel kind | Fastest cadence |
| --- | --- |
| Trend | 60 seconds |
| People affected, service health, alert state, log volume | 30 seconds |
| Note | Never refreshes |

Refresh runs on a timer on the server, not on a viewer's poll: ten people watching one screen cost
exactly what one person watching it costs. The server tells each display when to come back, and the
display jitters around that.

A screen nobody is looking at stops refreshing. Refresh services only publications a display has
polled recently, so a link left unopened costs nothing until somebody opens it, and a phone with the
tab in the background stops polling and lets the screen go idle.

When the project is already running its limit of measurements, a trend panel is **refused rather than
queued**, shown as **Delayed**, and retried on the next cycle as the identical request. Live yields to
the measurements that people and agents run on request. It never escalates past them.

## Next

- [Put a project on a live screen](/docs/investigate/live-screens) — the create, preview, publish
  and manage workflow. In the Console, **Published links** (`/published-links`) lists the links and
  revokes one.
- [Live viewing links and access](/docs/manage/live-links-and-access) — who can open a link and what
  stops it.
- [Plans, limits, and retention](/docs/reference/limits#anectico-live) — the same budgets beside the
  platform's other limits.
- [Measure product events](/docs/investigate/product-analytics) — what a trend measures and how its
  coverage is stated.

An explicit MCP service-health panel uses `service_names`, a nonempty allowlist of exact
service names approved for the display. Publication previews name all source permissions:
`services:read` for health, `alerts:read` for alerts and `logs:read` for log volume, as well
as the trend and people-affected permissions. Notes read no source.

Template creation previews name every optional source scope check and whether the credential holds it. Missing discovery permission can leave panels out; review the complete proposed draft and its notes before confirming.