How I Would Build a CE Marking System That Keeps a Product File Alive

Direct Answer

A CE marking system is a persistent product record that turns a manufacturer’s files into a mapped list of legal requirements, the evidence behind each one, and the gaps that still block a signature. Upload the bill of materials, the drawings, and the manual, pick the markets, and get a per-requirement status rather than one clean verdict. This is a designed system, not a deployed build. It comes from the Shopify Your Industry lab and has never been sold to or validated with a customer.

Key Takeaways

• Most of CE marking is a documentation problem wearing an engineering costume. The engineering part is real, but it is not the part that stalls.
• The product is the coordination layer: intake, requirement mapping, evidence tracking, test coordination, file assembly.
• The bottleneck is liability. The system assembles the evidence; it cannot be the one who certifies.
• Compliance is never finished at launch, so the record has to be persistent and versioned, not a one-off report.
• This is a model, like the freight booking system. The system I have actually built is the CRM follow-up loop.

What problem does this system actually own?

A manufacturer asks one question: can I sell this in Europe? The industry answers with directives, harmonised standards (the published technical specifications that give you a presumption of conformity if you follow them), conformity assessment routes, test reports, a technical file, and a declaration.

Today the path usually runs like this:

1. Someone searches for which legislation applies and finds three plausible answers.
2. A consultant is hired to produce a list of applicable standards.
3. Evidence is collected by email: supplier declarations, a risk assessment, a test report, a manual.
4. A lab is booked, sometimes for the wrong test, sometimes twice.
5. The technical file is assembled at the end, from folders that disagree with each other.
6. The product ships, a standard is revised eighteen months later, and nobody is watching.

None of that is design work. It is information moving between an engineer, a supplier, a lab, and sometimes a notified body, each holding one piece of it. That is the coordination layer, and it is the product.

The existing workflow I would map first

Before any model call, I would sit with the engineer who signs and walk one product from design freeze to declaration.

If that table is wrong, the system is wrong. I would rather spend a week on the table than a month on the wrong build.

How the system would run

Product intake

The manufacturer uploads what already exists: bill of materials, drawings, the user manual, supplier declarations, any prior test reports. The system extracts a product description a requirement engine can work with — what it does, what it plugs into, who uses it, where it is sold. Missing inputs are named as missing rather than assumed. This record is the product, not a ticket, and it stays open for the life of the product.

Applicable-requirements mapping

Retrieval over legislation and standards, scoped to the product type, proposes which acts apply and which conformity route each one allows. Every proposal carries the source text and a confidence. A mains-powered device may fall under the Low Voltage Directive and more besides; the modular structure behind those routes comes from Decision No 768/2008/EC. The system shows the map. An engineer confirms it before anything downstream is trusted.

Evidence gap analysis

Each confirmed requirement gets a slot: satisfied, weak, or empty. Satisfied means a document exists, is current, and actually covers this product variant. Weak is the useful state — a supplier declaration that names a different revision, a test report older than the design change. This is the screen the manufacturer opens, and it is deliberately not a single Ready or Blocked light. A product self-declared under one directive and a product waiting on a notified body are not the same state, and collapsing them into one badge would be a lie of convenience.

Test coordination

From the gaps, the system prepares the test request: what has to be tested, against which clause, with what sample and what documentation. It routes to accredited labs and tracks the booking, the sample, the report, and which requirement the report closes. It does not decide that a test was passed. It records what the lab said.

Technical file generation

The file is assembled continuously from the record: the same manual version, the same drawings, the same declarations, the same reasoning, under version control. When a document is superseded, the file shows what changed and when. The point is a file that survives being read by a market surveillance authority two years later.

Engineer sign-off

A named person reviews the mapping, the evidence, and the file, then signs the declaration of conformity. Where the law requires a notified body, that body does its own assessment and the system is only the applicant’s file clerk. Nothing here is signed by software.

What stays under human control?

• Final determination of which legislation and conformity route applies.
• The risk assessment, and any engineering judgement inside it.
• Interpretation of a test result that is borderline.
• Notified body involvement where the law requires it.
• The declaration of conformity itself, signed by the manufacturer’s named representative.

The system prepares, a person signs. That is the same rule I follow in the CRM build, and Anthropic’s note on building effective agents makes the same argument: keep the workflow simple and inspectable before adding autonomy.

How I would measure the path

Baselines first, and only baselines, because nothing has been built:

• Weeks from design freeze to a signed declaration.
• Number of evidence items that cannot be located when the file is assembled.
• Retests caused by an incomplete or wrong test request.
• Requirements whose supporting document is expired or names a superseded revision.
• Standards revised in the last year that affect a shipped product, and how long it took to notice.

Self-learning here means usage signals, engineer corrections to the requirement mapping, and evaluation of proposed routes against what qualified people actually confirmed — reviewed by a person. It does not mean the system quietly changing the basis of a declaration.

When this is the wrong build

• Nobody will sign. This is the bottleneck. If there is no engineer, no notified body relationship, and no appetite to carry the liability, the system produces a well-organised folder and no legal outcome.
• One product, launched once. The recurring value is monitoring standards after launch. A single product with no roadmap is a consulting job.
• The product is high-risk and heavily assessed. Where a notified body examines everything anyway, the coordination layer is thin and the fee has no room in it.
• The source material is not machine-readable. Scanned drawings and a manual that exists only in a designer’s file are an intake problem, not a model problem.
• The company wants a certificate, not a file. If the goal is a badge rather than a defensible technical file, we disagree about the deliverable and should say so early.

How this connects to the engagement

This case is one of the models on Shopify Your Industry. The freight teardown has the same shape and a different wall: there the supply side, here the signature. The retrieval and monitoring pattern behind standards tracking is closer to the Deal Database. The one system on this site that is actually running is the CRM follow-up loop.

If this coordination layer already exists in your company as folders and one engineer’s memory, the operating starting point is AI workflow automation. If you want it looked at honestly, describe the bottleneck. If you only want the next teardown, the newsletter is enough.

Summary

The abstraction is one line: upload the product file, pick the markets, see what is missing. The output is a defensible technical file and a declaration someone qualified signed. Between those sits a boring coordination layer moving information between an engineer, a supplier, a lab, and sometimes a notified body. This is a model. It stays a model until someone who signs declarations describes where it actually breaks.