BP Technology Validation
Data Access & Consumption Strategy
How bp Sphere leverages UDP, Databricks, OneData, and Foundry while minimizing SAP and system-of-record load.
A successful finance AI platform should not continuously query SAP. bp Sphere consumes most operational context from UDP, Databricks, OneData, and Foundry while using SAP and other systems of record only when necessary for validation, transaction execution, or evidence verification.
Platform proof standard: each data product is tied to source freshness, lineage, evidence pack, replay path, policy owner, collaboration owner, action authority, observability cost, and value attribution before a mission can rely on it.
Provenance: reference strategy model, not live SAP read telemetry. Percentages and SAP-load deltas are planning targets until linked to SOR adapter counters and consumption logs.
Databricks + UDP Reads
84%
Preferred governed data-product path
OneData + Foundry Reads
8%
Semantic authority and relationship context
Direct SAP Reads
3%
Reference target: validation, execution, and evidence verification only
SAP Load Reduction
82%
Reference planning model: 100M/month baseline to 18M/month
Architecture View
Agents consume resolved context packages instead of repeatedly calling transactional systems.
Enterprise Systems
v
UDP
v
Databricks
v
OneData
v
Foundry / Ontology
v
bp Sphere Runtime
v
Governed Decisions
SAP Load Reduction
Modeled SAP Reads
100,000,000/month
Reference Current Model
18,000,000/month
Modeled Reduction
82%
Target Direct SAP Share
<5%
SAP is preserved as system of record. bp Sphere reduces load by using event activation, governed data products,
context cache, and one-time validation calls before controlled actions.
Data Consumption Hierarchy
| Level | Source | Used For | Current | Target | Freshness | Confidence |
|---|---|---|---|---|---|---|
| Level 1 | UDP + Databricks | analytics, signals, KPIs, forecasting, pattern detection, agent context | 84% | 86% | 5 minutes | 94% |
| Level 2 | OneData + Foundry | business context, relationships, entity mapping, hierarchy resolution | 8% | 10% | 15 minutes | 91% |
| Level 3 | SAP APIs and SOR validation | transaction verification, current-state validation, governed execution, evidence verification | 3% | 5% | live on demand | 98% |
| Support | Context cache | vendor profiles, cost centers, budget context, commitments, approval chains, historical decisions, policy context | 5% | 0% | 30 seconds to 24 hours by object type | 90% |
Decision Formation
Duplicate Invoice Alert
This widget proves the query-optimization pattern: context comes from governed data products and semantic layers;
SAP is touched once in the reference model for status validation; production proof requires SAP gateway call telemetry.
SAP calls used
1
Single validation call in the reference model
Context package sources
6
Databricks, OneData, Foundry, Policy Runtime, SAP
Polling calls avoided
12
Event Fabric activation instead of repeated SAP checks
| Context | Source | Freshness | Confidence | SAP Calls |
|---|---|---|---|---|
| Invoice history | Databricks finance invoice product | 5 minutes | 95% | 0 |
| Vendor profile | Databricks vendor profile product | 1 hour | 93% | 0 |
| Approval policy | Policy Intelligence Runtime | versioned policy | 100% | 0 |
| Supplier hierarchy | OneData semantic authority | 1 hour | 92% | 0 |
| Business relationship | Foundry ontology relationship | 15 minutes | 91% | 0 |
| Live invoice status validation | SAP ECC/S4/CFIN API | on demand | 99% | 1 |
Context Cache Layer
Cache entries include explicit TTLs and freshness guards so agents can avoid repetitive SOR reads without acting on stale context.
| Object | TTL | Freshness Guard |
|---|---|---|
| Vendor profile | 24 hours | refresh before payment decision |
| Cost center context | 12 hours | refresh when owner or hierarchy changes |
| Budget context | 1 hour | refresh for material spend decision |
| Open commitments | 15 minutes | refresh for cash or working-capital action |
| Approval chains | 4 hours | refresh before escalation or write-back |
| Historical decisions | 7 days | replay hash verifies immutability |
| Policy context | versioned | invalidate on policy version change |
Event-Driven Consumption
SOR Event: Invoice Posted
Event Fabric: canonical signal duplicate_invoice_risk
Agent Activated: Duplicate Invoice Agent
- lower SAP load
- near real-time activation
- scalable consumption
- better audit trail
SAP Access Governance
| Class | Allowed For | Policy | Audit |
|---|---|---|---|
| Read only | exception inspection and evidence verification | no write permission | source, identity, timestamp, object, and reason recorded |
| Validation | current transaction state before action | single-purpose call with correlation id | decision id and evidence pack linked |
| Write back | approved workflow, hold, draft, or governed execution | policy check + human approval + replay package required | full action payload and approver retained |
Why This Aligns With BP Strategy
- Uses UDP as the enterprise ingestion layer
- Uses Databricks as the governed data product and analytics platform
- Uses OneData for semantic authority and business meaning
- Uses Foundry for ontology relationships where available
- Minimizes dependency on SAP implementation details
- Supports ECC, CFIN, and S4 coexistence
- Reduces load on operational systems
- Creates a future-ready finance intelligence layer
Runtime Guardrails
- Agents Start From Context Package: True
- Sap Writeback Requires Policy And Approval: True
- Low Freshness Blocks Autonomous Action: True
- Source Confidence Visible: True
- Sap Calls Metered Per Decision: True