System Requirements Document for trading-strategy

1. Introduction

trading-strategy is a fully working order flow analysis tool. It is built for people who read the tape: traders and analysts who watch prints, bid/ask imbalances, absorption events and cumulative delta for hours at a time and need a working instrument that turns raw order flow data into analysis they can act on.

The product intent, taken directly from the authoritative requirement thread, is twofold and both parts are current commitments:

1. Create a tool for order flow analysis.
2. The tool must be fully working.

"Fully working" is interpreted as a source-bounded, end-to-end usable lifecycle: the analyst can bring order flow data into the tool, run an analysis over it, and obtain observable analysis output — with material failure and recovery handled truthfully at each step. It is not interpreted as a licence to add adjacent trading capabilities (order routing, brokerage connectivity, portfolio management, strategy backtesting, alerting, or account administration) that the source never accepted.

The audience is the Order Flow Analyst — the single accepted active human persona for this generation.

2. System Overview

The system is a first-party web application with three pages, delivered as a custom UI:

• Landing — the public entry surface that explains the order flow analysis tool, its audience, and what it does.
• Data — owns the accepted responsibility of providing order flow data to the tool for analysis.
• Analysis — owns the accepted responsibility of running order flow analysis and viewing the resulting analysis output.

All three pages are application-owned and carry an access requirement of none; no identity establishment, sign-in, or account management is part of this generation. The analyst moves freely between the three surfaces, and the work is stateless with respect to user accounts — the durable state that matters is the loaded order flow dataset and the analysis result derived from it.

The system is a serious computing instrument, not a dashboard template. Its visual and interaction language is a dark, ruled, data-instrument aesthetic in which the product's own order flow data is the imagery.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The tool is delivered as a first-party custom web UI owned by the application. There is no provider-owned or external-destination surface in this generation, and no headless-only delivery. Every accepted human interaction — reading the landing explanation, supplying order flow data, running the analysis, and reading the analysis output — happens on a first-party page.

Access ownership. All three pages are reachable without establishing an identity. This is not a gap to be filled: the accepted journeys do not require the analyst to privately own or resume durable actor-specific state, and no commitment, decision, entitlement, or value transfer must remain bound to a particular participant. The loaded dataset and the analysis result are working state for the current session, not an account-bound record. Accordingly, no sign-in, registration, invitation, or provisioning flow is introduced, and no page is protected.

Current boundary. Current scope is exactly: explain the tool (Landing), provide order flow data to the tool (Data), and run and view order flow analysis (Analysis). Everything the analyst needs to complete those three responsibilities is in scope, including the failure and recovery states that make each step genuinely usable.

Future boundary. Anything not listed above is out of current scope. Live market data feeds, brokerage or exchange connectivity, order placement, strategy backtesting, alerting and notification, saved watchlists, multi-user collaboration, and account management are not current requirements and must not appear in current pages or acceptance criteria. They are recorded in Section 11 as future or excluded, not built.

2b. Source Content Inventory

Not applicable. No reference directive in this request declares a content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

The public entry surface. It explains what the order flow analysis tool is, who it is for, and what it does, before any data or analysis work begins.

Information and state

• Oversized flush-left headline statement: "READ THE TAPE." stacked in two lines, with a 1px teal rule beneath it.
• A single line of body copy at 18px describing the tool.
• Three live HUD readouts in IBM Plex Mono (13px, uppercase, 0.18em tracking) showing the bundled sample dataset's cumulative delta, buy/sell ratio, and absorption count, ticking in real time as the hero canvas animates.
• A "built for the desk" section carrying the single permitted photographic element: a high-contrast monochrome macro of a physical tape-printed chart.
• Seeded generative particle renders presented as data sculptures, one per demo instrument: ES, NQ, BTC.
• Diagrammatic secondary imagery: depth-of-market heatmaps, footprint clusters, and absorption profiles rendered as monochrome line drawings on the black ground.
• Section transitions marked by full-width 1px rules with a small uppercase mono label pinned to the left edge (e.g. "03 / FOOTPRINT").

Primary action

• A single coral CTA button, sharp-cornered, 48px tall, flush-left under the readouts: "Open the tape" — the entry into the tool.

Supporting actions

• Scroll through the explanatory sections.
• Inspect the per-instrument data sculptures and diagrammatic imagery.

Domain entities

• Bundled sample order-flow dataset (demo instruments ES, NQ, BTC).
• Derived sample metrics: cumulative delta, buy/sell ratio, absorption count.

Component responsibilities

• Full-bleed WebGL particle field hero driven by the bundled sample order-flow dataset.
• Left-aligned type column overlapping the canvas at 6–8 column width, vertically centred.
• HUD readout strip beneath the headline.
• Ruled section blocks with pinned mono labels.
• Data sculpture gallery and diagrammatic imagery blocks.

States

• Loading: the hero canvas initialises; HUD readouts hold at their initial values until the sample dataset is bound.
• Empty: not applicable — the sample dataset is bundled, so the hero always has data to render.
• Success: the particle field animates continuously and the three HUD readouts tick in real time.
• Error: if the WebGL context cannot be created or the sample dataset fails to bind, the hero falls back to a static composed frame of the same particle field with the HUD readouts rendered at their last known values; the headline, body copy, and "Open the tape" CTA remain fully readable and operable.
• Recovery: the static fallback is a complete, usable landing state; the analyst can still proceed to the tool.

Data

The dense tabular intake surface where the analyst provides order flow data to the tool.

Information and state

• A dropzone for supplying order flow data.
• A schema preview of the supplied data.
• A column mapping table binding supplied columns to the fields the analysis requires.
• Row count, detected columns, and per-column type information.
• Validation state per mapped column.

Primary action

• Confirm the column mapping and hand the dataset to the tool for analysis.

Supporting actions

• Drop or select a data file into the dropzone.
• Inspect the schema preview.
• Adjust column mappings.
• Replace or clear the supplied dataset.

Domain entities

• Order flow dataset.
• Column mapping (source column → required analysis field).
• Schema preview record.

Component responsibilities

• Dropzone with drag-and-drop and file selection.
• Schema preview panel.
• Column mapping table with per-row source/target selectors.
• Validation and readiness indicator.
• Continuation control into Analysis.

States

• Loading: while a file is being read and parsed, the dropzone shows an in-progress state and the schema preview and mapping table are held.
• Empty: no dataset supplied — the dropzone is the only active element, the schema preview and mapping table are absent, and the continuation control is unavailable.
• Success: the dataset parses, the schema preview populates, mappings are complete and valid, and the continuation control becomes available.
• Error: an unreadable, malformed, or unmappable file produces a specific, actionable message naming the problem; the previously supplied dataset, if any, is retained rather than discarded.
• Recovery: the analyst can correct the mapping, supply a different file, or clear the dataset and start the intake again.

Analysis

The two-pane instrument where order flow analysis runs and its output is read.

Information and state

• Left control rail (380px): symbol, session, aggregation, and threshold sliders.
• Right fluid canvas with stacked panels: footprint, cumulative delta, DOM ladder, and tape.
• Cumulative delta line, drawn left-to-right over 400ms when the analysis runs.
• Absorption events marked as small coral rings that pulse once and fade.
• DOM ladder rendered as a vertical data sculpture: each price level is a horizontal bar whose length is the resting size, teal for bid, coral for ask, with a hairline 1px rule between levels and mono numerals right-aligned.
• Streaming trade tape.
• Footprint grid rows updating with a 120ms fade-in per row.
• A hero-adjacent mini-canvas whose particle band highlights on hover over a price level.

Primary action

• Run the order flow analysis over the supplied dataset with the current control-rail settings.

Supporting actions

• Set symbol, session, aggregation, and threshold values on the control rail.
• Re-run the analysis after changing settings.
• Hover a price level to highlight the corresponding particle band in the mini-canvas.
• Read the footprint, cumulative delta, DOM ladder, and tape panels.

Domain entities

• Analysis run (settings + dataset).
• Footprint grid.
• Cumulative delta series.
• DOM ladder (price levels, resting size, bid/ask side).
• Trade tape (prints).
• Absorption events.

Component responsibilities

• Control rail with symbol, session, aggregation, and threshold controls.
• Footprint panel.
• Cumulative delta panel with self-drawing line and absorption ring markers.
• DOM ladder panel.
• Trade tape panel.
• Hero-adjacent mini-canvas with price-level hover linkage.

States

• Loading: while an analysis run is executing, panels show an in-progress state; the cumulative delta line begins its 400ms draw as results arrive.
• Empty: no dataset has been supplied — the canvas shows an explicit prompt directing the analyst to the Data page, and the run control is unavailable.
• Success: all four panels populate with results for the current settings, the delta line completes its draw, and absorption rings pulse once and fade.
• Error: a failed run (invalid settings, dataset incompatible with the selected aggregation, or an execution fault) reports the specific cause on the Analysis page without discarding the loaded dataset or the last successful result.
• Recovery: the analyst adjusts the control rail and re-runs, or returns to Data to correct the dataset, then re-runs.

3. Functional Requirements

Each requirement below is a distinct story point with provenance, lifecycle facts, and observable acceptance.

FR-1 — Explain the order flow analysis tool on public entry As an Order Flow Analyst, I should land on a public page that explains what the order flow analysis tool is, who it is for, and what it does, so that I understand the instrument before I use it.

• Provenance: required_inference (Landing page rationale: mandatory public entry explaining the tool, its audience, and what it does before any identity establishment or protected work).
• Trigger/input: the analyst opens the application root.
• Observable result: the Landing page renders the headline statement, the descriptive body line, the three live HUD readouts (cumulative delta, buy/sell ratio, absorption count), the per-instrument data sculptures (ES, NQ, BTC), the diagrammatic imagery, and the "built for the desk" section.
• Access state: anonymous; no identity required.
• Failure/recovery: if the WebGL hero cannot initialise, a static composed frame of the same particle field renders with the HUD readouts at their last known values; all readable text and the CTA remain whole and operable.
• Continuation: the analyst proceeds via the "Open the tape" CTA.

FR-2 — Enter the tool from the landing hero As an Order Flow Analyst, I should activate a single, clearly placed control on the landing hero to enter the tool, so that I can move from understanding the instrument to using it.

• Provenance: required_inference (Landing primary action).
• Trigger/input: the analyst activates the coral, sharp-cornered, 48px-tall "Open the tape" CTA, flush-left under the HUD readouts.
• Observable result: the analyst arrives at the tool's working surfaces.
• Access state: anonymous; no identity required.
• Failure/recovery: the CTA is a plain navigation control and remains operable even when the hero canvas has fallen back to its static frame.
• Continuation: the analyst supplies data (FR-3) or goes directly to analysis (FR-6).

FR-3 — Supply order flow data to the tool As an Order Flow Analyst, I should supply order flow data to the tool through a dropzone, so that the tool has the raw material it needs to analyse.

• Provenance: required_inference (Data page rationale: owns the accepted responsibility of providing order flow data to the tool for analysis).
• Trigger/input: the analyst drops or selects an order flow data file into the dropzone on the Data page.
• Observable result: the file is read and parsed, and the schema preview populates with detected columns, types, and row count.
• Access state: anonymous; no identity required.
• Failure/recovery: an unreadable or malformed file produces a specific, actionable error naming the problem; any previously supplied dataset is retained rather than discarded, and the analyst can supply a different file or clear the dataset.
• Continuation: the analyst reviews the schema preview and maps columns (FR-4).

FR-4 — Map supplied columns to the fields analysis requires As an Order Flow Analyst, I should map the columns of my supplied data to the fields the analysis requires, so that the tool interprets my data correctly.

• Provenance: required_inference (Data page: schema preview and column mapping table).
• Trigger/input: the analyst adjusts source-to-target mappings in the column mapping table.
• Observable result: each mapped column shows a validation state, and the readiness indicator reflects whether the mapping is complete and valid.
• Access state: anonymous; no identity required.
• Failure/recovery: an unmappable or invalid mapping is flagged per column with a specific reason; the analyst corrects the mapping in place.
• Continuation: once the mapping is complete and valid, the continuation control into Analysis becomes available (FR-5).

FR-5 — Hand the mapped dataset to the tool for analysis As an Order Flow Analyst, I should confirm my column mapping and hand the dataset to the tool, so that the analysis can run against data the tool understands.

• Provenance: required_inference (Data page primary action).
• Trigger/input: the analyst activates the continuation control after a complete, valid mapping.
• Observable result: the dataset and its mapping are carried into the Analysis page as the working dataset.
• Access state: anonymous; no identity required.
• Failure/recovery: the continuation control is unavailable while the mapping is incomplete or invalid, so the analyst cannot hand over a dataset the tool cannot interpret; the specific blocking reason is shown.
• Continuation: the analyst runs the analysis (FR-6).

FR-6 — Run order flow analysis over the supplied dataset As an Order Flow Analyst, I should run the order flow analysis over my supplied dataset with the settings I choose, so that I obtain working analysis results.

• Provenance: explicit (the authoritative requirement: "create a tool for order flow analysis full working") combined with required_inference (Analysis page rationale: owns the accepted responsibility of running order flow analysis).
• Trigger/input: the analyst sets symbol, session, aggregation, and threshold on the 380px left control rail and activates the run control.
• Observable result: the right fluid canvas populates its stacked panels — footprint, cumulative delta, DOM ladder, and tape — for the current settings; the cumulative delta line draws left-to-right over 400ms; footprint grid rows fade in over 120ms each; the tape streams.
• Access state: anonymous; no identity required.
• Failure/recovery: a failed run reports the specific cause on the Analysis page without discarding the loaded dataset or the last successful result; the analyst adjusts the control rail and re-runs, or returns to Data to correct the dataset.
• Continuation: the analyst reads the results (FR-7) and re-runs with different settings as needed (FR-8).

FR-7 — Read the order flow analysis output As an Order Flow Analyst, I should read the analysis output across the footprint, cumulative delta, DOM ladder, and tape panels, so that I can see order flow metrics and patterns and inform my trading decisions.

• Provenance: required_inference (Analysis page rationale: viewing the resulting analysis output; persona rationale: inspects order flow metrics and patterns and uses the analysis output to inform trading decisions).
• Trigger/input: a completed analysis run.
• Observable result: the footprint grid shows traded volume by price and time; the cumulative delta panel shows the drawn delta series with absorption events marked as small coral rings that pulse once and fade; the DOM ladder shows each price level as a horizontal bar whose length is the resting size, teal for bid and coral for ask, with hairline 1px rules between levels and right-aligned mono numerals; the tape shows streaming prints.
• Access state: anonymous; no identity required.
• Failure/recovery: if a panel has no data for the current settings, it states that explicitly rather than rendering an ambiguous blank.
• Continuation: the analyst adjusts settings and re-runs (FR-8), or returns to Data to change the dataset (FR-3).

FR-8 — Re-run analysis with changed settings As an Order Flow Analyst, I should change symbol, session, aggregation, or threshold and re-run the analysis, so that I can examine the same order flow under different views.

• Provenance: required_inference (Analysis page control rail: symbol, session, aggregation, threshold sliders).
• Trigger/input: the analyst changes one or more control-rail values and activates the run control again.
• Observable result: the panels repopulate for the new settings, with the same draw and fade behaviour as the initial run.
• Access state: anonymous; no identity required.
• Failure/recovery: an invalid combination (for example, an aggregation the dataset cannot support) reports the specific cause and leaves the previous result visible for comparison.
• Continuation: the analyst continues reading results (FR-7) or returns to Data (FR-3).

FR-9 — Link a price level to the particle field As an Order Flow Analyst, I should hover a price level and see the corresponding particle band highlighted in the mini-canvas, so that I can connect the ladder to the flow field.

• Provenance: required_inference (Analysis page: hero-adjacent mini-canvas with price-level hover linkage).
• Trigger/input: the analyst hovers a price level in the DOM ladder.
• Observable result: the corresponding particle band in the hero-adjacent mini-canvas highlights.
• Access state: anonymous; no identity required.
• Failure/recovery: with reduced motion, the highlight is applied as a static emphasis rather than an animated one; if the mini-canvas is unavailable, the ladder remains fully readable and operable on its own.
• Continuation: the analyst continues reading the ladder and other panels (FR-7).

FR-10 — Recover from a failed or unusable dataset As an Order Flow Analyst, I should be able to correct or replace a dataset that the tool cannot use, so that a bad file does not end my session.

• Provenance: required_inference (indispensable failure/recovery mechanics for the accepted data-provision and analysis lifecycles).
• Trigger/input: the analyst encounters a parse error, an unmappable column, or a run failure caused by the dataset.
• Observable result: the specific cause is named on the page where it occurred, the previously working dataset or result is retained, and the analyst can correct the mapping, supply a different file, or clear the dataset and start intake again.
• Access state: anonymous; no identity required.
• Failure/recovery: this requirement is the recovery path; it must not itself discard the analyst's prior working state.
• Continuation: the analyst re-runs the analysis (FR-6) once the dataset is usable.

4. User Personas

Order Flow Analyst

Product context. The Order Flow Analyst is the single accepted active human persona for this generation. Their working reality is long screen sessions reading raw order flow: prints arriving on the tape, resting size stacked on the DOM ladder, volume distributed across price and time in the footprint, and the cumulative delta line that tells them whether buyers or sellers are actually in control. They work at a desk, often late, and they treat their tools as instruments rather than apps.

Primary goal. Obtain working order flow analysis results from the tool — bring order flow data in, run the analysis, and read output that shows order flow metrics and patterns clearly enough to inform trading decisions.

Distinct accepted responsibilities.

• Understanding what the tool is and does before committing to it (Landing).
• Providing order flow data to the tool, including mapping its columns to the fields the analysis requires (Data).
• Running the order flow analysis with chosen symbol, session, aggregation, and threshold settings (Analysis).
• Reading the resulting footprint, cumulative delta, DOM ladder, and tape output, and connecting price levels to the flow field (Analysis).
• Recovering from a bad file or a failed run without losing prior working state (Data and Analysis).

Relevant inputs and decisions.

• The order flow data file they supply, and how its columns map to the analysis fields.
• Symbol, session, aggregation, and threshold settings for each run.
• Which price levels to inspect and which panels to read for the pattern they are looking for.

Interactions with other accepted participants. There are none. The Order Flow Analyst is the only accepted active human persona, and no other human participant is materially affected by this work: the tool produces analysis for the analyst who requested it, and no commitment, value transfer, or decision is owed to a second party. The tool itself is a system actor, not a persona.

Observable success. The analyst has supplied a dataset the tool accepted, run an analysis, and is reading populated footprint, cumulative delta, DOM ladder, and tape panels for their chosen settings — with the cumulative delta line drawn and absorption events marked. Failure is observable and recoverable: a bad file or failed run names its cause and leaves prior working state intact.

What makes this role's work different. The analyst's work is interpretive and iterative rather than transactional. There is no submission, approval, or handoff; the value is in the loop of setting parameters, running the analysis, reading the resulting order flow structure, and re-running with different settings. The tool must therefore make re-running cheap and make the data itself the dominant visual element, because the analyst is reading structure in the data, not filling in a form.

5. Core User Flows

Flow A — Understand the tool and enter it

1. The Order Flow Analyst opens the application root and lands on Landing (anonymous; no identity required).
2. The full-bleed WebGL particle field renders from the bundled sample order-flow dataset: buy-side particles drift teal (#5BE7C4), sell-side particles drift coral (#FF5A3C), with density and velocity mapped to print size and inter-arrival time.
3. The analyst reads the oversized flush-left headline "READ THE TAPE." stacked in two lines with a 1px teal rule beneath it, and the single 18px body line describing the tool.
4. The analyst watches the three live HUD readouts in IBM Plex Mono tick in real time: cumulative delta, buy/sell ratio, and absorption count for the sample dataset.
5. The analyst scrolls through the ruled sections — the per-instrument data sculptures for ES, NQ, and BTC, the diagrammatic depth-of-market heatmaps, footprint clusters, and absorption profiles, and the "built for the desk" section with its high-contrast monochrome tape-chart macro — each section marked by a full-width 1px rule with a pinned uppercase mono label.
6. The analyst activates the coral, sharp-cornered, 48px-tall "Open the tape" CTA, flush-left under the readouts.
7. Observable result: the analyst arrives at the tool's working surfaces.
8. Failure/recovery: if the WebGL context cannot be created or the sample dataset fails to bind, the hero renders as a static composed frame of the same particle field with the HUD readouts at their last known values; the headline, body line, and CTA remain whole and operable, and the analyst proceeds normally.
9. Next step: Flow B (supply data) or Flow C (go straight to analysis).

Flow B — Supply order flow data and map it

1. The analyst arrives at Data (anonymous; no identity required).
2. Empty state: the dropzone is the only active element; the schema preview and column mapping table are absent and the continuation control is unavailable.
3. The analyst drops or selects an order flow data file into the dropzone.
4. Loading state: the dropzone shows an in-progress state while the file is read and parsed.
5. Success: the schema preview populates with detected columns, types, and row count, and the column mapping table appears.
6. The analyst reviews the schema preview and adjusts source-to-target mappings in the column mapping table so each supplied column binds to the field the analysis requires.
7. Each mapped column shows a validation state, and the readiness indicator reflects whether the mapping is complete and valid.
8. Failure/recovery: if the file is unreadable or malformed, a specific, actionable message names the problem and any previously supplied dataset is retained rather than discarded. If a column cannot be mapped, that column is flagged with its specific reason and the analyst corrects it in place. The analyst may supply a different file or clear the dataset and start intake again.
9. Once the mapping is complete and valid, the continuation control becomes available.
10. The analyst activates the continuation control.
11. Observable result: the dataset and its mapping are carried into Analysis as the working dataset.
12. Next step: Flow C.

Flow C — Run the analysis and read the output

1. The analyst arrives at Analysis (anonymous; no identity required) with the working dataset from Flow B, or directly from Landing.
2. Empty state (no dataset): the canvas shows an explicit prompt directing the analyst to the Data page, and the run control is unavailable.
3. The analyst sets the left 380px control rail: symbol, session, aggregation, and threshold.
4. The analyst activates the run control.
5. Loading state: the panels show an in-progress state while the run executes.
6. Success: the right fluid canvas populates its stacked panels for the current settings:
   • the footprint grid fills, with each row fading in over 120ms;
   • the cumulative delta line draws left-to-right over 400ms, with absorption events marked as small coral rings that pulse once and fade;
   • the DOM ladder renders as a vertical data sculpture — each price level a horizontal bar whose length is the resting size, teal for bid and coral for ask, hairline 1px rules between levels, mono numerals right-aligned;
   • the tape streams prints.
7. The analyst reads the panels to identify order flow metrics and patterns — imbalance, absorption, and delta divergence — to inform trading decisions.
8. The analyst hovers a price level in the DOM ladder; the corresponding particle band highlights in the hero-adjacent mini-canvas, connecting the ladder to the flow field.

9. Failure/recovery: if the run fails — invalid settings, a dataset incompatible with the selected aggregation, or an execution fault — the specific cause is reported on the Analysis page without discarding the loaded dataset or the last successful result. If a panel has no data for the current settings, it states that explicitly rather than rendering an ambiguous blank.
10. Observable result: the analyst holds a complete, readable analysis of the supplied order flow for the chosen settings.
11. Next step: Flow D.

Flow D — Re-run with different settings

1. From a completed analysis on Analysis, the analyst changes one or more control-rail values: symbol, session, aggregation, or threshold.
2. The analyst activates the run control again.
3. Observable result: the panels repopulate for the new settings with the same draw and fade behaviour as the initial run, and the previous result remains available for comparison until the new one completes.
4. Failure/recovery: an invalid combination reports its specific cause and leaves the previous result visible.
5. Next step: the analyst continues reading results (Flow C, step 7), re-runs again (this flow), or returns to Data to change the dataset (Flow B).

Flow E — Recover from a bad dataset

1. On Data or Analysis, the analyst encounters a parse error, an unmappable column, or a run failure caused by the dataset.
2. The specific cause is named on the page where it occurred.
3. The previously working dataset or result is retained — nothing the analyst had working is discarded.
4. The analyst either corrects the mapping in place, supplies a different file through the dropzone, or clears the dataset and starts intake again.
5. Observable result: the analyst is back to a usable dataset state without having lost their session.
6. Next step: re-run the analysis (Flow C).

6. Visuals, Colors and Theme

The creative direction is authoritative for this section. The muse is Refik Anadol, and the headline concept is order flow rendered as a living data sculpture: the product's own data is the artwork, and the interface is the instrument that reads it.

Palette (dark mode)

Proportion: 80% black/surface, 12% teal, 6% coral, 2% muted grey. Blue and indigo are forbidden — this is a data-instrument palette, not a SaaS palette.

Typography

• Headings: Space Grotesk, 500–700 weight, tight tracking (-0.02em). Used for the oversized hero statement and section titles.
• Micro-labels: uppercase at 11px / 0.18em tracking, for HUD-style annotations over the data canvas.
• Data numerals: IBM Plex Mono at 13px with tabular figures, line-height 1.2, so DOM ladder and footprint grid columns align pixel-perfect at every viewport.
• Body: IBM Plex Sans.
• Scale: 1.333 modular — 128 / 96 / 72 / 48 / 28 / 18 / 15 / 13 / 11.
• Hero display: clamp(56px, 9vw, 128px) on desktop, 56px floor at 375px.
• Section titles: clamp(32px, 4.5vw, 72px).
• Body: 15–18px, line-height 1.55.

Inter, Roboto, Arial, Poppins, and system-ui are forbidden for headings and body.

Shape language

Sharp, engineered rectangles: 0–4px radii on panels, 2px radii on controls, hairline 1px borders in rgba(237,237,242,0.08). No pills, no blobs, no soft cards, no 16px+ radii. The generative canvas is the only curved form on the page — everything else is orthogonal and ruled, so the flowing particle field reads as the sole organic element. Dividers are 1px rules spanning the full column width. The DOM ladder uses a strict column grid with alternating row tints at 3% white.

Layout

Full-bleed generative canvas as the landing hero, with a single left-aligned type column overlapping it at 6–8 column width. Below the fold, a 12-column ruled grid. The Analysis page is a two-pane instrument: a 380px left control rail (symbol, session, aggregation, threshold sliders) and a right fluid canvas with stacked panels (footprint, cumulative delta, DOM ladder, tape). The Data page is a dense tabular intake surface with a dropzone, schema preview, and column mapping table. Everything flush-left, values right-aligned in their column, never centred. Sections separated by full-width 1px rules, not cards.

Imagery

The product's own data is the imagery. No stock photography, no people, no device mockups. Seeded generative particle renders derived from historical order-flow samples appear as data sculptures on the landing page, one per demo instrument: ES, NQ, BTC. Secondary imagery is diagrammatic: depth-of-market heatmaps, footprint clusters, and absorption profiles rendered as monochrome line drawings on the black ground. The only permitted photographic element is a single macro of a physical tape-printed chart in the landing page's "built for the desk" section, treated in high-contrast monochrome.

7. Signature Design Concept

The hero is the order book, rendered as a living sculpture.

The public entry is a full-viewport #07070A canvas running a real-time WebGL particle field generated from a bundled sample order-flow dataset. Thousands of points drift along a horizontal time axis. Buy-side particles are teal (#5BE7C4); sell-side particles are coral (#FF5A3C). Density and velocity are mapped to print size and inter-arrival time, so the composition is literally the buy/sell imbalance rather than a decorative gradient.

Overlaid on the left third, flush-left and vertically centred, sits an oversized Space Grotesk headline at clamp(56px, 9vw, 128px): "READ THE TAPE." stacked in two lines, with a 1px teal rule beneath it and a single line of IBM Plex Sans body at 18px describing the tool.

Beneath the headline, three live HUD readouts in IBM Plex Mono (13px, uppercase, 0.18em tracking) show the sample dataset's cumulative delta, buy/sell ratio, and absorption count, ticking in real time as the canvas animates.

One coral CTA button, sharp-cornered, 48px tall, flush-left under the readouts: "Open the tape."

No centred headline, no gradient blob, no floating glass card. The data field is the hero, and the type sits inside it as a caption rather than on top of a card. This concept recomposes only accepted content and controls — the headline, the descriptive line, the three sample-derived readouts, and the single entry CTA — and introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

Focal subject. A real-time WebGL particle field generated from the bundled sample order-flow dataset — thousands of points drifting along a horizontal time axis, buy-side particles teal (#5BE7C4), sell-side particles coral (#FF5A3C), with density and velocity mapped to print size and inter-arrival time.

Input → transformation → outcome thesis. The sample dataset's prints are the input; each print becomes a particle whose colour is its side, whose density reflects its size, and whose velocity reflects its inter-arrival time; the outcome is a continuously evolving composition in which the buy/sell imbalance is directly legible, while the three HUD readouts (cumulative delta, buy/sell ratio, absorption count) tick in step with the field. Absorption events pulse outward as rings.

Motion vocabulary. Cinematic and continuous. Slow generative drift; scroll-linked camera drift applied to the canvas only, never to the text; absorption rings that pulse once and fade.

Composed first frame. Full-viewport #07070A ground with the particle field already in motion. The left third carries the flush-left, vertically centred "READ THE TAPE." headline in Space Grotesk with a 1px teal rule beneath it, the 18px IBM Plex Sans body line, the three mono HUD readouts, and the coral 48px "Open the tape" CTA. All readable text and the CTA sit 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.

Reduced-motion state. With prefers-reduced-motion, the canvas freezes to a static frame of the same particle field, the tape becomes a scrollable list, and the cumulative delta line renders fully drawn. The headline, body line, HUD readouts, and CTA remain whole and operable.

Analysis Page Motion

On the Analysis page, the tape streams and the footprint grid updates with a 120ms fade-in per row; the cumulative delta line draws left-to-right over 400ms; absorption events are marked as small coral rings that pulse once and fade — the only decorative motion on the page. Hovering a price level highlights the corresponding particle band in the hero-adjacent mini-canvas. All of this respects prefers-reduced-motion: the tape becomes a scrollable list and the delta line renders fully drawn.

9. Non-Functional Requirements

NFR-1 — Fully working end to end. The tool must complete the full lifecycle — supply data, map it, run the analysis, read the output — without dead ends. Provenance: explicit ("full working"). Rationale: the authoritative requirement states the tool must be fully working, so every accepted step must reach an observable result.

NFR-2 — Readable text and controls stay whole at every viewport. Headlines, wordmarks, labels, numbers, panel 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. Provenance: explicit (creative direction, readable-text rule). Rationale: the direction's imagery and motion may bleed and overlap, but readable text and controls may not be cropped, clipped, or covered.

NFR-3 — Reduced-motion support. With prefers-reduced-motion, the hero canvas freezes to a static frame, the tape becomes a scrollable list, and the cumulative delta line renders fully drawn. Provenance: explicit (creative direction). Rationale: the direction specifies a usable static arrangement for motion-sensitive users.

NFR-4 — Data numeral alignment. DOM ladder and footprint grid numerals use IBM Plex Mono at 13px with tabular figures so columns align pixel-perfect at every viewport. Provenance: explicit (creative direction). Rationale: misaligned price and size columns make a ladder unreadable.

NFR-5 — Palette discipline. Blue and indigo must not appear as primary or accent anywhere. Provenance: explicit (creative direction). Rationale: the direction forbids the generic indigo/blue-on-white SaaS template for this project.

NFR-6 — Failure states preserve working state. A parse error, unmappable column, or failed run must name its specific cause and must not discard the analyst's previously working dataset or result. Provenance: required_inference. Rationale: without this, a single bad file would end the session and the tool would not be "fully working."

10. Tech Stack

• Frontend: React, with React Three Fiber / Drei for the WebGL particle field hero and the hero-adjacent mini-canvas.
• Backend: Python / FastAPI, serving the order flow data intake, column mapping validation, and analysis execution endpoints.
• Storage: appropriate storage for the working dataset and analysis results — a relational store for dataset metadata and column mappings, with the parsed order flow series held for the duration of the analysis session.
• Containerisation: Docker and docker-compose, with the frontend and the FastAPI backend as the runnable services. The analysis work runs inside the existing backend process and its modules; no separate container or ingress route is introduced for it.
• Kubernetes: not required for this deployment.

No source-specified technology is overridden; the stack above fills only what the source left unspecified.

11. Assumptions and Constraints

Assumptions

• A-1. The analyst supplies order flow data as a file through the dropzone. The source does not name a live market data feed, so none is assumed.
• A-2. The bundled sample order-flow dataset used by the landing hero covers the three demo instruments named in the creative direction: ES, NQ, and BTC.
• A-3. The working dataset and analysis result are session-scoped working state. No account-bound persistence is assumed, because no accepted journey requires the analyst to privately own or resume durable actor-specific state.
• A-4. The analysis runs inside the existing FastAPI backend process. No independent queue worker or separate service is assumed, because the accepted workflow does not call for one.

Constraints

• C-1. The tool must be fully working: every accepted step reaches an observable result, with material failure and recovery handled.
• C-2. The page inventory is fixed at exactly three pages — Landing, Data, and Analysis — in that order, with no additions, removals, merges, splits, renames, or reordering.
• C-3. All three pages are anonymously reachable. No identity establishment, sign-in, registration, invitation, or provisioning flow is part of this generation.
• C-4. The Order Flow Analyst is the only active human persona. No additional personas are introduced.
• C-5. The creative direction is authoritative for palette, typography, shape language, layout, imagery, motion, and the signature hero concept. Blue and indigo are forbidden as primary or accent.
• C-6. Readable text and controls stay whole at 375px, 768px, and 1280px; imagery, decoration, and motion may bleed and overlap, but never over readable text or controls.

Out of current scope (future or excluded)

• Live market data feeds and exchange or brokerage connectivity.
• Order placement, order routing, or any execution capability.
• Strategy backtesting, optimisation, or signal generation.
• Alerting, notification, or messaging of any kind.
• Saved watchlists, saved analyses, or account-bound history.
• Multi-user collaboration, sharing, or permissions.
• Account management: registration, sign-in, profiles, billing, or subscription.
• Any provider-owned or external-destination surface; all accepted interaction is first-party.

12. Glossary

• Order flow — The stream of executed trades and resting orders in a market, characterised by print size, side (buy or sell), price level, and inter-arrival time.
• Tape — The streaming list of individual prints, showing price, size, and side as trades execute.
• DOM ladder (Depth of Market) — A vertical display of price levels with resting bid and ask size at each level, rendered here as a data sculpture with horizontal bars whose length is the resting size.
• Footprint — A grid showing traded volume distributed across price and time, revealing where buyers and sellers transacted.
• Cumulative delta — The running sum of buy-side minus sell-side volume over the session; positive delta indicates net buying aggression.
• Absorption — A condition where aggressive orders are met by resting liquidity without price moving, indicating a large passive participant absorbing flow. Marked in the tool as small coral rings that pulse once and fade.
• Aggregation — The time or volume interval over which order flow is grouped for analysis; a control-rail setting.
• Threshold — A control-rail setting that determines the sensitivity at which order flow events (such as absorption) are flagged.
• Session — The trading period over which the analysis is scoped; a control-rail setting.
• Data sculpture — A seeded generative particle render derived from a historical order-flow sample, presented on the landing page as the product's own imagery.
• HUD readout — A small uppercase monospace annotation over the data canvas, showing a live metric such as cumulative delta, buy/sell ratio, or absorption count.
• Order Flow Analyst — The single accepted active human persona: the person who supplies order flow data, runs the analysis, and reads the resulting output to inform trading decisions.