Research libraryTraceable by Design
Chapter 10 of 14 · Part III · Draft web edition
Cryptography can preserve an assertion and identify its signing authority, but accepting a textile claim still requires physical evidence and an explicit trust policy.
The cloth is woven from this chapter's 4 exhibits: each weft is one exhibit's own data, normalised; each warp group is a section. The probe reads the exhibit's own value where it crosses. Procedural visualisation, not a measurement.
Read-out
Illustrative policy map. Negative and positive positions mean failed or unsupported and passed or supported respectively. Coordinates are arbitrary placements, not probabilities, scores or observed GFT results. Technical acceptance includes the required policy checks.
Unit: illustrative categorical positions. Status: illustrative. Sources: S1001, S1002. Illustrative figures are teaching examples, not measured factory results.
Overture · 1 min
A digital signature should preserve accountability for a claim without becoming a substitute for investigating it. GFT recommends separate decisions for technical verification, evidence admissibility and commercial claim release. W3C explicitly distinguishes credential verifiability from the truth of its claims.[S1001] For cotton provenance, the practical consequence is straightforward: an authorised signature over an unsupported origin declaration remains an unsupported declaration. The proposed control system must identify who asserted what, establish the evidence boundary and record who accepted that boundary. This chapter specifies those controls as design recommendations, not as a description of a deployed GFT service.
10.1
Related · chapter 049 paragraphs step it
Read-out
Illustrative role map. Horizontal position represents the role's typical direct responsibility for physical observation in the hypothetical arrangements; vertical position represents its typical authority over the commercial ownership decision. Coordinates are qualitative teaching positions, not measured scores, legal determinations or universal role definitions.
Unit: illustrative qualitative index (0 to 10). Status: illustrative. Sources: S01, S09, S10. Illustrative figures are teaching examples, not measured factory results.
Read this exhibit in its chapter ↗The W3C credential model distinguishes the issuer that makes claims, the holder that retains or presents credentials, and the verifier that evaluates them.[S1001] In a proposed cotton transaction these roles might belong to a ginnery, a trader and a buyer respectively. That mapping is illustrative, not a required organisational structure. GFT would require a role map for each workflow because the party presenting a declaration may have neither observed the cotton nor performed the assessment. A transport intermediary carrying an authentic document should not acquire authority to extend its conclusions.
Consider an illustrative origin declaration signed by a genuine processing organisation using its properly controlled key. The declaration identifies the intended lint lot, passes technical checks and states that the cotton was grown in Cameroon. The receiving dossier, however, contains an unresolved substitution between the inbound bale group and the recorded production input. GFT's proposed decision is to retain the signed assertion as evidence of what the organisation said, place the origin claim on hold and investigate the substitution. The signature provides an accountable starting point. It cannot supply the missing physical connection.
The converse case matters too. A warehouse may possess credible receiving and production documents while its digital credential has an invalid proof. GFT would reject that credential for automated acceptance, preserve the underlying dossier and seek an authorised replacement. The physical claim might eventually be supported through another approved channel. This distinction prevents technical failure from being misreported as proof of false origin. It also prevents commercial urgency from being used to excuse a failed digital control. The incident record should say which question remains unresolved.
The proposed issuer trust policy is a governed register, with an accountable policy owner and an effective version. Each entry should bind a stable digital identifier to a checked legal entity, authorised facilities, permitted claim classes and evidence obligations. Admission should state who checked the business identity, who granted the authority and how a buyer can challenge it. A record for dispatch acknowledgements should not automatically authorise environmental assessments or statements about farms beyond the issuer's documented knowledge. Trust must be granted to a defined activity rather than to an attractive organisation name.
GFT further recommends recording the custody model, material and geographic scope, validity conditions, suspension route and appeal owner alongside each permission. An issuer may be accepted for a receiving observation while remaining unapproved for a consumer origin statement. An assessment body should have its assessment scope checked separately from the manufacturer's own declaration. The working UN Transparency Protocol conformity model assigns issuance to the conformity assessment body and distinguishes assessment and authority information. It is a pre-production specification, not evidence of legal recognition or of any organisation's competence.[S29]
The proposed policy should also state what happens when authority changes. A merger, facility transfer or withdrawn assessment scope should trigger review of the affected permission, rather than automatic inheritance by the next organisation controlling the identifier. GFT recommends retaining both the earlier admission evidence and the decision authorising the new relationship. Buyers should receive a clear boundary for continued reliance. This requirement concerns permission to make a claim; it does not presume that a business change invalidates all previously recorded physical observations.
The illustrative positions in Exhibit 42 make the separation visible. The coordinates are categorical placements, not measured reliability scores. Their purpose is to stop a single green verification symbol from merging independent judgements.
Even the supported and technically accepted position means consider release rather than automatic approval. GFT's proposed release owner must still check the intended wording, product boundary and buyer use. Evidence supporting a lot-level statement should not be silently extended to every item after an unrecorded transformation. The diagram diagnoses decision categories; it neither certifies a product nor resolves the custody modelling questions treated elsewhere in this paper.
10.2
Preserve credential
Preserve credential. Starting point. Leads to Run technical checks. · illustrative
W3C Data Integrity distinguishes proof purpose from the verification relationship that authorises a key for that purpose.
Run technical checks
Run technical checks. From Preserve credential. Leads to If pass: review evidence. · illustrative
If pass: review evidence
If pass: review evidence. From Run technical checks. Leads to Release, reject or pending. · illustrative
Release, reject or pending
Release, reject or pending. From If pass: review evidence. End point. · illustrative
Illustrative conditional procedure. Stop if a required check fails or is unavailable. Failed requirements mean rejection; unavailable dependencies or missing evidence mean pending. Only technical acceptance and supported evidence permit release. Not a certification rule or implemented verifier.
Unit: illustrative decision sequence. Status: illustrative. Sources: S1001, S1002, S1003. Illustrative figures are teaching examples, not measured factory results.
10.2 · the bodyExhibit 43 above; its figures are illustrative where marked.
W3C Data Integrity distinguishes proof purpose from the verification relationship that authorises a key for that purpose. A key's presence in an identifier document alone is insufficient. The verifier must check that its authorised relationship matches the intended use.[S1002] GFT's proposed implementation checklist should therefore name the supported securing mechanism and document profile before procurement. It should reject unsupported mechanisms explicitly rather than attempting an improvised conversion that changes what was protected. A successful library operation is an input to acceptance, not the whole acceptance procedure.
GFT proposes a staged checklist recorded as individual results. Intake should preserve the received object and its identifier, identify the requested action and select the applicable policy version. Structural checks should confirm the supported credential type, required fields and interpretable units. Identity checks should resolve the issuer through the approved trust route and establish the relevant permission. Proof checks should use the supported implementation, check the declared purpose and verification relationship, and retain a useful diagnostic. These are proposed operating requirements, not claims that a particular software package implements them.
The checklist should then test the relevant validity period and status under the chosen profile. W3C's status-list specification provides a mechanism for publishing suspension or revocation information; it does not decide a buyer's commercial acceptance policy.[S1003] GFT recommends recording the list issuer, authenticated status result, retrieval time and permitted age. A credential without a status mechanism is not automatically defective under every possible profile. It should nevertheless fail the proposed workflow if that workflow requires withdrawable assertions. The required control must be declared before a transaction reaches the release desk.
Evidence checks should bind the signed proposition to the specific physical subject. GFT proposes matching lot identifiers, material description, relevant period, site and input-output references. Where a credential protects only a reference to a document, the reviewer should determine whether the referenced content is bound to that reference and whether it remains retrievable. An accessible attachment is not automatically the attachment originally assessed. The evidence owner should retain the reviewed version and the reason for accepting it. The release decision should cite that version rather than whichever document later occupies the same web address.
The proposed control flow in Exhibit 43 gives uncertainty its own destination. A failed signature is different from an unavailable status service, while an unsupported origin claim is different from either. The flow is an operating design and deliberately leaves implementation detail to the selected credential profile.
An illustrative offline receiving workflow may preserve the document and permit physical unloading into a controlled holding area while online checks remain pending. That permission should be an explicit operational decision, not a claim that the origin was verified. Before claim release, the reviewer would complete the missing checks, reconcile any changed status and record the approved wording. Commercial movement, inventory posting and public disclosure need distinct permissions so that an outage does not force an all-or-nothing decision about the material.
For the proposed reviewer interface, the first question should be the intended decision: receive material, acknowledge a transfer or publish an origin statement. The interface should then display the requirements for that action and the evidence already available. A technical pass should remain visible beside an unresolved physical link. A reviewer should be able to request missing evidence without changing the signed assertion. This keeps the original statement available for investigation and prevents a corrected screen label from disguising an uncorrected evidence gap.
GFT recommends retaining the checker version, policy version, decision time, dependency references and reason codes in the decision record. A later reviewer should be able to distinguish an authentic technical pass from an operator override. Repeating the procedure with the same preserved evidence should explain the earlier result, even if current policy produces a different result. The acceptance log should expose that difference instead of editing the earlier decision to look as though the new rule had always applied.
10.3
A decentralised identifier can associate a subject with an identifier document and verification methods. W3C makes the method specification responsible for important operational details, so the identifier prefix alone does not establish a complete recovery service.[S1004] GFT would treat DID support as an optional design choice. Procurement should identify the exact method, permitted updates, resolution dependencies and available historical information. Calling a design decentralised should not replace a demonstration that the buyer can discover which authority controlled an issuer identifier when a disputed assertion was made.
An illustrative managed-register option would place issuer admission and identifier-to-key bindings under an agreed operator. A DID-based option would obtain control information using the selected method and then apply the same business admission policy. GFT recommends comparing these options against the actual counterparties' ability to resolve identities, replace keys and export evidence. Neither route should be assumed to identify a legal business without a separate identity check. The trust register must record the relationship between technical control and the organisation authorised to make the commercial assertion.
A published research preprint examines using DIDs and verifiable credentials for passport management and reports evaluating performance in selected scenarios. Its abstract supplies a research hypothesis for comparison, not field evidence for a Cameroonian cotton chain.[S1008] GFT would require a bounded demonstration using the intended issuer and buyer workflows before selecting either approach. The demonstration should include a lost signing device, a changed service provider and a disputed historical document. A favourable result on ordinary issuance should not compensate for failure to recover the records needed to defend an earlier transaction.
The proposed key-custody register should distinguish the organisation responsible for issuing assertions, the operator of the signing service and the authority permitted to change its configuration. It should record authorised uses, backup arrangements, replacement procedure and the person or role accountable for incident escalation. GFT recommends keeping issuance keys separate from ordinary user login credentials and restricting administrative actions independently from routine document preparation. These are design controls to specify and test, not assertions about the security of an unidentified hosting platform.
Rotation should be rehearsed as a business event. The proposed exercise would issue a test assertion, rotate the key through the approved process, issue another assertion and ask an independent reviewer to reconstruct both decisions. The reviewer should receive the relevant trust-register versions and controller evidence. Historical checking must not depend on silently treating today's key as yesterday's authority. GFT would document whether the selected method supports the necessary historical view and what additional archived records are required where it does not.
Recovery creates a separate authority question. If the person who lost a device can also approve a replacement without further evidence, an attacker may gain a route around the signing control. GFT therefore proposes a documented recovery request, an independent identity and authority check, controlled replacement and notification through an established counterparty channel. The procedure should preserve the old identifier relationship where justified and record any discontinuity. A recovered account must not retrospectively make questionable assertions acceptable merely because a new key is now available.
Interlude · the cloth half-woven
Woven: sections 10.0 to 10.3Still to weave: 10.4 to 10.6
10.4
Issue assertion
0: Issue assertion. Preserve evidence · illustrative
Suspension and revocation concern the acceptability of a credential under its governing rules.
Possible compromise
2: Possible compromise. Investigate interval · illustrative
Buyer accepts
4: Buyer accepts. Record policy and status · illustrative
Discover incident
5: Discover incident. Contain issuance · illustrative
Publish status
6: Publish status. Notify affected buyers · illustrative
The method behind it: Worked example: an authentic quantity can exceed its evidence boundary.
Illustrative incident chronology, not observed events or recommended response deadlines. Day 0 is a chosen reference. Day 2 is an assumed earliest plausible compromise; the actual start could remain unknown. Day 5 is discovery and day 6 is status publication.
Unit: illustrative elapsed day. Status: illustrative. Sources: S1003, S1004. Illustrative figures are teaching examples, not measured factory results.
10.4 · the bodyExhibit 44 above; its figures are illustrative where marked.
Suspension and revocation concern the acceptability of a credential under its governing rules. They should be distinguished from expiry, issuer removal and the technical failure of a proof. W3C's bitstring design supports publication of credential status and discusses verifier caching and privacy considerations.[S1003] GFT recommends a status policy that states which authority publishes each status, what each value means and how changes affect outstanding claims. A buyer should not have to guess whether an unavailable declaration was withdrawn, temporarily suspended or simply inaccessible.
The proposed historical review separates event occurrence, assertion issuance, verification and later discovery. A credential may have been accepted under the available information before a compromise was detected. That historical acceptance is a fact about a decision, not conclusive evidence that its physical claim was true. Equally, discovering a compromised key does not establish that every earlier document was fabricated. GFT would quarantine the affected set according to the best supported compromise interval, retain the uncertainty about its start and commission a claim-specific review before deciding what can be restored.
The illustrative sequence in Exhibit 44 uses elapsed days solely to make ordering inspectable. Discovery occurs after the possible start of compromise. The timeline therefore prevents an investigator from equating the discovery timestamp with the first unsafe signature.
GFT proposes preserving the original assertion, evidence dossier, status observation and acceptance record when a later correction occurs. A correction should identify the superseded claim, state the reason and show the replacement's narrower or changed boundary. If evidence remains unavailable, the replacement should say so. Renewing a signature over the same unsupported statement is not remediation. The affected buyer needs to know whether the material may still move, whether the claim may still be used and which further review is required.
A proposed dispute procedure should preserve the difference between withdrawing reliance and deleting evidence. The issuer may dispute the buyer's interpretation, while the buyer may need to suspend public wording during investigation. GFT would give the dispute a reference, identify the contested proposition and appoint a review owner with the necessary independence. The outcome should record which documents changed the decision and whether affected recipients were informed. Reopening a claim requires an accountable decision, even when the original issuer objects to the hold.
GFT recommends permitting cached status only for actions and durations stated in advance by the policy owner. A cache record should show when it was retrieved, what it covered and why its use was permitted. The proposed default during an unplanned status outage is to restrict final claim release until fresh acceptance evidence is available. A business choosing another rule must document the consequence it accepts and disclose the status boundary to the reviewer. This is a proposed risk decision, not a universal requirement of the status-list standard.
10.5
NIST describes blockchains as distributed, tamper-evident and tamper-resistant ledgers, with transaction persistence under normal operation.[S1005] GFT's engineering inference is that preserving a recorded assertion cannot improve the truth of the original physical observation. A ledger could faithfully retain the illustrative false origin statement described earlier. The purchasing question is therefore which shared control the participants require, who operates it and what failure it addresses. The answer should name a business obligation before it names a preferred storage technology.
An illustrative controlled database is appropriate for evaluation where an agreed operator can maintain the authoritative register and the participants accept that operator's governance. Signed exports provide another candidate where counterparties need portable snapshots for independent checking. A permissioned ledger becomes a candidate where participants need shared write governance and can sustain the associated membership and recovery arrangements. GFT does not assign a cost or performance ranking without a measured workload, a dependency map and contractual responsibility for the service.
The comparison in Exhibit 45 is an illustrative procurement worksheet rather than a benchmark. Each option still requires evidence review and an accountable release decision. More distributed storage does not eliminate the need for an authority to resolve disputed cotton claims.
Read-out
| Controlled database | Accepted register operator | Audit, restore and export |
|---|---|---|
| Signed exports | Portable assertions | Version, status and retrieval |
| Permissioned ledger | Shared write governance | Membership, dispute and exit |
Illustrative GFT comparison informed by the NIST ledger overview and supply-chain risk overview. No price, throughput, legal status or deployment result is asserted. Verify each feature for the actual product and contract.
Unit: illustrative procurement questions. Status: illustrative. Sources: S1005, S1007. Illustrative figures are teaching examples, not measured factory results.
GFT proposes correction by addition of a governed superseding record. The original assertion should remain available to authorised investigators, with a clear relationship to the replacement and a visible current acceptance state. A user reading the current passport should not be directed towards a withdrawn claim merely because the original link still works. The system should distinguish retained history from current permission to rely on that history. This design recommendation applies to a database with an audit history as well as to a shared ledger.
For a procurement trial, GFT would ask every candidate to complete the same sequence: ingest an assertion, verify it independently, withdraw it, publish a correction, export the complete evidence set and restore the acceptance history in a separate environment. Record dependency failures and operator intervention. Success should mean that another authorised reviewer can explain the current claim and reconstruct the earlier decision. The build-or-buy comparison should use these observed outcomes, alongside measured operating effort, rather than treating a cryptography label as a performance result.
GFT would also require an exit rehearsal before relying on a shared service. The proposed test should export records in an agreed readable format, identify missing attachments and demonstrate verification without the departing provider's privileged account. The receiving operator should show how current status, superseded claims and access restrictions survive the move. A successful file download alone would not satisfy this requirement. If the exported record cannot explain which assertion a buyer accepted, the migration has preserved storage without preserving the decision evidence.
The proposed storage boundary should keep personal and commercially sensitive records in governed repositories with purpose-specific access. Public references should expose only what the claim requires. A hash or identifier should not be assumed harmless merely because its original attachment is private. GFT would review whether repeated references reveal counterparties or allow records about individuals to be linked. This is a design precaution; the appropriate retention and disclosure duties require separate legal assessment. This chapter provides no investment, legal or tax advice and does not establish regulatory conformity.
10.6
Related · chapter 099 paragraphs step it
Read-out
Illustrative GFT procedure informed by resolver functions and supplier-risk guidance. Proceed only after readback passes; retain the existing route or publish an explicit status notice if safe continuity cannot be demonstrated.
Unit: proposed continuity steps. Status: illustrative. Sources: S13, S27. Illustrative figures are teaching examples, not measured factory results.
Read this exhibit in its chapter ↗NIST's zero-trust overview separates authentication and authorisation and rejects implicit trust based solely on network location or asset ownership.[S1006] GFT applies that principle to a proposed issuance workflow: being inside a factory network should not grant permission to approve an origin claim. The data preparer, signing service administrator and claim release owner need distinct permissions wherever the operating structure permits. Exceptions should identify the combined responsibilities and compensating review rather than pretending that a small team has separation it cannot actually sustain.
The incident procedure should begin with a clear decision tree. Is there credible evidence of key or issuer-account compromise? If so, GFT recommends pausing the affected issuance route, preserving logs, invoking the approved status mechanism and opening a historical review. If the key remains controlled but a physical label has been copied, isolate the object-to-record problem and avoid withdrawing unrelated credentials without evidence. If the resolver or domain is unavailable, restrict dependent release decisions and activate the tested continuity route. Several branches may apply together; the incident owner should record that overlap explicitly.
For an illustrative compromised-key incident, the security owner would contain the signing route and protect recovery access. The evidence owner would identify assertions within the suspect interval and gather preserved dossiers. The claim owner would decide which statements require temporary withdrawal, narrower wording or reissue after review. The buyer communication owner would send the approved account through an established channel, distinguishing confirmed facts from open questions. An operational team should practise these handovers before a live dispute so that uncertainty about authority does not delay containment.
For an illustrative copied-label incident, the warehouse or dispatch owner would identify the affected physical units and preserve the observed label and transaction context. The verifier owner would determine whether the credential itself remains authentic. The claim owner would investigate the association between object and record before authorising further use of the label. A valid record attached to an unverified object should remain insufficient for release. The communication should explain the object-binding uncertainty, rather than inaccurately describing the event as a failed signature or alleging misconduct without an investigation.
An abandoned domain or departing service provider creates a different continuity problem. NIST's supply-chain risk guidance addresses identifying, assessing and mitigating cybersecurity risks across acquired products and services.[S1007] GFT proposes named ownership of domain renewal, provider exit, evidence export and restoration testing. The continuity owner should hold a readable issuer-register export, the relevant historical key information, status records and the claim decision history. A replacement service must preserve the ability to explain prior assertions; simply loading current product descriptions would leave historical acceptance unreviewable.
The proposed buyer notice should identify the affected claim, the material or product scope, the reason for the restriction and the next decision owner. It should distinguish an investigated finding from a precaution taken because information is missing. The notice should avoid unnecessary producer or worker details and should not expose private signing material. GFT recommends keeping an approved notice with the incident record and recording the channel used for each affected counterparty. Delivery evidence is separate from drafting the message or making a public status change.
After containment, the incident owner should commission a retrospective that tests the control rather than merely closing the ticket. Did the team identify the complete suspect set? Could the reviewer reconstruct the earlier acceptance? Did recovery restore the appropriate permissions without extending them? GFT proposes using the answers to revise the issuer policy, checker requirements and rehearsal cases. A resumed service proves availability; the separate claim review must establish what can again be stated about the cotton.
The pilot should test the decision tree with deliberately incomplete evidence, not merely a successful demonstration credential. GFT proposes asking an independent reviewer to assess a supported assertion, a correctly signed unsupported assertion, a wrong-purpose proof, stale status, a lost issuer key and a copied label. The reviewer should see which branch was taken and why, without receiving unrestricted personal records. A useful failure report states the action withheld, the evidence needed and the responsible owner. It does not convert an unknown result into either acceptance or an accusation.
Handover to wider governance and infrastructure work should preserve these requirements as acceptance criteria. Identity resolution must have an owner and a tested recovery route. Credential checking must expose pending and failed states. The evidence dossier must remain reconstructible after correction or supplier exit. Claim release must identify its authority and boundary. GFT would recommend scaling only after the pilot demonstrates these behaviours and an independent reviewer can reconstruct adverse cases. Until then, the material here remains a proposed trust system, not a qualified operating result.
Check the record
Every knot is a source this chapter cites; select one to read its record, or filter the register by grade. Publication dates and inherited-source limits stay explicit. Read the paper's full evidence summary.
9 sources · 20 citation marks on this pageMost cited: S1001, 3 times
Grade AGrade BGrade CKnot size: citations on this page
All 9 records shown
c10-S1001 · Grade A
Verifiable Credentials Data Model v2.0
Verifiability of a credential does not imply the truth of claims encoded therein.
2025-05-15. Register access date: 2026-10-30. Source provenance is supplied by the paper evidence register.
Open the recorded source ↗c10-S1002 · Grade A
Verifiable Credential Data Integrity 1.0
A proof that describes its purpose helps prevent it from being misused for some other purpose.
2025-05-15. Register access date: 2026-10-30. Source provenance is supplied by the paper evidence register.
Open the recorded source ↗c10-S1003 · Grade A
Bitstring Status List v1.0
There are a variety of privacy and performance considerations that are made when designing, publishing, and processing status lists.
2025-05-15. Register access date: 2026-10-30. Source provenance is supplied by the paper evidence register.
Open the recorded source ↗c10-S1004 · Grade A
Decentralized Identifiers (DIDs) v1.0
Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity.
2022-07-19. Register access date: 2026-10-30. Source provenance is supplied by the paper evidence register.
Open the recorded source ↗c10-S1005 · Grade A
NIST IR 8202: Blockchain Technology Overview
This document provides a high-level technical overview of blockchain technology.
2018-10. Register access date: 2026-10-30. Source provenance is supplied by the paper evidence register.
Open the recorded source ↗c10-S1006 · Grade A
NIST SP 800-207: Zero Trust Architecture
Authentication and authorization (both subject and device) are discrete functions performed before a session to an enterprise resource is established.
2020-08. Register access date: 2026-10-30. Source provenance is supplied by the paper evidence register.
Open the recorded source ↗c10-S1007 · Grade A
NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
Include critical suppliers in contingency planning, incident response, and disaster recovery planning and testing.
2024-11-01. Register access date: 2026-10-30. Source provenance is supplied by the paper evidence register.
Open the recorded source ↗c10-S1008 · Grade B
Digital Product Passport Management with Decentralised Identifiers and Verifiable Credentials
ESPR settles a set of requirements in collecting and administering product-related data.
2024-10-21. Register access date: 2026-10-30. Source provenance is supplied by the paper evidence register.
Open the recorded source ↗c10-S29 · Grade C
Conformity Credential
The issuing party should be the conformity assessment body (CAB).
2026-10-30. Register access date: 2026-10-30. Source provenance is supplied by the paper evidence register.
Open the recorded source ↗S1001 World Wide Web Consortium. 2025-05-15.
S29 UNECE / UN Transparency Protocol. 2026-10-30.
S1002 World Wide Web Consortium. 2025-05-15.
S1003 World Wide Web Consortium. 2025-05-15.
S1004 World Wide Web Consortium. 2022-07-19.
S1008 Ismael Illán García et al. / arXiv. 2024-10-21.
S1005 National Institute of Standards and Technology. 2018-10.
S1007 National Institute of Standards and Technology. 2024-11-01.
S1006 National Institute of Standards and Technology. 2020-08.
Keep the thread · chapter 10 of 14
Move the shuttle along the rack to preview any chapter: its sections, exhibits and reading time. Draft web edition. This research is not investment, legal or tax advice; illustrative models are not measured factory results.
The paper's rack · 14 boltsBolt length: reading time
01Part I: Claims must match the chain
GFT argues that provenance becomes useful when custody controls preserve the evidence behind a saleable claim.
02Part I: Claims must match the chain
Select the custody model by the attribute that must survive, then design operations to maintain that attribute.
03Part I: Claims must match the chain
An origin claim needs a defined producer boundary and a documented link from receipts to ginned fibre.
04Part II: Every transformation needs a record
A shipment is traceable only when dispatch and receipt refer to the same material and discrepancies remain visible.
05Part II: Every transformation needs a record
Each production step must preserve enough input-output linkage to support the claim carried by its outputs.
06Part II: Every transformation needs a record
Physical stock, processing yield and eligible claims need related but separate accounts.
07Part II: Every transformation needs a record
Assurance is credible when its issuer, scope, validity and sampling limitations remain attached to the claim.
08Part III: Passports must preserve evidence
Interoperability requires common semantics, stable identifiers and a tested way to exchange corrections.
09Part III: Passports must preserve evidence
A useful passport identifies its product, states who makes each claim and reveals the limits of the supporting evidence. Proposed fields must remain distinct from future legal requirements.
10Part III: Passports must preserve evidence
Cryptography can preserve an assertion and identify its signing authority, but accepting a textile claim still requires physical evidence and an explicit trust policy.
11Part III: Passports must preserve evidence
A system survives only if responsibilities, exceptions, privacy and constrained connectivity are part of ordinary work.
12Part IV: Scale follows demonstrated control
Compare the cost of producing admissible evidence with bounded benefits rather than an assumed premium.
13Part IV: Scale follows demonstrated control
Pilot success requires adverse cases, reproducible evidence and independently reviewed release decisions.
14Part IV: Scale follows demonstrated control
GFT recommends a staged programme in which every expansion follows demonstrated control of evidence, quantities and disclosure.