Two consoles, one platform

TL;DR

Lilac ships two consoles. Providers run their fleet in one: intake, burn-in, acceptance, assignment, metering, incidents. Customers run their nodes in the other: images, SSH keys, rebuilds, dashboards, alerts. Both are clients of the same API, so anything a human clicks, a machine can script.

---

The provider workspace

Onboarding a fleet starts with two artifacts: a delivery manifest and BMC access. Upload the manifest and every node in the shipment exists in the platform, serials and all, from the moment it hits the dock. Hand over BMC credentials and the platform can reach each node out-of-band, below the OS.

From there, the workspace is mostly something you watch. Nodes move through imaging, then burn-in, then acceptance. Burn-in runs the machine hard on purpose: GPUs, interconnect, storage, and thermals under sustained load, because a marginal node should fail in week zero, not in a customer's training run. Acceptance is the gate that matters commercially. A node bills only after it passes. Until then it is inventory, not product.

Accepted capacity is assigned to a customer from the same screen. Pick the nodes, apply the customer's network parameters, and the platform handles the plumbing. When a customer releases capacity, nodes are securely wiped and re-verified before anyone else touches them. When the billing period closes, export the metering: reserved GPU hours per node, with the state history behind every hour, ready to attach to an invoice.

Incidents work the way operators wish they always did. An alert arrives with the node's full timeline attached: what tripped, what the node was doing, every prior event on that serial. When the diagnosis points at hardware, a ticket opens automatically with the diagnosis in it, and a hot spare can rotate in while the failed node goes to repair, with the swap recorded for billing. The technician starts from the failing component, not from "node down."

The customer console

The customer side is deliberately boring, in the way good tools are boring.

You see your nodes: state, health, and history, live. You pick an OS image. You add SSH keys. You rebuild a node yourself, from the console, without filing a ticket or waiting for a human. Lilac's first self-serve moment was an inference API key; this one is a bare-metal rebuild.

Dashboards show health and usage as it happens, per node and across everything you rent. When something breaks, the alert reaches you within seconds, carrying the same telemetry the provider sees. You should never learn about a hardware failure from your own training job.

One API underneath

The design rule is strict: both consoles are clients of the same API. There is no staff-only backdoor, no endpoint the UI can reach that your scripts cannot. Anything a human clicks, a machine can script: enroll nodes, trigger rebuilds, pull metering exports, subscribe to alerts. The consoles are reference clients, not the product boundary.

The same rule means support runs both ways between the two sides. A customer reporting an incident and a provider investigating it are reading the same timeline, so the conversation starts at the diagnosis instead of at screenshots. A provider scheduling maintenance is looking at the same window the customer's console shows, the same window the billing clock-stop applies to. Same events, two views, no translation layer.

The metering both consoles export comes from the ledger we described in billing-grade metering: append-only history, reproducible reports, evidence both sides settle against.

And the platform underneath keeps learning. Every fleet it runs teaches it new failure signatures, and every next fleet inherits the catalog. Two consoles, one platform, one operating record.