Is this a customer data platform? Bounded customer foundation, not a full CDP

Not a customer data platform

People ask this as: open source customer data platform with identity resolution and segmentation

Accordo is a CRM framework with bounded customer imports, deterministic matching, logical canonical identity and a consolidated profile. It is not a full customer data platform: no streaming ingestion, audiences or destination activation. This category comparison names no CDP vendor and claims no tested connector.

Where this stops

Read this before the rest of the page. Every line below is a thing this does not do.

Every fact about another project on this page is single-sourced to docs/strategy/COMPETITOR_MAP.md and dated 2026-08-04. Nothing from another project was installed, configured or run, and there is no network access here to re-verify any of it.

  • Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included (L-04). No CSV importer, streaming ingestion or prebuilt CDP connector ships (L-05, L-06).
  • Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search (L-06).
  • No segmentation engine: no dynamic audiences, no frozen snapshots, no suppression sets, no sync to a destination.
  • No complete consent, retention, subject export/erasure or field-level privacy policy ships. Authorization and per-instance tenancy are separate implemented framework controls (L-01, L-09).
  • Real customer data does not belong in this yet — there is no export and no erasure path, so a subject request cannot be serviced (L-09).
  • The one provider call that exists runs against a checked-in fixture. No external data source is wired and no credential ships.
  • This page names no CDP product, because the only permitted competitor source carries no CDP research.

No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim. Every claim and every limitation is on one page.

Where a customer data platform wins

A CDP serves broad ingestion, profile and audience needs across source systems. Accordo implements a narrower customer foundation for CRM applications, not that complete platform. This is a category boundary, not a vendor evaluation.

Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search (L-06). Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included (L-04). No email/calendar sync or production CDP connector ships (L-05).

Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search (L-06). Matching runs on imports, not on arbitrary manual record entry. Ambiguity is left unresolved; physical source records remain intact.

No marketing audiences, snapshots, suppression or destination sync ship. Consent, complete subject export/erasure and field-level privacy policies remain gaps; framework authorization does not supply those domain operations (L-01, L-09).

Where this is different

What does exist is the opposite shape — per-record decision history rather than a population view. A lead is captured, enriched, scored, routed, qualified and converted through explicit actions, each one atomic and audited (C-06); a score carries the fingerprint of the model version that produced it, with one contribution row per rule, so a number from last quarter can still be accounted for (C-07); every mutation leaves an audit event and a step-level trace (C-16). The question that answers is why this one record got this outcome and under which policy version, a year later. The question it cannot answer is how many people match a rule across your systems — which is the question a CDP is bought for.

Customer Data Foundation imports bounded JSON rows and retains provenance with receipts (L-06). Lead enrichment remains a separate fixture-provider action (C-06). Neither is a streaming CDP pipeline or a prebuilt connector.

How to choose

For broad cross-system ingestion, identity graphs, audiences and activation, choose a CDP. Accordo offers a bounded customer foundation for a custom CRM process; it does not implement that complete platform (L-06).

If the sentence is our commercial process needs stages, quotes, approvals and an audit trail, and one record's outcome has to be explainable afterwards, that is the narrow case this exists for — with the standing caveats that there is no authentication and no place for real customer data yet (L-01, L-09).

A CDP and this framework are distinct layers. Bounded JSON import can receive mapped customer rows, but no prebuilt connector ships; the bridge remains application engineering (L-05, L-06).

If what you actually need is marketing execution — audiences, campaigns, journeys, attribution — the answer is the same and is recorded rather than implied: every one of those jobs is marked not supported in the job matrix, so you can confirm the refusal instead of taking it on trust.

What this comparison does not cover

No CDP product is named, ranked, priced or evaluated on this page. docs/strategy/COMPETITOR_MAP.md — the only source this cluster may use for facts about other software, researched on August 4, 2026 — covers CRM and CRM-adjacent projects and carries no CDP research whatsoever. A specific claim about a specific vendor would therefore have been invented, and inventing one would undo the credibility every other page here is built on.

The category description in the first section is definitional: the three jobs a CDP is bought to do. It is not a statement about how any particular implementation does them, how well, or at what price.

Nothing about data warehouses, reverse ETL, event streaming, identity graphs or consent management platforms, for the same reason: no researched source here carries them.

No roadmap. The absences listed above are current state, and recording them is not a commitment that any of them will be filled. This entry carries the research file's date rather than the date it was written, and must be re-read when that file is refreshed.

Common questions

Can this ingest events from my warehouse or website?

No, Accordo is not a full CDP. Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search (L-06). Audiences, segmentation and destination activation remain outside the implemented foundation.

How do the two work together?

Split the job: the CDP resolves identities and builds segments, and the agent-built CRM owns the governed process — quotes, approvals, orders, contracts, delivery, service — as code in your repository. Neither replaces the other, and this page states the seam rather than blurring it.

The evidence this page rests on

Claims and limitations are printed from site/claims.json word for word. Job statuses come from docs/benchmarks/jobs.json; a job with no page of its own is listed with its status rather than linked.

Claims

  • C-06 A lead is captured, scored, routed, qualified and converted into Company, Contact and Opportunity through explicit actions, each one atomic and audited.

    LimitEnrichment runs against a fixture provider — no real external data source is wired. The Lead model is the starter's, not a built-in core module.

  • C-07 Scoring is explainable and versioned: every score carries the fingerprint of the model version that produced it, so a number from last quarter can still be accounted for.

    LimitDeterministic weighted rules, not a machine-learning model. Nothing trains, fits or backtests.

  • C-16 Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it.

    LimitAudit records what the process did under an asserted actor. It is not a tamper-evident or externally attestable log, and it is not a compliance control.

Limitations

  • L-01 No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.
  • L-04 Timers exist; a service that runs them for you does not. Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included.
  • L-05 No email, calendar or marketing integrations. An in-memory notification provider contract exists. MK1 marketing records supplied funnel observations and human-reviewed proposals only; it has no sending, publishing or spending path.
  • L-06 Bounded customer imports and logical identity; incomplete data operations. Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search.
  • L-09 Personal-data readiness requires deployment work beyond the foundation. Customer Data Foundation supplies bounded import and identity governance, not complete personal-data operations. Authentication must be supplied by the deployment, and complete subject export and erasure remain absent; the framework alone does not establish compliance or suitability for real customer data. Lead scoring remains deterministic, versioned and explainable.

Jobs it covers