Better Data

Getting Started

Platform architecture

Edit this page

Platform architecture

Better Data is architected as four operational authority layers — not a flat list of SKUs. Each layer answers a different authority question for the organization.

| Layer | Authority | Role | | ----- | --------- | ---- | | Commerce Chain | Operational truth | Authoritative supply/demand and chain state — inventory, orders, fulfillment, procurement, returns | | Loop Engine | Governed decisions | Policy, approvals, attribution, evidence, and audit on transitions | | Commerce Gateway | Controlled connectivity | Governed tool and data access for AI and systems (implementation: MCP and other adapters — see Commerce Gateway) | | Signal Tags | Operational trust | Verification, provenance, and physical-world evidence tied to chain operations |

Operating model: Sense → Decide → Approve → Execute → Improve. (Docs that still say “Execute → Improve → Govern” should be updated to Approve as the tangible governance step.)

Narrative + diagrams (buyer context): Architecture on betterdata.co. This page is the technical companion — link out instead of duplicating marketing copy.

Canonical layered messaging (Infrastructure → Protocol → Reference → Control → Platform) lives in Core Concepts — Layered ecosystem. MCP surface roles (Gateway Console vs Commerce Gateway vs Registry MCP): MCP surfaces. Full C8 contract: Surface contract.

Diagrams below describe how signals and authority flow across product layers — they are not a second competing “flat stack,” and not the same as the MCP deployment table alone.

How the layers connect

High-level signal flow (events and decisions move through the stack; your deployment may partition services differently):

1Applications & automations
2      ↓
3Loop Engine          ← governed decisions (policy, approve, audit)
4      ↓
5Commerce Chain       ← operational truth (SCM / DCM)
6      ↓
7Commerce Gateway     ← controlled connectivity (AI & integrations)
8      ↓
9Signal Tags          ← operational trust (verify / attest at the edge)
10      ↓
11Partners, carriers, regulators, customers

A tag verification, procurement approval gate, or order event can open or advance a loop. The gateway exposes governed tools to LLMs and other clients against the same operational truth the Commerce Chain maintains.

Agent composition (C12)

Agents are not an autonomous platform or a separate “agent SKU.” They use Registry MCP to discover, Commerce Gateway to act, and Loop Engine to govern — the same layers as the rest of the system:

1Agent
2  ↓
3Registry MCP
4  ↓
5Commerce Gateway
6  ↓
7Loop Engine
8  ↓
9Demo / UI

→ Commerce Agent pattern · Build an agent

OSS vs hosted

OSS delivers composable engines and contracts (self-hostable Apache-2.0 where published). Hosted adds multi-tenant isolation, governance overlays (Industry Packs), operational coordination, trust surfaces (e.g. hosted verify), managed gateways and loops, compliance reporting, and enterprise SLA.

Industry Packs and parts of the hosted platform surface are proprietary; domain packages and many loop definitions remain OSS. Exact package names and scopes: Open Source overview.

The loop model

Everything important is modeled as a loop: a governed cycle with named actors, guards, evidence, and an audit trail. Phrases like “approval workflow” or “transfer workflow” describe task patterns inside loops — they are not the platform’s category identity.

Examples:

  • Procurement — recommend → guard evaluates → human approves → PO executes
  • Quality — Signal Tag verification → quarantine or release with evidence
  • Returns — RMA → inspection → disposition

See Loops and Hosted Loop Engine.

Where to go next