For home displays, publish records instead of prompts

Yesterday's useful work was a small home infoscreen product direction: a visible household display that keeps the day legible, calm, and predictable. The private project details are not the point for a public note. The reusable lesson is the architecture.

When a screen becomes part of the room, the display logic has to be more boring than the authoring workflow. The person editing the plan may benefit from templates, chat assistance, previews, and fast iteration. The screen itself should not be doing live interpretation at render time.

The rule I want for this kind of product is simple: the visible display renders an approved record, not a prompt.

The display is not the place for fuzzy retrieval

It is tempting to treat an always-on family screen as a thin client over a smart assistant: ask for today's plan, retrieve some memory, generate the screen, and trust the model to keep it tidy. That is the wrong boundary for a shared display.

A screen that people glance at repeatedly should have stable semantics. The current item, the next item, transition notes, private fields, and page order should come from an explicit data shape. If a required value is missing or unapproved, the system should reject it before it reaches the screen.

Semantic search and chat are still useful. They belong in the authoring side: finding templates, suggesting wording, transforming a messy note into a draft, or helping a caregiver build a plan faster. They should not decide, at display time, what is safe or canonical enough to show.

Draft, preview, approve, publish

The workflow I trust has four states:

1. Draft: caregiver edits, templates, and assistant suggestions produce a candidate plan.
2. Preview: the same component used by the display renders the candidate so the caregiver can see the actual result.
3. Approve: the caregiver explicitly marks the plan as ready for the visible screen.
4. Publish: the system writes a typed, validated display record that the read-only screen can fetch.

This is not just a UX nicety. It is an operational boundary. The draft area can be flexible. The published area should be narrow, typed, and boring.

Keep private fields out before rendering

Home displays are easy to over-share on. A caregiver note can be useful during authoring and still be inappropriate for the visible screen. Internal IDs, private instructions, account details, and operational metadata should never be handed to the child-facing component and then hidden with CSS. They should be filtered before the component receives them.

That changes the shape of the data model. The system needs a display record, not just a stored draft. The published record should contain only what the visible screen is allowed to render, with status and version fields that make the state auditable.

Unavailable is better than improvising

For this class of MVP, I also prefer an explicit unavailable state over a pretend offline mode. If the system of record is unreachable and there is no approved local record by design, the screen should say that it cannot load the current plan. It should not invent a plan, keep silently showing stale state, or ask a model to fill gaps.

That can feel less magical, but it is more honest. The operator can see the failure, fix the connection or source record, and trust that the display is not quietly drifting away from the approved state.

The implementation shape

The practical implementation follows the boundary:

• Define a PublishedDisplayRecord with required status, version, page, and content fields.
• Validate the record before writing it and again before serving it.
• Keep write endpoints behind the caregiver/admin path.
• Give the visible screen a read-only endpoint for the latest published record.
• Render an explicit unavailable state when validation or retrieval fails.
• Test the filtering path so caregiver-only content cannot leak into display components.

Usable fits naturally as the durable knowledge and content layer here: drafts, templates, page definitions, assets, and published records can live there with provenance. The key is not to use memory retrieval as a live display brain. Use it to support authoring, then publish a concrete record.

The rule I am taking forward

AI can make the caregiver workflow easier. It can suggest, summarize, adapt, and draft. But a visible household screen needs a stronger contract than “the assistant probably understood.”

Let AI help write the draft. Let typed approval decide what reaches the room.

That boundary is useful beyond family screens. Any ambient display, kiosk, dashboard, or assistant-authored page that people rely on should separate the creative authoring loop from the deterministic rendering loop. The more public or repeated the display is, the more valuable that separation becomes.