Your Technical File Holds Compliance Evidence. Which Parts Should Become Governed Product Data?

Technical documentation and governed product data do different jobs

[REGULATION] For products subject to harmonised EU product rules, current European Commission guidance describes technical documentation as the material that demonstrates compliance. It can include product identification, applicable rules and standards, risk assessment, critical components and materials, test reports, labels and instructions. The exact documentation and retention requirements still depend on the legislation applying to the product.¹

The document is therefore valuable partly because of its form, context and completeness as evidence.

Governed product data is valuable for another reason: it makes a product fact directly usable.

Consider a laboratory report that establishes a measured value for one model. The report may contain 40 pages of method, setup, sample details, uncertainty, observations and signatures. A retailer feed may need one approved value. A compliance rule may need a pass/fail state. A customer-service workflow may need the model and test date.

Those downstream systems should not have to reopen the PDF and reinterpret it each time.

That is the point at which evidence can become product intelligence, but only if the extracted value keeps its scope and provenance.

Source evidence

The evidence layer answers questions such as:

• What was tested or declared?
• Who issued or approved it?
• Which method was used?
• What was the sample?
• Which revision was assessed?
• What limitations or conditions apply?
• Was a signature, certificate or complete report required?

Governed product fact

The governed layer answers questions such as:

• What value can the organisation currently use?
• What product, model, variant, batch or item does it apply to?
• What evidence supports it?
• Is it current, expired, disputed or unknown?
• Who owns the record?
• Which outputs may consume it?

The two layers should stay connected. One should not replace the other.

What should usually stay documentary?

[RECOMMENDATION] Keep information primarily as documentation where the full artefact carries meaning that would be lost or distorted by extracting fragments.

Typical examples include:

• full laboratory methodology and narrative
• signed declarations and attestations
• complete risk assessments
• supporting calculations and calculation workbooks
• detailed technical drawings
• full supplier documentation
• certificate artefacts and annexes
• test photographs and observations
• detailed failure analysis
• correspondence that explains an exception or approved resolution.

There are four common reasons.

1. Legal or evidential form matters

A signed declaration is not made equivalent to the original by copying three fields into a database. The structured fields may be useful, but the declaration remains the evidence artefact.

2. Context matters

A test result can depend on sample preparation, method, tolerances, equipment or assumptions. Reducing the entire report to a number can remove the conditions that make the number meaningful.

3. The full artefact may be requested

A regulator, notified body, auditor, retailer or customer may need the report or declaration rather than a database value derived from it.

4. Extraction has a maintenance cost

Every structured field creates an obligation to define scope, ownership, update rules and conflict handling. Extracting information that nobody uses can create more governance work than value.

The practical rule is not “documents bad, data good”. It is use the right form for the job.

What should become structured, governed product data?

[RECOMMENDATION] A fact becomes a stronger candidate for governance when several of the following are true.

No single test makes extraction mandatory.

A field used once in a rare investigation may sensibly stay in the file. A manufacturer legal identity used in an online offer, retailer feed, label, passport and service workflow is a much stronger candidate for central governance.

Evidence is not product truth without scope

A genuine document can still be the wrong evidence for the fact you are trying to use.

A certificate may cover one factory but not another. A test report may cover one model and not a later variant. A supplier declaration may relate to one material grade or one production period. A weight may exclude packaging when another output expects gross weight.

[PRACTICE] A useful governed fact therefore needs more than a value. At minimum, the organisation needs enough context to establish:

value + scope + evidence + time

Scope can include:

• product family
• model
• variant
• component
• batch or lot
• individual item
• test sample
• manufacturer or facility
• geography or market
• effective date
• expiry or review date
• document revision.

This is not a universal database schema. The relevant dimensions depend on the fact.

Why scope errors are dangerous

Suppose a laboratory result is valid for Model A, black housing, Supplier X, production revision 4.

If a system stores only result = PASS, it may silently reuse the result for:

• Model B
• the white housing made from a different compound
• production revision 5
• a different supplier
• a later period after the certificate expired.

The document can be authentic and the reuse can still be wrong.

The extracted fact should retain provenance

[STANDARD] W3C PROV provides a formal, domain-independent model for describing the entities, activities and agents involved in producing data. Its value here is conceptual: provenance helps users understand origins, transformations and responsibility. It does not require ActivateDigital's exact field set and it is not a product-compliance rule.²

[RECOMMENDATION] For important governed product facts, useful provenance may include:

• source document or evidence ID
• issuer or source organisation
• evidence date
• expiry or validity period
• relevant page, section or result reference
• product and variant scope
• method or assessment route where material
• status such as verified, disputed or unknown
• record owner
• last verified date
• superseded-by relationship
• change or resolution history.

Not every implementation needs every field.

The principle is simpler: a user should be able to travel from the fact back to the evidence and understand why the fact applies to this product now.

That link also makes change safer. When evidence expires or is superseded, the organisation can identify which governed facts and downstream outputs may be affected.

What if two technical documents establish different values?

Do not make the database settle an evidence dispute by accident.

“Latest upload wins”, “supplier document wins” and “PIM wins” are all unsafe defaults because they confuse storage order or system position with evidential authority.

[RECOMMENDATION] Assess at least:

1. Scope: do the documents actually apply to the same product, variant, batch, facility and period?
2. Authority: who produced or approved each source and for what purpose?
3. Method: are the values derived from comparable methods or definitions?
4. Date: is one source legitimately superseding another or are both valid for different periods?
5. Evidence quality: is one assertion supported by direct testing while another is an unverified declaration?
6. Relevance: which source answers the specific question the downstream use is asking?
7. Resolution: has an authorised owner approved a conclusion and recorded why?

A conflict can disappear when scope is clarified. Two different weights may both be right if one is net product weight and the other is shipping weight. Two composition values may both be right for different variants.

If the conflict remains unresolved, the governed state should be able to remain conflicted or UNKNOWN rather than silently choose a convenient value.

See When a Test Contradicts a Supplier Declaration for the existing evidence-conflict journey.

A practical fact-candidate matrix

This is a selection aid, not a universal field list.

The matrix deliberately contains “context-dependent” rows. The same field can be critical in one business and irrelevant in another.

Worked example: document -> fact -> governed record -> output

A business sells Model AX17, with two variants that use different housing materials.

An approved product specification contains the product's net weight. A laboratory report contains safety test results. A declaration identifies the manufacturer and covered model. The documents are stored correctly, but teams repeatedly reopen them when populating retailer records and internal compliance checks.

Step 1: identify the reusable fact

The retailer feed and an internal calculation both need net product weight.

The approved specification states 1.24 kg.

Step 2: define scope

The value applies to:

• Model AX17
• Variant EU-BLK
• revision 7 onwards
• product only, excluding retail packaging.

The second variant has a different housing and is not assumed to have the same weight.

Step 3: retain the evidence path

The governed record points to:

• specification SPEC-AX17-R7
• section 3.2
• approved date
• record owner
• last verified date.

The complete specification remains the evidence artefact.

Step 4: create the governed record

A structured record can now say, in effect:

net_product_weight = 1.24 kg scope = AX17 / EU-BLK / rev7+ / excludes packaging evidence = SPEC-AX17-R7 §3.2 status = verified

Step 5: use it downstream

The governed value can feed:

• retailer product data
• ecommerce specifications
• logistics logic where net weight is needed
• a derived environmental calculation if that methodology uses product mass.

Nobody needs to reinterpret the whole specification for those uses.

If revision 8 changes the housing and weight, the evidence relationship tells the team which fact to review and which outputs may need updating.

That is the difference between having a document and operating a governed product fact.

A regulatory example of the boundary

[REGULATION] The current EU Toy Safety Regulation provides a useful illustration rather than a universal template. Its technical documentation covers a broader evidence set, including components and materials, substances and mixtures, supplier Safety Data Sheets, safety assessment and test evidence. Its mandatory Digital Product Passport dataset is narrower. In other words, information can be mandatory in technical documentation without automatically becoming a mandatory passport field.³

The detergent regime provides the same architectural lesson in a different form. It separates the mandatory DPP substance information from other composition information held in separate regulatory documentation.⁴

The wider lesson is not “design every product database like a DPP”. It is:

keep evidence and reusable product facts connected without assuming that every evidential detail belongs in every output.

What not to extract

Avoid extracting information merely because it can be extracted.

Be cautious where:

• nobody consumes the value separately from the document
• the value has no stable definition
• scope cannot be established
• context would be materially lost
• the source is too weak to support a product-level assertion
• the value is highly volatile and no owner exists
• extraction would create a duplicate field that competes with an already governed source
• a result is derived from weak inputs and would create false precision
• the organisation cannot define what should happen when evidence changes.

Sometimes the correct output of a review is leave this documentary.

Sometimes it is UNKNOWN until better evidence exists.

Both are better than creating a polished field with an unreliable meaning.

Common mistakes

Copying the technical file into the PIM

A product database is not improved by becoming a second document archive. Extract facts with a reuse or decision job.

Storing the value but losing the source

A number without provenance can become impossible to defend after staff, suppliers or documents change.

Applying model evidence to every variant

Scope must be explicit. Product families often contain differences that matter.

Treating “latest” as “authoritative”

A later upload can be wrong, irrelevant or scoped differently.

Publishing evidence because it exists

Evidence availability and publication requirement are different questions. Some evidence is confidential, contextual or intended for authorities rather than public channels.

Turning governance recommendations into legal requirements

The framework on this page is an ActivateDigital recommendation. Applicable legislation or formal channel rules determine what is legally or contractually required.

Existing Knowledge connections

Use these as next questions rather than blanket cross-links:

• Where did this value come from? Passport Evidence: How We Know, and What a Blank Means
• What if two sources disagree? When a Test Contradicts a Supplier Declaration
• Can I rely on the supplier document? Supplier evidence
• What should I do when evidence is missing? What You May Publish When You Do Not Know
• Is the product record ready to be reused? Is Your Product Data Ready for a DPP?
• Which governed facts deserve fixing first? Which Product Facts Actually Change a Business Decision?

Direct questions

Should every technical-file field go into the PIM?

No. Structure facts that have a clear reuse, decision or control job. Keep the rest in the evidence layer unless another requirement justifies extraction.

Is a certificate product data?

The certificate itself is usually an evidence artefact. Selected attributes such as certificate reference, scheme, status, scope and validity can be governed product data when they are repeatedly used.

Is a test report product data?

Usually not as a whole. A test result can become a governed fact if its method, scope and evidence relationship remain clear.

How do you link a product fact back to evidence?

Keep a stable evidence reference and enough metadata to identify what the source proves, its scope and its validity. The exact implementation can vary.

What if supplier evidence conflicts with a test report?

First check whether the sources have the same scope, method and time period. If a real conflict remains, use an approved evidence-resolution process. Do not automatically privilege the latest file or a preferred system.

Which compliance facts should be structured?

Prioritise facts that are repeatedly consumed by compliance decisions or outputs, especially where an incorrect value changes eligibility, publication, classification or action.

Should documents or structured records be the source of truth?

They answer different questions. Documents preserve evidence. Governed records preserve the current, usable product assertion and its connection to evidence. A robust system keeps both linked.

What product data should be extracted from a technical file?

Start with product-specific facts that are reused, decision-relevant, scopeable, evidence-backed, change-sensitive or machine-consumed. Do not extract fields that have no clear user or output.

What would change this page?

Revisit this framework if a binding product rule, formal channel requirement or adopted standard prescribes a different information architecture for a particular use case. The governance selection framework itself is intentionally presented as an ActivateDigital recommendation rather than universal law.

Sources and evidence basis

• European Commission / Your Europe, Preparing technical documentation, last checked by the Commission 12 July 2026. The page describes technical documentation under harmonised EU product rules, including its compliance purpose, typical contents and retention principle. Applicable legislation remains controlling.

  View official source

• W3C, PROV Model Primer / PROV Data Model, Recommendation family, 2013. Used as a formal provenance reference for origins, entities, activities and agents. It is not presented as a product-compliance requirement.

  View official source

  https://www.w3.org/TR/prov-dm/

• Regulation (EU) 2025/2509 on the safety of toys, particularly the technical-documentation and DPP annexes. Used only as a current regulatory example of a broad evidence layer and a narrower structured output layer.

  View official source

• Regulation (EU) 2026/405 on detergents and surfactants, particularly the separate technical/composition and DPP information layers. Used as a second current regulatory example.

  View official source

• ActivateDigital current Knowledge estate and final DPP V1 estate, used for editorial doctrine, evidence/scope treatment and internal-link ownership. Existing public articles are not treated as independent regulatory authority.