bp Sphere Runtime Architecture
bp Sphere is the governed runtime between enterprise signals and enterprise action. It sits above systems of record, data platforms, workflow tools, policy repositories, and AI services to make decisions governed, explainable, auditable, replayable, and operationally useful.
Condensed runtime architecture
Existing bp platforms feed the signal layer; bp Sphere then resolves context, orchestrates agents, applies policy, proves evidence, creates decisions, routes human action, and preserves replay.
The runtime loop bp should remember
Everything on mission pages should map back to this chain. KPIs and dashboards are presentation. The runtime is the governed path that turns an enterprise signal into an explainable decision and a controlled action.
Core positioning
bp Sphere is not the system of record, model provider, or data lake. It is the governed decision and action runtime that composes those assets into accountable enterprise operations.
Technology credibility test
Every meaningful decision should produce runtime records for signal, context, evidence, policy checks, agent steps, human judgment, action, outcome, and replay.
Detailed runtime layers
These layers are the operating model behind mission pages such as P2P, R2R, FP&A, Treasury, Credit, Journal, and Transformation Intelligence.
Enterprise Signal Layer
Detects what changed across systems and turns raw events into business signals.
Context and Ontology Runtime
Resolves the business meaning of each signal using entities, relationships, ownership, and history.
Agent Orchestration Runtime
Coordinates specialized agents rather than relying on one generic chatbot.
Policy and Control Runtime
Applies authority, SOX, cyber, data, approval, and write-back gates before any decision or action.
Evidence Intelligence Fabric
Builds credibility by retrieving, extracting, linking, and displaying evidence before recommendation.
Decision Runtime
Creates the governed decision object the human can inspect, challenge, approve, or replay.
Action Runtime
Moves from recommendation to governed execution across three maturity horizons.
Human Supervisor Runtime
Makes accountability explicit across analysts, supervisors, tower leads, controllers, and CFO roles.
Replay and Audit Runtime
Stores the full trail needed to prove what happened, why it happened, and who approved it.
Observability and Reliability Runtime
Shows platform operators whether agents, tools, policies, evidence, and replay are healthy.
Concrete execution path: P2P duplicate invoice
This is the concrete path bp technology reviewers should expect to inspect live: every decision must leave runtime records for signal, context, evidence, policy, agents, human action, and replay.
SAP/Ariba event arrives
Invoice enters the enterprise event stream with source lineage.
Duplicate signal detected
Signal layer identifies same supplier, amount, PO reference, and payment window.
Context resolved
Supplier, PO, invoice, cost center, payment history, and prior cases are linked.
Evidence retrieved
Invoice, PO, GRN, policy, and historical payment records become an evidence pack.
Policy checked
Duplicate payment control and authority boundary rules determine the allowed action.
Agents participate
Matching, evidence, policy, recommendation, and escalation agents create the decision.
Decision crate created
Supervisor sees risk, evidence, recommendation, alternatives, and confidence.
Human approves hold
Supervisor approves or modifies the payment hold with a reason code.
Action executed
Action runtime sends the governed hold instruction to SAP or Ariba workflow.
Replay and learning stored
The full trace is saved and the duplicate pattern improves future matching.
Likely validation questions
This page should make the platform boundary clear: bp Sphere complements bp systems of record and governed data platforms. It does not replace them.
Where does Databricks fit?
Databricks provides governed data products, analytical features, lineage, and quality metadata. bp Sphere consumes those products and turns them into explainable decisions and governed actions.
Where does Palantir / Foundry fit?
Foundry can provide ontology and business-object relationships. bp Sphere uses that ontology as context, then adds orchestration, evidence, policy, decision, action, replay, and human accountability.
Where does Yala fit?
Yala can be the deployment and enterprise hosting path. The runtime capabilities remain the same and can be deployed through bp-approved infrastructure.
Does bp Sphere replace SAP or Ariba?
No. SAP and Ariba remain systems of record. bp Sphere decides, explains, recommends, drafts, and routes governed actions back into those systems.
Proof required for credibility
Runtime records
Every agent run should produce signal, context, evidence, policy, recommendation, human action, and replay records.
Policy gates
Every recommendation and write-back path is bounded by authority, SOX, cyber, data, and human approval controls.
Evidence before opinion
Recommendations must show the invoices, POs, contracts, policy clauses, transactions, and source snapshots used.
Safe operations
Operators need health, latency, failures, evidence gaps, policy denials, approval latency, kill switch, and safe degradation controls.
Latest runtime wiring now implemented
The architecture now has code-backed seams for experience orchestration, governed chat, assistant portability, token economy, policy fail-closed behavior, replay determinism, signed evidence, runtime adoption auditing, learning promotion, autonomy demotion, case-state propagation, and observability readiness.
Experience Orchestration Layer
Surface available - Shared decision objects render across desktop, mobile, and chat surfaces.
/ui/mission/p2p, /ui/mobile-cockpit, /ui/enterprise-chat
Governed Chat Interface
Surface available - Chat resolves role, mission, case, evidence, policy, action contract, replay, and feedback.
/ui/enterprise-chat
Workforce Intelligence Integration Fabric
Surface available - Assistant registry, connector packages, certification, compliance mappings, identity resolution, failover drills, and workforce coordination APIs.
/ui/workforce-intelligence-fabric, /ui/assistant-operations-center
Token Economy Control Plane
Surface available - LLM calls are routed, cached, denied, downgraded, or escalated before spend occurs; token value is attributed to decisions.
/ui/ai-cost-usage, /api/iaf/decision-intelligence/token-economy/decision
Guardrail Policy Engine
Surface available - Policy evaluation fails closed in production posture; non-fail-closed failures route to escalation instead of silent execution.
/ui/policy-registry, /ui/control-plane
Decision Replay + LLM Determinism
Surface available - Execution seed, prompt/context hash, evidence hash, policy version, and replay records are persisted and validated.
/ui/decision-journey, /ui/single-decision-audit, /ui/decision-replay-studio
Still external, not hidden
- SAP/SOR phase 2-3: RFC/OData reads, CDC streams, governed write-back, and master-data sync require customer credentials and agreed write boundaries.
- Live Entra tenant/Graph sync and vendor assistant connector credentials are external deployment bindings.
- Production OTEL/SLO alerting requires environment configuration and failure-mode drills in dev/prod.
- Agent de-stubbing and route-level adoption breadth continue as capability migration work, not platform architecture gaps.