Before you build the model, take stock of the documents

Ask an engineering team where the truth about a product lives, and the honest answer is usually "in several places." The released drawing says one thing. The parts list in the planning system says another. The wiring list on the shop floor has a handwritten correction that never made it back to either. Each one is right about something.

That is the starting point for most digital engineering efforts, in companies and agencies alike. The goal is a single model that people can query: which parts connect to which, what each requirement traces to, what changes if one component is swapped. The information for that model almost always exists already. The problem is that it was written for people to read, across many years, by many hands.

So the first job is not conversion. It is taking stock.

Why the documents decide the outcome

A model built from documents inherits their condition. If two revisions of a wiring list disagree, the model will either pick one silently or carry both. If a parts list was never updated after an engineering change, the model will be wrong in exactly the place someone is most likely to look.

When we built and tested our own document-to-model pipeline, we did it on a synthetic test corpus written for the purpose, with no controlled or classified material: 18 documents in 7 formats, with 40 defects planted on purpose. We planted the defects because real document sets are messy, and a conversion method that only works on clean inputs is not ready for real ones. The pipeline is at technology readiness level 3: it works in a controlled test and has not yet been proven in production. The lesson that carries over to any effort is simple. Plan for the mess before you meet it.

Five questions to answer before conversion

1. What do you actually have? List the document types that describe the product: drawings, bills of material, wiring or cable lists, interface documents, work instructions, supplier datasheets and test procedures. Note the format of each: native CAD, spreadsheets, searchable PDFs, scans or paper. Scans and paper are not a reason to stop, but they change the effort.

2. Which revision is authoritative? For each document type, decide where the released version lives and who can say so. If nobody can answer that for a given document, write it down. That gap will become a dispute inside the model later.

3. Which elements matter first? No team needs every element type on day one. Pick the two or three that drive the most questions or the most rework. For many manufacturers that means parts, connections and requirements. Start there and add the rest once those hold up.

4. Who owns the model after it is built? A model with no owner drifts out of date within months. Name the person or team who approves changes, and decide how an engineering change order updates the model as well as the drawing.

5. How will you know the conversion is good enough? Agree on the measures before anyone starts: how accurate each element type must be, and how much correction effort is acceptable. Write the test down first. Agreeing afterward invites an argument about whether the result passed.

Start with one assembly

The safest first step is small. Pick one assembly or subsystem that people ask about often and that has a reasonably complete document set. Convert it, measure it against the targets from question 5, and have the engineers who know it best check the result.

Two habits make that pilot useful: every element in the model should point back to its source so a reviewer can check it in one step, and every disagreement the conversion turns up should go on a list. That list is often the most valuable thing the pilot produces, because it shows exactly where the paper record and the real product have drifted apart.

What to do this month

• Pick one assembly and list every document that describes it, with its format and current revision.
• For each document type, name the person who decides which version is released.
• Choose the two or three element types the model must get right first.
• Write down the accuracy and correction-effort targets you would accept, before any conversion work begins.
• Name the owner who will keep the model current after it is built.

None of these steps needs new software, and together they turn a vague goal into a scoped first project.

The same work in government

Agencies and their suppliers face the same problem at larger scale: technical data packages built over decades, with revisions held by different organizations. The questions do not change.

How Artheus can help

If you are planning a model, we can do this work with you. In a fixed-scope Digital Engineering Readiness Assessment, we sit down with your engineers, answer the five questions together and write down the accuracy and correction-effort targets you would accept. We then convert one pilot assembly with our document-to-model pipeline, on your own network if your data cannot leave it. Every element points to the document, page and row it came from, with a confidence score, and every disagreement between documents goes on a list for your engineers. You get the pilot model, its measured results against your targets and that list, and you decide whether to go further.