Infrastructure
Inherit the journey, not just the state.
Your infrastructure tells you where it is on its own trajectory — not just whether resources match. describe state returns each dimension’s current → desired with the blocker and catalyst between them; describe connections maps how one action depends on the next. The infra is structured as a DAG that carries sense, journey, and perspective, with declared actions that reproduce — so HA and resilience rise to another plane: a property of a system that knows its own state and how it got there, not redundancy bolted on.
The operator who inherits infrastructure cannot see its trajectory. IaC tools answer one question — does reality match the desired resource set? — and that diff is real but shallow: it shows the current shape, never how the infra reached it, which dimension is mid-transition, what blocks the next step, or why one action depends on the next. So evolving inherited infra means reverse-engineering intent from config, under incident risk.
Resilience suffers the same blindness. When HA is bolted on as redundancy and failover without the system knowing its own state and journey, recovery is a guess: you restore resources without restoring understanding. The relationship between actions — the cohesion that makes the whole behave predictably — lives in the heads of the people who built it, and leaves when they do.
ontoref · provisioning
What it is
Provisioning is the domain of infrastructure that knows its own trajectory. A workspace declares what is built and in what order as a typed DAG; every action is a declaration that reproduces, and the platform records where each dimension is, where it is going and what blocks the next step.
Why
Whoever inherits infrastructure sees its current shape and not how it got there. When the relations between actions live in the heads of the people who built it, recovery is a guess: resources are restored, the understanding is not.
What for
A workspace binds to the domain and takes its schemas, its catalogue and its engine. The capabilities below are what the provider declares it carries, each with the decisions behind it; the relations are the ones its ontology records between them.
Architecture
What the platform carries and how it holds together
Hover or tap a capability, or pick a card below, to see only its relations; a picked card keeps its route on the map until it is picked again. A relation is an edge the provider's ontology declares between the capabilities' nodes.
The platform
Capabilities, each with its decisions
Workflow
A change of infrastructure, from its declaration to its record
From a declaration to its record: one change of infrastructure through the domain. Nothing is applied that the schema and the catalogue have not checked, nothing runs that is not signed, and every applied operation leaves its trace in a ledger that only grows.
Capabilities read from the provisioning provider's manifest and relations from its ontology when this page was generated; every step cites the provisioning decision or mode that governs it.
The prize, once inside
When your reason for being is verifiable and not just declared, holding your course stops costing effort.
· reads
Perspectives