Osmiron / Developer documentation
Plan and optimize how operations change.
Osmiron is an operational model and optimization engine for software products. It uses a typed digital twin to find feasible plans, compare them by cost and other measures, and test how they respond to disruption.
- State
- Versioned and traceable
- Plans
- Feasible before optimal
- Results
- Inspectable by design
Target decision flow
From live state to a plan that can survive disruption.
The model defines the operation before the planner compares possible futures.
- 01Connect state
Read the records that matter and preserve their identity and source.
- 02Build the twin
Keep a durable and replayable model of the current operation.
- 03Define change
Describe permitted mutations, requirements, and resource limits.
- 04Set the goal
Declare the desired state and measures such as cost, time, or risk.
- 05Compare plans
Find feasible sequences and make their trade-offs explicit.
- 06Stress-test
Apply disruptions and expose the dependencies that can make a plan fail.
Current development scope
Build the operational model first.
The first release focuses on durable state ingestion, replay, local source-aware validation, and bounded exploration through Console, CLI, REST API, and agent tools.
The current checkout does not yet simulate operations, generate or select plans, run stress tests, or optimize decisions. Those capabilities come after the operational model is durable and reproducible.
Osmiron keeps confirmed state separate from proposals and predicted results. Selecting a plan does not make its predicted state true. An approved change or an observed result must update the digital twin.
Start here
Choose a developer surface.
Check an OSL source file from this repository.
02OSLDefine operational state, constraints, permitted changes, and goals.
03Model boundariesSeparate confirmed state, proposed plans, and observed results.
04API referenceInspect the customer-facing contract when a generated schema is available.