Knowledge

Finance concepts the codebase relies on, grouped by topic.

How the codebase is put together.

• Component architecture — api/core/service split, facet placement, CMake dependency chain, and scaffold profiles.
• Anatomy of a Service — every layer of a NATS service (registry, IAM, certs, controller, runner, authentication) with a stand-up checklist.
• Service Bootstrap Phases — Phase 1 (wire and subscribe every subject) vs. Phase 2 (mint tokens, warm caches — anything that calls a subject, including the service's own), worked through IAM's party_cache.
• Where should an entity-mirror cache live? — placement rule for the nats-event-cache facet's cached_by target: the entity's own producer never caches itself, a single specific consumer gets the cache in its own component (party_cache in ores.iam.core), multiple UI-layer consumers share a thin *.client component instead of duplicating. Covers cached_by's component.subcomponent dotted form for targeting a non-.core consumer.
• How does a Qt client cache stay fresh? — the GUI-tier counterpart to the entity-mirror cache above: ChangeReasonCache/BadgeCache subscribe to NATS change events via ClientManager and reload on receipt, re-subscribing on every login/reconnect. Contrasts the two tiers (concurrency model, auth, partitioning, protocol) and explains why the server-side facet is the wrong tool for a Qt-side cache.
• Entity-composed registrars — the meta-pattern of a top-level transport registrar delegating to per-entity sub-registrars, with a per-transport instance section (NATS, HTTP) linking to the codegen archetypes.
• Market Data Architecture — producers, the marketdata authority (subscribe → persist → remap), feed configs, and source-independent consumers.
• Tenor and Curve Bootstrapping Architecture — the end-to-end code model of the tenor machinery: the refdata tenor vocabulary (labels, conventions, anchors, schedules), the calendar/event store (calendar_event, diary_entry_types), how a tenor label resolves to a date (tenor_resolution.cpp, ANCHOR_OFFSET / SCHEDULE_STEP), and the bootstrap chain (configs → pillars → republish resolver → engine), including the FOMC 1F..=nF= worked example.
• ores.marketdata infrastructure inventory — inventory of the existing market data stack across all tiers: DB schema and entities (market_series, market_observation, market_fixing), FX spot encoding, tenant/workspace scoping, NATS request-reply subjects, Qt list windows, QueueChartWindow chart pattern, ORE CSV format, service registry entry, and CMake build conventions. Reference for the FX spot synthetic data PoC.
• FX spot synthetic data PoC: architecture — architecture design for the FX spot PoC vertical slice: gap analysis against the existing stack, new ores.synthetic service and ores.marketdata.client library designs, IFxSpotFeed interface, per-tick data flow, new NATS subjects, chart window and config dialog designs, 8 open design questions, and recommended 8-step implementation order. Gates implementation.
• Synthetic market data generators — architecture and specification of the generator library: IStochasticProcess / IFxSpotFeed separation, all 12 process types (5 deterministic + 7 stochastic) with mathematical specifications, per-process RNG design, ring-buffer pre-generation, QuantLib vs standalone analysis, and performance design for 50–100 concurrent high-frequency FX feeds.
• Polymorphic types over NATS — how to transport inheritance-like data structures (instrument variants, feed config params) over NATS using RFL: the type-specific subject pattern, discriminator-on-containing-entity convention, two-phase dispatch for read paths that cannot know the type upfront, the RFL std::variant index fragility pitfall, and the wrapper struct idiom. Canonical example from ores.trading instruments; applied example from ores.marketdata feed config parameters.
• CMake setup — preset menu, output directory layout, the conventions every component build follows.
• CI workflows and local checks — every PR-gating check, its fate (local / GitHub / retired), and the change-classification rules the submit-PR skills use.
• Entity lifecycle — layer ordering, type mappings, and service conventions for creating a full-stack entity.
• Qt plugin architecture — ores.qt.api contract, IPlugin lifecycle, the two-phase menu-building sequence.
• Qt entity patterns — ClientModel, list window, detail dialog, history dialog, and async-fetch patterns.
• Badge system wiring — DB-driven pill badges: ores.dq entities, SQL population, BadgeCache, and delegate wiring.
• C++ code style: clang-format configuration — literate source for .clang-format; every setting documented with rationale and examples.
• Qt menu and toolbar patterns — plugin registration, on_login() menu wiring, and MDI window toolbar construction.
• CLI entity patterns — options structs, parser layout, and command-dispatch conventions.
• Shell entity patterns — REPL command registration, message-based communication, and operation shapes.
• HTTP entity patterns — REST route structure, handler skeleton, and CRUD conventions.
• Wt entity patterns — list widget, detail dialog, and application-integration patterns.
• SQL entity schema patterns — naming conventions, idempotency patterns, and entity-type catalogue.
• Unit test conventions — Catch2 file structure, naming, test-case shape, generators, database helpers.
• Code review checklist — the categorised checks both PR-delta and full-component reviews apply.
• Component documentation guide — how to write a component_overview.org that passes audit.
• PlantUML class diagram conventions — styling for component and system class diagrams.
• PlantUML ER diagram conventions — styling for the SQL schema ER diagram.
• PostgreSQL architecture — schema layout, roles, session settings, bitemporal design, extensions, and key utility functions.
• Time and timestamps — bitemporality, TIMESTAMPTZ, db_timestamp, time_point, UTC standard, and the conversion layer.
• Temporal composite entity versioning: target state — child writes bumping a parent's version, as-of composition of parent + children, and the SQL/codegen/Qt enforcement plan.

Developer tools, scripts, and automation that support the build, test, and documentation workflows. These are not user-facing features — they are the instruments contributors reach for to get work done.

• Developer scripts — inventory of the standalone scripts in scripts/, grouped by purpose (metrics/reporting, validation, documentation generation, utilities), with a description of each script and notes on companion Python/shell pairs.
• ores.compass — the Python repository compass: temporal orientation, semantic doc search, and agile scaffolding over the org-roam graph. Primary quality-of-life aid for both human contributors and LLM agents.
• ores.codegen — Python + Mustache code generator producing SQL, C++, and v2 org documents from JSON models.
• ores.lisp — Emacs Lisp developer tooling: dashboard, database browser, shell integration, and org-roam export pipeline.
• ores.sql — PostgreSQL schema, migration scripts, role provisioning, and database lifecycle management. See the * Scripts section in the component overview for the full script inventory.

How ORE Studio's surfaces look and feel.

• UI design principles — the Jony Ive-level rulebook: design direction, typography, colour, spacing, depth, motion.
• Icon guidelines — the visual-language catalogue (Fluent UI System Icons) grouped by semantic category.

Authentication, authorisation, and tenancy.

• Identity and Access Management — how IAM is realised in ores.iam.core: tenants, accounts, roles, permissions.
• Role-Based Access Control — the RBAC model that backs IAM: roles compose permissions, the assignment graph.

The tools ORE Studio uses to author, publish, and navigate its documentation.

• Emacs — editor overview, our developer setup, and the CMake build targets (deploy_site, deploy_manual, deploy_skills, deploy_settings) that Emacs batch scripts drive.
• org-roam — how the knowledge graph is built, how id-links resolve across the static site, and the non-obvious hacks that make it work in CI.
• Zettelkasten — the atomic-note method that motivates the graph structure and id-link discipline across every .org file.

Concepts and systems we don't own — captured here so other docs can link to them without restating. See the external knowledge index for the full list, or jump direct:

• Open Source Risk Engine (ORE) — the upstream risk-analytics library ORE Studio wraps.
• QuantLib — the open-source quantitative-finance library ORE itself builds on.
• Financial Products Markup Language (FpML) — industry XML standard for representing financial products.
• Coding schemes — FpML mechanism for restricting fields to a known set of values.
• Standing settlement instructions — SSIs and how they flow through the trading lifecycle.
• PostgreSQL Row-Level Security — what RLS is at the database level, before we describe how we use it.
• Shared library symbol visibility — visibility annotations and hidden-by-default policy at the compiler / linker level.