Guide

Every surface, explained

What each page shows, where its numbers come from, and what to try next. Read it top to bottom, or jump straight to the page you have open. The math itself lives on the Methodology page.

On this page

HomeAgentsAgent detailValueCash ledgerCapacity logGradeBaselinesRate cardsAudit packReportsFindingsMethodologySettingsPersonas

Home — /dashboard

Two numbers, two units, never one

The dashboard leads with two headline cards: Cash saved, in dollars, and Capacity created, in hours. They are deliberately separate units and are never blended into one figure — that is the two-unit rule the whole product enforces. Cash saved is the month's GL-backed cash entries, net of the attribution haircut. Capacity created is the hours of work your agents absorbed this month. Below them, the trend charts show how the month accrued entry by entry, and the performance panel reports each agent across five fixed categories — quality, latency, cost, reliability, drift — each on its own scale, with no composite score.

Try this

  • Click the Cash saved card — it drills into the cash ledger, where every dollar has a GL event behind it.
  • Hover any small info icon. Every number on this page explains its own derivation and links to the relevant methodology section.

Agents — /ai-agents

The inventory of every AI system

Each row is one registered AI system: name, type, owner, business unit, status (active / paused / retired), health, and outputs over the last 7 days from observed telemetry. Agents are not created by hand in the console. An agent registers itself the first time it sends a telemetry event carrying a stable fingerprint — emit one HTTP telemetry event from the agent's runtime and the record appears here with a durable identity. That keeps the inventory a record of what actually runs, not what someone remembered to type in.

Try this

  • Press Register agent to see the fingerprint flow — the exact event an agent emits to enroll itself.
  • Click any row to open the agent's detail page: its risk tier, value claims, and spend.

Agent detail — /ai-agents/[id]

One agent's risk, value, and spend

The detail page carries three threads. Governance: the risk tier (low to critical, set at registration from the system's decision authority and blast radius) and the review policy it drives — human-in-the-loop, sampled, or autonomous. Value: the agent's value claims, each born self-reported and raised one rung at a time up the Credibility Ladder (self-reported, then validator-confirmed, then audit signed-off). Promotion is server-set and gated by segregation of duties — the author of a claim can never promote their own work, so a rung on the ladder always means a second person looked. Spend: per-provider monthly spend records, ingested over the same telemetry channel the agent registered through, keyed by its fingerprint — so cost attribution follows the agent's identity, not a spreadsheet.

Try this

  • Promote a value claim while signed in as Lin (governance). Then try promoting a claim you authored — segregation of duties blocks it.
  • Log a spend record for a provider and watch the agent's cost-versus-return picture update.

Value

The value ledger, split into four focused views

Value in the sidebar opens the ledger, which is deliberately split into four pages rather than one blended screen: the cash ledger (dollars, GL-backed), the capacity log (hours), the grade (how defensible the numbers are), and baselines (the pre-deployment evidence). The dollar side and the hours side never merge — each view answers one question with one unit.

Try this

Cash ledger — /cash-ledger

Every dollar with its source and GL event

Each row is one cash entry the customer attests is AI-caused, in one of five categories: GL delta, cancelled subscription, avoided backfill, cut overtime, reduced contractor. Open a row and the drill-through shows the full provenance: the GL event it ties to, the rate preserved as a derivation (GL extract, unit definition, allocation, utilization, finance signature — never a bare number), and the attribution chain naming the baseline, the counterfactual, and the residual band. The headline is the sum of entries with the attribution haircut taken out; the withheld amount is shown, not hidden, along with the rationale for the haircut on each entry.

Try this

  • Open any row and follow the rate back to its GL extract — the whole derivation is on the entry, not in a footnote.
  • Compare the realized figure with the withheld figure at the top: the gap is the attribution haircut, disclosed per entry.

Capacity log — /capacity

Hours, never dollars

The capacity log records the hours of work your agents absorbed this month, attributed per agent from metered outputs times a customer-stated baseline time per output. Capacity is reported in hours and is never multiplied into dollars at the headline. The Pending conversion figure is the hours waiting on a payroll event — capacity becomes cash only when the hours reconcile to a specific GL event, at which point the dollars appear in the cash ledger with full provenance.

Try this

  • Check Pending conversion — those hours are real work absorbed, but they stay in hours until payroll confirms them.
  • Compare the per-agent hours here with the same agents' outputs on the inventory — capacity follows telemetry, not estimates.

Grade — /grade

Two measurements, reported as a pair

The grade tells you how defensible the headline is, on two separate axes: count coverage (how much of the headline volume comes from metered counts rather than estimates) and rate provenance (how much of the dollarization rests on finance-signed rates rather than assumed ones). They are never averaged into a single letter, because a high count with weak rate provenance is a different risk than the reverse. The grade is a self-assessment until an independent party reviews it, and the page says so.

Try this

  • Read the two scores side by side and ask which is weaker — that is where your next hour of evidence work goes.

Baselines — /baselines

The evidence captured before the agent went live

No cash is credited to AI without a pre-deployment baseline, and a baseline is two records, not one. B3 is the shadow run: a paired, customer-signed comparison of the work with and without the agent. B4 is the independent 12-month sample: a third party verifies the pre-agent run-rate the savings are measured against. Both must be present and signed before the first cash entry — this is the contemporaneous control group the attribution rests on, captured when it still could be.

Try this

  • Check the two sign-off columns on any baseline row — the shadow run's customer sign-off and the 12-month sample's independent verifier are separate people by design.

Rate cards

A rate is a derivation, not a number

A rate card on AgentX is five artifacts, not one figure: the GL extract that produced the rate, the denominator definition, the allocation basis, the utilization assumption, and a finance countersignature. Rate cards expire on the budget cycle and must be re-signed. You meet them where they do their work — on each cash-ledger entry's drill-through, where the full derivation sits behind every dollarized row. The methodology behind them is documented on the Methodology page.

Try this

  • Open a cash-ledger entry and expand the rate — all five artifacts are attached to the entry itself.
  • Read the rate-card methodology for why a bare number would not survive an audit.

Audit pack — /audit-pack

The sealed export your auditor can verify

An audit pack bundles a reporting period's evidence — the cash ledger, capacity log, baselines, rate-card derivations, and structural-value attestations — into one file sealed with a signature. The signature is a deterministic hash of the pack's contents: re-running the export over the same inputs reproduces the same signature byte for byte, so an auditor can independently confirm nothing was altered after sealing. Generate one at the close of a reporting period. Generation is restricted to the admin, governance-lead, and attestor roles — segregation of duties applies to the export, too.

Try this

  • Generate a pack at /audit-pack/new (as Dana or Lin), then note its signature in the list.
  • Try the same as Kim — her owner role cannot seal packs, and the page tells her exactly why.

Reports

What leaves the building

The Reports section of the sidebar collects the artifacts meant for eyes outside the day-to-day console: the audit pack (the sealed period export above) and findings (open governance findings across the organization, tracked to resolution). Everything under Reports is built to be handed to an auditor, a regulator, or the board — signed, dated, and reproducible.

Try this

  • Open Findings to see what governance has flagged org-wide and what has been resolved.

Findings — /findings

What governance flagged, and what happened next

A finding is a flagged risk against a specific agent — measured (drift past a threshold, a latency regression, cost trending up) or declared (an overdue attestation, a policy gap). Each finding carries the rationale for why it was raised and a disposition history. Governance leads and admins acknowledge and resolve findings with a note; everyone else can read them. An open finding is not a failure — an aging one with no owner is.

Try this

  • Sign in as Lin (Governance), open a finding, and resolve it with a note — the action lands in the audit trail like every other mutation.
  • Click a finding's agent to jump to its detail page — the same risks appear in the agent's Open Risks table.

Methodology — /method

Where the math lives

Every formula this guide alludes to is written out on the Methodology page: the headline derivation and the haircut band, the capacity-to-cash rule, the baseline requirements, rate cards as derivations, the two-axis grade, the four company-size modes, structural value, and what an auditor can verify step by step. If your auditor asks how a number was derived, that is the document to share.

Try this

Settings — /settings

Who can do what

Settings holds your account, appearance, and — for administrators — the team roster: each user's role and business-unit scope, editable inline. Access is governed by nine roles with segregation of duties: elevated roles are gated (only an administrator or governance lead may assign the administrator or governance-lead role), business-unit scoping limits owners to their own agents, and the SoD reference on this page states each rule the backend enforces. Cross-organization data is never visible — every tenant is fully isolated.

Try this

  • As Dana, open Team & roles and add a business unit to a user — the change is audited like every other mutation.
  • Read the segregation-of-duties reference and match each rule against something you tried earlier (claim promotion, pack generation).

Personas

Three logins, three views of the same organization

The sandbox ships with three seeded users on the Brightoak demo tenant, one per vantage point, so you can see how the same console renders per role. Dana is the administrator: every agent, all users, and org-wide settings. Lin is governance: risk findings, structural attestations, and audit packs across all agents — and the second signature that segregation of duties keeps asking for. Kim is an owner: only the Operations agents she owns and their value loop. The credentials are on the sign-in page.

Try this

  • Sign out and back in as each persona in turn. Watch what disappears for Kim and what only Dana can touch — that difference is the RBAC model.

Want the math? Read the Methodology. Have buyer questions? The FAQ answers the ones a careful buyer asks.

Ready to walk it yourself? Explore the sandbox.