A Vendor-Neutral Reference Architecture for Modern Customer Experience Platforms

A practical model for connecting customer signals, identity, data, analytics, decisions, delivery, governance, and measurable outcomes—without beginning with a vendor’s product map.

Most customer-platform diagrams are reassuring at first glance. Data sources appear on the left, a large “customer 360” or “unified profile” sits in the middle, and channels appear on the right. Arrows suggest that everything connects. The architecture looks complete.

Then a real customer does something.

An anonymous visitor views a product, signs in, receives an offer, buys through another channel, withdraws consent a week later, and asks for their data to be deleted. Which identifier should connect the anonymous and known activity? Which system is authoritative for the purchase? Was the offer merely selected, or was it actually displayed? What happens if the decision service times out? Where is the consent change enforced? Can the outcome be used to claim incremental impact? Which derived profiles, audiences, caches, exports, and processors must change when the customer’s rights are exercised?

The familiar diagram rarely answers these questions because it describes a product estate, not an operating system for customer experience.

A modern customer experience platform is not a single database, CDP, journey tool, analytics application, or decision engine. It is a governed and observable system that turns customer and operational signals into eligible decisions and delivered experiences, then returns outcomes as trustworthy learning data.

This article presents Ciqor’s vendor-neutral reference architecture for that system. It has 12 logical capability layers, three operating paths, a separate control plane, and five cross-cutting responsibilities. The layers do not require 12 products. One product may cover several responsibilities; several products may share one. The point is to make the responsibilities, interfaces, service levels, owners, and failure behaviour visible before deciding what to buy or build.

Ciqor signal-to-outcome loop showing seven stages: Observe, Qualify, Remember, Understand, Decide, Deliver, and Learn, surrounded by privacy, security, governance, and reliability. — **Figure 1 — The Ciqor signal-to-outcome loop.** Observe → Qualify → Remember → Understand → Decide → Deliver → Learn → Observe. Delivery is not the endpoint: decisions, exposures, outcomes, costs, and harms return as governed learning data.

The model is a Ciqor synthesis of documented patterns across customer-data platforms, analytics and decisioning systems, data infrastructure, and privacy guidance. Vendor documentation is used as evidence that a pattern exists in a documented implementation—not as proof that the pattern is universal, complete, or uniquely superior.

Start with the decision, not the product inventory

The smallest useful unit of customer-experience architecture is not “the CDP” or “the martech stack.” It is a bounded decision and the outcome it is intended to influence.

Consider a retailer deciding whether to show a particular offer during a product interaction. Before selecting technology, the team should be able to state:

Actor or entity: Who or what is the decision about—an anonymous browser, an authenticated customer, an account, a household, or a device?
Trigger: What creates the need to decide—a page request, cart event, service case, inventory change, scheduled evaluation, or journey transition?
Eligible actions: What may the system do—show an offer, recommend content, suppress a message, route a case, or choose no action?
Context: Which current and historical facts are necessary to decide?
Constraints: Which permissions, purposes, product rules, inventory limits, frequency caps, risk policies, and content rights apply?
Time: How fresh must each input be, and how quickly must the decision reach the experience?
Delivery evidence: How will the system know the selected action was actually rendered or sent?
Outcome: Which event represents success, failure, cost, or harm—and which system is authoritative for it?
Measurement design: Is the question descriptive, predictive, or causal? Is a control or holdout required?
Failure behaviour: What happens when identity, context, decisioning, or delivery is unavailable?

This decision contract exposes architecture requirements that a feature checklist conceals. A “real-time profile” is irrelevant if the interaction can tolerate an hour of freshness. Conversely, a fast decision API is insufficient if it synchronously waits for five slow systems. A unified audience is not useful if permission is stale. A conversion report is not a causal result merely because the customer saw—or may have seen—a personalised treatment.

The architecture should therefore begin with a traceable path:

signal → qualified event → durable/current context → eligible candidates → decision → delivery or exposure → authoritative outcome → measured learning

Every arrow is a contract. Every contract needs an owner, time semantics, privacy basis, failure behaviour, and evidence.

Five boundaries to establish before drawing the layers

The reference model becomes much easier to use when five boundaries are explicit.

1. A capability is not a product

Collection, identity resolution, audience computation, decisioning, orchestration, and measurement are responsibilities. Commercial products package them in different combinations, and those combinations change over time. An architecture that begins with product boxes can accidentally make one vendor’s packaging look like a universal design.

A logical model instead asks what must happen, what enters and leaves each responsibility, and what qualities the interface must preserve. Only then should an organisation decide whether to consolidate the responsibility inside one platform, compose specialised services, or build a narrowly differentiated component.

Vendor-neutrality does not mean removing logos from a diagram. It means that a component can be replaced without silently changing the business contract, identity semantics, privacy controls, measurement definitions, or operating model.

2. The data plane is not the control plane

The data plane is the runtime path: customer and operational data is collected, transported, stored, resolved, queried, served, activated, delivered, and measured.

The control plane determines how that runtime behaves. It contains schemas, source registrations, purposes, access rules, identity policies, metric definitions, feature logic, decision policies, model versions, deployments, lineage, retention schedules, service-level objectives, and approvals.

This distinction is implemented in current customer-data infrastructure. For example, Snowplow documents deployment patterns where management interfaces and APIs form a control plane while pipeline infrastructure and data destinations form the data plane. The exact hosting split is product-specific; the durable architectural lesson is not. Runtime data and the configuration governing it have different change, security, audit, and recovery needs.

If an identity link is created in the data plane, the control plane should reveal which namespace, match rule, confidence threshold, precedence rule, and policy version authorised it. If an offer is selected, the control plane should reveal the eligible catalog, exclusion rules, ranking method, model version, fallback, and holdout policy. Without that evidence, the system can operate but cannot be governed.

3. Durable history is not an operational profile

Durable event history and authoritative business records are optimised for completeness, provenance, reconciliation, evolution, and analysis. A profile or feature service is optimised to supply bounded context to an operational decision within a latency and freshness target.

Those are different workloads.

The order-management system may remain authoritative for an order. A lakehouse may preserve the complete event and transaction history. A profile service may expose “last product viewed,” “loyalty tier,” or “predicted churn risk” to a decision. None should automatically be declared the universal source of truth.

Treat the profile as a time-dependent, purpose-built serving view. Every important attribute should retain its source, effective time, freshness, derivation, privacy classification, and time-to-live. This reduces the damage caused by stale values, conflicting systems, and over-broad “golden record” claims.

4. Audience, decision, and orchestration answer different questions

An audience answers: Which profiles or entities met a reusable condition when the audience was evaluated?

A decision answers: Given the current context, applicable policy, eligible actions, and ranking method, what should happen now?

Orchestration answers: How should stateful steps, waits, conditions, retries, approvals, and channel actions be coordinated over time?

Current decisioning platforms demonstrate the distinction. Adobe Journey Optimizer documents catalogs of decision items, eligibility rules, ranking methods, selection strategies, and decision policies. Its offer-decisioning architecture pattern separates central offer selection from the channel that renders or sends the result.

The pattern is useful beyond any one product. Audience membership can contribute to eligibility, but it should not be mistaken for the final interaction decision. A profile may enter a “high-value cart abandoner” audience at 10:00, withdraw permission at 10:05, purchase at 10:07, and return at 10:10 when inventory is gone. A decision made at 10:10 must consider the current facts.

5. Selection, exposure, and outcome are different events

A decision service can select an offer without the channel rendering it. The channel can render it without the customer noticing or engaging. The customer can purchase for reasons unrelated to the treatment.

Reliable measurement therefore distinguishes:

assignment: which experimental or policy condition applied;
decision: what the system selected and why;
delivery or exposure: what was actually sent or rendered;
outcome: what subsequently happened in the authoritative source;
cost and harm: what the action consumed or adversely affected; and
control/no-action/failure: what did not happen and why.

The identifiers connecting these records are part of the architecture, not reporting decoration. A conversion after a treatment is an observed association. Incremental impact requires an identification strategy, such as an appropriate control or holdout, and assumptions that survive scrutiny.

The 12-layer reference architecture

The main model contains 12 logical layers. It is deliberately more detailed than a “sources → profile → channels” diagram because the seams are where systems fail, rights are lost, and measurement becomes ambiguous.

Vendor-neutral customer experience platform reference architecture with 12 logical capability layers, a control plane, cross-cutting trust and operations, and a measurement feedback loop. — **Figure 2 — Ciqor’s 12-layer logical reference architecture.** Capabilities and contracts from sources and collection through decisioning, delivery, measurement, and governed feedback. The layers are logical responsibilities and do not require 12 separate products.

Layer 1: Sources and experience surfaces

Sources generate signals. Surfaces deliver experiences. Often the same system does both.

Websites, mobile applications, point-of-sale systems, call centres, CRM applications, commerce platforms, service systems, connected devices, ad platforms, warehouses, and partner feeds all observe different slices of reality. A browser sees an interaction; an order system knows whether money was accepted; an inventory service knows whether an item can be promised; a service platform knows whether a case is unresolved.

The most important design question is not “Can we connect the source?” It is: What does this source know authoritatively, and what does its signal actually mean?

A button click may indicate intent. It does not prove an order. A message send request does not prove delivery. A client timestamp may be delayed or manipulated. A destination’s “success” response may only mean the payload was accepted.

Source contracts should identify the event producer, observation time, ingestion time, entity identifiers, context, schema version, provenance, and applicable purpose metadata. Surfaces should emit delivery, exposure, error, and cost evidence—not merely consume decisions.

Layer 2: Collection and edge

Collection captures signals close to the source and converts source-native payloads into authenticated, time-aware envelopes.

This can include browser and mobile SDKs, server-side endpoints, webhooks, APIs, file ingestion, change-data capture, edge nodes, and partner connectors. The collection design must handle offline queues, retries, duplicate sends, blockers, clock skew, network loss, client tampering, SDK upgrades, and regional routing.

The edge is useful when an experience has a strict latency budget or when collection policy must be enforced before data travels deeper into the platform. It is not a magical location where every capability should run. Complex identity traversal, large historical queries, and slow synchronous fan-out can make an “edge” path slower and less reliable than a small central service.

Snowplow’s documentation shows one current pattern: define events, collect across multiple SDKs and sources, enrich and validate them, load valid data to a warehouse or lake, and stream enriched events to downstream platforms. The architectural lesson is to separate capture from later interpretation while preserving a contract between them.

Layer 3: Gateway, contracts, and policy enforcement

The gateway is where a signal becomes a qualified event—or is explicitly refused.

It authenticates the producer; validates schema, types, required fields, and versions; applies minimisation and classification; enriches trusted context; evaluates collection policy; and routes, redacts, rejects, or quarantines the event. Invalid or disallowed data should not quietly become permanent history.

A useful event taxonomy begins with business objectives and metrics, then specifies the events and properties required to answer them. Amplitude’s taxonomy guidance similarly connects business objectives, metrics, events, properties, naming consistency, and the cost of later schema rework. Its naming conventions are product guidance rather than a universal standard, but the underlying principle is durable: an event contract must make meaning consistent enough to test.

For each critical event, the control plane should hold at least:

business definition and owner;
producer and allowed environments;
schema and compatibility policy;
event-time and ingestion-time semantics;
identity fields and namespaces;
required purpose or policy context;
quality rules and acceptable thresholds;
routing and retention classification;
rejection/quarantine behaviour; and
decision, exposure, or outcome role where applicable.

The failure question is simple: Can the platform explain why an event was accepted, changed, blocked, or quarantined?

Layer 4: Event backbone and integration

An event backbone decouples producers from consumers. It buffers bursts, partitions streams, preserves order within defined keys, allows independent consumers, and supports recovery or replay under a stated retention policy.

Apache Kafka’s design documentation describes a persistent log built for high-throughput event streams, large backlogs, low-latency delivery, partitioned processing, and fault tolerance. Consumers track offsets and can re-read retained data—a powerful capability when a consumer is repaired, a transformation changes, or a new use case needs history.

But replay has limits. It does not undo an email already sent, a discount already granted, or an external API side effect. Consumers must still use idempotency keys, deduplication, transaction boundaries, and reconciliation.

The same caution applies to “exactly once.” Kafka documents exactly-once processing within a bounded Kafka read-process-write flow under the required transaction and isolation settings. It explicitly notes that exactly-once delivery to other destination systems generally requires cooperation from those systems. The safe architectural statement is therefore: identify what is transactional, make external effects idempotent where possible, and reconcile what cannot share the transaction boundary.

An event backbone is also not automatically the permanent analytical record. Its role, retention, compaction, security, replay window, regional strategy, and consumer-lag SLO should be explicit.

Layer 5: Durable history and systems of record

Durable history preserves what happened at the grain needed for audit, reconstruction, modelling, and analysis. Systems of record preserve authoritative business state. The architecture should respect both instead of copying everything into a profile and declaring the problem solved.

A durable customer-event history needs versioned schemas, provenance, access controls, retention and deletion processes, late-arriving data handling, and the ability to rebuild derived views. Open table formats illustrate some of the relevant engineering properties. Apache Iceberg supports schema evolution and evolving partition specifications; its evolution documentation explains how old and new partition layouts can coexist without an eager rewrite of all existing files. That is not a substitute for event-contract governance, but it reduces the pressure to freeze physical design forever.

Not every read requires centralising every record. Trino documents a connector-and-catalog model that can query multiple configured sources, including different source types, in one SQL environment. Customer platforms also combine federation and ingestion. Adobe Federated Audience Composition documents querying warehouse data to create or enrich audiences without copying the underlying warehouse records, while persisting the resulting operational audience in Experience Platform. Salesforce Data 360 documents both ingested objects and read-only zero-copy federation to partner data platforms.

Federation is a design choice, not an exemption from architecture. Source compute, permissions, semantics, lineage, query cost, freshness, availability, and derivative results still require ownership. “Without copying the underlying data” must not become “no data or metadata moves, nothing is stored, and no governance is needed.”

Layer 6: Identity, entity, and profile context

Identity resolution associates identifiers and activity under declared rules. Profile services expose current or recently computed context to operational consumers. These responsibilities are related but should not be collapsed into the phrase “single customer view.”

Identity is a governed inference. Even deterministic identifiers can be misused: households share devices, accounts are recycled, employees enter incorrect emails, and a login may occur after several people used the same browser.

Tealium’s visitor-stitching documentation describes one implementation that associates anonymous profiles with known identifiers across sessions and devices. It also documents shared-device “visitor switching,” identifier evaluation order, and the limitation that stitched profiles cannot be separated. That limitation is not universal across platforms, but it demonstrates why merge policy is a risk control, not a background setting.

Other current patterns distribute profile responsibility differently. Segment Profiles Sync can send identity-resolved profiles to a warehouse; its setup documentation describes an hourly sync, which is useful but should not be called real time. RudderStack Profiles documents declarative identity-stitching rules, entity relationships, and features defined close to warehouse data.

Whatever the implementation, the architecture should preserve:

identifier namespace and source;
link provenance and effective time;
match and reconciliation rule version;
confidence or certainty category where relevant;
attribute-level authority and precedence;
shared-device and household policy;
merge, unlink, rebuild, and deletion behaviour; and
purpose and permission constraints on both linking and use.

A useful profile is not the one containing the most data. It is the smallest governed view that reliably serves the intended decision.

Layer 7: Analytics, semantics, and knowledge

This layer turns durable data and resolved context into metrics, dimensions, aggregates, features, models, and reusable business knowledge.

The key architectural problem is semantic consistency. “Active customer,” “conversion,” “revenue,” “eligible account,” or “high value” cannot mean one thing in a dashboard, another in a decision engine, and a third in an AI assistant.

A semantic layer is one current way to centralise definitions. dbt documents centrally defined metrics, dynamic SQL generation, APIs, dimensions, entities, and downstream integrations intended to produce consistent answers. A semantic product does not repair bad sources, answer causal questions, or guarantee performance, but the pattern is important: definitions should be governed and reusable rather than reimplemented in every consumer.

Operational features need additional contracts: source, transformation, entity key, event-time window, freshness, time-to-live, training/serving consistency, privacy class, expected distribution, quality tests, and owner. Knowledge supplied to people or agents should retain provenance, permissions, currency, and evidence. AI does not reduce the need for semantics; it makes inconsistency easier to automate at scale.

Layer 8: Audiences, eligibility, and constraints

Audiences are reusable populations evaluated at a particular time. Eligibility determines whether a person, account, item, or action may participate in a decision now. Constraints enforce rules such as purpose, permission, product suitability, geography, inventory, channel availability, frequency, contact policy, content rights, capacity, and risk.

This layer should produce more than a Boolean label. For operational use it should expose the entity, qualifying rule or audience version, evaluation time, expiry/freshness, reason, exclusions, and policy result.

Staleness matters. A customer may be a member of an audience computed in the warehouse each morning, but the decision at noon may need a current suppression, stock level, service status, or consent state. Reusable membership can narrow the candidate set; it should not bypass interaction-time constraints.

The critical failure question is: Can a stale audience or attribute cause an action that current policy would forbid? If the answer is yes, the architecture needs an interaction-time control or a shorter, monitored freshness contract.

Layer 9: Decisioning and experimentation

Decisioning selects or ranks an action, item, message, treatment, or no-action state under current context and policy.

A robust decision contract includes:

request and decision identifiers;
subject/entity and context version;
candidate set and relevant exclusions;
selected item or explicit no-action/fallback;
policy, rule, model, and catalog versions;
reason codes or decision evidence appropriate to the use case;
experiment or holdout assignment;
decision time, expiry, and latency; and
constraints applied.

Machine learning is optional. Many consequential or sparse decisions are better served by reviewed rules, constrained rankings, or slower model updates. Where adaptive methods are appropriate, the objective and exploration policy must be explicit. Optimizely’s contextual multi-armed-bandit documentation describes using user attributes and past responses to choose variations while balancing exploration and exploitation around a defined primary metric. It also distinguishes dynamically allocated bandits from fixed-split A/B tests that support a conventional significance comparison.

The architectural lesson is broader than the implementation: optimisation still needs stable identifiers, trustworthy events, monitored guardrails, a declared objective, negative outcomes, and an evaluation design. A system that relentlessly improves clicks while degrading profit, trust, fairness, or long-term retention is not well governed.

Layer 10: Journey and workflow orchestration

Orchestration manages state over time: wait, listen, branch, approve, retry, escalate, suppress, and coordinate channel or operational actions.

It consumes signals and decisions, but it should not silently redefine them. A journey may ask a decision service what to do at a step; the decision service may return no action because the customer is ineligible; the orchestrator should record that result and follow an explicit branch rather than treating it as an error.

Stateful orchestration must handle duplicate and late events, re-entry, conflicting journeys, cancellation, frequency, concurrent state changes, channel failure, and human approval. It needs correlation identifiers and versioned definitions so an operator can answer: Which journey version was this person in? Which event advanced it? Which decision policy ran? Why was a message suppressed or retried?

The most dangerous orchestration is one that appears visually simple because reliability, consent, identity, and failure behaviour are hidden in connectors.

Layer 11: Activation and delivery

Activation moves audiences, attributes, decisions, or instructions to execution destinations. Delivery renders or sends the experience through a web surface, mobile app, email provider, advertising platform, call-centre interface, service workflow, or another operational system.

These are not the same outcome. A destination may accept a file without matching every record. An email platform may accept a send request without delivering the message. A web application may receive a decision that is never rendered because the component fails.

The contract should therefore record destination, payload or content version, intended subject, policy state, send/render attempt, actual delivery or exposure where observable, match and rejection counts, latency, error, retry, cost, and correlation to the decision.

Channel-specific controls belong here as well: locale, accessibility, content approval, expiry, brand rules, contact policy, frequency, and rendering safety. Central decisioning can separate “what to show” from “where to show it,” but channel context still matters. Consistency is valuable only when it does not override permission, suitability, inventory, or fatigue.

Layer 12: Measurement and learning

Measurement closes the architecture.

It joins assignment, decision, delivery or exposure, cost, outcome, and failure under declared time and identity rules. It supports operational monitoring, descriptive analysis, experimentation, model evaluation, and policy improvement—but those are different questions.

The outcome should come from the system authoritative for the business event. The decision system may know that an offer was selected. The channel may know that it was rendered. The order system knows whether a purchase was completed and later refunded. The measurement layer must preserve those distinctions.

Feedback freshness should match the rate at which a decision can safely change. A sub-100-millisecond decision does not create a real-time learning loop if outcomes arrive days later, identity joins are biased, or model updates occur without review. Many systems should learn on a slower governed cadence even when they decide quickly.

Finally, record negative evidence: no eligible action, policy block, fallback, timeout, delivery failure, control assignment, non-response, refund, complaint, and opt-out. A learning system trained only on successful deliveries and conversions sees a distorted world.

The planes that cannot be a final box

Architecture diagrams often place “governance and security” in a small box at the bottom. That presentation implies the customer-data path can be designed first and controlled later. In practice, trust requirements change what may be collected, linked, stored, queried, selected, delivered, retained, and learned from.

Privacy and rights

Privacy is both a policy and an executable workflow.

The European Commission’s summary of GDPR data-processing principles includes lawfulness, fairness and transparency, purpose limitation, data minimisation, storage limitation, accuracy, integrity and confidentiality, and accountability. The UK’s Information Commissioner’s Office explains data protection by design and by default as a lifecycle responsibility supported by appropriate technical and organisational measures.

For an India-relevant design, the Digital Personal Data Protection Act, 2023 makes specified purpose, notice, consent where relied on, withdrawal, processor obligations, erasure, and exceptions architecturally relevant. Applicable commencement, rules, sectoral requirements, processing basis, and facts must be confirmed at the time of use.

Important: This article translates selected principles into architecture questions. It is not legal advice and does not establish that a particular implementation is compliant. Organisations should obtain qualified privacy and legal review for their jurisdictions and use cases.

The technical consequence is that a single consent=true field is inadequate. The system may need purpose, basis, notice/consent evidence where applicable, scope, collection time, source, jurisdiction, policy version, expiry, and withdrawal state. It needs enforcement at collection, identity linking, feature computation, audience evaluation, decisioning, activation, retention, and rights handling.

Rights workflows must map identifiers, source records, profile attributes, audiences, caches, exports, destinations, processors, and derived datasets. They must distinguish access, correction, withdrawal, restriction, and erasure. They must record exceptions instead of silently retaining data. They must also prevent a later source replay from recreating state that should remain suppressed or deleted.

Security

Security crosses both data and control planes. The architecture should map authentication, authorisation, encryption, key and secret management, network isolation, tenant isolation, administrative privilege, supply-chain controls, audit evidence, and incident response to each capability.

The control plane is particularly sensitive. An attacker who changes an identity rule, destination credential, event schema, decision policy, or retention configuration may cause more damage than one who reads a single record. Configuration changes therefore need strong access controls, separation of duties where appropriate, approval, versioning, and rapid rollback.

Governance and metadata

Governance makes the system explainable over time. Each critical schema, transformation, dataset, identity rule, metric, feature, model, audience, policy, journey, destination mapping, and retention schedule needs an owner, version, effective date, approval state, dependencies, and evidence.

OpenLineage defines an interoperable model around dataset, job, and run entities for lineage metadata. That open standard does not cover every customer-experience control-plane object, but it illustrates a valuable principle: lineage should be emitted as systems operate, not reconstructed manually only after an incident. A complete CX lineage view should extend from the source event through transformations, identity and metric logic, decision policy, activation, and outcome.

Reliability and observability

API uptime is not sufficient. A platform can be technically green while customer data is stale, events are quarantined, identities are collapsing incorrectly, decisions are falling back, messages are blocked, or outcomes cannot be joined.

Operational views should include:

collection volume, latency, rejects, and schema violations;
event-backbone throughput, partition health, lag, replay, and dead-letter state;
durable-data freshness, late arrivals, transformation tests, and lineage gaps;
identity merge/split rates, conflict patterns, graph growth, and rebuild status;
profile and feature freshness, time-to-live, and serving errors;
audience evaluation time, size anomalies, exclusions, and staleness;
decision latency, eligibility failures, no-action, fallback, and policy/model versions;
activation match rates, delivery failures, retries, and cost;
consent or purpose blocks and rights-workflow completion; and
assignment-to-exposure and exposure-to-outcome join quality.

Every SLO should specify the user or business consequence of a breach and the safe fallback. “Profile unavailable” may mean show a non-personalised default. “Inventory stale” may mean suppress the offer. “Permission uncertain” should not mean guess.

Content and asset governance

Decisioning does not deliver an abstract score; it often delivers content. The architecture therefore needs stable content identity, version, locale, placement, rights, brand approval, accessibility state, expiry, and fallback. A perfect ranking model can still produce a bad experience if the selected asset is expired, inaccessible, legally restricted, or unsuitable for the surface.

These five planes are not extra products. They are responsibilities that must influence each data-plane action through the control plane.

Where “real time” belongs—and where it does not

“Real time” is one of the least useful unqualified phrases in customer technology. It may refer to event ingestion, audience evaluation, profile update, feature availability, query response, decision execution, channel delivery, or reporting. A platform can be real time in one step and stale in the customer experience.

ClickHouse’s real-time analytics documentation makes a helpful distinction: time to insight includes time to ingest, time to transform and prepare, and time to query. Ciqor extends that reasoning to customer experience:

capture + transport + prepare + retrieve + decide + deliver + log ≤ interaction budget

Even this formula describes response time, not learning time. Feature freshness and outcome-feedback freshness need separate SLOs.

The architecture should use at least three operating paths.

Path	Typical requirement	Appropriate work	Work to keep out of the path
Hot interaction path	Tens to hundreds of milliseconds when the experience genuinely requires it	Request context, bounded cached profile/features, current policy check, eligibility, deterministic rule or bounded model call, fallback, decision logging	Large federated joins, unbounded graph traversal, slow feature recomputation, synchronous fan-out to many systems
Warm operational path	Seconds to minutes	Streaming enrichment, audience updates, triggered orchestration, recent profile changes, operational monitoring	Claims that every destination becomes immediately consistent
Durable analytical path	Minutes to hours or scheduled	Complete history, reconciliation, governed metrics, deep analysis, model training, experiments, retention and rights jobs	Using warehouse completion time as if it were page-response latency

These ranges are illustrative. The correct budget begins with the interaction. A next-page content recommendation, fraud block, call-centre prompt, weekly campaign, and monthly retention analysis do not need the same latency.

Every synchronous dependency spends the interaction budget and creates a failure mode. A low-latency path should precompute or cache stable context, bound remote calls, use timeouts and circuit breakers, preserve a safe default, and log why the fallback occurred. If a decision cannot safely be made without a slow source, the design should question whether the decision belongs in that moment.

Federated data can still enrich a real-time experience. The heavy warehouse computation can run on a scheduled or triggered path, materialise only the bounded result needed operationally, and combine that result with live interaction context. What should generally be avoided is placing an unpredictable, cross-source analytical query directly in the page-response path and then advertising the decision API’s isolated benchmark.

Three flows that test the architecture

A reference architecture becomes useful only when real flows are traced through it. The following examples are intentionally bounded. Their latency figures are illustrative, not platform promises.

Flow 1: Anonymous product view → login → offer → purchase → learning

Decision: Select an eligible offer during a product interaction.
Outcome: Determine whether the treatment produced incremental value, not merely whether a conversion occurred later.
Illustrative decision-service budget: 150 milliseconds at p95, excluding unrelated page rendering.

Sequence diagram tracing an anonymous product view through a qualified event, durable history, bounded context read, governed decision, exposure evidence, identity link, and authoritative purchase outcome. — **Figure 3 — Event-to-decision-to-outcome sequence.** Selection, exposure, and outcome remain distinct. The flow records safe fallbacks, governed identity linking, and authoritative business outcomes as evidence.

An anonymous visitor views a product. The collector sends an event with anonymous and session identifiers, event time, product context, schema version, source, and applicable purpose metadata.
The gateway authenticates the producer, validates the contract, minimises and classifies fields, and accepts, redacts, rejects, or quarantines the event with a reason.
The event backbone distributes the qualified event to a recent-context processor and the durable history path.
The experience requests a decision. The hot path reads current request context and a bounded cached profile or feature view. It does not wait for a large warehouse join.
Permission or purpose, channel, product, inventory, frequency, risk, and other constraints reduce the candidate set.
The decision service ranks eligible items or returns a default/no-action. It records decision_id, catalog and policy versions, rule or model version, chosen item, exclusions, experiment assignment, expiry, latency, and fallback reason where applicable.
The surface renders the item and emits a separate delivery or exposure event. A successful selection is not counted as an exposure.
The visitor signs in. Identity policy may associate permitted prior activity with the authenticated account under a deterministic identifier. The system preserves the anonymous identifier, link provenance, effective time, rule version, and shared-device risk rather than rewriting history as certainty.
The order system emits the authoritative purchase outcome. Refund or cancellation follows as a separate authoritative state change.
Measurement joins assignment, decision, exposure, cost, and outcome under a declared window. Where the question is causal, the analysis uses the planned control or holdout rather than attributing every later purchase to personalisation.
Governed metrics and features update on their appropriate cadence. A rule or model change is versioned, reviewed, deployed, and monitored; raw conversions do not silently rewrite policy.

The flow also needs explicit states for profile unavailable, permission unknown, no eligible offer, decision timeout, delivery failure, duplicate event, late order, identity conflict, and holdout. Those states are not edge cases to hide from the diagram; they define whether the architecture is safe and measurable.

Flow 2: Consent withdrawal and rights propagation

Decision: Stop the relevant processing and execute applicable rights across the data estate while preserving lawful exceptions and evidence.
Outcome: Future disallowed collection or activation is blocked, affected systems are reconciled, and completion or exception status is auditable.

A person withdraws consent or submits a rights request through an authorised interface. The request receives a unique ID, timestamp, verified subject scope, jurisdictional context, and requested action.
The rights service verifies identity to the degree appropriate to the risk and resolves the necessary identifier set without exposing unrelated data.
The policy service distinguishes withdrawal, access, correction, restriction, and erasure. It determines affected purposes, legal bases, data categories, systems, processors, destinations, derived data, and retention exceptions.
The control plane updates active permission or purpose state. Subsequent collection, joining, decisioning, orchestration, and activation can enforce the change without waiting for a nightly deletion job.
An orchestrated workflow issues versioned actions to profile stores, durable datasets, audiences, caches, activation destinations, processors, and relevant feature/model rebuild processes.
Federated sources and persisted operational results are handled separately. Leaving underlying data in a warehouse does not remove obligations for audiences, selected attributes, exports, or operational metadata stored elsewhere.
Each system reports completed, not found, partially completed, or exception status with evidence. A required retention exception records its authority, scope, access restriction, and review or expiry.
Reconciliation verifies destination acknowledgements and checks that later replay or ingestion cannot recreate disallowed state from an untreated source.
The system produces an auditable completion record while applying minimisation and retention to the rights record itself.

Important failure states include ambiguous identity, processor timeout, destination without a rights API, immutable-backup boundaries, conflicting retention duties, partial completion, and re-ingestion. The architecture must reveal these conditions instead of turning “delete” into a green button with unknown reach.

Flow 3: Federated warehouse enrichment + recent behaviour

Decision: Combine valuable historical warehouse context with recent behaviour without copying all history into an operational platform or placing a heavy warehouse query in the page-response path.
Outcome: A bounded, fresh, governed enrichment contributes to an interaction-time decision and remains traceable to its source definition.

Data owners define a governed warehouse model for customer value, eligibility, or another enrichment. The contract includes entity key, metric definition, source tables, effective time, purpose, privacy class, and freshness.
A federated process queries the warehouse on a declared schedule or trigger. Source access, compute, lineage, evaluation time, cost, and failure remain observable.
The operational platform persists only the result required for activation—for example, an audience membership and evaluation timestamp or a small set of attributes—not the complete historical transaction table.
Recent behavioural signals arrive through the hot or warm path and update bounded context.
At interaction time, decisioning combines the operational enrichment, live context, current policy, constraints, and fallback. It does not synchronously execute the heavy federated computation.
The decision, exposure, and outcome return to durable history with lineage to the warehouse model, evaluation version, and source effective time.
Freshness monitoring expires, suppresses, or safely degrades the enrichment when its contract is breached.

This flow should be tested for warehouse unavailability, throttling, stale membership, key mismatch, permission change after audience evaluation, materialisation failure, and a source metric-definition change. Federation changes the movement pattern; it does not eliminate semantics, reliability, privacy, or operational ownership.

Build, buy, consolidate, or compose?

There is no universally correct answer. Consolidation can reduce interfaces, duplicated configuration, latency, and operational burden. Composition can preserve authoritative data ownership, provide specialised capabilities, and reduce dependence on one product’s model. Building can create genuine differentiation—or an expensive internal platform the organisation is not equipped to operate.

The decision should follow the use case and capability contracts, not a slogan such as “single suite,” “best of breed,” “warehouse native,” or “composable.”

Ask these questions before comparing products:

What is authoritative? Which system owns each critical field, event, permission, content item, decision record, and outcome?
What must be local to the interaction path? Which context, constraints, and decision functions must respond synchronously, and which can be computed earlier?
What can remain federated? Which underlying records can stay in a warehouse or operational source, and which bounded results must be materialised for serving?
What are the contracts? Are schemas, identities, metrics, features, decisions, exposures, outcomes, and rights actions portable and versioned?
What are the SLOs? Are latency, freshness, availability, recovery, and cost defined end to end, including stale and partial-failure behaviour?
How is trust enforced? Can purpose, permission, minimisation, access, retention, and rights propagate across every affected processor and destination?
Can the result be measured? Do assignment, decision, exposure, cost, outcome, and failure share stable correlation without fragile inference?
Can the team operate it? Who owns every interface, alert, runbook, replay, model change, connector failure, and vendor escalation?
What is the exit path? Which data, definitions, histories, policies, identifiers, and operational contracts must remain portable if a component changes?

The goal is not maximum composability. It is the smallest architecture that satisfies the decision’s latency, data, control, privacy, reliability, measurement, and change requirements. Every additional component must justify the interface and incident load it creates. Every consolidated product must still expose enough evidence to govern its internal boundaries.

Capability and ownership worksheet

For each of the 12 layers, record:

Capability	Business and technical owner	Authoritative source	Runtime system	Input and output contract	Latency and freshness SLO	Identity and purpose basis	Failure and fallback	Lineage and evidence date
Example: interaction decision	CX owner / decisioning team	Product, inventory, permission, and profile sources by attribute	Decision service	Context request → versioned decision/fallback	150 ms p95; inventory < 30 s; profile < 5 min	Authenticated/anonymous namespace; permitted purpose	Default content on timeout; suppress when permission unknown	Decision, policy, model, exposure, and outcome IDs

If a row cannot be completed, the architecture contains an unowned assumption.

Twelve anti-patterns that reveal a weak architecture

Anti-pattern	What it hides	Better question
“The CDP is the architecture.”	Collection, records, semantics, decisioning, delivery, measurement, and rights outside the product	Which capabilities and interfaces exist beyond the CDP?
“The profile is the single source of truth.”	Attribute-level authority, effective time, conflict, and purpose	Which system is authoritative for this value, and when?
“The platform is real time.”	Different ingestion, feature, audience, decision, delivery, and feedback latencies	What is the p95 end-to-end budget and stale-data behaviour for this use case?
The hot path calls every source.	Cumulative latency and correlated failure	What can be precomputed, cached, bounded, or removed?
Audience membership is the decision.	Current context, constraints, capacity, ranking, and no-action	What still must be evaluated at interaction time?
A selected treatment counts as exposure.	Rendering, sending, match, and delivery failure	Which event proves the experience was actually delivered?
A conversion proves personalisation worked.	Selection bias, base rates, channel overlap, and counterfactual outcome	Where is the control, holdout, or other identification strategy?
“Exactly once” describes the whole journey.	External side effects and transaction boundaries	What is transactional, what is idempotent, and what is reconciled?
“Zero copy” means zero governance.	Source access/compute, metadata, caches, derived audiences, and operational results	What is queried, persisted, charged, secured, retained, and deleted?
Identity links only move in one direction.	False merges, shared devices, disputed identity, and rebuild needs	Can a wrong link be detected, separated, rebuilt, or compensated?
Consent exists in one profile field.	Purpose-specific enforcement across collection, joining, activation, and processors	Where is policy evaluated, propagated, blocked, and audited?
An AI layer sits above inconsistent metrics.	Semantic conflict, excess access, untraceable answers, and automated policy drift	Which definitions, permissions, lineage, evidence, and evaluation constrain the agent?

These anti-patterns share one flaw: they replace a contract with a label. Strong architecture reverses that move. It specifies what the system must do, what evidence it must produce, and how it behaves when the happy path fails.

A practical evaluation checklist

Use the following questions to test an existing or proposed architecture. Score each Yes, Partial, No, or Not applicable, and require an owner plus evidence—not an opinion.

Use case, contracts, and data

Is the decision, intended outcome, non-goal, eligible action set, and fallback explicit?
Does every critical event have a versioned definition, owner, producer, time semantics, identity fields, purpose context, and quality tests?
Are authoritative systems defined per field and event rather than assigned wholesale to a profile?
Can durable history and derived views be replayed or rebuilt with provenance when logic changes?

Identity, privacy, and security

Are identifier namespaces, match rules, precedence, confidence, effective time, shared-device behaviour, and recovery documented?
Are profile attributes and features labelled with source, derivation, freshness, privacy class, purpose, and time-to-live?
Are applicable purpose or authority checks enforced at collection, joining, decisioning, activation, retention, and rights handling?
Do access, correction, withdrawal, deletion, and retention workflows cover processors, destinations, caches, audiences, and derived data?

Latency, decisions, and delivery

Is latency budgeted across capture, transport, preparation, retrieval, decision, delivery, and logging?
Are data, feature, audience, and feedback freshness separated from API response time?
Does every decision record candidates/exclusions, selection or no-action, policy/model version, experiment assignment, and fallback?
Is actual delivery or exposure recorded separately from selection, with error, retry, match, and cost evidence?

Measurement, governance, and operations

Can assignment, decision, exposure, outcome, cost, and failure be correlated under declared identity and time rules?
Are metrics and dimensions centrally defined, versioned, tested, and reusable by analytics and decisioning?
Do lineage and change records include identity rules, features, models, decision policies, journeys, and destinations—not only datasets?
Do operational views reveal freshness, rejects, lag, identity anomalies, policy blocks, fallbacks, delivery failures, join quality, and cost?
Does every component and interface have an owner, SLO, fallback, runbook, recovery test, review date, and portability plan?

An architecture that scores well should be able to demonstrate the evidence in a test environment. “The product supports it” is not equivalent to “our implementation is configured, monitored, and owned.”

What this model says—and does not say—about CXOS

CXOS is a future-looking Ciqor research direction, not a finished product described by this article. The reference architecture is vendor-neutral and stands on its own. Ciqor may use it to frame future research into governed signal-to-outcome systems, but this article makes no claim about current CXOS availability, implementation, performance, customers, integrations, or roadmap.

Any future product claim should be evaluated against the same standard applied here: a documented contract, a defined boundary, reproducible evidence, explicit failure behaviour, and independent technical and privacy review.

Draw the loop, then test the seams

A modern customer experience platform is not the profile in the centre of a diagram. It is the governed loop that observes a signal, qualifies it, remembers the right history, understands identity and context, chooses an eligible action, delivers it safely, and learns from what actually happened.

The 12 layers give that loop a durable vocabulary. The three operating paths prevent every workload from being forced into a misleading “real-time” claim. The control plane makes runtime behaviour reviewable. The cross-cutting planes ensure that privacy, security, governance, reliability, and content responsibility shape the system rather than trail behind it.

To use the model, choose one high-value decision. Trace it from source to outcome. At every seam, ask:

What is the contract?
Who owns it?
What is authoritative?
How fresh and fast must it be?
Which identity and purpose rules apply?
What proves selection, delivery, and outcome?
What happens when this step fails?
How can the system be corrected, replayed, reconciled, or changed?

If the architecture cannot answer those questions, adding another platform box will not make it complete.

The next article in this series will turn this reference architecture into a buyer’s capability map: The Customer Experience Platform Capability Map: 12 Layers Buyers Should Separate.

Editorial disclosure and review status

This draft requires review by two technical practitioners from different platform traditions and a qualified privacy reviewer before publication. Product features, availability, legal context, and source links should be rechecked on the publication date.