ORE Studio Sprint 27 – Release Notes

• Hotfix: the oresmd codec does not compile: Make ores.marketdata.core compile again on main.
• Hotfix: the party role names a dropped column: Make ores.trading.api compile and let the party roles table be created.
• Hotfix: the consumers still set the dropped party columns: Make the trade import and the trading service compile again.
• Hotfix: the counterparty fixtures write a dropped column: Let ores.refdata.api compile and let the counterparty fixtures load.
• Hotfix: the series shape writer cannot name its context: Let ores.marketdata.service compile again.
• Hotfix: the versioned catalogues cannot be seeded: Let compass db recreate finish, so a database can be built from scratch on this branch.
• Hotfix: the chrono include never reached the trading instruments: Bring trading-cpp back under the drift gate, so check_component_drift.py reports no drift for it.
• Hotfix: the seeded books have no purpose: Give the book artefact's two new not-null columns, book_purpose_type and ledger_feed_type, the SQL defaults their own model prose already promises, so the five book seeds insert unchanged and compass db recreate completes.
• Hotfix: Domain generator omits the Boost UUID I/O include: The CI build fails in projects/ores.iam/api/src/generators/run_grant_generator.cpp with error: 'to_string' is not a member of 'boost::uuids'.
• Hotfix: The credential model links a model that was withdrawn: The credential model links nothing that does not exist.
• Hotfix: the generated headers miss the chrono include: Let every generated domain header that names std::chrono compile on its own.
• Hotfix: the tenantless catalogues ask for tenant policies: Let the database schema load.
• Hotfix: the settings trigger is refused by the function it calls: Let a service write a tenant-wide setting, so bootstrap's last step completes.
• Hotfix: the audit events miss the sign-ins: The audit sign-ins screen shows almost nothing, on an installation whose authentication log is not empty.
• Hotfix: the er-diagram and pgtap checks fail on main: The local check gate passes er-diagram and pgtap on main, so a clean run means the branch is clean.
• Hotfix: a codegen test remaps the trade target for every later test: A full codegen test run passes on main, whatever order the tests run in.
• Hotfix: Windows MSVC build treats an unused catch parameter as an error: Make the MSVC build compile publish_service.cpp again.
• Hotfix: The user systemd probe ignores the busctl transport: A sandboxed checkout builds, and starts a Claude session, without a systemd-run scope the sandbox refuses.
• Hotfix: Site build needs live GNU ELPA: Site CI turns red whenever elpa.gnu.org does not answer.
• Hotfix: scheduler accepts six-field cron expressions: A job or report schedule written with six fields is refused with a message that names the field count, instead of being stored and run on a shifted schedule.
• Hotfix: Continuous Linux red and the site build cancelled on every push: Restore Continuous Linux to green and stop the site build from firing on every push.
• Hotfix: Drop the libstdc++ internal header the include run added: Both test files include <chrono> and not the libstdc++ internal.
• Repair the drifted artefacts on main: The ores.web workspace is prettier-formatted, so the TypeScript workflow passes on main again.
• Hotfix: the sweep schedule cannot see its own name: Let ores.inbox.service compile again.
• Hotfix: the operations screens cannot see the bus or the storage service: Let the message bus screen show samples, by polling the NATS monitor port the environment actually uses.
• Hotfix: the marketdata offset field has no name: Let ores.marketdata.core.tests compile, so a full build reaches 100% on main.
• Hotfix: the party role test asserts a dropped column: Let ores.trading.api.tests pass, so the trade party role suite reports on the code rather than on a column the model no longer has.
• Hotfix: the export joins on a trade id nobody mints: Let the XML roundtrip walk and the exporter tests join each trade to its own instrument, so the ORE corpus imports stop resolving a trade onto another trade's instrument.
• Hotfix: the trading children write outside the session party: Let the trade booking and trade state eventing tests pass again, so the suite reports on the notification chain rather than on a row its own session cannot see.
• Hotfix: the denial test counts on a caller without a role: Let the denial case of the account-access read exercise the refusal it describes, so the suite tests the authorization boundary rather than a state no account is in.

• Rework the rates instruments to the instrument table rule: Rework swaps, FRAs, caps and floors, swaptions and the other rates trade types to the instrument table rule of the trade shape investigation (section 14), as the bonds were reworked, with the data-oriented review deciding the tables.
• Rework the credit instruments to the instrument table rule: Rework the credit trade types and the risk participation agreement to the instrument table rule: a family header holding exactly its codes, product fact tables keyed by the trade, shared children with role codes, and securities keyed by their reference datum.
• Finish the refdata read path: Every refdata list the record-screen standard names searches and sorts on the server, a tenant has a history, a party event refreshes the cache that names parties, the party test inserts a category, and a parent cycle in the party hierarchy is reported rather than silently dropped.
• Carry every trading instrument as a typed batch: Every trading instrument crosses the export boundary as a typed array, not as an untyped payload.
• Show the whole history of a party: A party's history shows every change to the party and to everything attached to it: its identifiers, contacts, business units, countries, currencies and counterparties, each with who made it and why, and says nothing is missing because nothing is.
• Filter and search trades through the model: The trade model declares which columns a list can filter, search and sort by.
• Complete the trade list's filters: A trade page reads each child table by trade id, and the entity protocol states the standard for finding entities with range filter members.
• Hold money exactly and move the external version on economic change: Hold every money quantity as an exact decimal, read the ORE boundary without loss, and derive the trade's external version from the economics actually held rather than from the reason a writer supplied.
• Make the ACME data realistic and isolate the ORE samples: The ACME base bundle holds realistic agreements, netting sets, CSAs and portfolios for each party, and the ore_samples bundle carries only the labelled reference data the sample import needs and lands its imports in a sandbox portfolio tree.
• Record trade activities and trade links: Add trade_activity with its type, and trade_link with its type, so every component version names its cause and every relation between trades is typed and directed.
• Model trade structures: Implement section 11 of the trade shape investigation, so a structure is a group with an identity whose legs reference it, as Trade Structures and Deal Composition requires.
• Gather a run's inputs by declared dependency: A step declares the artifacts it consumes and produces, and a run's chain is held as a persisted dependency graph that the engine dispatches from.
• Define the trade set model: Lay the domain knowledge of grouping trades on one foundation.

• Make a series identity joinable in the database: Make the identity of a market series queryable in the database.
• Return marketdata to the clean-standard registry: marketdata passes every item of the component clean standard, or holds an exception the owner accepted, and is back in COMPONENTS_UNDER_TEST so the drift and protocol twin gates cover it again: P01 and H01 close, H03's namespace closer comments leave the templates and the files they generate, and the record is re-measured at one commit.
• Edit an oresmd URL in a dialog: A person never writes an oresmd URL by hand.
• Link an oresmd URL to what it names: An oresmd URL behaves like every other reference in the app.
• Implement synthetic data generation against the new market data model: Make the synthetic feeds first-class producers in the new market data model.
• Manage market data bindings: A journey and a signed-off clickable prototype define how a person manages market data bindings, for supported synthetic data and unsupported real data, and the server reads and BFF record kind the screen needs exist.
• Organise feeds by provider and scope: Make a provider a system-level record, give every feed a system or test scope, seed the provider catalogue by provider and kind, and browse feeds through one tree by scope, provider and feed kind.
• Add proper curve support to ores.marketdata: Give ores.marketdata a first-class representation of a curve, so a bootstrapped curve is an entity with identity, provenance and a consumer rather than a derived series nothing reads back.
• Show a curve evolving in ores.web: A person opens ores.web, names a curve or a surface, and watches it evolve as an aligned matrix of instants by nodes, with each node's change, staleness and provenance.
• Pick a curve from the series a party can see: A person opens the curve evolution screen and chooses the curve or surface from a list of the series their party can see, instead of typing its asset class, scope, instrument type, quote type and fields.
• Project the identities of the series a publish seeds: Every market series a publish creates can be found by the resolver and listed by the picker as soon as the publish completes, without anyone running a backfill by hand.
• Adjust a curve point by hand from the web: An operator who holds the write permission can set a node of a curve or surface by hand from the evolution screen, with a reason, and clear it again.
• Order the term axes of a shape by duration: A person who reads a surface or a curve sees each term axis in order of length: 1W, 1M, 2M, 3M, 6M, 9M, 1Y, 18M, 2Y.
• Plot a surface as a heatmap and slices: A person who reads a surface on the evolution screen sees its shape at once: a heatmap of the first axis against the second, and one line for each value of the first axis across the second.
• Name every synthetic feed by its oresmd reference: Every synthetic feed states the datum or the series it produces as an oresmd URI, the same reference the market data store, the ticks, the feed bindings and the screens use.
• Implement the synthetic market data journeys in ores.web: A person authors an FX price feed and an IR curve feed in ores.web, on the subjects the journeys name.

• Read each tenant's cache partition inside its tenant: Every tenant's partition of a generated event cache loads inside that tenant with a token for that tenant obtained by Token Exchange, and the parties policy and read are strict again.
• Add the identity workflow and the commands that drive it: The identity workflow is a registered definition whose steps are declared by the request, so one fixture covers many workflow configurations that emulate real ones, and ores.shell drives it end to end.
• Polish the audit sign-ins screen: The Sign-ins screen reads as the rest of the application does.
• Hide what system accounts did in a history: A history shows a toggle that hides or shows the entries made by service accounts.
• Split accounts into open and confidential data: Every tenant can read the open data of an account, such as the name, picture and type of a service account, through the same pattern that shares reference data.
• Close the IAM isolation gaps and review account visibility: No IAM table that carries a tenant is readable across the tenant boundary unless a model says why, and the account visibility model has been reviewed against a stated list of threats.
• The bootstrap runs as two workflows, one per administrator: Let each administrator finish the half of a tenant's setup that is theirs.
• Run a report as its tenant and party: A scheduled report run acts as the tenant and the party of its definition, with no caller present.
• Guard every read the security documentation does not allow: A read checks its read permission, unless the security documentation allow-lists it by subject, with the reason it is open.
• Name the installation's own data: The installation owns a class of data the schema does not name: the facts about the deployment itself.
• Separate the account's credentials from its profile: A profile write can never change a credential, and the history says which of the two actually changed.
• Report a refused request as a refusal: Make every client report a refusal as a refusal, naming the reason the server gave, so a permission problem is never mistaken for a malformed payload.
• Implement the audit sign-ins journey: The administrator can account for every open session: who is signed in, what the session did, who is failing to get in, where the session came from, and they can end a session that cannot be explained.
• Guard the curve-snapshot reads: The curve-snapshot reads answer only a caller that holds the read permission, and the permission is seeded, so a signed-in member cannot read every tenant's curve points.
• Show who did it in audit: Every audit row names the account by its username, with the UUID beneath it, and a failed-attempts row means an attempt actually happened.
• Build the four-eyes framework: The four-eyes framework: a gated write raises an approval request that names several deciding parts, is held until every part approves, is applied as one transaction, and every kind of request shares one queue, one request page and one review panel.

• Bootstrap the system at runtime: A freshly created database holds the schema and the staged DQ artefacts and nothing else.
• Run compute nodes on the local network hosts: Three machines on the local network, goedel (192.168.1.199), newton (192.168.1.22) and 192.168.1.11, run compute nodes (ores.compute.wrapper) that join an existing environment's grid over NATS.
• Serve the grid's samples as time series: Serve the grid's and the node samples as bucketed time series over a caller's range, page them through the BFF, and draw the load, fleet, throughput and outcomes panels on one shared time axis.
• Keep queued grid jobs runnable for as long as they wait: A job that waits in the grid queue for any length of time still runs when a node takes it, and the queue is bounded and visible, so a burst of work slows the grid and never fails it.
• Run an example bundle through the compute grid from a report definition: A report definition can select a step chain shorter than the full report execution workflow, and the reporting to compute handoff drives a compute job from it.
• Tidy up the system core and the leftovers: An installation brings itself up from a bundle that is the whole set of datasets it is read from, and the leftovers the first pass of that fix exposed are closed.
• Isolate tenant data in object storage and the compute grid: Object ownership and the object capability are settled, and a worker node reaches its assignment's objects through a per-assignment capability with no standing storage credential.
• Run the compute grid on the shared hosts: Every machine on the local network runs this environment's compute nodes beside the environments already there, and each environment's deploy, stop and logs touch only its own state.

• Write the refdata party, book, convention and tenor journeys: The five refdata journeys of the agreed catalogue that no document covers have one, so that a tenant administrator onboarding a counterparty, keeping a party's details current, shaping the book structure, defining the conventions for an instrument or defining how tenors resolve has a screen design to build against.
• Implement the refdata party, book, convention and tenor journeys: Four of the five refdata journeys – counterparty onboarding, party details, the book structure and the instrument conventions – run in ores.web on the server changes each one needs.
• Write the trade journeys: The trade journeys exist as use cases under doc/knowledge/journeys/trades/.
• Prototype the trade journeys: Four prototypes under doc/prototypes/trades/ serve all seven trade journeys as entity screens under the UX standards.
• Specify the trade screens in the UX standards: The menu page and the entity screen specification state how the trade screens look and behave, including the standard entity protocol they read and write through.
• Complete the ores.inbox approvals and notifications: A member asks for a role, an administrator answers from the queue, and both are told through in-application notifications: the role request is the first approval kind, and the request and notification screens render it.
• Complete the super administrator UX journeys: Signed in as the super administrator, the deployment's own world is real and named: the administrator is greeted by a human name and shown a picture, and the system administration area lists the accounts the installation runs on — the platform's service accounts among them.
• Attach pictures at runtime through one seam: Pictures are attached at runtime through one seam: an assets operation ensures a template image exists in a tenant, and an IAM operation reconciles accounts' pictures from a scope.
• Group the prototypes and add the Gemini reviews: A person looking for a prototype finds it by the journey topic it answers to, not by scanning one flat list of 46 directories.
• Keep the prototypes in git: A prototype is the design record its journey cites, and this story keeps it readable after the sprint that built it closes.
• Implement the operations journeys in ores.web: The five Operations journeys – the running services, the compute grid, the message bus, the telemetry logs, and the versions and database – run as screens in ores.web against the real server.
• Land the role request journey: The fourth Access journey runs in ores.web: the member asks for a role beyond the one registration gave them, and the tenant administrator answers.
• Bring the record screens to the standard: The classification, tenant and party screens conform to the record screen standard, and the product owner's review of the people screens is closed.

• Bring the QA validation runner to ores.web: A tester works through a test scenario in ores.web: open a scenario, read its steps beside its story and task, mark each step PASS or FAIL with a note, and save the result.
• Browse the agile tree in ores.web: Story 2 of the QA runner arc.
• One way to keep a prototype: Two prototype mechanisms exist.
• Account avatars are too dark to see: An account's avatar reads as an identity on the dark theme, whether the account is a person, a service, or an administrator.
• Implement the membership journeys in ores.web: The two Membership journeys run in ores.web against the real server.
• Export the reporting line write from the browser entry: The web bundle builds from main.
• Align the web palette with the reviewed scheme: The application's dark theme is the GitHub-dark palette the project site uses, and the landing-page review argued a different one: a blue-black surface ramp on slate neutrals, an indigo accent reserved for interaction, and a sky hue for content that is not built yet.
• Give the super administrator's landing page its cards: A system administrator lands on cards for the screens they use, and sees which journeys are still to come.
• Open the web as an Acme persona: Test the web as different Acme users without adding profiles to the developer's own Chrome.
• Group the super administrator's home into cards and subcards: A system administrator lands on Tenants, Accounts, Operations and Security cards, and reaches the operations screens through the Operations card.
• Make the services screen tell the truth about the installation: The Operations services screen shows the web service running, and an overview states how healthy the installation is at a glance.
• Show the release with its v: The newest release figure reads v0.0.27, whichever form the services report.
• Review the system administrator's home screen: The system administrator's home opens on a dashboard of four panels that all state their status the same way, with the active and upcoming modules on their own tabs.
• Review the tenant administrator's home screen: A tenant administrator lands on a dashboard of panels that say what needs them, with the active and upcoming modules on their own tabs.
• Draw the menu by reads alone: Who sees an area or a card depends on the reads a person holds and on nothing else, so the menu reads the same way for every person and a new screen needs no change to it.
• Change party from the account menu: A person changes the party they act for from the account menu, without signing out.
• Give every prototype its design note: Every market data prototype has a design note beside it, and the group page links each note instead of carrying the argument in a table cell.
• Write the synthetic market data journeys: Every synthetic prototype answers to a journey document: the actor, the steps, the wireframe, the entities it composes, a coverage table checked against the synthetic subjects, and the gaps that must close before it is built.

• Migrate the remaining refdata entities to the generated event registrar: A change to any refdata entity publishes its event on that entity's own subjects, so the caches, the audit trail and any other consumer learn of it.
• Codegen developer experience improvements: Fix two of the codegen regenerate workflow's friction points: a component run silently skips models whose type the address does not support, and an entity filter restricts a run to the named entities.
• Codegen improvements from the clean-up passes: The codegen layer has no defect left that the component clean-up passes found.
• Clean ores.scheduler to the component clean standard: ores.scheduler meets the Component Clean Standard: every item: All, Protocol and Entity pass, each item that does not apply is recorded with its reason, and ores.scheduler joins COMPONENTS_UNDER_TEST.
• Model the handcrafted ores.dq code and generate the artefact tables: Every handcrafted ores.dq table and function has a model, and the artefact tables generate from the same entities as their base tables, so the component keeps regenerating byte-identically.
• Remove the presentation keys no template reads: No presentation key is written that no template, render path or validator reads; the helpers that existed only to compute them are gone; regenerating a component produces no diff; and every document that named the Qt layer as live is corrected or marked historical.
• Remove workspaces from every component: No component carries a workspace: no table has a workspace_id, no request or session carries a workspace context, and ores.workspace is gone.
• Keep the nightly include-cleaner out of generated files: Every include fix from the nightly run lands in the layer that owns the file: hand-crafted sources directly, generated sources through their templates.
• Bring the last components under the drift gate: Put every component that generates C++ under the drift gate, one component per change, so a template change can no longer pass through unseen.
• Bring the generated column references under a gate: Catch a generated reference to a column that does not exist before it merges.
• Model the hand-written IAM tables: Every IAM table that holds data has a model, so the drift check covers it and no table is written by hand.
• Bring every DQ artefact table onto the canonical model: Move DQ artefact tables onto the canonical model: the duplicated ores.dq models and the hand-written artefact tables are generated from the entities they stage, and a guide states the one way to add a DQ artefact.
• Split the ER diagram by group: The ER diagram is split into one file per package plus an index, drawn as SVG, and the relationships inside each group come from the SQL rather than a stale map.
• Bring every subject onto the canonical entity protocol: One gate refuses a subject that is not {component}.v1.{resource}.{verb} with a verb from the closed set of eight, so the rule is enforced rather than remembered.
• Catch the generated artefacts up, and fix a dangling id link: Four local checks fail on main and none of them is a branch's fault, so every branch inherits a red gate.

• Publish the currency groups with Acme: A new tenant, Acme included, holds the desk currency groups and their members after provisioning.
• Publish the ACME reports ready to run: Publish the static inputs an ACME risk report needs through DQ datasets with declared dependencies, so a clean provision leaves every report definition bound to its shared configuration, with its analytics and parameters, and the export names every ORE file from the file types table.
• Quote the offset column in the marketdata identity view: The commodity identity view loads, so the database recreates from the schema.
• Order the structure members after the trades they reference: The trading schema loads, so the database recreates from the schema.

• Clear the local-check failures on main: The local check gate stops failing on drift that predates any branch.
• Run every check locally in one report: One local command replaces the GitHub pull-request wait.
• State the test run's prerequisites: A test run that cannot pass says why before it starts, and the three prerequisites are recorded where the next person looks.
• Make the local checks faster: The local gate stops spending most of its time on work the branch did not touch, so it is cheap enough to run per change.

• Clear the stale block on the literate template task: Return the literate-template task to the backlog, so a workstream that can proceed is not held by a dependency that finished three months ago.
• Add the writing discipline the Zettelkasten page omits: Give the Zettelkasten page the half of the method it does not yet carry: the craft of composing and filing a note.
• Close the sprint's finished stories: Let the sprint table tell the truth about what is in flight: no story says STARTED once every one of its tasks is DONE and every one of its PRs merged.
• Reconcile the sprint's bookkeeping: Take the sprint audit from 41 findings to the two that are real open work, and lose no record doing it.
• Open sprint 27: Sprint 27 exists as a proper agile artefact, with its mission set and wired into the version manifest and the agile index, and the project version carries 0.0.27, with the vcpkg submodule at latest.
• Complete the pattern language: The pattern language is complete: the communication, coordination, resilience, load and data pattern groups are written, each pattern naming its established name and its sources, and a design names its patterns as a rule rather than by memory.
• Record the env format change for the workspace removal: The env format log records version 29 as the removal of ORES_WORKSPACE_SERVICE_DB_*, so older checkouts can upgrade.
• Mop up after the workspace removal: The database recreates from the schema and populate scripts, and no knowledge or manual page describes the deleted workspace component.
• Sprint health review — System 2 analysis: A System 2 review of sprint 27 at its close.

Dual-axis bar chart. PRs (left axis) and commits (right axis) per day. A high commits-to-PR ratio may indicate scope creep.

The sprint peaked at 560 commits on 2026-10-08 and never fell below 277 on an active day. The PR rate rose with it: 122 merged on 10-08 and 119 on 10-09, the two heaviest days. There is no idle day and no single burst — a sustained overrun, not a spike.

Lines added (green) and deleted (red) per day. Building work produces mostly additions; refactoring produces a mix.

Churn ran high and mixed across the window: the shape of codegen and model rework rather than pure addition, because the rates and credit instrument reworks delete the old layout as they add the new one.

Hours from PR open to merge, one bar per PR. Long bars indicate review bottlenecks.

The chart carries only the first twenty PRs the collector returned, all from 2026-10-05 to 10-12, so read it as a sample: those twenty merged in a median 11.9 hours and at most 25.8. The collector cap is a known defect, not a property of the sprint.

Line chart tracking stories marked DONE during the sprint. Steady upward slope is healthy; plateauing signals a stall.

The curve climbs to 146 DONE stories with its steepest rise in the last three days, as the record-screen, instrument and IAM work closed together.