Architecture pack Governed finance runtime Cloud-portable intelligence layer

bp Sphere Architecture Pack

bp Sphere is a governed finance decision runtime that sits above source systems, data platforms, collaboration tools, models, and cloud infrastructure. It does not replace those platforms; it coordinates context, evidence, policy, agents, human actions, replay, learning, and controlled execution.

Back to introduction Architect demo path Runtime reference Recovery proof Value proof

Architecture view

Platform, capability, component, integration, deployment

Operating model

Context -> evidence -> policy -> action -> replay -> learning

BP context

SAP, WIM, FIM/FIL, UDP, Databricks, Foundry, OneData

Control posture

Sensitive writes remain policy and human approval gated

Architecture at a glance

BP users and missionsAnalyst, supervisor, tower leader, FB&T, CFO

Finance source systemsSAP, WIM, Ariba, FSCM, Databricks, UDP

Collaboration channelsServiceNow, Teams, Outlook, workflow

bp Sphere decision runtime

Context, evidence, policy, agents, human actions, replay, learning, and controlled execution.

Governed decisionsRecommendation, authority, approval, action

Trusted proofLineage, freshness, truth tier, audit pack

Reusable learningOutcomes, patterns, memory, evaluation

Architect demo path: 20-minute story

Use this section when the audience is evaluating architecture rather than buying a polished demo. The goal is to explain where bp Sphere sits, how it connects to BP systems, how agents interact with systems of record, and how human-centric work evolves into governed agentic operations.

Current enterprise pattern

Users

Analysts, requesters, buyers, approvers, supervisors.

Applications and workflows

Portal forms, WIM, Ariba workflow, SAP screens, ServiceNow, email, Teams.

Systems of record

SAP, Ariba, ServiceNow, data platforms, document repositories.

Future enterprise pattern

Users

Humans state intent, review exceptions, approve controlled actions, and govern outcomes.

bp Sphere decision runtime

Context, agents, policies, evidence, authority, collaboration, replay, learning.

Systems of record

SAP and Ariba remain the operational systems; Sphere prepares and governs the decision path around them.

Slide	Architect message	What to prove
1. What Sphere is	A decision and orchestration runtime above systems of record	Not another ERP, chatbot, or point workflow tool.
2. Where it connects	SAP ECC, CFIN, S/4, Ariba, ServiceNow, UDP, Databricks, Foundry, OneData, Entra ID, Teams, Outlook	Sphere consumes context and orchestrates governed actions; it does not own the source data.
3. How agents work	Events or conversations create context; agents gather evidence, validate policy, assess risk, and recommend next action	Agents coordinate the work before human approval or source-system write-back.
4. What changes operationally	Humans move from manual coordination and transaction processing to exception approval and outcome governance	The enterprise gains speed without removing accountability.
5. How to evaluate it	Review event availability, deployment boundary, allowed write-backs, source lineage, policy gates, and replay evidence	This is the architecture review agenda for BP architects.

PR / PO conversational flow as architecture illustration

Employee conversationNeed, supplier, amount, timing

Sphere agentClarifies missing information

Context and policySupplier, budget, contract, DoA

Human approvalException and authority gate

SAP / Ariba PO createdControlled write-back and replay

PR / PO step	How Sphere supports it	Architectural boundary
Employee request	Conversation or request form captures need, supplier, cost object, amount, timing, and business justification	Sphere asks clarifying questions instead of pushing incomplete PRs into workflow.
Context assembly	Supplier, contract, catalog, budget owner, cost center, company code, DoA threshold, and similar PR history are loaded	Context comes from SAP, Ariba, HR/identity, data platforms, and policy stores.
Policy validation	DoA, budget, supplier risk, catalog/contract, SoD, country, and procurement policy are evaluated	Policy output is deterministic and replayable; LLM output explains it but does not replace it.
Human approval	If value, risk, or evidence gaps exceed authority, the approver receives an evidence-backed ask	Human remains the approval boundary for controlled procurement actions.
Controlled write-back	Approved action creates or updates the PR/PO route in SAP or Ariba and records replay/audit evidence	The agent replaces coordination work, not the source system of record.

Human-centric process

Human reviews, validates, gathers evidence, approves, and executes across disconnected tools.

Agentic process

Agent gathers evidence, validates policy, assesses risk, prepares action, and routes the exception to the right human.

Future state

Agent executes only inside approved boundaries; humans govern exceptions, thresholds, controls, and outcomes.

Question for BP architects	Why it matters	What it decides
Events	Which PR, PO, invoice, payment, supplier, approval, and exception events are available today?	Defines whether Sphere runs event-driven, batch-triggered, or hybrid.
Deployment	Should the runtime land in Azure, AWS, private compute, or a hybrid cell model?	Defines network, identity, data residency, model routing, and operations constraints.
Write-back	Which systems can receive human-approved write-backs from Sphere?	Defines the first safe automation boundary.
Data trust	Which fields are live SOR, curated snapshot, cached, or scenario-only?	Defines credibility, attestation, and demo safety.
Authority	Which roles can approve, escalate, override, or block actions?	Defines human-in-the-loop controls and separation of duties.

Presenter rule: do not spend 20 minutes on screens. Spend the time explaining the runtime boundary, source-system interaction, policy and write-back gates, and how the PR/PO example illustrates the architecture.

North star

bp Sphere is not another dashboard, chatbot, or automation tool. It is a source-grounded finance intelligence platform that connects data, processes, controls, policies, people, source systems, models, and outcomes into a governed decision runtime.

Context

Understands finance objects, roles, policies, source systems, business events, and case state.

Orchestration

Coordinates agents, skills, evidence, models, workflows, collaboration, and human actions.

Assurance

Enforces source lineage, policy, authority, replay, audit, security, and controlled execution.

1. Platform architecture

The platform is layered so finance intelligence remains enterprise-owned while infrastructure and model providers stay replaceable.

Users and roles

Experience layer

Analyst workbench

Supervisor control plane

Tower leader view

FB&T leader view

CFO command center

↓

Business missions

Mission runtime layer

Case intelligence

Prioritization

Recommendations

Human action layer

Evidence viewer

Decision replay

↓

Core platform

Enterprise decision runtime

Agent orchestration

Skill fabric

Policy runtime

Authority runtime

Evidence fabric

Learning memory

↓

Connected foundation

Model, integration, and operations fabric

Model gateway

SAP and procurement

Data platforms

Collaboration tools

Governance and resilience

Layer	Purpose	Core services	Why it matters
Experience layer	Role-based decision workspaces	Analyst workbench, supervisor plane, tower leader, CFO	Each role sees the right decision, evidence, action, and accountability level.
Mission runtime	Turns finance missions into actionable cases	Case intelligence, triage, recommendations, action drawers	Keeps the system focused on business outcomes instead of generic chat.
Decision runtime	Core governed decision brain	Agents, skills, policy, authority, evidence, replay, learning	Makes recommendations explainable, repeatable, auditable, and bounded.
Evidence fabric	Creates trusted evidence packs	Lineage, freshness, source records, scoring, immutable packs	Builds credibility with finance, controls, audit, and executives.
Policy and authority	Enforces human and system boundaries	Policy checks, approval thresholds, SoD, write authority	Keeps sensitive finance actions approval-gated.
Model and compute fabric	Routes work to the right intelligence	Frontier LLMs, local models, small models, deterministic solvers	Allows model choice without platform lock-in.
Integration fabric	Connects source systems and collaboration channels	SAP, Ariba, FSCM, ServiceNow, Databricks, UDP, Foundry, Teams	Makes recommendations live, sourced, and operationally useful.
Governance and operations	Runs the platform safely	Observability, FinOps, model governance, cyber, resilience	Turns a demo surface into an enterprise operating platform.

2. Capability architecture

Do not build pages plus agents. Build reusable decision capabilities, then expose them through mission-specific workbenches.

Reusable mission equation: Mission = context + cases + signals + agents + evidence + policy + actions + replay + learning + impact.

Reusable capability model

P2P duplicate paymentInvoice, PO, supplier, payment, policy

O2C collections riskCustomer, dispute, promise, exposure

R2R close controlJournal, reconciliation, evidence, SOX

reuse

Shared platform servicesOntology, policy, evidence, action, replay

Shared agent servicesRegistry, skills, model gateway, tool router

Shared governance servicesCredibility, learning, observability, FinOps

Capability	Platform function	Used by	Credibility rule
Finance ontology	Common objects and relationships	All missions	Supplier, invoice, PO, customer, journal, forecast, policy, control, evidence.
Policy runtime	Rules, thresholds, approvals, controls	P2P, O2C, R2R, Treasury, Tax	Policy interpretation is owned by the enterprise, not by a model.
Agent and skill registry	Catalogs agent purpose, risk, owner, model, tools, write authority	Platform governance	Prevents uncontrolled agent sprawl.
Human action layer	Standardizes controlled actions	Analysts and supervisors	Hold, escalate, request evidence, approve, reject, open source record.
Collaboration layer	Routes asks and handoffs	All roles	Teams, Outlook, ServiceNow, tasks, approvals, SLA, response ingestion.
Decision replay	Reconstructs decision paths	Audit, controls, leaders	Inputs, prompts, tools, policies, evidence, human choices, outcome.
Learning runtime	Converts outcomes into improvement	Continuous improvement	Captures feedback, root causes, override patterns, automation candidates.
Live data credibility	Shows source and truth basis	Every KPI, drawer, and answer	Truth tier, freshness, lineage, fallback, attestation, owner.

Finance domain capability map

The same platform capabilities should support P2P, O2C, R2R, FP&A, Treasury, Tax, Close, and executive views rather than creating disconnected tower products.

Domain	Representative capabilities	Business outcome
P2P	Duplicate risk, GRIR, non-PO triage, payment blocks, supplier asks	Leakage prevented, cycle-time reduction, stronger payment controls.
O2C	Collections priority, disputes, cash application, credit risk	Working capital recovery and customer risk visibility.
R2R	Continuous close, journal controls, reconciliations, intercompany	Close confidence, SOX evidence, fewer late surprises.
FP&A	Variance intelligence, forecast quality, narrative, scenarios	Better management insight and faster explanation cycles.
Treasury	Liquidity, bank connectivity, payment status, FX exposure	Cash visibility, funding risk control, payment reliability.
Tax	Jurisdiction checks, indirect tax, filing readiness, evidence	Compliance readiness and audit support.

Component architecture

The platform should show concrete technical components so BP architects see more than a generic layered diagram.

Component plane

Experience APIsWorkbenches, drawers, command centers

Case runtimeQueue, priority, SLA, owner, state

Context engineCanonical objects and selected-case payload

Evidence fabricLineage, documents, freshness, proof pack

Policy runtimeRules, controls, DoA, SoD, authority

Agent runtimeSkills, prompts, tools, confidence

Action runtimeAsk, hold, escalate, approve, write-back

Replay and learningAudit, outcome, memory, evaluation

Component	Role	Technical capabilities	Why it matters
API and event engine	Receives source events, case actions, and system callbacks	API gateway, event bus, queue consumers	Keeps integration explicit rather than hidden inside page logic.
Document intelligence	Reads invoices, attachments, contracts, and support documents	OCR, PDF parsing, extraction confidence, evidence references	Separates document understanding from workflow routing.
Context engine	Builds selected-case context across supplier, company code, country, history, and owner	Canonical objects, data contracts, context graph	Prevents drawers and agents from inventing missing context.
Policy engine	Evaluates authority, thresholds, controls, country rules, tax rules, and SoD	Policy registry, authority matrix, control checks	Makes AI recommendations governed, not autonomous guesses.
Knowledge graph	Connects finance objects, policies, people, systems, evidence, and outcomes	Enterprise graph plus domain graph projections	Supports similarity, lineage, expert discovery, and reusable learning.
Copilot and agent runtime	Explains, researches, drafts, and recommends inside boundaries	Ask workspace, mission agents, skill registry, model gateway	Shows where LLM/RAG/agents add value beyond workflow automation.
Replay and audit engine	Reconstructs each decision from source facts to human action	Replay store, evidence hashes, tool traces, policy versions	Creates auditability and recovery of business decisions.
Operations plane	Monitors cost, latency, failures, fallback, RTO/RPO, and source coverage	Observability, FinOps, resilience, data credibility	Lets platform teams run the system as production infrastructure.

3. Integration architecture

The integration model should be governed: canonical finance objects, source adapters, event contracts, evidence contracts, data freshness, lineage, and human-approved write-back paths.

Canonical object layer

Supplier, customer, invoice, PO, receipt, payment, journal, dispute, forecast, control, policy, evidence pack, and decision record.

source mappedlineage trackedpolicy aware

Controlled output layer

Recommendations, tasks, approvals, ServiceNow cases, Teams and Outlook requests, source-system write-back, audit records, and replay packages.

approval gatedaudit loggedreplay ready

Source-to-decision integration flow

Source adaptersSAP, WIM, Ariba, FSCM

Canonical finance objectsInvoice, supplier, PO, payment

Event and evidence servicesEvent store, evidence store, replay store

Decision runtimeAgent, policy, authority, action

Controlled outputsTask, approval, write-back, audit

Pattern	Use case	Example	Rule
Read from data platform	High-volume analytics and triage	History, behavior, trends	Prefer curated data platforms for scalable reads.
Read from source of record	Final evidence validation	Live invoice, payment, approval status	Use when freshness or audit confidence requires source confirmation.
Event subscription	Case creation and state changes	Invoice posted, payment run pending, dispute created	Use for near-real-time mission triggers.
Controlled write-back	Operational action	Payment hold, ServiceNow ticket, workflow update	Must pass policy, authority, evidence, and human approval gates.
Collaboration integration	Human follow-up	Teams, Outlook, approvals, owner requests	Required for analyst and supervisor workflows.
Evidence integration	Audit and assurance	Invoice, PO, receipt, policy, approval, lineage	Creates immutable evidence pack and replay record.
Model integration	Reasoning, classification, explanation	LLMs, local models, deterministic solvers	Route by risk, cost, sensitivity, and latency.

BP-specific systems and data foundations

The architecture must be contextual to BP's existing finance, data, workflow, collaboration, and controls estate.

System / platform	Integration role	Recommended pattern
SAP ECC / CFIN / S/4	Finance source systems and migration coexistence	Live validation and controlled write-back only after approval.
SAP WIM	Invoice workflow, exception handling, document status, approval routing	Primary operational context for invoice intake and non-PO exceptions.
Ariba	Procurement, supplier, PO, contract signals	P2P evidence and contract compliance context.
SAP FSCM	Collections, credit, disputes	O2C workflow and risk integration.
FIM / FIL	Finance information model and finance data foundation	Data readiness, finance semantics, coverage, and model alignment dependency.
Databricks / UDP / OneData / Foundry	Curated data, history, features, operational data products	Primary read layer for scale, pattern mining, and AI-ready data products.
ServiceNow	Workflow, evidence requests, incidents, escalations	Create and track governed operational tasks.
Outlook / Teams	Human collaboration	Neutral, evidence-backed asks and approval handoffs.
HR / Identity / Controls repositories	Role, authority, delegation, policy and audit evidence	Authority runtime and assurance linkage.

Knowledge graph and ontology treatment

The clean architecture is one enterprise finance ontology with domain graph projections. That keeps semantics consistent while allowing AP, GL, tax, assets, and reporting to have deeper local structures.

Ontology plus domain graph projections

Supplier

Invoice

Policy

Evidence

Outcome

Enterprise finance ontologyCommon semantics across missions

AP graphP2P exceptions

AR graphCollections and disputes

GL graphClose and journals

Tax graphJurisdiction and compliance

Asset graphCapital and operations

Graph layer	Purpose	Outcome
Enterprise finance graph	Shared finance semantics across supplier, customer, invoice, payment, journal, company code, policy, and control	Common memory and cross-mission similarity.
Domain graph projections	AP, AR, GL, asset, tax, close, and reporting subgraphs tuned to local process needs	Domain depth without fragmenting the enterprise ontology.
Temporal memory	What policy, data, owner, and evidence were true at the time of decision	Audit replay, historic explanation, and policy-change analysis.
Access and classification	Public, internal, confidential, restricted, regulated graph nodes and edges	Security, Entra-aligned access, and data minimization.
Outcome-linked knowledge	Decisions connected to financial result, human override, learning artifact, and resolution pattern	Turns case work into reusable institutional memory.

Live data credibility layer

Every case, KPI, recommendation, evidence pack, and drawer should disclose its truth basis. This prevents source confusion and makes demos safe to mature into production.

Source

System, owner, object ID, and freshness are visible for every material value.

Truth tier

Scenario, snapshot, live source read, live lineage, or attested proof is explicit.

Fallback

Fallback is governed and labeled; hidden synthetic values are not allowed.

Attestation

Only source-grounded and lineage-backed values can be used as audit or executive proof.

Write-back architecture

Sensitive finance actions should not be autonomous by default. AI can inform, recommend, prepare, and execute only when policy, authority, evidence, and human approval gates permit it.

Controlled execution path

Agent recommendation

Policy check

Authority check

Evidence check

Human approval

Controlled write-back

Boundary outcomes

Approved: update SOR

Rejected: no write

Missing evidence: ask owner

Threshold exceeded: escalate

Authority level	Meaning	Example
Inform	AI explains only	Explain why an invoice is risky.
Recommend	AI suggests next action	Recommend a payment hold.
Prepare	AI drafts but does not submit	Draft a supplier evidence request.
Execute with approval	Human approves before execution	Apply a payment block.
Autonomous execution	System executes only inside strict low-risk policy	Low-risk reminder or data enrichment.

Detailed use-case walkthrough: non-PO invoice processing

Non-PO invoice processing is the right technical walkthrough because it requires document intelligence, supplier validation, GL coding, policy checks, approval routing, exception handling, and human judgment.

Non-PO invoice processing swimlane

Source systems

Email, EDI, portal, WIM

SAP supplier and company code

Contracts, SOPs, policy store

SAP / WIM / ServiceNow write-back

Decision runtime

Intake and OCR extraction

Context enrichment and graph link

Policy, tax, duplicate, DoA checks

Recommendation, action, replay

Human control

Review missing fields

Request owner or supplier evidence

Approve, hold, reject, or escalate

Rationale captured for audit

Step	Capability in motion	Credibility requirement
1. Invoice arrives	Email, EDI, portal, WIM, or scanned document triggers intake	Create case and preserve original document evidence.
2. Intake and extraction	Document intelligence extracts supplier, amount, tax, currency, lines, payment terms, and bank details	Show extraction confidence and missing fields.
3. Source enrichment	Context engine pulls supplier master, company code, country, contract, GL history, prior invoices, and approval owner	Hydrate from selected-case payload and source contracts.
4. Policy and control checks	Policy engine evaluates non-PO policy, authority, duplicate risk, tax rules, SoD, thresholds, and country constraints	Separate rule outcome from AI explanation.
5. Graph reasoning	Knowledge graph connects supplier, business unit, company code, approver, policy, history, and similar exceptions	Surface comparable cases and known risks.
6. Agent recommendation	Agent recommends approve, hold, reject, GL coding, request clarification, or escalate	Explain with evidence, confidence, uncertainty, and alternatives.
7. Human action	Analyst or supervisor reviews evidence, edits draft, requests owner input, or approves controlled action	No sensitive write without human authority.
8. System execution	Approved action updates WIM, SAP, ServiceNow, Teams, Outlook, or evidence store	Write-back is policy-gated and replay logged.
9. Replay and learning	Replay captures facts, evidence, policy, model output, human rationale, action, and outcome	Feeds decision memory and future recommendation quality.

Why this proves agentic depth: the process uses OCR, source reads, RAG over SOP and policy, knowledge graph context, deterministic policy checks, LLM explanation and drafting, human approval, controlled write-back, replay, and learning. It is not simple RPA.

4. Deployment architecture

The deployment model should support local compact runtime, tenant sandbox, UAT / parallel run, and production hybrid operation across cloud and private compute.

Runtime cells

Experience, mission, decision, agent, integration, evidence, replay, model gateway, observability, and governance cells scale independently.

Hybrid model routing

Frontier models for reasoning, local or small models for routine classification, deterministic engines for control checks.

Recovery by decision

RTO/RPO is measured on decisions, evidence, policy, agent state, human actions, and outcomes, not just servers.

Production runtime cells

Experience cellRole-based UI and workbenches

Mission cellP2P, O2C, R2R, FP&A

Decision cellPolicy, evidence, authority

Agent cellSkills, tools, model gateway

Integration cellSAP, data, collaboration

Evidence cellDocuments and source lineage

Replay cellAudit and recovery history

Learning cellOutcomes and memory

Observability cellHealth, latency, FinOps

Governance cellAccess, approvals, model policy

Environment	Purpose	Data mode	Write-back
Local compact runtime	Engineering, demo, offline testing	Selected non-attested extracts	No production write-back; clearly non-attested.
Dev tenant	Feature and integration testing	Masked or non-production data	Write-back disabled by default.
System integration test	End-to-end adapter validation	Test source systems	Controlled test writes.
UAT / parallel run	Business validation against live process	Read-only production mirror or governed live read	Human-approved limited writes.
Production	Operational use	Production data and governed source reads	Controlled write-back with policy and authority gates.

End-to-end runtime flow

Source event or data change

A business event or source refresh creates or updates a finance case.

Context and evidence assembly

The runtime loads canonical objects, source facts, lineage, freshness, documents, and prior outcomes.

Agent, policy, and authority evaluation

Agents and deterministic checks produce recommendations bounded by policy, approval, SoD, and write authority.

Human decision and controlled execution

Analysts or supervisors approve, reject, escalate, request evidence, or execute controlled write-back.

Replay, audit, outcome, and learning

The full path is captured for audit, recovery, learning, value attribution, and future decision improvement.

Platform capabilities to prioritize

These should be implemented once as platform services, not separately inside each mission page.

Priority capability	Why critical	Where to point reviewers
Evidence Intelligence Fabric	Builds source-grounded trust	Proof route: Evidence Vault and case evidence drawers.
Policy and Authority Runtime	Keeps finance actions governed	Proof route: policy registry, authority gates, human approvals.
Decision Replay	Makes every recommendation auditable	Proof route: Decision Replay Studio and replay records.
Finance Ontology	Enables reusable semantics across towers	Proof route: context graph and canonical registry.
Human Action Layer	Standardizes governed execution	Proof route: case actions, collaboration asks, escalation drawers.
Live Data Credibility Layer	Prevents hidden scenario or fallback leakage	Proof route: provenance labels, truth tiers, value attribution.
Model Gateway	Keeps models swappable and risk-aware	Proof route: model comparison and AI cost usage surfaces.
Resilience & Recovery Runtime	Recovers decisions, evidence, policy, agent state, and outcomes	Proof route: Recovery Command Center.
Learning Runtime	Turns outcomes into institutional memory	Proof route: learning fabric and decision memory surfaces.

Architecture principle: build a platform of reusable decision capabilities, then expose those capabilities through mission-specific workbenches.

Positioning summary. bp Sphere is a hybrid, governed, source-grounded, multi-cloud-capable finance decision runtime operating across source systems, data platforms, policies, controls, people, models, and outcomes.