System Requirements Document for jarvis-ai

1. Introduction

jarvis-ai is a personal, general-purpose conversational AI assistant intended for a single owner-operator. It is inspired by the broad usefulness of Gemini-class assistants: the Jarvis User can ask for help with any task and receive an AI response through a protected conversational workspace.

The product also provides on-demand camera vision. Jarvis may look through the user’s camera only when the user explicitly enables camera vision. Camera access is user-controlled and must never be continuously active or enabled by default.

2. System Overview

jarvis-ai is an application-owned AI assistant with anonymous entry and account enrollment/verification before protected work. The current system serves one active human persona: the Jarvis User.

Current delivery includes:

• A public Landing page that introduces Jarvis as a general-purpose personal AI assistant.
• Self-service Sign Up for first-use account establishment.
• Login for returning verification and resumption of the user’s protected assistant work.
• A protected Chat page for general-purpose conversations and AI responses.
• A protected Camera Vision page for an explicit, user-controlled camera-vision interaction.
• Backend integration to process conversation requests and camera-vision requests.

The system maintains continuity for the Jarvis User’s conversations and camera-vision sessions through application-owned identity. This continuity does not imply role-based permissions, multi-user collaboration, account administration, sharing, or other account-management features.

Current Exclusions

The current scope does not include:

• Always-on camera access or camera vision enabled by default.
• Camera monitoring without an explicit user action.
• Multiple user roles, role-based visibility, or differentiated permissions.
• A separate memory-management page or settings page.
• Collaboration, shared conversations, social features, marketplace features, or third-party skill publishing.
• Stock-photo, people-focused, or generic white SaaS visual treatment.

2a. Product Interpretation and Delivery Boundary

Jarvis is a private, general-purpose assistant for a user who wants to ask for help with arbitrary tasks in a conversational format. The user first encounters Jarvis on the public Landing page, then establishes or verifies their identity before entering protected Chat or Camera Vision work.

Chat and Camera Vision are separate protected working contexts. Chat owns text-based requests and Jarvis’s responses. Camera Vision owns the camera-view interaction, including the user’s explicit decision to enable vision and their ability to stop it.

Camera use is strictly opt-in for each engagement. The application must present camera vision as off until the Jarvis User actively initiates it. No current requirement establishes persistent camera enablement, autonomous activation, background observation, or a camera state that survives user control.

2c. Page Content and Component Coverage

Landing

• Information and state
  • Presents Jarvis as a personal, general-purpose AI assistant usable for anything the user asks.
  • Shows that camera vision is user-controlled and currently off by default.
  • Displays anonymous entry state only; protected chat and camera data are unavailable on this page.
• Primary actions
  • Navigate to Sign Up for first-use enrollment.
  • Navigate to Login for returning verification.
  • Use the landing hero’s visual hold-to-open-eye demonstration, which communicates the on-demand camera concept without granting protected camera access from the anonymous page.
• Supporting actions
  • Review the visible camera status indicator showing vision is off and microphone is standby.
• Domain entities
  • Jarvis assistant concept.
  • Camera-vision status: off.
• Component responsibilities
  • Full-viewport hero with the JARVIS wordmark, aperture subject, camera-control metaphor, and status readout.
  • Entry controls that direct new and returning users to the appropriate identity page.
  • The hero hold control must release back to a closed-eye/off visual state.
• States and recovery
  • Default state shows camera vision off.
  • Reduced-motion state uses a static rendered aperture frame.
  • If entry navigation cannot be completed, the page retains the selected entry option and presents a clear retry path.

Login

• Information and state
  • Provides the returning verification boundary for the Jarvis User.
  • Makes clear that successful verification restores access to protected Chat and Camera Vision work.
• Primary actions
  • Submit returning verification information to access the protected application.
• Supporting actions
  • Navigate to Sign Up when the user has not yet established an account.
  • Return to Landing.
• Domain entities
  • Jarvis User account.
  • Authenticated session.
• Component responsibilities
  • Collect the minimum verification input needed by the selected implementation.
  • Verify the supplied identity information.
  • Establish a session only after successful verification.
• States and recovery
  • Loading state while verification is processed.
  • Success state routes the verified user to Chat.
  • Error state explains that verification did not succeed and permits correction and retry.
  • Protected destinations remain inaccessible until verification succeeds.

Sign Up

• Information and state
  • Provides self-service first-use enrollment for the Jarvis User.
  • Establishes the account needed to associate future conversations and camera-vision sessions with the correct user.
• Primary actions
  • Submit enrollment information to create a Jarvis User account.
• Supporting actions
  • Navigate to Login when the user already has an account.
  • Return to Landing.
• Domain entities
  • Jarvis User account.
  • Authenticated session.
• Component responsibilities
  • Collect the minimum enrollment input needed by the selected implementation.
  • Create the account and establish an authenticated session upon successful enrollment.
• States and recovery
  • Loading state while enrollment is processed.
  • Success state routes the enrolled user to Chat.
  • Error state identifies that enrollment could not be completed and allows the user to correct input or retry.
  • If an existing account prevents enrollment, the user can continue to Login.

Chat

• Information and state
  • Protected general-purpose conversational workspace for the authenticated Jarvis User.
  • Displays the user’s prompts and Jarvis responses in the active conversation.
  • Represents an assistant available for arbitrary user requests.
• Primary actions
  • Enter and submit a conversational request to Jarvis.
  • Read Jarvis’s response to the submitted request.
• Supporting actions
  • Navigate to Camera Vision when the user wants Jarvis to look through the camera.
  • Continue the conversation with a follow-up request.
• Domain entities
  • Conversation.
  • User prompt.
  • Jarvis response.
  • Authenticated Jarvis User.
• Component responsibilities
  • Accept and submit user prompts.
  • Associate prompts and responses with the authenticated user’s conversation continuity.
  • Display an in-progress response and its completed result.
  • Present Camera Vision as a protected destination rather than enabling the camera directly in Chat.
• States and recovery
  • Loading or streaming state while Jarvis produces a response.
  • Empty state when no prompt has yet been submitted in the active conversation.
  • Success state displays the completed response and allows the user to continue.
  • Error state reports that Jarvis could not produce a response and preserves the user’s request for retry or revision.
  • If the session is no longer valid, the user is directed to Login before resuming protected work.

Camera Vision

• Information and state
  • Protected camera-vision workspace for the authenticated Jarvis User.
  • Displays camera vision as off until explicitly enabled by the user.
  • When active, presents the camera feed as the contextual visual input for Jarvis.
  • Allows a conversation overlay so the user can ask Jarvis about what is currently seen.
• Primary actions
  • Explicitly enable camera vision when the user wants Jarvis to look through the camera.
  • Explicitly stop camera vision when the user no longer wants Jarvis to look through the camera.
  • Ask Jarvis a question about the active camera view.
• Supporting actions
  • Navigate back to Chat.
  • Review the visible current camera-vision state.
• Domain entities
  • Camera-vision session.
  • Camera permission result.
  • Camera feed.
  • Vision-related user question.
  • Jarvis response.
• Component responsibilities
  • Request device camera access only after the user initiates camera vision.
  • Clearly show off, requesting access, active, stopped, and failed camera states.
  • Supply currently active camera input to Jarvis only while camera vision is engaged.
  • Stop use of the camera feed immediately when the user ends camera vision.
  • Provide the vision-context question input and response overlay.
• States and recovery
  • Default/off state: camera access is not active.
  • Permission-request state: the user has requested camera vision and must respond to the device permission prompt.
  • Active state: vision is visibly engaged and may be used as context for the user’s question.
  • Denied or unavailable state: no camera feed is shared; the user receives a clear explanation and may retry after resolving device access.
  • Stopped state: the camera feed is no longer active and the page returns to the off state.
  • Response-processing state: Jarvis is processing a question about the active camera view.
  • Response failure state: the question remains available for retry while the user can continue to control camera vision independently.

3. Functional Requirements

FR-01 — General-purpose conversational assistance

As a Jarvis User, I should be able to ask Jarvis for help with any task through a general-purpose conversation so that I can receive useful AI assistance.

• Provenance: explicit.
• Actor: Authenticated Jarvis User.
• Trigger/input: The user enters and submits a conversational request on Chat.
• Access state: Login is required.
• System behavior: The system sends the user’s request to Jarvis for processing and displays Jarvis’s response in the conversation.
• Observable result/state change: The conversation contains the submitted user prompt and Jarvis’s resulting response.
• Failure and recovery: If a response cannot be produced, the system must notify the user, preserve the submitted request where possible, and allow the user to retry or revise it.
• Continuation: The user may submit a follow-up request or navigate to Camera Vision.
• Acceptance criteria:
  1. Chat provides an input mechanism for a Jarvis User to submit a request.
  2. A submitted request is visibly associated with the active conversation.
  3. Jarvis provides a visible response for a successfully processed request.
  4. The user can continue the conversation after receiving a response.
  5. A processing failure does not falsely appear as a completed Jarvis response.

FR-02 — User-initiated camera vision

As a Jarvis User, I should be able to explicitly enable camera vision when I want Jarvis to look through my camera so that I can ask for assistance using what the camera sees.

• Provenance: explicit; required_inference for the explicit activation mechanic.
• Actor: Authenticated Jarvis User.
• Trigger/input: The user performs the Camera Vision page’s explicit enable action.
• Access state: Login is required.
• System behavior: The system requests camera access only after the user initiates camera vision. If access is granted, the system activates the camera feed for Jarvis vision context.
• Observable result/state change: The page visibly changes from camera vision off to camera vision active only after the user’s action and successful device access.
• Failure and recovery: If permission is denied, the device has no available camera, or camera access fails, the system must keep vision inactive, explain the failure, and allow the user to retry after resolving the condition.
• Continuation: When vision is active, the user can ask Jarvis a question about what is visible or stop camera vision.
• Acceptance criteria:
  1. Camera Vision initially displays camera vision as off.
  2. The system does not request device camera access before the user explicitly initiates camera vision.
  3. Successful permission and activation produce a clear active camera-vision state.
  4. The active state makes the current camera feed available as context for the user’s camera-related Jarvis request.
  5. A denied or failed permission request does not activate camera vision.

FR-03 — User-controlled camera stop

As a Jarvis User, I should be able to stop camera vision when I no longer want Jarvis to look through my camera so that camera use remains under my control.

• Provenance: explicit; required_inference for the stop interaction and state transition.
• Actor: Authenticated Jarvis User.
• Trigger/input: The user performs the explicit stop action while camera vision is active.
• Access state: Login is required.
• System behavior: The system stops use of the camera feed and changes the visible state back to camera vision off.
• Observable result/state change: The user sees that vision is no longer active, and Jarvis no longer receives active camera input.
• Failure and recovery: If the stop action cannot be completed immediately, the system must show that the attempt did not complete and retain an available stop/retry control until camera vision is off.
• Continuation: The user may remain on Camera Vision with vision off, return to Chat, or explicitly enable vision again later.
• Acceptance criteria:
  1. Camera Vision presents a clear stop control while vision is active.
  2. Activating the stop control ends active camera use.
  3. The page visibly returns to an off state after stopping.
  4. The application provides no always-on camera mode.
  5. Camera vision is not enabled by default or resumed as continuously active without an explicit user action.

FR-04 — Vision-context conversation

As a Jarvis User, I should be able to ask Jarvis a question while camera vision is active so that Jarvis can respond using what I have chosen to show through my camera.

• Provenance: explicit, derived directly from the requested ability for Jarvis to look through the camera when the user wants it to; required_inference for the minimal question-and-response lifecycle.
• Actor: Authenticated Jarvis User.
• Trigger/input: The user submits a question from Camera Vision while camera vision is active.
• Access state: Login is required; camera vision must already be explicitly enabled.
• System behavior: The system processes the question using the active camera feed as relevant context and displays Jarvis’s response in the Camera Vision workspace.
• Observable result/state change: The user sees Jarvis’s response associated with their vision-context question.
• Failure and recovery: If Jarvis cannot process the vision-context question, the system reports the failure and allows the user to retry or revise the question. The user retains independent control to stop camera vision.
• Continuation: The user may ask a follow-up question, stop camera vision, or return to Chat.
• Acceptance criteria:
  1. A vision-context question can be submitted only when camera vision is active.
  2. The resulting response is visibly displayed in Camera Vision.
  3. The user can stop camera vision regardless of whether a vision-context response is processing.
  4. Once camera vision is stopped, the system does not treat an inactive camera feed as active visual context for a new vision request.

FR-05 — Self-service enrollment

As a Jarvis User, I should be able to enroll myself before using protected Chat and Camera Vision work so that my conversations and camera-vision sessions remain associated with me.

• Provenance: required_inference.
• Actor: New Jarvis User.
• Trigger/input: The user submits enrollment information on Sign Up.
• Access state: Anonymous.
• System behavior: The system creates an application-owned Jarvis User account and establishes an authenticated session after successful enrollment.
• Observable result/state change: The user is routed to protected Chat as an authenticated user.
• Failure and recovery: If enrollment cannot be completed, the system identifies the failure and allows correction or retry. If the user already has an account, Login remains available.
• Continuation: The enrolled user can begin a Chat conversation or navigate to Camera Vision after login continuity is established.
• Acceptance criteria:
  1. Sign Up is anonymously reachable.
  2. Successful enrollment creates access to protected work.
  3. Protected Chat and Camera Vision remain unavailable before successful enrollment or Login.
  4. Enrollment failure provides a path to retry or continue to Login where appropriate.

FR-06 — Returning verification and resumption

As a Jarvis User, I should be able to verify my identity when returning so that I can resume my protected conversations and camera-vision sessions.

• Provenance: required_inference.
• Actor: Returning Jarvis User.
• Trigger/input: The user submits verification information on Login.
• Access state: Anonymous before successful verification.
• System behavior: The system verifies the user and establishes an authenticated session associated with that user’s protected assistant work.
• Observable result/state change: The user gains access to Chat and Camera Vision and is routed to Chat after successful Login.
• Failure and recovery: If verification fails, the system does not grant protected access and permits correction and retry.
• Continuation: The verified user can continue with Chat or navigate to Camera Vision.
• Acceptance criteria:
  1. Login is anonymously reachable.
  2. A successful Login establishes access to Chat and Camera Vision.
  3. A failed Login does not expose protected conversation or camera-vision work.
  4. The user can retry failed verification.

4. User Personas

Jarvis User

• Provenance: required_inference from the accepted personal-assistant journey.
• Product context: The Jarvis User is the single owner-operator of jarvis-ai. They want a Gemini-like assistant that can be used for arbitrary requests and can, when explicitly requested, understand what the user chooses to show through a camera.
• Primary goal: Receive useful AI assistance for whatever task or question they bring to Jarvis.
• Distinct responsibilities: The user submits conversational prompts, reviews responses, decides whether camera vision should be enabled, grants or declines device camera permission, asks questions about an active camera view, and explicitly stops camera vision when finished.
• Relevant inputs and decisions: Conversational request text, vision-context questions, the decision to sign up or log in, the decision to enable camera vision, and the decision to stop it.
• Interaction with other accepted participants: The user interacts with Jarvis as the AI responder. Jarvis returns responses to user prompts and vision-context questions. No additional active human participant is in scope.
• Observable success: The user receives a visible Jarvis response to their request and, when using camera vision, sees that camera access occurs only while they have explicitly chosen to engage it.

5. Core User Flows

Flow 1 — First-use enrollment and first conversation

1. The new Jarvis User starts on Landing in an anonymous state.
2. The user reviews that Jarvis is a general-purpose personal AI assistant and that camera vision is off unless explicitly engaged.
3. The user selects the entry action for first-use enrollment.
4. The user arrives at Sign Up.
5. The user enters the required enrollment information and submits it.
6. The application creates the Jarvis User account and establishes an authenticated session.
7. The user is routed to Chat.
8. The user enters and submits a request for help with any task.
9. Jarvis processes the request and displays a response in the conversation.
10. The user reads the response and may submit a follow-up request.

Failure and recovery: If enrollment fails, Sign Up presents a failure state and allows the user to correct input or retry. If the user already has an account, they can continue to Login. If a Jarvis response fails, Chat preserves the request where possible and lets the user retry or revise it.

Flow 2 — Returning access and conversational assistance

1. The returning Jarvis User starts on Landing or reaches Login directly.
2. The user selects Login.
3. The user arrives at Login and submits returning verification information.
4. The application verifies the user and establishes an authenticated session.
5. The user is routed to Chat.
6. The user submits a conversational request.
7. Jarvis processes the request and displays its response.
8. The user reviews the response and may continue the conversation or navigate to Camera Vision.

Failure and recovery: If verification fails, Login keeps protected pages unavailable and permits the user to correct and resubmit their verification information. If processing fails in Chat, the user can retry or revise the request.

Flow 3 — Enable camera vision and ask about what is seen

1. The authenticated Jarvis User begins on Chat and decides they want Jarvis to look through the camera.
2. The user navigates to Camera Vision.
3. Camera Vision displays the initial state: vision is off and no camera feed is active.
4. The user explicitly initiates camera vision using the page’s camera engagement control.
5. The application requests device camera permission only after this action.
6. The user grants device camera permission.
7. The application activates the camera feed and visibly changes Camera Vision to its active state.
8. The user enters and submits a question about what they are showing through the camera.
9. Jarvis processes the question using the active camera view as relevant context.
10. Jarvis displays a response in the Camera Vision conversation overlay.
11. The user reviews the response and may ask another vision-context question, stop camera vision, or return to Chat.

Failure and recovery: If camera permission is denied, unavailable, or fails, camera vision remains off and the user sees a clear failure state with a retry path. If Jarvis cannot process the question, the question can be retried or revised without removing the user’s ability to stop camera vision.

Flow 4 — Stop camera vision

1. The authenticated Jarvis User is on Camera Vision while camera vision is active.
2. The user decides they no longer want Jarvis to look through the camera.
3. The user activates the explicit stop control.
4. The application stops use of the active camera feed.
5. Camera Vision visibly returns to its off state.
6. The user remains able to return to Chat or explicitly enable camera vision again later.

Failure and recovery: If stopping camera vision does not complete immediately, Camera Vision presents a failure indication and keeps a stop/retry action available until the camera is confirmed off.

6. Visuals Colors and Theme

Muse: Gleb Kuznetsov
Headline: Cinematic future-tech after Gleb Kuznetsov: a dark void, one glowing aperture, motion as the interface.

jarvis-ai uses a cinematic, instrument-like future-tech visual system for an early-adopter power user. The product should feel quietly powerful, controlled, and present rather than corporate-neutral or cute.

Color Tokens

• Use approximately 70% near-black void, 20% glass panels, 8% cyan interactive signal, and 2% amber.
• Cyan is reserved for live or interactive signal, including active navigation, reply strokes, and cursor rings.
• Amber is reserved exclusively for the engaged camera-vision state and send action. Amber must not appear as an enabled camera state before the user turns the eye on.
• Body text uses #E8F1FA against #05070C.
• Muted text is limited to non-essential metadata at 13px or above.

Typography

• Headings and wordmark: Space Grotesk 700 and 500.
• Body: Sora.
• Micro-labels and technical readouts: IBM Plex Mono.
• Use uppercase Space Grotesk with +0.06em tracking for wordmarks and section titles.
• Use -0.03em tracking for oversized display text.
• Use IBM Plex Mono at 11px, uppercase, with +0.18em tracking for system-status language.
• Use a 1.5 modular scale:
  • Display: approximately 19vw.
  • Display support: 72px.
  • Heading: 44px.
  • Section heading: 28px.
  • Subheading: 18px.
  • Body: 15px.
  • Micro-label: 13px.
• Display line height is approximately 0.92; 18px body copy uses approximately 1.7.

Surfaces, Shape, and Layout

• Use thin luminous strokes over dark glass surfaces.
• Primary panels use 20px radii, cyan-tinted 1px borders, and no drop shadows.
• Rail elements and data chips use sharp 0px corners.
• Use one repeating circular motif: the aperture ring, shutter geometry, reply pulse dot, and hold-to-engage camera control.
• Depth comes from bloom, blur, and light edges rather than solid filled cards or shadows.
• Add restrained radial and diagonal hairline arcs at low opacity as ambient orbital structure.
• Avoid a top navigation bar. The app shell uses a fixed 88px left rail with rotated uppercase mono labels and a glowing active cyan bar.
• Only the contract pages are navigable destinations. Current navigation exposes Chat and Camera Vision; any “MEMORY” and “SETTINGS” labels shown in visual composition are non-interactive future-facing decorative rail text and must not create pages or current functionality.

Imagery

• Use generated visual content only.
• Do not use stock photography, people imagery, flat clip art, emoji icons, or decorative confetti.
• The hero subject is a volumetric glass-and-light aperture ring with luminous cyan rings and refracted internal filaments.
• Use faint particle fields, luminous data streams, and topographic arc grids as ambient texture.
• Treat active live camera imagery with a cyan-to-amber duotone edge and scanline overlay only while vision is engaged.

7. Signature Design Concept

The Landing page is a full-bleed near-black instrument panel dominated by a single real-time volumetric aperture positioned slightly right of center. The oversized cropped wordmark JARVIS bleeds from the left side of the viewport, while the phrase SEES WHEN YOU SAY SO appears beneath it as a muted technical readout.

At bottom-right, the first-screen focal control is a circular outlined interaction reading HOLD TO OPEN THE EYE. Its cyan progress arc fills while held; the aperture shutters open only during the held state and snap shut when released. This is a visual explanation of the user-controlled camera principle, not an anonymous camera activation mechanism. Entry actions to Sign Up and Login remain available as restrained luminous text controls integrated into the scene.

The scene’s bottom-left mono status line reads: VISION · OFF · MIC · STANDBY. The design keeps the camera visibly off by default and reserves amber for the protected Camera Vision page’s active vision state.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: A volumetric glass aperture with concentric cyan rings and refracted