A View is a standing choice about what to see
You already know a Frame is one materialized instant of the screen. A View is the thing that decides what that instant contains: the standing definition of which panes an agent should see, in what order, at what token budget. It is authored in the Kestrel language itself, and it materializes into a fresh Frame on every wake. The Views reference is the library of the shipped screens; this unit teaches the two ideas that make Views more than a dashboard — screens are chosen per seat, and layouts are measured.
Different seats read different screens
A Kestrel pod is not one agent; it is a small organization of seats — roles distinguished by the deliberation budget each can afford. And each seat reads a different View because each does a different job at a different speed:
- Strategist — frames the session and authors the Plans. Slow, deliberate, frontier-class judgment, a few times a day. It reads a rich screen.
- Watcher — manages the armed book inside the strategist's frame. Fast and cheap, every few seconds. It reads a lean, token-light screen.
- Scanner — the PM's discovery half; reads one name deeply when a universe-wide scan fires.
- PM — the allocation half; watches aggregate exposure across the pod.
A watcher reading the strategist's heavy screen every few seconds would be ruinously expensive and slow; a strategist reading the watcher's stripped screen would be flying blind at the one moment it needs the whole picture. The View is where perception is tuned to the seat's task and timescale.
The selection rule: explicit > seat > phase default
Because several Views could apply on any given wake, the runtime resolves each wake to exactly one screen through a strict precedence:
explicit authored View > seat View > phase default- An explicitly authored View — one an agent wrote, scheduled, or a Wake forced — always wins. A seat never overrides a lens the agent chose on purpose.
- Otherwise, when the runtime knows the acting seat, that seat's View for the frame kind renders.
- Otherwise the frame kind's phase default panes render — byte-identical to a run with no seat at all.
Seat Views are opt-in (a run sets seatViews to turn them on), and where a seat
has no View for a frame kind, resolution simply falls through to the phase
default. Absence is a first-class value here, never a silently fabricated screen —
the same fail-closed ethic the rest of the perception layer lives by.
Which panes belong is measured, not opinion
The last idea is the most Kestrel-ish. No pane layout on a default screen is blessed by taste. Under the platform's rendering discipline, every layout choice is a hypothesis that must earn its default status in rendering tournaments: cohorts of agents run on identical Frames over identical replay corpora, differing only in the rendering variant, and are graded on decision quality, token cost, and attention efficiency. The screen an agent reads today is the one that won its tournament, not the one a designer preferred. That is why "the screen is chosen, not given" is true twice over — chosen per seat, and chosen by measurement.
See it in kestrel
Run an event session and watch a live screen render against real recorded data:
npx kestrel.markets sim fomc-rate-decision-whipsawThat runs a deterministic simulation over a generic index session — managed licensed data, no wall time, no signup, no card — and prints a certified proof URL. Point the CLI back at the proof and it recomputes the whole record on your own machine, byte for byte:
npx kestrel.markets certify https://kestrel.markets/proof/art_d29415f0cf502f4a218a9cbaKeep it one command away: drop the kestrel.markets MCP server into your client and the next session is already wired up — no account in between.