Knowledge
Table of Contents
Durable, cross-cutting knowledge that outlives any sprint. Each page is a single topic — a definition, a convention, an explanation of how some piece of the system works — that other documents can link to without restating it. If you find yourself explaining the same concept in two places, that concept belongs here.
This index lists the hub of each topic rather than every page in it.
A hub gathers its own pages and says how they relate, so listing both
here would duplicate that work and go stale as pages are added. Follow
the hub for the topic you want; to see every page regardless of topic,
list the knowledge tag.
For user-facing documentation see ORE Studio Manuals.
1. Where to start
A structure note says which pages to read, in what order, and why that order — the judgement search cannot supply. If your subject has one, start there rather than here.
| Cluster | Read it to be competent at |
|---|---|
| Trade | What a trade is, how it is classified, and what happens to it over its life |
| Market Data Requirements and Resolution | How a logical need for market data becomes concrete items |
| Interest Rate Curves | Discounting, bootstrapping, and the multi-curve family |
| Volatility | Realised against implied, the surface, and what trades on it |
| Identity and Access | Who an actor is, and where each layer enforces it |
| MASD | The methodology the code generator implements |
| Entity Lifecycle | The order an entity's layers must be built in |
| Message Queue | How a subject is addressed, what a message must look like, and where a service binds to the bus |
| NATS service patterns | How a service must use the bus: the call each situation requires, its rationale, and the failure without it |
| Data storage | Where the durable data lives, which interface reaches each store, and how to choose one |
| The data path | How a service reaches the database and how ticks reach the store, at one hundred thousand feeds |
| Data classification | How to tell what a data set is before choosing a shape, and how a set that crosses owners travels |
| Report Processing | How a report is scheduled, prepared, run on the compute grid, and recorded |
| UX | How a screen looks, what its marks mean, where it lives, and how it behaves for a record and for an entity |
Every structure note carries the structure_note tag, so listing that
tag returns the complete set.
2. Domain
Finance concepts the codebase relies on.
| Hub | What it gathers |
|---|---|
| Trade | Identity, classification, lifecycle, versioning, confirmations, operational authorisation, links between trades, trade sets and trade groups |
| ORE Products by Asset Class | Every ORE product type, by asset class and product family, each with its own page |
| Report pages | Every documented report, each with its own page: what decision it feeds, who reads it, how often it runs, and the ORE XML that configures it |
| Report families | Structure note for the report pages: the intraday monitors, their close twins, the desk maps and the ladder family, and the order to read them |
| Currency | The money and cash foundation, ISO 4217, and the currency roles a book or trade carries |
| Currency Pairs | Pairs as reference data: naming, deliverability, quoting, classification |
| FX forwards | Forward rates, points, ladders, and how desks and Finance use them |
| Cross-Rates Matrix | The no-arbitrage spanning tree of driver and derived spot rates |
| Market Data Requirements and Resolution | Requirements, identifiers, resolution, dependency closure, snapshotting, filtering |
| Interest Rate Curves | Day counts, discount factors, bootstrapping |
| Interest Rate Curve Families | How a currency's curves compose: funding and projection, build order, namespacing |
| Term Structures and Tenors | Tenor labels, horizon date, date rolling, IMM dates, broken dates |
| Volatility | The concept, the surface, the smile, and what trades on it |
| Calendars, Holidays and Events | Calendar reference data, recurrence, and calendar-anchored events |
| Book | Classification, the book and portfolio distinction, groups, lifecycle, ledger connection |
| Sweep | Cash centralisation, and the spot and ledger sweep types built on it |
| Stochastic Processes | The processes behind the quant generators: Wiener, Ito, and the mean-reverting family |
| Market Data Architecture | How a tick becomes a stored observation, how a config becomes a running synthetic feed, the verbs and screens that drive it, and the vendor and stored data side |
| Cuts | The label, the timepoint and the object a cut fixes; the kinds of cut; the data a cut must freeze, reference data included; the market data, deal and expiry components |
2.1. Topics with no hub yet
These have several pages and no page that gathers them, so they are named here until one exists.
- Risk and valuation: Risk Reporting, P&L Attribution, Pricing Configuration, ORE model configuration and Compute Engine.
- Front office: Trade Blotter, Trade Structures and Deal Composition, Business Unit and the trading and banking book boundary.
- Data quality: Data quality, the DQ-6 dimensions as we apply them.
3. Architecture
How the codebase is put together.
| Entry point | What it covers |
|---|---|
| Component Architecture | The api/core/service split, facet placement, the CMake dependency chain |
| Entities | What an entity is, how it is named, addressed and written, and how its layers are generated |
| Entity Lifecycle | Layer ordering and conventions for a full-stack entity, and the per-transport pattern pages |
| Anatomy of a Service | Every layer of a NATS service, with a stand-up checklist |
| Data-Oriented Design | The three regimes, and how to review a component's data model against them |
| Data classification | The classification cluster: the closed set of classifications, the checklist that applies it, and the transport that carries a package of bundles, in the order a modeller needs them |
| The data tiers | The five tiers of data by substitutability, and which machinery delivers each |
| Journey execution | The four composition classes for a journey, where the transaction boundary sits, and why a journey is not a saga |
| Workflows | The engine, the step protocol, the run and step states, and how a component describes the steps of a run |
| Scheduler | The cron expression, the loop that evaluates it, the firing and its record, and the actions a firing performs |
| Service architecture patterns | The pattern language of service interaction: the established patterns the platform uses, by group, with their sources, failure handling and pitfalls |
| Market Data Architecture | Producers, the marketdata authority, feed configs, source-independent consumers |
| The ORE XML infrastructure | How an ORE document becomes rows and comes back, in six notes: the codec that owns the shape, the mapper's conversion, the export's asymmetry, the three leaf maps, the value sets, and the guards that refuse a value |
| Tracking market data identity from fixing to report | The target state: identities that distinguish observed, generated, derived and published data, and reports that reference published curves |
| Bootstrapping a curve: from quotes to a published set | The recipe, the quotes it reads, the solve, the checks, the candidate and its publication |
| A report binds to a published curve, not to a name | The market binding names the publish record and the as-of, refuses a set that is not published, and the export builds the XML from the set |
| The cut is the body a run prices from | The cut's facts and derived states, the permissions that take and authorise one, the derived label, and the second binding that lets a run name a body |
| Data storage | The system of record, object storage, the durable stream and the caches, and what each one owns |
| The data path | Connections, the transaction API, bounded handlers, the tick store and its writers, and the numbers each reports |
| PostgreSQL Architecture | Schema layout, roles, session settings, bitemporal design |
| NATS Entity Protocol Specification | The subject grammar, verb set, envelopes, write model and security rules every common entity message follows |
| Component Architecture Audit | The recurring per-component cleanliness check, and the conventions it enforces |
| Component Clean Standard | The checklist a component passes to be clean and join the codegen gates |
| CMake Setup | The preset menu, output layout, and the conventions every component build follows |
4. Infrastructure
The shared substrate every component builds on rather than a component of its own.
| Entry point | What it covers |
|---|---|
| Message Queue | The bus, the subject namespace, the message contract, and how a service binds to it |
5. Tooling
The instruments contributors reach for, rather than user-facing features. Each component's own page carries its script inventory.
| Component | What it does |
|---|---|
| ores.compass | Repository compass: orientation, doc search, agile scaffolding over the graph |
| ores.codegen | The code generator producing SQL, C++ and org documents from JSON models |
| ores.lisp | Emacs Lisp tooling: dashboard, database browser, org-roam export |
| ores.sql | Schema, migrations, role provisioning, database lifecycle |
| Developer scripts | Inventory of the standalone scripts in scripts/ |
| CI workflows and local checks | Every gating check, its fate, and the change-classification rules |
6. UI
- Menu structure — the one menu every person sees, the entry that owns each screen, and the breadcrumb trail that follows.
- UI design principles — design direction, typography, colour, spacing, depth and motion, and the icon catalogue that follows from them.
- User Journeys — what a person is trying to do, written down before it is built: the goal, the steps, the wireframe, the entity fields composed into one screen, and the operations each step needs.
- Record screen standard — the one shape and behaviour of every screen that lists and maintains records: paging, the record page, writes and change reasons, history, related records, icons and states.
- Entity screen specification — the look and feel of a screen for an entity made of several kinds of record, such as a person: the list, the page, the Edit pattern, people links, photos and flags, server paging, history, who sees what.
- ORE element and leaf screen standard — the one way a screen draws a value of an ORE document, whether a product parameter, an engine run setting or a convention term: Simple and Advanced, the documentation, the value in force, the control and the gaps, with the exact words.
7. Security
- Identity and Access — the structure note: who an actor is, and where each layer enforces it. It orders the IAM and RBAC pages.
8. Documentation tooling
- Zettelkasten — the atomic-note method that motivates the graph structure and the id-link discipline every page follows. It orders the org-roam and Emacs pages.
9. Demonstrations
The working examples. Each is an instance of several clusters at once, so it holds one structure note that orders the pages about it rather than a page per subject.
- The Acme demonstration's market data and its approvals — how the fully populated demonstration tenant gets its market data, which rows the seed profile writes, and who may decide the approvals it raises.
10. External reference
Concepts and systems we do not own, captured so other documents can link to them without restating.
- External knowledge index — the full list, including ORE, QuantLib and FpML.