System Requirements Document for gork-subscribers

1. Introduction

gork-subscribers is an AI chat assistant application in the spirit of Grok, built around a single defining product fact: its subscriber capacity is a shared, finite, monthly-replenished pool of 200 seats. Rather than each user holding an independent subscription, the product distributes a shared pool of 200 subscriber seats across its subscribers every month, and an allocation owner configures and manages how that monthly 200 is divided.

The product intent, derived from the authoritative requirement thread ("Make me an app like gork but share the subscribers 200 each month"), is twofold:

1. A Grok-like AI chat assistant — subscribers send prompts and receive AI responses in a conversational workspace.
2. A shared monthly subscriber pool of 200 — the 200 subscriber seats are shared, distributed each month, and managed by an allocation owner so that subscribers can actually use their share.

The audience is individual AI power users (subscribers) who want conversational AI access through a shared monthly allocation, plus an allocation owner who runs the monthly distribution of the 200 seats.

2. System Overview

gork-subscribers is a first-party web application with application-owned identity. It delivers:

• An anonymous public entry (Landing) that explains the Grok-like AI assistant and the shared 200-per-month subscriber model before identity is established.
• Self-service identity establishment (Sign Up) and returning verification (Login) for both subscribers and the allocation owner.
• A protected AI chat workspace (Chat) where subscribers send prompts, receive responses, and continue their conversations.
• A subscriber management view (Subscribers) where the allocation owner browses and manages the subscribers participating in the shared monthly 200 distribution.
• A focused allocation workspace (Allocations) where the allocation owner configures and edits each subscriber's share of the monthly 200.

Actors: Two accepted human personas — Subscriber and Allocation Owner — plus the AI assistant backend as a non-persona system actor.

Ownership: All six pages are application-owned custom UI. Identity is application-owned and established through self-service enrollment. The AI assistant response generation is a backend/system responsibility invoked by subscriber prompts.

Narrow exclusions: This document does not add adjacent capabilities such as billing, payment processing, social feeds, content moderation consoles, analytics dashboards, or third-party integrations. The product is scoped to the Grok-like chat assistant plus the shared monthly 200 subscriber distribution.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. gork-subscribers is delivered as a first-party web application with custom UI. All six destinations — Landing, Login, Sign Up, Chat, Subscribers, Allocations — are owned and rendered by the application itself. There is no provider-owned or external-only surface in the current scope.

Access ownership. Identity is application-owned. Because subscribers and the allocation owner must privately own and resume durable, actor-specific state (conversations, allocation configuration, monthly share), the application establishes identity through self-service enrollment (Sign Up) and verifies returning users (Login). The Landing page is anonymously reachable and explains the product before identity is established. Chat, Subscribers, and Allocations are protected destinations whose durable state is bound to the correct participant; they cannot own the interaction that establishes access to themselves, so the anonymous entry boundary (Landing → Sign Up / Login) is distinct from the protected surfaces.

Current vs. future boundary. The current delivery horizon covers the Grok-like chat assistant, the shared monthly 200 subscriber pool, subscriber management, and allocation configuration. No future-horizon requirements were stated in the authoritative thread; anything beyond the current scope is out of scope for this generation.

2b. Source Content Inventory

No reference directive in the Planning Scope declares content_source. The single reference directive (Grok) is declared inspiration_only with uses: ["feature_reference"], supplying only a loose feature reference for an AI chat assistant and no factual content, entities, or collections. Therefore no Source Content Inventory is included.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Explains the Grok-like AI assistant and the shared subscriber model — that 200 subscriber seats are shared and distributed every month. No protected state is shown.
• Primary action: Proceed to establish identity (Sign Up) or verify returning identity (Login).
• Supporting actions: Read the product explanation; view the shared-pool concept.
• Domain entities: Shared monthly subscriber pool (200 seats); subscriber concept; allocation concept (conceptual only, no protected data).
• Component responsibilities: Full-bleed generative hero canvas seeded from the shared-pool concept; wordmark; headline; single outlined CTA; entry links to Sign Up and Login.
• States: Loading (hero canvas initializing); empty (no protected data by design); success (visitor understands the product and proceeds); error (canvas fails to initialize → static seeded frame fallback); recovery (reduced-motion static frame).

Login

• Information/state: Anonymous identity-access surface for returning subscribers and the allocation owner. Collects returning-user credentials.
• Primary action: Verify identity and resume protected workflows.
• Supporting actions: Navigate to Sign Up for first use.
• Domain entities: Application identity (returning user).
• Component responsibilities: Credential input; submit control; link to Sign Up; error display.
• States: Loading (verification in progress); empty (no credentials entered); success (identity verified → route to Chat for subscribers, Subscribers/Allocations for the allocation owner); error (invalid credentials → inline error, retry); recovery (re-enter credentials or navigate to Sign Up).

Sign Up

• Information/state: Anonymous self-service enrollment surface for first-use identity establishment. No invitation, provisioning, or provider boundary is established, so enrollment is self-service.
• Primary action: Establish an application identity.
• Supporting actions: Navigate to Login for returning users.
• Domain entities: Application identity (new user).
• Component responsibilities: Enrollment input; submit control; link to Login; validation and error display.
• States: Loading (enrollment in progress); empty (no input entered); success (identity established → route to protected surfaces); error (validation or enrollment failure → inline error, retry); recovery (correct input or navigate to Login).

Chat

• Information/state: Protected AI assistant workspace for subscribers. Shows the subscriber's conversations and the current conversation's messages. Reflects the subscriber's available monthly share.
• Primary action: Send a prompt and receive an AI response.
• Supporting actions: Browse and select conversations; continue an existing conversation; start a new conversation.
• Domain entities: Conversation; message (prompt and response); subscriber's monthly share.
• Component responsibilities: Narrow left conversation rail; wide reading column; prompt input; message rendering with the condensing-arrival treatment; persistent allocation spine showing the shared 200 for the current cycle.
• States: Loading (conversation list and messages loading); empty (no conversations yet → prompt to start one); success (prompt sent, response received and rendered); error (response generation failure → inline error with retry); recovery (retry the prompt or continue the conversation).

Subscribers

• Information/state: Protected allocation-owner view. Lists the subscribers participating in the shared monthly 200 distribution, with each subscriber's current share.
• Primary action: Browse and manage the subscriber roster.
• Supporting actions: Select a subscriber to view or edit their allocation; navigate to Allocations.
• Domain entities: Subscriber; monthly share; shared monthly pool (200).
• Component responsibilities: Ruled subscriber rows with tabular figures; radial allocation gauge per row; persistent allocation spine; navigation to Allocations.
• States: Loading (roster loading); empty (no subscribers yet → prompt to add or enroll subscribers); success (roster displayed with shares); error (roster load failure → retry); recovery (retry load or navigate to Allocations).

Allocations

• Information/state: Protected allocation-owner workspace. Shows the monthly 200 pool and each subscriber's configured share, with the total distributed against the 200.
• Primary action: Configure and edit each subscriber's share of the monthly 200.
• Supporting actions: Review the total distributed; adjust individual shares; confirm the monthly distribution.
• Domain entities: Monthly allocation; subscriber share; shared monthly pool (200).
• Component responsibilities: Allocation editing controls; radial allocation gauge per subscriber; total-vs-200 summary; persistent allocation spine; confirmation control.
• States: Loading (allocation data loading); empty (no subscribers to allocate → prompt to add subscribers); success (shares configured and confirmed); error (save or validation failure → inline error, retry); recovery (correct the share or retry the save).

3. Functional Requirements

FR-1 — Grok-like AI chat assistant

As a Subscriber I should send prompts to an AI assistant and receive conversational responses so that I can use the product as a Grok-like AI chat assistant.

• Provenance: explicit
• Actor: Subscriber (initiator); AI assistant backend (system participant)
• Trigger/input: Subscriber enters a prompt in the Chat workspace.
• Observable result/state change: The prompt is recorded as a message and an AI response is rendered in the conversation.
• Access state: Protected — requires established application identity.
• Failure/recovery: If response generation fails, an inline error is shown and the subscriber can retry the prompt.
• Continuation: The subscriber can continue the conversation with further prompts or start a new conversation.

FR-2 — Shared monthly subscriber pool of 200

As an Allocation Owner I should have the shared subscriber pool fixed at 200 seats per month so that the monthly distribution is bounded and predictable.

• Provenance: explicit
• Actor: Allocation Owner (initiator); Subscriber (affected participant)
• Trigger/input: The monthly cycle; the allocation owner's configuration of the pool.
• Observable result/state change: The shared pool for the current cycle is 200 seats, visible to the allocation owner and reflected in the allocation spine.
• Access state: Protected — allocation-owner surfaces.
• Failure/recovery: If the configured distribution exceeds 200, the allocation workspace surfaces the overage and blocks confirmation until corrected.
• Continuation: The allocation owner confirms a distribution within the 200 bound.

FR-3 — Configure the monthly 200 distribution

As an Allocation Owner I should configure how the monthly 200 is distributed across subscribers so that subscribers can rely on their available allocation.

• Provenance: required_inference
• Actor: Allocation Owner (initiator); Subscriber (affected participant)
• Trigger/input: The allocation owner opens Allocations and edits each subscriber's share.
• Observable result/state change: Each subscriber's share of the monthly 200 is set and the total distributed is shown against 200.
• Access state: Protected — allocation-owner surface.
• Failure/recovery: If a share is invalid or the total exceeds 200, an inline error is shown and the save is blocked until corrected.
• Continuation: The allocation owner confirms the distribution, making shares available to subscribers.

FR-4 — Browse and manage subscribers

As an Allocation Owner I should browse and manage the subscribers participating in the shared monthly distribution so that I know who is receiving a share.

• Provenance: required_inference
• Actor: Allocation Owner (initiator); Subscriber (affected participant)
• Trigger/input: The allocation owner opens Subscribers.
• Observable result/state change: The subscriber roster is displayed with each subscriber's current share.
• Access state: Protected — allocation-owner surface.
• Failure/recovery: If the roster fails to load, a retry is offered.
• Continuation: The allocation owner selects a subscriber to view or edit their allocation.

FR-5 — Subscriber receives and uses their monthly share

As a Subscriber I should have my monthly share of the shared 200 available and usable for my own prompts and conversations so that I can use the AI assistant within my allocation.

• Provenance: required_inference
• Actor: Subscriber (initiator); Allocation Owner (configuring participant)
• Trigger/input: The subscriber opens Chat after the allocation owner has configured the distribution.
• Observable result/state change: The subscriber's available share is reflected in the allocation spine and usable for prompts.
• Access state: Protected — subscriber surface.
• Failure/recovery: If the subscriber's share is exhausted or unavailable, the workspace surfaces the state and the subscriber can continue once the next cycle's allocation is configured.
• Continuation: The subscriber continues using the assistant within their share.

FR-6 — Self-service identity establishment

As a Subscriber or Allocation Owner I should establish an application identity on first use so that I can access protected workflows.

• Provenance: required_inference
• Actor: Subscriber or Allocation Owner (initiator)
• Trigger/input: First use; the user opens Sign Up from the Landing page.
• Observable result/state change: An application identity is established and the user is routed to protected surfaces.
• Access state: Anonymous entry (Sign Up is reachable without identity).
• Failure/recovery: If enrollment fails validation, an inline error is shown and the user can correct input or navigate to Login.
• Continuation: The user proceeds to Chat (subscriber) or Subscribers/Allocations (allocation owner).

FR-7 — Returning identity verification

As a Subscriber or Allocation Owner I should verify my identity on return so that I can resume my protected workflows.

• Provenance: required_inference
• Actor: Subscriber or Allocation Owner (initiator)
• Trigger/input: Returning use; the user opens Login.
• Observable result/state change: Identity is verified and the user is routed to their protected surfaces.
• Access state: Anonymous entry (Login is reachable without identity).
• Failure/recovery: If credentials are invalid, an inline error is shown and the user can retry or navigate to Sign Up.
• Continuation: The user resumes Chat (subscriber) or Subscribers/Allocations (allocation owner).

4. User Personas

Subscriber

• Product context: An individual AI power user who uses the Grok-like assistant through a shared monthly pool of 200 subscriber seats. Their access is not an independent subscription but a share of a finite, monthly-replenished resource.
• Primary goal: Have their monthly share of the shared 200 available and usable for their own prompts and conversations.
• Distinct accepted responsibilities: Sending prompts and receiving AI responses; continuing conversations; using their allocation within the shared pool.
• Relevant inputs or decisions: Prompts; conversation selection; awareness of their remaining share.
• Interactions with other accepted participants: Depends on the Allocation Owner to configure the monthly distribution that makes their share available.
• Observable success: The subscriber's share is reflected in the allocation spine and their prompts receive responses within their allocation.
• Provenance: required_inference (from the explicit "share the subscribers 200 each month" requirement).

Allocation Owner

• Product context: The participant who runs the monthly distribution of the shared 200 subscriber seats. Their work is the operational core of the shared-pool model.
• Primary goal: A correctly configured monthly distribution of the 200 that subscribers can actually use.
• Distinct accepted responsibilities: Browsing and managing the subscriber roster; configuring and editing each subscriber's share of the monthly 200; confirming the distribution within the 200 bound.
• Relevant inputs or decisions: Subscriber roster; per-subscriber share values; the 200-seat monthly bound; confirmation of the distribution.
• Interactions with other accepted participants: Configures the shares that Subscribers rely on; their configuration directly determines subscriber availability.
• Observable success: The total distributed is within 200, each subscriber's share is set, and subscribers can use their allocation.
• Provenance: required_inference (from the explicit "share the subscribers 200 each month" requirement).

5. Core User Flows

Flow A — Subscriber first use and chat

1. Starting context: A visitor with no application identity opens the Landing page.
2. Action: The visitor reads the explanation of the Grok-like assistant and the shared 200-per-month subscriber model.
3. Decision: The visitor chooses to establish identity and proceeds to Sign Up.
4. Action: The visitor completes self-service enrollment on Sign Up.
5. Observable result: An application identity is established and the visitor is routed to the protected Chat workspace.
6. Action: The subscriber enters a prompt in Chat.
7. Observable result: The prompt is recorded and an AI response is rendered in the conversation; the allocation spine reflects the shared 200 for the current cycle.
8. Continuation: The subscriber continues the conversation or starts a new one within their share.
9. Failure/recovery: If response generation fails, an inline error is shown and the subscriber retries the prompt.

Flow B — Subscriber returning use

1. Starting context: A subscriber with an existing identity opens the Landing page.
2. Action: The subscriber proceeds to Login.
3. Action: The subscriber enters credentials on Login.
4. Observable result: Identity is verified and the subscriber is routed to Chat.
5. Continuation: The subscriber resumes their conversations and continues using their monthly share.
6. Failure/recovery: If credentials are invalid, an inline error is shown and the subscriber retries or navigates to Sign Up.

Flow C — Allocation Owner configures the monthly 200

1. Starting context: The allocation owner has an established identity and opens Login (or arrives from Sign Up on first use).
2. Action: The allocation owner verifies identity and is routed to the protected allocation-owner surfaces.
3. Action: The allocation owner opens Subscribers to review the roster of subscribers participating in the shared monthly distribution.
4. Observable result: The roster is displayed with each subscriber's current share and the allocation spine shows the shared 200 for the current cycle.
5. Action: The allocation owner opens Allocations and edits each subscriber's share of the monthly 200.
6. Observable result: Each subscriber's share is set and the total distributed is shown against 200.
7. Decision: The allocation owner confirms the distribution.
8. Observable result: The distribution is confirmed within the 200 bound and subscribers can rely on their available allocation.
9. Continuation: The allocation owner returns to Subscribers to review the configured shares.
10. Failure/recovery: If a share is invalid or the total exceeds 200, an inline error is shown and the save is blocked until corrected.

Flow D — Subscriber uses their configured share

1. Starting context: The allocation owner has confirmed the monthly distribution; a subscriber with an established identity opens Chat.
2. Action: The subscriber sends a prompt.
3. Observable result: The subscriber's available share is reflected in the allocation spine and the prompt receives a response within their allocation.
4. Continuation: The subscriber continues using the assistant within their share.
5. Failure/recovery: If the subscriber's share is exhausted or unavailable, the workspace surfaces the state and the subscriber can continue once the next cycle's allocation is configured.

6. Visuals Colors and Theme

Muse: Refik Anadol. Headline direction: Data made physical — the shared pool of 200 subscriber seats rendered as a living, breathing generative field rather than a SaaS dashboard.

Colour tokens (dark mode)

Colour appears only as light inside the generative field — never as a filled brand block.

Typography

• Headings: Space Grotesk 500–600, tracked -0.02em, sentence case for headlines; uppercase only for 11px micro-labels with 0.16em tracking.
• Body: IBM Plex Sans, 16px/1.6.
• Numerals: IBM Plex Mono 500, always tabular; allocation figures set at 2–3× the size of their label.
• Scale: 1.25 modular — 96/72/48/28/20/16. Display clamp(40px, 8vw, 96px); section heads clamp(28px, 4vw, 48px); body 16px/1.6; micro-labels 11px uppercase.

Shape language

Full-bleed generative canvas with no visible frame; UI floats as thin luminous strokes and 1px-bordered rectangles with 4px radii. Gauges are radial arcs, never rings with fills. Section boundaries are soft horizontal luminescence gradients rather than hard rules. Cards are 1px outlines on the dark ground — no shadows, no lift.

Layout

Asymmetric museum grid: a 12-column field with content held to columns 2–7 on desktop and the generative canvas bleeding to the right edge and past it. Landing is a single full-viewport canvas with a fixed, sparse overlay — wordmark top-left, one line of copy bottom-left, one CTA bottom-left beneath it. Chat is a two-column split: a narrow left rail of conversations (col 1–3) and a wide reading column (col 4–9) with the right third left empty as breathing room. Subscribers and Allocations are dense but calm: ruled rows on #0E1016 with tabular figures right-aligned, and a persistent thin allocation bar pinned to the top of every authenticated page.

Imagery

No stock photography, no device mockups, no clip art. All imagery is generative: a WebGL particle/fluid field seeded from the user's own allocation data (remaining seats, burn rate, days left in cycle), plus geometric line diagrams for the allocation model. The only non-generative visuals are 1px hairline charts and typographic numerals.

7. Signature Design Concept

The allocation field as hero. The Landing first screen is one full-bleed dark canvas (#07080C) filled edge to edge with a slow generative particle field in cyan #7BE0FF that thins and warms toward magenta #FF6FA8 where density is highest. Overlaid bottom-left, not centred: the wordmark gork-subscribers set in Space Grotesk 500 at clamp(18px, 2vw, 22px), and beneath it a two-line headline at clamp(40px, 8vw, 96px) — "Two hundred seats. Shared every month." — occupying columns 1–6 only, so the field's densest region stays visible and untouched on the right. A single outlined CTA sits directly under the headline, left-aligned, 1px cyan border, transparent fill. Nothing is centred; there is no gradient blob, no floating card, no blue button.

The signature moves that carry the concept through the product:

• Full-bleed WebGL generative particle field on the landing whose density and hue are seeded from the product's own allocation data, drifting on a slow loop and morphing into the monthly allocation arc as the page scrolls.
• Allocation spine: a 3px full-width luminous bar pinned to the top of every authenticated page that shows the shared 200 for the current cycle draining in real time, with the remaining count in IBM Plex Mono sitting in the top-right of the bar.
• Allocation gauge: a radial arc, not a ring, drawn in 1px cyan stroke with a single glowing head where the current share ends — used on Subscribers and Allocations rows instead of progress bars.
• Editorial-numeral treatment: every allocation figure is set in IBM Plex Mono 500 at 2–3× the size of its label with the label as an 11px uppercase tracked micro-caption beneath it, so the numbers read as the page's ornament.
• Chat answer arrival: answers condense out of a faint particle wash at the top of the reading column — the message body fades up from 0.4 opacity over 500ms while a 1px cyan stroke draws left-to-right along the message's top edge.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: A full-bleed WebGL particle/fluid field seeded from the product's own allocation data (remaining seats, burn rate, days left in cycle), rendered in cyan #7BE0FF thinning and warming toward magenta #FF6FA8 where density is highest.
• Input → transformation → outcome thesis: As the visitor scrolls the landing, the drifting particle field condenses into the shape of the monthly allocation arc — the abstract shared pool becomes the concrete distribution model the product delivers.
• Motion vocabulary: One continuous generative flow driven by a seeded particle field drifting on a 40–60s cycle with no visible loop point; scroll-linked morphing; no bounce, no spring, no hover-lift.
• Composed first frame: Full-viewport #07080C canvas with the field at rest; wordmark top-left; two-line headline bottom-left in columns 1–6; single outlined cyan CTA beneath it.
• Reduced-motion state: A static seeded frame of the field plus a plain allocation bar; no scroll-linked morphing.

In-app motion is data-driven and restrained: allocation bars animate their width over 600ms with cubic-bezier(0.16,1,0.3,1), numbers count up once on mount, no hover-lift, no bounce. prefers-reduced-motion renders a static seeded frame of the field plus a plain allocation bar.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

A single crafted real-time WebGL particle/fluid field that shows the product's defining state: a finite, shared, monthly-replenished pool of 200 seats. The scene is seeded from the product's own allocation data so the field's density and hue encode remaining seats, burn rate, and days left in the cycle. It drifts on a slow 40–60s cycle with no visible loop point and morphs into the monthly allocation arc on scroll. Under prefers-reduced-motion, the scene renders a static seeded frame.

9. Non-Functional Requirements

• NFR-1 — Shared pool bound. The shared subscriber pool is fixed at 200 seats per month. The allocation workspace must surface the total distributed against 200 and block confirmation when the total exceeds 200. (Provenance: explicit. Rationale: the authoritative requirement states "share the subscribers 200 each month".)
• NFR-2 — Identity continuity. Protected workflows (Chat, Subscribers, Allocations) must remain bound to the correct participant so that durable state — conversations, allocation configuration, monthly share — is privately owned and resumable. (Provenance: required_inference. Rationale: subscribers and the allocation owner must resume actor-specific state.)
• NFR-3 — Anonymous entry. Landing, Login, and Sign Up must be reachable without an established identity; protected state must remain unavailable until identity is established. (Provenance: required_inference. Rationale: a protected destination cannot own the interaction that establishes access to itself.)
• NFR-4 — Readable text and controls. Headlines, wordmarks, labels, numbers, cards' 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 creative direction.)
• NFR-5 — Reduced motion. With prefers-reduced-motion, provide a usable static arrangement: a static seeded frame of the generative field plus a plain allocation bar, and wrap or allow horizontal scrolling so each item can be brought fully into view. (Provenance: explicit creative direction.)
• NFR-6 — Accessibility contrast. Body text #F2F4F8 on #07080C (~17:1) and muted #8A93A6 (~5.5:1) must both pass at 16px. (Provenance: explicit creative direction.)

10. Tech Stack

• Frontend: React (web application with custom UI).
• 3D/Generative hero: WebGL / React Three Fiber for the full-bleed generative particle field on the Landing page (direction-derived hero dimensionality: webgl).
• Backend: Python / FastAPI for the AI assistant integration, identity, subscriber roster, and allocation configuration.
• Storage: Appropriate persistent storage for application identities, conversations, messages, subscriber roster, and monthly allocations.
• Deployment: Docker / docker-compose for local and single-host deployment. Kubernetes only if deployment scale requires it.

11. Assumptions and Constraints

• A-1: The shared pool is exactly 200 subscriber seats per month, as stated in the authoritative requirement. (Explicit.)
• A-2: Identity is application-owned and established through self-service enrollment, because no invitation, provisioning, provider, or pre-existing-account boundary is established in the source. (Required inference.)
• A-3: The AI assistant response generation is a backend/system responsibility invoked by subscriber prompts; the human interaction is owned by the Chat page. (Required inference.)
• A-4: The allocation owner is a distinct participant from subscribers because the monthly 200 must be distributed across subscribers by someone. (Required inference.)
• A-5: No billing, payment processing, or adjacent account-management capabilities are in scope; the product is scoped to the Grok-like chat assistant plus the shared monthly 200 subscriber distribution. (Source-bounded exclusion.)
• A-6: The Grok reference is inspiration_only and supplies only a loose feature reference for an AI chat assistant, not a specification. (Reference directive.)
• A-7: No future-horizon requirements were stated; anything beyond the current scope is out of scope for this generation. (Source-bounded.)

12. Glossary

• Subscriber: An accepted human persona who uses the Grok-like AI assistant through a share of the shared monthly 200 subscriber seats.
• Allocation Owner: An accepted human persona who configures and manages the monthly distribution of the shared 200 subscriber seats across subscribers.
• Shared monthly pool: The finite pool of 200 subscriber seats that is shared and distributed every month.
• Allocation: A subscriber's configured share of the monthly 200.
• Allocation spine: The persistent 3px full-width luminous bar pinned to the top of every authenticated page showing the shared 200 for the current cycle draining in real time.
• Allocation gauge: A radial arc drawn in 1px cyan stroke with a single glowing head where the current share ends, used on Subscribers and Allocations rows.
• Cycle: The monthly period over which the shared 200 is distributed and consumed.
• Grok-like: A loose feature reference for an AI chat assistant where users send prompts and receive conversational responses; not a specification.