LESSON 6: EVIDENCE OBJECTS AND VERIFICATION STRUCTURES

Lesson Overview

This lesson covers evidence objects and verification structures for Digital Product Passport implementations. Students will learn about evidence object overview, certificates, test reports, inspection reports, declarations, verification structures, audit evidence, evidence linking, evidence schema design, and evidence data quality. The lesson provides practical guidance on modeling the verification and compliance data that supports DPP credibility and regulatory compliance.

Learning Objectives

• Design effective evidence object structures
• Model certificates and certification data
• Implement test report structures
• Design inspection report models
• Model declarations of conformity
• Implement verification structures
• Design evidence linking and references
• Create evidence schemas with validation
• Ensure evidence data quality

Detailed Content

Evidence Object Overview

Evidence objects represent the documents, certificates, test reports, and other verification artifacts that support claims made in Digital Product Passports. Effective evidence modeling enables verification of compliance, establishment of trust, and support for regulatory audits. Evidence is the foundation of DPP credibility.

Evidence Purpose: The primary purpose of evidence objects is to provide verifiable support for claims made in passports. Evidence includes documents that certify compliance (certificates), documents that report test results (test reports), documents that record inspections (inspection reports), and documents that declare conformity (declarations). Evidence must be trustworthy, tamper-evident, and accessible. For DPP systems, evidence is essential for regulatory compliance and consumer trust.

Evidence Types: Different types of evidence serve different verification purposes. Types include certificates (formal certification of compliance), test reports (results of testing activities), inspection reports (results of inspection activities), declarations (self-declarations of conformity), and audit evidence (records of audits). Each type has specific structure and validation requirements. For DPP systems, all evidence types are typically required for comprehensive compliance demonstration.

Evidence Attributes: Evidence objects have attributes that describe and identify them. Attributes include evidence identifier (unique identifier for the evidence), evidence type (what kind of evidence), issuer (who issued the evidence), subject (what the evidence is about), validity period (when the evidence is valid), and status (current state of the evidence). Attributes should be standardized and should support validation. For DPP systems, evidence attributes enable proper interpretation and verification.

Evidence Lifecycle: Evidence objects have lifecycles from creation through expiration. Lifecycle stages include issuance (evidence is created), validity (evidence is valid), expiration (evidence expires), revocation (evidence is revoked before expiration), and archiving (evidence is retained for historical purposes). Lifecycle should be tracked to ensure only valid evidence is used. For DPP systems, evidence lifecycle management is critical for maintaining compliance status.

Certificates

Certificates are formal documents issued by authorized bodies that certify compliance with specific standards or regulations. Effective certificate modeling enables compliance verification and regulatory acceptance.

Certificate Attributes: Certificate attributes include certificate identifier (unique identifier), certificate type (what is being certified), issuer (certification body), subject (who or what is certified), scope (what the certification covers), validity period (when the certificate is valid), and standards (which standards or regulations are met). Attributes should align with certification body requirements. For DPP systems, certificate attributes are critical for regulatory compliance verification.

Certificate Types: Different types of certificates exist for different purposes. Types include product certificates (certification of product compliance), process certificates (certification of manufacturing processes), management system certificates (certification of management systems such as ISO 9001), and personnel certificates (certification of individual qualifications). Types should be explicitly modeled to enable appropriate handling. For DPP systems, product and process certificates are most relevant.

Certificate Issuers: Certificates are issued by authorized certification bodies. Issuers include notified bodies (EU-authorized certification bodies), accredited laboratories (accredited testing labs), and industry associations (industry-specific certification programs). Issuers should be modeled with their accreditation details and authorization scope. For DPP systems, issuer accreditation is essential for certificate acceptance.

Certificate Validity: Certificates have validity periods that define when they are valid. Validity includes issue date (when certificate was issued), expiry date (when certificate expires), renewal requirements (what is required for renewal), and revocation status (whether certificate has been revoked). Validity should be tracked and monitored to ensure only valid certificates are used. For DPP systems, certificate validity is critical for maintaining compliance status.

Test Reports

Test reports document the results of testing activities performed on products or materials. Effective test report modeling enables verification of product characteristics and compliance with technical requirements.

Test Report Attributes: Test report attributes include report identifier (unique identifier), test type (what kind of test was performed), testing laboratory (who performed the test), test subject (what was tested), test date (when the test was performed), test results (the results of the test), and test standards (which standards the test followed). Attributes should enable interpretation and verification of results. For DPP systems, test report attributes support compliance verification and product characterization.

Test Types: Different types of tests serve different purposes. Types include performance tests (measuring product performance), safety tests (verifying safety characteristics), durability tests (testing product lifespan), environmental tests (testing environmental impact), and compliance tests (verifying regulatory compliance). Types should be explicitly modeled to enable appropriate handling. For DPP systems, performance, safety, and compliance tests are most relevant.

Test Methods: Test reports should document the test methods used. Methods include test procedures (step-by-step test process), test equipment (equipment used), test conditions (environmental conditions during test), and measurement accuracy (precision of measurements). Methods should reference standard test methods where applicable. For DPP systems, test method documentation enables result verification and reproducibility.

Test Results: Test results include the actual measurements and outcomes of the test. Results include quantitative results (numerical measurements), qualitative results (pass/fail assessments), comparison to requirements (how results compare to specifications), and uncertainty (measurement uncertainty). Results should be clearly presented and should include units and reference values. For DPP systems, test results support product characterization and compliance demonstration.

Inspection Reports

Inspection reports document the results of inspection activities that verify product characteristics or process compliance. Effective inspection report modeling enables verification of product quality and process adherence.

Inspection Report Attributes: Inspection report attributes include report identifier (unique identifier), inspection type (what kind of inspection), inspector (who performed the inspection), inspection subject (what was inspected), inspection date (when inspection occurred), inspection results (findings of the inspection), and inspection criteria (what was evaluated). Attributes should enable interpretation and verification of findings. For DPP systems, inspection report attributes support quality verification and compliance demonstration.

Inspection Types: Different types of inspections serve different purposes. Types include product inspections (inspecting finished products), process inspections (inspecting manufacturing processes), facility inspections (inspecting manufacturing facilities), and supplier inspections (inspecting supplier capabilities). Types should be explicitly modeled to enable appropriate handling. For DPP systems, product and process inspections are most relevant.

Inspection Findings: Inspection reports document findings from the inspection. Findings include observations (what was observed), non-conformities (deficiencies found), corrective actions (required corrections), and overall assessment (pass/fail or rating). Findings should be specific and should include evidence (photos, measurements). For DPP systems, inspection findings support quality improvement and compliance verification.

Inspector Qualifications: Inspectors should have appropriate qualifications for the inspections they perform. Qualifications include certification (inspector certification), experience (relevant experience), and training (specific training). Qualifications should be documented and should be linked to inspection reports. For DPP systems, inspector qualifications support credibility of inspection findings.

Declarations

Declarations are formal statements by organizations declaring compliance with specific requirements. Effective declaration modeling enables self-declaration of conformity and supports regulatory frameworks that allow manufacturer declarations.

Declaration Attributes: Declaration attributes include declaration identifier (unique identifier), declaration type (what is being declared), declarant (who is making the declaration), declaration subject (what the declaration covers), declaration date (when declaration was made), validity period (how long declaration is valid), and supporting evidence (evidence supporting the declaration). Attributes should enable verification of the declaration. For DPP systems, declaration attributes support self-declaration compliance frameworks.

Declaration Types: Different types of declarations exist for different purposes. Types include declarations of conformity (DoC - declaring compliance with regulations), declarations of performance (declaring performance characteristics), and declarations of origin (declaring material or product origin). Types should be explicitly modeled to enable appropriate handling. For DPP systems, declarations of conformity are most relevant for regulatory compliance.

Declarant Responsibility: The declarant (organization making the declaration) has responsibility for the accuracy of the declaration. Responsibility includes legal liability (legal consequences of false declarations), verification requirements (what verification must be performed), and record keeping (how long records must be kept). Responsibility should be clearly defined and documented. For DPP systems, declarant responsibility is essential for accountability.

Declaration Evidence: Declarations should be supported by evidence. Evidence includes test reports (supporting test results), certificates (supporting certifications), and internal records (supporting documentation). Evidence should be linked to the declaration and should be accessible for verification. For DPP systems, declaration evidence enables verification of self-declared compliance.

Verification Structures

Verification structures define how evidence is organized and linked to support verification of claims. Effective verification structure design enables efficient verification, audit trails, and trust establishment.

Verification Chains: Verification chains link evidence to the claims they support. Chains include claim (what is being claimed), evidence (evidence supporting the claim), and verification (process of verifying the evidence). Chains should be explicit and should enable tracing from claim to evidence to verification. For DPP systems, verification chains enable regulators and consumers to verify claims.

Verification Levels: Different levels of verification provide different levels of assurance. Levels include self-verification (organization verifies its own claims), third-party verification (independent third party verifies claims), and regulatory verification (regulatory body verifies claims). Levels should be explicitly modeled to enable assessment of assurance. For DPP systems, verification levels support risk-based trust assessment.

Verification Status: Verification status tracks the current state of verification. Status includes pending (verification in progress), verified (claim has been verified), not verified (claim could not be verified), and expired (verification has expired). Status should be tracked and updated as verification occurs. For DPP systems, verification status enables consumers to assess claim validity.

Verification Metadata: Verification should include metadata about the verification process. Metadata includes verifier (who performed verification), verification date (when verification occurred), verification method (how verification was performed), and verification result (outcome of verification). Metadata should be linked to evidence and claims. For DPP systems, verification metadata supports audit trails and accountability.

Audit Evidence

Audit evidence represents records and documentation created during audits of products, processes, or organizations. Effective audit evidence modeling supports regulatory audits, certification audits, and internal audits.

Audit Evidence Attributes: Audit evidence attributes include evidence identifier (unique identifier), audit type (what kind of audit), auditor (who performed the audit), audit subject (what was audited), audit date (when audit occurred), audit findings (findings from the audit), and audit scope (what was covered in the audit). Attributes should enable interpretation and follow-up on findings. For DPP systems, audit evidence supports regulatory compliance and continuous improvement.

Audit Types: Different types of audits serve different purposes. Types include regulatory audits (audits by regulatory bodies), certification audits (audits for certification), internal audits (internal quality audits), and supplier audits (audits of suppliers). Types should be explicitly modeled to enable appropriate handling. For DPP systems, regulatory and certification audits are most relevant.

Audit Findings: Audit evidence documents findings from the audit. Findings include observations (what was observed), non-conformities (deficiencies found), corrective actions (required corrections), and follow-up requirements (what must be done to close findings). Findings should be specific and should include severity and deadlines. For DPP systems, audit findings support compliance improvement and risk management.

Audit Trails: Audit evidence should support complete audit trails. Trails include what was audited, when it was audited, who performed the audit, what was found, and what was done about findings. Trails should be complete and should be maintained for regulatory periods. For DPP systems, audit trails are essential for regulatory compliance and accountability.

Evidence Linking

Evidence linking defines how evidence is connected to products, organizations, and claims. Effective linking enables navigation from products to supporting evidence and verification of claims.

Link Types: Different types of links connect evidence to other entities. Types include product-evidence links (evidence supporting a product), organization-evidence links (evidence about an organization), claim-evidence links (evidence supporting a specific claim), and evidence-evidence links (evidence referencing other evidence). Types should be explicitly modeled to enable appropriate navigation. For DPP systems, product-evidence and claim-evidence links are most relevant.

Link Attributes: Links have attributes that describe the relationship. Attributes include link type (what kind of link), link role (what role the evidence plays), validity period (when the link is valid), and confidence (level of confidence in the link). Attributes should enable interpretation of the relationship. For DPP systems, link attributes support evidence evaluation and verification.

Link Aggregation: Evidence may be aggregated to support complex claims. Aggregation includes grouping related evidence (evidence that together supports a claim), evidence hierarchies (evidence referencing other evidence), and evidence bundles (collections of evidence for a specific purpose). Aggregation should support both individual and collective evidence evaluation. For DPP systems, evidence aggregation supports complex compliance demonstrations.

Link Validation: Links should be validated to ensure they are appropriate and accurate. Validation includes verifying that evidence is relevant to the linked entity, verifying that evidence is current and valid, and verifying that the link is authorized. Validation should be automated where possible and should include manual review for complex cases. For DPP systems, link validation ensures evidence integrity.

Evidence Schema Design

Evidence schema design defines the structure and validation rules for evidence data. Effective schema design ensures data quality, interoperability, and supports diverse evidence types.

Schema Structure: Evidence schema structure defines how evidence data is organized. Structure includes core evidence object (identity, type, issuer), evidence content (document content or reference), evidence links (connections to products, organizations, claims), and verification metadata (verification status and details). Structure should be consistent with CEDM and should support all evidence types. For DPP systems, schema structure should accommodate diverse evidence formats.

Schema Validation: Schema validation rules ensure evidence data quality. Validation includes required fields (mandatory attributes), format validation (standard formats for identifiers, dates), referential validation (references to valid entities), and business rule validation (domain-specific rules such as validity periods). Validation should be implemented at both schema and application levels. For DPP systems, validation is critical for evidence integrity and trust.

Schema Extensibility: Evidence schemas must support extensibility to accommodate industry-specific and evidence-type-specific requirements. Extensibility mechanisms include additional evidence types (custom evidence types), additional attributes (custom attributes for specific evidence types), and extension points (defined locations for extensions). Extensibility should be controlled to prevent fragmentation. For DPP systems, extensibility is essential for accommodating diverse certification and testing schemes.

Schema Versioning: Evidence schemas will evolve over time. Versioning includes semantic versioning (MAJOR.MINOR.PATCH), compatibility policies (what changes break compatibility), and migration support (how to migrate data between versions). Versioning should be planned from the start and should support historical evidence preservation. For DPP systems, schema versioning is critical for maintaining valid historical evidence.

Evidence Data Quality

Evidence data quality is essential for trust, verification, and compliance. Poor evidence data leads to verification failures, compliance issues, and loss of trust.

Quality Dimensions: Evidence data quality has multiple dimensions. Authenticity (evidence is genuine and not forged), integrity (evidence has not been tampered with), validity (evidence is current and not expired), completeness (all required evidence is present), accuracy (evidence content is correct), and accessibility (evidence can be accessed when needed). All dimensions should be measured and monitored. For DPP systems, quality dimensions are critical for trust and compliance.

Quality Validation: Quality validation ensures evidence meets quality standards. Validation includes authenticity verification (verify evidence is genuine), integrity verification (verify evidence has not been tampered with), validity verification (verify evidence is current), and completeness verification (verify all required evidence is present). Validation should occur at evidence ingestion and should include automated checks where possible. For DPP systems, validation should include cryptographic verification for authenticity and integrity.

Quality Monitoring: Quality monitoring tracks quality metrics over time. Monitoring includes evidence coverage (percentage of claims with supporting evidence), evidence validity (percentage of evidence that is current), and evidence accessibility (percentage of evidence that is accessible). Monitoring should be automated and should drive improvement efforts. For DPP systems, quality monitoring is essential for maintaining trust at scale.

Quality Improvement: Quality improvement processes address quality issues. Improvement includes root cause analysis (identifying causes of quality issues), corrective actions (fixing current issues), and preventive actions (preventing future issues). Improvement should be continuous and should be data-driven. For DPP systems, quality improvement is critical for long-term trust and compliance.

Technical Concepts

• Evidence Object: Entity representing verification documents and artifacts
• Certificate: Formal document certifying compliance with standards or regulations
• Test Report: Document reporting results of testing activities
• Inspection Report: Document reporting results of inspection activities
• Declaration: Formal statement declaring compliance with requirements
• Verification Structure: Organization of evidence to support claim verification
• Audit Evidence: Records and documentation from audits
• Evidence Linking: Connection of evidence to products, organizations, and claims
• Verification Chain: Link from claim through evidence to verification
• Notified Body: EU-authorized certification body
• Declaration of Conformity (DoC): Self-declaration of compliance with regulations
• Authenticity: Property of evidence being genuine and not forged
• Integrity: Property of evidence not being tampered with

Architecture Considerations

Evidence Model Architecture: Design evidence model architecture based on requirements. Consider centralized evidence repository (single store for all evidence) vs distributed evidence storage (evidence stored with products or organizations). Centralized repository ensures consistency and enables efficient verification. Distributed storage provides simplicity but may complicate verification. For DPP systems, centralized evidence repository with references from products is common.

Document Storage Architecture: Design architecture for storing evidence documents. Consider embedded storage (documents stored directly in evidence objects) vs referenced storage (documents stored separately with references). Embedded storage simplifies access but increases storage. Referenced storage reduces storage but requires document management. For DPP systems, referenced storage with secure document storage is common for large documents.

Verification Architecture: Design architecture for verification processes. Consider automated verification (automated checks of evidence validity) vs manual verification (human review of evidence). Automated verification provides speed and consistency. Manual verification provides flexibility for complex cases. For DPP systems, hybrid approach with automated checks and manual review for exceptions is common.

Security Architecture: Design architecture for evidence security. Security includes access control (who can access evidence), encryption (evidence encrypted at rest and in transit), integrity protection (cryptographic signatures to prevent tampering), and audit logging (tracking access and modifications). Security is critical for evidence trust. For DPP systems, cryptographic signatures and secure storage are essential.

Integration Architecture: Design architecture for integrating with external evidence sources. Integration includes certification body systems (certificates), testing laboratory systems (test reports), and regulatory systems (declarations). Integration should be automated where possible and should include validation. For DPP systems, integration with external systems is critical for comprehensive evidence collection.

Implementation Considerations

Schema Technology: Select appropriate schema technology for evidence schemas. JSON Schema for document-based implementations, XML Schema for legacy systems, or custom schema definitions. Technology selection should be based on implementation architecture and interoperability requirements. For DPP systems, JSON Schema is commonly used for passport data exchange.

Document Storage: Select appropriate document storage for evidence documents. Storage options include object storage (AWS S3, Azure Blob Storage), document databases (MongoDB, CouchDB), or secure file systems. Storage should support security, access control, and integrity protection. For DPP systems, object storage with cryptographic integrity protection is common.

Cryptographic Protection: Implement cryptographic protection for evidence integrity and authenticity. Protection includes digital signatures (sign evidence to prevent tampering), hash verification (verify evidence hashes), and certificate validation (validate issuer certificates). Cryptographic protection should use standard algorithms and should be properly managed. For DPP systems, digital signatures are essential for evidence trust.

Validation Implementation: Implement validation at multiple levels. Schema validation (validate against schema), cryptographic validation (verify signatures and hashes), referential validation (validate references to valid entities), and business rule validation (validate domain rules such as validity periods). Validation should provide clear error messages and should be automated where possible. For DPP systems, cryptographic validation is particularly important.

API Design: Design APIs to expose evidence data effectively. API endpoints should support evidence retrieval (get evidence by identifier), evidence search (search evidence by type, issuer, subject), evidence verification (verify evidence validity), and evidence upload (submit new evidence). API responses should include necessary metadata and should support large document downloads. For DPP systems, REST or GraphQL APIs with evidence-specific endpoints are common.

Enterprise Examples

Battery Evidence Model: A European automotive manufacturer implemented an evidence model for EV battery passports. The model included certificates for regulatory compliance (CE marking, UN 38.3), test reports for battery performance and safety, and declarations of conformity for EU Battery Regulation. Evidence was stored in a centralized repository with cryptographic signatures for integrity. The implementation supported verification by regulators and provided consumers with access to compliance documentation.

Textile Evidence Model: A European textile industry association implemented an evidence model for textile product passports. The model included certificates for organic certification (GOTS, OCS), test reports for chemical testing (REACH compliance), and declarations for material origin. Evidence was linked to products through explicit evidence-evidence links supporting material composition claims. The implementation enabled industry-wide verification of sustainability claims and supported consumer trust.

Electronics Evidence Model: A consumer electronics manufacturer implemented an evidence model for electronic product passports. The model included certificates for regulatory compliance (CE, FCC), test reports for electromagnetic compatibility and safety, and audit evidence from supplier audits. Evidence was integrated with external certification body systems for automatic certificate updates. The implementation supported global product portfolios with diverse regulatory requirements and enabled efficient compliance verification.

Common Mistakes

Incomplete Evidence: Not including all required evidence types, resulting in incomplete compliance demonstration. All evidence types required by regulations should be modeled and included in passports.

Poor Evidence Linking: Not explicitly linking evidence to claims, resulting in inability to verify claims. Evidence should be explicitly linked to the claims it supports with clear relationship types.

Ignoring Evidence Validity: Not tracking evidence validity periods, resulting in use of expired evidence. Evidence validity should be tracked and monitored, and expired evidence should be flagged.

No Cryptographic Protection: Not implementing cryptographic protection for evidence, resulting in inability to ensure integrity and authenticity. Evidence should be digitally signed and hash-verified to prevent tampering.

Poor Document Storage: Storing evidence documents in ways that compromise accessibility or security. Document storage should support secure access, integrity protection, and long-term retention.

Best Practices

Standard Evidence Types: Use standard evidence types where possible. Standard types include common certificate types (CE, ISO certifications), standard test report formats, and standard declaration formats. Standard types enable interoperability and reduce custom mapping.

Cryptographic Signatures: Implement digital signatures for all evidence. Signatures provide authenticity and integrity protection. Signatures should use standard algorithms and should be properly managed (key management, certificate validation).

Explicit Linking: Explicitly link evidence to claims and products. Links should have clear types and roles and should be navigable in both directions. Explicit linking enables verification and audit trails.

Centralized Repository: Use a centralized evidence repository. Centralization ensures consistency, enables efficient verification, and simplifies security management. Repository should support secure access and integrity protection.

Validity Tracking: Track evidence validity periods and status. Validity should be monitored and expired evidence should be flagged. Validity tracking ensures only current evidence is used for verification.

Evidence Aggregation: Support evidence aggregation for complex claims. Aggregation enables multiple pieces of evidence to support a single claim and provides flexibility for different verification scenarios.

Key Takeaways

• Evidence objects represent verification documents and artifacts supporting DPP claims
• Certificates certify compliance with standards or regulations
• Test reports document results of testing activities
• Inspection reports document results of inspection activities
• Declarations are formal statements declaring compliance with requirements
• Verification structures organize evidence to support claim verification
• Audit evidence represents records from audits
• Evidence linking connects evidence to products, organizations, and claims
• Evidence schema design defines structure and validation rules
• Evidence data quality dimensions include authenticity, integrity, validity, completeness, accuracy, and accessibility
• Architecture considerations include evidence model, document storage, verification, security, and integration architecture
• Implementation considerations include schema technology, document storage, cryptographic protection, validation, and APIs
• Common mistakes include incomplete evidence, poor evidence linking, ignoring evidence validity, no cryptographic protection, and poor document storage
• Best practices include standard evidence types, cryptographic signatures, explicit linking, centralized repository, validity tracking, and evidence aggregation