System Requirements Document for azure-deepfake

1. Introduction

azure-deepfake is a web application for producing realistic face-swap video from a creator's own uploaded media. A creator uploads a source video and a face source image, the system applies a realistic face swap, and the creator reviews and obtains the resulting swapped video.

The product intent is a serious visual-effects instrument for a creator audience — editors, motion designers, and content makers — who want a convincing face swap on footage they own. The product is explicitly not a tool for making deepfakes of real people; the interface and language frame all media as the user's own, and the experience reads as a controlled, consent-aware studio.

Audience: a single active human role, the Face-swap video creator, working in a self-service, account-based studio.

2. System Overview

azure-deepfake is delivered as a first-party web application with a custom UI and an application-owned backend that performs the face-swap processing.

Current delivery comprises:

• A public Landing page that explains the face-swap video product, who it is for, and what it does, and that surfaces the "your own media only" consent rule.
• Anonymous Sign Up (self-service first-use enrollment) and Login (returning verification) surfaces that establish application-owned identity.
• A protected New Swap page where the signed-in creator uploads their own source video and a face source image and starts a realistic face swap.
• A protected Swap Result page where the creator reviews the resulting swapped video and obtains the output.
• A protected Live Studio page where the signed-in host runs a real-time face swap on their own live camera feed, hosted on the web, with a host-controlled guest track option.
• A protected Credits page where the signed-in user buys credits through the payment gateway and sees the balance available for real-time swaps.

Actors:

• Face-swap video creator (active human persona) — the only human actor.
• Live swap host (active human persona, the same creator in a live-hosting responsibility) — hosts a real-time swap on the web and controls the guest track option.
• Credit buyer (active human persona, the same creator in a purchasing responsibility) — buys credits through the payment gateway to run real-time swaps.
• Face-swap processing service (system actor, application-owned backend) — executes the realistic face swap on the uploaded media and produces the output video, and executes the real-time swap on the live camera feed. It is not a persona and has no independent product surface.
• Payment gateway (external system actor) — processes credit purchases on behalf of the application. It is not a persona and has no independent product surface inside the studio.

Narrow exclusions: the product does not create deepfakes of real people and does not operate on media the user does not own. It does not provide a stock or third-party face library, and it does not offer social sharing, publishing, or distribution of results beyond the creator obtaining their own output.

Removed from scope

• Deepfakes of real people (also: deepfake generation of real people, non-consensual face replacement)
• Face swapping onto media the user does not own (also: third-party footage, stock face libraries)

2a. Product Interpretation and Delivery Boundary

Delivery is a first-party web application with custom UI and an application-owned backend. Identity is application-owned: a creator enrolls once through Sign Up and later verifies through Login to reach their own uploaded media, swap results, live sessions, and credit balance. Landing, Sign Up, and Login are anonymously reachable; New Swap, Swap Result, Live Studio, and Credits require the creator to be signed in.

The face-swap processing itself is owned by the application's backend service. There is no provider-owned or external product surface in the current scope; the payment gateway is an external system actor that the application calls to process credit purchases, and it exposes no studio surface of its own. All current behavior is delivered now; no future-horizon capabilities are committed in this document.

The hard constraint — face-swap effects on the user's own uploaded media, never deepfakes of real people — is a current, binding boundary that shapes the language, the consent band, and the framing of every upload control and every live camera control.

Runnable services (docker-compose inventory): a frontend React application, a shared backend FastAPI process that owns all application APIs and domain modules (identity, media upload, swap jobs, result delivery, live swap sessions, credits and payment-gateway integration), a database (MariaDB) for application-owned persistent data, a litellm gateway used by the backend for model-provider calls, and a postgres instance that supports LiteLLM and is separate from application-owned storage. New feature APIs are added as routes and modules inside the existing shared backend rather than as new containers; real-time swap sessions use the same backend process with a streaming transport, and credit purchases are handled by the same backend calling the external payment gateway.

2b. Source Content Inventory

Not applicable — no reference directive declares a content_source.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Explains the realistic face-swap video product, who it is for (creators working with their own footage), and what it does. Presents the "your own media only" consent rule as a visible HUD strip.
• Primary actions: Begin enrollment (to Sign Up); go to Sign In (to Login); preview the two upload drop zones ("Your video", "Face source") as an invitation that routes an unauthenticated visitor to Sign Up or Login before any protected work.
• Supporting actions: Navigate to the "How it works" scan sequence (01 Source video → 02 Face source → 03 Swap result); read the consent/trust band; read the real-time live swap and credit-purchase explanation, which routes an unauthenticated visitor to Sign Up or Login before any protected work.
• Domain entities: None persisted; presents product explanation and the consent rule.
• Component responsibilities: Hero volumetric face-mesh scene with HUD overlay; oversized headline block with primary CTA pill; glass upload panel with two labelled drop zones and a monospace status readout; scan-sequence section; result-viewer section; real-time live swap section with a credit-cost note; consent HUD strip.
• States: Loading (hero scene initializing); empty (no media yet — status reads "READY · 0 frames"); success (visitor proceeds to Sign Up or Login); error (hero scene fails to initialize — static lit frame fallback with all content visible); recovery (reduced-motion static arrangement; retry scene load).

Login

• Information/state: Anonymous returning-verification surface. Collects the creator's credentials to reach their own uploaded media and swap results.
• Primary actions: Submit credentials to sign in.
• Supporting actions: Navigate to Sign Up if the visitor has no account; return to Landing.
• Domain entities: Creator identity (email/identifier and credential).
• Component responsibilities: Credential form; submit control; inline validation; link to Sign Up.
• States: Loading (submitting); empty (blank form); success (redirect to New Swap); error (invalid credentials — inline message, form retained); recovery (retry submission; navigate to Sign Up).

Sign Up

• Information/state: Anonymous self-service first-use enrollment for a creator who independently begins using the product.
• Primary actions: Create an account with the creator's identifying details and credential.
• Supporting actions: Navigate to Login if already enrolled; return to Landing.
• Domain entities: Creator identity (identifier, credential).
• Component responsibilities: Enrollment form; submit control; inline validation; link to Login.
• States: Loading (submitting); empty (blank form); success (account created, creator signed in and routed to New Swap); error (identifier already in use or invalid input — inline message, form retained); recovery (correct input and resubmit; navigate to Login).

Live Studio

• Information/state: Protected working surface for a signed-in host. Holds the host's own live camera feed, the real-time swap state, the guest track option, and the credit balance available for real-time swaps.
• Primary actions: Start the real-time face swap on the host's own live camera feed; stop the live session; enable or disable the guest track option for a guest who joins the stream.
• Supporting actions: Choose the face source used for the live swap; view the monospace status readout (live frames, confidence, session duration); view the remaining credit balance; navigate to Credits to buy more credits when the balance is insufficient.
• Domain entities: Live swap session (host camera feed, face source, guest track state, status, frame count, confidence readout, credit consumption); credit balance.
• Component responsibilities: Live camera preview with the swap applied; start/stop session control; guest track toggle; face source selector; status readout; credit balance indicator with a link to Credits; consent reminder that the live feed and any guest feed must be the host's own or consented media.
• States: Loading (camera permission requested, session initializing); empty (no live session — preview idle, start disabled until a face source is chosen and credits are available); success (live swap running on the host feed, guest track on or off as chosen); error (camera permission denied or device unavailable — inline message with retry; insufficient credits — message with a link to Credits; session failure — error state with retry); recovery (grant permission and retry, buy credits, restart the session, or return to New Swap for an uploaded-media swap).

Credits

• Information/state: Protected surface for a signed-in user to buy credits through the payment gateway and see the balance available for real-time swaps.
• Primary actions: Choose a credit purchase and complete payment through the payment gateway.
• Supporting actions: View the current credit balance and purchase history; return to Live Studio to run a real-time swap; return to New Swap.
• Domain entities: Credit balance; credit purchase (selected amount, price, payment status, timestamp); payment transaction reference.
• Component responsibilities: Credit balance readout in monospace; credit purchase options; checkout control that hands off to the payment gateway; payment status and receipt confirmation; purchase history list; link to Live Studio.
• States: Loading (purchase options and balance loading; payment processing); empty (no purchases yet — balance shown, options available); success (payment confirmed, credits added to the balance, receipt shown); error (payment declined or gateway unavailable — inline message, no credits added, retry offered); recovery (retry payment, choose a different amount, or return to Live Studio once credits are available).

New Swap

• Information/state: Protected working surface for a signed-in creator. Holds the creator's own source video and face source image and the swap's processing state.
• Primary actions: Upload the source video; upload the face source image; start the realistic face swap.
• Supporting actions: Replace or remove either upload before starting; view the monospace status readout (frames, confidence) as processing proceeds.
• Domain entities: Swap job (source video, face source, status, frame count, confidence readout, resulting output).
• Component responsibilities: Two labelled drop zones ("Your video", "Face source"); start-swap control; status readout; consent reminder that media must be the creator's own.
• States: Loading (uploads in progress); empty (no media uploaded — start disabled); success (both uploads present, swap started, status advancing); error (unsupported or failed upload — inline message, drop zone reset; processing failure — error state with retry); recovery (re-upload, retry the swap, or return to New Swap from a failed result).

Swap Result

• Information/state: Protected surface for a signed-in creator to review the resulting swapped video and obtain the output.
• Primary actions: Play/review the swapped video; download the output.
• Supporting actions: Return to New Swap to start another swap; view the status/confidence readout for the completed swap.
• Domain entities: Swap job result (output video, frame count, confidence readout).
• Component responsibilities: Framed result viewer tagged "your media"; download control; status readout; link back to New Swap.
• States: Loading (result rendering); empty (no result available — prompt to start a swap); success (result plays and downloads); error (result unavailable or failed — message with retry/return to New Swap); recovery (retry processing or start a new swap).

3. Functional Requirements

FR-1 — Realistic face-swap video from own media (explicit) As a Face-swap video creator, I should be able to produce a realistic face swap on video from my own uploaded media, so that I get a convincing swapped-face video.

• Trigger/input: a signed-in creator supplies their own source video and a face source image and starts a swap.
• Observable result: a realistic swapped-face video is produced and available for review.
• Access state: requires sign-in.
• Failure/recovery: processing failure surfaces an error with retry; the creator can re-upload and restart.
• Continuation: the creator proceeds to review and obtain the result on Swap Result.

FR-2 — Own-media-only framing (explicit) As a Face-swap video creator, I should see the product framed as face-swap effects on my own uploaded photos/video rather than deepfakes of real people, so that I understand the consent-aware boundary.

• Trigger/input: any visit to Landing, New Swap, or Swap Result.
• Observable result: the "your own media only" rule is visible in the interface language and consent band.
• Access state: applies on all surfaces.
• Failure/recovery: not applicable (presentation constraint).
• Continuation: the creator proceeds with their own media.

FR-3 — Self-service enrollment (required_inference) As a Face-swap video creator, I should be able to create an account on my own, so that I can begin using the studio.

• Trigger/input: an anonymous visitor submits identifying details and a credential on Sign Up.
• Observable result: an account is created and the creator is signed in.
• Access state: anonymous entry.
• Failure/recovery: invalid or duplicate identifier shows an inline error and retains the form; the visitor can correct and resubmit or go to Login.
• Continuation: the creator is routed to New Swap.

FR-4 — Returning verification (required_inference) As a Face-swap video creator, I should be able to sign in to reach my own uploaded media and swap results, so that I can resume my work.

• Trigger/input: a returning creator submits credentials on Login.
• Observable result: the creator is signed in and can reach their own media and results.
• Access state: anonymous entry; protected destinations become available after sign-in.
• Failure/recovery: invalid credentials show an inline error and retain the form; the creator can retry or go to Sign Up.
• Continuation: the creator is routed to New Swap.

FR-5 — Upload own source video and face image (required_inference) As a Face-swap video creator, I should be able to upload my own source video and a face source image before processing, so that the swap has the media it needs.

• Trigger/input: a signed-in creator drops or selects a source video and a face source image on New Swap.
• Observable result: both uploads are present and the start-swap control becomes available.
• Access state: requires sign-in.
• Failure/recovery: unsupported or failed uploads show an inline error and reset the affected drop zone; the creator can re-upload.
• Continuation: the creator starts the swap.

FR-6 — Review and obtain the swapped video (required_inference) As a Face-swap video creator, I should be able to review the resulting swapped video and download it, so that I can use the output.

• Trigger/input: a completed swap is opened on Swap Result.
• Observable result: the swapped video plays in a framed viewer tagged "your media" and can be downloaded.
• Access state: requires sign-in.
• Failure/recovery: an unavailable or failed result shows a message with retry or a return to New Swap.
• Continuation: the creator downloads the output or starts another swap.

FR-7 — Real-time live video swap hosted on the web (explicit) As a Live swap host, I should be able to run a real-time face swap on my own live camera feed and host it on the web, so that viewers see the swap applied live.

• Trigger/input: a signed-in host opens Live Studio, chooses a face source, and starts a live session on their own camera feed.
• Observable result: the host's live camera feed is streamed with the realistic face swap applied in real time, and the monospace status readout advances (live frames, confidence, session duration).
• Access state: requires sign-in.
• Failure/recovery: camera permission denied or device unavailable shows an inline message with retry; a session failure shows an error state with retry; the host can restart the session or return to New Swap for an uploaded-media swap.
• Continuation: the host stops the session, or enables the guest track option for a guest who joins the stream.

FR-8 — Host-controlled guest track option (explicit) As a Live swap host, I should be able to control whether a guest who joins my live stream is also swapped, so that the live session stays under my control.

• Trigger/input: the host toggles the guest track option in Live Studio while a live session is running.
• Observable result: when enabled, the guest who joins the stream is swapped via the guest track; when disabled, the guest track is not swapped.
• Access state: requires sign-in; the option is available only to the host of the session.
• Failure/recovery: if the guest track cannot start, an inline message appears and the host feed continues unaffected; the host can retry or leave the option disabled.
• Continuation: the host continues or ends the live session.

FR-9 — Buy credits through the payment gateway (explicit) As a Credit buyer, I should be able to buy credits through the payment gateway, so that I can run real-time swaps.

• Trigger/input: a signed-in user opens Credits, chooses a credit purchase, and completes payment through the payment gateway.
• Observable result: the payment is confirmed, credits are added to the account balance, and the balance is shown in the studio.
• Access state: requires sign-in.
• Failure/recovery: a declined payment or an unavailable gateway shows an inline message, no credits are added, and the user can retry or choose a different amount.
• Continuation: the user returns to Live Studio with credits available for real-time swaps.

FR-10 — Credits required before running real-time swaps (required_inference) As a Live swap host, I should be able to see my credit balance and be told when it is insufficient, so that I know why a real-time swap cannot start.

• Trigger/input: the host opens Live Studio or attempts to start a live session.
• Observable result: the remaining credit balance is visible; when the balance is insufficient, the start control is unavailable and a message links to Credits.
• Access state: requires sign-in.
• Failure/recovery: an insufficient balance shows an inline message with a link to Credits; after a successful purchase the host can start the session.
• Continuation: the host starts the live session or buys credits first.

4. User Personas

Face-swap video creator

• Product context: A creator (editor, motion designer, or content maker) who wants a realistic face swap on footage they own. They work in a self-service studio and expect a serious visual-effects instrument, not a consumer toy.
• Primary goal: Produce a convincing swapped-face video from their own uploaded video and face source, and obtain the output.
• Distinct accepted responsibilities: Enrolls or signs in; uploads their own source video and face source image; starts the realistic face swap; reviews the resulting swapped video; downloads the output.
• Relevant inputs/decisions: Which source video and which face source to use; whether the result is convincing enough to keep; whether to start another swap.
• Interactions with other participants: Interacts with the application's face-swap processing service (system actor) that executes the swap; no other human participants.
• Observable success: A convincing swapped-face video produced from their own uploaded media, available to review and download.
• Constraints carried from source: Must use their own media; the product is not for deepfakes of real people.

Live swap host

• Product context: A creator who hosts a real-time face swap on the web, swapping onto their own live camera feed. They work inside the same self-service studio and expect the live session to feel like a controlled broadcast bay.
• Primary goal: Run a live hosted stream with the realistic swap applied to their own camera feed and, when they choose, to a guest who joins the stream.
• Distinct accepted responsibilities: Signs in; opens Live Studio; chooses a face source; starts and stops the live session on their own camera feed; enables or disables the guest track option; watches the live status readout; keeps enough credits for real-time swaps.
• Relevant inputs/decisions: Which face source to use live; whether to enable the guest track; whether the live result is good enough to keep streaming; whether to buy more credits.
• Interactions with other participants: Interacts with the application's face-swap processing service (system actor) that executes the real-time swap, and with the payment gateway (external system actor) when buying credits; no other human participants.
• Observable success: A live hosted stream with the swap applied to the host's own feed and, when enabled, the guest track.
• Constraints carried from source: Must use their own media and their own live camera feed; the product is not for deepfakes of real people.

Credit buyer

• Product context: A signed-in creator who purchases credits through the payment gateway so they can run real-time swaps.
• Primary goal: Buy credits and see the balance available for real-time swap use.
• Distinct accepted responsibilities: Signs in; opens Credits; chooses a credit purchase; completes payment through the payment gateway; confirms the credits were added; returns to Live Studio.
• Relevant inputs/decisions: Which credit amount to buy; whether the payment succeeded; whether more credits are needed.
• Interactions with other participants: Interacts with the payment gateway (external system actor) that processes the purchase; no other human participants.
• Observable success: Credits added to their account and usable for real-time swapping.
• Constraints carried from source: Credits are for real-time swaps on the user's own media; the product is not for deepfakes of real people.

5. Core User Flows

Flow A — First-time creator enrolls and produces a swap

1. The creator arrives anonymously on Landing, reads what the product does and the "your own media only" consent band, and chooses the primary CTA.
2. The creator is routed to Sign Up and submits identifying details and a credential.
3. On success, the creator is signed in and routed to New Swap. (On invalid or duplicate input, an inline error appears and the form is retained; the creator corrects and resubmits or goes to Login.)
4. On New Swap, the creator uploads their own source video into the "Your video" drop zone and a face source image into the "Face source" drop zone.
5. Both uploads are present; the start-swap control becomes available. The creator starts the realistic face swap.
6. The face-swap processing service executes the swap; the monospace status readout advances (frames, confidence).
7. On completion, the creator is taken to Swap Result, where the swapped video plays in a framed viewer tagged "your media".
8. The creator downloads the output. Continuation: the creator returns to New Swap to start another swap.

Flow B — Returning creator resumes and produces a swap

1. The creator arrives on Landing and chooses Sign In.
2. On Login, the creator submits credentials. (On invalid credentials, an inline error appears and the form is retained; the creator retries or goes to Sign Up.)
3. On success, the creator is routed to New Swap and uploads their own source video and face source image.
4. The creator starts the swap; the processing service executes it and the status readout advances.
5. On completion, the creator reviews the swapped video on Swap Result and downloads the output.

Flow C — Upload or processing failure and recovery

1. On New Swap, an upload fails or is unsupported; an inline error appears and the affected drop zone resets.
2. The creator re-uploads the media and starts the swap again.
3. If processing fails, an error state appears with a retry option; the creator retries or returns to New Swap to re-upload.
4. On success, the creator proceeds to Swap Result to review and download.

Flow D — Host runs a real-time live swap on the web

1. The signed-in host opens Live Studio and sees the credit balance and the live status readout.
2. If the balance is insufficient, the start control is unavailable and a message links to Credits; the host buys credits (Flow E) and returns.
3. The host chooses a face source and starts the live session on their own camera feed. (On denied camera permission or an unavailable device, an inline message appears with retry.)
4. The face-swap processing service applies the realistic swap to the live feed in real time; the status readout advances (live frames, confidence, session duration).
5. The host optionally enables the guest track option; a guest who joins the stream is then swapped via the guest track. The host can disable it at any time.
6. The host stops the session, or returns to New Swap for an uploaded-media swap.

Flow E — Credit buyer purchases credits for real-time swaps

1. The signed-in user opens Credits and sees the current balance and purchase options.
2. The user chooses a credit purchase and completes payment through the payment gateway.
3. On success, the payment is confirmed, credits are added to the balance, and a receipt is shown.
4. On a declined payment or an unavailable gateway, an inline message appears, no credits are added, and the user can retry or choose a different amount.
5. The user returns to Live Studio with credits available for real-time swaps.

6. Visuals Colors and Theme

Muse: Gleb Kuznetsov. Headline direction: "Cinematic future tech — a dark, volumetric studio for realistic face-swap on your own footage."

Mode: Dark only.

Colour tokens (exact hex by role):

No blue-indigo as a brand colour; teal and magenta are the only hot hues.

Typography:

• Headings: Space Grotesk — wide geometric techno sans; uppercase for micro-labels and section eyebrows at +0.14em tracking; headlines in mixed case at 400–500 weight, -0.02em tracking.
• Body: Space Grotesk.
• Data/values: JetBrains Mono for timestamps, frame counts, confidence readouts (13px tabular).
• Scale (1.333 modular): hero clamp(44px, 8vw, 120px); section heads 40/32/24; body 16/17 with 1.55 line-height; micro-labels 12px uppercase tracked.

Shape language: Full-bleed dark canvas with floating glass panels; 1px luminous strokes; 20–28px panel corners; pill micro-controls; thin radial HUD rings and progress arcs around the upload/scan subject. Sharp-edged full-bleed imagery underneath, soft glass on top. No drop-shadow cards, no rounded-blob decorations.

Layout: Max content width 1320px; 24px gutters on mobile, 64px on desktop. Every section opens on a thin teal rule with an uppercase eyebrow label.

Imagery: Abstract volumetric 3D — a luminous low-poly/gaussian face mesh solving from wireframe to solid, particle fields, glassy data panels, thin luminous strokes, radial HUD rings. No stock people, no clip art, no gradient blobs. Any real footage shown is clearly the user's own upload in a framed viewer with a "your media" tag.

Avoid: White/near-white ground; blue-indigo primary on white; gradient-blob heroes; grids of identical hover-lift cards with drop shadows; stock photos of smiling people or generic "AI robot" clip art; centred headline + subtext + single button SaaS hero; Inter/Roboto/Arial/system-ui/Poppins for headings or body; playful bouncy easing or cartoon illustration; any hint that the tool swaps faces onto real people the user does not own.

Readability: Headlines, wordmarks, labels, numbers, cards' text and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (e.g. clamp(...) with its mobile size) to fit; no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled, rotated, overlapped, or cut as the direction asks, provided they cover no readable text or control. With prefers-reduced-motion, provide a usable static arrangement.

7. Signature Design Concept

The live solve. The public entry (Landing) is a full-bleed dark scene (#070A12) where a single glowing face-mesh volume floats slightly right of centre — half-wireframe and half-solid to signal "realistic swap solving" — lit teal with a magenta rim. A thin teal scan line sweeps it on a slow 6s loop. Bottom-left, an oversized Space Grotesk headline (clamp(44px → 120px)) stacks over the dark ground with the primary CTA pill (teal fill, ink text) pinned beneath it. Bottom-right, a glass upload panel with two labelled drop zones ("Your video", "Face source") and a monospace status line "READY · 0 frames". The top bar is a single hairline row: wordmark, "Studio", "How it works", "Sign in" — no centred-nav SaaS look. The whole first screen reads as a sci-fi editing bay, not a marketing page.

Below the hero, a radial/diagonal section flow: a 3-up "how it works" arranged as a scan sequence (01 Source video → 02 Face source → 03 Swap result) with connecting luminous lines and a travelling teal dot, each step a glass tile with a mono index label; then a full-width dark result-viewer section; then a compact consent-aware "your own media only" band rendered as a HUD strip with an uppercase micro-label, a magenta REC dot, and a one-line plain-language rule.

The concept only recomposes accepted content, states, and controls — it introduces no new behavior, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: A single glowing face-mesh volume floating slightly right of centre in a near-black void, half-wireframe and half-solid, lit teal with a magenta rim.
• Input → transformation → outcome thesis: As the visitor scrolls and hovers, the camera drifts and the face-mesh volume orbits slowly while a teal scan line sweeps it on a 6s loop; the wireframe resolves toward solid, and the monospace status readout counts up frames and confidence — showing the "realistic swap solving" as a live render queue, using only accepted product behavior.
• Motion vocabulary: One continuous slow parallax/orbit of the hero volumetric subject; a teal scan line sweeping the face volume on a 6s loop; scroll-linked camera drift (CSS 3D / layered parallax); a count-up on frame/confidence readouts; hover on panels lifts glass 2px with a light-sweep highlight.
• Composed first frame: Full-bleed #070A12 ground; face-mesh volume right of centre; oversized bottom-left headline with teal CTA pill beneath; bottom-right glass upload panel with two drop zones and "READY · 0 frames"; hairline top bar with wordmark, "Studio", "How it works", "Sign in".
• Reduced-motion state: Freeze the orbit and scan line to a static lit frame; keep all content visible and stacked; no scroll-linked transforms.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

A crafted real-time WebGL/R3F scene showing the product's defining state: a luminous low-poly/gaussian face mesh that is half-wireframe and half-solid, floating in a near-black void, lit teal with a magenta rim, with a thin teal scan line sweeping it on a slow loop and a subtle particle field. The scene communicates "realistic swap solving" — the product's core promise — without depicting any real person. It must degrade gracefully to a static lit frame under prefers-reduced-motion and on devices without WebGL.

9. Non-Functional Requirements

• Own-media-only constraint (explicit): The product must not be built as a tool for making deepfakes of real people; scope is face-swap effects on the user's own uploaded media. Rationale: explicit hard constraint in the authoritative source.
• Consent-aware framing (explicit): The interface must always frame media as the user's own, including a visible "your own media only" rule. Rationale: explicit hard constraint.
• Durable state (required_inference): The application must persist creator identity, uploaded media, swap results, live session records, and credit balances and purchase records so a returning creator can reach their own media, results, and credits. Rationale: accepted journeys require resumable, creator-owned state.
• AI processing (required_inference): The backend must perform realistic face-swap processing on uploaded video and face source, and on the host's live camera feed for real-time swaps. Rationale: the core accepted capabilities require it.
• Real-time live swap (explicit): The backend must support a real-time face swap on the host's own live camera feed, hosted on the web, with a host-controlled guest track option. Rationale: explicit user requirement.
• Payment gateway (explicit): The backend must integrate a payment gateway so a signed-in user can buy credits, and must record the resulting balance and purchase history. Rationale: explicit user requirement.
• Credits gate real-time swaps (required_inference): A real-time swap must not start without sufficient credits, and the balance must be visible in Live Studio. Rationale: accepted journey requires it.
• Readable text and controls (explicit): Readable text and controls must stay whole and inside the viewport and their container at 375px, 768px, and 1280px. Rationale: explicit design constraint.
• Reduced motion (explicit): Provide a usable static arrangement under prefers-reduced-motion. Rationale: explicit design constraint.
• No forbidden template look (explicit): The generic indigo/blue-on-white SaaS template is forbidden. Rationale: explicit design constraint.

10. Tech Stack

• Frontend: React (custom UI, dark cinematic studio).
• Frontend: React (custom UI, dark cinematic studio).
• Backend: Python / FastAPI, extended with routes and modules for identity, media upload, swap jobs, result delivery, live swap sessions (streaming transport), and credits with payment-gateway integration. All feature APIs live in this one shared backend process.
• Storage: Durable storage for creator identity, uploaded media, swap results, live session records, credit balances, and purchase records — MariaDB, application-owned.
• Processing: Application-owned face-swap processing service integrated into the backend (AI processing required), covering both uploaded-media swaps and real-time live swaps.
• Model provider access: LiteLLM gateway used by the backend for model-provider calls; its supporting PostgreSQL instance is separate from application-owned storage.
• Payments: External payment gateway called by the backend to process credit purchases; the application owns the credit balance and purchase records.
• Deployment: Docker / docker-compose for the runnable services (frontend, backend, database, litellm, postgres).

11. Assumptions and Constraints

• Assumption: The creator has their own source video and a face source image available to upload. (required_inference)
• Assumption: Application-owned identity is used for self-service enrollment and returning verification, as established by the Planning Scope. (required_inference)
• Constraint: The product is not for deepfakes of real people; only the user's own media is in scope. (explicit)
• Constraint: Landing, Sign Up, and Login are anonymously reachable; New Swap, Swap Result, Live Studio, and Credits require sign-in. (required_inference)
• Constraint: No stock or third-party face library, and no social sharing or distribution beyond the creator obtaining their own output. (explicit)
• Constraint: Real-time live swap is hosted on the web with the host swapping their own live camera feed, with a host-controlled guest track option. (explicit)
• Assumption: The payment gateway is an external provider configured with the application's merchant credentials; the application records the resulting credit balance and purchase history. (required_inference)

12. Glossary

• Face swap: The process of replacing the face in a source video with a face from a face source image, producing a realistic swapped-face video.
• Source video: The creator's own video footage into which the face is swapped.
• Face source: The creator's own face image used as the replacement face.
• Swap job: A single processing run combining a source video and a face source into a swapped-face output.
• Swap result: The completed swapped-face video produced by a swap job, available for review and download.
• Creator: The single active human persona, the Face-swap video creator.
• Own media: Media the creator owns and has the right to use; the only media the product operates on.
• Consent band: The visible "your own media only" HUD strip that states the own-media rule.
• Live swap session: A real-time processing run in which the host's own live camera feed is streamed with the face swap applied, optionally including a guest track.
• Guest track: The host-controlled option that applies the swap to a guest who joins the live stream.
• Credit: A unit of balance purchased through the payment gateway and consumed to run real-time swaps.
• Payment gateway: The external system actor that processes credit purchases on behalf of the application.