OTO
oto

The product lifecycle in the Studio

A product moves through six phases, and every phase is a set of facts in the same graph. Nothing is a document beside the product; everything is the product's graph, read in the Studio. The screens below are OTO Studio, in alpha, on one product of a sample motor insurer. The traceability runs the whole way: an outcome is realised by a journey, a journey by use cases, a use case by requirements, a requirement by components, a component by tests.

EnvisionDiscoverDesignBuildOperateRealize

Envision

The problem and the opportunity, stated and sourced: the stakeholders, the outcome the product exists for, and the target it is measured against.

Envision: the problem statement and the opportunity, as facts with their sources
Envision. The problem statement and the opportunity, each a fact with its source.

Discover

Personas, journeys, use cases, requirements including the non-functional ones, and the policies that constrain them. A journey is told as an arc, tied to its persona and realised by use cases.

Discover: a user journey told as an arc, tied to its persona and realised by use cases
Discover. A journey as an arc, with its persona and the use cases that realise it.

Design

Where the architecture lives, as facts: the bounded contexts and how they relate, the system in its world, the decisions with their status, the components with the requirements each implements, the stack and the resources each binds to.

Bounded contexts of the product, each core, supporting or generic, with its use cases
Bounded contexts. Each a boundary where one model and one language hold.
The system map: the product in its world with actors and external systems
System map. The product in its world, actors and external systems.
Design decisions as architecture decision records, each with its status
Decisions. Architecture decision records with their status.
Components to build, each implementing its requirements
Components. Each implementing its requirements.
Stack and resources: environments and the resources each module binds to
Stack and resources. The environments and the resources each module binds to.

The spec skill writes a design from the graph and lists the decisions it makes in a shape that becomes decision records, so the next design starts from recorded decisions instead of re-deciding them.

Build

Platform, components, integrations, agents, and the tests that gate a release: acceptance tests in given-when-then form, each linked to the requirement it proves.

Build: acceptance tests in given, when, then form, each passing
Build. Acceptance tests in given, when, then form, each passing, each tied to its requirement.

Operate

Deployments, incidents, runbooks, and what changed in production and when. The sample product has no operating history yet, so the Studio's Operate phase is empty for it; the runbooks and deployment records of the software estate example are what fills it.

Realize

The KPIs and OKRs, the value realised against the target, rolled up from the lifecycle graph, and the go-forward decision.

Realize: value realised against the target, rolled up from the lifecycle graph
Realize. Outcomes against targets, the value realised, the source of every number.

Under the screens

Each phase mints its own nodes in one graph per product, built by the engine like any other: proposed by the agent, gated, compiled, served. An internal tool is a product too, with the same six phases. A product through its lifecycle says what enters the graph at each phase; the product-delivery ontology that names those classes is in preparation.