System Requirements Document for rapid-ia

1. Introduction

rapid-ia is a public AI question-answering website. Its product intent, taken directly from the authoritative requirement thread, is twofold and current:

• Criar um site de IA — build an AI website.
• O site deve responder a qualquer pergunta feita pelo usuário — the site must answer any question the user asks.

The audience is any curious visitor who arrives with an arbitrary question in natural language, with no account and no setup, and expects to receive a generated answer on the site itself. The product should feel like consulting a powerful intelligence: fast, clear, and a little awe-inspiring — a portal to a thinking machine rather than a friendly chatbot toy or a neutral utility.

This document defines the current delivery (a single public entry surface that explains the AI site and hosts the ask-and-answer flow), the closed persona catalog, the functional requirements, the page content coverage, the core user flows, the visual and motion direction, and the supporting non-functional and technical constraints.

2. System Overview

rapid-ia is delivered as a single-page public web experience with a full-viewport hero built around a real-time 3D luminous orb, a wide luminous question-input capsule, and a vertical answer stream of glass panels. A visitor types a question in natural language, submits it, and reads the generated answer rendered directly on the page.

Actors

• Visitante — the single accepted active human persona. A human who arrives with an arbitrary question, formulates it in natural language, submits it, and reads the generated answer. No account, no configuration, no setup.
• AI answering service — a typed non-persona actor (external/system provider). It receives the submitted question and produces the generated answer text and its associated metadata (model, latency, tokens) that the site displays.

Accepted behavior

• The site explains itself as an AI question-answering product on arrival.
• The visitor writes any question in natural language and submits it.
• The site returns a generated answer to that question and displays it on the page.
• The answer is presented as a stream of glass panels, each with a mono metadata row above the answer body.

Ownership

• The Landing page (application-owned, public, no access requirement) owns the entire accepted lifecycle: entry, question composition, submission, answer display, and recovery.
• The AI answering service owns answer generation only; it is not a human-facing destination.

Narrow exclusions

• No account creation, sign-in, or identity establishment is required or provided for the accepted flow.
• No adjacent account-management, billing, history-persistence, or collaboration capabilities are in scope.
• No photographic stock imagery, clip art, or illustrated characters are used.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. rapid-ia is a first-party, application-owned public website. The visitor-facing surface is custom UI built for this product. The AI answering capability is delivered by an external AI answering service that the site calls; the site owns the question input, the submission interaction, the answer presentation, and the recovery states, while the service owns the generation of the answer content itself.

Access ownership. The Landing page is public and requires no access credential. The accepted persona arrives with no account and no setup, and the accepted requirement thread contains no identity, sign-in, or account requirement. Access to the ask-and-answer flow is therefore anonymous and immediate. No protected destination exists in the current delivery, so no identity establishment or verification interaction is introduced.

Current vs. future boundary. Everything described in this document is current. No future-horizon requirements were stated in the authoritative thread; nothing in this document should be read as committing to capabilities beyond answering a visitor's question on the public site.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

Purpose and information/state. The public entry surface. It explains the AI site and hosts, in one cohesive flow, the writing and submission of a question and the display of generated answers. It is reachable with no access requirement.

Information and state shown

• Product identity micro-label: RAPID-IA / ASK ANYTHING in mono uppercase at 12px with 0.18em tracking.
• Hero statement: PERGUNTE QUALQUER COISA in Space Grotesk, uppercase, tight leading, set at clamp(56px, 9vw, 128px), spanning the viewport as a horizontal band beneath the input.
• The question input capsule, empty by default, with placeholder guidance inviting any question.
• The answer stream region: empty on first load, populated with one glass panel per submitted question.
• Per-answer metadata row: model, latency, tokens, in IBM Plex Mono at 12–13px uppercase with wide tracking.
• Left rail micro-labels on desktop: ASK / ANSWER / SOURCES, in mono uppercase with corner tick marks, tracking scroll position like a HUD; on mobile these collapse into small inline labels above each section.

Primary actions

• Type a question into the input capsule.
• Submit the question via the cyan send button pinned to the right edge of the capsule.
• Read the generated answer in the answer stream.
• Re-submit a new question at any time, appending a new panel to the stream.

Supporting actions

• Focus the input, which raises its border luminance and starts a faint pulse in the orb.
• Scroll through the answer stream, which drives a scroll-linked camera drift on the orb.
• Hover the input, which raises border luminance and starts the orb pulse.

Domain entities

• Question — the natural-language text the visitor composes and submits.
• Answer — the generated response text returned for a question.
• Answer metadata — model, latency, tokens associated with a generated answer.
• Answer stream — the ordered, single-column, variable-height sequence of answer panels.

Component responsibilities

• Void ground layer — full-bleed dark background #05060E covering the page.
• 3D orb — the dominant hero subject: a slowly rotating volumetric orb of layered translucent shells with a cyan core and violet outer haze, roughly 60vh on desktop and 38vh on mobile, centred with a violet halo bleeding into the black. It orbits on a 60s cycle, parallaxes subtly to cursor position, and pulses faintly when the input is focused or hovered.
• Product micro-label — the small mono uppercase identity line above the orb.
• Question input capsule — a wide luminous capsule spanning 8 of 12 desktop columns and full width minus 24px gutters on mobile, with a 999px radius and a 1px luminous border.
• Send button — an electric-cyan capsule control pinned to the right edge of the input capsule.
• Hero headline band — the oversized uppercase statement beneath the input, acting as a section rule.
• Answer stream — a single column of variable-height glass panels, each with a cyan-glow left border, a mono metadata row above the body, and a typed token-by-token reveal with a cyan glow pulse and a horizontal light sweep across the panel's 1px border.
• Left rail HUD — the desktop micro-label rail with corner tick marks; collapses to inline labels on mobile.
• Generative supporting imagery — particle fields behind the orb, thin HUD rings with tick marks, and mono data readouts. Purely generative and diagrammatic; no photography or clip art.

States

• Loading — after submission, the orb enters its thinking/orb state with a violet glow, and the pending answer panel shows the metadata row in a pending state while the answer is generated.
• Empty — on first load, the answer stream region is empty and the input capsule is empty with placeholder guidance; the orb is in its idle slow orbit.
• Success — the answer panel appears below with a cyan-glow left border, the answer body types in token-by-token with a cyan glow pulse and a horizontal light sweep across the panel border, and the metadata row shows model, latency, and tokens.
• Error — if the AI answering service fails to return an answer, the pending panel resolves into an error state that names the failure and preserves the submitted question text.
• Recovery — the visitor can retry the failed question from the error state, or edit the question in the input capsule and submit again; the input retains the question text so nothing is lost.

3. Functional Requirements

FR-1 — Public entry and product explanation As a Visitante, I should arrive at a public page that explains the AI site and presents the question input, so that I understand what the product does and can immediately ask something.

• Provenance: explicit (site creation) + required_inference (public entry surface).
• Trigger/input: the visitor opens the site.
• Observable result: the Landing page renders the void hero, the RAPID-IA / ASK ANYTHING micro-label, the 3D orb, the question input capsule, and the PERGUNTE QUALQUER COISA headline band.
• Access state: public, no access requirement, no account, no setup.
• Failure/recovery: if the hero subject cannot render, the page still presents the micro-label, input capsule, and headline as a usable static arrangement.
• Continuation: the visitor proceeds to compose a question.

FR-2 — Compose a question in natural language As a Visitante, I should write any question I have in natural language into the input capsule, so that I can ask the AI anything.

• Provenance: explicit.
• Trigger/input: the visitor types into the question input capsule.
• Observable result: the question text appears in the capsule; focusing or hovering the capsule raises its border luminance and starts a faint pulse in the orb.
• Access state: public, no access requirement.
• Failure/recovery: the input remains editable at all times; text is not lost on a failed submission.
• Continuation: the visitor submits the question.

FR-3 — Submit the question As a Visitante, I should submit my question with the send action, so that the AI begins answering it.

• Provenance: explicit.
• Trigger/input: the visitor activates the cyan send button pinned to the right edge of the input capsule.
• Observable result: the question is dispatched to the AI answering service; the orb enters its thinking state with a violet glow; a pending answer panel appears in the answer stream.
• Access state: public, no access requirement.
• Failure/recovery: if dispatch fails, the pending panel resolves into an error state that names the failure and preserves the question text for retry.
• Continuation: the visitor waits for the answer, or retries.

FR-4 — Receive and read the generated answer As a Visitante, I should see the AI's answer to my question rendered on the page, so that my question is answered without leaving the site.

• Provenance: explicit.
• Trigger/input: the AI answering service returns a generated answer for the submitted question.
• Observable result: an answer panel appears below with a cyan-glow left border; the answer body types in token-by-token with a soft cyan glow pulse and a thin horizontal light sweep across the panel's 1px border; a mono metadata row above the body shows model, latency, and tokens.
• Access state: public, no access requirement.
• Failure/recovery: if the service returns no answer or an error, the panel shows an error state naming the failure and preserving the question; the visitor can retry or edit and resubmit.
• Continuation: the visitor reads the answer and may ask another question.

FR-5 — Ask additional questions in the same session As a Visitante, I should be able to ask another question after reading an answer, so that I can keep consulting the AI without reloading or reconfiguring anything.

• Provenance: required_inference (indispensable continuation of the accepted ask-and-answer lifecycle).
• Trigger/input: the visitor types a new question into the input capsule and submits it.
• Observable result: a new answer panel is appended to the single-column answer stream below the previous one; the stream grows and drives a scroll-linked camera drift on the orb.
• Access state: public, no access requirement.
• Failure/recovery: a failed new question produces its own error panel without disturbing previously answered panels.
• Continuation: the visitor continues reading or asking.

FR-6 — Answer generation by the AI service As the AI answering service, I should receive the submitted question and produce the answer text and its metadata, so that the site can display a response to any question asked.

• Provenance: explicit (the site must answer any question) + required_inference (the service boundary that makes it possible).
• Trigger/input: the submitted question text from the Landing page.
• Observable result: generated answer text plus model, latency, and token metadata returned to the site.
• Access state: provider-owned; not a human-facing destination.
• Failure/recovery: on failure or timeout, the service returns an error condition that the Landing page surfaces as a recoverable error panel.
• Continuation: the site renders the answer or the error state.

FR-7 — Reduced-motion usable arrangement As a Visitante who prefers reduced motion, I should still be able to ask and read answers in a usable static arrangement, so that the product works for me without decorative motion.

• Provenance: explicit (creative direction) + required_inference (accessibility of the accepted flow).
• Trigger/input: the visitor's prefers-reduced-motion setting is active.
• Observable result: the orb becomes a static gradient sphere, the answer stream reveals instantly without typing or light sweep, and no cursor parallax runs; the input, send button, headline, and answer panels remain fully readable and operable.
• Access state: public, no access requirement.
• Failure/recovery: not applicable; this is the fallback state itself.
• Continuation: the visitor asks and reads answers normally.

4. User Personas

Visitante

Product context. The Visitante is the single accepted active human persona for rapid-ia. They arrive at the public site from anywhere, with no account, no setup, and no prior configuration. They may be curious, in a hurry, or mid-task with a specific doubt. They have not been onboarded, they have not been shown a tutorial, and they do not expect to create anything.

Primary goal. Get a question answered. The Visitante's goal is to turn an arbitrary natural-language question into a readable, generated answer on the page, quickly and without friction.

Distinct accepted responsibilities.

• Formulate a question in natural language — any question, with no topic restriction imposed by the product.
• Submit that question through the send action on the input capsule.
• Read the generated answer and its metadata (model, latency, tokens) in the answer stream.
• Decide whether to ask another question, retry a failed one, or leave.

Relevant inputs and decisions. The Visitante's inputs are the question text and the submission action. Their decisions are: what to ask, whether the answer is sufficient, whether to ask a follow-up question, and whether to retry after a failure.

Interactions with other accepted participants. The Visitante interacts with the AI answering service only indirectly: they submit a question, and the service returns the answer that the site renders. The Visitante never sees or configures the service; the handoff is invisible and the observable result is the answer panel.

Observable success. The Visitante's question appears in the input capsule, the answer panel appears below with its metadata row, and the answer body is readable. Success is having their question answered on the site itself, with no account and no setup.

What makes this role distinct. The Visitante is the only human actor, and their work is entirely one-directional: ask, read, optionally ask again. There is no counterparty to negotiate with, no shared state to coordinate, and no administrative or review responsibility. The role's difficulty is not procedural but interpretive — the visitor must phrase a question well enough to get a useful answer, and must judge the answer's usefulness themselves.

5. Core User Flows

Flow 1 — Ask a question and read the answer

1. Starting context. The Visitante opens the rapid-ia site in a browser. No account, no sign-in, no setup.
2. Entry. The Landing page renders: the dark void ground, the RAPID-IA / ASK ANYTHING micro-label, the slowly rotating 3D orb, the wide question input capsule with its cyan send button, and the PERGUNTE QUALQUER COISA headline band beneath the input. The answer stream region is empty.
3. Compose. The Visitante clicks into the input capsule and types their question in natural language. On focus, the capsule's border luminance rises and the orb starts a faint pulse, linking the input to the subject.
4. Submit. The Visitante activates the cyan send button pinned to the right edge of the capsule.
5. Pending state. The question is dispatched to the AI answering service. The orb enters its thinking state with a violet glow, and a pending answer panel appears in the answer stream with its metadata row in a pending state.
6. Answer arrives. The AI answering service returns the generated answer text with model, latency, and token metadata. The answer panel resolves below with a cyan-glow left border; the answer body types in token-by-token with a soft cyan glow pulse and a thin horizontal light sweep across the panel's 1px border; the metadata row shows model, latency, and tokens.
7. Read. The Visitante reads the answer. The question has been answered on the site itself.
8. Continuation. The Visitante may type another question into the input capsule and submit it; a new panel is appended below in the single-column stream, and scrolling the growing stream drives a scroll-linked camera drift on the orb.

Flow 2 — Recover from a failed answer

1. Starting context. The Visitante has submitted a question and is waiting on the pending answer panel.
2. Failure. The AI answering service fails to return an answer, or returns an error condition.
3. Observable error. The pending panel resolves into an error state that names the failure. The submitted question text is preserved in the input capsule.
4. Recovery decision. The Visitante either activates retry on the failed panel, or edits the question in the input capsule and submits again.
5. Result. On success, the answer panel resolves as in Flow 1, step 6. Previously answered panels in the stream are undisturbed.
6. Continuation. The Visitante reads the answer or asks another question.

Flow 3 — Ask with reduced motion enabled

1. Starting context. The Visitante's system has prefers-reduced-motion active.
2. Entry. The Landing page renders with the orb as a static gradient sphere, no cursor parallax, and no decorative motion. The micro-label, input capsule, send button, and headline band are fully readable and operable.
3. Compose and submit. The Visitante types a question and activates the send button exactly as in Flow 1.
4. Answer arrives. The answer panel appears instantly without typing animation or light sweep; the metadata row and answer body are fully readable.
5. Continuation. The Visitante reads the answer and may ask another question.

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. The muse is Gleb Kuznetsov; the headline direction is "Cinematic future tech — an AI oracle in a dark void." The product should feel like consulting a powerful intelligence: a little awe, speed, and clarity.

Color tokens (dark mode)

Color rules. Near-black navy ground #05060E covers most of the page. Panels are translucent #0D1020 at 70–85% opacity with 1px rgba(255,255,255,0.10) borders. Electric cyan #00E5FF is the primary signal used for the answer stream, active borders, and the send action. Violet #C77DFF is the secondary glow used for the thinking/orb state and hover washes. Body text is cool near-white #F2F5FF at 16px (contrast ~16:1); muted #7A84A8 is for micro-labels only. Never place cyan text on violet; never use cyan as a large flat fill behind small text.

Typography

• Headings: Space Grotesk — wide geometric display, uppercase micro-labels with 0.18em tracking, headings at 500–600 weight with tight leading (0.95–1.05) so the wordmark and hero statement read as a machine interface rather than marketing copy.
• Body and data: IBM Plex Mono. Data and metadata set at 12–13px uppercase with wide tracking.
• Scale (1.25 modular): hero display clamp(56px, 9vw, 128px); section heading clamp(28px, 4vw, 48px); panel title 20px; body 16px/1.7; micro-label 12px uppercase +0.18em; data 13px mono. Mobile hero floors at 56px; desktop caps at 128px.

Shape language

Full-bleed 3D void as the ground layer. Floating glass panels with 2px continuous-curve radii (12–16px), 1px luminous borders at 10–14% white, and thin 1px cyan strokes (0.5–1px) for active states. Radial layout around a central luminous orb. No drop shadows — depth comes from blur, opacity, and glow. Buttons and the input are capsules with a 999px radius; all other panels stay at 12–16px. Hairline rules and corner ticks frame data rows.

Layout

Single-page landing with a full-viewport hero: the AI orb is the dominant element, centred, roughly 60vh tall on desktop and 38vh on mobile. The question input sits directly beneath the orb as a wide capsule spanning 8 of 12 columns on desktop and full width minus 24px gutters on mobile. Answers render below in a vertical stream of glass panels, each with a mono metadata row (model, latency, tokens) above the answer body. A thin left rail on desktop holds micro-labels (ASK / ANSWER / SOURCES) in mono caps; on mobile this collapses into small inline labels above each section. Section transitions use diagonal cuts and a faint scanline rule rather than rounded dividers. No identical card grid — the answer stream is a single column of variable-height panels.

Imagery

No photography, no clip art. The hero subject is a single crafted real-time 3D object: a slowly rotating volumetric orb built from layered translucent shells with a cyan core and violet outer haze, rendered with Three.js / React Three Fiber. Supporting imagery is purely generative and diagrammatic: particle fields behind the orb, thin HUD rings with tick marks, and mono data readouts. The answer stream itself is the content image.

Readability constraint

Readable text and controls stay whole at every viewport: headlines, wordmarks, labels, numbers, panel text, and controls 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 covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, as long as they cover no readable text or control. With prefers-reduced-motion, a usable static arrangement is provided.

7. Signature Design Concept

The instrument panel around a glowing core.

The public entry is composed as a vertical instrument panel rather than a marketing hero. A full-viewport dark void (#05060E) fills the screen. At its centre sits the dominant subject: a single luminous 3D orb, roughly 60vh on desktop and 38vh on mobile, built from layered translucent shells with a cyan core and a violet outer haze that bleeds into the black. Above it, a small mono uppercase micro-label reads RAPID-IA / ASK ANYTHING at 12px with 0.18em tracking.

Directly beneath the orb, the question input capsule spans 8 of 12 desktop columns (full width minus gutters on mobile), with the electric-cyan send button pinned to its right edge. Focusing or hovering the capsule raises its border luminance and starts a faint pulse in the orb, so input and subject feel physically linked.

Beneath the input, the headline PERGUNTE QUALQUER COISA is set in Space Grotesk at clamp(56px, 9vw, 128px), uppercase, tight leading, spanning the viewport as a wide horizontal band that acts as a section rule rather than a marketing line. It wraps to two lines on mobile without clipping or being covered.

Below the headline band, the first answer panel appears with a cyan-glow left border, its mono metadata row above the answer body. A thin left rail of mono uppercase micro-labels (ASK / ANSWER / SOURCES) with corner tick marks tracks the scroll position like a HUD, collapsing to inline labels on mobile.

Nothing here is a centred headline plus subtext plus blue button plus gradient blob. The composition is a vertical instrument panel around a glowing core, and the answer stream is the content image.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: webgl

Landing Hero Motion Brief

Focal subject. The single crafted real-time 3D orb: layered translucent shells with a cyan core and violet outer haze, rendered with Three.js / React Three Fiber, roughly 60vh on desktop and 38vh on mobile, centred with a violet halo bleeding into the black.

Input → transformation → outcome thesis. The visitor's question enters the input capsule; on focus the capsule's border luminance rises and the orb begins a faint pulse, linking input to subject. On submission the orb shifts into its thinking state with a violet glow while the pending answer panel appears. When the answer returns, the answer body types in token-by-token with a soft cyan glow pulse and a thin horizontal light sweep across the panel's 1px border, and the metadata row resolves to model, latency, and tokens. The transformation is: a question becomes a visible act of thinking, and the thinking resolves into a streamed answer.

Motion vocabulary. Continuous slow orbit of the orb on a 60s cycle; subtle parallax response to cursor position; a faint orb pulse on input focus and hover; typed token-by-token answer reveal with a cyan glow pulse; a thin horizontal light sweep across the panel border; scroll-linked camera drift on the orb as the answer stream grows.

Composed first frame. Full-viewport dark void. The orb centred and slowly rotating, violet halo bleeding outward. The RAPID-IA / ASK ANYTHING micro-label above it. The wide luminous input capsule beneath it with the cyan send button pinned right. The PERGUNTE QUALQUER COISA headline band spanning the viewport below the input. The answer stream region empty. The left rail micro-labels visible on desktop.

Reduced-motion state. Under prefers-reduced-motion, the orb becomes a static gradient sphere, the answer stream reveals instantly with no typing or light sweep, and no cursor parallax runs. The micro-label, input capsule, send button, headline band, and answer panels remain fully readable and operable.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

The direction specifies webgl hero dimensionality, so a real-time 3D hero is expected.

• Object. One crafted real-time orb: layered translucent shells, a cyan core (#00E5FF), and a violet outer haze (#C77DFF), rendered with Three.js / React Three Fiber.
• Defining state shown. The orb is the product's "brain" visible on first load — it rotates slowly on a 60s cycle, parallaxes subtly to cursor position, pulses faintly when the input is focused or hovered, and shifts to a violet thinking glow while an answer is pending.
• Supporting scene elements. Particle fields behind the orb, thin HUD rings with tick marks, and mono data readouts. Purely generative and diagrammatic.
• Scroll behavior. A scroll-linked camera drift on the orb as the answer stream grows.
• Reduced-motion behavior. The orb becomes a static gradient sphere; no orbit, no parallax, no pulse.

9. Non-Functional Requirements

NFR-1 — Public, no-account access. The Landing page is reachable with no access requirement, no account, and no setup. Provenance: explicit (the accepted persona arrives with no account or configuration) + required_inference (public entry surface). Rationale: the accepted flow must be immediately usable by any visitor.

NFR-2 — Readability at all viewports. Headlines, wordmarks, labels, numbers, panel text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Provenance: explicit (creative direction). Rationale: the accepted content must remain readable and operable.

NFR-3 — Reduced-motion support. All decorative motion is disabled under prefers-reduced-motion: the orb becomes a static gradient sphere, the stream reveals instantly, and no cursor parallax runs. Provenance: explicit (creative direction). Rationale: the accepted flow must remain usable without decorative motion.

NFR-4 — Answer latency visibility. Each answer panel displays a mono metadata row with model, latency, and tokens above the answer body. Provenance: explicit (creative direction). Rationale: the product should feel like a fast, transparent thinking machine.

NFR-5 — Contrast and color safety. Body text #F2F5FF on #05060E achieves approximately 16:1 contrast. Cyan text is never placed on violet, and cyan is never used as a large flat fill behind small text. Provenance: explicit (creative direction). Rationale: legibility of the answer stream and controls.

NFR-6 — Generative imagery only. No photography, no clip art, no illustrated characters. All supporting imagery is generative and diagrammatic. Provenance: explicit (creative direction). Rationale: the void-and-orb register must not be broken by stock imagery.

NFR-7 — Backend integration for answer generation. The site integrates with an AI answering service to generate answers. Provenance: explicit (the site must answer any question) + required_inference (the service boundary). Rationale: answer generation cannot be performed by the client alone.

10. Tech Stack

• Frontend: React, single-page public landing.
• 3D hero: Three.js with React Three Fiber for the real-time orb, particle fields, and HUD rings. Provenance: explicit (creative direction).
• Backend: Python with FastAPI, exposing the question-submission endpoint that calls the AI answering service and returns the answer text with model, latency, and token metadata. Provenance: required_inference (backend integration is required for answer generation).
• Storage: Not specified by the user. No persistence of questions or answers is required by the accepted flow; the answer stream is session-scoped in the browser. [Default — not specified by user]
• Containerization: Docker with docker-compose for local and deployment packaging. [Default — not specified by user]
• Orchestration: Kubernetes is not required by the accepted scope. [Default — not specified by user]

11. Assumptions and Constraints

Assumptions

• A-1. The AI answering service is an external provider that accepts a natural-language question and returns generated answer text plus model, latency, and token metadata. This is a required inference from the accepted requirement that the site answer any question.
• A-2. The answer stream is session-scoped: answers remain visible while the visitor stays on the page, and no durable history is persisted. This is a required inference; no persistence requirement was stated.
• A-3. "Any question" means the product imposes no topic restriction of its own on the visitor's question; the AI answering service's own content policy governs what it returns. This is a required inference from the explicit requirement wording.
• A-4. The visitor's browser supports WebGL. Where it does not, the reduced-motion static arrangement is used as the fallback. This is a required inference from the explicit WebGL hero direction.

Constraints

• C-1. The Landing page is public with no access requirement; no account creation, sign-in, or identity establishment is introduced. Provenance: explicit (accepted persona arrives with no account or setup).
• C-2. The palette, typography, shape language, layout, motion, and imagery follow the creative direction exactly as specified in sections 6, 7, and 8.
• C-3. The generic indigo/blue-on-white SaaS template is forbidden for this project. Provenance: explicit (creative direction).
• C-4. Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are not used for headings or body. Provenance: explicit (creative direction).
• C-5. No photographic stock people or clip-art illustrations are used. Provenance: explicit (creative direction).
• C-6. No bouncy, playful easing or confetti-style micro-interactions are used. Provenance: explicit (creative direction).
• C-7. Decorative motion never ignores prefers-reduced-motion. Provenance: explicit (creative direction).
• C-8. No adjacent account-management, billing, history-persistence, or collaboration capabilities are added. Provenance: explicit (no such requirements in the authoritative thread).

12. Glossary

• Visitante — the single accepted active human persona of rapid-ia; a public visitor who arrives with an arbitrary question, no account, and no setup.
• Landing — the single public entry page of rapid-ia; it explains the AI site and hosts the ask-and-answer flow.
• Question — the natural-language text the Visitante composes and submits.
• Answer — the generated response text returned for a submitted question.
• Answer metadata — the model, latency, and token values displayed in the mono metadata row above each answer body.
• Answer stream — the ordered, single-column, variable-height sequence of glass answer panels on the Landing page.
• AI answering service — the external provider that receives a submitted question and returns the generated answer text and metadata.
• Orb — the real-time 3D hero subject: layered translucent shells with a cyan core and violet outer haze, rendered with Three.js / React Three Fiber.
• Thinking state — the orb's violet-glow state while an answer is pending.
• Reduced-motion state — the static arrangement used when prefers-reduced-motion is active: static gradient sphere, instant answer reveal, no cursor parallax.