One decision, five kinds of knowledge

Consider a simple enterprise decision. An AI system needs to determine whether a strategic customer should receive a $200,000 service credit.

To make that decision responsibly, it needs at least five different kinds of knowledge:

• Facts: The customer generates $18 million in revenue, has experienced three critical incidents and renews in 90 days.
• Policy: Service credits are permitted up to a defined percentage of contract value and under specific conditions.
• Authority: The agent can recommend any amount but can independently approve only $5,000.
• Experience: In comparable situations, customers accepted smaller credits combined with executive sponsorship and subsequently renewed.
• Intent: Protect the customer relationship while maintaining commercial discipline.

These are not interchangeable.

Facts require provenance and freshness. Policies require applicability, precedence, versioning and exception handling. Authority requires identity, delegation and enforcement. Experience requires more than a historical decision: it requires the original situation, the judgment made, the action taken and, critically, the outcome. Intent requires an explicit objective and a clear understanding of which trade-offs the business is prepared to accept.

When AI is answering a question, these distinctions can remain largely invisible.

When AI is making a judgment and taking action, they become fundamental.

Intelligence is not authority

An AI system might determine, with high confidence, that the full $200,000 credit is the right commercial decision.

That does not mean it has the authority to grant it.

Being capable, being compliant and being authorized are three different things.

Enterprises have spent decades building structures around precisely these distinctions. We separate information from policy, expertise from decision rights and recommendations from approvals. We establish delegation hierarchies, learn from precedent and evaluate decisions against business objectives.

An agentic enterprise needs to be architected with the same discipline.

The Enterprise Decision Fabric

An enterprise agent does not simply need more information in its context window. It needs access to the institutional machinery the enterprise already uses to make judgments.

We think of this as an Enterprise Decision Fabric, with five distinct planes:

• Fact: What do we know?
• Policy: What framework governs this judgment?
• Authority: Who or what is permitted to decide and act?
• Experience: What have we learned from comparable decisions and their outcomes?
• Intent: What are we trying to achieve?

Separating these planes also clarifies the role of the model.

Sometimes the right intelligence is a frontier LLM. Sometimes it is a specialized decision model such as Jev or a domain-specific predictive model. And sometimes deterministic business logic remains the most appropriate answer.

The agent harness has a different responsibility: planning, orchestration, tool and model invocation, state management, failure recovery and execution.

Models provide intelligence. Harnesses provide agency. Decision Fabrics provide institutional judgment.

What leaders should do now

• Map where your agents already hold real decision rights and who granted those rights.
• Treat policy and authority as systems that must be engineered, versioned and enforced—not paragraphs buried inside prompts.
• Assign clear accountability for every agent’s decisions, including what it knows, what it can do and what controls apply before and after deployment.
• Capture outcomes, not just decisions, so organizational experience becomes something future agents can learn from.
• Design explicit boundaries between recommendation, approval and autonomous action.

We spent the last decade engineering enterprise data and the last two years learning to engineer context.

The next discipline is decision engineering: designing how the enterprise makes decisions, what institutional knowledge those decisions depend on, and where AI fits into that system.

First, what this isn’t

This isn’t an argument for rationing AI, or for asking employees to use it more sparingly. Usage going up is usually a sign the tools are working, and the last thing you want is employees second-guessing whether a question is worth asking.

Which is exactly what’s starting to happen. McKinsey’s State of AI survey for 2026 — 1,719 business leaders across 97 countries — found that one in five organizations is now limiting how much AI it uses because of what it costs to run, token costs included. In the same survey, 60 percent expect to spend more on AI over the coming year, while the share reporting any real bottom-line impact sat at 37 percent, essentially where it was a year earlier. Spending is climbing, returns are flat, and a fifth of companies have begun throttling usage to control the bill.

And the overspend isn’t caused by volume in the first place. It’s caused by every request, regardless of difficulty, being priced as though it were the hardest thing you’ll ask all year.

Don’t use a Lamborghini for a milk run

A simple request like “What’s our travel expense limit?” doesn’t need the same model, compute, or cost as “Analyse the causes of our three-quarter sales decline and recommend what we should do next.”

Yet that’s how enterprise AI usually works today. The newest and most capable frontier models handle everything — the hard reasoning tasks, yes, but also the email summaries, the policy lookups, the reformatting. All at the same premium rate.

The reason is simple: whoever built the tool wired it to a single model, chosen for the most demanding thing it might ever be asked to do. Every easy request that follows inherits that price.

Why the bill is hard to see

AI usage is billed in tokens — roughly, the chunks of text a model reads and writes. More text processed means more tokens, which means more cost. It’s a small charge per request, which is exactly why it goes unnoticed. Nobody flags a few cents. But multiply a few cents by thousands of employees making dozens of requests a day, and the number stops being small.

Worse, most organizations can’t say what kind of work that budget is going toward. They can see a total. They can’t see that a third of it went to routine lookups a far cheaper model would have handled perfectly.

Sort by pattern, not by use case

What’s needed is a layer that looks at each incoming request, works out how demanding it actually is, and sends it to the cheapest model capable of doing that job well — automatically. This isn’t asking employees to choose a tool based on how hard their question is. People shouldn’t have to make that judgement, and if you ask them to, they’ll pick the premium option every time. Which is entirely rational, and defeats the purpose.

The instinct when building this is to catalogue every way people use AI. That list never ends, and it’s out of date by the time you finish it.

The more practical move is to look for the pattern underneath. Most AI requests are one of a handful of shapes: generate something new, condense something long, extract a specific fact, or work through a multi-step task using several tools. Organizations that do this exercise typically find that six to eight patterns explain the overwhelming majority of their AI usage, and therefore their spend.

Patterns are useful because they’re stable. New use cases appear constantly; the underlying shapes don’t. And once you know the shape of a request, you can make a sensible decision about what it costs to answer. 

Try the cheap option first — but check the work

Here’s the mechanism, in plain terms:

• Classify the request — what pattern is this, how demanding is it?
• Gateway choices — Apply best fit techniques for the pattern
• Route it to the cheapest model that should be able to handle that pattern.
• Check the answer against a quality standard. Correct, complete, right format?
• Escalate if it isn’t. The request goes automatically to the stronger model, and the user gets the better answer without ever knowing a swap happened.

The whole sequence happens in the time it takes to answer a question. The person asking sees one answer, not four steps.

Think of it as triage. A scraped knee doesn’t need a surgical team, but you want one on standby and the handover to be instant when it’s needed. What you don’t want is a system that quietly hands people worse answers to save money. The quality check is what separates the two — cost savings are only real if the output still clears the bar.

There’s an honest caveat worth naming: cheap isn’t cheap if it fails often. If a particular kind of task frequently needs escalating, you’ve paid twice — once for the failed attempt, once for the retry. Which is why this only works when you measure the miss rate per pattern rather than assuming it works everywhere.

One invisible gateway instead of five separate tools

Today, AI tools tend to arrive as separate products — one chat assistant here, another built into the office suite, a third inside developer tooling. Each with its own settings, rules, and bill.

The alternative is a single gateway sitting behind the interfaces employees already use. Nothing changes for them: same tools, same questions. The gateway simply decides what happens next.

That one checkpoint is where a surprising amount of value sits:

• Routing & escalation: Route each request based on task pattern and complexity to the model optimally priced for the required quality bar.
• Semantic cache: Reuse answers to repeated or semantically similar questions. If five people ask the same policy question in a week, only the first needs to reach a model.
• Policy & guardrails: Apply data-handling, security, and compliance rules consistently across models and vendors.
• Context & entitlements across models: Preserve the conversation and the user’s permissions when a request moves from one model to another.
• Prompt right-sizing: Remove unnecessary context and tokens before a request reaches the model, reducing cost without compromising the required output.
• Evaluation & cost ledger: Track requests in one place so the organization can see what its AI budget is buying, broken down by team, model, and type of work.

And there is a commercial benefit. When every AI request runs through your own gateway, switching, or adding a vendor becomes a configuration change rather than a rebuild.

Build it once, not thirty times

There’s another source of waste, less obvious than token spend. When teams build AI tools independently, they build the same things: their own document summariser, meeting scheduler, report drafter — each to a slightly different standard.

A shared library of common capabilities, built once and made available through templated prompts and tools, eliminates that duplication. For a large organization this can be a bigger saving than routing itself. The cost isn’t tokens; it’s engineering time spent solving the same problem thirty times.

What you’re actually buying

Paying premium rates for routine work is a choice. Most organizations are making it by default rather than on purpose because, until recently, the infrastructure to do anything else wasn’t in place. Once it is, usage can keep growing while the cost per unit of work falls.

But cost is only half of what you get. An organization that routes its own AI traffic knows what its AI budget is actually buying, broken down by team and type of work. It can also move between vendors without rebuilding the experience employees already use. Walk into a renewal conversation with those two facts in hand and it’s a different conversation entirely. Walk in without them and you’re accepting whatever the dashboard tells you.

Frontier models are worth their price for frontier problems. The rest of the time, you’re sending a Lamborghini for the milk.

And once every AI request passes through one front door, that door becomes the natural place to enforce everything else: enterprise policies, guardrails, and AI security and trust controls, set once and applied to every tool and every team. What starts as a cost decision becomes the foundation for AI trust and maturity.

Author

Customer Challenge: Fraud Decisions Happen After the Damage Is Done

For most financial institutions, fraud detection still operates after a transaction has already been authorized. While post‑transaction analytics help identify fraud patterns and recover losses, they fall short where it matters most—preventing fraudulent activity at the moment of payment.

Legacy fraud detection systems are typically optimized for batch processing and retrospective analysis, resulting in delayed decision‑making. At the same time, transaction data, customer behavior history, and risk signals are distributed across multiple systems, making it difficult to assemble a real‑time view of risk. As a result, organizations face a tradeoff between fraud prevention and customer experience.

Common challenges include delayed access to features, fragmented OLTP and analytics platforms, rigid rule engines with high false‑positive rates, and limited explainability once a transaction is flagged. Operations teams often struggle to answer a simple but critical question: why was this transaction considered fraudulent?

As payment volumes increase and fraud tactics evolve in real time, financial institutions need a new approach—one that delivers decision‑grade intelligence at transaction time, not after the fact.

Introduction: From Post‑Transaction Analytics to Transaction‑Time Intelligence

Modern fraud prevention requires more than faster models. It requires bringing real‑time decisioning, AI, and analytics onto the same platform. Rather than moving data across disconnected streaming systems, feature stores, decision engines, and analytics warehouses, organizations need a unified architecture that can handle all of it—securely and at scale. 

The Databricks Data Intelligence Platform enables this convergence. By unifying streaming ingestion, large‑scale analytics, machine learning, and governance within a single Lakehouse architecture, Databricks allows fraud decisions to be made while the transaction is in flight.

With Databricks Lakebase, real‑time fraud use cases can now access low‑latency features and state without duplicating data into external operational stores. Combined with serverless Delta Live Tables (DLT) and built‑in ML lifecycle management, Databricks makes near-real‑time fraud detection operationally feasible and architecturally streamlined. 

This blog introduces a near-real‑time credit card fraud detection solution framework that demonstrates how financial institutions can modernize fraud decisioning using Databricks—delivering faster decisions, better accuracy, and explainable outcomes. 

Solution Overview: A Near-Real‑Time Fraud Detection Solution Framework on Databricks

The solution framework is designed as a reusable architecture pattern, rather than a one‑off implementation. Its objective is to score transactions in near real time, enable intervention before authorization, and continuously improve fraud detection outcomes using a single governed data foundation.

At a high level, the solution delivers:

• Streaming‑first ingestion of transaction events 
• Near-real‑time feature engineering at transaction scale 
• Low‑latency feature access with Databricks Lakebase 
• Machine learning–driven fraud scoring 
• Natural language explainability with Databricks Genie

Streaming Ingestion and Processing 

Credit card transactions are ingested as a continuous event stream and processed using Databricks Structured Streaming. This enables low-latency processing while maintaining strong reliability and exactly‑once semantics. 

Feature Engineering with Delta Live Tables (DLT)

Delta Live Tables provides a serverless, declarative framework to transform raw transaction streams into fraud‑ready features. Streaming and historical signals—such as spend velocity, geolocation patterns, merchant behavior, and customer risk history, are continuously updated and validated.

By automatically managing orchestration, scaling, and data quality checks, DLT enablesfraud teams to focus on feature logic rather than pipeline operations.

Online Feature Access with Lakebase

Transaction‑time fraud detection requires millisecond‑level access to recent customer and card activity. Databricks Lakebase enables this by serving as a low‑latency operational layer fully integrated with the Lakehouse.

Features and transactional state stored in Lakebase remain governed, consistent, and immediately available for both online scoring and offline analysis, eliminating the need for separate feature stores or operational databases.

Real‑Time Scoring and Decisioning

Machine learning models trained on historical fraud patterns generate a risk score for each transaction. This score is combined with configurable business rules to enforce regulatory controls and business thresholds. 

The result is a decision that can be acted upon immediately—approve, challenge, or decline—before the transaction is authorized. 

Explainability with Databricks Genie

Trust and transparency are essential in fraud detection. Databricks Genie enables fraud analysts and business users to query transactions, risk scores, and contributing features using natural language. 

Teams can quickly understand why a transaction was flagged, how customer behavior deviated from normal patterns, and which signals drove the final decision—all without custom dashboards or complex SQL. 

Conclusion: Proactive Fraud Prevention with Databricks

Fraud prevention is fundamentally a timing problem. The value of analytics drops sharply once a transaction is complete. To stay ahead of increasingly sophisticated fraud schemes, financial institutions must shift from reactive investigation to proactive, transaction‑time decisioning. 

This near-real-time fraud detection solution framework shows how Databricks enables that shift. By unifying streaming data, AI, low‑latency feature access, and explainability on one governed platform, organizations can stop fraud before it happens—while improving customer experience and operational efficiency. 

Beyond credit card fraud, this solution framework serves as a foundation for other transaction‑time use cases such as payment risk management, credit assessment, and anomaly detection. With Databricks, real‑time intelligence becomes a built‑in capability of the data platform—not an afterthought. 

The Problem: Fragmented Systems and Delayed Decisions

Most insurance enterprises still operate on fragmented architectures where claims platforms, underwriting tools, and analytics environments function in isolation. This creates several critical challenges:

• Batch-driven processing: Claims are processed in periodic cycles rather than in real time, delaying approvals, settlements, and overall response times.
• Data silos and inconsistency: Disconnected systems maintain separate copies of data, resulting in inconsistent views across channels and reduced trust in information.
• Reactive decision-making: Fraud detection, risk evaluation, and actuarial calculations often occur after transactions are completed, increasing financial exposure.
• Complex data movement: ETL pipelines are required to move data between operational systems and analytics platforms, introducing latency and operational overhead.

Together, these limitations make it difficult for insurers to deliver a responsive customer experience while also increasing cost, complexity, and risk.

The Solution Framework: A Lakebase-Centric Approach

To address these challenges, Impetus designed a solution framework for real-time claims processing, built on Databricks Lakebase, that unifies transactional operations and analytics on a single, real-time platform.

In this solution framework approach, all core business transactions—such as customer updates, claim submissions, and payment processing—are captured directly in Lakebase, which serves as the operational system of record. Lakebase provides low-latency, ACID-compliant processing with high concurrency, ensuring that data remains consistent and immediately available.

Unlike traditional architectures that separate operational and analytical systems, this solution framework keeps data within a single platform and changes are synced into the Databricks Lakehouse. This eliminates the need for complex ETL pipelines and ensures that analytics and AI operate on fresh, consistent data.

Architecture Overview: Unified Operations and Analytics

The solution framework architecture is designed to seamlessly connect business applications, transactional processing, and analytics:

• Frontend applications: Customers, agents, and partners interact through web and mobile applications for activities such as claim submissions.
• Databricks Apps (API layer): Acts as the backend layer, handling API orchestration, validation, and business logic.
• Lakebase (operational layer): Stores all transactional data—including customers, claims, and payments—and ensures real-time updates across the system.
• Business engines: Claims, underwriting, and payment engines operate directly on Lakebase to execute business rules and decisions.
• Lakehouse (analytical layer): Data from Lakebase is synced into the Lakehouse and organized into Bronze, Silver, and Gold layers for analytics and reporting.
• Analytics and AI layer: Enables dashboards, fraud detection, risk scoring, and actuarial insights using tools such as Databricks SQL and MLflow.

The outcome is a single data foundation that supports both operational and analytical workloads, enabling real-time processing and decision-making.

Key Capabilities: What This Enables

By combining Lakebase with the Lakehouse, it delivers several powerful capabilities:

1. Real-time claims processing: Claims can be submitted, validated, and processed instantly, shortening settlement cycles and lifting customer satisfaction.

2. Unified data platform: Operational and analytical data coexist in the same platform, eliminating data duplication and ensuring a single source of truth.

3. Instant insights on live data: Fraud detection, risk scoring, and actuarial calculations can run on live transactional data rather than on delayed datasets.

4. Elimination of ETL overhead: Removing complex data pipelines reduces latency, infrastructure cost, and operational complexity in one move.

5. High-concurrency processing: The platform supports simultaneous reads and writes, enabling real-time interactions across customer portals, underwriting systems, and analytics tools.

Business Impact: Transforming Claims Processing

The solution framework shifts claims processing from a reactive, batch-driven model to a proactive, real-time model, delivering measurable business benefits:

• Faster claims settlement: Reduced turnaround time improves customer experience and satisfaction.
• Improved risk management: Real-time insights help detect fraud and manage exposure proactively.
• Operational efficiency: A simplified architecture reduces maintenance and integration costs.
• Better decision-making: Access to live, consistent data enables faster and more informed business decisions.
• Regulatory compliance: Unified governance improves traceability, auditability, and control.

Overall, insurers can operate more efficiently while delivering a more responsive and transparent experience to customers.

Conclusion: From Systems of Record to Systems of Action

Traditional systems were designed primarily to record the transactions. Modern insurers, however, need platforms that can act on those transactions instantly. By leveraging Lakebase as the operational backbone and the Lakehouse for analytics and AI, this solution framework bridges that gap, enabling real-time decisioning on a unified data platform.

The result is not just an architectural transformation but a fundamental shift in how claims processing are executed—from delayed processing to real-time, insight-driven action.

From Oracle Workload Complexity to Databricks-Native Execution

Oracle-to-Databricks modernization is not a one-dimensional code conversion exercise. It spans the full operating fabric of the Oracle estate which must be assessed, modernized, validated, and reassembled for Databricks-native execution.

LeapLogic™ Migrate transforms these assets with a target-native lens, preserving the original business intent while reshaping each workload for seamless execution on Databricks.

Oracle workload type	Modernization approach with Impetus LeapLogic™ Suite	Databricks-aligned target pattern
Schemas and DDLs	Restructured for modern lakehouse patterns while preserving source data definitions and relationships.	Delta Lake, Unity Catalog-aligned structures, Medallion architecture.
DMLs and SQL logic	Converted into Databricks-aligned SQL with optimized execution patterns.	Databricks SQL, Delta-optimized processing.
ODI jobs, load plans, packages, and mappings	Interpreted as enterprise data movement and orchestration logic, not just ETL scripts.	Lakeflow for ingestion, transformation, streaming, batch, and orchestration use cases.
OBIEE subject areas, reports, dashboards, and metrics	Treated as business-consumption intelligence with embedded semantic and KPI context.	AI/BI, governed reporting foundations, business-ready data products.
PL/SQL procedures and cursor logic	Refactored from row-by-row procedural execution into set-based, Databricks-native patterns.	Joins, aggregations, window functions, optimized SQL, PySpark, reusable notebooks.
Exadata and analytical workloads	Modernized into scalable analytical foundations for performance, governance, and AI- readiness.	Databricks Lakehouse, Medallion architecture, governed data products.
Real-time/OLTP Oracle usage	Identified separately from analytical workloads and routed to operational modernization patterns where relevant.	Lakebase for real-time/operational workloads, alongside Lakehouse for analytics.

The true value of modernization is not only in converting assets, but in reassembling them into a cleaner Databricks-native operating model that ensures high performance post migration.

With Impetus LeapLogic™ Suite, analytical workloads can move into Lakehouse and Medallion patterns, domain intelligence can evolve into governed data products, data movement can align with Lakeflow, and real-time or operational use cases can be evaluated for Lakebase. That is how Oracle complexities give way to a modern, AI-ready enterprise data foundation.

AI Augmentation Brings Automation with Controls

Impetus LeapLogic™ Suite combines deterministic conversion intelligence with AI augmentation to improve automation, scale, and certainty. Generative AI is applied where context matters most:

• Interpreting ambiguous procedural logic 
• Resolving complex transformation patterns 
• Optimizing target constructs 
• Accelerating long-tail, difficult conversions 

Every converted artifact is then checked through iterative review loops using multiple partner LLM providers and reviewer models.

These reviewer models inspect the output for semantic alignment, logic preservation, syntactic correctness, and Databricks readiness. Where gaps are detected, the conversion is refined and checked again.