]>

carsten@botstandards.org

ART The APIX Core () defines a three-dimensional trust model — Organisation Trust Level (O), Service Verification Level (S), and Liveness — that lets a consuming agent decide whether a discovered service is operated by a verified party, is technically reachable and consistent, and is currently alive. These dimensions do not describe the quality of what a service produces. They cannot answer whether a manufacturing process is GMP-certified, whether a product carries an independent quality grade, or whether an organisation holds a domain quality certification, nor who attested any of these and with what strength. This document defines the APIX Quality Attestation Extension: a cross-cutting extension, docking via the structured extensions container of the APM ( Section 7.1), that records third-party and self-declared quality claims about a discovered service's Organisation, Process, or Product, each carried with an explicit assurance level, attestation provenance, validity state, and liability regime. The extension reuses and extends the Core Verification Basis Registry for provenance and mirrors the Core capability-taxonomy governance for its criterion vocabulary. It is the mechanism by which measurable quality enters the agentic purchase decision without re-introducing the central-arbiter and race-to-the-bottom failure modes the Core is designed to prevent.

Introduction ## Motivation: The Quality Gap Federated, zero-prior-knowledge discovery lowers search and trust cost. Absent a verifiable quality layer, this has a structural side effect: the only machine-comparable parameter that remains is price, and the discovered market tends toward a race-to-the-bottom that structurally favours large aggregators able to source from a fragmented, commoditised supplier base. Two complementary mechanisms counter this: A public attestation layer prevents levelling on measurable quality. Attested, ideally independently verifiable properties let a small, high-quality provider justify a price premium rather than merely assert one. A private relationship overlay (Section 6.3) prevents relational trust capital ("know your supplier") from disappearing behind interchangeable criteria. Together they reconstruct, in machine-actionable form, what a competent procurement officer does: combine objective quality signals with hard-won relationship knowledge.

Relationship to APIX Core This extension does not modify the Core. It docks at the reserved docking points the Core defines for exactly this purpose: It is carried in the structured extensions container of the APM ( Section 7.1), under a registered extension identifier (Section 8). It is a distinct axis from the Core trust dimensions ( Section 8): O/S/Liveness describe operator verification, technical endpoint verification, and operational availability; this extension describes attested quality of organisation, process, or product. It reuses the Core Verification Basis Registry for attestation provenance, rather than defining a parallel root-type enumeration (Section 2.5). It mirrors the Core capability-taxonomy governance ( Section 5.3) for its Quality Criterion Registry (Section 4). A consuming agent that does not implement this extension ignores its data; an index that does not understand the extension key MUST nonetheless preserve it verbatim per Section 7.1.

Boundary with Core Evidence Channels (Normative) The Core already absorbs certain conformity attestations as evidence channels for an O-level. In particular, a Cyber Resilience Act conformity assessment is recorded as the cra_conformity channel substantiating O-5 ( Section 8.1). This extension MUST NOT duplicate, override, or re-express any attestation that the Core already records as an O-level or S-level evidence channel. This extension addresses the broader product- and process-quality space that the Core trust model does not represent — for example pharmaceutical GMP process certification, independent graded product testing, and domain-specific quality marks. Where an attestation could plausibly be expressed both ways, the Core evidence channel takes precedence and this extension MUST reference it rather than restate it.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals. Quality Assertion — the atomic unit of this extension: an attested statement about a quality criterion of an Organisation, Process, or Product. Attestation Body — an entity that issues Quality Assertions about other entities. An Attestation Body is itself a registered Organisation in the APIX and carries its own Quality Assertions describing its accreditation. Quality Criterion — a governed, registered definition of a measurable or assessable property, including (where applicable) a measurement method and scope.

The Quality Attestation Model

The Quality Assertion The Quality Assertion is the single primitive of this extension. Provider quality, attestation-body legitimacy, and private relationship depth are all expressed through it; they differ only in facet values. Consequently the accreditation chain is expressible in the same primitive: it is simply a set of Quality Assertions whose subject is an Attestation Body. A Quality Assertion has the following facets: Facet Description subject Identifier (e.g., DID) of the attested entity or service object_type ORG | PROC | PROD (Section 2.2) criterion Reference to a Quality Criterion, incl. measurement method and scope (Section 4) claim Value typed per Section 2.4: boolean, ordinal, or quantitative assurance_level A0..A3 (Section 2.3) attester Reference to a registered Attestation Body, or self verification_basis Reference into the Core Verification Basis Registry (Section 2.5) evidence Link/hash to underlying evidence (e.g., a credential) subject_revision Version/state of the assessed artefact the claim refers to (Section 2.4) validity issued, valid_from, valid_until, status, last_verified (Section 2.6) visibility public (index-recorded) | private (requester-held overlay) (Section 6.3) liability_regime Liable party, governing framework, coverage (Section 9)

Axis 1 — Quality Object Three orthogonal object types. A subject MAY carry assertions about each independently. The separation is not academic: a trustworthy organisation may ship mediocre products; a doubtful provider may ship an excellent product no one stands behind. Object What is attested Real-world examples ORG The legal/operational entity as a whole ISO 9001, domain quality marks PROC A defined operated process GMP (pharma), ISO 13485, ISO 14001 PROD A specific service/output carries property X independent graded product test, fitness-for-purpose report Note: organisational trust (identity, compliance posture) remains the Core O-level. ORG here means organisational quality attested by a third party, which is distinct from index-assigned O-level verification.

Axis 2 — Assurance Level A Quality Assertion without a declared assurance level is as dangerous as an organisation without an O-level: it suggests trust without a basis. Level Label Meaning Trust anchor A0 Self-declared Provider asserts it; no external backing provider reputation/liability only A1 Third-party attested External party attests; not (necessarily) accredited the attester A2 Accredited attestation Attester accredited under a recognised scheme the accreditation chain A3 Independently verifiable Claim binds to a reproducible measurement method the method, not the attester A3 is the gold standard: where reached, the issuer-pays failure mode (Section 7) collapses because the claim is auditable and challengeable independent of the attester.

Axis 3 — Claim Types and Temporal Binding The claim carries one of three value types: Type Form Example boolean conformance yes/no { "type": "boolean", "conformant": true } ordinal grade on a declared scale { "type": "ordinal", "grade": "good", "score": 2.1, "scale": "<scale-id>" } quantitative measured value + unit + metric { "type": "quantitative", "value": 99.95, "unit": "%", "metric": "<metric-id>" } An ordinal claim MUST reference a registered scale (range, direction, meaning of steps). An agent MUST NOT order ordinal claims across different scales. Ordinal and product-bound claims are version- and time-bound. The subject_revision and the assessment time form part of the claim; a grade issued for a superseded product revision is a different claim from a current one. Agents MUST be permitted to discount assertions bound to a superseded revision when ranking.

Attestation Provenance and the Verification Basis Registry Provenance is expressed through the Core Verification Basis Registry, extended (not duplicated) by this document. The verification_basis facet identifies the evidence channel and its root, so that agents operating under a specific regulatory regime can filter by provenance — the same mechanism the Core uses for eIDAS 2 QEAA and GLEIF LEI at O-2. This extension registers additional verification-basis entries for quality attestation, each declaring a root class: root class accreditation — authority derived from an accreditation chain (e.g., a national accreditation body under and its international peers). Used by accredited test/certification bodies. root class statutory — authority derived directly from law (e.g., a competent authority issuing a GMP certificate). The chain terminates at a legal basis, not at an accreditor. root class apix-governing-body — authority derived from the APIX Accredited Verifier model ( Section 8.6). This is the internal case and makes the Core Accredited Verifier model a special case of the general attestation layer defined here. Self-reference. An Attestation Body is itself a registered Organisation and carries ORG Quality Assertions describing its accreditation. The accreditation pyramid is therefore expressed in the same primitive. The index records and exposes the chain subject -> attester -> scheme -> root; it does not adjudicate legitimacy at any point. The consuming agent's policy decides which roots it trusts (Section 6).

Validity and Revocation status is one of active, suspended, revoked, expired. valid_until in the past yields expired regardless of the last reported status. Revocation MUST be checkable against a queryable status endpoint of the Attestation Body. An assertion whose revocation status is not checkable MUST be treated as at most A1, regardless of the declared level. last_verified records when validity was last confirmed.

Relationship to Core Trust Fields (Normative) The Core requires that trust fields be set exclusively by the index operator and that a Service Owner MUST NOT assert its own trust level ( Section 7.1). Quality Assertions are NOT Core trust fields. They are a distinct field class: externally sourced or self-declared claims that the index records with provenance, not trust levels the index assigns. This mirrors how the Core already records O-level evidence channels as facts about how a level was substantiated. Accordingly: A self-attested Quality Assertion is permitted but MUST be carried at A0 and MUST be clearly distinguishable from any index-assigned O/S value. It MUST NOT be presented as, or promotable to, a Core trust level. The index MUST NOT raise or lower a Core O/S level on the basis of a Quality Assertion in this extension.

The Quality Criterion Registry Comparability is the hardest sub-problem: self-defined, incomparable labels reproduce the eco-label proliferation failure where noise destroys signal. The governance of this registry mirrors the Core capability taxonomy ( Section 5.3) rather than inventing new machinery. Criteria are registered, not ad hoc: stable ID, human-readable definition, and — where applicable — a measurement method. Criteria are hierarchically namespaced by domain, e.g. pharma.gmp.sterile-fill, consumer.graded.overall, safety.product.<...>. A domain filter is thus a namespace filter. Each criterion declares scope disjunctness: what it does NOT cover. An attestation without scope is not machine-meaningful. Quantitative criteria MUST declare verb, unit, and threshold to permit A3. Ordinal scales are registered with range, direction, and step meaning. The registry follows the Core registry deprecation lifecycle (grace period, warning period, sunset). Registry governance MUST be federated, not centrally curated by the index operator, to avoid creating a second capture point (Section 7).

Discovery and Filtering Individual quality marks are NOT hard-wired top-level fields; that would be both a capture point and a brittleness source. Instead: First-class is the ability to filter over Quality Assertions as a query capability; marks are data addressed by Quality Criterion IDs. A domain filter is a namespace prefix filter over criterion IDs. The Index API SHOULD allow filtering by any combination of object_type, criterion (or namespace prefix), assurance_level >= A2, status = active, verification_basis root class, and assessment validity date.

Ranking, Weighting, and the Private Overlay

Two Data Natures Attested quality is about the subject, third-party attestable, belongs in the federated index (visibility: public). Relationship depth is relational, specific to the requester-provider pair, confidential business intelligence. It MUST NOT enter the public index (visibility: private). Placing relationship depth in the public index would leak who does business with whom, and server-side ranking on such signals would itself be a manipulation/capture point.

Hard Invariant

• No signal that is not a verifiable public Quality Assertion (or a Core trust field) MAY influence server-side ranking.

This follows the Core principle that the index exposes verifiable facts, not recommendations, and that trust decisions remain with the consuming agent ( Section 8). Weighting of relationship depth is therefore client-side by design, not by limitation. An index MAY offer stateless server-side scoring in which the agent supplies a weight vector over criteria and the index sorts by public data only; such scoring is a recomputable convenience and MUST NOT consider any private or relational signal.

Relationship Depth as a Private Overlay Relationship depth is modelled in the same primitive as a requester-held Quality Assertion with visibility: private — an overlay the agent merges locally with the public assertions before applying its weighting policy. The Core already establishes a private-state precedent: device instance trust state is never returned to unauthenticated queries ( Section 8.4). Without this overlay an agent would see only identically certified, interchangeable providers and relational trust capital would evaporate. The overlay is the second anti-commoditisation mechanism alongside the public attestation layer.

Root Trust Policy and Recognition

Purpose A Quality Assertion (Section 2.1) carries a verification_basis that resolves to a terminal root authority (Section 2.5). A consuming agent cannot enumerate every accreditation body and competent authority in the world, and it cannot delegate that judgement to the index without recreating the central-arbiter failure mode the Core forbids ( Section 8: the index exposes verifiable facts, not recommendations; trust decisions remain with the consuming agent). This section defines (a) how recognition relationships between roots are expressed as data in the federated index, and (b) how a consuming agent declares, in a Root Trust Policy, which roots it accepts — directly or through a recognition framework — and at what effective assurance. The separation is deliberate and follows Section 6.2: recognition facts are federated, verifiable assertions; root trust choices are a client-side policy. No part of recognition is adjudicated server-side.

Roots and Root Classes A Root is the terminal authority of a verification_basis chain. It has a stable identifier and a root class (Section 2.5): accreditation — a national accreditation body (e.g., one operating under Regulation (EC) 765/2008) or its international peer structure. statutory — a competent authority whose mandate derives from law (e.g., a GMP-inspecting authority). apix-governing-body — the APIX Accredited Verifier root ( Section 8.6).

Recognition Expressed as Quality Assertions A recognition relationship is itself a Quality Assertion, reusing the single primitive (Section 2.1). A Recognition Assertion states that a root is a signatory of a recognition framework for a defined scope: subject — the recognized Root (registered as an ORG) object_type — ORG criterion — apix:qcrit:meta.recognition.<framework> whose scope is the recognition scope (e.g., testing, calibration, inspection, qms, gmp-inspection) claim — { "type": "boolean", "conformant": true } attester — the framework secretariat (e.g., the body administering an ILAC-MRA / IAF-MLA arrangement, a regional accreditation cooperation, or a competent authority administering a pharmaceutical MRA), itself a registered entity verification_basis — the statutory or accreditation root of that secretariat validity — the signatory status period; revocable per Section 2.6 The recognition framework is therefore just a well-known attester whose assertions say "Root X is my signatory for scope Y." Multilateral arrangements (one secretariat, many signatories) produce one Recognition Assertion per signatory. The index records and exposes these; it does not adjudicate them.

The Root Trust Policy A consuming agent expresses a Root Trust Policy as an ordered set of entries. Each entry is one of: Explicit root trust — trust a named Root directly. Framework trust — trust every signatory of a named recognition framework. Every entry MAY carry: scope — a set of Quality Criterion namespaces to which the entry applies (e.g., pharma.gmp.*). An entry with no scope applies to all criteria. An entry MUST be ignored for any assertion whose criterion falls outside its scope. assurance_cap — an upper bound on the effective assurance level contributed by assertions accepted under this entry. max_recognition_depth — for framework entries, the maximum number of recognition edges the agent will traverse (Section 6.4.6). Default 1. The policy is default-deny: an assertion whose root is not matched by any policy entry contributes no assurance and MUST be treated as if self-declared (effective A0), regardless of its declared level. The assertion data remains visible to the agent; it simply earns no third-party assurance.

Assurance Resolution Algorithm (Normative) For each Quality Assertion the agent computes an effective assurance level as follows:

recognized(R, f, depth_limit, scope) is true iff there exists a chain of at most depth_limit valid (non-expired, non-revoked) Recognition Assertions linking a Root trusted under framework f to R, where the recognition scope covers scope at every edge. Scope is checked at every hop; a chain that loses scope coverage at any edge does not recognize R for that criterion. Notes: A0 never gains assurance from roots. A3 is self-verifying: an agent that executes the criterion's measurement method needs no root trust at all. Root policy therefore primarily governs A1/A2 (attester-anchored) assertions. Effective assurance is always the minimum across the assertion's own level, any recognition cap, and the matched policy entry's cap.

Recognition Depth and Anti-Laundering Transitive recognition ("A recognizes B, B recognizes C") is a laundering surface: a weakly governed framework could relay trust from a strong one. The default max_recognition_depth is therefore 1 (direct recognition only). An agent MAY raise it but SHOULD NOT exceed a small bound, analogous to X.509 path-length constraints. Recognition chains MUST be acyclic; an agent MUST detect and reject cycles.

Bootstrapping and Default Policies An agent needs an initial trust anchor. The index MUST NOT supply it (that would make APIX the gatekeeper). Instead, baseline Root Trust Policies are published by parties whose authority is independent of the index — typically regulators or regional bodies. A jurisdiction-specific baseline policy is the point at which regulatory-regime preference becomes machine-actionable: an agent operating under a given regime loads that regime's baseline (for example one that trusts roots anchored in that regime's accreditation cooperation and its recognized MRAs) and extends it locally. This is the policy-layer counterpart to the Core's verification_basis provenance filtering ( Section 8.1). Baseline policies are themselves data, not code: an agent SHOULD obtain them as signed, versioned documents and SHOULD record which baseline and version it applied.

Worked Example — GMP Recognition for CDMO Discovery A procurement agent sourcing contract manufacturing capacity expresses:

The agent trusts EU-cooperation-anchored GMP authorities directly, and GMP authorities of mutual-recognition partner jurisdictions through the EU-GMP MRA framework — one hop only, scoped strictly to pharma.gmp.*. Everything else is denied for pharma. The specific partner authorities are never hardcoded in the policy; they are carried as Recognition Assertions in the index, e.g.:

Resolution trace for a CDMO whose GMP PROC assertion is rooted at competent-authority-partner-yy (claimed A2): Assertion level A2, not A0/A3 → resolve root. No explicit entry for that root. Framework eu-gmp-mra is trusted; one valid Recognition Assertion links the partner authority to the framework, scope gmp-inspection covers pharma.gmp.* at the single edge, depth 1 OK. Effective assurance = min(A2, cap A2) = A2. Accepted. A CDMO whose GMP assertion is rooted at an authority with no recognition chain to either trusted framework resolves to A0 and is excluded by any Trust Policy requiring >= A2 for pharma.gmp.*.

Security Considerations (Recognition-Specific) Recognition spoofing — a forged Recognition Assertion. Mitigated by requiring the attester (secretariat) to resolve to a registered entity with its own verification_basis; an unresolved secretariat downgrades the recognition to ineffective. Scope creep — a recognition valid for one scope relied upon for another. Prevented by per-edge scope checking (Section 6.4.5). Stale membership — an expired or revoked signatory still relied upon. Prevented by Section 2.6 validity precedence; an unresolvable revocation status makes the recognition ineffective. Transitive laundering / cycles — bounded by default depth 1 and the acyclicity requirement (Section 6.4.6). Baseline-policy substitution — a tampered baseline. Mitigated by signed, versioned baselines and by recording the applied baseline version (Section 6.4.7).

Structural Failure Modes and Mitigations Failure mode Mechanism Mitigation Issuer-pays / rating-agency Provider-paid body is lax A3 verifiability + accreditation layer Goodhart Optimising for the label, not the quality measurement-method binding + scope disjunctness Label proliferation Inflation of incomparable labels governed Quality Criterion Registry; scope obligation Accreditation capture Index becomes the legitimacy gatekeeper index traverses only; root trust at the agent Relationship commoditisation "Know your supplier" disappears private overlay (Section 6.3); client-side ranking Ranking capture Server-side ranking on purchased signals hard invariant (Section 6.2)

APM Integration A Quality Assertion set is carried under a single registered extension key in the APM extensions container ( Section 7.1). Example (illustrative; aligned to where applicable):

A private overlay assertion carries the same shape with "visibility": "private", "attester": "self", "assurance_level": "A0", and is held by the requesting agent rather than submitted to the index.

Liability A price-justifying claim only holds if a party is liable when it is false; in agentic procurement a false, agent-relied-upon claim can trigger real damage chains. Every Quality Assertion MUST declare a liability_regime naming the liable party (attester / provider / none), the governing law or clause, and the coverage. The index records who attested what under which regime; the index itself bears no liability for the content of recorded attestations.

Security Considerations False or inflated attestations are the primary risk; the assurance ladder, the accreditation/verification-basis chain, and the requirement that revocation be checkable (Section 2.6) are the structural defences. Provenance spoofing is mitigated by requiring verification_basis to resolve to a registered Attestation Body and a registered root class; unresolved chains MUST downgrade the effective assurance level. Self-declared (A0) assertions carry no third-party assurance and MUST be treated by agents as provider claims only. Stale validity is handled by expired precedence and last_verified freshness.

IANA / Registry Considerations This document requests: Registration of the org.botstandards.quality.v1 extension identifier in the APIX extension-identifier registry maintained by the governing body ( IANA Considerations; apix.example.org/registry/extensions). The identifier follows the Core format <reverse-domain>.<extension-name>.v<major>. Establishment of a Quality Criterion Registry under the governance rules of Section 4, mirroring the Core capability-taxonomy registry. Reservation of the private.* criterion namespace as client-side only. Criteria under private.* (e.g., private.relationship.depth, Section 6.3) MUST NOT be registered in the public Quality Criterion Registry and MUST NOT be served by an index; they exist solely as requester-held overlay assertions (visibility: private). An index that receives a submission carrying a private.* criterion or visibility: private MUST reject it. This mirrors the reserved-namespace mechanism of (contract.*, extension.*). Additional Verification Basis Registry entries for quality attestation, each declaring a root class (accreditation, statutory, apix-governing-body), coordinated with .

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities.

Open Issues Quality Criterion Registry governance details (who federates scale and metric definitions). Private overlay storage: where and how visibility: private assertions are held client-side and protected against exfiltration. Exact coordination procedure with the Core Verification Basis Registry to keep the O-5 cra_conformity boundary (Section 1.3) unambiguous. (Note: the former open issue on root-recognition policy format is resolved by Section 6.4.) End of draft-rehfeld-apix-quality-00. Composes with draft-rehfeld-apix-core-07 (co-submission cluster: core-07, services-04, iot-04, quality-00).