System Requirements Document for inner-hii

1. Introduction

inner-hii is a private, LLM-driven analysis instrument for a data-analyst domain owner. The product exists so that a single analyst can run the full data-analysis workflow — automating analysis tasks, generating dashboards, discovering patterns in their data, and handling all related data-analyst processes — through one LLM-based model, while the underlying data never leaks outside the permitted boundary.

The audience is technical and works alone: a Data Analyst / Domain Owner who owns a data domain and wants an assistant that performs end-to-end analysis on their own data, and a Data Privacy / Governance Reviewer who stands beside that work and verifies that no data leaves the permitted boundary at any point in automation, analysis, dashboard generation, or pattern discovery.

The product is delivered as a first-party application with custom UI, application-owned identity, and backend execution for private data handling, automated analysis, dashboard generation, pattern discovery, and privacy verification.

2. System Overview

inner-hii is a first-party web application. An anonymous visitor first meets the product on Landing, which explains the data-analyst LLM assistant, its automation, dashboards, pattern discovery, and privacy focus. Access to private-data workflows is established through Login, a shared first-party access surface supporting self-service enrollment for independently starting users and returning verification for existing users.

Once verified, the Data Analyst / Domain Owner works across four role-restricted destinations: Data Sources (submit or connect their own data for analysis), Analysis Runs (run and revisit automated analysis tasks on submitted data), Dashboards (browse and manage dashboards generated from analyzed data), and Patterns (inspect patterns discovered in the user's data). The Data Privacy / Governance Reviewer works in Privacy Review, a role-restricted destination for verifying that data remains private throughout automation, analysis, dashboard generation, and pattern discovery.

Backend execution performs the private data handling, automated analysis, dashboard generation, pattern discovery, and privacy verification that these surfaces present. The hard constraint across all of it is that data must not leak at any point in the analysis, automation, dashboard, or pattern-discovery workflow.

Narrow exclusions. This document does not add adjacent capabilities beyond the accepted thread: no model training or fine-tuning pipeline, no third-party data marketplace, no collaboration or sharing features, no billing, and no account-management surface beyond the first-use identity establishment and returning verification needed to reach protected work.

2a. Product Interpretation and Delivery Boundary

inner-hii is a precision instrument the analyst calibrates and watches, not a chat toy. The analyst brings their own data, and the LLM-based model does the work: it automates analysis tasks, produces dashboards, and surfaces patterns, covering the related data-analyst processes end-to-end. The governance reviewer's job is separate and equally first-party: confirming, inside the product, that the data stayed private through every one of those steps.

Delivery is first-party and application-owned. The public entry (Landing) is anonymously reachable and explains the instrument. Login is the shared access boundary where a new user establishes identity for the first time and a returning user verifies identity; it is anonymously reachable itself, because a protected destination cannot own the interaction that establishes access to it. Only after identity is established do the private-data destinations become available: Data Sources, Analysis Runs, Dashboards, and Patterns for the Data Analyst / Domain Owner, and Privacy Review for the Data Privacy / Governance Reviewer. Role-aware authorization distinguishes the analyst's work from the reviewer's oversight; it does not create any capability beyond those accepted destinations.

Everything in this document is current. No future-horizon requirements were accepted in the authoritative thread, so none are carried.

2b. Source Content Inventory

No reference directive in this project declares content_source, so no source content inventory applies.

2c. Page Content and Component Coverage

Landing

• Information / state: Anonymous public entry. Explains the data-analyst LLM assistant and its four working promises — automation of analysis tasks, generated dashboards, pattern discovery from the data, and operation without leakage of data. Presents the instrument as a sealed, private bench.
• Primary action: Enter the product through the champagne-outlined CTA, which leads to Login.
• Supporting actions: Read the ruled sub-row of aligned label/value pairs beneath the headline; follow the privacy statement into the sealed-bezel framing of the product.
• Domain entities: The product itself; the analyst's private data (referenced, never shown); the no-leak guarantee.
• Component responsibilities: Hero instrument face (820px circular gauge, three concentric hairline bezel rings, needle resting at 78%, figure set at 112px condensed inside the dial); oversized stacked flush-left headline; ruled sub-row of three label/value pairs; champagne-outlined CTA; faint topographic line field bleeding off the top-right edge behind the gauge.
• States: Loading — needle sweeps 0→78% over 1.6s with physical ease-out and 0.3s settle. Empty — not applicable; the entry is static content. Success — needle settles at 78%, headline and ruled row fully readable. Error — if the CTA target is unreachable, the CTA remains visible and the user can retry. Recovery — reduced-motion renders the needle at its final value and all figures statically.

Login

• Information / state: Shared first-party access surface, anonymously reachable. Carries two modes: first-use identity establishment (self-service enrollment) and returning verification.
• Primary action: Establish identity for the first time, or verify identity as a returning user.
• Supporting actions: Switch between the enrollment and returning-verification modes; correct a rejected entry.
• Domain entities: User identity; the role binding that determines whether the user lands in the analyst's working set or the reviewer's oversight set.
• Component responsibilities: Ruled credential fields as label/value pairs with hairline rules; ruled-rectangle submit control with 1px champagne border and left-edge fill wipe on hover; mode toggle as the single tabular toggle permitted by the shape language; inline error rule beneath the failing field.
• States: Loading — submit control holds a ruled pending state while identity is established or verified. Empty — first visit shows the enrollment mode with empty fields. Success — identity established or verified; the user continues to their role-appropriate destination. Error — invalid or unrecognized credentials show an inline ruled error and preserve entered values. Recovery — the user can retry, or switch modes if they enrolled previously.

Data Sources

• Information / state: Role-restricted workspace for the Data Analyst / Domain Owner. Lists the data the analyst has submitted or connected for analysis, with each source's identity, submission state, and readiness for analysis.
• Primary action: Submit or connect the analyst's own data for analysis.
• Supporting actions: Review a submitted source's state; select a source as the input for an analysis run; remove or replace a source.
• Domain entities: Data source; submission/connection state; readiness for analysis; the private boundary the source stays inside.
• Component responsibilities: Ruled source rows as aligned label/value pairs with hairline rules that lift to champagne on hover; submission/connection control; per-source state readout; empty-bench prompt when no source exists yet.
• States: Loading — source rows render as ruled placeholders while the list resolves. Empty — no data submitted yet; the bench is empty and the submission control is the only prominent action. Success — the source appears as a ruled row with its state and is selectable for analysis. Error — a rejected submission shows an inline ruled error naming the source and the reason. Recovery — the analyst can resubmit or replace the source without losing previously accepted sources.

Analysis Runs

• Information / state: Role-restricted workspace for the Data Analyst / Domain Owner. Shows automated analysis tasks run against submitted data, each with its run state, the source it consumed, and its results.
• Primary action: Run an automated analysis task on submitted data.
• Supporting actions: Revisit a previous run and its results; select which submitted source a run consumes; read a run's counted figures.
• Domain entities: Analysis run; run state; consumed data source; run results; the automated analysis task definition.
• Component responsibilities: Run rows as ruled label/value pairs with tabular figures counting up over 600ms on entry; run-status pips as structural circles; run control; run detail readout; empty-state prompt when no run exists.
• States: Loading — run rows count their figures up over 600ms as they enter view. Empty — no runs yet; the run control is the primary action. Success — the run completes and its results are readable as ruled rows. Error — a failed run shows its failed state on the run row with the reason, and the consumed source remains intact. Recovery — the analyst can re-run the task against the same source.

Dashboards

• Information / state: Role-restricted destination for the Data Analyst / Domain Owner. Browses and manages dashboards generated from analyzed data, each presented as a bezel board rather than a grid of identical cards.
• Primary action: Open a generated dashboard and read its instrument face.
• Supporting actions: Browse the set of generated dashboards; manage a dashboard (retain or remove it); read the ruled readouts beside the gauge panel.
• Domain entities: Dashboard; the analysis run that produced it; gauge panel; ruled readouts; units.
• Component responsibilities: Bezel board layout — one large gauge panel spanning 7 columns beside three stacked ruled readouts at 5 columns; tabular figures with units right-aligned in muted; hairline rules that lift to champagne on hover; dashboard list as ruled rows.
• States: Loading — the gauge panel and readouts render as ruled placeholders. Empty — no dashboards generated yet; the destination explains that dashboards come from completed analysis runs. Success — the bezel board renders with its gauge and readouts fully readable. Error — a dashboard that cannot be resolved shows an inline ruled error on its list row. Recovery — the analyst can return to Analysis Runs and re-run the producing task.

Patterns

• Information / state: Role-restricted destination for the Data Analyst / Domain Owner. Presents patterns discovered in the user's data, each tied to the analysis that surfaced it.
• Primary action: Inspect a discovered pattern and its supporting figures.
• Supporting actions: Browse discovered patterns; read a pattern's ruled label/value detail; move from a pattern back to the run that produced it.
• Domain entities: Discovered pattern; the analysis run that surfaced it; supporting figures; the data source the pattern derives from.
• Component responsibilities: Pattern rows as ruled label/value pairs with tabular figures; pattern detail readout; hairline rules that lift to champagne on hover; empty-state prompt when no pattern has been discovered.
• States: Loading — pattern rows render as ruled placeholders. Empty — no patterns discovered yet; the destination explains that patterns come from completed analysis runs. Success — patterns render as ruled rows with their figures. Error — a pattern that cannot be resolved shows an inline ruled error on its row. Recovery — the analyst can return to Analysis Runs to produce the analysis that surfaces patterns.

Privacy Review

• Information / state: Role-restricted destination for the Data Privacy / Governance Reviewer. Renders as a sealed bezel: a champagne stroke traces the panel perimeter once on entry, and the panel is un-enterable — a hash-locked, read-only ring — until verification passes. Presents the verification that data remained private throughout automation, analysis, dashboard generation, and pattern discovery.
• Primary action: Verify that data remained private across the workflow.
• Supporting actions: Read the verification result and its supporting ruled evidence; observe the sealed-bezel state before verification passes.
• Domain entities: Privacy verification; the workflow stages it covers (automation, analysis, dashboard generation, pattern discovery); the no-leak result; the sealed boundary.
• Component responsibilities: Sealed bezel panel with a champagne perimeter stroke traced in 900ms on first scroll; hash-locked read-only ring state before verification; verification control; ruled evidence rows as label/value pairs; teal signal reserved exclusively for the verified no-leak state.
• States: Loading — the perimeter stroke traces the panel in 900ms on first scroll. Empty — no verification has been run; the panel is sealed and read-only. Success — verification passes and the teal signal marks the verified no-leak state. Error — verification does not pass; the panel remains sealed and the failing stage is named in a ruled row. Recovery — the reviewer can re-run verification after the analyst addresses the named stage.

3. Functional Requirements

FR-1 — LLM-based model that performs the analyst's domain tasks (explicit) As a Data Analyst / Domain Owner, I should have an LLM-based model that can perform all tasks for my data-analyst domain, so that my domain work is carried out by the model rather than by hand.

• Trigger / input: The analyst has submitted or connected their own data and initiates work in the product.
• Observable result: The model performs the requested data-analyst task and its result is presented in the product.
• Access state: Requires established identity; the working destinations are role-restricted to the Data Analyst / Domain Owner.
• Failure / recovery: If the model cannot complete a task, the failure is shown on the affected run and the analyst can retry.
• Continuation: The analyst continues into Analysis Runs, Dashboards, or Patterns with the produced result.

FR-2 — Automate data analysis tasks (explicit) As a Data Analyst / Domain Owner, I should have my data analysis tasks automated, so that recurring analysis runs without me performing each step manually.

• Trigger / input: The analyst selects a submitted data source and starts an automated analysis task.
• Observable result: The automated analysis task runs and its state and results appear on Analysis Runs.
• Access state: Role-restricted to the Data Analyst / Domain Owner.
• Failure / recovery: A failed run shows its failed state with the reason, and the consumed source remains intact so the task can be re-run.
• Continuation: Completed runs feed Dashboards and Patterns.

FR-3 — Generate dashboards (explicit) As a Data Analyst / Domain Owner, I should get dashboards generated from my analyzed data, so that I can read the results as instrument faces rather than raw output.

• Trigger / input: An analysis run completes on submitted data.
• Observable result: A dashboard is generated and appears on Dashboards as a bezel board with a gauge panel and ruled readouts.
• Access state: Role-restricted to the Data Analyst / Domain Owner.
• Failure / recovery: A dashboard that cannot be resolved shows an inline ruled error on its list row; the analyst can re-run the producing task.
• Continuation: The analyst browses and manages generated dashboards.

FR-4 — Discover patterns from the data (explicit) As a Data Analyst / Domain Owner, I should have patterns discovered from my data, so that structure in the data is surfaced without me hunting for it.

• Trigger / input: An analysis run completes on submitted data.
• Observable result: Discovered patterns appear on Patterns, each tied to the analysis that surfaced it.
• Access state: Role-restricted to the Data Analyst / Domain Owner.
• Failure / recovery: A pattern that cannot be resolved shows an inline ruled error on its row; the analyst can return to Analysis Runs to reproduce it.
• Continuation: The analyst inspects a pattern and can move back to the run that produced it.

FR-5 — Perform all related data-analyst processes (explicit) As a Data Analyst / Domain Owner, I should have all related data-analyst processes covered by the model, so that the workflow is end-to-end rather than a single isolated step.

• Trigger / input: The analyst works through their domain tasks in the product.
• Observable result: The related processes are carried out within the same workflow, with their states and results visible on the working destinations.
• Access state: Role-restricted to the Data Analyst / Domain Owner.
• Failure / recovery: A process that cannot complete surfaces its failure on the affected destination with a retry path.
• Continuation: The analyst continues to the next process in the workflow.

FR-6 — Operate without leakage of data (explicit) As a Data Analyst / Domain Owner, I should have my data handled without leakage at any point, so that my private data stays inside the permitted boundary through automation, analysis, dashboard generation, and pattern discovery.

• Trigger / input: Any submission, analysis run, dashboard generation, or pattern discovery involving the analyst's data.
• Observable result: The data remains inside the permitted boundary, and the no-leak state is verifiable in the product.
• Access state: Applies to all private-data work; the verification surface is role-restricted to the Data Privacy / Governance Reviewer.
• Failure / recovery: If a stage does not hold the boundary, that stage is named and the workflow can be corrected and re-verified.
• Continuation: Verified no-leak state is the standing condition for continued analysis work.

FR-7 — Self-service enrollment for independently starting users (required_inference) As a Data Analyst / Domain Owner, I should be able to establish my identity for the first time on my own, so that I can start using the instrument without waiting on anyone else.

• Trigger / input: An anonymous visitor chooses to enter the product from Landing and establishes identity on Login.
• Observable result: Identity is established and the user continues to their role-appropriate destination.
• Access state: Login is anonymously reachable; protected destinations remain unavailable until identity is established.
• Failure / recovery: A rejected entry shows an inline ruled error and preserves entered values so the user can retry.
• Continuation: The user proceeds into the working destinations.

FR-8 — Returning verification before accessing private data and analysis workflows (required_inference) As a Data Analyst / Domain Owner or Data Privacy / Governance Reviewer, I should verify my identity when I return, so that my private data and analysis workflows stay bound to me.

• Trigger / input: A returning user enters credentials on Login.
• Observable result: Identity is verified and the user reaches their role-appropriate destination.
• Access state: Login is anonymously reachable; private-data destinations stay unavailable until verification succeeds.
• Failure / recovery: Unrecognized credentials show an inline ruled error and the user can retry or switch modes.
• Continuation: The user resumes their work in the destination they left.

FR-9 — Role-aware authorization distinguishing analyst work from governance oversight (required_inference) As a Data Privacy / Governance Reviewer, I should have oversight access that is distinct from the analyst's working access, so that verification is performed by the role accountable for it.

• Trigger / input: A verified user reaches the product after Login.
• Observable result: The Data Analyst / Domain Owner reaches Data Sources, Analysis Runs, Dashboards, and Patterns; the Data Privacy / Governance Reviewer reaches Privacy Review.
• Access state: Role-restricted destinations resolve by the verified user's role.
• Failure / recovery: A user without the required role does not reach the restricted destination and is returned to their own working set.
• Continuation: Each role continues in its own destination set.

FR-10 — Verify that data remained private across the workflow (required_inference) As a Data Privacy / Governance Reviewer, I should verify that data remained private throughout automation, analysis, dashboard generation, and pattern discovery, so that the no-leak constraint is confirmed rather than assumed.

• Trigger / input: The reviewer opens Privacy Review and runs verification over the workflow stages.
• Observable result: The sealed bezel panel reports the verification result; the teal signal marks the verified no-leak state, and a failing stage is named in a ruled row.
• Access state: Role-restricted to the Data Privacy / Governance Reviewer; the panel is un-enterable and read-only until verification passes.
• Failure / recovery: A failing verification keeps the panel sealed, names the failing stage, and allows re-verification after the stage is corrected.
• Continuation: Verified no-leak state stands as the condition for continued analysis work.

FR-11 — Backend execution for private data handling, automated analysis, dashboards, pattern discovery, and privacy verification (required_inference) As a Data Analyst / Domain Owner, I should have the heavy work executed by the backend, so that private data is handled inside the permitted boundary rather than in the browser.

• Trigger / input: The analyst submits data, starts a run, or the reviewer runs verification.
• Observable result: The backend performs the private data handling, automated analysis, dashboard generation, pattern discovery, and privacy verification, and the resulting state appears on the corresponding destination.
• Access state: Backend execution is reached only through an established identity.
• Failure / recovery: A backend failure surfaces on the affected destination with a retry path; no partial result is presented as complete.
• Continuation: The user retries or continues with the completed result.

4. User Personas

Data Analyst / Domain Owner

Product context. This persona owns a data-analyst domain and works alone. They are technical, protective of their data, and are building their own LLM so that the full analysis workflow runs on their own bench rather than through outside services. They treat the product as a precision instrument they calibrate and watch.

Primary goal. To have an LLM-based model perform all tasks for their data-analyst domain — automating analysis tasks, generating dashboards, discovering patterns from the data, and covering all related data-analyst processes — while the underlying data never leaks.

Distinct accepted responsibilities. This persona submits or connects their own data on Data Sources; runs and revisits automated analysis tasks on Analysis Runs; browses and manages generated dashboards on Dashboards; and inspects discovered patterns on Patterns. Their work is the producing side of the workflow: they create the data, the runs, the dashboards, and the patterns.

Relevant inputs and decisions. Which data source to submit or connect; which source a run consumes; whether to re-run a failed task; which generated dashboard to retain or remove; which discovered pattern to inspect.

Interactions with other accepted participants. The analyst's work is what the Data Privacy / Governance Reviewer verifies. The analyst does not perform the verification; the reviewer does. The analyst's runs, dashboards, and patterns are the stages the reviewer checks for no-leak compliance.

Observable success. Completed analysis runs, generated dashboards readable as instrument faces, discovered patterns tied to their producing runs, and a verified no-leak state — all produced without any data leakage.

Data Privacy / Governance Reviewer

Product context. This persona stands beside the analyst's work, accountable for the explicit requirement that analysis happen without leak of data. They are not a producer of analysis; they are the oversight role that confirms the boundary held.

Primary goal. To verify that data used in the LLM workflow stayed private and was not exposed at any point.

Distinct accepted responsibilities. This persona reviews and confirms that no data leaves the permitted boundary during automation, dashboard generation, and pattern discovery, working on Privacy Review. Their work is the confirming side of the workflow: they read the sealed bezel, run verification, and read the ruled evidence.

Relevant inputs and decisions. The workflow stages under review (automation, analysis, dashboard generation, pattern discovery); whether verification passes; which stage to name when it does not.

Interactions with other accepted participants. The reviewer's verification covers the Data Analyst / Domain Owner's runs, dashboards, and patterns. When verification fails, the reviewer names the failing stage, and the analyst addresses it before re-verification.

Observable success. Verified no-leak compliance — the teal signal marking a verified no-leak state, with every covered stage confirmed to have stayed inside the permitted boundary.

5. Core User Flows

Flow 1 — First use: establish identity and reach the working set (Data Analyst / Domain Owner)

1. The analyst arrives anonymously on Landing and reads the instrument face: the gauge with its needle at 78%, the headline, and the ruled sub-row of label/value pairs.
2. The analyst activates the champagne-outlined CTA and arrives at Login.
3. On Login, the analyst uses the enrollment mode and enters their credentials in the ruled fields.
4. The analyst submits. The submit control holds a ruled pending state while identity is established.
5. Observable result: Identity is established and the analyst continues to their role-appropriate destination — Data Sources — with the analyst's working set available.
6. Failure / recovery: If the entry is rejected, an inline ruled error appears beneath the failing field and the entered values are preserved; the analyst corrects and retries, or switches to returning verification if they had enrolled previously.
7. Next step: The analyst submits their first data source (Flow 2).

Flow 2 — Submit or connect data for analysis (Data Analyst / Domain Owner)

1. From Data Sources, the analyst starts a submission or connection of their own data.
2. The analyst provides the source and confirms the submission.
3. Observable result: The source appears as a ruled row with its submission state and readiness for analysis, and becomes selectable as input for a run.
4. Failure / recovery: If the submission is rejected, an inline ruled error names the source and the reason; previously accepted sources remain intact and the analyst can resubmit or replace the source.
5. Next step: The analyst runs an automated analysis task (Flow 3).

Flow 3 — Run an automated analysis task and revisit it (Data Analyst / Domain Owner)

1. From Analysis Runs, the analyst selects a submitted source and starts an automated analysis task.
2. The run appears as a ruled row with its run-status pip and its figures counting up over 600ms as the row enters view.
3. Observable result: The run completes and its results are readable as ruled rows with tabular figures.
4. Failure / recovery: If the run fails, the run row shows its failed state with the reason, and the consumed source remains intact; the analyst re-runs the task against the same source.
5. Next step: The analyst reads the generated dashboard (Flow 4) or inspects discovered patterns (Flow 5).

Flow 4 — Read and manage a generated dashboard (Data Analyst / Domain Owner)

1. From Dashboards, the analyst opens a dashboard generated from a completed analysis run.
2. The dashboard renders as a bezel board: one large gauge panel spanning 7 columns beside three stacked ruled readouts at 5 columns, with tabular figures and units right-aligned in muted.
3. Observable result: The analyst reads the instrument face and its ruled readouts, and can retain or remove the dashboard from the list.
4. Failure / recovery: If a dashboard cannot be resolved, an inline ruled error appears on its list row; the analyst returns to Analysis Runs and re-runs the producing task.
5. Next step: The analyst continues to Patterns or back to Analysis Runs.

Flow 5 — Inspect a discovered pattern (Data Analyst / Domain Owner)

1. From Patterns, the analyst opens a pattern discovered in their data.
2. The pattern's ruled label/value detail and supporting figures are shown, tied to the analysis that surfaced it.
3. Observable result: The analyst reads the pattern and its figures, and can move back to the run that produced it.
4. Failure / recovery: If a pattern cannot be resolved, an inline ruled error appears on its row; the analyst returns to Analysis Runs to reproduce the analysis.
5. Next step: The analyst continues with further runs, dashboards, or patterns.

Flow 6 — Verify that data stayed private (Data Privacy / Governance Reviewer)

1. The reviewer verifies identity on Login and reaches Privacy Review.
2. On entry, the sealed bezel panel draws its champagne perimeter stroke in 900ms on first scroll. The panel is un-enterable — a hash-locked, read-only ring — until verification passes.
3. The reviewer runs verification over the workflow stages: automation, analysis, dashboard generation, and pattern discovery.
4. Observable result: Verification passes and the teal signal marks the verified no-leak state; the ruled evidence rows are readable.
5. Failure / recovery: If verification does not pass, the panel remains sealed and the failing stage is named in a ruled row. The reviewer's finding goes back to the analyst, who addresses that stage; the reviewer then re-runs verification.
6. Next step: Verified no-leak state stands as the condition for the analyst's continued analysis work.

Flow 7 — Returning use: resume work (Data Analyst / Domain Owner or Data Privacy / Governance Reviewer)

1. A returning user arrives at Login and uses the returning-verification mode.
2. Observable result: Identity is verified and the user reaches their role-appropriate destination — the analyst to Data Sources, Analysis Runs, Dashboards, or Patterns; the reviewer to Privacy Review.
3. Failure / recovery: Unrecognized credentials show an inline ruled error and preserve entered values; the user retries or switches modes.
4. Next step: The user resumes the work they left.

6. Visuals Colors and Theme

Muse and headline. MARQ by Garmin — luxury instrument aesthetic. The headline is the hero's own: YOUR DATA NEVER LEAVES THE BENCH. The register is sombre, exact, quietly powerful: a cockpit, not a chat toy. No consumer cheer, no SaaS pastel, no meme energy.

Mode. Dark mode only.

Colour tokens by role.

Titanium graphite dominates: #0E1114 is the plate, #171B1F the raised panels, #2A3036 the hairline rules. Text is warm brushed white #E8E4DC, never pure white. Champagne #C8A268 is the instrument metal — bezel strokes, ruled data rows, the primary CTA fill, and the needle — appearing on roughly 8% of any screen. Teal #3FA9A0 is reserved for exactly one meaning: privacy verified / no-leak states. Amber and teal never touch in the same component.

Typography. Headings: Saira Condensed, uppercase, 600 weight, tracking +0.06em, used at instrument scale — headlines are data, not prose. Display sizes clamp(40px, 9vw, 112px) with 40px at 375px; section heads clamp(22px, 3.4vw, 40px). Numbers are always tabular, set in Saira with font-variant-numeric: tabular-nums, and given the champagne colour. Body: Saira. Scale is 1.25 modular with an instrument jump: 112 / 72 / 40 / 24 / 17 / 14 / 11. Body copy 17px, line-height 1.6, max measure 62ch. Micro-labels 11px uppercase, tracking +0.14em, in muted.

Shape language. Machined, not rounded. 2px radii on panels; 1px hairline strokes at #2A3036; chamfered 45° corner cuts on primary cards via clip-path to read as bezel facets. Circles are structural: gauges, dial rings, run-status pips. Nothing soft, nothing pill-shaped except the single tabular toggle. Buttons are ruled rectangles with a 1px champagne border and no fill until hover, when the fill wipes in from the left edge in 140ms.

Spacing rhythm. A ruled instrument grid: 12 columns at 1280px with a persistent 64px left rail of vertical micro-labels (DATA / RUNS / PANELS / PRIVACY) that rotates 90° and tracks the active section. Dashboards are laid out as a bezel board — one large gauge panel spanning 7 columns, three stacked ruled readouts at 5 columns — never a grid of identical cards. Every data row is an aligned label/value pair with a hairline rule beneath, units right-aligned in muted. At 768px the left rail collapses to a horizontal labelled strip above the content; at 375px all panels go full-width, gauges scale to 220px, and ruled rows wrap label above value rather than truncating.

Imagery style. Macro material photography only: brushed titanium, sapphire glass edges, anodised aluminium, topographic line fields, expedition-grade landscape shot dark and desaturated. Diagrams are engineered line art — signal paths, boundary schematics, radial dial scales — drawn in champagne on graphite. No stock people, no flat illustration, no 3D blobs. Screenshots of the product are presented as instrument faces inside a bezel frame, tilted 4° at most.

Forbidden. White or near-white grounds; any blue-indigo accent in the #2563EB / #4F46E5 family; a grid of identical hover-lift cards as the dashboards page; Inter, Roboto, Arial, Helvetica or system-ui for headings or body; gradient-blob heroes, glassmorphism panels, or soft multicolour gradients; rounded pill buttons and 16px+ card radii; cheerful illustration, mascots, emoji, or pastel support colours; parallax layers beyond the hero and any decorative particle field; using the teal signal colour for anything other than verified no-leak state.

7. Signature Design Concept

The bench dial. The public entry is a dial, not a headline-and-button stack. An 820px circular gauge dominates the right 55% of the viewport. Its bezel is built from three concentric hairline rings in champagne and steel. The needle rests at 78%, with the figure 78% set at 112px condensed inside the dial. The left 45% holds an oversized stacked headline in Saira Condensed uppercase — YOUR DATA NEVER LEAVES THE BENCH — set flush-left at 112px on desktop and 40px on mobile, with a ruled sub-row of three aligned label/value pairs beneath it (RUNS 1,284 / LEAKS 0 / MODELS 1) and a champagne-outlined CTA pinned under the rule. The background is flat #0E1114 with a faint topographic line field bleeding off the top-right edge behind the gauge. Nothing is centred, no subtext paragraph above the fold, no gradient behind the button.

The concept recomposes only accepted content: the product's promises (automation, dashboards, pattern discovery, no leakage), the entry CTA into Login, and the instrument framing that carries through to Analysis Runs, Dashboards, and Privacy Review. It introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief.

• Focal subject: The 820px instrument gauge on the right 55% of the viewport, its three concentric hairline bezel rings in champagne and steel, and its needle.
• Input → transformation → outcome thesis: On load, the needle sweeps from 0 to 78% over 1.6s with a physical ease-out and a 0.3s settle; the figure inside the dial resolves to 78%; the ruled sub-row of label/value pairs settles beneath the flush-left headline. The transformation is the instrument coming to rest — the bench reading its own state — and the outcome is a composed first frame in which the headline, the ruled row, and the CTA are all fully readable.
• Motion vocabulary: Needle sweeps and counting numbers only. No bounce, no particles, no gradient drift.
• Composed first frame: Flat #0E1114 plate; faint topographic line field bleeding off the top-right edge behind the gauge; needle at 78%; headline stacked flush-left; ruled sub-row beneath it; champagne-outlined CTA pinned under the rule.
• Reduced-motion state: Under prefers-reduced-motion, the needle renders at its final value, numbers appear statically, and the boundary stroke is simply present.

Product-wide motion. Run rows count their figures up over 600ms when they enter view. The privacy boundary on Privacy Review is drawn as a stroke that traces the panel perimeter in 900ms on first scroll. Hover on a data row lifts its hairline rule to champagne in 120ms — the only hover state in the product. Buttons fill from the left edge in 140ms on hover.

9. Non-Functional Requirements

NFR-1 — No data leakage (explicit). Data must not leak at any point in the analysis, automation, dashboard, or pattern-discovery workflow. This is the hard constraint of the product and the reason Privacy Review exists. Rationale: explicit user requirement.

NFR-2 — Private data handled in backend execution (required_inference). Private data handling, automated analysis, dashboard generation, pattern discovery, and privacy verification execute in the backend rather than in the browser, so that the permitted boundary is enforced server-side. Rationale: indispensable to make the no-leak constraint hold across the accepted workflow.

NFR-3 — Identity continuity for private work (required_inference). Private-data destinations are reachable only after identity is established or verified on Login; the entry interaction itself is anonymously reachable. Rationale: indispensable to bind private data and analysis workflows to the correct participant.

NFR-4 — Role-aware authorization (required_inference). Access to Data Sources, Analysis Runs, Dashboards, and Patterns is restricted to the Data Analyst / Domain Owner; access to Privacy Review is restricted to the Data Privacy / Governance Reviewer. Rationale: indispensable to keep verification with the accountable role.

NFR-5 — Readable text and controls at every viewport (explicit design constraint). Headlines, wordmarks, labels, numbers, cards' text and controls 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, and no other element covers any part of them. Imagery, decoration and motion may be cropped, bled off an edge, rotated, overlapped or cut as the direction asks, as long as they cover no readable text or control. Rationale: explicit design constraint.

NFR-6 — Reduced-motion usability (explicit design constraint). Under prefers-reduced-motion, the needle renders at its final value, numbers appear statically, and the boundary stroke is simply present; any moving or scrollable content provides a usable static arrangement in which each item can be brought fully into view. Rationale: explicit design constraint.

NFR-7 — Tabular figures (explicit design constraint). All numbers are set in Saira with font-variant-numeric: tabular-nums and given the champagne colour, so that counted figures and ruled readouts align. Rationale: explicit design constraint.

NFR-8 — Single-meaning signal colour (explicit design constraint). Teal #3FA9A0 is used for exactly one meaning — privacy verified / no-leak state — and amber and teal never touch in the same component. Rationale: explicit design constraint.

10. Tech Stack

• Frontend: React, delivered as a first-party web application with custom UI. (Default — not specified by user; the accepted delivery shape is custom UI with application-owned identity.)
• Backend: Python with FastAPI, executing private data handling, automated analysis, dashboard generation, pattern discovery, and privacy verification. (Default — not specified by user; required by the accepted backend execution requirement.)
• Storage: Appropriate persistent storage for user identity, submitted data sources, analysis runs, generated dashboards, discovered patterns, and privacy verification records. (Default — not specified by user.)
• Containerization: Docker with docker-compose for local and single-host deployment. (Default — not specified by user.)
• Orchestration: Kubernetes is not included; the accepted delivery does not require it. (Default — not specified by user.)

No source-specified technology choices were given in the authoritative thread, so the above are labeled defaults and carry no product behavior.

11. Assumptions and Constraints

Assumptions.

• A-1. The analyst supplies their own data; the product does not acquire data on the analyst's behalf. (Assumption — consistent with "my own data" in the accepted thread.)
• A-2. The LLM-based model is the product's own model surface, reached through the product's working destinations rather than through a separate external tool. (Assumption — consistent with "i have to make my on llm".)
• A-3. The Data Privacy / Governance Reviewer is a distinct accepted participant whose verification is performed inside the product on Privacy Review. (Assumption — carried from the accepted persona catalog.)
• A-4. "All related data-analyst processes" is bounded by the accepted thread: automation, dashboards, pattern discovery, and the workflow stages those imply. It is not an open-ended mandate for adjacent capabilities. (Assumption — narrows scope without removing accepted behavior.)

Constraints.

• C-1. Data must not leak at any point in the analysis, automation, dashboard, or pattern-discovery workflow. (Explicit.)
• C-2. The page inventory is fixed: Landing, Login, Data Sources, Analysis Runs, Dashboards, Patterns, Privacy Review. No pages are added, removed, merged, split, renamed, or reordered. (From the versioned page contract.)
• C-3. The persona catalog is closed: Data Analyst / Domain Owner and Data Privacy / Governance Reviewer. No personas are added, removed, merged, renamed, or replaced. (From the accepted persona contract.)
• C-4. Landing and Login are anonymously reachable; Data Sources, Analysis Runs, Dashboards, and Patterns are role-restricted to the Data Analyst / Domain Owner; Privacy Review is role-restricted to the Data Privacy / Governance Reviewer. (From the accepted access contract.)
• C-5. The visual direction is binding: dark mode only, the specified palette, Saira Condensed headings and Saira body, machined shape language, ruled instrument grid, and the forbidden list in Section 6. (Explicit design constraint.)
• C-6. No future-horizon requirements were accepted; nothing in this document is deferred. (From the accepted thread.)

12. Glossary

• inner-hii — The product: a private, LLM-driven analysis instrument for a data-analyst domain owner.
• LLM-based model — The product's own large-language-model surface that performs the analyst's domain tasks.
• Data Analyst / Domain Owner — The accepted persona who owns a data-analyst domain and runs the analysis workflow on their own data.
• Data Privacy / Governance Reviewer — The accepted persona accountable for verifying that data stayed private through the workflow.
• Data source — Data the analyst submits or connects for analysis.
• Analysis run — An automated analysis task executed against a submitted data source.
• Dashboard — A generated instrument face produced from analyzed data, presented as a bezel board.
• Pattern — A structure discovered in the analyst's data, tied to the analysis that surfaced it.
• Privacy Review — The sealed-bezel destination where the reviewer verifies that data remained private.
• No-leak state — The verified condition in which data stayed inside the permitted boundary; marked by the teal signal.
• Permitted boundary — The limit inside which the analyst's private data must remain throughout automation, analysis, dashboard generation, and pattern discovery.
• Bezel board — The dashboard layout: one large gauge panel spanning 7 columns beside three stacked ruled readouts at 5 columns.
• Ruled row — An aligned label/value pair with a hairline rule beneath it, units right-aligned in muted; its rule lifts to champagne on hover in 120ms.
• Instrument gauge — The structural circular dial with concentric hairline bezel rings and a needle, used on the hero and in dashboards.
• Tabular figures — Numbers set with font-variant-numeric: tabular-nums in Saira and given the champagne colour.