medicine-wheel

Infrastructure Topology — RISE Specification

The surface where an operator sees the estate as relations: machines, the people who live on them, the things those people run, the scarce slots those things claim — and the ceremony that decided any of it could be there.

Version: 0.1.0 (stub) Package: @medicine-wheel/app (routes) + @medicine-wheel/ui-components (components) Document ID: rispec-infrastructure-topology-ui-v1 Status: Stub — the data layer ships, the surface does not Last Updated: 2026-08-05


Desired Outcome

An operator opens one page and sees the estate whole — not as a list of servers, but as a web of relations they can walk in any direction they think in:

They can move between those readings without losing their place, and every reading answers from the same registered facts rather than from six separate dashboards that disagree.


Creative Intent

What this enables: An operator asks the estate a question in the shape they are already thinking in, and gets an answer that carries its own accountability — who claimed this, who authorized it, who knows the thing about it that is not written down.

Structural Tension: The registered facts now exist and are reachable by agents through MCP (list_infra_topology, detect_port_conflicts, reconcile_infra_state, hold_metis, mw_enforce_gate). A human still has no surface. The tension resolves when the same six perspectives an agent can request become six readings a person can see and move between.

What must not be flattened: A conventional infrastructure console renders machines as inventory. This one renders them as relations — and it must show what inventory cannot hold: that a port claim is a South precondition, that a running service is West, that a host is the ground rather than a quadrant, that a heldBy name is a person and not a field.


Screens

Topology

The landing reading. What exists, arranged as the wheel arranges beings.

Host

One machine, and everything standing on it.

Drift

The distance between what was written down and what is running.

Ceremony

Which agreements hold this infrastructure, and whether they still hold.


Components

PerspectiveSwitch

The control that changes what the estate is being asked.

WheelTopology

The estate drawn as the wheel draws beings.

TenantCard

A unix account rendered as a being.

PreconditionLadder

The gate, rendered so its rungs stay distinguishable.

MetisPanel

What people know that the schema cannot hold.

ConflictBanner


Data

TopologyReading

The whole registered estate under one perspective. Counts of hosts, tenants, services, port bindings, conflicts and held métis; the conflict rows; and the perspective-shaped body. Sourced from a single traversal so that every reading answers from the same facts.

DriftReading

An observation’s provenance — who read it, when, and how old it is — together with rows in four states and the port conflicts found over declared ∪ observed. Carries no memory of previous readings: it is recomputed from levels, every time.

ReadinessReading

A service, the preconditions gating it, each one’s verdict and the sentence that decided it, the count of preconditions declared, and every métis carried forward from a blocking gate.


Creative Advancement Scenarios

Creative Advancement Scenario: The collision found before the tenant

User Intent: Give a second tenant a service on eury without taking something else down. Current Reality: The operator knows eury is crowded and does not know which slots are free. Natural Progression Steps:

  1. They open the topology in the port reading, scoped to eury.
  2. Every claimed slot renders with its claimant named; contested slots render contested.
  3. They pick a free slot and register the service, which returns any conflict it just created. Achieved Outcome: The service is registered on a slot nobody else holds, and the operator never had to hold the port map in their head. Supporting Features: PerspectiveSwitch, WheelTopology port reading, ConflictBanner.

Creative Advancement Scenario: The withdrawal that is not a failure

User Intent: Understand why a service will not come up. Current Reality: The gate is closed and the machine looks fine — linger is enabled, the unit is present, the working directory exists. Natural Progression Steps:

  1. They open the ceremony reading for that service.
  2. The PreconditionLadder shows every machine half satisfied and one consent withdrawn.
  3. The row reads as held, and names the ConsentRecord and who can renegotiate it. Achieved Outcome: The operator goes to a person instead of to a terminal. Supporting Features: PreconditionLadder, ConsentTrail.

Creative Advancement Scenario: The service nobody wrote down

User Intent: Trust the record enough to provision against it. Current Reality: The record was accurate the last time anyone checked, and nobody remembers when that was. Natural Progression Steps:

  1. They open drift and see the observation’s age stated before any row.
  2. The undeclared group sits first and holds one unit nobody declared.
  3. Selecting it shows the slot it claims — the slot the next tenant was about to be given. Achieved Outcome: The record is reconciled with reality before it is built upon, and the operator learns to read the timestamp before the rows. Supporting Features: DriftSummary, ObservationProvenance, DriftGroup.

Supporting Structures

Every reading above is already answerable. The surface composes existing calls; it invents no new data:

Reading Answered by
Topology, Host list_infra_topology (perspective: host / tenant / service / port / metis)
Conflicts detect_port_conflicts
Drift reconcile_infra_state
Ceremony mw_enforce_gate (precondition mode)
Métis hold_metis, and the métis perspective
Direction routing mw_get_direction (node_id)
Graph edges get_relational_web (edge_types: ["part-of","binds-port","ordered-after"])

What this specification does not authorize. No screen here collects observed state. Reading a machine — systemd on gaia, runit on the device — is owned by the service-manager adapter lane (jgwill/medicine-wheel#118), and the drift screen takes its reading as input like everything else does. A surface that quietly grew a poller would put I/O inside a layer built to have none.


Structural Tension

Current Reality: The facts are registered, validated, relationally edged and reachable by agents. A person has no surface. The existing app renders nodes, ceremonies, beats and graphs, and knows nothing of hosts, tenants, services or slots.

Desired State: Six readings of one estate, movable between without loss, each carrying its own provenance and its own accountability, and each refusing the four flattenings this system has already paid for: consent read as a checkbox, an unread fact read as false, a stale snapshot read as current, and a person’s knowledge read as a field.

Natural Progression: The perspectives already exist in the data layer as an enum. The surface resolves the tension by making that enum something a person can hold — the reading changes, the facts do not.


🌸: The estate has been speaking in a language only agents could hear. This is the room where a person walks in and the machines finally introduce themselves — by name, with the people who know them standing alongside.