Ask For a Trading Screen, Get a Fintech Dashboard
There is a particular disappointment familiar to anyone who has asked a general-purpose tool to build a trading interface. What comes back is competent and completely wrong: a card grid, a line chart, a table with fifty rows and pagination, a green up-arrow and a red down-arrow, and a big brand-coloured "Submit" button.
It is wrong in ways that are not cosmetic. A blotter is not a table with pagination — it is tens of thousands of rows that a trader scrolls and filters without ever reaching for a page control. Red and green as the only direction cue fails for roughly eight percent of male traders, and on a desk that cue carries money. A brand accent used for status means the one colour that should mean "look here" is already spent on the logo. And a desk is operated by keyboard under time pressure, so a screen with no command palette, no keyboard registry and no scoped focus model is a screen that will be operated slowly on the day it matters.
These are not preferences. They are the constraints that separate an application a desk can be run on from a screenshot of one.
An Industry Model, Not a Template
The Capital Markets blueprint exists to carry that knowledge into a build. It is a catalog of fifty capabilities across seven desk areas — execution, market data, risk, RFQ, algo, surveillance and post-trade — with three built verticals, trade entry, order matching and securities finance, each composing its own slice on top of those shared reference surfaces.
It defines the things a generic scaffold has no opinion about and a desk cannot ship without: the information hierarchy, the semantic colour channels, numeric and instrument formatting, data-grid behaviour, the keyboard model, the responsive policy, pre-trade safety states, and the regulatory UI profiles that follow from MiFID, SEC and FINRA obligations.
Locked, Default, Open
The interesting mechanism is not the catalog. It is how a vertical says this is not negotiable without forking the shared library underneath it.
Every capability carries a disposition. Some are locked: a virtualized grid, colourblind-safe direction cues, a keyboard registry, a scoped focus model, semantic colour channels, screen-reader support and locale-aware formatting. A locked capability cannot be switched off in the interview, so the desk cannot be generated without the things the work depends on. Others are defaults: pre-selected, still yours to drop — master-detail views, filter builders, bulk actions, optimistic sync, destructive-action confirmation. The rest is open and asked normally.
This matters because the alternative is a fork. Without dispositions, a vertical that needs stricter rules than the shared catalog has to copy the catalog and edit it, and from that moment every improvement to the shared layer has to be merged by hand into every vertical that copied it. Dispositions let the desk tighten the shared rules while still riding on them.
Capabilities Before Cosmetics
The questionnaire is ordered deliberately: the shared experience deck comes first, then the desk-specific catalog, then surface, then standards, then mock data. Capabilities before appearance — what gets built, before how it looks.
The reasoning is that a trading desk is an application before it is a vertical. It needs the shell, the token layer, the grid and the focus model that every serious application needs, and there is no reason for a domain to author its own version of those. The desk overlays only what it genuinely specialises.
The Generated App Can Still Change Its Mind
One more thing separates a blueprint from a template. The generated application ships a feature registry: capabilities can be enabled or disabled at runtime, not only at generation time.
That is the difference between a scaffold and a product. A desk that discovers in week three that it needs the RFQ surface after all does not go back to the generator and re-run its own project. It turns the capability on.
How It Composes
The blueprint is a domain overlay, not a runtime. It pins the stack it was authored against — Next.js 16 on the App Router, TypeScript, shadcn/ui with Tailwind v4, Vitest and Playwright — and contributes only its own UI questionnaire, so the vertical stays reusable as the runtimes underneath it move.
It also refuses to guess at the parts it cannot see. A UI kit does not know whether your desk sits on an existing OMS, what identity provider you use, or where your market data comes from, so it does not quietly activate a database, auth, queue or deployment interview on the strength of an assumption. Those stay yours to answer.
The point of a domain blueprint is not to save you the typing. It is to start the build from an industry's accumulated answers rather than from an empty folder and a hopeful prompt.
Beyond One Industry
Capital Markets is the worked example because trading desks are unusually unforgiving — the constraints are sharp, the failure modes are expensive, and a generic dashboard is obviously wrong within about four seconds of a trader looking at it. But the shape is not specific to finance. Any industry with real interface constraints — clinical systems, logistics control, industrial monitoring — has the same structure: a shared application layer, a domain catalog on top of it, and a set of capabilities that are not up for discussion.
The blueprint is how that knowledge gets written down once and applied every time, instead of being rediscovered by each new team three sprints in.