Certification, decided by a machine

Register version: v0.1 Class: Normative. Closed and append-only. Status: Established under the interim-committee bootstrap clause. Both entries are proposed; no endorsement is earnable and none may appear in a mark until its entry is active. Steward: Concert Foundation Licence: CC0-1.0 Governs: the endorsement-list production in mark grammar §4.

An endorsement certifies a property that is worth certifying but does not belong on the Core/Full level axis, because it is not universally applicable. Endorsements are additive: they change neither Core nor Full, nobody is blocked from certifying without one, and an unearned endorsement is inert. See conformance/levels.md §2.4.

1. Register mechanics

Closed. An endorsement exists only if it appears below. An implementation may not coin one, and a profile may not add one.

Append-only. Entries are added, never removed or renamed. Withdrawing an endorsement means marking its entry withdrawn and stating the date; marks already issued keep naming it, and the register keeps explaining what it meant.

Admission is a Standards Committee act, at a suite minor-version boundary only. Every admission records the three-part test (§2) against the entry, which makes admission auditable rather than discretionary.

Ordering is register order, not alphabetical. The endorsement-list in a mark string MUST follow the order below. Register order keeps a given set of endorsements rendering identically as the register grows.

Registry entries record the register version in force at issuance. The register is append-only, so without this every certification issued before a later admission would appear deficient against a register that grew after the fact. That unfairness is created automatically by append-only design unless entries are dated against it.

2. The three-part test (normative)

An endorsement may enter this register only where the property is:

• (a) genuinely orthogonal to the Core/Full level axis — it is not a stronger version of a level requirement, and adding it to a level would be wrong rather than merely aggressive;
• (b) not universally applicable — some conformant implementations have no occasion to exhibit it, so requiring it at a level would fail them for an irrelevance; and
• (c) machine-testable under CN-1 — a public, reproducible check decides it, with no discretionary judgement.

A property failing (a) belongs in a level. A property failing (b) belongs in a level. A property failing (c) belongs nowhere in certification, and should be said out loud as a scope limit instead.

3. Entries

E1 — Mandate Enforcement

Three-part test. (a) Orthogonal — Core and Full concern document structure, event integrity, provenance, mapping fidelity, and the form of policies and decisions; whether an agent's action was refused when it exceeded its mandate is a behavioural property of a different kind. (b) Not universally applicable — an implementation that runs no synthetic agents has no mandates to enforce. (c) Machine-testable — the harness supplies the Mandate and the Policy objects, so it knows the expected outcome of each scenario, and the Policy carries an executable expression an assessor can re-evaluate independently.

What it establishes. That the boundary sits where the mandate says it does: an action beyond an approvalThresholds policy does not complete on the agent's own authority; actions within all thresholds proceed without demanding approval; capability, scope, and effectiveness limits refuse; a constraints policy is a hard limit that humanApproval cannot cure; and every refusal is evented, so refused and never attempted are distinguishable in the record.

What it does not establish. That the implementation's mandates are well drafted, that its policies express the organisation's actual delegation of authority, or anything about actions taken outside the SIGNET record.

It also establishes nothing about human oversight having occurred — only that autonomous completion did not. A conformance run is unattended, so the suite never observes an approval and does not test what happens after one: real flows resume, and that resumption is out of scope. Nothing here speaks to the identity, authority, or existence of any approver; identity-proofing is outside the standard. An implementation MUST NOT represent this endorsement as evidence that a human reviewed anything.

E2 — Consent Enforcement

Three-part test. (a) Orthogonal — C-DOC validates a Consent structurally and says nothing about whether the grant has any consequence. (b) Not universally applicable — an implementation may hold no access-controlled documents at all. (c) Machine-testable — the harness supplies the grant, the event stream, and the evaluation time, so effectiveness is deterministic and reproducible under CN-4.

Scope limit (normative for this entry). E-CNS certifies the interoperability of the grant — its representation, its projection from the event stream, and the temporal and party evaluation the model defines. It does not certify runtime access enforcement: whether a production system physically refuses a read is a security-posture property assessed under ISO 27001 and SOC 2 regimes. Concert does not claim to certify it, and no positioning copy may imply otherwise. This limit is why the endorsement is named Consent Enforcement and not Data Sovereignty: a badge reading Data Sovereignty would assert precisely the thing the proposal declines to assert.

What it does establish, stated positively so the limit does not read as a bare deficiency: grant terms are represented interoperably; the implementation's own authorisation decisions honour those terms as the model defines them; revocable acquires its first enforced consequence; and because the effective/not-effective determination is reproducible from the published event stream, a third party can verify after the fact whether access decisions were consistent with the grants then in force.

4. Why two entries and not one

A single "governance" badge covering both properties was considered and rejected. The decisive argument is not accuracy but that a merged badge has no coherent earning rule: the two properties are independently applicable — an implementation may run agents but hold no access-controlled documents, or the reverse. A conjunction rule would make the badge unearnable for most implementations; a disjunction rule would award it on the strength of the half not done.

5. Change log

Steward: Concert Foundation · Tier: Process · Licence: CC0-1.0

Certification turns a passing conformance result into the right to use the "SIGNET Certified" mark. This document describes the process. It is governed by the neutrality rules (CN-1…CN-4) in levels.md and the Concert IP & Licensing Policy. The process is identical for every implementer, including Score Networks.

1. What certification asserts

SIGNET Certified: Core or SIGNET Certified: Full asserts that, against a stated CDM version and suite version, the implementation produced a passing conformance report at that level from the public, machine-runnable suite. It asserts nothing more: it is not a security audit, or a guarantee of fitness.

Nor does it assert that every MUST in the specification was met — only the requirements in levels.md §2, which the suite decides. Two governance properties are modelled but untested at any level, and levels.md §5 says which and why. A Full certification is not evidence that human oversight was enforced.

2. The process

1. Self-test. The implementer writes a conformance adapter for their system (see adapter/adapter-contract.md) and runs the public suite:

   node conformance/runner/run-conformance.js --adapter <their-adapter>
   

   This produces a report conforming to report-schema.json.
2. Submit. The implementer sends Concert the report, the adapter source, and the suite + CDM versions used. Because the suite is public and the result is reproducible (CN-4), no private assessment is needed.
3. Reproduce. Concert re-runs the identical suite against the submitted adapter and confirms the report. The check is mechanical (CN-1).
4. Issue. On a confirmed pass, Concert records the certification (implementer, level, CDM version, suite version, date, report hash) in the public registry — certification-register.md — and licenses the "SIGNET Certified" mark for that level and version.
5. Publish. The report is publishable; the registry entry is public.

There is no committee judgement, interview, or discretionary gate at any step.

The register is empty. No certification has been issued to anyone, including Score Networks, so no mark is licensed and no short form resolves today. It is empty as a statement of fact, not as a placeholder: this document specified a public registry from the moment it was written, and for as long as no artifact existed a mark string had nothing to resolve to (governance/defects.md D-44).

3. Marks and their use

The form of every mark Concert issues is fixed by the mark grammar, which is normative for licensees. In outline:

• The canonical implementation mark is SIGNET Certified: <Core|Full>[; <endorsements>] (CDM vX.Y, suite vX.Y) — for example SIGNET Certified: Full (CDM v0.1, suite v0.1). Mark strings are ASCII, and the punctuation is fixed so the form can be linted in CI (npm run lint:marks).
• The registry record is the source of truth; the string is a projection. No mark string is authored by hand. The registry is certification-register.md.
• Short forms resolve or they are not licensed. SIGNET Certified: Full is permitted only alongside a resolvable link to the registry entry; the bare badge only as a hyperlink. Print, slides, and spoken claims require the canonical form — the qualification is the claim.
• An endorsement MUST NOT appear without a level.
• The mark licence is granted under the IP & Licensing Policy, on identical terms to all implementers, and is conditional on a current passing report.
• Misuse — claiming a level not achieved, or omitting the version qualification in a way that misleads — is grounds for withdrawal of the mark licence, under the complaint-driven escalation in mark grammar R5.

Anyone may say they implement SIGNET. The artifacts are CC0, so "Implements SIGNET CDM v0.1" and "Self-assessed against the SIGNET conformance suite v0.1 — Core" need no permission. What requires a licence is the assertion that Concert assessed you. The qualifier self-assessed is mandatory in that construction.

3.1 Registry entries

The registry is certification-register.md: closed, append-only, and currently empty.

A registry entry records the implementer, the level, the CDM and suite versions, the date, the report hash, any endorsements held — and the endorsement register version in force at issuance. The endorsement register is append-only, so without that last field every certification issued before a later admission would appear deficient against a register that grew after the fact.

Failed attempts are not published. An implementation that tries, fails, fixes, and retries is behaviour worth encouraging.

4. Renewal and versioning

• A certification is valid for its stated CDM + suite versions.
• A new CDM major version requires re-certification.
• A suite minor/patch update (added or clarified tests) does not invalidate an existing certification immediately, but the current suite applies at renewal.
• Concert publishes the current versions and a deprecation window for superseded ones.
• A mark for a superseded CDM major version is not false, but it is misleading in any form that hides the version — so it survives in canonical form only, and the short and minimal forms are withdrawn (mark grammar §9).

5. Fees and neutrality

Certification may carry a fee that funds Concert's neutral stewardship. The fee is published, identical for all implementers at a given level, and unrelated to the outcome (you pay to be assessed, not to pass). No implementer — including Score Networks — receives a discount, a fast track, or any other preference (CN-3). Fees are the Foundation's primary sustaining revenue, by design, so that the standard itself can remain free.

6. Disputes

Because conformance is mechanical and reproducible, a dispute is resolved by re-running the public suite. If an implementer believes a test is wrong (rather than their implementation), they raise it through the normal standard change-control process; the suite is corrected for everyone or not at all (CN-2).