Skip to main content
Version: Work in Progress
UNTP Public Review
Public review has now closed. The UNTP team is working through the review comments and expects to release UNTP version 1.0.
info

Please note that this specification is suitable for pre-production pilot implementations.

Claims and Assessments

A supplier's claim and an auditor's assessment are only useful to the party receiving them if that party can work out what was assessed, against what requirement, and what the numbers mean. UNTP carries all three in the same small set of properties, and this page is about using them well. The data model itself is described on the credential pages; what follows is the practice that makes a conforming credential a useful one.

Two credentials carry the two sides. A Claim is self-declared by the subject's owner and appears on a Digital Product Passport, a Digital Facility Record or a Digital Corporate Record, in each case as performanceClaim. A ConformityAssessment is issued by an independent party and appears on a Conformity Credential as conformityAssessment. Both reference criteria and both carry performance, so a buyer can compare what a supplier says about itself against what an assessor found.

UNTP claims and assessments architecture: credentials reference a conformity criterion published by a scheme owner; the criterion is classified by a conformity topic and uses a performance metric, so performance can be compared and rolled up from product to corporate level

The two taxonomies​

Two published vocabularies give claims and assessments their shared meaning. Both are SKOS concept schemes, maintained in the UN/CEFACT vocabulary rather than in this repository.

TaxonomyPublished atWhat it classifies
Conformity Topicsconformity-topicsThe subject matter a criterion addresses
Performance Metricsperformance-metricsWhat is measured, in what unit, and which direction is better

Keep the two apart. A topic answers what is being assessed, so "Greenhouse Gas Emissions" or "Water Conservation". A metric answers what was measured and how, so "Scope 1 GHG Emissions in tonnes CO2e" or "Recycled Content Percentage". One topic usually has several metrics beneath it, and conflating them produces claims that cannot be aggregated: a buyer can add up tonnes of CO2e across suppliers, but cannot add up "emissions".

Every concept has its own resolvable identifier, and content negotiation works at any level of either hierarchy, so the same URI serves a person and a machine.

curl https://test.uncefact.org/vocabulary/conformity-topics/water-conservation \
-H 'Accept: application/ld+json'

Browse either scheme at the links above for the full list of concepts, their definitions, their scope notes and their mappings to international frameworks. The topics are mapped to the UN Sustainable Development Goals, the OECD Guidelines for Multinational Enterprises and regulatory instruments including the EU deforestation and due diligence regulations. The metrics are mapped to the IFRS Sustainability Disclosure Standards and the GRI Standards, which is what allows product-level and facility-level data to roll up into corporate reporting.

A claim is only as good as its criterion​

Both a claim and an assessment reference criteria, in referenceCriteria and assessmentCriteria respectively. The criterion is where the requirement being claimed or assessed is actually stated, and it is the part most often done badly. A criterion whose id is a URI published by the party that owns the requirement can be looked up, compared across credentials and relied on. A criterion carrying only a name and a sentence of prose validates perfectly well and tells a downstream buyer almost nothing.

{
"type": ["Criterion"],
"criteriaType": "scheme-criterion",
"id": "https://sample-scheme.coppermark.org/criteria/ghg-management/v3",
"name": "GHG Emissions Management (Coppermark RRA Criterion 26)",
"conformityTopic": [
{
"type": ["ConformityTopic"],
"id": "https://test.uncefact.org/vocabulary/conformity-topics/greenhouse-gas-emissions",
"name": "Greenhouse Gas Emissions"
}
]
}

The criteriaType property says what kind of source the identifier points at: a scheme criterion, a whole scheme profile, a published standard, a regulation, or another published document. Use it honestly: a claim citing a regulation as its criterion is making a different statement from one citing a scheme's audited criterion, and a verifier reads the two differently.

Where the requirement comes from a conformity scheme, the criterion URI should be published by the scheme owner through a Conformity Vocabulary Catalog, and the scheme itself should appear in the CVC register. The register records each scheme's catalogue location and, for each profile version, the topics that version covers. That gives a reader two paths: from a credential's criterion to the scheme that defines it, and from a topic to the schemes that address it.

Classification flows through the criteria​

conformityTopic sits on Criterion, and only there. Neither Claim nor ConformityAssessment carries a topic of its own, and this is deliberate. A claim is classified by the criteria it references, so holding the topic on the container as well would store the same fact twice and let the two drift apart. It also would not work: one assessment may reference several criteria on different topics, and a single topic on the assessment could not represent that.

So the way to make a claim findable by subject is to reference criteria that are themselves well classified. If a scheme's criteria carry no topics, the claims referencing them cannot be grouped, however carefully the rest of the credential is filled in. That is a reason to prefer schemes whose catalogue is published and classified, and a reason for scheme owners to classify their criteria.

Metrics give the numbers meaning​

A measure on its own is not interpretable. "1.8" needs a unit, and "1.8 litres" still needs to say litres of what, per what. The metric property supplies that by naming a published metric, and the metric's own definition carries the unit it is expressed in, how values aggregate, and whether higher or lower is better. A consumer reading water-intensity knows the value is litres per unit of output, that intensities combine as a weighted average rather than a sum, and that lower is better, without being told any of it by the issuer.

{
"metric": {
"type": ["PerformanceMetric"],
"id": "https://test.uncefact.org/vocabulary/performance-metrics/water-intensity",
"name": "Water Intensity"
},
"measure": { "value": 1.8, "unit": "LTR" },
"determination": "pass"
}

Use the published unit for the metric rather than a convenient alternative. Two suppliers reporting the same metric in different units cannot be compared without a conversion the consumer has to infer, which is the problem the metric was there to solve.

A numeric measure requires a metric, which the schema enforces. The reverse does not hold, and a performance entry may state its outcome without measuring anything.

  • measure for a quantity, with its metric.
  • score for a position on a scale the scheme defines, such as a maturity level or a grade.
  • determination for a conformity outcome from the UN/CEFACT conformity-determination code list.
  • qualitativeFinding for an outcome that only words capture.

Any one of these is enough and they combine. An assessment that found no reportable incidents has nothing numeric to report and should say so plainly rather than inventing a count of zero against a metric that does not exist:

{
"determination": "pass",
"qualitativeFinding": "No loss-of-containment or reportable exposure events during the assessment period; handling procedures were followed and records were complete."
}

Where no published metric fits, a scheme may define its own and reference it by a URI it publishes, the same way it publishes criteria. That is better than forcing a measurement into an ill-fitting UN metric, and it still gives the consumer something to resolve. It does cost comparability outside the scheme, so it is worth checking the published list first.

Required, claimed and assessed​

The same Performance shape appears in three positions, and the position is what gives it meaning.

PropertyOnMeans
requiredPerformanceCriterionThe threshold the criterion sets
claimedPerformanceClaimWhat the subject's owner declares
assessedPerformanceConformityAssessmentWhat an independent party found

Because all three use the same metrics, they can be read against each other: a criterion requiring a score of at least "conformant", a supplier claiming it, and an assessor confirming it are three statements about one quantity rather than three unrelated numbers. A consumer that understands the metric can evaluate the claim against the requirement without understanding the scheme.

The distinction between claimed and assessed carries most of the assurance weight, and it is easy to lose. The four outcome forms mean the same things in both places, so a determination of pass on a claim looks identical to one on an assessment while meaning something much weaker: it is the supplier's own judgement about its own product. Where independent assurance matters, a claim should carry evidence linking to the conformity credential, and a verifier should read the determination there rather than on the claim.

Rolling up from product to corporate​

The three claim carriers describe different subjects, and using the same metric identifiers across them is what lets data move between the levels. A product passport reports a product carbon footprint per unit. A facility record reports the facility's annual totals. A corporate record consolidates across operated facilities for a reporting period. Reported against the same metric IRIs, a facility's Scope 1 total and a group's consolidated Scope 1 are the same measurement at two scopes, which is the alignment with IFRS S2 and GRI that the metrics scheme is built for.

Product-level and facility-level claims usually differ in the kind of metric they suit. Per-unit intensities belong on a product; absolute annual totals belong on a facility or a corporate record. Reporting an annual total on a product passport, or a per-unit intensity as a corporate disclosure, will validate and will not aggregate.

A short checklist​

Reviewing someone else's credential, or your own before issuing it:

  • Does every criterion have an id that resolves, published by whoever owns the requirement?
  • Is criteriaType the kind of source that identifier actually points at?
  • Does every criterion carry at least one conformityTopic from the published scheme?
  • Is every metric a concept that exists, at a resolvable URI, rather than a plausible-looking slug?
  • Does every measure use the unit the metric defines?
  • Where there is no number, is the outcome stated as a score, a determination or a finding rather than as a fabricated measure?
  • Does a self-declared claim that matters carry evidence pointing at independent assessment?
  • Are absolute totals and per-unit intensities on the subjects they belong to?