Architecture Overview

Architecture Overview

The SIGNET Canonical Data Model (CDM) is organised into four layers. Each layer builds on the one below. This page explains the layering, the lifecycle, the identifier model, and how the pieces fit together. For field-level detail, follow the links into each layer page.

┌─────────────────────────────────────────────────────────┐
│  Trust layer      Event · Provenance · Consent · Audit   │
├─────────────────────────────────────────────────────────┤
│  Agent layer      SyntheticAgent · Mandate · Capability ·│
│                   Decision · Policy                       │
├─────────────────────────────────────────────────────────┤
│  Process layer    Need · SourcingEvent · Lot · Submission│
│                   Evaluation · Award · Contract · Order · │
│                   Catalogue · Invoice · Obligation        │
├─────────────────────────────────────────────────────────┤
│  Foundation layer Identifier · Party · Credential ·      │
│                   Value · Period · Classification ·       │
│                   Document · Item · Provenance            │
└─────────────────────────────────────────────────────────┘

The four layers

Foundation layer

The primitive value types and reference objects used everywhere: identifiers, parties, values, periods, classifications, items, credentials, documents, provenance — plus the EN 16931 building blocks (Unit, InvoiceLine, VatBreakdown). These are defined once in schema/definitions.schema.json and referenced by every other schema. → Foundation Layer

Process layer

The procurement lifecycle objects, aligned to the five OCDS stages — planning, tender, award, contract, implementation. This includes the complete lifecycle: Need → SourcingEvent (with Lots) → Submission → Evaluation → Award → Contract → Order / Catalogue → Obligation → Invoice. → Process Layer

Agent layer

SIGNET's distinctive contribution. Structures that make the network agent-native: SyntheticAgent, AgentCapability, Mandate, Decision, and the Policy objects that govern them. No existing procurement standard represents synthetic agents as first-class, governed, accountable participants. → Agent Layer

Trust layer

Cross-cutting governance structures that wrap every object above: Event (append-only, hash-chained change records), Provenance (W3C PROV-aligned), and Consent (data-sovereignty access grants). → Trust Layer

The procurement lifecycle

The process layer follows the OCDS lifecycle so any SIGNET process can be projected to a conforming OCDS release. The canonical phase model:

 planning        tender                      award        contract     implementation
 ────────   ───────────────────────────   ─────────   ───────────   ──────────────────
  Need  →  SourcingEvent  →  Submission  →  Evaluation → Award → Contract →  Order
           (+ Lots)          (supplier)     (scoring)            (+Obligations)  Catalogue
                                                                                  Invoice

Stage	OCDS stage	Primary object(s)
Planning	planning	Need
Tender	tender	SourcingEvent, Lot, Submission, Evaluation
Award	award	Award
Contract	contract	Contract, Obligation
Implementation	implementation	Order, Catalogue, Invoice

Every transition between these is also recorded as an immutable Event in the trust layer (e.g. need.raised, submission.lodged, award.decided, contract.signed).

How the layers interlock

A few cross-layer relationships are worth highlighting, because they are what make SIGNET governed rather than merely interoperable:

• Policies govern process. A Need and a SourcingEvent reference Policy objects as governingPolicies, eligibilityCriteria, and evaluationCriteria. The same policy object that a human reads is the one a synthetic agent executes.
• Agents make decisions, decisions justify process. An Evaluation and an Award link to a Decision record. The Decision records who (human or synthetic) decided, under which mandate, from which inputs, applying which policies, with what rationale, and with what human approval.
• Mandates bound agents. A SyntheticAgent points to a Mandate that constrains the capabilities it may exercise, the hard limits it must respect, and the thresholds above which a human must approve.
• Everything carries provenance; everything emits events. Decisions and Events embed Provenance. The current state of any object is the projection of its ordered Event stream (principle 1.7), so the audit trail is the system of record.
• Access is consented. A Document whose access is controlled references a Consent grant, separating the assertion that a document exists from the right to read it (principle 1.5).

Identifiers and namespaces

• Every CDM object MUST carry a network-unique id.
• DIDs are RECOMMENDED for Parties and agents (making them self-sovereign and resolvable without a central registry); URN or URI identifiers are acceptable for process objects.
• The SIGNET vocabulary namespace, the published @context, and the registry of identifier schemes and codelists are maintained by Concert at stable URIs under concert.foundation and must not be repurposed to publish non-conforming extensions under the SIGNET name.

See Foundation Layer → Identifier and Codelists → identifierScheme.

Conformance keywords

The specification uses RFC 2119 / RFC 8174 keywords (MUST, MUST NOT, REQUIRED, SHALL, SHOULD, RECOMMENDED, MAY, OPTIONAL). Field cardinality is written as 1 (exactly one, required), 0..1 (optional single), 1..* (one or more, required), 0..* (zero or more). These same conventions are used throughout this wiki's layer pages. Whether an implementation actually meets these requirements is decided mechanically by the Conformance Harness.

Where to go next

• Drill into a layer: Foundation · Process · Agent · Trust.
• See the bridges: Standards Mapping.
• Understand the serialisation: Serialisation (JSON-LD).
• Check conformance: Conformance Harness.