# What Can a Mill Test Certificate Prove for a Steel Digital Product Passport?

Source: https://activatedigital.ai/knowledge/digital-product-passport/iron-steel/mill-test-certificate-evidence
Last verified: 10 September 2026
Summary: A scope-first steel evidence guide to what a mill test certificate can establish, what multi-heat and date fields do not prove and where current melt-and-pour rules use MTC evidence.

## Direct answer

A mill test certificate is useful only at the scope its identifiers and rows actually support. Where the certificate and the relevant row are correctly bound to a heat, batch, product or item, it can establish substantial governed data. Where that binding is missing, the right answer is to keep the value at the scope the document supports or leave the downstream field unresolved.

A mill test certificate can be one of the strongest evidence objects available for steel product data. It can also be a very efficient way to create false precision.

The difference is scope. A certificate may contain document-level delivery details, heat-linked chemistry, sample or product test results and specification references on the same page. Those values do not become one flat set of facts simply because software can read them.

That means four controls matter before reuse:

- identify what the value actually says;
- identify the scope at which it is true;
- join that scope to the steel being described; and
- keep document integrity and physical truth as separate questions.
This page is about steel-specific MTC interpretation. For the broader hierarchy of [document scope and evidential weight](https://activatedigital.ai/knowledge/evidence/documents), the horizontal evidence page remains the owner.

**Acceptance rule:** a visible value is not a governed product fact until its meaning, scope and subject binding all survive the move from certificate to product record.

## Read the certificate as layers, not one record

A practical steel certificate can carry several evidence layers at once:

- **document or delivery layer:** certificate number, order references, overall quantity or mass;
- **heat or batch layer:** heat number and facts explicitly attached to that heat;
- **product or sample layer:** measured results for a named specimen, sample or product row;
- **specification layer:** grade, standard or nominal limits that describe what the product is intended to conform to;
- **item layer:** only where an item identifier and the evidence actually bind the assertion to that item.
The control is simple to state and easy to lose in extraction: a value can move downstream only with the scope that made it true.

That becomes especially important when a certificate contains more than one heat.

## A multi-heat certificate is not one batch-shaped object

The accepted steel research includes a historical Ostrava inspection certificate used as a real scope test. The certificate contains two heat numbers, **38191K** and **38190K**. It also carries header totals of **761 pieces** and **148,656 lb**.

Those visible totals are useful facts about the certificate or delivery represented by the header. They are not, by themselves, a safe allocation to heat 38191K, heat 38190K or any child product derived from either heat.

If software reads the document once, sees one total and attaches that number to the first heat row, the extraction may be technically accurate while the resulting product data is wrong. The error is not OCR. It is a scope lift.

The safe rule is:

**document total + multiple heats ≠ per-heat total unless the certificate provides an explicit allocation or another governed join supplies it.**

The same rule applies beyond mass. Header-level test references, delivery facts or other document-wide values must not silently become heat facts because a parser needs a single place to put them.

The example is historical. It is useful because the failure mode is real and visible, not because the public copy proves anything about a current transaction. The issuer authenticity of that copy and its present binding to physical material were not independently established in the accepted research.

## Heat analysis and product or sample analysis are different assertions

The historical certificate also exposes another common flattening error: it carries separately labelled chemistry rows for heat analysis and product/sample analysis.

Those rows can contain chemically similar values. That does not make them interchangeable.

A heat analysis is an assertion at the heat scope represented by the certificate. A product or sample analysis is an assertion about the tested product or specimen represented by that row. If a future data model has a field for one of those concepts, populating it from the other changes the meaning of the evidence even when the numbers look plausible.

So the acceptance test is not “did we extract a chemistry value?” It is “did we extract the right chemistry assertion, at the right scope, for the subject we are publishing?”

| Certificate evidence | Safe governed use | Unsafe promotion |
|---|---|---|
| Heat number on the relevant row | Heat identifier for the row it binds | Treating it as proof that every item in a delivery belongs to that heat without a join |
| Header quantity or mass on a multi-heat certificate | Document or delivery total | Allocating the total to one heat or child item without explicit allocation |
| Heat-analysis row | Heat-level chemistry where the heat binding is clear | Re-labelling it as product/sample analysis |
| Product/sample-analysis row | Test result for the represented product or sample scope | Re-labelling it as heat analysis |
| Certificate issue date | Certificate issue date | Manufacture date |
| Grade or specification reference | Declared specification context at the supported scope | Proof that a catalogue/model value is the measured delivered-batch result |

## The date on the certificate is not automatically the manufacture date

A certificate can have a perfectly clear issue date and still tell you nothing definitive about when the steel was manufactured.

In the historical case, the certificate issue date is **30 September 2012**. The accepted evidence did not establish an independent manufacture date. The Steel Engine acceptance gate therefore keeps those concepts separate: certificate issue date must not populate manufacture date.

This is a useful test of a governed pipeline. If a source has a date but the source does not establish the business meaning of the target date field, the field stays unresolved. A date that looks operationally convenient is not a substitute for evidence.

## Specification evidence can set the envelope, not prove the delivery

Producer pages, catalogues and technical sheets can be excellent sources for grade identity, nominal chemistry ranges, dimensions, declared properties and operating limits. They are usually easier to find and structure than transaction-linked batch evidence.

But a model or specification source describes the product definition or permitted envelope. It does not become proof of the delivered heat simply because the product name matches.

The governing question is the join. Is there a controlled relationship from the model/specification evidence to the delivered batch, heat or item, and does the target field actually ask for a specification value rather than an actual measured result?

That distinction is central to [extracting governed facts from technical evidence](https://activatedigital.ai/knowledge/product-data/technical-file-to-governed-product-data). For an MTC, the same discipline prevents a nominal limit being stored as actual chemistry or a catalogue property being presented as a measured batch result.

## Machine-readable does not mean true

Digitising the certificate can improve the process enormously. Structured records can make fields easier to parse. Signatures and credentials can help check whether an artefact has changed and whether it comes from the claimed issuer. Digital certificate platforms can support authentication and controlled exchange.

None of those controls removes the subject-binding problem.

A system can successfully parse a heat number from the wrong certificate. It can validate the signature on a credential that belongs to a different batch. It can prove that an artefact has not been altered without proving that the physical chemistry assertion inside it is correct.

The horizontal owner for those controls is [machine-verifiable certificate evidence](https://activatedigital.ai/knowledge/evidence/machine-verifiable-product-certificates). The steel-specific rule here is narrower: verify the join between the intended steel and the correct certificate, then preserve the header, heat and row scope inside that certificate.

S1SEVEN's published developer material shows that digital MTC authentication and certificate workflows are technically real. The accepted research did not establish a universal public producer API or demonstrate end-to-end retrieval for every transaction. That keeps the maturity position at **emerging**, not universal.

## Current melt-and-pour law gives the MTC a specific trade-law role

There is now a separate current-law reason why MTC evidence matters for some EU steel imports.

Regulation (EU) 2026/1384 requires importers of product categories in its Annex I to provide appropriate verifiable evidence, such as a mill test certificate, for the country where raw steel or iron was first produced in liquid form and cast into its first solid state. Commission Implementing Regulation (EU) 2026/1963 then specifies the evidence route. It is in force and applies from **1 October 2026**.

For covered imports, the implementing regulation requires an MTC containing the **country of melt and pour** and **heat number**. If either is missing from the MTC, listed complementary documents can supply the missing information. If no MTC is available, the listed alternatives can act as standalone evidence only during the temporary period from **1 October 2026 to 30 September 2027**, provided they contain the required melt-and-pour and heat information.

That is a current trade-law evidence rule. It is not an adopted future ESPR Steel DPP field list.

As at **10 September 2026**, the European Commission still states that any Steel DPP requirements will be defined through a future product-specific delegated act. The exact information requirements are therefore not final. The wider [current Steel DPP readiness and requirement position](https://activatedigital.ai/knowledge/digital-product-passport/iron-steel) owns that question.

The distinction matters because one evidence object can have a mandatory role under one legal regime without becoming the passport or dictating the fields of another regime.

## Field-by-field acceptance: use a gate, not a document dump

A safe MTC-to-product-data workflow is field-led rather than document-led.

**1. Define the target assertion.** Be precise about what the downstream field means. “Chemistry”, “origin” or “date” is not enough.

**2. Identify the evidence location.** Record the certificate, page, header or row that carries the candidate value.

**3. Preserve the source scope.** Mark whether that value is specification, document/delivery, heat/batch, product/sample or item-level evidence.

**4. Prove the subject join.** Use the relevant heat, order, batch, product or item identifiers to show why this evidence belongs to the steel being described.

**5. Reject semantic substitutions.** Do not swap heat analysis for product analysis, issue date for manufacture date or country of melt and pour for another origin concept.

**6. Keep provenance with the accepted value.** Store the evidence reference, source scope, identifier join and any qualification that made the value safe to use.

**7. Leave unresolved facts unresolved.** A certificate can solve many fields at once, but its richness is not permission to infer the facts it does not establish.

That last point is where MTCs become valuable rather than dangerous. One evidence bundle can compress a large amount of acquisition work if each accepted value retains its own scope, source and binding.

## What an MTC cannot establish on its own

Even a rich steel certificate does not automatically prove:

- that the visible or extracted document is authentic;
- that the certificate belongs to the intended delivery, batch or item;
- that a document-level total belongs to one heat in a multi-heat certificate;
- that heat analysis and product/sample analysis mean the same thing;
- that the certificate issue date is the manufacture date;
- that a catalogue specification is the measured truth of delivered material;
- that country of melt and pour is the same as customs country of origin, finishing location or producer headquarters; or
- what the final legally required future ESPR Steel DPP field set will be.
The practical standard is therefore not “we found the certificate”. It is “the certificate establishes this fact, at this scope, for this subject, with this evidence trail”.

## What would change this answer?

Two developments deserve a fresh review.

First, the future Steel ESPR delegated act could prescribe different information, evidence or granularity rules. That would change the DPP side of the answer, but it would not justify treating today's preparatory model as final law.

Second, the current melt-and-pour evidence regime can change. The Commission is required to keep the evidence list under review, and the temporary standalone-alternative period in Implementing Regulation (EU) 2026/1963 ends on 30 September 2027 unless the law changes.

The scope principle is more durable: whatever the format, a fact is only as strong as the evidence meaning and subject binding that support it.

## Sources

- [Commission Implementing Regulation (EU) 2026/1963, current melt-and-pour evidence route, checked 10 September 2026.](https://eur-lex.europa.eu/eli/reg_impl/2026/1963/oj/eng)
- [Regulation (EU) 2026/1384, Article 4 basis for melt-and-pour evidence for covered imports.](https://eur-lex.europa.eu/eli/reg/2026/1384/oj)
- [European Commission: The Digital Product Passport for Iron and Steel, current future-delegated-act position, checked 10 September 2026.](https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/iron-steel_en) European Commission
- [S1SEVEN developer information, evidence that digital certificate and authentication workflows exist; not evidence of universal public transaction retrieval.](https://developers.s1seven.com/docs/information/)
- [Historical inspection certificate used in the accepted real-case test, third-party public copy used only for scope analysis; issuer authenticity and current physical binding were not independently established.](https://f.machineryhost.com/87ae6fb631f7c8a627e8e28785d9992d/8680ae24faf90d3879b8899e808bcbbd/Heat%20%2338191K.pdf)