System Requirements Document for pewbeam-ai

1. Introduction

Pewbeam AI is a Kivy-based mobile application that gives a single live-service operator a mission-control console for scripture dispatch. During a live church service, the app listens to the pastor's spoken sermon, resolves the referenced verse against a local scripture index, and dispatches the matched passage to the live projection screen — all from a dark charcoal cockpit that reads as "AI is listening right now."

The product intent is narrow and operational: one operator, one live service, one projection target. The app surfaces a live projection card, a read-only live transcript stream, a read-only production queue, and a search/dispatch control that resolves a verse address or phrase against an embedded local scripture index. Success means the correct verse appears on the projection panel and the queue and transcript logs reflect either the match or a clear mismatch.

The audience is the operator in the church tech booth — not the congregation, not a multi-tenant team. The emotional register is focused, high-stakes, and slightly futuristic: a broadcast console where every dispatch is a live cue.

2. System Overview

Pewbeam AI is delivered as a Kivy mobile application with a dark charcoal (#121212) background and deep blue (#0A192F) projection card styling. The current delivery is a single-operator console with two first-party pages: a Landing page that introduces the console, and a Console page that contains the live projection panel, live transcript, production queue, search bar, and DISPATCH TO SCREEN action.

Actors. The only accepted active human persona is the Operator. There are no other human personas, no congregation-facing surface, and no external scripture service. Scripture lookup is served entirely by a local mock scripture index database embedded in the app.

Accepted behavior. The Operator enters a verse address or phrase in the search bar (or presses the mobile keyboard Enter/Done key), or presses the DISPATCH TO SCREEN button. The app performs an exact-match lookup against the local index; if no exact key matches, it performs a context/semantic fall-through lookup across verse text and references. On a match, the projection card updates with the matched title and verse text, a live entry is prepended to the Production Queue log, and a [Matched Address: ...] line is appended to the transcript. On no match, a ⚠ Clear mismatch for ... warning is prepended to the Production Queue log. The search bar is cleared after each dispatch.

Ownership. Both pages are first-party application surfaces owned by the application. The Live Transcript and Production Queue panels are read-only. The local scripture index is embedded in the app and is not an external service.

Narrow exclusions. No external scripture API, no multi-user accounts, no congregation-facing display surface, no editing of the transcript or queue by the operator, and no additional pages beyond the two accepted surfaces.

2a. Product Interpretation and Delivery Boundary

Pewbeam AI is a self-contained mobile console. The operator opens the app on a mobile device, sees the Landing composition that frames the console, and moves into the Console workspace where all live-service work happens. All scripture resolution is local: the app carries its own mock scripture index and never calls out to a remote scripture provider. The Live Transcript and Production Queue are read-only observation surfaces — the operator watches them, does not edit them. The DISPATCH TO SCREEN action is the single commitment point in the product, and its result is visible immediately on the projection card and in the queue log.

Current delivery covers the Landing and Console surfaces, the local lookup, the dispatch action, and the resulting projection, queue, and transcript updates. There is no future-horizon section in the accepted requirements; nothing beyond the current console is committed.

2b. Source Content Inventory

The local mock scripture index embedded in the app contains the following verified entries:

Initial projection card state on app open: title Psalm 32:1 (NKJV), verse text "Blessed is he whose transgression is forgiven, Whose sin is covered."

Initial Live Transcript state: [AI Listening...] followed by Pastor: "Open to Psalm 32:1..."

Initial Production Queue state: ■ Psalm 32:1 -> Active and ■ Joshua 1:8 -> Ready

2c. Page Content and Component Coverage

Landing

• Information and state. A full-viewport charcoal (#121212) field with a faint dotted pixel grid at 4% opacity. The deep blue (#0A192F) projection card dominates the frame, bleeding from the left edge to the right edge at 92% width, with a 1px #00A8FF stroke at 30% opacity and a soft #00A8FF radial glow behind its top edge. Inside the card, the verse title PSALM 32:1 (NKJV) sits in 13px uppercase #00A8FF with 0.18em tracking, and the verse text Blessed is he whose transgression is forgiven, Whose sin is covered. is set in 38–72px Space Grotesk 400 weight #E8EDF5, wrapping across three lines. Below the card, a single 56px-tall strip of live transcript text scrolls right-to-left in JetBrains Mono 13px #8892A6, clipped by the viewport edge as it moves. In the bottom-right corner, a 56px-tall capsule button in #FF6B35 reads DISPATCH TO SCREEN in white 14px uppercase with 0.12em tracking, with a thin #00A8FF focus ring.
• Primary action. Enter the Console workspace to begin live-service operation.
• Supporting actions. The DISPATCH TO SCREEN capsule is present as the signature control; on the Landing composition it is the visual anchor of the cockpit framing.
• Domain entities. Projection card (title, verse text), live transcript strip, dispatch control.
• Component responsibilities. Top bar (wordmark left, LIVE dot right, 56px tall); projection card slab; transcript strip; dispatch capsule.
• States. Loading: the projection card renders with the initial Psalm 32:1 (NKJV) content. Empty: not applicable — the card always carries the initial verse. Success: the composition renders fully with the LIVE dot pulsing at 2.4s intervals. Error: not applicable on this surface. Recovery: not applicable on this surface.

Console

• Information and state. A three-zone HUD. Zone 1: the projection card full-width at top, deep blue #0A192F with a 1px #00A8FF luminous stroke, a soft radial glow behind its top edge, and a 400ms light-sweep animation across its face every time a verse is dispatched. The card carries the slide title (e.g. PSALM 32:1 (NKJV), or ... (AI EXACT) / ... (CONTEXT MATCH) after a dispatch) and the verse text. Zone 2: at ≥768px a two-column grid for Live Transcript and Production Queue, stacked at 375px. Each panel opens with an uppercase 11px 0.18em-tracked #8892A6 micro-label (LIVE TRANSCRIPT, PRODUCTION QUEUE) sitting on a 1px luminous top rule. The Live Transcript is read-only and shows the AI listening stream; the Production Queue is read-only and renders each row as a ruled data line with a status glyph (■ active in #00A8FF, □ ready in #8892A6,\x20\xe2\x9a\xa0 mismatch in #FF6B35). Zone 3: a bottom dock with the search bar (capsule, 999px radius, placeholder Enter verse address or phrase...) and the DISPATCH TO SCREEN button (capsule, #FF6B35, white 14px uppercase, 0.12em tracking, 1px #FF6B35 outer pulse while a dispatch is resolving).
• Primary action. Enter a verse address or phrase and dispatch it to the projection screen.
• Supporting actions. Submit via mobile keyboard Enter/Done; submit via the DISPATCH TO SCREEN button; observe the live transcript stream; observe the production queue log.
• Domain entities. Projection card (slide title, verse text), live transcript stream, production queue log, search query, local scripture index, match result (exact or context), mismatch warning.
• Component responsibilities. Top bar (wordmark, LIVE dot with 2.4s expanding halo ring); projection card slab with light-sweep animation; Live Transcript panel (read-only, auto-scrolls with a soft 300ms ease); Production Queue panel (read-only, new rows slide in from the right with a 12px offset and fade over 220ms); search bar capsule; DISPATCH TO SCREEN capsule.

• States. Loading: the projection card renders with the initial Psalm 32:1 (NKJV) content; the transcript shows [AI Listening...] and the pastor's opening line; the queue shows the initial active and ready rows. Empty: the Production Queue empty state uses the concentric arc segments motif as its mark. Success: on an exact match, the slide title updates with (AI EXACT), the verse text updates, a ▶ [Match] ... Live row is prepended to the queue, and a [Matched Address: ...] line is appended to the transcript. On a context match, the slide title updates with (CONTEXT MATCH), the verse text updates, and a ▶ [Context] ... Live row is prepended to the queue. Error: on no match, a ⚠ Clear mismatch for '...' warning is prepended to the queue log; the projection card retains its previous content. Recovery: the operator can re-enter a corrected verse address or phrase in the search bar and dispatch again; the search bar is cleared after each dispatch so the next query starts fresh.

3. Functional Requirements

FR-1 — Kivy mobile app with dark charcoal background As the Operator, I should open a Kivy-based mobile app named Pewbeam AI that renders on a dark charcoal (#121212) background, so that the console reads as a focused live-service cockpit.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = app launch; observable result = the app window renders with #121212 background; access state = none; failure/recovery = not applicable; continuation = the Landing composition renders.
• Acceptance: the app launches as a Kivy mobile application with Window.clearcolor set to #121212.

FR-2 — Top navigation bar with wordmark and LIVE status As the Operator, I should see a top navigation bar showing the Pewbeam AI wordmark on the left and a LIVE status indicator on the right, so that I always know the console is live.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = app render; observable result = the wordmark ψ Pewbeam AI renders in #FF6B35 bold 18sp on the left and LIVE ● renders in #888888 12sp on the right; access state = none; failure/recovery = not applicable; continuation = the console remains visible.
• Acceptance: the top bar is 40px tall in the source layout (56px in the creative direction), with the wordmark left-aligned at 50% width and the LIVE indicator right-aligned at 50% width.

FR-3 — Live projection presentation panel As the Operator, I should see a live projection presentation panel showing the current slide title and verse text on a deep blue (#0A192F) card, so that I can confirm what is on the projection screen.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = app render and each dispatch; observable result = the slide title (e.g. Psalm 32:1 (NKJV)) renders in #00A8FF 14sp and the verse text renders in white 16sp centered on a #0A192F card; access state = none; failure/recovery = not applicable; continuation = the card persists across dispatches.
• Acceptance: the projection card renders with the initial title Psalm 32:1 (NKJV) and the initial verse text "Blessed is he whose transgression is forgiven, Whose sin is covered.".

FR-4 — Live Transcript panel (read-only) As the Operator, I should see a read-only Live Transcript panel displaying the AI listening transcript stream, so that I can follow what the AI is hearing during the service.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = app render and each dispatch; observable result = the transcript shows [AI Listening...] and Pastor: "Open to Psalm 32:1..." initially, and appends [Matched Address: ...] lines on matches; access state = none; failure/recovery = not applicable; continuation = the transcript persists and grows.
• Acceptance: the transcript panel is read-only (readonly=True) and renders on a #151515 background with white 11sp text.

FR-5 — Production Queue panel (read-only) As the Operator, I should see a read-only Production Queue panel displaying queued and active scripture items with status markers, so that I can track what has been dispatched and what is ready.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = app render and each dispatch; observable result = the queue shows ■ Psalm 32:1 -> Active and ■ Joshua 1:8 -> Ready initially, and prepends new entries on each dispatch; access state = none; failure/recovery = not applicable; continuation = the queue persists and grows.
• Acceptance: the queue panel is read-only (readonly=True) and renders on a #151515 background with #888888 11sp text.

FR-6 — Search bar with mobile keyboard Enter/Done submission As the Operator, I should enter a verse address or phrase in the search bar and submit it with the mobile keyboard Enter/Done key, so that I can dispatch scripture without leaving the keyboard.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = text entry and Enter/Done key; observable result = the search is processed; access state = none; failure/recovery = empty query returns without action; continuation = the search bar is cleared after dispatch.
• Acceptance: the search bar is a single-line TextInput with placeholder Enter verse address or phrase..., bound to on_text_validate.

FR-7 — DISPATCH TO SCREEN button As the Operator, I should press the DISPATCH TO SCREEN button to trigger the same search and dispatch action, so that I have a deliberate commitment control for live cues.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = button press; observable result = the search is processed identically to the Enter/Done path; access state = none; failure/recovery = empty query returns without action; continuation = the search bar is cleared after dispatch.
• Acceptance: the button renders with background_color #FF6B35, white text, 14sp, and is bound to on_press.

FR-8 — Local mock scripture index database As the Operator, I should have scripture lookup served by a local mock scripture index database embedded in the app, so that dispatch works without any external scripture service.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = app build; observable result = the index contains the four verified entries; access state = none; failure/recovery = not applicable; continuation = the index is available for every lookup.
• Acceptance: the index is keyed by psalm 32:1, psalm 32:2, joshua 1:8, and romans 8:28 with the verified verse texts.

FR-9 — Exact-match lookup As the Operator, I should have the app perform an exact-match lookup when my query matches a database key, so that I get the precise verse I asked for.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = dispatch with a query that matches a key; observable result = the slide title updates with (AI Exact) and the verse text updates; access state = none; failure/recovery = not applicable; continuation = the queue and transcript update.
• Acceptance: the slide title becomes {QUERY} (AI Exact) and the slide text becomes the matched verse text.

FR-10 — Context/semantic fall-through lookup As the Operator, I should have the app perform a context/semantic fall-through lookup when no exact key matches, so that a phrase or partial reference still resolves to a verse.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = dispatch with a query that does not match a key; observable result = the slide title updates with (Context Match) and the verse text updates; access state = none; failure/recovery = if no context match is found, the mismatch path runs; continuation = the queue and transcript update.
• Acceptance: the app searches verse text and references for the query and shows the first match with (Context Match).

FR-11 — Match updates to queue and transcript As the Operator, I should see a live entry prepended to the Production Queue log and a [Matched Address: ...] line appended to the transcript on a match, so that the console records what was dispatched.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = a successful match; observable result = the queue log gains a ▶ [Match] ... Live or ▶ [Context] ... Live row at the top, and the transcript gains a [Matched Address: ...] line; access state = none; failure/recovery = not applicable; continuation = the operator can dispatch again.
• Acceptance: the queue log is prepended and the transcript is appended exactly as specified.

FR-12 — Mismatch warning As the Operator, I should see a ⚠ Clear mismatch for '...' warning prepended to the Production Queue log when no match is found, so that I know the dispatch did not resolve.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = a dispatch with no exact or context match; observable result = the queue log gains a ⚠ Clear mismatch for '{query}' row at the top; access state = none; failure/recovery = the operator can re-enter a corrected query; continuation = the projection card retains its previous content.
• Acceptance: the warning is prepended to the queue log and the projection card is unchanged.

FR-13 — Search bar cleared after each dispatch As the Operator, I should have the search bar cleared after each dispatch, so that the next query starts fresh.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = any dispatch (match or mismatch); observable result = the search bar text is empty; access state = none; failure/recovery = not applicable; continuation = the operator can type the next query.
• Acceptance: self.search_bar.text = '' runs after every dispatch.

FR-14 — Empty query is a no-op As the Operator, I should have an empty query return without action, so that an accidental empty dispatch does not corrupt the console state.

• Provenance: explicit
• Lifecycle: initiator = Operator; trigger = dispatch with an empty or whitespace-only query; observable result = no state change; access state = none; failure/recovery = not applicable; continuation = the operator can type a query.
• Acceptance: if not query: return runs before any lookup.

4. User Personas

Operator

Product context. The Operator runs the Pewbeam AI mobile console during a live church service, seated or standing in the tech booth with the app open on a mobile device. The room is dark; the projection screen is the congregation's view; the console is the Operator's view. The Operator is the only human actor in the product.

Primary goal. Get the correct verse onto the projection screen at the moment the pastor references it, and keep a visible record of what has been dispatched and what is ready.

Distinct accepted responsibilities. The Operator watches the live transcript stream to follow what the AI is hearing; watches the production queue to track active and ready items; enters a verse address or phrase in the search bar; submits via the mobile keyboard Enter/Done key or the DISPATCH TO SCREEN button; reads the resulting projection card, queue entry, and transcript line; and recovers from a mismatch by re-entering a corrected query.

Relevant inputs or decisions. The verse address or phrase typed into the search bar; the choice between Enter/Done and the DISPATCH TO SCREEN button; the decision to re-dispatch after a mismatch.

Interactions with other accepted participants. None. The Operator is the sole accepted human persona. The AI listening stream and the local scripture index are system-side, not human participants.

Observable success. The correct verse appears on the projection card with the right title suffix ((AI Exact) or (Context Match)), the queue log shows the corresponding live entry, and the transcript shows the matched address line. On a mismatch, the queue log shows the ⚠ Clear mismatch warning and the Operator can immediately re-dispatch.

What makes this role different. The Operator is a live-service cue caller, not a content editor or a viewer. Every action is a commitment to the projection screen in front of a congregation, so the console must be readable at a glance, the dispatch control must be unmistakable, and the result must be visible immediately. The role is defined by the pressure of the live moment, not by content management or administration.

5. Core User Flows

Flow 1 — Operator opens the console and orients

1. The Operator launches the Pewbeam AI mobile app.
2. The app renders the Landing composition: a charcoal (#121212) field with a faint dotted pixel grid, the deep blue (#0A192F) projection card dominating the frame with the verse title PSALM 32:1 (NKJV) and the verse text Blessed is he whose transgression is forgiven, Whose sin is covered., a live transcript strip scrolling beneath the card, and the DISPATCH TO SCREEN capsule in the bottom-right corner.
3. The Operator sees the LIVE dot pulsing at 2.4s intervals in the top bar, confirming the console is live.
4. The Operator enters the Console workspace to begin live-service operation.
5. Observable result: the Console renders with the projection card at top, the Live Transcript and Production Queue panels in the middle (two-column at ≥768px, stacked at 375px), and the search bar and DISPATCH TO SCREEN button in the bottom dock.
6. Continuation: the Operator is ready to dispatch.

Flow 2 — Operator dispatches an exact verse reference

1. The Operator is on the Console page during a live service.
2. The Operator hears the pastor reference a verse and types the address (e.g. psalm 32:1) into the search bar.
3. The Operator submits by pressing the mobile keyboard Enter/Done key, or by pressing the DISPATCH TO SCREEN button.
4. The app performs an exact-match lookup against the local scripture index.
5. Observable result: the projection card performs a 400ms light sweep, the slide title updates to PSALM 32:1 (AI EXACT), and the verse text crossfades in over 260ms. A ▶ [Match] PSALM 32:1 Live row slides into the top of the Production Queue log, and a [Matched Address: PSALM 32:1] line is appended to the Live Transcript.
6. The search bar is cleared.
7. Continuation: the Operator can dispatch the next verse.

Flow 3 — Operator dispatches a phrase that resolves by context

1. The Operator is on the Console page during a live service.
2. The Operator types a phrase or partial reference (e.g. forgiven) into the search bar.
3. The Operator submits via Enter/Done or DISPATCH TO SCREEN.
4. The app finds no exact key match and performs a context/semantic fall-through lookup across verse text and references.
5. Observable result: the projection card performs a 400ms light sweep, the slide title updates to the matched reference with (CONTEXT MATCH), and the verse text crossfades in. A ▶ [Context] ... Live row slides into the top of the Production Queue log.
6. The search bar is cleared.
7. Continuation: the Operator can dispatch the next verse.

Flow 4 — Operator recovers from a mismatch

1. The Operator is on the Console page during a live service.
2. The Operator types a query that matches neither a key nor any verse text or reference (e.g. a typo or an out-of-index reference).
3. The Operator submits via Enter/Done or DISPATCH TO SCREEN.
4. The app finds no exact match and no context match.
5. Observable result: a ⚠ Clear mismatch for '{query}' warning is prepended to the Production Queue log. The projection card retains its previous content, so the congregation's view is not disturbed.
6. The search bar is cleared.
7. Recovery: the Operator re-enters a corrected verse address or phrase and dispatches again.
8. Continuation: the corrected dispatch follows Flow 2 or Flow 3.

Flow 5 — Operator monitors the live transcript and production queue

1. The Operator is on the Console page during a live service.
2. The Operator watches the Live Transcript panel as the AI listening stream updates with the pastor's spoken words.
3. The Operator watches the Production Queue panel as active and ready items are listed with their status glyphs (■ active in #00A8FF, □ ready in #8892A6,\x20\xe2\x9a\xa0 mismatch in #FF6B35).
4. Observable result: the Operator can see at a glance what is currently on the projection screen, what is queued, and whether any dispatch failed.
5. Continuation: the Operator dispatches the next verse when the pastor references it.

6. Visuals Colors and Theme

Muse and headline. Cinematic mission-control for live scripture dispatch, after Gleb Kuznetsov. The console reads as a HUD instrument cluster, not a dashboard: dark voids, glowing volumetric forms, HUD data overlays, and motion-as-the-hero.

Palette (dark mode).

Accent and primary are used at roughly 8% and 12% of the surface respectively; the rest is charcoal and deep blue.

Typography.

• Headings: Space Grotesk — wide geometric grotesk with techno temperament. Slide titles and the Pewbeam wordmark are set in uppercase with 0.08em tracking, 600 weight, tight 1.05 line-height.
• Body: Space Grotesk at 400 weight with generous 1.5 line-height so long passages read like a broadcast lower-third.
• Micro-labels (LIVE, PRODUCTION QUEUE, LIVE TRANSCRIPT): 11px uppercase, 0.18em tracking, #8892A6.
• Numeric and reference data (verse addresses, timestamps, queue indices): JetBrains Mono at 12–13px.
• Scale: 1.333 modular — 12 / 13 / 16 / 21 / 28 / 38 / 50. Hero display on Landing: 38px mobile → 50px tablet → 72px desktop (clamp(38px, 6vw, 72px)). Verse text 21px mobile → 28px desktop. Panel titles 13px uppercase. Body 16px. Micro-labels 11px.

Shape language. Rounded-rect cards with 14–18px radii, thin 1px luminous strokes at #00A8FF at 30% opacity, soft inner glow on the projection card, hairline dividers between HUD rows. The projection card is the one volumetric object — a deep blue slab that appears to sit slightly above the charcoal ground with a subtle radial glow behind its title. Controls are capsules (search bar, dispatch button) with 999px radii. No drop-shadow clutter: depth comes from glow, not from grey shadows.

Layout. Mobile-first vertical stack that becomes a HUD grid at wider widths. Persistent top bar (wordmark left, LIVE dot right) 56px tall. Landing is a single full-viewport composition: the projection card dominates, a thin scan-line of live transcript runs beneath it, and the dispatch control sits bottom-right like a cockpit switch. Console is a three-zone HUD: (1) projection card full-width at top, (2) two-column grid at ≥768px for Live Transcript and Production Queue, stacked at 375px, (3) bottom dock with search bar and DISPATCH TO SCREEN button. Every panel is a deep blue card with a 1px luminous top rule and an uppercase micro-label. At 1280px the grid becomes a 12-column layout with the projection card spanning 8 columns and a live data rail spanning 4.

Imagery. The interface itself is the imagery: glowing HUD panels, thin luminous strokes, a faint radial glow behind the projection card, and a subtle grid of 1px dots at 4% opacity across the charcoal ground suggesting a projection screen's pixel matrix. No stock photography, no flat clip art. The one graphic motif is a set of concentric arc segments (echoing a projection beam) used as a section divider and as the empty-state mark in the Production Queue.

7. Signature Design Concept

The Landing hero is a full-viewport charcoal (#121212) field with a faint dotted pixel grid at 4% opacity. Dominating the frame, bleeding from the left edge to the right edge at 92% width, is the deep blue (#0A192F) projection card — a 14px-radius slab with a 1px #00A8FF stroke at 30% opacity and a soft #00A8FF radial glow behind its top edge. Inside, the verse title PSALM 32:1 (NKJV) sits in 13px uppercase #00A8FF with 0.18em tracking, and the verse text Blessed is he whose transgression is forgiven, Whose sin is covered. is set in 38–72px Space Grotesk 400 weight #E8EDF5, wrapping across three lines. Below the card, a single 56px-tall strip of live transcript text scrolls right-to-left in JetBrains Mono 13px #8892A6, clipped by the viewport edge as it moves. In the bottom-right corner, a 56px-tall capsule button in #FF6B35 reads DISPATCH TO SCREEN in white 14px uppercase with 0.12em tracking, with a thin #00A8FF focus ring. No centred headline-and-subtext stack, no gradient blob, no blue CTA on white — the composition is a cockpit, not a marketing page.

Signature moves.

• The projection card as a volumetric HUD slab: deep blue #0A192F with a 1px #00A8FF luminous stroke, a soft radial glow behind its top edge, and a 400ms light-sweep animation across its face every time a verse is dispatched.
• A live "on air" pulse: the LIVE indicator is a #00A8FF dot with a 2.4s expanding halo ring, and the DISPATCH TO SCREEN capsule carries a 1px #FF6B35 outer pulse while a dispatch is resolving.
• A HUD micro-label system: every panel opens with an uppercase 11px 0.18em-tracked #8892A6 label (LIVE TRANSCRIPT, PRODUCTION QUEUE) sitting on a 1px luminous top rule, so the console reads like an instrument cluster rather than a card grid.
• Monospace data voice: verse references, timestamps, and queue indices are set in JetBrains Mono, and the Production Queue renders each row as a ruled data line with a status glyph (■ active in #00A8FF, □ ready in #8892A6,\x20\xe2\x9a\xa0 mismatch in #FF6B35).
• A scrolling transcript strip that bleeds off the viewport edge and moves continuously, with prefers-reduced-motion turning it into a horizontally scrollable row where each line can be brought fully into view.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: layered_2d

Landing Hero Motion Brief

Focal subject. The deep blue projection card slab, bleeding from the left edge to the right edge at 92% width, with the verse title and verse text inside it.

Input → transformation → outcome thesis. The operator's dispatch input (a verse address or phrase submitted via Enter/Done or DISPATCH TO SCREEN) transforms into a resolved verse: the projection card performs a 400ms #00A8FF light sweep left-to-right across its face, then the verse text crossfades in over 260ms. The outcome is the matched verse visible on the projection card, with the queue and transcript updated to record the dispatch.

Motion vocabulary. Restrained-to-expressive HUD motion. The LIVE dot pulses at 2.4s intervals. The projection card light sweep is 400ms. The verse text crossfade is 260ms. New queue rows slide in from the right with a 12px offset and fade over 220ms. The transcript stream auto-scrolls with a soft 300ms ease. No bounce, no particles outside the projection card.

Composed first frame. The charcoal field with the dotted pixel grid; the projection card slab centered and bleeding to the edges; the verse title PSALM 32:1 (NKJV) in 13px uppercase #00A8FF; the verse text in 38–72px Space Grotesk 400 weight #E8EDF5; the transcript strip scrolling beneath the card; the DISPATCH TO SCREEN capsule in the bottom-right corner with its #00A8FF focus ring.

Reduced-motion state. With prefers-reduced-motion, all sweeps become instant state changes and the LIVE dot becomes a static filled circle. The transcript strip becomes a horizontally scrollable row where each line can be brought fully into view.

9. Non-Functional Requirements

NFR-1 — Mobile-first responsive layout. The console must remain readable and operable at 375px, 768px, and 1280px. At 375px the Live Transcript and Production Queue stack vertically; at ≥768px they form a two-column grid; at 1280px the grid becomes a 12-column layout with the projection card spanning 8 columns and a live data rail spanning 4. Provenance: explicit (creative direction). Rationale: the operator uses a mobile device in the tech booth, and the console must scale to tablet and desktop widths without losing the HUD composition.

NFR-2 — Readable text and controls stay whole. Headlines, wordmarks, labels, numbers, cards' text and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element may cover any part of them. Provenance: explicit (creative direction). Rationale: the operator must be able to read the verse and the queue at a glance during a live service.

NFR-3 — Reduced-motion support. With prefers-reduced-motion, all sweeps become instant state changes, the LIVE dot becomes a static filled circle, and the transcript strip becomes a horizontally scrollable row where each line can be brought fully into view. Provenance: explicit (creative direction). Rationale: accessibility for operators who are motion-sensitive.

NFR-4 — Local-only scripture lookup. Scripture lookup must be served by the local mock scripture index embedded in the app, not an external scripture service. Provenance: explicit (hard constraint). Rationale: the app must work without network dependency during a live service.

NFR-5 — Read-only observation panels. The Live Transcript and Production Queue panels must be read-only. Provenance: explicit (hard constraint). Rationale: the operator observes these streams; editing them would corrupt the live record.

NFR-6 — Dark charcoal and deep blue styling. The app must render on a dark charcoal (#121212) background with deep blue (#0A192F) projection card styling. Provenance: explicit (hard constraint). Rationale: the dark room and the glowing projection card are the product's visual identity.

NFR-7 — Kivy mobile delivery. The app must be delivered as a Kivy mobile application. Provenance: explicit. Rationale: the operator uses a mobile device in the tech booth.

10. Tech Stack

• Kivy — the mobile application framework specified by the user. The app is built as a Kivy App subclass (PewbeamMobile) with BoxLayout, GridLayout, Label, TextInput, Button, and ScrollView widgets, and Window.clearcolor set to #121212.
• Python — the language of the Kivy application.
• Local mock scripture index — an in-app Python dictionary keyed by verse references, containing the four verified entries. No external scripture service, no database server, no network dependency.
• Fonts — Space Grotesk (headings and body) and JetBrains Mono (numeric and reference data), as specified by the creative direction.

11. Assumptions and Constraints

Assumptions.

• The operator uses a mobile device in the church tech booth during a live service. [Default — not specified by user]
• The projection screen is a separate physical display that the app's projection card mirrors; the app does not directly control the projection hardware. [Default — not specified by user]
• The local mock scripture index is sufficient for the current delivery; no external scripture service is required or permitted. [Explicit]
• The app is used by a single operator at a time; no multi-user concurrency is required. [Default — not specified by user]

Constraints.

• Scripture lookup is served by a local mock scripture index database embedded in the app, not an external scripture service. [Explicit]
• The Live Transcript and Production Queue panels are read-only. [Explicit]
• The app is a mobile (Kivy) application with a dark charcoal background and deep blue projection card styling. [Explicit]
• The DISPATCH TO SCREEN action and the mismatch warning are the only uses of #FF6B35; the accent must not be used for anything else. [Explicit — creative direction]
• No blue-indigo (#0057FF, #2563EB, #4F46E5, #6366F1) on white; the ground is always #121212 charcoal. [Explicit — creative direction]
• No Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or body. [Explicit — creative direction]
• No gradient-blob hero backgrounds, no grid of identical hover-lift cards, no glassmorphism panels, no bright pastel or candy-colour surfaces, no centred marketing-style hero, no decorative particle fields or floating 3D props. [Explicit — creative direction]

12. Glossary

• Operator — the single accepted active human persona; the person running the Pewbeam AI console during a live service.
• Projection card — the deep blue (#0A192F) HUD slab that displays the current slide title and verse text.
• Slide title — the reference line at the top of the projection card, e.g. Psalm 32:1 (NKJV), PSALM 32:1 (AI EXACT), or ... (CONTEXT MATCH).
• Verse text — the scripture passage displayed on the projection card.
• Live Transcript — the read-only panel showing the AI listening stream of the pastor's spoken words.
• Production Queue — the read-only panel listing active, ready, and mismatch items with status glyphs.
• Dispatch — the act of submitting a verse address or phrase via Enter/Done or the DISPATCH TO SCREEN button.
• Exact match — a query that matches a key in the local scripture index; the slide title gains the (AI Exact) suffix.
• Context match — a query that matches verse text or a reference without matching a key; the slide title gains the (Context Match) suffix.
• Mismatch — a query that matches neither a key nor any verse text or reference; a ⚠ Clear mismatch for '...' warning is prepended to the Production Queue log.
• Local scripture index — the in-app mock database keyed by verse references, containing the four verified entries.
• HUD — the heads-up-display visual language of the console: dark voids, glowing panels, thin luminous strokes, and uppercase micro-labels.
• LIVE dot — the #00A8FF status indicator in the top bar with a 2.4s expanding halo ring.