Product Identity
Table of Contents
This is the product identity of ORE Studio — the System 5 document in our
cybernetic information architecture, where identity is the durable policy layer
that constrains every level below it. It is the statement of what the product
is and what it is not; it predates any version and outlives every release.
Everything else under doc/ — sprints, stories, tasks, captures — is filtered
through this page when deciding whether a candidate idea belongs in the product
backlog at all. If you are looking for instructions on how to use the
product, see the user manual instead.
Figure 1: ORE Studio v0.0.17 — the main window, an early implementation of the vision below.
Vision
Here we define the vision for the product — what guides us when we think about ORE Studio and what can and cannot go into the product backlog. Vision is one facet of identity: it states what we are building toward.
Vision statement
The vision for ORE Studio is to build on top of Acadia's Open Source Risk Engine (ORE), which itself builds on QuantLib, with the aim of providing:
- a persistent database storage for all of its inputs and outputs;
- a graphical user interface both for data generation as well as data exploration;
- the ability to configure and orchestrate ORE execution.
Vision quote
People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I'm actually as proud of the things we haven't done as the things I have done. Innovation is saying no to 1,000 things. — Steve Jobs
Audience
ORE Studio exists to lower the barrier to learning quantitative finance through hands-on building. The primary barriers are access: real market data is proprietary and expensive; production quant models live inside institutional systems; the infrastructure of an enterprise risk platform tends to obscure rather than reveal the underlying domain. ORE Studio addresses these by providing synthetic and generated market data, delegating all quantitative mathematics to ORE and QuantLib, and keeping the architecture intentionally simple (client → service layer → Postgres) so that domain concepts stay visible rather than buried.
The target is the software developer — moderately fluent in C++ or a similar systems language — who wants to understand how computational finance works by building and extending a real system. Not by reading textbooks, not by running spreadsheets: by modifying code, running ORE, and observing what changes. A secondary audience is the developer already familiar with ORE or QuantLib who wants a graphical environment for exploration and experimentation.
ORE Studio is independent of both ORE and QuantLib and has no affiliation with either project or any financial institution.
Out of scope
What ORE Studio is not — equally important to what it is.
- A professional, enterprise-grade risk system. ORE Studio follows Karpathy's "learning is enmeshed with the act of building" principle; production-grade performance, multi-user features, and cloud deployment are explicitly out of scope.
- A reimplementation of ORE or QuantLib. ORE Studio wraps them; their models, conventions, and limitations are inherited as-is.
- A pricing or risk authority. Numbers come from ORE / QuantLib; ORE Studio is the surface through which they flow.
Relationship to versions and milestones
The product identity is durable. Versions and milestones are not. v0
establishes the shape; v1.0 and beyond will extend it. When something in this
document changes, that is a re-identification — not a version bump.
See the Roadmap for the user-facing narrative of where the product is and where it is going, Versions for the running list of versions that have implemented this identity, and Milestones for the major release targets bounding each version series.