RetivAISubmit a product

6 product blueprints · no code required to read

The model is fast.
The loop is the product.

Use these architecture blueprints to decide where state lives, how playback survives latency, what gets moderated, when generation stops, and which failures the audience is allowed to see.

01INPUTchat · voice · state
→
02CONTROLselect · prompt · guard
→
03PLAYOUTbuffer · stream · recover

Choose the loop

01

Native realtime

Native Continuous AI Channel

One WebRTC generation session stays alive while an operator or agent sends small steering directions.

Best for

Private live direction, controlled public channels, ambient worlds, recurring hosts, and experiences where a hard clip boundary would break the illusion.

A

System flow

01Authorize viewer or operator→
02Quote and cap the session→
03Configure world and continuity→
04Open WebRTC receive tracks→
05Send reviewed steering deltas→
06Record metrics and media→
07Stop and finalize
B

Core components

01

Session broker

Authenticates users, creates provider sessions, and keeps provider keys server-side.

02

Director client

Receives video/audio and sends configure, prompt, ping, and stop messages.

03

World-state reducer

Separates immutable identity from mutable story facts.

04

Prompt gate

Sanitizes audience intent and produces one bounded steering delta.

05

Recorder

Captures the visible session and operational metrics when rights allow.

06

Kill switch

Stops generation and public playout immediately.

C

State to keep

  • Session: id, owner, started time, hard stop, prompt version, connection state.
  • World: characters, immutable anchors, location, current objects, open action.
  • Safety: source message, moderation result, sanitized intent, reviewer/agent decision.
  • Operations: buffer depth, chunk index, generation time, deadline misses, cost estimate.
D

Prompt strategy

Use one detailed configure prompt as a world contract. Send later prompt messages as short deltas that preserve established facts and request one visible beat.

BUFFER

Director controls continuous chunk generation, but the product should still monitor server chunk metrics and show a neutral reconnect/fallback layer when media stalls.

MODERATION
  • Authenticate anyone who can spend against the provider proxy.
  • Separate raw audience text from the generation prompt.
  • Reject prompt-injection attempts, public-figure impersonation, unsafe content, and rights-sensitive requests.
  • Log accepted intent and exact applied prompt version.
FALLBACK
  • Keep a rights-safe standby slate or prerecorded ambient loop.
  • On missed media deadline, preserve the last good frame briefly and disclose reconnection.
  • On safety uncertainty, send no audience change; continue the existing world or stop.
  • On provider/session failure, close resources and require a deliberate restart.
COST CAPS
  • Quote a fixed session cap before opening the provider session.
  • One active session per authorized user or room.
  • Enforce a hard server-side stop independent of browser state.
  • Track streamed seconds and alert before the account budget threshold.
DEPLOYMENT
  • Use a server-side provider proxy; never ship the provider key to the browser.
  • Choose infrastructure that supports long-lived WebRTC signaling and recording needs.
  • Put public chat ingestion and moderation outside the media hot path.
  • Test reconnection, page close, mobile network change, and abandoned-session cleanup.

Risks to resolve

  • A live session can continue billing after the visible UI disconnects.
  • Continuity may drift even when prompts are stable.
  • Audience steering introduces injection and content-policy risk.
  • Generated audio and visual rights need the same review as the prompt.

Build checklist

  • Provider key is server-only
  • Hard duration and spend caps are enforced server-side
  • Configure and prompt versions are logged
  • Audience input is sanitized before prompt construction
  • Kill switch works without the primary UI
  • Fallback is clearly disclosed and rights-safe
02

Just-in-time generation

Audience-Prompted AI TV

A public prompt queue selects future programming while the current video remains on air.

Best for

Novelty channels, community events, launch activations, and formats where voting and visible production are part of the entertainment.

A

System flow

01Receive chat or prompt→
02Rate-limit and moderate→
03Rank or vote→
04Select one intent→
05Expand into a bounded scene prompt→
06Generate into runway→
07Play and collect feedback
B

Core components

01

Audience gateway

Normalizes web chat, Twitch, YouTube, or voting events.

02

Moderation queue

Blocks unsafe input and removes instructions aimed at the control system.

03

Selector

Chooses one eligible request by vote, score, or editorial rule.

04

Prompt compiler

Combines sanitized intent with channel style and production constraints.

05

Generation runway

Tracks queued, generating, ready, on-air, failed, and archived clips.

06

Player

Maintains uninterrupted playout and exposes truthful queue state.

C

State to keep

  • Request: source, pseudonymous user id, received time, normalized intent, votes, moderation.
  • Clip: prompt version, provider job id, duration, state, media URL, expiry, cost.
  • Channel: on-air clip, next-ready clip, queue depth, fallback position, current style.
D

Prompt strategy

Treat audience text as data. A compiler converts the selected intent into one visual beat inside a fixed channel style; never concatenate raw chat after a system prompt.

BUFFER

Start with two or three fully decoded clips. Generate new clips while the current one plays, and insert transparent filler or curated reruns if the ready queue falls below one.

MODERATION
  • Rate-limit by viewer and room before expensive model calls.
  • Detect duplicate/near-duplicate requests and coordinated voting.
  • Apply rights, identity, sexual, violent, self-harm, and platform-specific rules.
  • Show why a request was rejected without exposing internal policy text.
FALLBACK
  • Keep a reviewed rerun pool and a generic standby clip.
  • If generation fails, mark the request failed and advance; do not retry without a bounded policy.
  • If chat is empty, draw from an editorially approved prompt deck rather than unconstrained invention.
  • If moderation is unavailable, stop accepting prompts and continue safe programming.
COST CAPS
  • One selected prompt per playout window, not one generation per chat message.
  • Set maximum concurrent generations and queue length.
  • Define an hourly generation budget and switch to reruns when reached.
  • Expire abandoned requests before they consume generation.
DEPLOYMENT
  • Use durable queue/state storage so a server restart does not lose paid jobs.
  • Proxy expiring provider media into storage the channel controls when terms allow.
  • Keep the encoder/stream sink isolated from prompt and web failures.
  • Record a public status distinction between live, generating, rerun, and offline.

Risks to resolve

  • Prompt queues attract abuse and prompt injection.
  • Popularity incentives may produce repetitive or unsafe requests.
  • Generation latency spikes can reveal the buffer.
  • A public broadcast may trigger platform copyright and synthetic-media rules.

Build checklist

  • Raw chat never reaches the generator
  • Request and generation rate limits are separate
  • The ready queue survives a web-process restart
  • Reruns/filler are labeled truthfully
  • The operator has pause, reject, and kill controls
  • Platform rules and disclosure are reviewed
03

Just-in-time generation

Just-in-Time Episode Generator

A showrunner writes upcoming shots while a chained clip buffer keeps an episode playing.

Best for

Open-ended fiction, educational programs, ambient series, and personal channels where a coherent format matters more than direct audience control.

A

System flow

01Play a prepared cold open→
02Plan the first shot immediately→
03Generate from cold-open final frame→
04Decode and enqueue→
05Plan a small shot batch→
06Chain each next shot from the visible final frame→
07Grow and monitor buffer
B

Core components

01

Series bible

Holds immutable visual and narrative rules for the title.

02

Showrunner

Produces compact upcoming shot specs and factual continuity updates.

03

Frame handoff

Extracts the actual final frame used to condition the next clip.

04

Render scheduler

Balances planning, concurrency, provider limits, and buffer targets.

05

Gapless player

Preloads and swaps decoded clips without a spinner.

06

Episode ledger

Records prompts, outputs, errors, and the sequence actually seen.

C

State to keep

  • Immutable title bible and mutable episode summary.
  • Shot spec, input frame, prompt, generation state, output, actual final frame.
  • Player sequence and decoded readiness—not only API job completion.
  • Buffer seconds, generation estimate, deadline, and fallback decision.
D

Prompt strategy

Plan several narrative beats, but render one shot at a time. Carry forward a short factual synopsis and use the actual prior final frame for visual continuity.

BUFFER

A short prepared preview buys time for the first generation. After that, target at least two decoded shots and expand the runway when generation is faster than playback.

MODERATION
  • Review title bibles and recurring character assets before launch.
  • Moderate showrunner output before each generation, even without public chat.
  • Keep model instructions separate from story text to resist self-generated prompt injection.
  • Scan final media when the product category requires it.
FALLBACK
  • Hold the prior final frame briefly rather than showing an unexplained loader.
  • Use an approved neutral continuation that does not change story facts.
  • If a frame handoff fails, make a clearly motivated hard cut rather than pretending continuity.
  • End the episode cleanly when the budget or error ceiling is reached.
COST CAPS
  • Generate only shots likely to air; speculative branches are opt-in.
  • Use a per-session minute cap and maximum queued render count.
  • Stop planning when the renderer or player has already failed.
  • Store and reuse approved cold opens instead of regenerating them per session.
DEPLOYMENT
  • Long-lived in-memory prototypes need a single process; production needs durable session and job state.
  • Store media before provider URLs expire.
  • Use same-origin media delivery if the browser must capture the final frame.
  • Measure decoded-ready time, not only provider completion time.

Risks to resolve

  • Visual continuity can drift even when chained by a final frame.
  • The showrunner may contradict what the generated shot actually shows.
  • A slow first planning call can exhaust the cold-open runway.
  • Unbounded viewing creates unbounded cost.

Build checklist

  • Cold open is rights-safe and long enough for first-shot latency
  • Every shot stores its actual input and final frames
  • Player waits for decoded readiness
  • Showrunner facts are reconciled with visible output
  • Session has hard duration and job caps
  • Episode can end cleanly on failure
04

Buffered interactive

Branching Interactive Movie or Game

Player choices, visible outcomes, and a state reducer turn generated shots into a playable world.

Best for

Short adventures, choice-driven films, horror tapes, role-playing prototypes, and worlds where what appears on screen becomes canonical state.

A

System flow

01Play current shot→
02Inspect visible outcome→
03Derive legal choices→
04Accept selected or typed move→
05Rule intended outcome→
06Generate one or more branches→
07Adjudicate landed pixels→
08Commit visible state
B

Core components

01

World rules

Defines allowed actions, stakes, victory, failure, and immutable setting facts.

02

Choice generator

Offers a small set of actions grounded in the current visible frame.

03

Referee

Classifies typed actions and chooses success/complication before generation.

04

Branch renderer

Generates the chosen next shot or a budgeted speculative set.

05

Vision adjudicator

Describes what visibly occurred and proposes a bounded state patch.

06

State reducer

Validates the patch and commits inventory, health, location, and objectives.

C

State to keep

  • World: zone graph, rules, threats, objective, time.
  • Player: health, inventory with evidence frame, current intent.
  • Scene: visible entities, exits, props, unresolved actions, final frame.
  • Decision: offered choices, selection, roll/rule, planned outcome, visible outcome.
D

Prompt strategy

Describe one physical action and one ruled outcome. Keep first-person camera, relevant hands/items, target, and the evidence-bearing consequence visible.

BUFFER

For fixed choices, render likely branches while the current clip plays only when the budget permits. For typed actions, show a short decision window or neutral hold while the selected branch renders.

MODERATION
  • Treat typed actions as untrusted and enforce world/safety rules before the referee.
  • Do not let a vision model execute arbitrary state mutations; validate patches against a schema.
  • Bound health/inventory deltas and require visible evidence.
  • Keep public-figure, self-harm, sexual, and graphic violence rules explicit for the game's age level.
FALLBACK
  • If output contradicts the planned result, canonicalize the visible result or regenerate within a strict cap.
  • If adjudication fails, freeze state and offer a safe retry rather than inventing facts.
  • If every branch fails, play a neutral world action and return control.
  • Preserve a complete replay ledger for dispute and debugging.
COST CAPS
  • Default to rendering only the selected branch.
  • Limit speculative branches to high-value moments and cancel jobs that can still be cancelled.
  • Cap turns, clip duration, concurrent jobs, and total session spend.
  • Use deterministic non-video UI for inventories, dice, and text.
DEPLOYMENT
  • Keep authoritative state server-side with idempotent turn identifiers.
  • Store evidence frames alongside each accepted state change.
  • Separate video-provider failure from game-state failure.
  • Test double-submit, reconnect, stale choice, and late branch completion cases.

Risks to resolve

  • Planned and visible outcomes disagree.
  • Speculative branches multiply cost quickly.
  • Generated objects disappear between shots and invalidate inventory.
  • A generative world can produce unreviewed content at gameplay speed.

Build checklist

  • State changes require visible evidence
  • Typed moves are moderated and schema-bounded
  • Stale choices and late jobs cannot overwrite newer turns
  • Inventory stores an evidence frame
  • Speculative rendering is capped
  • Replay ledger reproduces the visible sequence
05

Buffered interactive

Interruptible AI Tutor or Character

Realtime voice remains responsive while a cancellable visual queue catches up to the newest conversational topic.

Best for

Tutors, guides, companions, coaches, and role-play characters where interruption speed matters more than native continuous video.

A

System flow

01Listen for speech→
02Produce partial transcript→
03Identify visualizable concept→
04Compile safe visual spec→
05Queue short clip→
06Play current decoded media→
07On barge-in cancel stale work→
08Swap when new-topic clip is ready
B

Core components

01

Realtime conversation

Handles turn detection, partial transcripts, speech, and barge-in.

02

Concept extractor

Ignores filler and identifies one concrete subject worth visualizing.

03

Visual compiler

Adds style, age/safety rules, duration, and layout constraints deterministically.

04

Cancellable scheduler

Versions work so stale results cannot enter the live queue.

05

Decoded media deck

Keeps current video visible until a replacement is actually ready.

06

Quota layer

Limits clips by learner, room, and service-wide budget.

C

State to keep

  • Conversation turn id, transcript revision, current intent, interruption time.
  • Visual topic id, generation version, cancellation status, decoded status.
  • Character/style bible and learner-safe policy profile.
  • Per-user and global quota counters.
D

Prompt strategy

Derive one concrete visual subject from the conversation, then combine it with a fixed style and safety template. Do not ask a second LLM to rewrite every visual unless it adds measurable value.

BUFFER

A bounded queue avoids unlimited lag. Keep the current clip or neutral idle motion visible while the new topic renders, then swap only after decode.

MODERATION
  • Apply age-appropriate topic and image rules before generation.
  • Do not send generic greetings or sensitive learner data to the video provider.
  • Keep transcripts and voice recordings on a documented retention schedule.
  • Clearly state that educational or character output is not authoritative advice.
FALLBACK
  • Continue voice with a static or approved idle visual when generation is unavailable.
  • Cancel stale visual jobs on interruption; prevent late responses from becoming current.
  • Use deterministic diagrams or images for facts that generative video cannot represent accurately.
  • Surface provider and quota state to the operator without interrupting the conversation.
COST CAPS
  • Generate only after a minimum amount of useful subject matter is detected.
  • Deduplicate semantically similar topics within a short window.
  • Use short fixed-duration clips and a small maximum queue.
  • Enforce both learner-level and global quotas.
DEPLOYMENT
  • Realtime voice and persistent video scheduling may need different services.
  • Encrypt transcripts and session state where durable storage is required.
  • Authenticate public sessions and rate-limit both voice and video actions.
  • Test rapid barge-in and out-of-order provider completion.

Risks to resolve

  • The visual track lags behind the spoken topic.
  • A late stale clip replaces the correct current topic.
  • Generated educational imagery can be confidently wrong.
  • Voice/transcript processing creates additional privacy obligations.

Build checklist

  • Every visual job carries a conversation revision
  • Stale completions are discarded
  • Current media remains visible until replacement decodes
  • Sensitive transcript content is minimized
  • Per-user and global quotas exist
  • Accuracy disclaimer and escalation path are visible
06

Synthetic live

Local-GPU Livestream Pipeline

Generation workers and one persistent playout process exchange completed clips through a minimal durable contract.

Best for

Teams with suitable GPUs, privacy or marginal-cost requirements, and a need to stream continuously without depending on per-clip cloud APIs.

A

System flow

01Ingest chat or prompt deck→
02Moderate and expand→
03Dispatch across GPU workers→
04Write to staging→
05Validate media→
06Atomically publish to clip pool→
07Decode next clip→
08Encode once to RTMP
B

Core components

01

Input service

Maintains chat connections, reconnects, deduplication, and request priority.

02

Prompt compiler

Creates structured, moderated prompts without embedded concrete examples that leak.

03

GPU workers

Run one bounded generation process per device.

04

Clip contract

Publishes only complete, validated media into a durable pool.

05

Playout service

Predecodes, rescales, timestamps, and sends an uninterrupted stream.

06

Supervisor

Restarts workers, monitors temperature/storage, and closes the stream safely.

C

State to keep

  • Request/job records with deterministic ids and worker assignment.
  • Staging, ready, played, quarantined, and failed media states.
  • Encoder clock and RTMP reconnect state independent of source clip timestamps.
  • GPU health, queue depth, storage use, and generation time.
D

Prompt strategy

Use a structured compiler that applies format, pacing, audio, and safety rules to a sanitized idea. Keep examples out of the system prompt if the small expansion model tends to imitate them.

BUFFER

The clip pool is the buffer and failure boundary. Decode the next complete clip in parallel, prioritize never-played clips, and use reviewed reruns when the fresh queue empties.

MODERATION
  • Filter before dispatching scarce GPU work.
  • Quarantine media that fails duration, codec, audio, or content validation.
  • Maintain an operator kill switch and platform-specific blocked topics.
  • Keep chat credentials and RTMP secrets outside repository/config examples.
FALLBACK
  • Rerun reviewed clips when no fresh clip is ready.
  • Use a generated-media fake worker for pipeline testing without GPU spend.
  • Restart a failed generator without interrupting the encoder.
  • Reopen the RTMP sink while maintaining a monotonic playout clock.
COST CAPS
  • Cap power, worker count, generation resolution, and pool size.
  • Stop generation when the ready pool reaches its high-water mark.
  • Prefer one selected request per clip and drop expired queue entries.
  • Measure electricity, hardware utilization, and operator time—not only API cost.
DEPLOYMENT
  • Keep the generator and encoder as separate supervised processes.
  • Publish media with an atomic rename or transactional object-state change.
  • Use one long-lived encoder/container for gapless timestamps.
  • Validate A/V duration and pad or trim audio before playout.

Risks to resolve

  • Large model weights and multi-GPU memory requirements limit portability.
  • Encoder timestamps and audio drift accumulate over long streams.
  • A partial file can crash playout unless publication is atomic.
  • Repository code and model weights can have different licenses.

Build checklist

  • Staging files are never visible to playout
  • Generation and encoder can restart independently
  • A/V duration is validated before ready state
  • RTMP reconnect preserves monotonic timestamps
  • Model and code licenses are reviewed separately
  • GPU-free fake mode exercises the full control path

From architecture to direction

Now write the next beat.

Use the prompt library for session openers, audience continuations, game actions, recovery scenes, and disclosure-safe interstitials.

Open prompt recipes