Open source. Not deployable to production. This page states what the tests prove and what is missing — nothing else.

What is a customer hub?

Customer hub, defined

People ask this as: what is a customer hub, single view of the customer across crm records

A customer hub is a system in which the records of one customer's commercial life — lead, deal, quote, order, contract, delivery, service — connect through explicit identifiers, so following the customer means following the references. The term is used three ways in practice: a profile hub assembled from many systems, a single screen over existing tools, and a record chain one application writes itself. Accordo implements only the third: a locally-run chain of audited records, with no ingestion, no identity resolution, no merge and no per-customer screen.

Where this stops

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

  • This page defines the term. It does not claim Accordo ships a finished customer hub product — the concept page for customer hub carries that argument with each domain's status attached.
  • The definition implemented here is the record chain only. Nothing ingests, deduplicates, merges or resolves identities from other systems, and there is no import or export (L-06).
  • There is no per-customer screen. The Admin navigates by module and domain, and no view assembles one customer's chain for a reader.
  • A customer hub is not a customer data platform. The profile-hub reading belongs to a different category this framework explicitly refuses.
  • None of it is deployable: no authentication, tenancy or RBAC (L-01), and no export or erasure path, so real customer data does not belong in it (L-09).

No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network. Every claim and every limitation is on one page.

The definition, and its three readings

A customer hub is a system where one customer's commercial records are connected rather than scattered: the quote knows its opportunity, the contract knows its order, the support case knows its entitlement. The value of the term is navigational — from any record you can reach the rest of the customer's history by following identifiers instead of re-keying names into other tools.

In practice the phrase covers three different systems, and knowing which one is being sold matters. The first is a profile hub: records and events ingested from many source systems, resolved into one profile per person or account — that is a customer data platform's job. The second is a screen hub: a unified interface laid over tools that stay separate. The third is a record-chain hub: one application writes all the records itself, and each record carries the id of the record it came from. Only the third makes no claim about systems it does not own — and only the third is what this framework builds.

The record-chain reading, as Accordo implements it

In an Accordo application the chain is written by the actions that move the process. A lead converts atomically into a Company, a Contact and an Opportunity through explicit, audited actions (C-06); a signed Order activates into a Commercial Contract that carries the orderId, quoteVersionId, opportunityId and companyId it descended from (C-10); delivery and service records carry the contract and company they serve. Every one of those identifiers is managed storage written by the framework, never a value a client supplied, and every mutation leaves an audit event and a step-level trace (C-16).

That is a single customer view as a property of the data, not as a feature of the interface. There is no per-customer page in the Admin, no cross-module search and no unified activity timeline — following a customer means reading the references, and the honest description of the result is a chain this application wrote, not a profile it assembled.

What this definition excludes

The profile-hub reading is excluded entirely: Accordo has no pipeline that ingests records or events from external systems, no identity resolution and no merge, so two records for the same human stay two records. Detecting duplicates, merging Companies or Contacts, importing from CSV and exporting records all read not supported in the job catalogue, and there is no import or export of any kind (L-06).

The deployment reading is excluded too. A hub built here runs on one developer's machine: no authentication, tenancy or RBAC (L-01), and no way to service a data-subject access or deletion request, which is why real customer data does not belong in it (L-09). For the fuller argument about what a hub built on this foundation is and is not, the customer hub concept page carries the commercial version of this definition with every status quoted from the catalogue.

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-10 A signed Order activates into a Commercial Contract, an immutable contract version, a Subscription and explicitly pending delivery and service obligations — every component classified, never guessed.

    LimitThe term is post-signature operational metadata, not a signed contractual term. Nothing bills, renews, amends or cancels: there is no scheduler, so auto-renew and notice periods are recorded and never fire.

  • 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, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.
  • L-06 No import, export, dedupe, merge, bulk edit, saved views or global search. Table stakes in every commercial CRM, and none of them has a milestone yet. This is recorded deliberately rather than left for you to discover.
  • L-09 You cannot put real customer data in this yet. A CRM is a personal-data system by definition, and this one has no authentication, no tenancy, no export and no erasure path — so there is no way to service a data-subject access or deletion request with it. Data governance is designed and unimplemented. The one thing that does hold today: lead scoring is deterministic, versioned and explainable, not a model's judgement about a person.

Jobs it covers

Documented in

Proved by