Boards have approved the AI and data spend. Models are in production. The question now being asked in every steering committee is the same one: where is the revenue? Organisations buy Pega, Salesforce, Adobe or Braze and assume personalisation follows. It rarely does. The engines are mature — the bottleneck is almost always the same, whatever the vendor or industry: the data reaching the decision isn't decision-ready. Scattered across source systems, aggregated in the wrong layer, refreshed on the wrong cadence, or arriving too late to matter.
The Decision-Ready Data Layer is the layer between static data storage and real-time activation: a vendor-agnostic reference architecture, attribute taxonomy, readiness diagnostic and delivery playbook — built from seven live decisioning implementations, not from research.
It turns dormant data spend into measurable revenue without replacing your core stack. The platforms you have bought are almost never the problem, and a rip-and-replace is almost never the answer.
This is the short form of the diagnostic. The full engagement scores each dimension against evidence rather than self-report, and produces a prioritised remediation roadmap.
A sixth is now arriving with third-party cookie deprecation: the same customer state that drives inbound decisions has to be pushed outward, server-side and consent-governed, to paid media and measurement — and most organisations are building that as a second, unrelated pipeline. It is the same layer, or it will drift.
None of these are decisioning-engine problems. They are data product problems — and they need the discipline used to build any production data product: a reference architecture, an explicit schema, defined SLAs, and something to measure against. Not another vendor tool.
Transformation logic gets pushed into the application or presentation layer — a CRM, a middleware service, a reporting database — instead of the aggregation layer built for it. Result: duplicated logic, drift between channels, numbers nobody can trace.
Clickstream, app activity, IVR and transaction events flow through the messaging layer but never land in the engine's adaptive models. The platform is technically real-time and still deciding on stale, batch-refreshed profile data.
Prioritisation logic is split across the CRM, the campaign tool, the app and the engine, each applying its own rules. No single system can explain why a customer got the offer they got — which is also a regulatory exposure.
New or changed attributes take weeks to reach the decisioning layer, because provisioning was hand-built per attribute, per request, instead of designed once as a repeatable pipeline.
Programmes report impressions and use cases live, because the data needed to trace an action to attributed revenue was never modelled as a first-class citizen of the decision-ready layer. Retrofitting it is expensive and usually partial.
Every one of these is a symptom of the same thing — the data layer was built as a series of one-off requests behind a platform purchase, rather than designed, owned and governed as a product in its own right.
A fast, denormalised, always-current customer store sitting between slow systems of record and the decision itself — so a decision request never waits on a live query to core banking, POS or billing. Pega backs it with Cassandra; Salesforce Data Cloud, Adobe Real-Time CDP and custom Kafka stacks solve it in structurally identical ways. The pattern is the product. The technology is an implementation detail.
Abstracted from vendor-specific implementations. The highlighted layer is where most programmes are actually broken.
Same source systems, same platform licences. The change is where logic and state live — not a replacement programme.
Who the customer is. Customer ID, segment or tier, tenure, relationship start, demographics.
What they hold with you. Products, balances or usage, contract status, relationship value.
What they are doing, in near real time. Sessions across 30 minutes to 90 days, channel activity, basket events, service contacts.
What the engine needs to arbitrate. Propensity scores, last accept or reject, contact counts by period, eligibility flags, action history.
Deliberately industry-neutral: “holdings” becomes accounts in banking, SKUs in retail, plans in telco, policies in insurance. Identity resolution, consent state and hashed identifiers sit in domain 01 — which is what makes the same layer usable for cookieless server-side activation.
Four levels of depth, sold separately. Most clients start at the first and stop when they have what they need.
Fixed scope. Scores your pipeline against the five dimensions using evidence rather than self-report, and produces a gap map with a prioritised remediation roadmap.
The four-domain taxonomy built out to attribute level for your sector and platform — cutting weeks off a typical data-model build.
Hands-on delivery leadership applying the playbook to the highest-impact gaps first. Embedded in your programme, not handing over a document.
A single arbitration authority, a change lifecycle for new actions and attributes, and clear accountability per layer — so the fix survives past the launch.
Every pattern here was diagnosed — and mostly remediated — inside live, complex, regulated environments. Seven real-time decisioning implementations across major Australian financial institutions and a telco, then a full programme build at a top-five MENA bank: from two people and no live use cases to a 42-use-case capability across eight channels in under two years, with independent attribution putting incremental revenue at a multiple of run cost.
The method has an academic spine as well as a delivery one. My master's research at UTS on Next-Best-Action decisioning has passed 2,000 downloads — over 500 in the past year — and is still being pulled into production environments six years on. Not cited in journals. Deployed.
Razvan Codis. Econometrics (UNSW), Master of Analytics Research (UTS, 2020), TOGAF and ArchiMate certified. Based in Sydney, working across the east coast and MENA.
Almost never because the decisioning engine is wrong. In practice five things break, in this order of frequency: transformation logic lands in the wrong layer; behavioural events stream through the infrastructure but never reach the adaptive models; arbitration logic is fragmented across channel tools; new attributes take weeks to provision; and there is no data trail from an action back to attributed revenue. All five are data product problems, not platform problems.
A fast, denormalised, always-current store of customer state that sits between slow systems of record and the decision itself, so a real-time decision never waits on a live query to core banking, billing or POS. Pega implements it as a Cassandra-backed cache; Salesforce Data Cloud, Adobe Real-Time CDP and custom Kafka stacks solve the same problem in structurally identical ways. The pattern matters; the technology is an implementation detail.
Usually because the model output never becomes a governed decision at the point of interaction. A propensity score sitting in a warehouse changes nothing. Value appears only when that score is arbitrated against other candidate actions, filtered by eligibility and consent, delivered on a channel, and measured against a control. That chain is the decision layer, and it is almost always the missing piece rather than the modelling.
Agents don't replace the data layer — they expose it. An autonomous agent handling a customer conversation needs current, permissioned context in milliseconds. Querying transactional systems of record mid-conversation introduces latency the customer feels, and pushing raw unstructured records into the prompt inflates token cost and invites ungrounded answers. A decision-ready layer already solves exactly that problem for decisioning engines: pre-aggregated, governed customer state, retrievable in under 200ms. The same layer serves an agent. Organisations that build a separate context pipeline for AI end up with two versions of the customer and two consent models.
A CDP unifies and segments customer data. A decision-ready layer serves a decision under latency, with the derived attributes an arbitration engine actually needs — propensity scores, contact counts by period, last accept or reject, eligibility flags. Many organisations buy a CDP and discover it was never designed to answer a decision request in under 200 milliseconds. The two are complementary; they are not substitutes.
No. The architecture is identical across sectors — systems of record, aggregation layer, event stream, decision-ready store, arbitration engine, channels. Only the attribute content changes: holdings become accounts in banking, SKUs in retail, plans in telco, policies in insurance. Banking is the reference case because that is where the pattern was built and proven under regulatory pressure.
The same governed, consented event set that drives inbound decisions is what a conversions API needs to send outbound to paid media and measurement. Organisations that build that as a separate marketing pipeline end up with two identity graphs, two consent states and two definitions of a conversion. It belongs in the same layer — and the hard part is propagating lawful basis with each event, not calling the API.
Two to three weeks, fixed fee, fixed scope. Each of the five dimensions is scored against evidence rather than self-report, producing a gap map and a prioritised remediation roadmap you own outright, whether or not any further work follows.
Razvan Codis — econometrics at UNSW, Master of Analytics Research at UTS, TOGAF and ArchiMate certified. Seven live real-time decisioning implementations across major Australian financial institutions and a telco, then a full programme build at a top-five MENA bank. Based in Sydney, working across the east coast and MENA.
Fixed scope, two to three weeks, and you own the output whether or not we work together afterwards.
A short call is enough to know whether there's a fit. If there isn't, I'll say so.