This page explains how to read the P2P Mission Control surface end to end. Use it before the workshop so every tester interprets the same KPIs, signals, queues, drawers, agent traces, evidence, policies, actions, value, and learning in a consistent way.
The page should be experienced as a progressive decision journey, not as a wall of widgets. The right sequence is awareness, investigation, decision, action, outcome, and learning.
This is the first control block on the P2P page. It exists to answer whether the queue is safe to automate, where human judgment is still required, and whether each decision can be reconstructed later. Read it before opening the work queue.
| Item | How to interpret | What the drawer should prove |
|---|---|---|
| Governed Decisions | The number of live P2P decisions that remain under human governance because policy, evidence, duplicate risk, amount, or authority boundaries prevent straight-through release. | The drilldown should show the exact cases, supplier, amount, hold reason, confidence, owner, and the agentic chain that stopped automation. |
| Value Awaiting Judgment | The total value currently blocked behind analyst or supervisor judgment. This is not automatically money saved; it is exposure that must be reviewed before release, hold, escalation, or exception approval. | The drilldown should reconcile the value to named invoices, show currency, risk reason, due date, supplier impact, and what happens if the decision is delayed. |
| Replay-Ready | Cases with enough source lineage, evidence, policy evaluation, and decision trace to reconstruct why the recommendation was made later for audit or supervisor review. | The drilldown should show evidence pack ID, source records, policy checks, agent steps, human actions, missing evidence if any, and replay status. |
| Duplicate-Sensitive | Cases where duplicate-risk signals exist, including similar supplier, invoice number, amount, PO reference, tax value, payment window, or supplier resubmission patterns. | The drilldown should show candidate duplicate transactions side by side, matching factors, confidence, exposure, root cause, and recommended hold or supplier validation action. |
Executive KPIs provide leadership awareness. They are not the agentic fabric themselves; they are the presentation layer for what the fabric found, checked, governed, and made replayable.
| KPI | How to interpret | What the drawer should prove |
|---|---|---|
| Value Protected | Exposure prevented before release across duplicate, off-contract, and authority-bound payment risk. | Named transactions, value basis, evidence pack, agents involved, and action status. |
| Cash Timing Opportunity | Working-capital timing available through terms, discounts, sequencing, and treasury payment windows. | Invoices, supplier terms, due dates, discount windows, treasury timing, and recommended sequencing. |
| Judgment Load | Human-controlled decisions that cannot be safely automated because policy, evidence, or authority boundaries apply. | Case list, owner, reason automation stopped, confidence, and required decision. |
| Autonomy Posture | How much routine checking is automated while payment release remains governed and replayable. | Autonomous checks, human-approved actions, human-controlled decisions, and boundary rationale. |
| Evidence Coverage | Cases carrying source lineage, evidence packs, or replay-ready decision traces. | Evidence completeness, source records, missing proof, and replay status. |
| Learning Signals | Reusable operational patterns detected across late invoices, duplicate risk, policy holds, and supplier behavior. | Pattern, source cases, confidence, next recommended control, and memory update. |
Operational KPIs sit behind the executive view. They help a P2P leader understand process health, workload, control coverage, supplier impact, and where operational pressure is building.
| KPI | How to interpret | What the drawer should prove |
|---|---|---|
| Invoice Volume | Process load and workload pressure. High volume is not automatically bad, but it increases exception and staffing pressure. | Volumes by region, business unit, supplier, aging, and exception category. |
| POT Volume | Payment-on-time performance by item count. It shows how many payments are on time, not whether the highest-value payments are protected. | On-time and late items, root causes, team owner, and supplier impact. |
| POT Value | Payment-on-time performance weighted by value. This reveals whether high-value payments are being delayed or protected. | High-value payment list, value aging, supplier impact, and treasury timing. |
| ADP | Average payment timing. Interpret together with supplier terms, discount windows, and working-capital posture. | Payment terms, actual payment dates, cash impact, and supplier trust risk. |
| PO Coverage | Share of spend or invoices linked to purchase orders. Low coverage means weaker control, poorer evidence, and more policy risk. | Non-PO invoices, cost centers, suppliers, breached policies, and recommended remediation. |
| Paper Invoices | Manual or unstructured intake. Higher paper share usually increases cycle time, evidence gaps, and duplicate risk. | Source channel, region, supplier, extraction confidence, and automation opportunity. |
| Payment Leakage | Potential value leakage from duplicate, off-contract, wrong-term, or policy-bound payment exposure. | Transaction list, leakage type, evidence, value protected, and recommended hold or recovery action. |
| Working Capital | Cash timing opportunity. It is not a simple saving number; it represents timing, terms, and sequencing choices. | Terms, due dates, discounts, payment windows, forecast impact, and execution recommendation. |
Each visible block should either guide attention, explain a decision, prove trust, generate action, attribute value, or capture learning. If it does not do one of those, it is decoration.
How to interpret: The live threat is the story anchor. It should show the single case most worth discussing now, such as a blocked high-value invoice or duplicate-sensitive supplier release.
What click-through should prove: Open the case drawer to inspect situation, source transaction, duplicate or policy reason, evidence, and the next governed action.
How to interpret: This is the operational triage strip. It separates SLA pressure, escalations, value awaiting judgment, and replay-ready cases before the user enters the queue.
What click-through should prove: Open the drilldown to see the exact cases behind the count and why each item needs attention.
How to interpret: Signals are not generic alerts. They are operation changes that require investigation, such as duplicate risk, supplier SLA breach, policy exception, or approval bottleneck.
What click-through should prove: Click a signal to move from alert to decision, then inspect evidence, policy, causality, and response path.
How to interpret: This proves what the agents are doing before the human decides. KPIs are presentation; the fabric is the chain of agent work behind the case.
What click-through should prove: Open the trace to see signal detection, context assembly, evidence resolution, policy evaluation, impact simulation, judgment formation, and action generation.
How to interpret: Decision crates are the primary work area. They should show situation, impact, confidence, recommendation, status, and source case without forcing a user into raw tables.
What click-through should prove: Use View case for the full decision drawer and View decision formation when a technology or governance leader asks how the recommendation was formed.
How to interpret: The drawer is where credibility is established. It should not be a generic detail panel; it should explain this selected case only.
What click-through should prove: Inspect tabs or sections for situation, evidence, policy, context, agent trace, action draft, simulation, collaboration, value, replay, and learning.
How to interpret: The rail explains who is working, what value is tied to the queue, and what autonomy boundary applies. It should summarize, not duplicate the main queue.
What click-through should prove: Open details for team activity, value impact, or autonomy posture to see named people, named transactions, and risk-classified decisions.
How to interpret: Evidence is the difference between a credible operating surface and a dashboard. Every recommendation should connect to invoices, POs, contracts, approvals, and supporting documents.
What click-through should prove: Open evidence records to verify source system, record ID, highlighted field, timestamp, completeness, and replay eligibility.
How to interpret: Policy explains why the system held, escalated, or recommended an action. It must be visible enough for a supervisor, controller, auditor, or technology reviewer to inspect.
What click-through should prove: Open policy details to see policy name, owner, effective date, rule, threshold, actual value, and violation result.
How to interpret: The page must not stop at insight. A demo-ready case should create or preview the next executable action.
What click-through should prove: Review the drafted action, approval chain, target system, payload, pending owner, and expected outcome before approval.
How to interpret: Value should be tied to actual decisions and transactions, not abstract productivity claims.
What click-through should prove: Open value details to see duplicate prevention, leakage avoided, discount captured, cash timing opportunity, and the transaction behind each figure.
How to interpret: Learning shows that bp Sphere is improving the operating model over time. Role evolution shows how the analyst or supervisor moves from chasing data to governing decisions.
What click-through should prove: Inspect learned pattern, source cases, confidence, control recommendation, before/after work, and capacity released.
Use these questions while testing the P2P page. A credible page should answer them from the UI without relying on verbal explanation.
Do not describe a KPI, chart, table, or recommendation as the agentic fabric. The KPI is presentation. The agentic fabric is the trace that detected a signal, assembled context, resolved evidence, evaluated policy, simulated impact, formed a recommendation, and generated an action while keeping release decisions governed.