Skip to main content
The Console is Wardin’s off-rail control plane — everything that changes how requests get handled, as opposed to the Request Path rail, which only shows you what already happened to a request. Open it from the CONSOLE button in the header, or the square node next to the six rail diamonds.

​
Placement rule

Every screen in the product answers exactly one of two questions, and that answer decides where it lives:
  • “What happened to a request?” → a rail stage (INGRESS, POLICY, ROUTE, LEDGER, EVIDENCE, OUTCOMES).
  • “How do requests get handled, or what does the org offer as a capability?” → a Console section.
A rail stage can still surface a read-only glance of a Console value — for example, ROUTE shows the live cache similarity threshold and per-key spend — but changing that value always happens in the Console, never on the rail.

​
Console groups

Console sections are organized into three groups:

​
Shipped vs. roadmap

Every Console section is honestly labeled — a section that isn’t built yet is marked SOON, never presented as if it were live.
This table mirrors the Console’s own section index in the app — if a section here says SOON, the in-product Console shows the same dashed placeholder rather than a working control.