frgd-v1

byKhanya Vikilahle

**AI Prompt: FRGD — Identity Operating System** FRGD is an AI-assisted Identity Operating System designed to help people become the person they aspire to be. Its core purpose is to turn personal goals and desired identity traits into realistic, structured daily actions. FRGD considers a user's goals, traits, lifestyle, available time, obstacles, and behavioural history to create personalised plans. Its adaptation system is intended to respond to changing daily circumstances while keeping the user's long-term direction in focus. Unlike a conventional habit tracker or productivity app, FRGD aims to reduce decision fatigue, help users follow through on their intentions, and learn from their actual behaviour over time. Its guiding principle is: **“Become who you’ve said you’d be.”**

LandingIdentity ProfilePlanLoginTodaySign Up
Landing

Comments (0)

No comments yet. Be the first!

System Requirements

System Requirements Document for frgd-v1

1. Introduction

FRGD is an AI-assisted Identity Operating System designed to help people become the person they aspire to be. Its core purpose is to turn personal goals and desired identity traits into realistic, structured daily actions. FRGD considers a user's goals, traits, lifestyle, available time, obstacles, and behavioural history to create personalised plans, and its adaptation system responds to changing daily circumstances while keeping the user's long-term direction in focus.

Unlike a conventional habit tracker or productivity app, FRGD aims to reduce decision fatigue, help users follow through on their intentions, and learn from their actual behaviour over time. Its guiding principle is: "Become who you've said you'd be."

The audience is adults undertaking personal, long-horizon self-work who want to close the gap between intention and follow-through. The product is delivered as a first-party web application with application-owned identity, a durable personalised plan, and a daily action surface that records actual behaviour so the system can learn over time. The visual direction is dark and futuristic: near-black surfaces, high-contrast accents, subtle depth and glow, dark-only with no light mode toggle.

Page 1 of 31

2. System Overview

FRGD is a custom-UI web application backed by a first-party service that owns identity, profile, plan, and behavioural history. Two accepted human personas use it: the Identity Builder, who defines the desired identity traits and goals and receives a personalised plan, and the Daily Practitioner, who executes the plan on a given day, reports what actually happened, and notes changed circumstances so the plan can adapt.

Current accepted behaviour:

Page 2 of 31
  • Anonymous visitors learn what FRGD does on Landing and reach Sign Up via the "Build your identity plan" CTA, or Login for returning users.
  • A person self-enrolls on Sign Up and returns through verification on Login to reach their durable profile, plan, and behavioural history.
  • A signed-in user captures desired identity traits, personal goals, lifestyle, available time, and obstacles on Identity Profile, and can add, edit, and remove individual entries later.
  • Plan generation is available only once the required profile inputs are captured; the user requests generation or regeneration from the current profile.
  • Plan presents long-horizon direction in a narrow left rail and the adaptable week in the wider right column, showing when the plan was last adapted and what changed.
  • Today presents the current day's structured actions along a time spine, each with a category chip and exactly one primary control, and lets the user note changed circumstances for the day.
  • The adaptation system responds to changing daily circumstances while keeping long-term direction in focus, and the system learns from actual behaviour over time.
  • All six pages are rendered in the dark futuristic theme while keeping their existing layout and content structure intact; dashboard-style pages keep their current information hierarchy.

Narrow exclusions: FRGD is not a conventional habit tracker or productivity app; it does not present gamified streaks, confetti-style reward mechanics, or dense data-table admin surfaces. These are presentation and positioning boundaries, not prohibitions on recording behaviour or showing progress.

Page 3 of 31

2a. Product Interpretation and Delivery Boundary

FRGD is delivered as a first-party application. Identity is application-owned and self-service: a person establishes access through enrollment on Sign Up and returns through verification on Login, because the durable identity profile, personalised plan, and behavioural history must remain bound to the correct person and be resumable across sessions. Landing, Sign Up, and Login are anonymously reachable; Identity Profile, Plan, and Today require a verified session. Enrollment and returning verification are the only access interactions — no adjacent account-management capabilities (password reset flows, social sign-in, role administration) are in scope.

The current horizon covers the full loop of defining an identity, receiving a personalised plan, executing a day's actions, recording what actually happened, and having the plan adapt. The dark futuristic visual direction applies to all six pages as a current commitment. No future-horizon capability set is established by the source; all accepted requirements are current.

2b. Source Content Inventory

Not applicable — no reference directive declares a content_source.

2c. Page Content and Component Coverage

Page 4 of 31

Landing

  • Information/state: Anonymous first impression. States that FRGD is an AI-assisted Identity Operating System that turns personal goals and desired identity traits into realistic, structured daily actions, and carries the guiding principle "Become who you've said you'd be." Presents the gallery-room sequence — hero room, principle room, how-it-works room, plan-preview room — rendered in the dark futuristic theme with near-black surfaces, high-contrast accents, and subtle depth and glow.
  • Primary action: "Build your identity plan" — a solid high-contrast accent capsule CTA leading to Sign Up.
  • Supporting actions: Navigate to Login for returning users; scroll through the rooms.
  • Domain entities: Guiding principle statement; sample day preview (illustrative only, not user data).
  • Component responsibilities: Oversized three-line principle headline with the word "said" underlined in the accent underline stroke and "be." dropped in the structural primary colour; one sentence of body copy; tall portrait photographic panel overlapped by a small surface card with tabular numerals; full-width hairline rule with uppercase captions "TRAITS → PLAN → DAY"; unequal-panel how-it-works room; plan-preview room laid out like a museum label. Layout and content structure remain as established; only the theme is refreshed.
  • States: Loading — panels reveal on viewport entry over 400–600ms. Empty — not applicable (static marketing content). Success — CTA navigates to Sign Up. Error — not applicable. Recovery — reduced motion replaces reveals with instant state.
Page 5 of 31

Sign Up

  • Information/state: Anonymous self-service enrollment form for a person beginning their identity profile and durable plan, in the dark futuristic theme.
  • Primary action: Create the account and proceed to Identity Profile.
  • Supporting actions: Navigate to Login if already enrolled.
  • Domain entities: Account credential and identity of the enrolling person.
  • Component responsibilities: Short panel-based form in the sequential capsule-chip style, not a dense form wall; inline validation messaging; submit control. Layout and content structure remain as established.
  • States: Loading — submit disabled with progress indication. Empty — blank fields with labels. Success — session established, redirect to Identity Profile. Error — inline field-level and form-level messages for invalid or already-used credentials, with the form preserved for correction. Recovery — user corrects and resubmits, or switches to Login.
Page 6 of 31

Login

  • Information/state: Anonymous returning verification for a person reaching their durable identity profile, plan, and daily action history, in the dark futuristic theme.
  • Primary action: Verify and enter the application.
  • Supporting actions: Navigate to Sign Up if not yet enrolled.
  • Domain entities: Account credential and identity of the returning person.
  • Component responsibilities: Compact credential form; inline error region; submit control. Layout and content structure remain as established.
  • States: Loading — submit disabled with progress indication. Empty — blank fields. Success — session established, redirect to Today. Error — inline message for unrecognised or incorrect credentials, form preserved. Recovery — retry, or switch to Sign Up.
Page 7 of 31

Identity Profile

  • Information/state: The signed-in owner's captured desired identity traits, personal goals, lifestyle, available time, and obstacles — the basis of the personalised plan. Shows what has been captured and what is still missing before a plan can be generated. Rendered in the dark futuristic theme with its existing information hierarchy intact.
  • Primary action: Save the captured profile and request plan generation.
  • Supporting actions: Add, edit, and remove individual traits, goals, obstacles, and availability entries; revisit and revise the profile later.
  • Domain entities: Identity trait; goal; lifestyle description; available time; obstacle.
  • Component responsibilities: Sequential form of capsule chips and short panels; category chips coded by trait, goal, and obstacle; per-section short panels; save and generate controls; completeness indication for the inputs required before generation. Layout and content structure remain as established.
  • States: Loading — existing profile fetched with panel placeholders. Empty — first-use guidance prompting the person to begin with traits and goals. Success — saved confirmation and handoff to Plan generation. Error — inline message if saving or generation fails, with entered content preserved. Recovery — retry save or generation without re-entering data.
Page 8 of 31

Plan

  • Information/state: The personalised plan of structured daily actions generated from the profile and behavioural history, with long-horizon direction pinned in a narrow left rail and the adaptable week in the wider right column. Shows when the plan was last adapted and what changed. Rendered in the dark futuristic theme with its existing information hierarchy intact.
  • Primary action: Generate or regenerate the plan from the current profile.
  • Supporting actions: Review the long-horizon direction; review the adaptable week's structured actions; trigger adaptation to changed circumstances; open Today.
  • Domain entities: Long-horizon direction; structured daily action; adaptation event.
  • Component responsibilities: Narrow left rail with a vertical hairline rule holding the long-horizon direction; wider right column holding the adaptable week; generation and adaptation controls; adaptation crossfade region. Layout and content structure remain as established.
  • States: Loading — generation in progress with panel placeholders. Empty — no plan yet, prompting generation from the profile. Success — plan rendered; adaptation crossfades rows over 600ms. Error — generation or adaptation failure message with the previous plan retained. Recovery — retry generation or adaptation; reduced motion swaps content instantly.
Page 9 of 31

Today

  • Information/state: The current day's structured actions presented as museum labels along a tabular-numeral time spine, each with a category chip and exactly one high-contrast accent primary control. Reflects recorded actual behaviour for the day. Rendered in the dark futuristic theme with its existing information hierarchy intact.
  • Primary action: Record what actually happened for the current action.
  • Supporting actions: Note changed circumstances for the day so the plan can adapt; move through the day's actions.
  • Domain entities: Structured daily action; behavioural record; changed-circumstance note.
  • Component responsibilities: Single vertical column with left time spine; wide action panels; category chips; one primary control per action; circumstance-note entry; adaptation crossfade region. Layout and content structure remain as established.
  • States: Loading — day's actions fetched with panel placeholders. Empty — no actions for the day, with a route to Plan. Success — recorded behaviour reflected on the action and available to the learning loop. Error — inline message if recording or adaptation fails, with the action state preserved. Recovery — retry recording; reduced motion swaps adapted content instantly.
Page 10 of 31

3. Functional Requirements

FR-1 — Identity Operating System purpose (explicit) As an Identity Builder, I should have FRGD turn my personal goals and desired identity traits into realistic, structured daily actions, so that my aspirations become concrete daily work. Lifecycle: initiator — Identity Builder; input — goals and desired identity traits; observable result — a structured set of daily actions derived from them; access — verified session; failure/recovery — if no plan can be produced, the profile is preserved and generation can be retried; continuation — the resulting actions appear on Plan and Today. Acceptance: given captured goals and traits, the system produces structured daily actions traceable to them.

FR-2 — Personalisation inputs (explicit) As an Identity Builder, I should have the system consider my goals, traits, lifestyle, available time, obstacles, and behavioural history when creating my personalised plan, so that the plan fits my actual life rather than an idealised one. Lifecycle: initiator — Identity Builder supplying profile inputs; participant — the system consuming recorded behavioural history; observable result — a plan whose actions reflect the supplied inputs; access — verified session; failure/recovery — missing inputs are surfaced on Identity Profile before generation; continuation — the plan can be regenerated as inputs change. Acceptance: the generated plan demonstrably reflects each supplied input category, including behavioural history once it exists.

Page 11 of 31

FR-3 — Adaptation to changing circumstances (explicit) As a Daily Practitioner, I should have the adaptation system respond to my changing daily circumstances while keeping my long-term direction in focus, so that a disrupted day does not derail the longer arc. Lifecycle: initiator — Daily Practitioner noting changed circumstances; participant — the system reordering and adapting the day's actions; observable result — an adapted set of actions with the long-horizon direction unchanged; access — verified session; failure/recovery — if adaptation fails, the prior actions remain and the note is preserved for retry; continuation — the adapted actions are visible on Today and Plan. Acceptance: after a circumstance is noted, the day's actions change while the long-horizon direction remains as before.

FR-4 — Reduced decision fatigue (explicit) As a Daily Practitioner, I should be presented with the day's structured actions and one clear primary action per moment, so that I do not have to re-decide what to do. Lifecycle: initiator — Daily Practitioner opening Today; observable result — the day's actions presented in order with exactly one primary control each; access — verified session; failure/recovery — if the day cannot be loaded, an error with retry is shown; continuation — the practitioner acts on the presented action. Acceptance: each action panel carries exactly one primary control and the day's order is presented without requiring the user to choose among competing options.

Page 12 of 31

FR-5 — Follow-through on intentions (explicit) As a Daily Practitioner, I should be able to record what actually happened against each of the day's structured actions, so that I follow through on my intentions and the record is truthful. Lifecycle: initiator — Daily Practitioner recording an outcome; observable result — the action reflects the recorded behaviour; access — verified session; failure/recovery — if recording fails, the action's prior state is preserved and the record can be retried; continuation — the record feeds the learning loop and the next day's plan. Acceptance: a recorded outcome is persisted and visible on the action it belongs to.

FR-6 — Learning from actual behaviour over time (explicit) As an Identity Builder, I should have the system learn from my actual behaviour over time, so that my plan becomes better matched to what I really do. Lifecycle: initiator — accumulated behavioural records from Daily Practitioner activity; observable result — subsequent plan generation and adaptation reflect that history; access — verified session; failure/recovery — if history is unavailable, generation proceeds from profile inputs and states that history was not used; continuation — history continues to accumulate. Acceptance: behavioural history is an input to plan generation and adaptation, and its use is observable in the resulting plan.

Page 13 of 31

FR-7 — Self-service enrollment (required_inference) As a prospective user, I should be able to enroll myself on Sign Up, so that I can begin building my identity profile and durable plan without waiting on anyone else. Lifecycle: initiator — prospective user; observable result — an established session bound to that person; access — anonymous entry on Sign Up; failure/recovery — invalid or already-used credentials produce inline errors with the form preserved; continuation — redirect to Identity Profile. Acceptance: a completed valid enrollment establishes a session and reaches Identity Profile.

FR-8 — Returning verification (required_inference) As a returning user, I should verify on Login to reach my durable profile, plan, and behavioural history, so that my personal state remains mine and resumable. Lifecycle: initiator — returning user; observable result — a verified session reaching durable state; access — anonymous entry on Login; failure/recovery — unrecognised or incorrect credentials produce an inline error with the form preserved; continuation — redirect to Today. Acceptance: valid verification reaches the person's own profile, plan, and history; invalid verification does not.

Page 14 of 31

FR-9 — Capture of identity inputs before generation (required_inference) As an Identity Builder, I should capture my identity traits, goals, lifestyle, available time, and obstacles on Identity Profile before a plan is generated, so that generation has the inputs it requires. Lifecycle: initiator — Identity Builder; observable result — a saved profile with the required inputs; access — verified session; failure/recovery — save failure preserves entered content and allows retry; continuation — plan generation is requested from the saved profile. Acceptance: generation is available only once the required inputs are captured, and each captured input is editable afterwards.

FR-10 — AI-generated personalised plan before daily actions (required_inference) As an Identity Builder, I should receive an AI-generated personalised plan before daily actions are presented, so that Today always reflects a plan built from my profile and history. Lifecycle: initiator — Identity Builder requesting generation; participant — the AI generation service; observable result — a plan of structured daily actions on Plan; access — verified session; failure/recovery — generation failure shows an error and retains the profile and any prior plan; continuation — the plan is available on Plan and drives Today. Acceptance: Today presents actions only from a generated plan; without a plan, Today routes the user to Plan.

Page 15 of 31

FR-11 — Dark futuristic theme across all pages (explicit) As an Identity Builder or Daily Practitioner, I should see every page — Landing, Sign Up, Login, Identity Profile, Plan, and Today — rendered in a dark futuristic theme with near-black surfaces, high-contrast accents, and subtle depth and glow, so that the product feels coherent and current. Lifecycle: initiator — any visitor or signed-in user opening any of the six pages; observable result — the page renders in the dark futuristic theme; access — theme applies on anonymous and verified pages alike; failure/recovery — not applicable to a static presentation commitment; continuation — the theme persists across navigation. Acceptance: all six pages render dark-only with no light mode toggle, and existing layout and content structure remain intact.

FR-12 — Preserved information hierarchy (explicit) As an Identity Builder or Daily Practitioner, I should find dashboard-style pages keeping their current information hierarchy after the theme refresh, so that the dark theme does not disrupt how I read my profile, plan, or day. Lifecycle: initiator — signed-in user opening Identity Profile, Plan, or Today; observable result — the same information hierarchy as before the theme refresh; access — verified session; failure/recovery — not applicable to a presentation commitment; continuation — the hierarchy holds across revisits. Acceptance: Identity Profile, Plan, and Today retain their established information hierarchy under the dark theme.

4. User Personas

Page 16 of 31

Identity Builder

Product context: The Identity Builder is the person who defines the identity traits and personal goals they aspire to and receives a personalised plan built from those traits, their lifestyle, available time, and obstacles. They hold the long-horizon view: the direction the plan must keep in focus even as daily circumstances change.

Primary goal: To close the gap between who they have said they would be and who they actually are, by turning aspiration into a realistic, structured plan they can follow.

Distinct accepted responsibilities: Capturing desired identity traits, personal goals, lifestyle, available time, and obstacles on Identity Profile; requesting and reviewing the personalised plan on Plan; keeping the long-horizon direction intact while the adaptable week changes; relying on the system learning from actual behaviour over time to improve the plan; regenerating the plan as their profile or accumulated behavioural history changes.

Relevant inputs and decisions: What identity they are building toward; which goals matter; how much time they realistically have; which obstacles they face; whether the generated plan is faithful to their direction; when to regenerate after their profile changes.

Interactions with other accepted participants: The Identity Builder supplies the inputs the Daily Practitioner's day is built from, and receives the benefit of the behavioural history the Daily Practitioner records. The AI generation service is the non-persona participant that produces the plan from these inputs.

Observable success: A saved profile that reflects their stated identity and constraints, and a plan whose long-horizon direction they recognise as their own while its daily actions fit their real life.

Page 17 of 31

Daily Practitioner

Product context: The Daily Practitioner is the person executing the plan on a given day: reviewing the day's structured actions, reporting what actually happened, and noting changed circumstances so the plan can adapt. Their recurring follow-through is what the system learns from.

Primary goal: To complete the day's intended actions without re-deciding what to do, and to have the plan respond when the day does not go as planned.

Distinct accepted responsibilities: Opening Today and reading the day's actions in order; acting on the single primary control each action presents; recording what actually happened; noting changed circumstances so the adaptation system can respond while long-term direction stays in focus.

Relevant inputs and decisions: Whether each action was done as intended; what changed in the day; whether to note a circumstance rather than abandon the day.

Interactions with other accepted participants: The Daily Practitioner works from the plan the Identity Builder's inputs produced, and their recorded behaviour becomes the history the Identity Builder's future plans learn from. The adaptation system is the non-persona participant that reorders the day in response.

Observable success: A day whose actions were presented without decision fatigue, whose outcomes were truthfully recorded, and whose adapted remainder still points at the same long-term direction.

5. Core User Flows

Page 18 of 31

Flow A — First-time enrollment and identity capture (Identity Builder)

  1. The visitor arrives anonymously on Landing and reads that FRGD turns personal goals and desired identity traits into realistic, structured daily actions, with the guiding principle "Become who you've said you'd be," presented in the dark futuristic theme.
  2. The visitor selects the high-contrast accent capsule CTA "Build your identity plan" and lands on Sign Up.
  3. On Sign Up, the visitor enters credentials and submits. On success a session is established and they are taken to Identity Profile. On failure, inline errors appear, the form is preserved, and they correct and resubmit.
  4. On Identity Profile, the Identity Builder adds desired identity traits as capsule chips, then personal goals, then a short lifestyle description, available time, and obstacles, each in its own short panel.
  5. The Identity Builder saves the profile. If saving fails, the entered content is preserved and they retry.
  6. With the required inputs captured, the Identity Builder requests plan generation and is handed to Plan.
Page 19 of 31

Flow B — Plan generation and review (Identity Builder)

  1. On Plan, the Identity Builder sees the long-horizon direction in the narrow left rail and the adaptable week in the wider right column.
  2. The Identity Builder triggers generation. While the AI generation service works, panel placeholders show progress.
  3. On success, the plan renders as structured daily actions traceable to the captured traits, goals, lifestyle, available time, obstacles, and any behavioural history. On failure, an error is shown, the profile and any prior plan are retained, and generation can be retried.
  4. The Identity Builder reviews whether the long-horizon direction matches what they said they would become, and whether the week's actions are realistic.
  5. If the profile has changed, the Identity Builder returns to Identity Profile, revises the relevant chips or panels, saves, and regenerates on Plan.
  6. The Identity Builder continues to Today to begin executing the plan.
Page 20 of 31

Flow C — Executing and recording a day (Daily Practitioner)

  1. The Daily Practitioner opens Today and sees the day's actions as museum labels along a tabular-numeral time spine, each with a category chip and exactly one high-contrast accent primary control.
  2. They act on the first action's primary control and record what actually happened. If recording fails, the action's prior state is preserved and they retry.
  3. They move down the spine through the remaining actions, recording each outcome. The day's order is presented for them, so no re-deciding is required.
  4. Each recorded outcome is persisted against its action and becomes part of the behavioural history the system learns from.
  5. If the day has no actions, an empty state routes them to Plan.

Flow D — Adapting to a changed day (Daily Practitioner)

  1. Partway through the day, circumstances change. On Today, the Daily Practitioner notes the changed circumstance against the day.
  2. The adaptation system responds: the day's actions reorder and adjust, crossfading over 600ms, while the long-horizon direction stays as it was.
  3. The Daily Practitioner sees the adapted actions and continues with the new first action's single primary control.
  4. If adaptation fails, the prior actions remain, the note is preserved, and adaptation can be retried. With reduced motion, the adapted content swaps instantly.
  5. The adapted outcomes are recorded as in Flow C and feed the same behavioural history.
Page 21 of 31

Flow E — Returning to durable state (Identity Builder / Daily Practitioner)

  1. A returning person opens Login anonymously and enters their credentials.
  2. On valid verification, a session is established and they reach Today, with their durable profile, plan, and behavioural history intact.
  3. On invalid verification, an inline error appears, the form is preserved, and they retry or switch to Sign Up.
  4. From Today they can move to Plan to review the long-horizon direction or to Identity Profile to revise inputs.

Flow F — Learning over time (Identity Builder)

  1. After a period of recorded behaviour, the Identity Builder opens Plan.
  2. They regenerate or trigger adaptation. The AI generation service now consumes the accumulated behavioural history alongside the profile inputs.
  3. The resulting plan reflects what the person actually does, not only what they intended. If history is unavailable, generation proceeds from profile inputs and states that history was not used.
  4. The Identity Builder reviews the result against the unchanged long-horizon direction and continues to Today.
Page 22 of 31

Flow G — Experiencing the dark futuristic theme (any visitor or signed-in user)

  1. A visitor opens Landing and sees the guiding principle hero, gallery rooms, and CTA rendered on near-black surfaces with high-contrast accents and subtle depth and glow.
  2. They move to Sign Up or Login and find the same dark theme with the established form layout and content structure intact.
  3. After verification, they open Identity Profile, Plan, and Today and find each page dark-themed with its current information hierarchy preserved.
  4. No light mode toggle is offered anywhere; the dark theme is the only presentation.
Page 23 of 31

6. Visuals Colors and Theme

Muse and headline: Charles & Ray Eames — Warm modernism for becoming who you said you'd be. Honest materials, joy inside order, nothing decorative that is not also useful. The user's explicit refinement — dark and futuristic — governs the surface treatment: near-black grounds, high-contrast accents, subtle depth and glow, dark-only with no light mode toggle. The Eames warmth survives in the typography, the gallery-room rhythm, the unequal panels, and the offset-card shadow, now rendered as luminous cards on a dark field.

Mode: Dark only. No light mode toggle.

Colour tokens by role:

RoleHexUse
Background (field)#0E0D0BNear-black warm ground
Surface (panel)#1A1815Raised panel laid on the field
Surface elevated#242019Hovered or active panel
Text#F2EBDDBody and heading text on #0E0D0B (passes AA)
Text muted#A99C86Secondary metadata, captions
Primary (structural)#6E9C93Luminous teal — headers, active states, the plan's spine
Accent (hot)#FF6A4DBright tomato — only the one action that matters today, emphasis rules, the CTA
Mustard#E8B84BSmall coded category chips (traits, goals, obstacles), progress marks, the "said" underline
Walnut rule#6B4A2FHairline rules and tabular numerals
Glow#6E9C93 at 18%Subtle depth and glow behind active panels and the hero

Mustard and teal-light never appear as large fills. No indigo, no blue-on-white, no gradient blobs, no glassmorphism.

Page 24 of 31

Typography:

  • Headings: Jost, 500–600 weight, tracking -0.02em, sentence case, generous optical size. The guiding principle line is set at 700 with a mustard underline stroke.
  • Body: Literata, 17px at 1.65 line-height, reading measure capped at 62ch.
  • Labels and metadata: Jost 600 uppercase at 11–12px with +0.14em tracking, like exhibition captions.
  • Scale, 1.333 modular: 56 / 40 / 30 / 22 / 17 / 15.
  • Display clamp(40px, 8vw, 112px) for the hero principle; H1 clamp(32px, 5vw, 56px); H2 clamp(26px, 3.4vw, 40px); captions 13px Jost.
  • Inter, Roboto, Poppins, and system-ui are excluded for headings and body.

Shape language: Organic-modern — soft rounded panels with 14–20px radii, capsule chips for traits and categories, thin 1px walnut rules as panel separators. Modular panels of unequal size arranged like an exhibition wall: a tall portrait panel beside two stacked square panels. Flat fills with honest edges; one subtle 2px offset shadow in near-black at 40% opacity plus a faint teal glow, suggesting a luminous card laid on a dark field. No blobs, no glossy gradients.

Spacing rhythm: 8-pt scale; 24px gutters at 375px, 64–96px at 1280px.

Imagery style: Warm, honest, material — close-cropped photography of hands, notebooks, a morning cup, walking shoes by a door, a desk in natural light; softly lit, film-grain, mid-century colour grading in walnut, cream, and mustard, graded to sit on the dark field. Playful geometric Eames dot-and-line pattern used sparingly as a section opener band. Small hand-drawn accent marks (an arrow, a check, a circled date) as UI flourishes. No stock corporate people, no 3D blobs, no abstract gradient art.

Page 25 of 31

Readability constraint: 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 element covering any part of them. Imagery and decoration may crop, bleed, rotate, or overlap freely as long as they cover no readable text or control.

7. Signature Design Concept

The exhibition wall of a life being built — after dark.

The public entry is a full-bleed near-black field split asymmetrically. The left seven columns hold the guiding principle set enormous in Jost 700 — "Become who you've said you'd be." — stacked across three lines, with the word said underlined in mustard and be. dropped alone onto its own line in luminous teal. Beneath it sits one sentence of Literata body copy and a solid bright-tomato capsule CTA, Build your identity plan. The right five columns are a tall portrait photographic panel: a hand writing in a notebook in natural morning light, grain visible, cropped so the notebook runs off the bottom edge, its warm tones glowing against the dark. Overlapping its lower-left corner is a small raised surface card carrying a real sample day — 7:10 Walk 20 min · 12:30 One hard thing · 21:00 Reflect — each row a museum-label line with walnut tabular numerals. A thin walnut rule runs the full viewport width beneath the hero, carrying three uppercase Jost captions: TRAITS → PLAN → DAY.

Below, the page continues as gallery rooms rather than a card grid: a principle room, a how-it-works room built as three unequal panels (one tall portrait beside two stacked squares), and a plan-preview room where a real day's actions are laid out like a museum label. Every panel carries the offset shadow and faint teal glow, so the interface reads as luminous printed cards laid on a dark field. The headline is the hero, not the image. No centred stack, no gradient, no floating glass.

Page 26 of 31

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

  • Focal subject: The oversized three-line guiding principle in Jost 700, with the mustard-underlined "said" and the luminous-teal "be." on its own line, paired with the tall portrait photographic panel of a hand writing in a notebook glowing against the near-black field.
  • Input → transformation → outcome thesis: As the visitor scrolls, each gallery room enters the viewport and its panels reveal over 400–600ms ease-out — the principle room assembling the three-line statement, the how-it-works room settling its unequal panels into place, the plan-preview room laying down a day's actions as museum labels. The outcome is a visitor who has read the principle, understood TRAITS → PLAN → DAY, and reached the bright-tomato CTA.
  • Motion vocabulary: Film-like and gentle. 400–600ms ease-out reveals on viewport entry; a slow 600ms crossfade when the plan adapts and a day's actions reorder; mustard progress marks drawing in over 500ms; hover on panels lifts them 2px with the offset shadow deepening and the teal glow brightening — quiet, physical, never bouncy.
  • Composed first frame: The near-black field at rest, the three-line principle fully legible on the left, the portrait panel and its overlapping sample-day card on the right, the walnut rule and TRAITS → PLAN → DAY captions beneath. Nothing animates before the first reveal.
  • Reduced-motion state: Reveals are replaced with instant state and the adaptation crossfade with a simple content swap; the hero and all rooms render fully composed and static, with every item readable.
Page 27 of 31

9. Non-Functional Requirements

  • NFR-1 — Durable state (explicit via planning scope): The identity profile, personalised plan, behavioural history, and adaptation events persist across sessions and are bound to the correct person. Rationale: the product's learning-over-time intent and the resumable daily loop require durable, person-bound state.
  • NFR-2 — AI-assisted generation (explicit): Plan generation and adaptation are AI-assisted and consume the profile inputs and behavioural history. Rationale: the source states the system considers these inputs to create personalised plans.
  • NFR-3 — Application-owned identity (explicit): Access to Identity Profile, Plan, and Today requires a verified session; Landing, Sign Up, and Login are anonymously reachable. Enrollment and returning verification are the only access interactions; no password reset, social sign-in, or role administration is in scope. Rationale: durable person-bound state must not be reachable by another person, and a protected destination cannot own the interaction that establishes access to itself.
  • NFR-4 — Readability at every viewport (explicit): Readable text and controls remain whole and uncovered at 375px, 768px, and 1280px, wrapping or scaling to fit. Rationale: stated design constraint.
  • NFR-5 — Reduced motion (explicit): With prefers-reduced-motion, reveals become instant state and the adaptation crossfade becomes a content swap, with a usable static arrangement. Rationale: stated design constraint.
  • NFR-6 — Calm, single-action presentation (explicit): Each action panel presents exactly one primary control, and no gamified streaks, confetti, or bouncy spring animations appear. Rationale: the product's stated aim to reduce decision fatigue and its explicit presentation exclusions.
  • NFR-7 — Accessible contrast (explicit): Body text #F2EBDD on #0E0D0B passes AA. Rationale: stated design constraint.
Page 28 of 31
  • NFR-8 — Dark-only theme (explicit): All six pages render in the dark futuristic theme with near-black surfaces, high-contrast accents, and subtle depth and glow; no light mode toggle is offered. Rationale: explicit user refinement.
  • NFR-9 — Preserved layout and hierarchy (explicit): The theme refresh keeps existing layout and content structure intact, and dashboard-style pages keep their current information hierarchy. Rationale: explicit user refinement.

10. Tech Stack

  • Frontend: React web application with custom UI, implementing the Jost/Literata typography, the dark futuristic palette, and the gallery-room layout.
  • Backend: Python / FastAPI service owning identity, profile, plan, behavioural history, and adaptation, extended in place rather than split into separate services.
  • AI generation: Server-side AI-assisted plan generation and adaptation invoked by the backend.
  • Storage: Durable persistent storage for accounts, profiles, plans, behavioural records, and adaptation events.
  • Deployment: Docker / docker-compose for the application and its storage; Kubernetes only if deployment requires it.
Page 29 of 31

11. Assumptions and Constraints

  • A-1 (explicit): Identity is application-owned and self-service; enrollment and returning verification are the only access interactions, and no adjacent account-management capabilities (password reset flows, social sign-in, role administration) are in scope.
  • A-2 (explicit): The two accepted personas may be the same human at different moments; the product does not enforce differentiated permissions or role-based visibility over shared state.
  • A-3 (explicit): The sample day shown on Landing is illustrative presentation, not user data.
  • A-4 (explicit): FRGD is positioned against conventional habit trackers and productivity apps; it does not adopt gamified streaks, confetti, or dense data-table admin surfaces.
  • A-5 (explicit): The guiding principle "Become who you've said you'd be." is a current product commitment and appears as the hero statement.
  • A-6 (explicit): The visual direction is dark and futuristic — near-black surfaces, high-contrast accents, subtle depth and glow, dark-only with no light mode toggle — and this refinement overrides the earlier light cream palette while preserving the Eames typography, shape language, layout rhythm, motion tempo, and imagery style.
  • A-7 (explicit): All six pages (Landing, Sign Up, Login, Identity Profile, Plan, Today) are refreshed to the dark futuristic theme while keeping existing layout and content structure intact; dashboard-style pages keep their current information hierarchy.
  • A-8 (explicit): No future-horizon capability set is established by the source; all accepted requirements are current.
Page 30 of 31

12. Glossary

  • Identity Operating System — FRGD's framing of itself: a system that turns goals and desired identity traits into structured daily actions and adapts them over time.
  • Identity trait — A quality of the person the user aspires to become, captured on Identity Profile.
  • Long-horizon direction — The enduring aim the plan keeps in focus, pinned in the Plan page's left rail, unchanged by daily adaptation.
  • Adaptable week — The near-term set of structured daily actions in the Plan page's right column, which the adaptation system may reorder and adjust.
  • Structured daily action — A concrete, realistic action for a given day, derived from the profile and behavioural history.
  • Behavioural history — The accumulated record of what actually happened against structured daily actions, used as an input to future generation and adaptation.
  • Adaptation event — A recorded instance of the plan responding to changed daily circumstances.
  • Decision fatigue — The cognitive cost of repeatedly choosing what to do; FRGD reduces it by presenting one clear primary action per moment.
  • Guiding principle — "Become who you've said you'd be."
  • Dark futuristic theme — The dark-only visual direction: near-black surfaces, high-contrast accents, subtle depth and glow, with no light mode toggle.
  • Identity Builder — The accepted persona who defines identity traits and goals and receives the personalised plan.
  • Daily Practitioner — The accepted persona who executes the plan on a given day, records what happened, and notes changed circumstances.
Page 31 of 31
Landing design preview
Landing: Read guiding principle
Login: 1. Verify returning session
Login: 2. Retry credentials
Sign Up: Enroll new account
Today: Read day's actions
Today: 1. Record first outcome
Today: 2. Retry recording
Today: 1. Record remaining outcomes
Today: 2. Note changed circumstance
Today: 3. Retry adaptation
Today: 4. Continue adapted actions
Plan: Review plan for day
Today: Return to actions
Landing design preview
Landing: Read guiding principle
Login: 1. Verify returning session
Login: 2. Retry credentials
Sign Up: Enroll new account
Today: Read day's actions
Today: 1. Record first outcome
Today: 2. Retry recording
Today: 1. Record remaining outcomes
Today: 2. Note changed circumstance
Today: 3. Retry adaptation
Today: 4. Continue adapted actions
Plan: Review plan for day
Today: Return to actions