Skip to content

Work in the operator console

The console is where you see what FDAI is doing. It shows incidents, pending approvals, running processes, scheduled work, provisioning progress, and the evidence behind every decision. What it never does is change your cloud.

This guide maps the areas you’ll actually use, tells you which ones accept a request, and explains the boundary that makes a browser session safe to leave open.

Every panel reads. The console’s API client has no create, update, or delete helpers at all, and the console never receives the executor identity. When you submit something from the console, you are filing a governed request that re-enters the normal pipeline, not triggering a change.

That design has a practical consequence worth internalizing: a compromised browser session can’t change your infrastructure. It can read what that person was allowed to read. Execution authority lives with the executor identity, which no browser ever holds.

AreaWhat you do thereCan you submit?
Overview and liveSee current control-plane activity at a glanceNo
IncidentsInspect open incidents, their members, timelines, and linked analysisNo
ApprovalsReview work waiting on a person, with its evidence, quorum, and deadlineYes, a decision
Agent activity and pantheonWatch which agent is handling what, and inspect agent rolesNo
ProcessesBrowse process runs, rendered views, and journal eventsYes, on specific process routes
Scheduler runsInspect scheduled task dispatch attemptsNo, and it can’t retry or cancel a task
ProvisioningWatch provisioning progress as it streamsNo, it never executes provisioning
Onboarding and readinessCheck what is still missing before a capability is usableNo
InvestigationsStart and read bounded Azure investigationsYes, a read-only investigation
Audit and traceFollow a correlation ID through every recorded stepNo
Rules, ontology, and promotion gatesInspect what FDAI knows and what is allowed to runNo
Agent oversightSee ownership, human dependencies, and submit an ownership handover proposalYes, a proposal
SettingsView runtime, model, memory, integration, and identity configurationYes, on identity and access

Approvals is the one place where your click carries a real decision, and even there the decision is re-authenticated and re-checked on the server before anything runs. See Approve a change for that flow.

The console shows what your role allows and hides the rest, but the server is what actually enforces it. Every request carries your identity, and the check happens again on arrival.

  • Reader sees state, evidence, and audit history.
  • Contributor adds the ability to start a bounded investigation and to author a draft change.
  • Approver adds approval decisions on work waiting for a person.
  • Owner adds identity, access, and runtime settings work.

A narrower view in the console is a convenience, not the boundary. Someone who calls the API directly still gets the same answer, because the capability check doesn’t live in the browser.

Two habits keep you from over-reading a screen:

  • Check freshness before you trust a number. Panels project stored state. A quiet incidents list can mean a quiet estate, or a projection that hasn’t caught up.
  • Treat a missing value as unknown. The console shows unavailable evidence as unavailable rather than filling in a zero, and that distinction is usually the important one during an incident.

A federated Tasks view that gathers work across domains, along with cross-domain projection metadata, is proposed rather than built. Today you move between the domain areas above rather than working from one combined queue.

To learn aboutRead
How to act on work waiting for youApprove a change
How to follow a decision end to endRead the audit log
How to ask a bounded question about a resourceInvestigate an Azure resource
Who is accountable behind each agentAgent ownership
Why approvals never travel through the console identityApprovals and channels
The full console contract and route mapConsole operations