Digital Facility Record

info

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

Artifacts

v0.8.0 Schema and Samples

The JSON schema and sample credential instances for the Digital Facility Record are maintained in this repository.

• JSON Schema:

Schema	Description
DigitalFacilityRecord.json	Full credential schema including the W3C VC envelope and Facility subject
Facility.json	Standalone schema for the Facility credential subject

• Sample Instances:

Sample	Description
DigitalFacilityRecord_instance.json	Copper mine in Zambia
DigitalFacilityRecord_smelter_instance.json	Copper refinery in Japan
DigitalFacilityRecord_battery_instance.json	Battery factory in Germany

The three samples represent successive stages of a copper-to-battery supply chain.

Vocabulary and Context

The DFR is built on the UNTP Core Vocabulary, which defines the shared classes and properties used across all UNTP credential types. The machine-readable vocabulary and JSON-LD context files are published under https://vocabulary.uncefact.org/untp/.

A credential references the versioned context, not that base path. For this release that is https://vocabulary.uncefact.org/untp/0.8.0/context/, which is what the samples on this page use. The unversioned path is where the vocabulary is published, not a context a credential can resolve.

Overview

The digital facility record (DFR) is issued by the owner or operator of a production or manufacturing facility and is the carrier of facility data and sustainability information for an identified facility in the value chain. It describes the facility's identity, location, ownership, material consumption, and sustainability performance over a defined reporting period. Because facilities are long-lived assets, DFRs are designed to be re-issued as performance data is refreshed, so that customers see an up-to-date picture of facility operations.

A facility typically has multiple identifiers issued by different organisations — a national environmental register, a mining cadastre, an industry membership number. The DFR architecture allows each of these identifiers to resolve to the same facility record maintained by the facility operator, restoring data ownership to the natural owner while enabling discovery from any register. The DFR is discoverable in the same way as a DPP — by resolving a facility identifier to an Identity Resolver service that returns links to the facility record.

The DFR tracks material usage — the raw materials consumed by the facility, their origin countries, mass fractions, recycled content, and hazardous indicators — as well as performance claims at the facility's annual total level (e.g. total Scope 1 emissions in tonnes) rather than at the per-product level. In many value chains, facility-level information may be sufficient to meet the due diligence requirements of buyers, and so the DFR can be used independently of product passports. However, product passports SHOULD reference the facility at which the product was produced. Where both facility and product information are available, verifiers can perform an approximate mass-balance cross-check — for example, the total emissions recorded across all products shipped from a facility should approximately equal the reported annual emissions of the facility. This is an optional analysis that a verifier may run when the data happens to support it. It is not a conformance requirement and not an expectation on issuers. Quantitative material and emissions data is simply unavailable to many facilities, particularly in apparel, footwear and light manufacturing, and a DFR that omits it is as conformant as one that includes it. The same applies to every other facility-level quantitative measure: recycled content, water, waste. Reporting what you can substantiate is the requirement; reporting everything is not.

Conceptual Model

A Digital Facility Record answers six key questions about a production or manufacturing facility:

• WHO owns or operates the facility — identified by a registered business entity with a verifiable identifier.
• WHAT is the facility — its identity, name, address, and registration details.
• WHERE is it located — using point coordinates, boundary polygons, or Plus Codes.
• SCOPE of operations — classified by industry process categories (e.g. UN CPC).
• MATERIAL usage — what raw materials are consumed, their origin countries, volumes, and recycled content over a reporting period.
• CLAIMS about facility performance — conformity claims against recognised standards or regulations, each quantified by specific performance metrics such as GHG emissions intensity or water consumption.

Design Requirements

The digital facility record is designed to meet the following detailed requirements as well as the more general UNTP Requirements

ID	Name	Requirement Statement	Solution Mapping
01	Resolvable ID	Each facility must have at least one resolvable identifier that can be used in digital product passports and other data exchanges so that verifiers can always access the latest facility data.	Facility.id and Facility.registeredId with Facility.idScheme
02	Process categories	The DFR should support any number of industry process classifications using codes from a defined classification scheme (eg UN CPC).	The Facility.processCategory array of Classification objects
03	Geo-Location	The DFR should provide a means to specify a geo-location point, a boundary geometry, and/or a variable-precision area code so that verifiers can geo-locate supplier facilities.	Facility.locationInformation with geoLocation, geoBoundary, and plusCode
04	Related parties	The DFR should specify the owner and/or operator of the facility using one or more globally unique and resolvable entity identifiers, each in a defined role.	The Facility.relatedParty array of PartyRole objects, each linking to a Party with verifiable identifiers
05	Claims	The DFR MUST provide a means to include any number of performance claims so that it can provide a single point to aggregate all claims about the facility in one place.	The Facility.performanceClaim array of Claim objects
06	Conformity Topic	The DFR MUST provide a simple mechanism to express the sustainability/circularity/conformity topic for each claim so that similar claims can be grouped and the high-level scope easily understood.	The Criterion.conformityTopic property on each referenced criterion, referencing the Conformity Topics taxonomy
07	Metrics	The DFR MUST provide a simple mechanism to quantify a performance claim (eg carbon intensity, water consumption) using either a numeric measure with tolerance, or a categorical score, or both.	The Performance class with metric (from the Performance Metrics taxonomy), measure (value + unit), score (code + rank), and the alternative outcome forms described in the Conformity Credential
08	Criteria	The DFR MUST provide a means to reference a standard or regulation as well as the specific criteria within that standard or regulation — so that claims can be understood in terms of the criteria against which they are made.	Claim.referenceCriteria, Claim.referenceRegulation, and Claim.referenceStandard
09	Evidence	The DFR MUST provide a means to reference independent conformity assessments that support and verify the claims being made. The related evidence SHOULD be digitally verifiable but MAY be a simple document or web page.	The Claim.evidence property links to a UNTP Digital Conformity Credential (DCC) or other supporting document
10	Material usage	The DFR should provide a structure to describe the raw materials consumed by the facility over a reporting period, including origin country, mass fraction, recycled content, and hazardous material indicators.	The Facility.materialUsage property with MaterialUsage.materialConsumed array of Material objects
11	Reporting period	The DFR should support time-bounded reporting so that claims and material consumption can be attributed to a specific period, even when different data sources follow different reporting cycles.	The applicablePeriod property on both Claim and MaterialUsage, independent of the credential-level validFrom / validUntil
12	Address	The DFR should provide a structured postal address for the facility, distinct from its geographic coordinates.	The Facility.address property using the Address class
13	Alternative identifiers	The DFR should support listing additional facility identifiers from other schemes so that multiple registers and directories can resolve to the same facility record.	The Facility.facilityAlsoKnownAs array of identifier objects
14	Related documents	The DFR should provide a means to link to supporting documents such as environmental permits, site plans, or conformity credentials that are relevant to the facility but are not structured data within the credential.	The Facility.relatedDocument array of Link objects

Logical Model

A Digital Facility Record has two layers, which are easier to follow separately.

• The facility model: what the record says about the facility, covering its identity, where it is, who owns and operates it, what it consumes and what is claimed about its performance. This is an assembly of classes from the UNTP core vocabulary, and the part a site or ERP system maps onto.
• The credential envelope: who said it, when, and how a verifier can tell it has not been altered. This is the W3C Verifiable Credentials wrapper, identical for every UNTP credential type.

The two layers are independent of each other. A facility model describes a site whether or not it is ever signed, and the envelope will secure any subject. UNTP joins them by placing a Facility in the envelope's credentialSubject. Because facilities are long-lived and their performance data is refreshed, a DFR is re-issued over time, so the envelope's validity period does more work here than in a product passport.

The facility model

Each box is a class; each labelled arrow is a property, with its cardinality at the target end: 1 exactly one, 0..1 optional single, * any number. Properties whose values are plain text, numbers, dates or codes are listed inside the box; properties whose values are other objects appear as arrows. The class names are the type values that appear in the JSON, so Claim in the diagram is "type": ["Claim"] in a credential.

Everything in the diagram is defined in the Core Vocabulary and shared with other UNTP credential types. Party, Claim, Criterion, Measure, Link and the rest appear in product passports and conformity credentials too. Nothing in the facility model is unique to the DFR except the Facility class itself.

Facility, the credential subject. Three properties are mandatory: id, name and countryOfOperation. Everything else is optional.

Property	Type	Required	What it carries
id	URI	required	The facility identifier, ideally resolvable — see Facility Identifiers
name	string	required	The facility name as it is known to those who deal with it
countryOfOperation	Country	required	Where the facility operates, which is not always where its operator is registered
description	string		A short description of what happens at the site
registeredId	string		The identifier a register assigned to the facility, where one exists
idScheme	IdentifierScheme		The scheme that issued registeredId, identified rather than described in free text
processCategory	Classification *		What kind of processing happens here, coded against a published scheme
relatedParty	PartyRole *		The owner, the operator and any other party, each paired with the role it plays
relatedDocument	Link *		Links to permits, reports and other documents about the facility
facilityAlsoKnownAs	object *		Other identifiers for the same facility, each with its scheme — the upgrade path described in Facilities without a register entry
locationInformation	Location		Plus Code, point coordinates or a boundary polygon
address	Address		The postal address, which is a different thing from the location
materialUsage	MaterialUsage		What the facility consumed over a reporting period
performanceClaim	Claim *		Sustainability and conformity claims about the facility over that period

The supporting classes. PartyRole pairs a Party with the role it plays, which is why an owner and an operator can both appear without ambiguity. Location carries the site's geography, and is the place a precise geoBoundary belongs, rather than being copied into every downstream material description. MaterialUsage groups the Material inputs consumed in a stated Period, each with its originCountry, materialType classification, mass and recycled fraction. Claim is the assertion structure shared across UNTP: it references a Criterion from a Standard or Regulation, is classified by ConformityTopic, carries quantified Performance (a Measure, Score, determination or finding against a PerformanceMetric), and links to evidence, typically a Digital Conformity Credential. Classification, Country, IdentifierScheme, Measure, Address, Link and Image are shared value objects.

The credential envelope

The envelope is the W3C Verifiable Credential that carries the facility model. It contributes no facility data. Its job is to let a reader decide whether the record can be trusted, and when it was true.

Property	What it carries
issuer	The DID of the organisation making the assertions, anchored to a registered identity by a Digital Identity Anchor
validFrom, validUntil	The period over which the issuer stands behind the record — see Reporting Periods
credentialStatus	Where to check whether it has since been revoked
credentialSubject	The Facility — the facility model above
renderMethod	How to present it to a person
proof / JOSE signature	The cryptography that makes tampering detectable

How a verifier combines them

A verifier reads the envelope first and the facility model second. It checks the signature against the issuer's DID, resolves that DID to a Digital Identity Anchor to learn which registered organisation controls it, checks credentialStatus, and confirms the record was valid at the time that matters. The facility data becomes meaningful once it is attributable to a known organisation.

That last step carries more weight for a DFR than elsewhere, because facility records are superseded rather than corrected. A reader looking at a claim about last year's emissions needs the record that was current then, not the one that is current now.

Credential Schema

The full JSON Schema, the envelope wrapping the Facility subject, is the working version and a candidate for UNTP v1.0.0.

Loading schema viewer...

For detailed class and property definitions, see the Core Vocabulary reference.

Implementation Guidance

Who issues a DFR

A DFR is issued by the organisation that owns or operates the facility, by a parent company authorised to act for it, or by a software provider acting on their behalf — see identifier control and key custody in the Verifiable Credentials profile. The issuer identity SHOULD be anchored by a Digital Identity Anchor that recognises the issuer as the owner or operator of the facility, so that a verifier can tell an operator's own record from a third party's account of them.

The conceptual model describes manufacturers, producers and brands as issuers of UNTP credentials generally. That is not a licence for a brand to publish a facility record about its suppliers. A brand's assessment of a supplier's site is a conformity attestation about that facility, carried in a Digital Conformity Credential; a DFR is the facility speaking for itself.

This matters most for subcontractors working across several brands and platforms. A facility issues one DFR for a reporting period and lets every customer link to it, rather than a separate record per customer. Each customer's product passport references the same facility identifier, which resolves to the same record.

Where more than one record nonetheless exists for a facility — an operator's and a parent company's, say — the record linked from the facility's Identity Resolver entry is the one a verifier should treat as current, and relatedParty names the owner and operator roles behind it. A verifier comparing two records SHOULD prefer the one whose issuer is anchored as the facility's owner or operator.

Reporting Periods

Unlike a DPP, which is a performance snapshot of a specific product model, batch, or item, the DFR describes a long-lived facility. A DFR therefore describes facility performance over a defined period, and the performanceClaim array carries claims for that period, each with an applicablePeriod that makes the time range explicit.

UNTP sets no required reissuance cadence. Quarterly and annual cycles are common because they follow reporting obligations a facility already has, but they are illustrations, not requirements, and a facility that issues a DFR once and revises it when something material changes is conformant. What matters is that each DFR states the period it covers, so a reader can tell how current the data is and judge it accordingly. Issuing on a schedule the facility cannot sustain produces stale records that claim to be fresh, which is worse than an honest annual one.

The record's reporting period and a claim's applicablePeriod are independent. A facility may issue annually while a particular claim covers a harvest season, an audit cycle, or a single production campaign. Neither has to align with the other, and neither has to align with a calendar year:

"applicablePeriod": {
  "startDate": "2025-09-15",
  "endDate": "2026-01-31",
  "periodInformation": "2025/26 harvest season, from first delivery to end of processing."
}

A period that does not follow a calendar or fiscal year is not a data-quality problem and should not be treated as one. For agricultural and seasonal processing it is the honest period: averaging a harvest across a calendar year would describe something that never happened. What matters is that the period is stated, so a reader knows what the number covers.

In practice, reporting periods do not always align neatly across all data sources. Bulk material consumption may be reported on a calendar-year basis while a third-party conformity attestation covers a different audit cycle. For this reason, both MaterialUsage and Claim include an applicablePeriod property that can specify a precise date range, allowing each component to declare its own time boundaries independently of the credential's overall validFrom / validUntil dates.

Re-issuing a DFR

Updated performance data produces a new DFR instance, not an in-place mutation of the previous credential.

• The facility identifier (Facility.id) is unchanged. It identifies the facility, not a reporting period.
• Each DFR credential has its own id. A 2024 annual report and a 2025 annual report for the same smelter are two credentials.
• The Identity Resolver linkset for the facility SHOULD include all DFR links, with period or version metadata so a client can pick the relevant report (for example IANA predecessor-version as in Versioned targets, or title / date text that names the period).
• The linkset default (no linkType, or the facility's default dfr link) SHOULD be the current / latest DFR.

Revoking an earlier DFR is a status-list decision, not a reuse of the credential id.

Facility Identifiers

A DFR is discovered by downstream customers by resolving the facility identifier — for example, scanning a facility ID or looking it up in a register — to find the DFR via an Identity Resolver. Most facilities have multiple identifiers issued by different organisations: a national environmental register, a mining cadastre, an industry association membership number, and so on. The key insight is that each of these identifiers can resolve to the same DFR that the facility owner maintains and controls.

This architecture restores ownership of facility data to the natural owner — the facility operator — while allowing multiple registers and directories to link to it, like many different road signs pointing at the same city. In the DFR, the primary identifier is carried by Facility.id and Facility.registeredId, while additional identifiers are listed in the facilityAlsoKnownAs array.

Data Mapping

Implementers should map their existing facility data to a UNTP DFR following a similar approach to DPP data mapping:

Mapping Type	UNTP Pattern	When to use
Direct property	Named properties on Facility (e.g. id, countryOfOperation, processCategory, address, locationInformation, relatedParty)	The source attribute has a direct equivalent in the UNTP core vocabulary
Related document	Facility.relatedDocument — a Link to an external resource	Supporting documents such as environmental permits, site plans, or conformity credentials
Performance claim	Facility.performanceClaim — a Claim referencing a ConformityTopic, a PerformanceMetric, and optionally linked to a scheme criterion, an external standard, and/or relevant national regulations	Quantified sustainability metrics such as annual GHG emissions, water consumption, or recycled content
Separate credential	A UNTP Digital Traceability Event (DTE) or Digital Conformity Credential (DCC) linked from the DFR	Detailed mass-balance stocks and flows (DTEs) and independent third-party audits of those flows (DCCs) — data that UNTP recommends managing outside the DFR
No mapping	—	If you find a facility data requirement that cannot be mapped, please contact our mailing list so we can address it

Facilities without a register entry

Facility.id is any resolvable URI, and that includes a DID. A facility identifier MAY therefore be self-issued or issued by an aggregator on the operator's behalf, exactly as party and product identifiers already may be, without waiting for entry in a formal register.

This matters for artisanal and informal production. A smallholder processing site, an artisanal mine, or a cooperative's collection point often has no cadastre entry and no prospect of one soon, and a model that assumes formal registration excludes them from the supply chain it is meant to describe. A DID gives such a facility a verifiable identifier it controls — or that a cooperative, aggregator or software provider controls on its behalf under delegated key custody.

A self-issued identifier says less than a register-issued one, and a verifier should read it that way: it asserts that someone stands behind this facility record, not that an authority has recognised the facility exists. Where a register entry follows later, the facility keeps its original identifier and adds the register's identifier to facilityAlsoKnownAs with its idScheme, so historic credentials remain resolvable and the two identifiers are visibly the same site. Nothing has to be re-issued.

Claimed and unclaimed identifiers

A register may mint and maintain identifiers for facilities that have never interacted with it. An identifier is claimed once the facility owner or operator takes responsibility for the record it identifies, and unclaimed until then. The distinction, what a verifier may infer from each state, and how a subject claims an identifier a register minted for it are defined on the Identity Resolver page under claimed and unclaimed identifiers.

Applied to facility records, a conformant implementation:

• MUST issue a DFR as the facility owner or operator, or as a software provider acting on their behalf.
• MUST NOT issue a DFR for a facility whose identifier the operator has not claimed, if the issuer is the register that minted that identifier.
• MUST NOT create a decentralised identifier on behalf of a facility operator who has not claimed the corresponding facility identifier.

There is therefore no such thing as an unclaimed DFR: the record exists because its operator stands behind it, so no property is needed to signal the claim state of a record.

Geographic Anchoring

Every DFR should be geographically anchored via the locationInformation property, which supports three representations that can be used individually or in combination:

• A single coordinate (geoLocation) — a latitude/longitude point marking the facility location.
• A boundary (geoBoundary) — a sequence of coordinates defining the facility perimeter.
• A Plus Code (plusCode) — a Plus Code grid reference that can define areas at varying precision, from a precise point (e.g. 8Q7Q5G22+22) to a larger region by removing trailing digits.

The components of a DFR

This section provides sample JSON-LD snippets for each DFR component, drawn from the copper refinery sample credential.

Credential Envelope

All DFRs are issued as W3C Verifiable Credentials (VCDM 2.0). The credential type includes both VerifiableCredential and DigitalFacilityRecord, and the @context references both the W3C VCDM and UNTP context URIs. The issuer id SHOULD be a DID using a supported DID method, with issuerAlsoKnownAs linking to authoritative business register identifiers. The issuing party should be the facility owner or operator.

{
  "type": ["DigitalFacilityRecord", "VerifiableCredential"],
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://vocabulary.uncefact.org/untp/0.8.0/context/"
  ],
  "id": "https://credentials.sample-refinery.example.com/dfr/smelter-002",
  "issuer": {
    "type": ["CredentialIssuer"],
    "id": "did:web:sample-refinery.example.com",
    "name": "Sample Copper Refinery Co. Ltd",
    "issuerAlsoKnownAs": [
      {
        "id": "https://www.sample-register.example.com/henkorireki-johoto.html?selHouzinNo=REF-001",
        "name": "Sample Copper Refinery Co. Ltd",
        "registeredId": "REF-001",
        "idScheme": {
          "id": "https://www.sample-register.example.com",
          "name": "Japan Corporate Number (Houjin Bangou)"
        }
      }
    ]
  },
  "validFrom": "2025-01-15T00:00:00Z",
  "validUntil": "2028-01-15T00:00:00Z",
  "name": "Digital Facility Record — Sample Copper Refinery",
  "credentialSubject": {"type": ["Facility"], "...": "..."}
}

Facility Identification

The Facility credential subject identifies the facility via a resolvable URI (id), a registered identifier (registeredId), and an identifier scheme (idScheme). The facility id should be resolvable via an Identity Resolver that returns links to the DFR. The countryOfOperation carries the ISO 3166 country, and processCategory classifies operations using schemes such as UN CPC. Additional identifiers from other schemes can be listed in facilityAlsoKnownAs.

"credentialSubject": {
  "type": ["Facility"],
  "id": "https://facility-register.example.com/fac-002",
  "name": "Sample Copper Refinery",
  "description": "Copper smelting and electrolytic refining facility in Sample, Oita Prefecture, Japan.",
  "registeredId": "fac-002",
  "idScheme": {
    "id": "https://facility-register.example.com",
    "name": "UNTP Sample Facility Register"
  },
  "countryOfOperation": { "countryCode": "JP", "countryName": "Japan" },
  "processCategory": [
    {
      "type": ["Classification"],
      "code": "41521",
      "name": "Unwrought copper",
      "idScheme": {
        "type": ["IdentifierScheme"],
        "id": "https://unstats.un.org/unsd/classifications/Econ/cpc/",
        "name": "UN Central Product Classification (CPC)"
      }
    }
  ],
  "facilityAlsoKnownAs": [
    {
      "id": "https://prtr.example.go.jp/facilities/JP-44-SM-0021",
      "name": "Sample Copper Refinery",
      "registeredId": "JP-44-SM-0021",
      "idScheme": {
        "id": "https://prtr.example.go.jp",
        "name": "Japan PRTR Facility Register"
      }
    }
  ]
}

Related Parties

The relatedParty array identifies organisations associated with the facility in defined roles (e.g. owner, operator). Each PartyRole links to a Party with verifiable identifiers, registration country, address, and industry classification.

"relatedParty": [
  {
    "role": "owner",
    "party": {
      "type": ["Party"],
      "id": "did:web:sample-refinery.example.com",
      "name": "Sample Copper Refinery Co. Ltd",
      "registeredId": "REF-001",
      "idScheme": {
        "id": "https://www.sample-register.example.com",
        "name": "Japan Corporate Number (Houjin Bangou)"
      },
      "registrationCountry": { "countryCode": "JP", "countryName": "Japan" },
      "partyAddress": {
        "streetAddress": "3-1 Sample, Usuki",
        "postalCode": "879-2201",
        "addressLocality": "Oita",
        "addressRegion": "Oita Prefecture",
        "addressCountry": { "countryCode": "JP", "countryName": "Japan" }
      },
      "organisationWebsite": "https://sample-refinery.example.com"
    }
  }
]

Related Documents

The relatedDocument array provides links to supporting resources such as conformity credentials, environmental reports, or permits. Each Link includes a URL, human-readable name, media type, and a link type from a controlled vocabulary.

"relatedDocument": [
  {
    "linkURL": "https://credentials.sample-cab.example.com/dcc/smelter-002",
    "linkName": "Coppermark Certification — Sample Copper Refinery",
    "mediaType": "application/ld+json",
    "linkType": "https://test.uncefact.org/vocabulary/link-type/dcc"
  }
]

Location

The locationInformation property locates the facility geographically. It supports three representations, at least one of which should be provided:

• A Plus Code — a grid reference that can define areas from a precise point to a large region.
• A geoLocation as a decimal latitude/longitude point.
• A geoBoundary as a sequence of latitude/longitude pairs defining the facility boundary.

The address property provides a structured postal address.

"locationInformation": {
  "plusCode": "https://plus.codes/8Q7Q5G22+22",
  "geoLocation": { "latitude": 33.25, "longitude": 131.88 },
  "geoBoundary": [
    { "latitude": 33.24, "longitude": 131.87 },
    { "latitude": 33.26, "longitude": 131.89 }
  ]
},
"address": {
  "streetAddress": "3-1 Sample, Usuki",
  "postalCode": "879-2201",
  "addressLocality": "Oita",
  "addressRegion": "Oita Prefecture",
  "addressCountry": { "countryCode": "JP", "countryName": "Japan" }
}

Material Usage

The materialUsage property describes the raw materials consumed by the facility over a reporting period. Each Material includes its origin country, classification, mass fraction of total input, absolute mass, recycled content fraction and hazardous indicator.

originCountry answers which country did this input come from, and no more. It is deliberately not a geo-risk locator: making it finer would not make a deforestation or land-tenure claim verifiable, because the risk attaches to a place and a practice rather than to a material description.

Those cases are served by the pieces that already exist. The facility carrying out the work publishes its own location, including a precise geoBoundary where that is what the use case needs, and makes a performance claim against the relevant criterion, with evidence. An upstream farm or mine is itself a facility, with its own record and its own boundary, referenced from the supply chain that consumed its output. That keeps the precise location with the party that can actually attest to it, rather than copying coordinates into every downstream material description where nobody can verify them.

"materialUsage": {
  "applicablePeriod": {
    "startDate": "2024-01-01",
    "endDate": "2024-12-31",
    "periodInformation": "Calendar year 2024 reporting period."
  },
  "materialConsumed": [
    {
      "name": "Copper concentrate",
      "originCountry": { "countryCode": "ZM", "countryName": "Zambia" },
      "materialType": {
        "type": ["Classification"],
        "code": "14110",
        "name": "Copper ores and concentrates",
        "idScheme": {
          "type": ["IdentifierScheme"],
          "id": "https://unstats.un.org/unsd/classifications/Econ/cpc/",
          "name": "UN Central Product Classification (CPC)"
        }
      },
      "massFraction": 0.85,
      "mass": { "value": 420000000, "unit": "KGM" },
      "recycledMassFraction": 0,
      "hazardous": false
    },
    {
      "name": "Coke (reducing agent)",
      "originCountry": { "countryCode": "AU", "countryName": "Australia" },
      "materialType": {
        "type": ["Classification"],
        "code": "33100",
        "name": "Coke and semi-coke",
        "idScheme": {
          "type": ["IdentifierScheme"],
          "id": "https://unstats.un.org/unsd/classifications/Econ/cpc/",
          "name": "UN Central Product Classification (CPC)"
        }
      },
      "massFraction": 0.10,
      "mass": { "value": 50000000, "unit": "KGM" },
      "recycledMassFraction": 0,
      "hazardous": false
    }
  ]
}

Performance Claims

The performanceClaim array carries the facility operator's self-declared sustainability claims for a reporting period. Each Claim references criteria classified by a ConformityTopic from the Conformity Topics taxonomy and carries quantified performance using a PerformanceMetric from the Performance Metrics taxonomy. Unlike product-level claims, facility claims typically report annual totals (e.g. total Scope 1 emissions in tonnes) rather than per-unit intensities. Claims SHOULD link to independent conformity assessments as evidence. See Claims and Assessments for guidance on criteria, topics and metrics.

Performance can be expressed as a numeric measure, a categorical score, a determination or a qualitativeFinding, the same four properties a conformity credential uses. They mean the same things, but a claim here is self-declared: a determination of pass is the operator's own judgement about its own facility, not an independent finding. Where independent assurance matters, a verifier should read the determination in the linked conformity credential rather than this one.

"performanceClaim": [
  {
    "type": ["Claim"],
    "id": "https://sample-refinery.example.com/claims/ghg-2024",
    "name": "GHG Emissions — Scope 1",
    "description": "Annual Scope 1 greenhouse gas emissions from the Sample Copper Refinery for the 2024 reporting year.",
    "referenceCriteria": [
      {
        "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"
          }
        ]
      }
    ],
    "claimDate": "2025-03-01",
    "applicablePeriod": {
      "startDate": "2024-01-01",
      "endDate": "2024-12-31"
    },
    "claimedPerformance": [
      {
        "metric": {
          "id": "https://vocabulary.uncefact.org/performance-metrics/scope-1-ghg-emissions",
          "name": "Scope 1 GHG Emissions"
        },
        "measure": { "value": 120000, "unit": "TNE" }
      }
    ]
  }
]

Referencing Conformity Criteria

Claims SHOULD unambiguously reference a criterion from a recognised scheme, standard, or regulation using a URI. This shared reference is what allows independent conformity assessments to verify facility operator claims — both reference the same criterion. Issuers can discover the right criterion URIs via the UNTP Conformity Vocabulary Catalog.