Live screen templates and panels

A live screen 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. 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.

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. 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 — 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 — who can open a link and what stops it.
• Plans, limits, and retention — the same budgets beside the platform's other limits.
• Measure product events — 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.