System Requirements Document for bronze-mammoth

1. Introduction

bronze-mammoth is a public website whose central act is the visitor's own face becoming the interface. Any person who arrives at the site is asked for camera access; once granted, the site scans and recognises their face, stores the recognised face data, and uses that data as an identity credential so the same person can be recognised again on return. The site also presents a handmade artificial intelligence called XRF that lives on Telegram as the bot @Rradonbot — XRF is not hosted on this site; the site introduces it and points visitors to it.

The audience is curious Persian-speaking web users, developers, and Telegram tinkerers: technical, playful, and comfortable with a browser doing something live and slightly uncanny. The product intent is intrigue and quiet awe at a machine recognising you — an instrument you interact with, not a form you fill in — while remaining honest and legible about camera consent and about what happens to the captured face data.

2. System Overview

bronze-mammoth is delivered as a first-party web application with a custom interface and application-owned identity. Its current behaviour is:

• A public Landing surface that introduces the site, the face-recognition flow, and the handmade AI XRF on Telegram (@Rradonbot).
• A Face Verification surface that handles first-use self-service enrolment by face and returning verification against stored face data.
• A Camera Access surface that manages the visitor's camera-permission step at the start of use.
• A Face Scan surface that receives and processes the camera image for face recognition after access is granted.
• A Face Capture surface that records and stores the recognised face data to continue the identity cycle.
• A Face Records surface that lets the visitor revisit and manage the face data stored in the system.

Actors are the anonymous site visitor (the active human who gives camera access, enrols, is recognised, and returns) and the Telegram user of the XRF bot (the active human who interacts with XRF inside Telegram). The Telegram bot @Rradonbot and the XRF AI are external, provider-owned, and out of this site's delivery boundary.

Narrow exclusions: XRF is handmade and lives on Telegram, not on this site; the site does not host, run, or reimplement XRF. The site does not add adjacent account-management capabilities beyond the face-based identity cycle the source requires.

2a. Product Interpretation and Delivery Boundary

The site owns the camera-consent interaction, the face scan, the storage of recognised face data, and the face-based identity cycle (first-use enrolment and returning verification). Identity is application-owned: a visitor's face data must remain bound to the correct person so that returning recognition is truthful, and the visitor must be able to revisit the face data stored about them.

The camera-permission step, the scan, the capture, and the verification are all first-party surfaces of this site. The Telegram bot @Rradonbot and the XRF AI are provider-owned and external: the site's responsibility ends at presenting XRF, its Telegram identity, and a link to it. Nothing about XRF's conversation, model, or hosting is delivered by this site.

Current horizon: camera request, face recognition, face-data storage, face-based identity (enrolment and returning verification), and the XRF/@Rradonbot presentation. No future-horizon items were stated by the user.

2b. Source Content Inventory

Not applicable — no reference directive declares content_source.

2c. Page Content and Component Coverage

Landing

• Information/state: Public entry surface. Presents the site's purpose (camera-based face recognition and identity), the face-recognition flow, and the handmade AI XRF that lives on Telegram as @Rradonbot. Displays the current identity state of the visitor (UNKNOWN until recognised).
• Primary actions: Enter the face-verification flow; follow the link to the XRF Telegram bot @Rradonbot.
• Supporting actions: Read the camera-consent and face-data explanation before proceeding.
• Domain entities: Visitor identity state; XRF bot reference (@Rradonbot).
• Component responsibilities: Oversized kinetic wordmark and single CTA stack in the left columns; live camera panel placeholder in the right five columns with a monospace status readout beneath it; procedural dot-field canvas behind all content; XRF/Telegram block rendered as a monospace message ticker ending in a hard-edged vermilion link to @Rradonbot; full-width 1px rules with monospace section numbers (01 CONSENT / 02 SCAN / 03 RECORD / 04 XRF).
• States: Loading (dot-field initialising, status CAMERA: AWAITING PERMISSION); empty (no camera permission yet, camera panel empty); success (visitor proceeds to verification); error (link or navigation failure surfaces a legible message and the CTA remains available); recovery (visitor can retry entry or re-read the consent explanation).

Face Verification

• Information/state: Identity-access surface. Shows whether the visitor is enrolling for the first time or verifying as a returning visitor, and the current verification state.
• Primary actions: Start first-use self-service enrolment by face; start returning verification against stored face data.
• Supporting actions: Move to the camera-access step; return to Landing.
• Domain entities: Visitor identity; enrolment record; stored face data.
• Component responsibilities: Mode selection between first-use enrolment and returning verification; status readout in monospace; handoff into the camera-access step.
• States: Loading (checking whether stored face data exists for this visitor); empty (no stored face data — first-use enrolment path); success (verification outcome shown, visitor continues); error (verification could not complete — legible message with retry); recovery (retry verification or restart enrolment).

Camera Access

• Information/state: Manages the visitor's camera-permission step at the start of use. Shows the browser permission state (not yet requested / granted / denied).
• Primary actions: Request camera permission; proceed once granted.
• Supporting actions: Read why the camera is needed; decline and return.
• Domain entities: Camera-permission state.
• Component responsibilities: Permission request control; plain-language explanation of camera use and face-data handling; monospace status line narrating permission state.
• States: Loading (awaiting the browser's permission response); empty (permission not yet requested); success (permission granted — hand off to Face Scan); error (permission denied or unavailable — legible explanation and a way to retry or return); recovery (re-request permission or continue without it where the flow allows).

Face Scan

• Information/state: After access is granted, receives the camera image and processes it for face recognition. Shows the live camera feed and the recognition state.
• Primary actions: Present the face to the camera; trigger the scan.
• Supporting actions: Reposition or retry the scan; cancel and return.
• Domain entities: Camera frame; face landmarks; face embedding; recognition result.
• Component responsibilities: 4:3 camera panel inside a 1px frame; 2px vermilion scan sweep travelling down the panel over 1.6s; monospace status readout narrating state (FRAME 04 · LANDMARKS 68 · EMBEDDING OK · RECORD #A7F3); dot-field canvas displaced by the detected face position.
• States: Loading (camera stream starting); empty (no face detected in frame); success (face recognised — hand off to Face Capture); error (no face detected, poor lighting, or scan failure — legible message with retry); recovery (retry the scan or return to Camera Access).

Face Capture

• Information/state: Records and stores the recognised face data to continue the identity cycle. Shows the captured record and its identifier.
• Primary actions: Confirm and store the recognised face data; continue the identity cycle.
• Supporting actions: Retake the capture; return to Face Scan.
• Domain entities: Face record (identifier, e.g. #A7F3); stored face data; timestamp.
• Component responsibilities: Capture confirmation control; monospace record readout (record hash, timestamp); handoff to Face Records or back to Landing in a recognised state.
• States: Loading (writing the record); empty (no capture yet); success (record stored — visitor continues as recognised); error (storage failed — legible message with retry); recovery (retake capture or retry storage).

Face Records

• Information/state: Returning view for the visitor to see and manage the face data stored in the system. Shows stored face records with identifiers and timestamps.
• Primary actions: View stored face records; manage (e.g. remove) a stored face record.
• Supporting actions: Return to Landing or Face Verification.
• Domain entities: Face record; identifier; timestamp; stored face data.
• Component responsibilities: Record list with monospace identifiers and timestamps; management controls; empty and error states.
• States: Loading (fetching records); empty (no stored face records — prompt to enrol); success (records listed); error (records could not be loaded — legible message with retry); recovery (retry loading or return to verification).

3. Functional Requirements

FR-1 — Camera access request. As an anonymous site visitor, I should be asked for camera access when I arrive, so that the site can recognise my face. (provenance: explicit; lifecycle: initiator = visitor; trigger = arriving at the site and entering the verification flow; observable result = the browser permission prompt is shown and the permission state is displayed; access state = anonymous, no identity required; failure/recovery = if permission is denied or unavailable, a legible explanation is shown and I can retry or return; continuation = on grant, the flow proceeds to the face scan.)

FR-2 — Face recognition via camera. As an anonymous site visitor, I should have my face recognised through the camera, so that the site knows who I am. (provenance: explicit; lifecycle: initiator = visitor; trigger = camera access granted and my face presented to the camera; observable result = the recognition state changes from UNKNOWN to RECOGNISED and the recognised face is shown; access state = anonymous until recognition completes; failure/recovery = if no face is detected or the scan fails, a legible message is shown and I can retry the scan; continuation = on recognition, the flow proceeds to capture and storage.)

FR-3 — Storage of recognised face data. As an anonymous site visitor, I should have my recognised face data stored, so that the site can recognise me again. (provenance: explicit; lifecycle: initiator = visitor; trigger = a successful recognition; observable result = a face record with an identifier and timestamp is stored and shown to me; access state = the record is bound to my identity; failure/recovery = if storage fails, a legible message is shown and I can retry or retake the capture; continuation = the stored record continues the identity cycle and is visible in Face Records.)

FR-4 — Identity expression (verification) system. As a site visitor, I should have a system that expresses and verifies my identity, so that the site can confirm who I am. (provenance: explicit; lifecycle: initiator = visitor; trigger = entering the verification flow; observable result = my identity is verified against stored face data and the outcome is shown; access state = anonymous for first-use enrolment, recognised for returning verification; failure/recovery = if verification fails, a legible message is shown and I can retry or restart enrolment; continuation = on success, I continue as a recognised visitor.)

FR-5 — First-use self-service enrolment by face. As a first-time site visitor, I should be able to enrol myself by face without an invitation, so that I can use the site's identity system. (provenance: required_inference; lifecycle: initiator = visitor; trigger = no stored face data exists for me; observable result = my face is captured and stored as my identity credential; access state = anonymous entry, protected state unavailable until enrolment completes; failure/recovery = if enrolment fails, a legible message is shown and I can retry; continuation = I continue as a recognised visitor and can return later.)

FR-6 — Returning verification against stored face data. As a returning site visitor, I should be verified against my stored face data, so that the site recognises me again. (provenance: required_inference; lifecycle: initiator = visitor; trigger = I return and present my face; observable result = my identity is matched to my stored face record and the outcome is shown; access state = anonymous entry, recognised on success; failure/recovery = if no match is found, a legible message is shown and I can retry or re-enrol; continuation = on success, I continue as a recognised visitor.)

FR-7 — Server-side processing and secure storage of recognised data. As the site, I should process and store recognised face data server-side and securely, so that recognition and returning verification are truthful and the data is protected. (provenance: required_inference; lifecycle: initiator = system, triggered by the visitor's scan and capture; observable result = the face record is persisted and retrievable for verification; access state = server-side, bound to the correct visitor identity; failure/recovery = storage or processing failure surfaces a legible error to the visitor with retry; continuation = the stored record supports later verification and the Face Records view.)

FR-8 — Presentation of the handmade XRF AI on Telegram. As a site visitor, I should be told about the handmade AI XRF that lives on Telegram, so that I can go and use it there. (provenance: explicit; lifecycle: initiator = visitor; trigger = visiting the Landing surface; observable result = XRF and its Telegram identity @Rradonbot are presented with a link to the bot; access state = public, no identity required; failure/recovery = if the link cannot be followed, the reference remains legible and available; continuation = the visitor can open @Rradonbot in Telegram.)

FR-9 — Telegram bot identity @Rradonbot. As a site visitor, I should see the exact Telegram bot identifier @Rradonbot, so that I can find the XRF bot. (provenance: explicit; lifecycle: initiator = visitor; trigger = viewing the XRF block; observable result = the identifier @Rradonbot is displayed exactly and is actionable as a link; access state = public; failure/recovery = the identifier remains readable if the link fails; continuation = the visitor can locate the bot in Telegram.)

FR-10 — Interaction with XRF inside Telegram. As a Telegram user of the XRF bot, I should interact with the handmade AI XRF inside Telegram, so that I can use it in that platform. (provenance: required_inference; lifecycle: initiator = Telegram user; trigger = opening @Rradonbot in Telegram; observable result = XRF responds inside Telegram; access state = provider-owned Telegram surface, outside this site; failure/recovery = handled by the Telegram provider; continuation = the user continues the conversation in Telegram.)

FR-11 — Revisiting and managing stored face data. As a recognised site visitor, I should be able to revisit and manage the face data stored about me, so that I stay in control of my record. (provenance: required_inference; lifecycle: initiator = visitor; trigger = opening Face Records; observable result = my stored face records with identifiers and timestamps are shown and can be managed; access state = recognised visitor; failure/recovery = if records cannot be loaded, a legible message is shown and I can retry; continuation = I can return to verification or the Landing surface.)

4. User Personas

بازدیدکننده سایت (کاربر ناشناس) — Anonymous Site Visitor

• Product context: Any person who arrives at bronze-mammoth. They land anonymously, are asked for camera access, and move through a face-recognition and identity flow. They may be a first-time visitor with no stored face data or a returning visitor whose face is already stored.
• Primary goal: To enter the site, give camera access if they choose, complete face recognition, and have their identity recognised and recorded.
• Distinct accepted responsibilities: Granting or declining camera access; presenting their face for scanning; confirming the capture of their recognised face data; returning later to be verified against that stored data; revisiting and managing the face records held about them.
• Relevant inputs or decisions: The decision to grant camera permission; the decision to proceed with enrolment or returning verification; the decision to confirm or retake a capture; the decision to manage or remove a stored record.
• Interactions with other accepted participants: None required inside the site beyond the system's own processing; the visitor's face data is the state that the system stores and later verifies. The visitor is also the audience for the XRF/@Rradonbot presentation, which points them to a separate Telegram participant context.
• Observable success: Their identity is recognised and recorded, the recognition state changes from UNKNOWN to RECOGNISED, and on return they are verified against their stored face data.

کاربر تلگرام ربات XRF — XRF Telegram Bot User

• Product context: A user who interacts with the handmade AI XRF through Telegram, reached via the bot @Rradonbot. This interaction happens entirely inside Telegram, not on the bronze-mammoth site.
• Primary goal: To use the handmade AI XRF inside Telegram.
• Distinct accepted responsibilities: Opening the bot @Rradonbot in Telegram and interacting with XRF there. This role does not perform camera access, face scanning, or face-data management on the site.
• Relevant inputs or decisions: The decision to follow the site's link to @Rradonbot; the messages they send to XRF in Telegram.
• Interactions with other accepted participants: The site presents XRF and the bot identifier to this user; the actual conversation is provider-owned and external to the site.
• Observable success: They receive a response from XRF inside Telegram.

5. Core User Flows

Flow A — First-time visitor enrols by face

1. The visitor opens bronze-mammoth and lands on Landing. The dot-field canvas is already alive and reacting to the cursor; the camera panel is empty with the status readout CAMERA: AWAITING PERMISSION; the identity state is UNKNOWN.
2. The visitor reads the camera-consent and face-data explanation and the XRF/@Rradonbot reference, then chooses to proceed into the face-verification flow.
3. On Face Verification, the system finds no stored face data for this visitor and presents the first-use enrolment path.
4. On Camera Access, the visitor is asked for camera permission. The browser prompt is shown and the permission state is displayed.
5. If the visitor grants permission, the flow proceeds to Face Scan. If the visitor denies or the camera is unavailable, a legible explanation is shown and the visitor can retry or return to Landing.
6. On Face Scan, the live camera feed appears in the 4:3 panel. The visitor presents their face. The 2px vermilion scan sweep travels down the panel over 1.6s and the monospace status readout narrates the state (FRAME 04 · LANDMARKS 68 · EMBEDDING OK · RECORD #A7F3). The dot-field is displaced by the detected face position.
7. If no face is detected or the scan fails, a legible message is shown and the visitor can retry the scan or return to Camera Access.
8. On recognition, the identity state changes from UNKNOWN to RECOGNISED, the dot-field flashes vermilion for 400ms and settles back, and the flow proceeds to Face Capture.
9. On Face Capture, the visitor confirms the capture. The recognised face data is stored server-side as a face record with an identifier and timestamp, shown in monospace.
10. If storage fails, a legible message is shown and the visitor can retry or retake the capture.
11. On success, the visitor continues as a recognised visitor and can open Face Records to see the stored record, or return to Landing in the recognised state.

Flow B — Returning visitor is verified against stored face data

1. The returning visitor opens bronze-mammoth and lands on Landing with the identity state UNKNOWN.
2. The visitor proceeds into the face-verification flow.
3. On Face Verification, the system finds stored face data for this visitor and presents the returning verification path.
4. On Camera Access, the visitor is asked for camera permission and grants it (or retries if denied).
5. On Face Scan, the visitor presents their face; the scan sweep and monospace status readout run as in Flow A.
6. The system matches the presented face against the stored face data. On success, the identity state changes from UNKNOWN to RECOGNISED and the dot-field flashes vermilion for 400ms.
7. If no match is found, a legible message is shown and the visitor can retry the scan or restart enrolment.
8. On success, the visitor continues as a recognised visitor and can open Face Records.

Flow C — Recognised visitor revisits and manages stored face data

1. The recognised visitor opens Face Records.
2. The system loads the stored face records and lists them with monospace identifiers and timestamps.
3. If loading fails, a legible message is shown and the visitor can retry.
4. If no records exist, the visitor is prompted to enrol.
5. The visitor views a stored record and chooses to manage it (for example, remove it).
6. The visitor returns to Landing or Face Verification.

Flow D — Visitor discovers and uses XRF on Telegram

1. The visitor lands on Landing and reads the XRF block, rendered as a monospace message ticker of sample XRF exchanges ending in a hard-edged vermilion link to @Rradonbot.
2. The visitor sees the exact Telegram bot identifier @Rradonbot and follows the link.
3. In Telegram, the visitor opens @Rradonbot and interacts with the handmade AI XRF.
4. XRF responds inside Telegram. This interaction is provider-owned and external to the site; the site's responsibility ends at presenting XRF and its Telegram identity.

6. Visuals Colors and Theme

Muse and headline: Yugo Nakamura — Interaction as identity. The interface is an instrument, not a form: the visitor's own face becomes the interface, the recognition event is the state change, and the cursor/face position is the input.

Colour tokens (light mode):

Colour tokens (dark scan stage): ground inverts to #101010 with paper-white type (#F2F0EA) and the same vermilion accent #FF3B1F, so the accent means the same thing in both modes.

Colour proportion: ~78% paper, 14% ink, 6% white cards, 2% vermilion. No blue anywhere; no gradients.

Typography:

• Headings: Space Grotesk at 500–700, tightly tracked (−0.02em) at display sizes and widely tracked (+0.14em) uppercase at micro-label sizes.
• Body: IBM Plex Sans; body measure capped at 62ch.
• Numbers and IDs (face record hash, timestamps, @Rradonbot): IBM Plex Mono.
• Scale: 1.333 modular with a display jump — 44 / 60 / 96 / 144px display (clamp, 44px at 375px → 144px at 1280px), then 28 / 20 / 16 / 14 / 12px. Micro-labels 11px uppercase +0.14em tracking.
• Headlines are set flush-left, ragged-right, in short stacked lines that fill the viewport width.

Shape language: Hard-edged and geometric — 0–4px radii only, so the interface reads as an instrument panel rather than a card deck. Thin 1px ink rules divide everything. The one soft element is the scan reticle: a circle that morphs to an ellipse and back as the face is tracked, drawn as a 2px vermilion stroke that never fills. Buttons are rectangles with a 1px ink border that inverts to solid ink on hover, plus a 1px offset "shadow" rule that shifts on press, like a mechanical key. No blobs, no pills, no soft shadows.

Spacing rhythm: 4/8pt scale; fixed 12-column grid with 24px gutters (16px at 375px).

Imagery style: No stock photography, no 3D renders, no illustration. The imagery is the visitor's own camera feed at 4:3 inside a 1px frame, and the generative dot-field derived from it. Supporting graphics are procedural: a small dot-matrix glyph of the XRF mark, a monospace schematic of the recognition pipeline (camera → landmark mesh → embedding → record) drawn as 1px lines and labelled nodes. Telegram presence is represented by a live-looking monospace message ticker of XRF replies, not a screenshot.

7. Signature Design Concept

The public entry is a single full-viewport stage with no centred headline and no button-under-subtext. The dominant element is a live procedural dot-field canvas covering the entire viewport in ink-on-paper — thousands of 2px ink dots displaced by the cursor like a magnetic field, and displaced again by the detected face position once the camera is live. The visitor literally pushes the interface around with their face.

Over the field, flush left, a stacked display headline set in Space Grotesk at clamp(44px, 10vw, 144px) in two lines — «چهرهات را» / «بشناس» — occupies the left seven columns and bleeds its second line under the camera panel. The camera panel sits in the right five columns: a 4:3 white rectangle with a 1px ink border, empty until permission is granted, with a monospace status line beneath it reading CAMERA: AWAITING PERMISSION. Directly under the headline, pinned to the baseline of the display type, a single vermilion CTA rectangle reading «اجازه دوربین» with a 1px offset rule; below it in 12px mono, @Rradonbot · XRF در تلگرام as a plain underlined link, not a second button. The dot-field reacts to the cursor before any permission is given, so the page is already alive at first paint. Nothing is centred; the composition is asymmetric, left-heavy, and unmistakably an instrument.

This concept only recomposes accepted content, states, and controls: the camera-consent CTA, the camera panel, the status readout, the XRF/@Rradonbot link, and the identity state.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: The procedural dot-field canvas filling the viewport in ink-on-paper, with the live camera panel as the second focal element.
• Input → transformation → outcome thesis: Cursor movement displaces the dot-field like a magnetic field; once camera permission is granted and a face is detected, the detected face position displaces the field again, and on successful recognition the field snaps from ink to vermilion for 400ms and settles back — the visitor's own head physically bends the background and the recognition event is the state change.
• Motion vocabulary: A 2px vermilion scan sweep travelling top-to-bottom across the camera panel over 1.6s with cubic-bezier(0.2, 0, 0, 1); kinetic display headline whose two lines slide in from alternating sides on load and re-settle (never bounce) when identity state changes from UNKNOWN to RECOGNISED; instant (120ms) colour-inversion hover states; full-width 1px ink rules with monospace section numbers (01 CONSENT / 02 SCAN / 03 RECORD / 04 XRF).
• Composed first frame: Dot-field alive and reacting to the cursor; stacked headline «چهرهات را / بشناس» flush left; empty 4:3 camera panel in the right five columns with CAMERA: AWAITING PERMISSION beneath it; vermilion CTA «اجازه دوربین» with its 1px offset rule; @Rradonbot · XRF در تلگرام as a plain underlined link.
• Reduced-motion state: The dot-field renders static, the scan sweep becomes a single non-animated rule, the headline simply appears, and the XRF/Telegram ticker stops and wraps into static rows.

9. Non-Functional Requirements

• Camera consent legibility. The camera-permission step must be honest and legible about privacy and camera consent, with a plain-language explanation of camera use and face-data handling. (provenance: explicit — the user requires the site to request camera access; rationale: a consent-heavy camera flow must not feel like surveillance.)
• Secure server-side processing and storage. Recognised face data must be processed and stored server-side and securely, bound to the correct visitor identity. (provenance: required_inference; rationale: returning verification is only truthful if the stored record belongs to the correct person.)
• Readable text and controls at every viewport. Headlines, wordmarks, labels, numbers, card text, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, with no other element covering any part of them. (provenance: explicit — user design constraint.)
• Reduced-motion support. All motion must respect prefers-reduced-motion: the dot-field renders static, the scan sweep becomes a single non-animated rule, the headline simply appears, and the XRF/Telegram ticker stops and wraps into static rows. (provenance: explicit — creative direction.)
• No blue/indigo template look. The generic indigo/blue-on-white SaaS template is forbidden; the accent is vermilion #FF3B1F on warm paper #F2F0EA only. (provenance: explicit — user design constraint and creative direction.)

10. Tech Stack

• Frontend: React (custom web interface with a full-viewport interactive stage, camera capture, and procedural canvas rendering).
• Backend: Python / FastAPI for server-side face processing, recognition, and secure storage of recognised face data.
• Storage: A persistent store for face records (identifiers, timestamps, stored face data) supporting retrieval for returning verification and the Face Records view.
• Containerisation: Docker / docker-compose for local and deployment packaging.
• External: Telegram bot @Rradonbot hosting the handmade AI XRF — provider-owned and external to this site.

11. Assumptions and Constraints

• Assumption: The site is delivered as a first-party web application with application-owned identity, as established by the Planning Scope. (provenance: required_inference)
• Assumption: First-use identity establishment is self-service by face, with no invitation or provisioning step, because the source states that anyone who arrives is asked for camera access and has their face recognised. (provenance: required_inference)
• Constraint: XRF is handmade and lives on Telegram, not on this site. The site does not host, run, or reimplement XRF. (provenance: explicit)
• Constraint: The Telegram bot identifier is exactly @Rradonbot. (provenance: explicit)
• Constraint: The camera-permission step, face scan, capture, and verification are first-party surfaces of this site; the Telegram interaction is provider-owned and external. (provenance: explicit + required_inference)
• Constraint: No adjacent account-management capabilities beyond the face-based identity cycle are added. (provenance: required_inference)
• Constraint: No blue or indigo primary/accent on a white ground; no Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, or system-ui for headings or body copy; no centred headline + subtext + button hero; no gradient-blob or glowing-orb backgrounds; no grids of identical hover-lift cards with soft drop shadows and 16px radii; no dark HUD "surveillance" styling; no stock photography of faces, AI brain illustrations, or 3D robot heads; no decorative motion that runs without a state meaning. (provenance: explicit — creative direction "Avoid" list)

12. Glossary

• XRF: A handmade artificial intelligence that lives on Telegram, not on this site. Presented by bronze-mammoth and reached via the bot @Rradonbot.
• @Rradonbot: The exact Telegram bot identifier for XRF.
• Face recognition: The process of detecting and identifying a visitor's face from the camera feed.
• Face data: The recognised face information captured and stored by the site.
• Face record: A stored entry containing a recognised face, its identifier (e.g. #A7F3), and a timestamp.
• Identity expression (verification): The site's system for confirming who a visitor is, using their stored face data.
• First-use enrolment: Self-service establishment of a visitor's identity by capturing and storing their face on first use.
• Returning verification: Matching a returning visitor's presented face against their stored face data.
• Dot-field: The procedural canvas of 2px ink dots that fills the viewport and is displaced by the cursor and by the detected face position.
• Scan sweep: The 2px vermilion horizontal line travelling top-to-bottom across the camera panel over 1.6s during capture.
• UNKNOWN / RECOGNISED: The visitor's identity state, changing on successful recognition.