System Requirements Document for connecta-dating

1. Introduction

Connecta is an 18+ global dating service whose tagline is "Meet beyond borders." and whose promise to its users is "Meet people. Build connections." The product exists so that adults anywhere in the world can discover compatible people across country and language boundaries, express interest, be matched when interest is mutual, and then hold a private conversation — while a safety layer (verification, reporting, blocking, automated fraud detection, human moderation, and a strict no-exact-location rule) is present from the very first release rather than bolted on later.

The audience is mobile-first adults aged 18 and over who are often nervous about being on a dating app at all. They need a first impression that feels like something fun might happen, and a visible, brand-integrated safety layer that makes them feel in control of who sees them and who can reach them. A second audience — moderators and administrators — needs a separate, denser working surface to review reports, act on fraudulent or spam behaviour, manage users, and run the admin-only live stream.

This document specifies the first version of Connecta, which is deliberately limited to eleven features: Register, Create Profile, Discover, Like, Match, Chat, live stream (admin only), video post, Report/Block, Notifications, and the admin dashboard.

2. System Overview

Connecta is delivered as a Flutter application for Android and iPhone, backed by Firebase for accounts, database, notifications and chat, with Cloud Storage for profile photos, AI moderation to help detect spam and fraudulent content, and an admin dashboard for managing reports and users. The dating experience is free at its core; Connecta Premium is the paid tier.

Two active human roles use the product:

• Dating App User — an adult (18+) who registers, builds a profile, discovers and reacts to other profiles, matches, chats, publishes video posts, and manages their own safety and preferences.
• Moderator / Admin — the operator who reviews reports and safety signals, acts on reported content and accounts, manages users, and runs the admin-only live stream.

The current release covers exactly the eleven features listed above. Everything else described in the concept material — the wider Premium catalogue beyond the listed benefits, the full matching-signal set, and the broader safety tooling — is specified here only to the extent it is part of the current commitment, and any item not in the eleven-feature list is treated as a future horizon rather than current scope.

2a. Product Interpretation and Delivery Boundary

Connecta owns its own identity. A dating user creates their own account on the Sign up surface, verifies a phone number or email address, and then owns a durable profile, a durable set of likes and matches, and a durable conversation history that must remain bound to the correct person across sessions and devices. Because a match is a mutual commitment between two specific people and a conversation is private to exactly those two people, the application must be able to prove that the returning visitor is the same person who made those likes and sent those messages. Returning verification therefore happens on the Log in surface, and the protected dating surfaces — Create Profile, Discover, It's a Match!, Messages, Notifications, Video Posts, Profile — are reachable only after identity is established. The Welcome, Sign up and Log in surfaces are reachable anonymously, because a person cannot be asked to log in to the surface that creates their login.

Moderators and administrators do not self-enroll. Their access to the Moderation dashboard, the Admin dashboard and the Live Stream surface is provisioned and role-assigned by the service before they can reach those surfaces; the Log in surface is the shared returning-verification entry point for both roles, and the role attached to the account determines which working surfaces open.

The safety layer is part of the product surface, not a hidden back office. Verification state, moderation state and premium state are rendered as visible status marks on the surfaces where they matter. Exact location is never displayed anywhere in the product — users may express country/city and location preferences, but no precise position is ever shown to another user.

Live streaming is admin only. Dating App Users do not broadcast. Video posts are published content within the current feature set.

2b. Source Content Inventory

Not applicable — no reference directive in this project declares a content_source.

2c. Page Content and Component Coverage

Welcome

• Information and state: Full-bleed hot pink field. Connecta wordmark as a cream slab, top-left. The headline "MEET BEYOND BORDERS" stacked flush-left across four lines. The promise line "Meet people. Build connections." A rotated lime capsule badge reading "VERIFIED · 18+". A bottom marquee strip reading "MEET PEOPLE. BUILD CONNECTIONS. · 18+ · VERIFIED PROFILES · NO EXACT LOCATIONS ·". No authenticated state is required to view this page.
• Primary actions: "Create profile" pill (tangerine) leading to Sign up; "Log in" outlined cream pill leading to Log in.
• Supporting actions: None beyond the two entry points.
• Domain entities: None owned; the page presents brand identity and the two access entry points.
• Component responsibilities: Wordmark block; oversized headline block occupying columns 1–9; hard-cut portrait bleeding off the right edge and overlapping columns 6–9; rotated verification badge overlapping the seam between headline and portrait; bottom action row; bottom marquee strip.
• States: Loading — not applicable, the page is static. Empty — not applicable. Success — the page renders with both entry points available. Error — if the app cannot reach the service, the entry points remain visible and a non-blocking notice states that sign-up and log-in are temporarily unavailable. Recovery — the notice clears and the entry points become active again once connectivity returns.

Sign up

• Information and state: Anonymous enrollment surface. Collects the credentials needed to establish a Connecta account and the phone number or email address used for verification. States the 18+ requirement before submission.
• Primary actions: Submit registration; complete phone/email verification.
• Supporting actions: Return to Welcome; move to Log in if the visitor already has an account.
• Domain entities: Account (identity), verification challenge (phone or email), 18+ attestation.
• Component responsibilities: Registration form; 18+ attestation control; verification-code entry; resend-verification control; error messaging region.
• States: Loading — submission in progress, controls disabled. Empty — the form is presented blank on first arrival. Success — the account is created and verified, and the user is taken to Create Profile. Error — invalid or already-used credentials, failed verification code, or an unconfirmed 18+ attestation each produce a specific inline message and keep the user on the page with their entered data intact. Recovery — the user can request a new verification code, correct the offending field, or leave for Log in; no partial account is left in a usable but unverified state.

Log in

• Information and state: Anonymous returning-verification surface shared by Dating App Users and Moderator / Admin accounts. Collects credentials and, where required, a verification challenge.
• Primary actions: Submit credentials; complete the verification challenge.
• Supporting actions: Return to Welcome; move to Sign up if the visitor has no account; initiate credential recovery.
• Domain entities: Account (identity), session, role assignment (dating user vs. moderator/admin).
• Component responsibilities: Credential form; verification challenge entry; recovery entry point; error messaging region.
• States: Loading — verification in progress, controls disabled. Empty — the form is presented blank on first arrival. Success — the session is established and the user is routed to the surface their role owns: a Dating App User to Discover (or Create Profile if their profile is incomplete), a Moderator / Admin to the Moderation dashboard. Error — wrong credentials or a failed challenge produce a specific message without revealing whether the account exists. Recovery — credential recovery is offered; repeated failures are rate-limited and the user can retry or return to Welcome.

Create Profile

• Information and state: Protected surface, reachable by a verified Dating App User. Captures profile photos, name, age, gender, country/city, bio, interests, what you're looking for, and languages. Shows the profile's current completeness and the verification state of the account.
• Primary actions: Upload and order profile photos; enter and save each profile field; submit the profile for use in Discover.
• Supporting actions: Edit any previously saved field; add or remove interests and languages; set what you're looking for; start optional selfie verification; leave to Discover once the profile is usable.
• Domain entities: Profile (photos, name, age, gender, country/city, bio, interests, looking-for, languages), verification state, photo assets in Cloud Storage.
• Component responsibilities: Photo upload and ordering control; field editors for each profile attribute; interest and language selectors; looking-for selector; completeness indicator; verification status sticker; save and submit controls.
• States: Loading — existing profile data is being fetched, fields render as skeletons. Empty — a first-time user sees an empty form with guidance on the required fields. Success — the profile saves and the user is told the profile is live and discoverable. Error — a failed photo upload, an invalid age (under 18), or a save failure each produce a specific message; the user's other entered fields are preserved. Recovery — retry the failed upload or save; the user may continue editing and resubmit; an under-18 age blocks submission and explains the 18+ requirement.

Discover

• Information and state: Protected surface for a verified Dating App User with a usable profile. Presents one large profile card at a time, filling the viewport between the top bar and the action rail. The card carries the candidate's photos, name, age, country/city (never exact location), bio, interests, languages, and the compatibility ring showing the percentage with the shared-interest sentence beneath it. A Worldwide toggle and a Filters control sit in the top bar.
• Primary actions: Like; Pass; Super Like.
• Supporting actions: Open Filters; toggle Worldwide discovery on or off; open the candidate's full profile detail; open the compatibility explanation.
• Domain entities: Candidate profile, compatibility score and shared-interest explanation, like/pass/super-like decision record, filter set, worldwide preference.
• Component responsibilities: Full-bleed card stack; compatibility ring rendered as a poster numeral with the shared-interest sentence; action rail of three large pills pinned in a bottom band on a contrasting colour field so controls never sit over the photo; top bar with Filters and Worldwide toggle; decision-coloured wipe on the outgoing card.
• States: Loading — the next card is being fetched, the deck shows a placeholder card. Empty — no candidates match the current filters: an oversized single prop on a colour field explains the situation and offers to widen filters or turn on Worldwide. Success — a decision is recorded and the next card animates in; a mutual like routes to It's a Match!. Error — a failed decision submission or a failed candidate fetch shows a specific message and offers retry without losing the current card. Recovery — retry the fetch or the decision; the user can adjust filters or the Worldwide toggle to change the candidate pool.

It's a Match!

• Information and state: Protected surface shown when two users like each other. Displays both profile pictures, the message "You both liked each other", and the compatibility context for the pair.
• Primary actions: Start Chat.
• Supporting actions: Dismiss and return to Discover; open either profile.
• Domain entities: Match (the mutual-like record binding two accounts), the two profile pictures.
• Component responsibilities: Full-viewport typographic headline "IT'S A MATCH!"; the two profile photos scaling in with a hard three-frame stagger; a single 2D lime confetti burst that fires once and clears; the Start Chat button; the "You both liked each other" line.
• States: Loading — the match record and both photos are being resolved. Empty — not applicable; the surface only exists when a match exists. Success — both photos and the headline render and Start Chat opens the conversation. Error — if the match record cannot be resolved, the user is returned to Discover with a specific message and the match remains available from Messages. Recovery — the match is reachable again from the Messages matches list.

Messages

• Information and state: Protected surface for a verified Dating App User. Two-pane split at 1280px (matches list 360px, conversation fluid) and a single-pane push at 375/768px. The matches list shows every mutual match; the conversation pane shows the private thread between exactly two matched users, including text, photos, voice messages, and translation of received messages. Block and report controls are available inside the conversation.
• Primary actions: Send a text message; send a photo; record and send a voice message; translate a received message; block the other participant; report the other participant.
• Supporting actions: Open a match from the list; return to the matches list; open the other participant's profile; play a received voice message; view a received photo.
• Domain entities: Match, conversation, message (text, photo, voice), translation result, block record, report record.
• Component responsibilities: Matches list; conversation thread; composer with text, photo and voice controls; translation control on received messages; voice-message waveform chip; block and report affordances; safety tips entry point before meeting someone.
• States: Loading — the matches list and the selected conversation are being fetched. Empty — no matches yet: an oversized single prop on a colour field explains that matches will appear here once both people like each other. Success — a message is delivered and appears in the thread; a translation renders beneath the original; a block or report is confirmed. Error — a failed send, upload, recording or translation shows a specific message and keeps the composed content so it can be retried. Recovery — retry the failed action; a blocked participant can no longer send messages into the thread, and a reported participant's content is queued for moderation review.

Profile

• Information and state: Protected surface for a verified Dating App User, composed of stacked colour-block sections with a sticky in-section nav. Sections cover edit profile, verification, dating preferences, privacy, notifications, Premium, and help & safety. Shows current verification state, current premium state, and current notification and privacy settings.
• Primary actions: Edit profile fields and photos; start or complete verification; set dating preferences; change privacy settings; change notification settings; view and manage Premium; open help & safety.
• Supporting actions: Move between sections via the sticky nav; start optional selfie verification; read safety tips before meeting someone; reach the report and block affordances.
• Domain entities: Profile, verification state (phone/email verified, optional selfie verified), dating preferences, privacy settings, notification settings, premium entitlement, safety content.
• Component responsibilities: Sticky in-section nav; edit-profile section; verification section with status stickers; dating-preferences section; privacy section; notifications section; Premium section; help & safety section with safety tips.
• States: Loading — the profile and settings are being fetched. Empty — a section with no configured value shows its default and an invitation to set it. Success — a change saves and the section reflects the new value immediately. Error — a failed save or a failed verification attempt shows a specific message and preserves the previous value. Recovery — retry the save or verification; the user can leave and return without losing previously saved settings.

Notifications

• Information and state: Protected surface for a verified Dating App User. Lists match notifications and message notifications, each with enough context to identify the match or conversation and a route back into it.
• Primary actions: Open a notification to continue the underlying journey.
• Supporting actions: Mark notifications as read; clear the list.
• Domain entities: Notification (match notification, message notification), read state.
• Component responsibilities: Notification list; per-item context and timestamp; route into It's a Match! or Messages.
• States: Loading — notifications are being fetched. Empty — no notifications: an oversized single prop on a colour field explains that match and message activity will appear here. Success — opening a notification routes to the correct destination and marks it read. Error — a failed fetch shows a specific message and offers retry. Recovery — retry the fetch; the underlying match or conversation remains reachable from Messages regardless.

Video Posts

• Information and state: Surface for publishing video-post content. A verified Dating App User publishes a video post; a Moderator / Admin can view published video posts as part of moderation and administration. Shows the publisher's own posts and their moderation state.
• Primary actions: Publish a video post; view a published video post.
• Supporting actions: Remove one's own video post; open the publisher's profile.
• Domain entities: Video post (media asset, publisher, publication time, moderation state).
• Component responsibilities: Video capture or upload control; post list; moderation-state sticker (lime for clear, near-black for under review); playback control.
• States: Loading — the post list and media are being fetched. Empty — no posts yet: an oversized single prop on a colour field invites the user to publish their first video post. Success — the post publishes and appears in the list with its moderation state. Error — a failed upload or a rejected post shows a specific message and preserves the user's draft where possible. Recovery — retry the upload; a post placed under review remains visible to its publisher with its state shown.

Moderation dashboard

• Information and state: Protected surface for a Moderator / Admin, rendered on a near-black ground with cream text and lime status chips so it reads as a different room from the dating product. Shows the queue of reports, the safety signals raised by fake-profile detection and scam/spam detection, and the current state of each item.
• Primary actions: Review a report; act on reported content or an account; resolve or escalate a safety signal.
• Supporting actions: Filter and sort the queue; open the reported profile, message, video post or conversation in context; record a moderation decision.
• Domain entities: Report, safety signal (fake-profile detection, scam/spam detection), moderation decision, affected account, affected content.
• Component responsibilities: Dense three-column grid; report queue; signal queue; detail pane with the reported content in context; decision controls; lime status chips.
• States: Loading — the queues are being fetched. Empty — no open reports or signals: the dashboard states that the queue is clear. Success — a decision is recorded and the item leaves the open queue with its outcome stored. Error — a failed fetch or a failed decision shows a specific message and keeps the item in the queue. Recovery — retry the fetch or the decision; the item is never silently dropped from the queue.

Admin dashboard

• Information and state: Protected surface for a Moderator / Admin, on the same near-black administrative ground. Manages users and administration tasks for the service, including account state and role assignment for administrative access.
• Primary actions: Search for and open a user account; change an account's state; assign or remove administrative roles; review administrative activity.
• Supporting actions: Move between the Admin dashboard and the Moderation dashboard; open the Live Stream surface.
• Domain entities: Account, account state, role assignment, administrative action record.
• Component responsibilities: Dense three-column grid; user search and list; account detail pane; state and role controls; lime status chips.
• States: Loading — the user list is being fetched. Empty — no accounts match the current search. Success — a change is applied and reflected in the account detail. Error — a failed fetch or a failed change shows a specific message and preserves the previous state. Recovery — retry the fetch or the change; the account is never left in an indeterminate state.

Live Stream

• Information and state: Protected surface for a Moderator / Admin only. Dating App Users cannot reach or start a live stream. Shows the current stream state and the controls for running the admin-only live stream.
• Primary actions: Start a live stream; stop a live stream.
• Supporting actions: Monitor the stream's state while it runs.
• Domain entities: Live stream session (state, operator, start and stop times).
• Component responsibilities: Stream state indicator; start and stop controls; operator identity display.
• States: Loading — the stream state is being resolved. Empty — no stream is running: the surface offers to start one. Success — the stream starts or stops and the state indicator reflects it. Error — a failed start or stop shows a specific message and leaves the previous state intact. Recovery — retry the start or stop; the operator can leave and return to the surface without an orphaned session.

3. Functional Requirements

FR-1 — 18+ service and brand promise (explicit) As a visitor, I should see that Connecta is an 18+ dating service presented under the tagline "Meet beyond borders." and the promise "Meet people. Build connections.", so that I understand what the product is and who it is for before I commit to it.

• Lifecycle: triggered on arrival at Welcome; observable result is the wordmark, tagline, promise and the 18+ mark rendered together; no failure path beyond the page failing to load, in which case the entry points remain visible with a notice; continuation is either Sign up or Log in.

FR-2 — Welcome entry points (explicit) As a visitor, I should see the Connecta logo, the tagline, and both a Sign up and a Log in entry point on the Welcome screen, so that I can choose the path that matches whether I already have an account.

• Lifecycle: triggered on arrival; observable result is two distinct, reachable entry points; failure is a service-unreachable notice that leaves both entry points visible; continuation is Sign up or Log in.

FR-3 — Registration (explicit) As a Dating App User, I should be able to register for Connecta, so that I can create a profile and take part in the dating experience.

• Lifecycle: initiated on Sign up; input is the registration credentials and an 18+ attestation; observable result is a created account; material failure is invalid or already-used credentials or an unconfirmed 18+ attestation, each reported specifically with entered data preserved; recovery is correcting the field or moving to Log in; continuation is phone/email verification and then Create Profile.

FR-4 — Phone/email verification at registration (explicit) As a Dating App User, I should verify a phone number or email address as part of registering, so that the service knows a real, reachable person is behind the account.

• Lifecycle: initiated on Sign up after credential submission; input is the verification challenge response; observable result is a verified account; material failure is an incorrect or expired code, reported specifically; recovery is requesting a new code and retrying; continuation is Create Profile. No unverified account reaches protected dating surfaces.

FR-5 — Log in (explicit) As a Dating App User or a Moderator / Admin, I should be able to log in to Connecta, so that I can return to my durable profile, matches, conversations and administrative work.

• Lifecycle: initiated on Log in; input is credentials and, where required, a verification challenge; observable result is an established session routed by role — a Dating App User to Discover (or Create Profile if incomplete), a Moderator / Admin to the Moderation dashboard; material failure is wrong credentials or a failed challenge, reported without revealing whether the account exists; recovery is credential recovery or retry; continuation is the role's home surface.

FR-6 — Create Profile (explicit) As a Dating App User, I should create my profile with profile photos, name, age, gender, country/city, bio, interests, what I'm looking for, and languages, so that other people can understand who I am and whether we might fit.

• Lifecycle: initiated on Create Profile after verification; input is each listed field and one or more photos; observable result is a saved, discoverable profile; material failure is a failed photo upload, an age below 18, or a failed save, each reported specifically with other fields preserved; recovery is retrying the failed upload or save; continuation is Discover.

FR-7 — Edit profile (explicit) As a Dating App User, I should edit my profile from the Profile surface, so that my photos, bio, interests, languages and looking-for statement stay accurate as things change.

• Lifecycle: initiated from the Profile surface's edit section; input is the changed fields; observable result is the updated profile reflected immediately; material failure is a failed save, reported specifically with the previous value preserved; recovery is retry; continuation is returning to the section or to Discover.

FR-8 — Discover profile card (explicit) As a Dating App User, I should see a large profile card for one candidate at a time in Discover, so that I can consider a person properly rather than skim.

• Lifecycle: initiated on Discover; input is the candidate pool; observable result is a full-bleed card showing the candidate's photos, name, age, country/city, bio, interests and languages; material failure is a failed candidate fetch, reported specifically with the current card retained; recovery is retry; continuation is a Like, Pass or Super Like decision.

FR-9 — Like, Pass and Super Like (explicit) As a Dating App User, I should be able to Like, Pass or Super Like the profile in front of me, so that I can express interest or move on.

• Lifecycle: initiated on Discover; input is the chosen action; observable result is a recorded decision and the next card; material failure is a failed decision submission, reported specifically without losing the current card; recovery is retry; continuation is the next card, or It's a Match! when the Like is mutual.

FR-10 — Filters (explicit) As a Dating App User, I should be able to apply Filters in Discover, so that the people I see match what I am looking for.

• Lifecycle: initiated from the Discover top bar; input is the filter set; observable result is a changed candidate pool; material failure is a failed filter application, reported specifically; recovery is retry or resetting the filters; continuation is browsing the filtered pool.

FR-11 — Worldwide toggle (explicit) As a Dating App User, I should be able to toggle Worldwide discovery in Discover, so that I can choose between people near my stated location preference and people anywhere in the world.

• Lifecycle: initiated from the Discover top bar; input is the toggle state; observable result is a visibly changed candidate pool and a visibly changed toggle state; material failure is a failed toggle, reported specifically; recovery is retry; continuation is browsing the changed pool.

FR-12 — Compatibility calculation and display (explicit) As a Dating App User, I should see a compatibility percentage with a shared-interest explanation on a candidate's card, calculated from shared interests, age preferences, relationship goals, languages, location preferences, lifestyle preferences, and answers to compatibility questions, so that I can judge fit before deciding.

• Lifecycle: initiated when a candidate card is presented; input is the candidate's and my own matching signals; observable result is a percentage rendered as a poster numeral with the shared-interest sentence beneath it (for example "Compatibility: 87%" with "You both enjoy football, movies and traveling."); material failure is an unavailable score, in which case the card still presents and the score area states it is unavailable; recovery is the score appearing once the signals resolve; continuation is the Like, Pass or Super Like decision.

FR-13 — It's a Match! (explicit) As a Dating App User, I should see an "It's a Match!" screen when two users like each other, showing both profile pictures and the message "You both liked each other", so that the mutual moment is unmistakable.

• Lifecycle: initiated when the second of two mutual Likes is recorded; input is the mutual-like record; observable result is the match screen with both profile pictures and the "You both liked each other" line; material failure is an unresolvable match record, in which case the user returns to Discover with a specific message and the match remains reachable from Messages; recovery is opening the match from the Messages matches list; continuation is Start Chat.

FR-14 — Start Chat from a match (explicit) As a Dating App User, I should be able to press Start Chat on the match screen, so that I can begin the conversation immediately.

• Lifecycle: initiated on It's a Match!; input is the Start Chat action; observable result is the private conversation opened in Messages; material failure is a failed conversation open, reported specifically; recovery is opening the match from the Messages matches list; continuation is sending a message.

FR-15 — Matches list (explicit) As a Dating App User, I should see a matches list in Messages, so that I can find and reopen any conversation I have.

• Lifecycle: initiated on Messages; input is my match records; observable result is a list of every mutual match; material failure is a failed list fetch, reported specifically; recovery is retry; continuation is opening a conversation.

FR-16 — Private conversations (explicit) As a Dating App User, I should hold private conversations with my matches in Messages, so that what I say is visible only to the two people in the match.

• Lifecycle: initiated from the matches list or from Start Chat; input is my composed message; observable result is the message delivered into the thread between exactly those two participants; material failure is a failed send, reported specifically with the composed content preserved; recovery is retry; continuation is the ongoing conversation.

FR-17 — Photos in chat (explicit) As a Dating App User, I should send and view photos inside a conversation, so that I can share more than text with a match.

• Lifecycle: initiated in the conversation composer; input is the selected photo; observable result is the photo delivered into the thread and viewable by the other participant; material failure is a failed upload, reported specifically with the composed content preserved; recovery is retry; continuation is the ongoing conversation.

FR-18 — Voice messages in chat (explicit) As a Dating App User, I should record and send voice messages inside a conversation and play the ones I receive, so that I can communicate when typing is not the right mode.

• Lifecycle: initiated in the conversation composer; input is the recorded audio; observable result is the voice message delivered into the thread and playable by the other participant; material failure is a failed recording or upload, reported specifically; recovery is retry; continuation is the ongoing conversation.

FR-19 — Translation in chat (explicit) As a Dating App User, I should translate a received message in a conversation, so that a language difference does not end a connection.

• Lifecycle: initiated on a received message; input is the translate action; observable result is the translated text rendered with the original; material failure is a failed translation, reported specifically with the original message intact; recovery is retry; continuation is replying in the conversation.

FR-20 — Block and report in chat (explicit) As a Dating App User, I should be able to block and report the other participant from inside a conversation, so that I can stop unwanted contact and flag bad behaviour.

• Lifecycle: initiated from the conversation's block or report affordance; input is the chosen action and, for a report, the reason; observable result is a confirmed block that stops further messages from that participant, or a confirmed report queued for moderation review; material failure is a failed block or report, reported specifically; recovery is retry; continuation is returning to the matches list, with the blocked participant no longer able to send into the thread.

FR-21 — Report button (explicit) As a Dating App User, I should have a report button available where I encounter other people's content, so that I can flag behaviour that breaks the rules.

• Lifecycle: initiated from the report affordance on a profile, a conversation, or a video post; input is the report reason; observable result is a recorded report routed to the Moderation dashboard; material failure is a failed report submission, reported specifically; recovery is retry; continuation is returning to what I was doing.

FR-22 — Block button (explicit) As a Dating App User, I should have a block button available where I encounter other people, so that I can remove someone from my experience immediately.

• Lifecycle: initiated from the block affordance; input is the block action; observable result is a confirmed block that removes the participant from my matches and stops their contact; material failure is a failed block, reported specifically; recovery is retry; continuation is returning to the matches list or Discover.

FR-23 — No display of exact location (explicit) As a Dating App User, I should never have my exact location displayed to another user, so that being on Connecta does not expose where I physically am.

• Lifecycle: applies to every surface that presents a person — Discover cards, profile detail, matches list, conversations, video posts and the match screen; observable result is that only country/city and location preferences are ever shown, and no precise position, map pin or location dot appears anywhere; there is no failure path because the constraint is enforced at presentation; continuation is unaffected.

FR-24 — Optional selfie verification (explicit) As a Dating App User, I should be able to complete an optional selfie verification, so that I can show others I am a real person without being required to.

• Lifecycle: initiated from the Profile surface's verification section; input is the selfie capture; observable result is a verified status mark rendered as a lime capsule sticker on my profile; material failure is a failed or rejected selfie check, reported specifically; recovery is retrying the selfie; continuation is returning to the Profile surface with the verification state shown. Declining leaves the account fully usable.

FR-25 — Fake-profile detection (explicit) As the service, I should run fake-profile detection so that fraudulent accounts are identified for moderation.

• Lifecycle: runs continuously against account and profile signals; observable result is a safety signal raised into the Moderation dashboard; material failure is a detection error, which leaves the account untouched and the signal unraised; recovery is the next detection pass; continuation is moderator review. No Dating App User interacts with this capability directly.

FR-26 — Scam/spam detection (explicit) As the service, I should run scam and spam detection so that fraudulent and spammy content is identified for moderation.

• Lifecycle: runs continuously against messages, profiles and video posts; observable result is a safety signal raised into the Moderation dashboard; material failure is a detection error, which leaves the content untouched and the signal unraised; recovery is the next detection pass; continuation is moderator review. No Dating App User interacts with this capability directly.

FR-27 — AI moderation assistance (explicit) As the service, I should use AI moderation to help detect spam and fraudulent content, so that the moderation queue is prioritised toward the content that most needs a human decision.

• Lifecycle: runs as part of the detection pipeline; observable result is flagged content surfaced in the Moderation dashboard with its signal; material failure is an AI moderation error, which leaves content un-flagged rather than auto-removed; recovery is the next pass; continuation is moderator review. AI moderation assists; it does not replace the moderator's decision.

FR-28 — Safety tips before meeting someone (explicit) As a Dating App User, I should be able to read safety tips before meeting someone, so that I know how to meet a match safely.

• Lifecycle: initiated from the Profile surface's help & safety section and from the conversation's safety entry point; input is opening the tips; observable result is the safety guidance presented; material failure is a failed load, reported specifically; recovery is retry; continuation is returning to the conversation or the Profile surface.

FR-29 — Moderation dashboard (explicit) As a Moderator / Admin, I should work from a moderation dashboard that shows reports and safety signals, so that I can review and act on them in one place.

• Lifecycle: initiated on the Moderation dashboard after role-verified login; input is the report and signal queues; observable result is a reviewed item with a recorded decision; material failure is a failed fetch or a failed decision, reported specifically with the item retained in the queue; recovery is retry; continuation is the next item in the queue.

FR-30 — Act on reported content and accounts (explicit) As a Moderator / Admin, I should be able to act on reported content or an account from the moderation dashboard, so that fraudulent accounts and rule-breaking content are removed from the service.

• Lifecycle: initiated from a report or signal in the Moderation dashboard; input is the moderation decision; observable result is the decision applied to the content or account and the item leaving the open queue with its outcome stored; material failure is a failed decision, reported specifically with the item retained; recovery is retry; continuation is the next queue item.

FR-31 — Admin dashboard user management (explicit) As a Moderator / Admin, I should manage users from the admin dashboard, so that accounts and administrative access stay correct.

• Lifecycle: initiated on the Admin dashboard after role-verified login; input is the account search and the chosen change; observable result is the account state or role assignment updated and reflected in the account detail; material failure is a failed fetch or change, reported specifically with the previous state preserved; recovery is retry; continuation is the next account or the Moderation dashboard.

FR-32 — Moderator / Admin provisioning (required_inference) As a Moderator / Admin, I should have my administrative access provisioned and role-assigned by the service before I can reach the moderation, administration and live-stream surfaces, so that administrative control is never self-granted.

• Lifecycle: initiated by the service before first administrative use; input is the role assignment; observable result is that the Log in surface routes the account to the Moderation dashboard and opens the administrative surfaces; material failure is an unassigned or revoked role, in which case the administrative surfaces are not reachable; recovery is the role being assigned or restored; continuation is the administrative work.

FR-33 — Live stream, admin only (explicit) As a Moderator / Admin, I should be able to run a live stream from the Live Stream surface, so that the service can broadcast live to its users under administrative control.

• Lifecycle: initiated on the Live Stream surface by a role-verified Moderator / Admin; input is the start action; observable result is a running stream with its state shown; material failure is a failed start or stop, reported specifically with the previous state intact; recovery is retry; continuation is monitoring the stream and stopping it. Dating App Users cannot start or reach this capability.

FR-34 — Video post (explicit) As a Dating App User, I should publish a video post, so that I can express myself beyond my profile photos.

• Lifecycle: initiated on Video Posts; input is the recorded or uploaded video; observable result is the published post appearing in the list with its moderation state; material failure is a failed upload or a rejected post, reported specifically with the draft preserved where possible; recovery is retry; continuation is viewing the published post or publishing another.

FR-35 — Notifications (explicit) As a Dating App User, I should receive notifications for matches and messages, so that I know when something has happened and can continue the journey.

• Lifecycle: initiated by a match or a new message; input is the underlying event; observable result is a notification listed on the Notifications surface with enough context to identify the match or conversation; material failure is a failed notification delivery, in which case the underlying match or message remains reachable from Messages; recovery is opening Messages directly; continuation is opening the notification into It's a Match! or the conversation.

FR-36 — Open a notification (required_inference) As a Dating App User, I should open a notification and be taken to the match or conversation it refers to, so that I can act on it rather than just read it.

• Lifecycle: initiated on the Notifications surface; input is the selected notification; observable result is the correct destination opened and the notification marked read; material failure is a failed route, reported specifically; recovery is opening the match or conversation from Messages; continuation is the underlying journey.

FR-37 — Free basic app (explicit) As a Dating App User, I should be able to use the basic app for free, so that registering, creating a profile, discovering, liking, matching, chatting, reporting, blocking and receiving notifications do not require payment.

• Lifecycle: applies to the whole basic experience; observable result is that no basic capability is gated behind payment; there is no failure path; continuation is unaffected.

FR-38 — Connecta Premium (explicit) As a Dating App User, I should be able to view and manage Connecta Premium from the Profile surface, so that I can decide whether the paid tier is worth it for me.

• Lifecycle: initiated from the Profile surface's Premium section; input is the Premium action; observable result is the Premium state shown and the entitlement reflected on the surfaces it affects; material failure is a failed Premium action, reported specifically with the previous state preserved; recovery is retry; continuation is returning to the Profile surface or to Discover.

FR-39 — Premium benefits (explicit) As a Premium Dating App User, I should receive the Premium benefits — see who liked you, unlimited likes, Super Likes, Profile Boost, advanced filters, worldwide discovery, and incognito mode — so that paying changes my experience in the ways promised.

• Lifecycle: initiated when the entitlement is active; observable result is each listed benefit available to me and visibly marked as premium where it appears; material failure is an entitlement that fails to apply, reported specifically; recovery is retry or re-checking the entitlement; continuation is using the benefit. Non-premium users retain the free basic experience unchanged.

FR-40 — Verification status visibility (explicit) As a Dating App User, I should see verification state rendered as a visible status mark on the profiles I encounter and on my own profile, so that verification is part of the brand rather than buried in settings.

• Lifecycle: initiated wherever a profile is presented; observable result is a lime capsule verification sticker overlapping the card it annotates; material failure is an unavailable verification state, in which case no mark is shown rather than a false one; recovery is the state resolving; continuation is unaffected.

FR-41 — Moderation state visibility (explicit) As a Dating App User, I should see the moderation state of my own video posts, so that I understand whether my content is live or under review.

• Lifecycle: initiated on Video Posts; observable result is a near-black "under review" sticker or a lime clear sticker on the post; material failure is an unavailable state, in which case the post shows no state mark rather than a false one; recovery is the state resolving; continuation is viewing or publishing posts.

4. User Personas

Dating App User

Product context. An adult aged 18 or over who is looking to meet people beyond their own borders. They are mobile-first, they are frequently new to dating apps, and they are often a little nervous about being on one at all. They may be navigating a language difference with the people they want to meet, and they care about not being findable at their exact location.

Primary goal. To form and sustain real connections with compatible people across countries and languages, while staying in control of who can see them and who can reach them.

Distinct accepted responsibilities. This persona carries the entire dating lifecycle and it is genuinely theirs, not shared with the operator: they register and verify a phone number or email address; they build a profile with photos, name, age, gender, country/city, bio, interests, what they're looking for, and languages; they browse Discover one large card at a time; they Like, Pass or Super Like; they read the compatibility percentage and its shared-interest explanation before deciding; they experience the mutual-like moment; they start and hold private conversations with text, photos and voice messages, translating what they receive; they publish video posts; they read safety tips before meeting someone; they block and report; they manage their own verification, dating preferences, privacy, notification settings and Premium; and they act on their notifications.

Relevant inputs and decisions. Their own profile content and photos; their filter set and Worldwide toggle; each Like, Pass and Super Like; whether to start a chat from a match; whether to translate a message; whether to send a photo or a voice message; whether to block or report; whether to complete optional selfie verification; whether to take Premium; whether to publish a video post.

Interactions with other accepted participants. Every meaningful outcome of this persona's work involves another Dating App User: a Like only becomes a match when the other person also likes back, and a conversation only exists between two matched people. The other participant's response is the thing that turns this persona's action into an outcome. This persona also interacts with the Moderator / Admin indirectly — their reports and blocks become moderation queue items, and their content can be acted on by a moderator.

Observable success. A match appears with both profile pictures and the "You both liked each other" line; a conversation exists and messages arrive; a translation renders; a block stops unwanted contact; a report is confirmed; a video post publishes with its state shown; a notification opens into the right place. Throughout all of it, no exact location is ever shown.

Moderator / Admin

Product context. The operator of the service, working from a near-black administrative ground that is deliberately a different room from the dating product. They do not date on the platform; they keep it safe and keep it running. Their access is provisioned and role-assigned by the service rather than self-created.

Primary goal. To keep Connecta a safe 18+ dating service by resolving reports, acting on fake-profile and scam/spam signals, managing users, and running the admin-only live stream.

Distinct accepted responsibilities. Reviewing the report queue and the safety signals raised by fake-profile detection and scam/spam detection; acting on reported content or accounts; recording moderation decisions; managing users and administrative role assignments from the admin dashboard; and starting, monitoring and stopping the admin-only live stream. They also view published video posts as part of moderation.

Relevant inputs and decisions. The report reason and the reported content in context; the safety signal and its evidence; the AI moderation flag attached to content; the decision to act on content or an account; account state and role changes; whether to start or stop a live stream.

Interactions with other accepted participants. This persona acts on the Dating App User's reports, blocks, content and accounts. Their decisions change what a Dating App User can see or do — a removed account stops appearing in Discover, a removed post stops being visible, a blocked participant stops being able to send messages. Their work is downstream of the dating user's actions and upstream of the dating user's experience.

Observable success. A report is reviewed and a decision recorded; a fraudulent account is removed; a signal leaves the open queue with its outcome stored; an account's state or role is corrected; a live stream starts and stops cleanly. The queue is never silently emptied.

5. Core User Flows

Flow 1 — A new Dating App User registers, verifies and creates a profile

1. The visitor arrives at Welcome and sees the Connecta wordmark, the headline "MEET BEYOND BORDERS", the promise "Meet people. Build connections.", the rotated "VERIFIED · 18+" badge, and the bottom marquee strip.
2. The visitor presses the tangerine "Create profile" pill and lands on Sign up.
3. On Sign up, the visitor enters their registration credentials and confirms the 18+ attestation. If they confirm they are under 18, submission is blocked and the 18+ requirement is explained.
4. The visitor submits and completes the phone/email verification challenge. If the code is wrong or expired, a specific message appears and they can request a new code; their entered data is preserved.
5. On success, the account is created and verified, and the user is taken to Create Profile.
6. On Create Profile, the user uploads profile photos and enters name, age, gender, country/city, bio, interests, what they're looking for, and languages. A failed photo upload or save is reported specifically and the other entered fields are preserved so they can retry.
7. The user saves and submits. The profile becomes live and discoverable, and the user continues to Discover.

Flow 2 — A returning Dating App User logs in

1. The user arrives at Welcome and presses the outlined cream "Log in" pill.
2. On Log in, the user enters their credentials and completes the verification challenge if one is required.
3. If the credentials are wrong or the challenge fails, a specific message appears that does not reveal whether the account exists; the user can retry or start credential recovery.
4. On success, the session is established. Because this account is a Dating App User, they are routed to Discover — or to Create Profile if their profile is still incomplete.
5. The user continues with the dating experience.

Flow 3 — A Dating App User discovers people and makes a decision

1. The user opens Discover. The top bar shows the Filters control and the Worldwide toggle; the viewport is filled by one large profile card.
2. The card shows the candidate's photos, name, age, country/city (never an exact location), bio, interests and languages, with the compatibility ring rendered as a poster numeral and the shared-interest sentence beneath it — for example "Compatibility: 87%" with "You both enjoy football, movies and traveling."
3. If the user wants a different pool, they open Filters and apply a filter set, or they toggle Worldwide on or off. The candidate pool visibly changes and the toggle's state visibly changes.
4. The user presses ❤️ Like, \xe2\x9d\x8c Pass or ⭐ Super Like in the bottom action rail. The outgoing card leaves with a flat colour-block wipe whose colour encodes the decision — pink for pass, tangerine for like, lime for super like — and the corresponding action pill fills with the same colour in the same frame.
5. The decision is recorded and the next card animates in. If the decision submission fails, a specific message appears and the current card is retained so the user can retry.
6. If the user exhausts the pool, an oversized single prop on a colour field explains the situation and offers to widen filters or turn on Worldwide.
7. The user continues browsing, or a mutual Like routes them to It's a Match!.

Flow 4 — Two Dating App Users match

1. Dating App User A likes Dating App User B's profile in Discover.
2. Dating App User B, in their own Discover session, likes Dating App User A's profile. This is the second of the two mutual Likes.
3. The match record is created and It's a Match! opens for the user who completed the mutual like. The full-viewport headline "IT'S A MATCH!" reveals word by word; the two profile pictures scale in with a hard three-frame stagger; a single 2D lime confetti burst fires once and clears; the line "You both liked each other" is shown.
4. The user presses Start Chat and the private conversation opens in Messages.
5. If the match record cannot be resolved, the user is returned to Discover with a specific message, and the match remains reachable from the Messages matches list.
6. The other participant sees the same match in their own matches list and can open the same conversation from there.

Flow 5 — A Dating App User holds a conversation with a match

1. The user opens Messages. At 1280px they see the two-pane split — matches list at 360px and the conversation fluid; at 375/768px they see a single pane and push into the conversation.
2. The user opens a match from the matches list. If they have no matches yet, an oversized single prop on a colour field explains that matches will appear here once both people like each other.
3. In the conversation, the user sends a text message. It appears in the thread. A failed send is reported specifically and the composed content is preserved for retry.
4. The user sends a photo from the composer. It is delivered into the thread and viewable by the other participant. A failed upload is reported specifically and the composed content is preserved.
5. The user records and sends a voice message. It is delivered into the thread and playable by the other participant. A failed recording or upload is reported specifically.
6. The user receives a message in another language and presses translate. The translated text renders with the original. A failed translation is reported specifically and the original message stays intact.
7. The other participant receives each of these and can reply, translate, send photos and send voice messages in the same way.

Flow 6 — A Dating App User blocks or reports someone

1. Inside a conversation in Messages, the user opens the block or report affordance.
2. For a report, the user selects a reason and submits. The report is recorded and routed to the Moderation dashboard. A failed submission is reported specifically and can be retried.
3. For a block, the user confirms. The block is applied: the participant is removed from the user's matches and can no longer send messages into the thread. A failed block is reported specifically and can be retried.
4. The user returns to the matches list. The blocked participant is no longer able to contact them.
5. The same report and block affordances are available wherever the user encounters other people's content — on a profile and on a video post — so the user can flag behaviour without first opening a conversation.

Flow 7 — A Dating App User completes optional selfie verification

1. The user opens Profile and moves to the verification section via the sticky in-section nav.
2. The section shows the current verification state — phone/email verified, and selfie verification not yet done.
3. The user starts the optional selfie verification and captures a selfie.
4. On success, a lime capsule verified sticker appears on the user's profile, overlapping the edge of the card it annotates.
5. If the selfie check fails or is rejected, a specific message appears and the user can retry.
6. If the user declines to do this at all, nothing changes and the account remains fully usable.

Flow 8 — A Dating App User manages preferences, privacy, notifications and Premium

1. The user opens Profile and uses the sticky in-section nav to move between the stacked colour-block sections.
2. In edit profile, the user changes photos, bio, interests, languages or their looking-for statement. The change saves and is reflected immediately; a failed save is reported specifically and the previous value is preserved.
3. In dating preferences, the user sets what they are looking for. In privacy, the user changes their privacy settings. In notifications, the user changes their notification settings.
4. In Premium, the user views their Premium state and manages it. A failed Premium action is reported specifically and the previous state is preserved.
5. In help & safety, the user reads the safety tips before meeting someone, and can reach the report and block affordances from here.
6. The user leaves the Profile surface and returns to Discover or Messages.

Flow 9 — A Dating App User publishes a video post

1. The user opens Video Posts. If they have no posts, an oversized single prop on a colour field invites them to publish their first one.
2. The user records or uploads a video and publishes it.
3. The post appears in the list with its moderation state shown as a sticker — lime for clear, near-black for under review.
4. If the upload fails, a specific message appears and the draft is preserved where possible so the user can retry. If the post is rejected, the reason is shown specifically.
5. The user can remove their own post, or open their own profile from here.

Flow 10 — A Dating App User acts on a notification

1. A match or a new message occurs, and a notification is created.
2. The user opens Notifications and sees the notification listed with enough context to identify the match or conversation. If there are none, an oversized single prop on a colour field explains that match and message activity will appear here.
3. The user opens the notification. The correct destination opens — It's a Match! for a match, the conversation in Messages for a message — and the notification is marked read.
4. If the route fails, a specific message appears and the user can reach the same match or conversation directly from Messages.
5. The user continues the underlying journey.

Flow 11 — A Moderator / Admin logs in and works the moderation queue

1. The Moderator / Admin arrives at Welcome and presses "Log in".
2. On Log in, they enter their credentials and complete the verification challenge. Their administrative access has already been provisioned and role-assigned by the service; they cannot self-grant it.
3. On success, because their role is Moderator / Admin, they are routed to the Moderation dashboard — a near-black ground with cream text and lime status chips, deliberately a different room from the dating product.
4. The dashboard shows the queue of reports and the safety signals raised by fake-profile detection and scam/spam detection, with AI moderation flags attached to the content that most needs a human decision.
5. The moderator opens a report and sees the reported profile, message, video post or conversation in context.
6. The moderator records a moderation decision and acts on the reported content or account. The item leaves the open queue with its outcome stored. A failed fetch or failed decision is reported specifically and the item stays in the queue.
7. If the queue is empty, the dashboard states that it is clear. The moderator moves to the next item, or to the Admin dashboard.

Flow 12 — A Moderator / Admin manages users

1. From the Admin dashboard, the Moderator / Admin searches for and opens a user account.
2. The account detail shows the account's current state and role assignment.
3. The moderator changes the account's state, or assigns or removes an administrative role.
4. The change is applied and reflected in the account detail. A failed fetch or change is reported specifically and the previous state is preserved, so the account is never left in an indeterminate state.
5. The moderator continues with the next account, or moves back to the Moderation dashboard.

Flow 13 — A Moderator / Admin runs the admin-only live stream

1. From the administrative surfaces, the Moderator / Admin opens Live Stream. Dating App Users cannot reach or start this surface.
2. The surface shows the current stream state. If no stream is running, it offers to start one.
3. The moderator starts the stream. The state indicator reflects the running stream and the operator identity is shown.
4. If the start fails, a specific message appears and the previous state is left intact so the moderator can retry.
5. The moderator monitors the stream, then stops it. The state indicator reflects the stop. If the stop fails, a specific message appears and the previous state is left intact.
6. The moderator can leave and return to the surface without leaving an orphaned session.

6. Visuals Colors and Theme

Muse and headline. Jessica Walsh — colour-saturated romantic maximalism. The headline idea is "Meet beyond borders" rendered as a poster: a full-bleed hot pink field, an oversized flush-left headline, and a hard-cut portrait bleeding off the right edge. Dating is a colour-saturated emotional product, not a utility; the first screen has to promise the jolt of a match, and the safety layer has to look like part of the brand rather than legal furniture.

Colour tokens — light mode

Colour tokens — administrative mode (inverted)

Proportion. 45% pink fields, 35% cream surfaces, 12% near-black type and rules, 6% tangerine, 2% lime.

Typography. Headings: Archivo Black at weight 400 (its only weight), set very large, tight leading 0.88–0.92, tracking −0.02em, sentence case for warmth but never lowercase; headlines may stack across 3–4 lines and break mid-phrase. Supporting headings and UI labels: Syne 700–800 in caps with +0.08em tracking. Body: Syne 400–500 at 16–18px with 1.55 line-height. Scale: 1.333 modular with a display tier — display clamp(44px, 9vw, 104px); h1 34 → 64px; h2 26 → 40px; h3 20 → 26px; body 16 → 18px; label 12 → 13px caps +0.08em; data/numerals 28 → 56px in Archivo Black for the compatibility percentage.

Shape language. Hard colour-block edges with soft bodies: sections are rectangles of flat saturated colour meeting at clean 0px seams, while every interactive object inside them is a capsule or superellipse. Buttons are full pills (radius 999px) with a 2px near-black outline and a hard 4px offset shadow in the same outline colour — no blur, no soft drop shadow. Cards use 28px radius; profile cards 36px. Sticker elements (compatibility badge, verified mark, voice-message waveform chip) are rotated −4° to +6° and overlap the edge of the panel they belong to. No glassmorphism, no gradient fills, no blurred blobs.

Spacing rhythm. A 12-column desktop grid with an asymmetric editorial composition: the hero headline occupies columns 1–9 and imagery occupies 6–12, deliberately overlapping. Mobile is single-column but keeps the asymmetry — headline flush left, one element always bleeding off the right edge. Discover is a full-bleed card stack filling the viewport between the top bar and the action rail, with the action rail as three large pills pinned in a bottom band on a contrasting colour field so controls are never over the photo. Messages uses a two-pane split at 1280px (matches list 360px, conversation fluid) and a single-pane push at 375/768px. Profile and Premium are stacked colour-block sections with a sticky in-section nav. Admin dashboard is a dense three-column grid with lime status chips.

Imagery style. Art-directed, staged, surreal portraiture — real people photographed against flat saturated colour backdrops, holding one unexpected prop (a globe, a passport, a paper plane, a stack of postcards) to make "beyond borders" literal without a single map pin or location dot. Cut-outs with hard edges, no soft vignettes. Supporting props are 3D-rendered candy objects (a glossy pink heart, a lime speech bubble, a tangerine paper plane) at sticker scale. No stock-photo couples on a beach, no gradient mesh, no laptop-on-a-desk. Empty states use oversized single props on colour fields rather than illustration kits. User profile photos are always presented inside the cream card frame with a 2px near-black outline so the art direction survives user content.

Readable text and controls. Headlines, wordmarks, labels, numbers, card text and controls stay entirely inside the viewport and their container at 375px, 768px and 1280px, wrapping or scaling 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 as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The Welcome screen is a full-bleed hot pink #FF4D8D field with no white anywhere. The wordmark "Connecta" sits top-left as a cream #FFF3E4 slab in Archivo Black at 28px. The dominant element is the headline "MEET BEYOND BORDERS" in Archivo Black at clamp(44px, 9vw, 104px), near-black #1A0B12, stacked across four flush-left lines occupying columns 1–9 and running from the top third to the bottom third of the viewport — it is the largest thing on screen and it is allowed to be. Overlapping columns 6–12 and bleeding off the right edge is a hard-cut photographic portrait on a tangerine #FF5A1F backdrop, cropped so the subject's shoulder exits the viewport. A lime #B8FF3C capsule badge reading "VERIFIED · 18+" is rotated −5° and overlaps the seam between the headline block and the photo. Bottom-left: a tangerine #FF5A1F pill button "Create profile" and a cream outlined pill "Log in", both with hard 4px near-black offset shadows. Along the bottom edge, a 40s marquee strip in cream caps runs "MEET PEOPLE. BUILD CONNECTIONS. · 18+ · VERIFIED PROFILES · NO EXACT LOCATIONS ·". Nothing is centred; nothing sits in a floating glass card; there is no gradient.

The same signature language carries into the product: the compatibility ring is a 2px near-black outlined circle with a lime arc containing the percentage in Archivo Black at clamp(28px, 6vw, 56px), rotated −4° and overlapping the profile card's bottom-left corner, with the shared-interest sentence set beneath it in Syne caps. Decision-coloured card swipes make the outgoing Discover card exit with a flat colour-block wipe whose colour encodes the action — pink for pass, tangerine for like, lime for super like — with the corresponding action pill filling with the same colour in the same frame. Match is a typographic event, not a modal: "IT'S A MATCH!" reveals word by word in Archivo Black at clamp(40px, 8vw, 92px) across the full viewport width, the two profile photos scale in with a hard three-frame stagger, and a single 2D lime confetti burst fires once and clears. Sticker status language runs across the whole product: verified, online, boosted, premium and moderation state are all rotated capsule stickers — lime for verified, tangerine for premium/boost, near-black for under review — overlapping the edge of the card they annotate, so safety and monetisation are visible brand furniture rather than buried settings.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject. The oversized flush-left headline "MEET BEYOND BORDERS" in Archivo Black, overlapped by the hard-cut portrait bleeding off the right edge, with the rotated lime "VERIFIED · 18+" badge sitting on the seam between them.
• Input → transformation → outcome thesis. On load, the headline reveals line by line as clip wipes rather than fades, the portrait settles into its overlap position, and the lime badge rotates into place on the seam — so the visitor's first frame resolves into the promise "Meet people. Build connections." with the 18+ and verification marks already present. The bottom marquee then begins its 40s loop. Nothing here is a new behaviour: the reveal simply stages the accepted Welcome content and its two entry points.
• Motion vocabulary. Line-by-line clip wipes for type; spring-driven card motion with real velocity and rotation (±12° max) in Discover; flat colour-block wipes for decisions; a hard three-frame stagger for the match photos; a single 2D lime confetti burst that fires once and clears; a 40s marquee loop. Expressive and confident, never bouncy-cute.
• Composed first frame. Full-bleed hot pink. Wordmark top-left in cream. Headline stacked across four flush-left lines occupying columns 1–9. Portrait overlapping columns 6–12 and exiting the right edge. Lime badge rotated −5° on the seam. Two pills bottom-left with hard 4px near-black offset shadows. Cream marquee strip along the bottom edge.
• Reduced-motion state. With prefers-reduced-motion, the headline appears whole with no clip wipe, the portrait and badge are static in their final positions, the marquee stops and wraps into static rows so every item is fully readable, Discover swipes become instant state changes, and the match burst is replaced by a single static lime badge.

9. Non-Functional Requirements

NFR-1 — 18+ only (explicit) Connecta is an 18+ dating service. Age is captured in Create Profile and an 18+ attestation is required at Sign up; an age below 18 blocks profile submission. Rationale: the source states this as a hard constraint and it is the precondition for the whole product.

NFR-2 — No exact location display (explicit) Exact location must never be displayed. Only country/city and location preferences are ever shown, and no map pin, location dot or precise position appears on any surface, including Discover cards, profile detail, matches list, conversations, video posts and the match screen. Rationale: explicit hard constraint and a core safety promise.

NFR-3 — Safety built in from the beginning (explicit) Verification, report, block, fake-profile detection, scam/spam detection, the moderation dashboard and safety tips must all be present in the first version, not deferred. Rationale: explicit hard constraint.

NFR-4 — Basic app remains free (explicit) The basic app must remain free; Connecta Premium is the paid tier. No basic capability — registering, creating a profile, discovering, liking, matching, chatting, reporting, blocking, notifications — may be gated behind payment. Rationale: explicit hard constraint.

NFR-5 — Selfie verification is optional (explicit) Selfie verification must be offered but never required. Declining leaves the account fully usable. Rationale: explicit hard constraint.

NFR-6 — Live streaming is admin only (explicit) Live streaming is restricted to Moderator / Admin. Dating App Users cannot start or reach it. Rationale: explicit hard constraint.

NFR-7 — First version limited to eleven features (explicit) The first version is limited to Register, Create Profile, Discover, Like, Match, Chat, live stream (admin only), video post, Report/Block, Notifications, and the admin dashboard. Rationale: explicit hard constraint; it bounds scope and prevents adjacent capability creep.

NFR-8 — Mobile delivery on both platforms (explicit) The app ships for Android and iPhone via Flutter. Rationale: explicit technology direction.

NFR-9 — Identity continuity for durable dating state (required_inference) Because likes, matches and conversations are durable and private to specific people, the application must maintain identity continuity so that returning users reach their own state and no one reaches another person's. Rationale: required to make the accepted match and chat journeys executable; without it a match cannot be bound to the correct two participants.

NFR-10 — Administrative access is provisioned, not self-granted (required_inference) Moderator / Admin access to the moderation, administration and live-stream surfaces must be provisioned and role-assigned by the service. Rationale: required to keep administrative control out of self-service enrollment while still making the accepted administrative journeys executable.

NFR-11 — Moderation decisions are recorded, not silent (required_inference) A moderation decision must leave the open queue with its outcome stored, and a failed fetch or decision must retain the item. Rationale: required so that acting on reported content and accounts produces a durable, observable result rather than an unrecorded action.

NFR-12 — Readable text and controls stay whole (explicit, from the creative direction) Headlines, wordmarks, labels, numbers, card 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. Moving and scrollable content may cross the viewport edge by design, judged by whether it actually moves and whether every item becomes fully readable as it passes; with reduced motion it stops and shows whole items. Rationale: explicit accessibility and legibility constraint.

NFR-13 — Reduced-motion support (explicit, from the creative direction) All motion respects prefers-reduced-motion: swipes become instant state changes, the marquee stops and wraps into static rows, and the match burst is replaced by a single static lime badge. Rationale: explicit constraint in the creative direction.

NFR-14 — No exact-location imagery (explicit, from the creative direction) No map pins, exact-location dots, or imagery implying precise location may appear anywhere in the product. Rationale: reinforces NFR-2 at the visual layer.

10. Tech Stack

• Flutter — the Android and iPhone application. (explicit)
• Firebase — accounts, database, notifications and chat. (explicit)
• Cloud Storage — profile photos. (explicit)
• AI moderation — helps detect spam and fraudulent content. (explicit)
• Admin dashboard — manages reports and users. (explicit)
• Containerization and orchestration — [Default — not specified by user] Docker and docker-compose for local and service packaging; Kubernetes only if deployment scale requires it. Not a product requirement.

11. Assumptions and Constraints

Assumptions

• A1 — The eleven-feature list is the complete current scope. Items described in the concept material that fall outside those eleven — such as the full Premium benefit catalogue beyond the listed benefits, and the full matching-signal set — are treated as current only where they are named in the eleven-feature list or in the explicit screen and safety specifications, and otherwise as future horizon. (narrow, labeled)
• A2 — Country/city is user-entered profile information and location preference is a user-set preference; neither is derived from device location, because exact location must never be displayed. (narrow, labeled)
• A3 — "Live stream-admin For admin only" is read as a single admin-only live-stream capability, and "video post" as a separate publishable-content capability. (narrow, labeled)
• A4 — Moderator and Admin are treated as one operational role for access purposes, since the source names them together as the operator of the moderation and admin dashboards. (narrow, labeled)
• A5 — Notification delivery uses Firebase notifications; the Notifications surface is the in-app record of match and message activity. (narrow, labeled)

Constraints

• C1 — 18+ dating service only. (explicit)
• C2 — Exact location must never be displayed. (explicit)
• C3 — First version is limited to the eleven listed features. (explicit)
• C4 — Live streaming is admin only. (explicit)
• C5 — Basic app must remain free; Premium is the paid tier. (explicit)
• C6 — Selfie verification is optional. (explicit)
• C7 — Safety features must be built in from the beginning. (explicit)
• C8 — The generic indigo/blue-on-white SaaS template is forbidden for this project; no blue, indigo or violet primary, and no white or near-white page grounds. (explicit, from the creative direction)

12. Glossary

• Connecta — the 18+ global dating service specified in this document, tagline "Meet beyond borders."
• Dating App User — an adult (18+) who registers, creates a profile, discovers and reacts to profiles, matches, chats, publishes video posts, and manages their own safety and preferences.
• Moderator / Admin — the provisioned operator who reviews reports and safety signals, acts on reported content and accounts, manages users, and runs the admin-only live stream.
• Match — the durable record created when two users like each other, binding exactly those two accounts and enabling a private conversation between them.
• Compatibility — the percentage shown on a Discover card, calculated from shared interests, age preferences, relationship goals, languages, location preferences, lifestyle preferences, and answers to compatibility questions, accompanied by a shared-interest explanation.
• Super Like — a distinct, stronger expression of interest available in Discover alongside Like and Pass.
• Worldwide toggle — the Discover control that switches between the user's stated location preference and people anywhere in the world.
• Connecta Premium — the paid tier offering see who liked you, unlimited likes, Super Likes, Profile Boost, advanced filters, worldwide discovery, and incognito mode.
• Profile Boost — a Premium benefit that raises a profile's visibility.
• Incognito mode — a Premium benefit that changes how a user's profile is exposed.
• Fake-profile detection — the automated safety capability that identifies fraudulent accounts for moderation.
• Scam/spam detection — the automated safety capability that identifies fraudulent and spammy content for moderation.
• AI moderation — the automated assistance that helps detect spam and fraudulent content and prioritises the moderation queue; it assists a human moderator's decision rather than replacing it.
• Moderation dashboard — the near-black administrative surface where reports and safety signals are reviewed and acted on.
• Admin dashboard — the near-black administrative surface where users and administrative roles are managed.
• Live Stream — the admin-only capability for running a live broadcast, restricted to Moderator / Admin.
• Video post — a published video content item created by a Dating App User and subject to moderation state.
• Safety tips — the guidance presented before meeting someone, reachable from the Profile surface's help & safety section and from a conversation.
• Sticker — the rotated capsule status mark used across the product for verified, online, boosted, premium and moderation state.