Product · Console
Every decision, the rung that made it, and the confirm behind it.
You cannot revoke what you cannot see. The console is the reference implementation of the kernel: one queue for the work that needs you, one inspector for why anything happened, one page where authority is granted and taken back, and one dashboard that shows what stopped needing the model.
The tour
Eight pages. Nothing you cannot explain.
The console does not seed demo data and does not phone home. What you see is your SQLite file, read through the same functions the CLI uses.
Today
Queue
Decisions
Patterns
Usage
Connect
Agents
Blockers
Queue
One click per work type. One confirm per staged row.
Each agent declares its work types and the button that takes the next one. The queue packs the context, walks the ladder, and shows you only the residual. Staged actions sit beside the item with their own Confirm. Nothing on this page executes until you press it.
- Take the next item for a work type, or open a specific one. The packed context is what the model would have seen.
- Resolve with a choice. The choice is recorded against you as evidence for the learned rung.
- Confirm each staged action separately. Confirm is execution: it enqueues the outbox job in the same transaction.
- Delegate to a teammate from the same panel. The delegation is itself a staged action.
Work types
- Incoming contract4
- Signature request2
- Expiry review7
- Counterparty
- Northgate Pty Ltd · known
- Signature
- counterparty signed · ours missing
- Value
- 18,500 money_legal
- Resolved by
- rule · missing-signature · 0 tokens
Staged
- request_signatureConfirm
Send signature request to legal@northgate.example
- escalate_reviewConfirm
Route to the value reviewer
Decisions
One screen answers why anything happened.
Every Decision carries the winning rung, the versions of the rule and pattern sets it ran against, the tokens it cost, and the human verdict if there was one. A learned fire also carries the pattern id and version, the replay that certified it, and the envelope it fired inside.
- Replay re-walks the ladder at the stored evaluation context. It writes nothing and never calls a model. Match, or the name of the dependency that changed.
- Was this wrong? records a counterexample. The pattern stops firing and the work returns to judgment.
- Historical rows never change. A pattern edited after promotion is replayed against the WHEN and THEN captured at promotion, not the current one.
- d_41c…9e0qualify0structured
- d_9f3…c21triage0learned
- d_a02…77benrich1,140llm
- d_b7e…d13decide0judgment
- Rung
- learned
- Pattern
- renewal-note · version valid
- Replay
- certified against your history
- Envelope
- action · request_signature
- Rule sets
- rules valid · patterns valid
- Tokens
- 0 · input 0 / output 0
- Human verdict
- none
Patterns
Authority is granted here, and only here.
A proposed pattern shows the WHEN it mined, the THEN it would take, and how far through the replay gate it is. Promote is disabled until replay against your own history certifies it. Retire is permanent. Revalidate re-runs the gate and, on a pass, leaves the pattern verified but inert until you promote it again.
Induction runs when you ask it to (engine induce), never on a schedule. Promotion goes through one function in the kernel. The CLI refuses to bypass it, and an imported agent starts with no active patterns.
- proposedPromote
WHEN signature_status = counterparty_signed · counterparty_known = true
THEN stage request_signature
replay in progress · not yet certified
- proposedPromote
WHEN expiry_within_days ≤ 30 · renewal_clause = present
THEN verdict flag · draft renewal note
certified by replay · ready to promote
- activeRetire
WHEN checklist_complete = true · signature_status = fully_signed
THEN verdict allow · file
fired 212 times · binding valid
- suspendedRevalidate
WHEN signature_status = fully_signed · expiry_within_days > 90
THEN verdict allow
revoked on counterexample · skipped at fire time
proposed never fires · promote after replay certifies it · retire is permanent
Usage and conversion
The dashboard and the CLI report are the same function.
There is no summary table and no hand-maintained number. Every figure is recomputed from the decision log as of the evaluation clock, per ISO week. What the dashboard shows is what engine report prints.
Conversion rate
Tokens and cost avoided
Human interrupts
Demotion events
Unsafe fires
Time to first conversion
definitions from docs/conversion-metrics.md · every metric lists what it does not claim
Connect
Credentials in, never out.
Model keys, the Gmail refresh token or IMAP password, and every connector secret are written to the encrypted store with AES-256-GCM and read by key name at execution time. The console never prints a secret and a connector YAML that inlines one fails doctor. Connector calls are HTTPS only, resolved against a private-address guard, with bounded bodies.
Agents
Describe the work. Approve the simulated week.
An agent is a folder of YAML, but you never have to read it. The interview writes a draft, doctor validates it and names the file and the fix when it is wrong, and simulate replays synthetic history with the model mocked to produce the report you would have received on a Tuesday. You approve the simulation. Local SQLite is go-live.
Login and roles
The console runs on a single-tenant appliance behind your network, or embedded via the SDK. OIDC login through your identity provider gates every route, with viewer, approver, and admin roles, and every confirm, dismiss, promotion, and retirement is attributed to a named user. Hosted instances for the small tiers are on the launch plan.
Bring the traffic. We will show you the queue.
Design partners run the console against their own decision stream. The patterns page fills with proposals from your own decisions, and the conversion line is computed from the same log.