Business Requirements Document
CXOS — Business Requirements Document
The business case and requirements driving the six-stage CXOS architecture — what the business needs each stage to deliver, who it serves, and how success is measured. Companion document to the technical reference; read alongside the six module pages for the "why" behind each "how".
📄 Document Control
| Document | CXOS Business Requirements Document (BRD) |
|---|---|
| Version | 1.0 |
| Status | Approved for Stages 1–4 (Data Sources, Ingestion Layer, Transformation & Processing, Unified Data Foundation); Draft for Stages 5–6 (Intelligence & Services, Destinations & Activation) |
| Owner | Platform & Product Team |
| Last Updated | 2026-08-02 |
📚 Purpose & Business Context
Customer interactions are currently spread across a website, a mobile app, a CRM, a support desk, a call center, and a dozen other SaaS tools — each holding a different sliver of the same customer relationship. Marketing sees one version of the customer, support sees another, and no team has a complete, real-time picture in time to act on it. This fragmentation shows up as duplicated outreach, inconsistent personalization, slow compliance response, and engineering time spent building one-off integrations between systems that already exist.
This document defines the business requirements for CXOS (Customer Experience Operating System) — a single platform that collects every customer interaction once, resolves it to one unified profile, and makes that profile usable everywhere it needs to show up, from a personalized email to a support agent's screen to a machine learning model. It is the business counterpart to the technical architecture documented across the six module pages on this site.
🎯 Business Objectives
- Unify customer data from every channel and business system into one real-time, governed profile
- Reduce the time it takes to onboard a new data source or activation destination from a multi-week engineering project to a configuration change
- Enable real-time personalization and activation without each team building its own pipeline
- Make compliance (GDPR, CCPA, DPDP) a built-in property of the platform, not a bolt-on process
- Give business users self-service access to unified customer data without an engineering ticket
- Provide a single, auditable source of truth that Finance, Legal, and Compliance can all rely on
📌 Scope
In Scope
- Ingestion from all customer touchpoints, core business systems, and file/API-based sources (Stage 1)
- A shared, versioned ingestion contract and edge processing for every integration (Stage 2)
- Real-time and batch transformation, identity resolution, and schema governance (Stage 3)
- A governed, open-format data lakehouse with full lineage, classification, and access control (Stage 4)
- Self-service analytics, AI-driven insight, and operational monitoring (Stage 5)
- Real-time and batch activation to marketing, ad, and CRM/support platforms (Stage 6)
Out of Scope
- Replacing existing systems of record (Salesforce, Shopify, Zendesk, HubSpot) — CXOS unifies their data, it does not replace them
- Building new customer-facing applications (the Angular storefront, mobile apps) — CXOS instruments existing applications, it does not build them
- Multi-cloud support — Azure is the approved cloud provider for this program
- Data science model development beyond the reference AI & Insights capabilities — CXOS provides the platform, not the model roadmap
🤝 Stakeholders
| Stakeholder | Interest |
|---|---|
| Marketing & Lifecycle Teams | Unified profile for personalization, campaign targeting, and consent-safe activation |
| Customer Support & Success | Full customer context (orders, tickets, usage) at the point of an interaction |
| Sales & RevOps | Accurate account/opportunity data blended with product-usage signals |
| Finance & Billing | Reliable revenue and subscription data tied to the customer record |
| Legal & Compliance | Provable consent enforcement, data classification, and audit trails |
| Data Engineering & Platform Engineering | A maintainable, governed platform instead of N bespoke pipelines |
| Data Science / ML Engineering | Trustworthy, point-in-time-correct data for model training and inference |
👤 BR-1 · Data Sources
| ID | Requirement | Priority | Acceptance Criteria |
|---|---|---|---|
| BR-1.1 | Capture customer interactions across every touchpoint (web, mobile, IoT, kiosk, chat/voice/bots, email/SMS, call center, social) without measurable gaps. | Must | ≥99.5% of instrumented touchpoint events are captured and visible in the unified profile within the defined SLA. |
| BR-1.2 | Ingest core business-system data (CRM, Commerce, Support, Marketing, ERP/Billing) to enrich the unified customer record. | Must | All five business systems are connected and reconciled against source-system record counts within 0.1% variance. |
| BR-1.3 | Support onboarding a new file- or API-based data source without a bespoke engineering project for common integration patterns. | Should | A new pre-built-connector-eligible source can be enabled via configuration in under 1 business day. |
Microservices
Generic Subdomain — reusable integration adapters. A connector has no bespoke business rules of its own (just source→contract translation), so DDD treats it as Infrastructure-layer only — one deployable service each, not a full Domain/Application/Infrastructure/Api split.
| Microservice | Namespace | C/Q | Interacts With |
|---|---|---|---|
| Salesforce Connector | Cxos.Connectors.Salesforce |
Command | Publishes to Cxos.Ingestion.Api via Cxos.Ingestion.Client · receives Reverse ETL write-back calls from Cxos.Activation.Api |
| Shopify Connector | Cxos.Connectors.Shopify |
Command | Publishes to Cxos.Ingestion.Api via Cxos.Ingestion.Client |
| Zendesk Connector | Cxos.Connectors.Zendesk |
Command | Publishes to Cxos.Ingestion.Api · receives Reverse ETL write-back calls from Cxos.Activation.Api |
| HubSpot Connector | Cxos.Connectors.HubSpot |
Command | Publishes to Cxos.Ingestion.Api · receives Reverse ETL write-back calls from Cxos.Activation.Api |
| ERP / Billing Connector | Cxos.Connectors.ErpBilling |
Command | Publishes to Cxos.Ingestion.Api · payment-failure webhooks feed Cxos.Activation.Api's dunning workflows downstream |
| File Ingestion Connector | Cxos.Connectors.Files |
Command | Publishes batches to Cxos.Ingestion.Api from an Azure Blob Storage landing zone |
| Database CDC Connector | Cxos.Connectors.Cdc |
Command | Publishes change events to Cxos.Ingestion.Api via Azure Event Hubs |
| Generic Connector Framework | Cxos.Connectors.Generic |
Command | Publishes to Cxos.Ingestion.Api; instantiated per long-tail source via configuration, not a new codebase |
🔌 BR-2 · Ingestion Layer
| ID | Requirement | Priority | Acceptance Criteria |
|---|---|---|---|
| BR-2.1 | Every client and server integration must speak one versioned event contract so downstream teams never encounter conflicting schemas for the same event type. | Must | 100% of production event types are registered in the Event Schema & Registry with an owning team. |
| BR-2.2 | No event may be lost due to a downstream outage or traffic spike. | Must | Zero data-loss incidents attributable to ingestion capacity over a 12-month rolling window. |
| BR-2.3 | Consent must be evaluated and enforced before any event is used for a regulated purpose (marketing, personalization). | Must | 100% of consent-gated events carry a valid consent basis; verified in a quarterly audit. |
Microservices
Supporting Subdomain — Ingestion (bounded context, DDD-layered: Domain / Application / Infrastructure / Api)
| Layer | Namespace | C/Q | Interacts With |
|---|---|---|---|
| Domain | Cxos.Ingestion.Domain |
— | Defines the versioned event contract (Event, EventSchema, ConsentBasis entities) published as the Cxos.Ingestion.Client NuGet package that every Cxos.Connectors.* service and SDK depends on |
| Application | Cxos.Ingestion.Application |
Command | Orchestrates Event Collection → Validation → Enrichment → Consent Enforcement → Queue & Retry; validates schema compatibility via Cxos.Processing.SchemaGovernance.Api |
| Infrastructure | Cxos.Ingestion.Infrastructure |
Command | Azure API Management binding · Azure Event Hubs publisher · Azure Cache for Redis (geo/device enrichment lookups + idempotency/dedup keys) · Azure Key Vault. Deliberately owns no persistent database of its own — ingestion is stateless pass-through, with durable state living in Event Hubs and downstream stores |
| Api | Cxos.Ingestion.Api |
Command | Deployed entry point called by every Cxos.Connectors.* service and client SDK · publishes accepted events to Azure Event Hubs, consumed by Cxos.Processing.Infrastructure |
⚡ BR-3 · Transformation & Processing
| ID | Requirement | Priority | Acceptance Criteria |
|---|---|---|---|
| BR-3.1 | Duplicate or out-of-order events must not distort business-critical metrics (revenue, active users, conversion). | Must | Reconciliation against source-system totals shows <0.1% variance attributable to dedup/ordering defects. |
| BR-3.2 | A customer's activity across every device, session, and channel must resolve to one identity. | Must | ≥95% of logged-in-session events are correctly stitched to the known customer profile. |
| BR-3.3 | Business-facing metric and schema definitions must be reviewed, versioned, and change-controlled like source code. | Should | 100% of schema/metric changes have an associated pull request and reviewer sign-off. |
Microservices
Supporting Subdomain — Event Processing (bounded context, DDD-layered)
| Layer | Namespace | C/Q | Interacts With |
|---|---|---|---|
| Domain | Cxos.Processing.Domain |
— | Entities/rules for deduplication, identity stitching, sessionization, and rollup/aggregation definitions |
| Application | Cxos.Processing.Application |
Command | Orchestrates the Stream Worker (real-time) and Batch Worker (dbt-driven) use cases; validates event/table compatibility via Cxos.Processing.SchemaGovernance.Api |
| Infrastructure | Cxos.Processing.Infrastructure |
Command | Azure Event Hubs consumer · dbt CLI invocation (Azure Container Apps Jobs) · Azure Data Lake Storage Gen2 (Iceberg) writer · Azure Cosmos DB Table API for stream-consumer checkpoint/offset state (fast key-value, not a relational fit) |
| Api | Cxos.Processing.Api |
Query | Exposes job status/backfill triggers to Cxos.Operations.Api; writes curated/marts tables consumed by Cxos.Foundation.Api and every Cxos.Intelligence.* service |
Microservices — Schema Governance
Supporting Subdomain — Schema Governance (bounded context, DDD-layered)
| Layer | Namespace | C/Q | Interacts With |
|---|---|---|---|
| Domain | Cxos.Processing.SchemaGovernance.Domain |
— | Compatibility rules, classification requirements, and versioning policy for every event/table schema |
| Application | Cxos.Processing.SchemaGovernance.Application |
Both | Validates schema-change requests submitted through Cxos.Operations.Api's Workflow Engine; approved changes propagate to Cxos.Foundation.Domain's classification tags |
| Infrastructure | Cxos.Processing.SchemaGovernance.Infrastructure |
Both | Azure Database for PostgreSQL — schema versions, compatibility rules, and owning-team relationships are genuinely relational (foreign keys, ACID), unlike the event/table data itself |
| Api | Cxos.Processing.SchemaGovernance.Api |
Query | Called by Cxos.Ingestion.Application (event validation) and Cxos.Processing.Application (table compatibility checks) on every write |
🗃 BR-4 · Unified Data Foundation
| ID | Requirement | Priority | Acceptance Criteria |
|---|---|---|---|
| BR-4.1 | Customer and business data must be stored once, in an open format, accessible to any approved analytics engine without duplication. | Must | No team maintains an unsanctioned "shadow copy" of customer data outside the lakehouse. |
| BR-4.2 | Every field must be classified and access-controlled sufficiently to pass a compliance audit (GDPR, CCPA, DPDP, SOC 2). | Must | Zero critical findings in the annual data-governance audit. |
| BR-4.3 | The organization must be able to reconstruct the state of any customer record as of a past date, for dispute resolution and regulatory response. | Must | A historical "as of" query returns an auditable answer within 1 business day of a request. |
Microservices
Supporting Subdomain — Data Foundation & Governance (bounded context, DDD-layered)
| Layer | Namespace | C/Q | Interacts With |
|---|---|---|---|
| Domain | Cxos.Foundation.Domain |
— | Entities: LakehouseTable, ClassificationTag, RetentionPolicy, AccessPolicy, ConsentBasis (mirrored from Ingestion) |
| Application | Cxos.Foundation.Application |
Both | Orchestrates catalog registration, lineage capture, classification propagation, policy evaluation, and Lifecycle Management actions |
| Infrastructure | Cxos.Foundation.Infrastructure |
Command | Azure Data Lake Storage Gen2 (Iceberg tables, the lakehouse itself) · Azure Purview (catalog/lineage/policy metadata) · Azure Database for PostgreSQL (CXOS-owned retention-policy definitions and deletion-request tracking — relational, needs joins and audit trail, doesn't belong in Purview) · Azure Data Lake Storage Gen2 write-once container (Audit Logs) · Azure AD / ADFS (role source) · Azure Key Vault |
| Api | Cxos.Foundation.Api |
Query | Serves Catalog/Lineage/Dictionary/Policy lookups to every Cxos.Intelligence.* service and Cxos.Activation.Api; receives table registrations from Cxos.Processing.Api |
🧠 BR-5 · Intelligence & Services
| ID | Requirement | Priority | Acceptance Criteria |
|---|---|---|---|
| BR-5.1 | Business users (analysts, marketers) must be able to query unified customer data without submitting an engineering ticket. | Should | ≥80% of ad hoc data requests are self-served within 2 quarters of general availability. |
| BR-5.2 | The platform must support predictive use cases — churn risk, propensity to convert, anomaly detection — using the unified profile. | Should | At least 2 predictive models are in production use by business teams within the first year. |
| BR-5.3 | Operational issues (data quality, pipeline failures, billing/usage anomalies) must be visible to the owning team without manual log inspection. | Must | Mean time to detect a data-quality regression is under 30 minutes. |
Microservices — Customer Profile
Core Domain — Customer Profile (bounded context, DDD-layered). This is the platform's differentiating capability, so unlike the Generic Subdomain connectors it gets the full layered treatment.
| Layer | Namespace | C/Q | Interacts With |
|---|---|---|---|
| Domain | Cxos.Profile.Domain |
— | Entities: CustomerProfile, IdentityGraph, Relationship, ConsentState |
| Application | Cxos.Profile.Application |
Command | Orchestrates profile assembly from Cxos.Foundation.Api's curated zone and identity-resolution graph traversal |
| Infrastructure | Cxos.Profile.Infrastructure |
Both | Azure Cosmos DB (Core/SQL API) for the profile document store — per-customer attributes vary, so a flexible-schema document fits better than a relational table · Azure Cosmos DB (Gremlin API) for the Identity Graph specifically — multi-hop identifier resolution is a graph-traversal problem, not a document or relational one · Azure Cache for Redis in front of both for hot-key reads |
| Api | Cxos.Profile.Api |
Query | Serves reads to Cxos.Activation.Api and every internal consumer; receives propensity/anomaly writes from Cxos.Intelligence.Api |
Microservices — Analytics & AI Insights
Supporting Subdomain — Analytics & AI Insights (bounded context, DDD-layered)
| Layer | Namespace | C/Q | Interacts With |
|---|---|---|---|
| Domain | Cxos.Intelligence.Domain |
— | Entities: Metric, Segment, PropensityScore, AnomalyRecord |
| Application | Cxos.Intelligence.Application |
Both | Orchestrates the Semantic Layer, Query Optimizer, and model training/scoring workflows; reads metadata from Cxos.Foundation.Api |
| Infrastructure | Cxos.Intelligence.Infrastructure |
Both | DataFusion engine (reads Iceberg tables directly — no separate copy) · Azure Database for PostgreSQL for the Semantic Layer's own metric/dimension definitions (genuinely relational: versioned, joined, reviewed like schema) · Azure Cache for Redis (query-result cache) · Azure Machine Learning (model registry, managed) · Azure OpenAI Service · Azure Data Explorer (Kusto) for anomaly-scoring time series — purpose-built for high-cardinality time-series, a poor fit for a relational or document store |
| Api | Cxos.Intelligence.Api |
Both | Serves query/analytics reads to BI tools and Cxos.Activation.Api; writes propensity/anomaly results to Cxos.Profile.Api and Cxos.Operations.Api |
Microservices — Operational Services
Supporting Subdomain — Operational Services (bounded context, DDD-layered)
| Layer | Namespace | C/Q | Interacts With |
|---|---|---|---|
| Domain | Cxos.Operations.Domain |
— | Entities: Workflow, Alert, QualityCheck, UsageRecord |
| Application | Cxos.Operations.Application |
Both | Orchestrates the Workflow Engine state machine, alert routing, quality scorecards, and usage metering |
| Infrastructure | Cxos.Operations.Infrastructure |
Both | Azure Database for PostgreSQL for the Workflow Engine's state machine and the Usage & Billing ledger (both need ACID + relational joins across tenant/period) · Azure Cosmos DB (Table API) for Alerts & Notifications history and dedup-window state (high write throughput, simple key lookup, TTL) · Azure Data Explorer (Kusto) for Data Quality Monitoring's scorecards (time-series, not relational) · Azure Service Bus · SendGrid / Slack / PagerDuty delivery adapters |
| Api | Cxos.Operations.Api |
Both | Receives quality/anomaly signals from every other Cxos.*.Application layer; serves status/usage queries to Finance and Platform Engineering |
📤 BR-6 · Destinations & Activation
| ID | Requirement | Priority | Acceptance Criteria |
|---|---|---|---|
| BR-6.1 | Insights and audiences must reach marketing, ad, and CRM platforms without a manual export/import step. | Must | 100% of supported destinations sync via an automated connector, not a manual file handoff. |
| BR-6.2 | Activation must occur within a business-relevant window: real-time for in-session personalization, near-real-time/batch for campaign-style activation. | Must | Real-time activation triggers fire within 5 minutes of the qualifying event; batch syncs complete within their scheduled window. |
| BR-6.3 | Downstream systems (CRM, Support, Marketing) must receive CXOS-computed insight (propensity, LTV) back into their native workflow via Reverse ETL. | Should | Reverse ETL sync to at least 3 named destination systems is live within the first year. |
Microservices — Activation
Core Domain — Activation (bounded context, DDD-layered). The second of the platform's two differentiating capabilities, alongside Customer Profile.
| Layer | Namespace | C/Q | Interacts With |
|---|---|---|---|
| Domain | Cxos.Activation.Domain |
— | Entities: ActivationTrigger, Destination, DispatchPolicy |
| Application | Cxos.Activation.Application |
Command | Orchestrates consent/entitlement checks against Cxos.Profile.Api and segment/propensity resolution against Cxos.Intelligence.Api before every dispatch decision |
| Infrastructure | Cxos.Activation.Infrastructure |
Command | Azure Service Bus publisher · Azure API Management · Azure Cosmos DB (Core/SQL API) for dispatch/delivery-status records (high write throughput, TTL-expired, no relational joins needed) · Azure Cache for Redis for frequency-cap counters and consent-check cache |
| Api | Cxos.Activation.Api |
Command | Entry point for every internal trigger; dispatches to every Cxos.Connectors.* outbound service via Azure Service Bus |
Microservices — Outbound Delivery Connectors
Generic Subdomain — reusable outbound adapters, same reasoning as BR-1's inbound connectors (Infrastructure-layer only, no bespoke Domain/Application split).
| Microservice | Namespace | C/Q | Interacts With |
|---|---|---|---|
| Email Connector | Cxos.Connectors.SendGrid |
Command | Receives dispatch calls from Cxos.Activation.Api · delivers via SendGrid |
| SMS / Push Connector | Cxos.Connectors.Twilio |
Command | Receives dispatch calls from Cxos.Activation.Api · delivers via Twilio / Firebase Cloud Messaging |
| Ad Platform Connector | Cxos.Connectors.AdPlatforms |
Command | Receives audience syncs from Cxos.Activation.Api · delivers to Google Ads Customer Match / Meta Conversions API |
| Batch Export Connector | Cxos.Connectors.BatchExport |
Command | Receives scheduled export jobs from Cxos.Activation.Api · delivers to partner S3/GCS/Blob, SFTP, Snowflake, or Databricks |
| Reverse ETL (CRM / Support / Marketing) | Cxos.Connectors.Salesforce / .Zendesk / .HubSpot |
Command | Same bidirectional services listed under BR-1 · receive write-back dispatch calls from Cxos.Activation.Api to sync insight into Salesforce, Zendesk, and HubSpot |
⚠️ Non-Functional Requirements
- Availability: 99.9% platform availability for real-time ingestion and activation paths, measured monthly
- Compliance: GDPR, CCPA, and India's DPDP Act compliance from day one; SOC 2 Type II readiness within 18 months
- Data Residency: support region-specific data residency requirements (EU, India) as new markets are onboarded
- Scalability: support multi-tenant, multi-brand usage without cross-tenant data leakage
- Cost Governance: storage and compute cost per unified customer profile tracked and reported to Finance quarterly
- Support Model: Platform Engineering provides tier-1/2 support with a documented runbook for every production incident class
📋 Assumptions & Constraints
- Azure is the approved cloud provider for this program; there is no multi-cloud requirement in this phase
- Existing business systems (Salesforce, Shopify, Zendesk, HubSpot) remain systems of record for their domain — CXOS unifies their data, it does not replace them
- Delivery was phased: Data Sources, Ingestion Layer, Transformation & Processing, and Unified Data Foundation shipped first, followed by Intelligence & Services and Destinations & Activation — all six stages are now specified end to end
- Ongoing budget and timeline for implementation against real infrastructure remain subject to each phase's success criteria being met
📈 Success Metrics
| Metric | Target |
|---|---|
| Customer touchpoints unified into a single profile | 100% of in-scope touchpoints within 12 months |
| Time to onboard a new data source | <5 business days for a pre-built connector |
| Reduction in duplicate/conflicting customer records | >90% reduction vs. pre-CXOS baseline |
| Real-time activation latency | <5 minutes, event to activation |
| Compliance audit pass rate | Zero critical findings |
| Self-service analytics adoption | 80% of ad hoc requests self-served |