Seven experiments — the mechanisms behind the claims
Each demo runs an interactive data visualization of one mechanism, shows the copilot screenshot where it surfaces, and cites the measured result. No live API calls — these are the experiments and data that back the outreach document.
07:14 this morning. SAP pushes MATKL_V2 — 340K new material classification codes. The join between material master and procurement pipeline fans out 1× → 9×. Seven downstream systems silently degrade. A freshness alert fires at 07:22.
Who cares: every CDO whose team investigates alerts manually What’s at stake: $2.1M/month revenue pipeline exposure, 3 critical systems
Run: two investigations, same alert, same morning
What the investigation finds. The Situation Analyzer starts at the alert — a freshness violation on the procurement pipeline — and traverses upstream through the context graph. In 47 seconds it names the root cause (SAP MATKL_V2 schema change, +340K codes, 9× join fanout), maps the blast radius (7 downstream systems, 3 critical, $2.1M/month exposure), and recommends a fix (pre-join filter, 87% confidence). Your engineer reaches the same answer in 3 hours. The system also learns: when this pattern recurs at billing_api three weeks later, it’s auto-resolved in 15 minutes.
Measured result · K14 experiment (240 judgment pairs)
LLM reading alert text agreed with correct triage 12%. Graph-based Situation Analyzer: 76%.
Why you should care: Your team has 15–20 of these a week. At 3 hours each, that’s a full-time engineer doing nothing but investigation. The system does the same work in under a minute — and learns so the next occurrence is auto-resolved.
In the product: Triage screen
DataOps Copilot — Dashboard with pipeline status, alert groups, and conservation projection
Demo 2 · Auto-Ingestion Safety · Earned Trust
”The $420K Load Your Agent Approved”
Context — what your agent did last quarter
Tuesday, 02:17 AM. Your data quality agent auto-approved a load from Airflow Pipeline #47. The source had been returning stale cached data since Monday’s infra update. Three downstream pipelines ingested it. Finance ran Q3 close on it.
The trust dimensions the gate watches:
Data quality — is the data accurate, complete, and fresh?
Ingestion latency — is the pipeline delivering within SLA? A source that delivers accurate data 6 hours late is not trustworthy.
Throughput stability — has load volume spiked or dropped unexpectedly?
Freshness SLA — when was the last verified load? Staleness = risk.
Who cares: CDOs deploying agents without guardrails on quality OR performance What’s at stake: $420K in Q3 restatement costs. CFO asks “who approved this?”
Run: the same load, with and without the Conservation Gate
What the trust scores reveal. Each source earns its trust from verified decisions — not from a configuration file. After 500 decisions, SAP S/4HANA has earned 0.94, dbt Cloud 0.82, Celonis 0.71 — all above the θ_min threshold of 0.45, safe for autonomous approval. Airflow #47 sits at 0.23. Manual XLS at 0.14. Both below the line. When the agent tries to auto-approve the Airflow load at 2 AM, the Conservation Gate runs the θ_min check, it fails, and the decision routes to a human. Four seconds. The engineer rejects the stale data. The correct load runs at 6:30 AM. Cost avoided: $420K in Q3 restatements.
Measured result · Conservation Gate theorem
θ_min = 23.53/(α×V). The Conservation Gate runs a formal check before every autonomous decision. In production: 9,826 gate checks, zero violations. The gate does not approve unless the system has earned enough verified history in that decision category. This is a theorem, not a threshold.
Why you should care: Every CDO is being asked to deploy agents. The question isn’t whether to — it’s how to prevent the $420K Tuesday. The Conservation Gate is mathematically bounded: it cannot approve what the system hasn’t earned. That’s the difference between “automation” and “earned autonomy.”
Demo 3 · Compounding Accuracy · Platform ROI
”The $2.4M Accuracy Gap”
Context — every platform has this problem
Static scoring systems plateau. After an initial configuration period, accuracy flatlines — the system can’t learn from its own decisions. Your best engineer’s judgment improves daily. Your data platform’s doesn’t.
Who cares: CDOs spending $2–4M/year on platforms that don’t get smarter What’s at stake: the gap between what your team knows and what your system knows grows every quarter
Run: two systems, 1,000 decisions, same data
What the curves show. Both systems start at the same accuracy on the same alerts. Through decision 200, they track together — the initial configuration period. Then the static system plateaus at ~62%. It can’t learn from its own decisions. The RGI curve keeps climbing — every verified decision updates centroids (judgment memory), DK weights (factor importance), and AgentEvolver rules (automation candidates) simultaneously. By decision 800, the gap is 28 percentage points. By decision 1,000, it’s still growing. The compounding shape is the mechanism: one verified decision produces three simultaneous improvements.
Measured result · V-CGA-FROZEN (390-cell factorial)
Cross-Graph Attention provides +42.69pp Day-1 accuracy from enriched initialization. DK characterization: +13.2pp on heterogeneous noise (r=0.990). Re-convergence after distributional shock: 54.4% faster. The compounding is measured, not modeled.
What 28 points means for your P&L: At 1,000 alerts/month, a 28pp accuracy advantage = ~280 fewer misrouted investigations. At $800/investigation (senior engineer time + downstream delay) = $224K/month — $2.4M/year in recovered capacity.
Why you should care: After 1,000 decisions, a static platform and RGI are looking at the same data — but one is 28 points more accurate. That gap is your team’s judgment being captured vs. evaporating. Every quarter it doesn’t compound is a quarter you can’t get back.
In the product: Insight screen — fingerprint + profile
DataOps Copilot — Insight tab: decision fingerprint, profile archetype, and factor weights that emerge from verified decisions
Demo 4 · The Learning Engine
”One Decision, Three Updates”
Context — the engine behind the outcomes
One verified decision updates three subsystems simultaneously
Judgment Memory centroids sharpen — the “what” of the decision is captured
DK factor weights adjust — the “why” is captured (which dimensions matter)
AgentEvolver rules re-evaluate — the “how to automate” is captured
This is why accuracy compounds — three learning signals from every human confirmation
Who cares: CDOs who need to explain why the system gets smarter / CIOs who need the moat argument What’s at stake: without the loop, each decision is isolated — with it, each decision improves the next 1,000
Run: one decision through the compounding loop
The loop is the product — one confirmation, three updates, compounding intelligence. This is the mechanism that makes Demo 3’s accuracy curve climb while the static line flatlines.
Ontologies are fixed classifications — “supplier → risk: high” doesn’t change after 1,000 decisions
LLM extraction is richer but still static — the graph on day 1,000 = day 1
Cross-Graph Attention is algebraic enrichment — attends across SAP, Celonis, Snowflake simultaneously
Factor vectors are learned geometry — centroids sharpen with every verified decision
No pre-defined ontology mapping needed — the attention weights ARE the ontology, earned not designed
Who cares: CDOs evaluating knowledge graph / data catalog investments What’s at stake: static enrichment requires human maintenance that scales linearly — CGA scales by observation
Run: three approaches, same supplier entity, 100 decisions
Measured result · V-CGA-FROZEN (390-cell factorial)
Cross-Graph Attention: +42.69pp Day-1 accuracy from enriched initialization
DK characterization: +13.2pp on heterogeneous noise (r=0.94 correlation)
Static ontology and LLM extraction provide no compounding — the enrichment is a one-time snapshot
Dark data — the hidden cost of static enrichment
40–55% of enterprise data is available but used for no analysis of any form
Your catalog indexed it. Nobody computed over it. Nobody knows if it correlates with anything useful.
Cross-Graph Attention discovers those connections — "Connect weather API → demand prediction: +$180K/yr"
Modeled trajectory: dark data ratio 53% → 34% as CGA enrichment compounds
Why this matters: Traditional ontologies scale by human effort — adding a domain costs months of expert schema work. LLM extraction is cheaper but still static after extraction. CGA scales by observation — every verified decision enriches every connected entity. The attention weights ARE the ontology, earned not designed.
Context — what happens after you deploy automation
Your team automated a triage rule: “auto-resolve partition-count alerts.” It worked for weeks — 93% accuracy through decision 30. Then the infrastructure changed. Partition semantics shifted. The rule started getting it wrong. Nobody noticed for 20 more decisions.
Who cares: CDOs who’ve been burned by automation that silently degrades What’s at stake: the trust your team places in any automated rule
Run: the full lifecycle of one automation rule
What the lifecycle shows. The rule “auto-resolve partition-count alerts” is discovered by AgentEvolver, shadow-tested on live decisions, and promoted at decision 30 with 93% accuracy. Then the infrastructure changes. Partition semantics shift. Accuracy drops — 89%, 85%, 82% — crossing below the 78% correctness floor at decision 42. The system demotes its own rule. Alerts return to manual triage. The full audit trail shows exactly when it was promoted, what it was tested against, and why it was pulled. No human had to notice. No incident had to happen first.
Measured result · AgentEvolver production data
~10 rules tested, ~7 rejected. The system’s restraint rate IS the credibility proof. Every rule has a full audit trail: when it was discovered, what it was tested against, when it was promoted, why it was demoted. The 70% rejection rate means the system is strict enough to trust.
Why you should care: Your current automation doesn’t have a demotion mechanism. Once a rule is deployed, it stays deployed until someone notices it’s wrong. RGI’s AgentEvolver catches degradation before it becomes an incident — and has the audit trail to prove it.
Demo 7 · Process Mining → ERP Fix
”3-Way Match Fix — 38 min to 5 min”
Context — Celonis shows WHERE. Who explains WHY? Who fixes WHAT?
Your process mining dashboard says: the 3-way match (PO → GR → Invoice) takes 38 minutes, 80% of total cycle time. Celonis shows the bottleneck: the vendor matching step. It cannot tell you why. And it cannot reach into SAP to fix it.
The fix gap:
Process mining identifies the slow step — cannot trace data lineage to root cause
Your team: 2–4 hours to trace to the SAP configuration that caused it
RGI’s Tech-Process Fusion: names the root cause AND generates the SAP-specific fix
Who cares: CDOs who’ve bought process mining and still can’t close the loop to a fix What’s at stake: $180K/month in delayed invoice processing, supplier payment penalties
Run: decompose the bottleneck — where the 38 minutes go
What the waterfall reveals. Celonis says the 3-way match takes 38 minutes, 70% of total cycle time. The waterfall decomposes those 38 minutes: Data Fetch (1 min), Vendor Match (35 min), Validation (1 min), Write-back (0.5 min), Queue (0.5 min). The bottleneck is one stage — the join. Tech-Process Fusion connects the process layer to the data layer and names the cause: a quarterly vendor master consolidation merged 3 regional supplier tables, tripling join cardinality on LIFNR. The recommended fix is a partition filter on BUKRS (company code) (87% confidence, based on 3 similar past fixes). After the fix: 38 minutes → 5 minutes.
SAP process fix recommendation
Root cause: Vendor master consolidation — 3 regional supplier tables merged into global LIFNR table, join cardinality tripled
Immediate fix: partition filter on BUKRS (company code) before vendor join — cardinality back to pre-consolidation levels. 3× → 1×
SAP config: SE16N → table LFA1 → secondary index on LIFNR + BUKRS. 15-min deploy, no transport in sandbox
Preventive rule: AgentEvolver monitors future vendor master consolidations — any >2× cardinality increase triggers auto partition filter recommendation
Measured result · Cross-system data lineage trace
Celonis shows: 3-way match = 38 min, 80% of total. RGI explains: vendor master consolidation merged 3 regional tables, tripling LIFNR join cardinality. The fix is a partition filter on BUKRS — based on 3 similar past consolidations, 87% confidence. Fix applied: 38 min → 5 min.
Why you should care: Process mining shows you the WHAT. Your team still has to figure out the WHY. Tech-Process Fusion connects the process layer to the data layer — so when a vendor consolidation causes a bottleneck, the system traces the data lineage to the consolidation, not just the slow step. And the next time it happens, it’s auto-resolved.
In the product: Insight — BottleneckPanel + WhatIf
47 sec vs 3 hours — fix transferred to next occurrence
2. The Conservation Gate
$420K → $0
9,826 gate checks, zero violations — trust earned incrementally
3. The Compounding Gap
+28pp accuracy
Walk-out proof — $2.4M/year in recovered capacity
4. The Compounding Loop
1 decision → 3 updates
The engine — JM + DK + AgentEvolver
5. Data Intelligence
+42pp Day-1
Enrichment beats ontology — CGA scales by observation
6. The Self-Demotion
~7 of 10 rejected
5-stage lifecycle — the restraint IS the credibility
7. The 3-Way Match Fix
38 min → 5 min
Process mining shows WHERE — RGI traces the data lineage to WHY and generates the SAP fix
The compounding loop: one verified decision updates three things simultaneously — centroids (judgment memory), DK weights (factor importance), and AgentEvolver rules (automation candidates). This is why accuracy keeps climbing after static systems plateau.
ROUTE — graph of agents fans out work. Databricks, Palantir stop here.
RESHAPE — judgment graph decides, learns, compounds from verified outcomes. Only RGI.
The question that disqualifies: "After 1,000 decisions, show me how the system got smarter." dbt, Great Expectations, Monte Carlo, Bigeye — none can answer it. If your next vendor meeting can, talk to them. We will still be here — compounding.
Compounding Intelligence by RGI
The reasoning layer between your data platform and your agents.
Compounding Intelligence by RGI · All experimental results are measured, not modeled.
