We've been writing about a specific gap in how engineers work today. The first post laid out the [PDF tax problem →]. The second covered [what engineering firms actually put in an AI knowledge base →] — the surprising answer being that the most valuable content is internal, not external.
The throughline of both posts is this: AI has gotten good at answering questions about engineering documents. It hasn't gotten good at turning those answers into the artifact engineers actually ship — the calculation.
This post is about closing that gap. What does the complete workflow look like, end to end? What's the difference between a tool that helps you read a document and a tool that helps you do the work the document describes?
The two halves of reference work
Every engineering reference task has the same structure:
Half one — retrieval. Find the clause, parse the formula, identify the limits, cross-check against related provisions.
Half two — composition. Build the calculation. Define the variables. Implement the formula correctly. Apply the right load factors. Document inputs and assumptions. Make it reusable for the next project.
Half one used to take hours. With document chat tools, it now takes minutes. That's a real, large productivity gain that most firms haven't even fully internalised yet.
Half two takes the same time it always did — because the productivity tools that have arrived for half one don't carry through to half two. The conversation ends. The blank spreadsheet starts.
Why the gap exists
There's a structural reason document chat tools stop where they do. They're built on retrieval-augmented language models — architectures designed to find relevant text and produce text in response. The output medium is prose.
A calculation is not prose. A calculation is a structured object: named variables with units, formulas that reference those variables, dependencies between formulas, validation rules, and a layout that's reviewable. Producing one as an output requires the AI to do something different from generating a paragraph. It requires composing a structured artifact in a specific environment.
That's why the gap has persisted. It's not that nobody noticed — engineers have been asking for it loudly. It's that solving it requires both halves of the architecture: retrieval and a compositional environment that can hold a real engineering calculation.
What a complete workflow looks like
Concretely, end to end, here's what we think a complete AI-assisted engineering reference workflow should feel like:
Step 1 — Build the library. Your firm's content goes in directly: the design manual, project archives, SOPs, training material, manufacturer datasheets — once, indexed once. Licensed external content (where it's available) comes in through publisher partnerships, not by uploading PDFs you don't have the rights to.
Step 2 — Ask a real question. Not "where's the design template?" but "I'm checking a 600x400 beam, simply supported, 8m span, with these loads — what does our firm's methodology have me check, and is there a similar precedent calc?" The answer cites the relevant section of your design manual and points to the precedent. The reasoning is traceable.
Step 3 — Generate the calculation. From the same conversation, the workflow produces a live calculation: variables defined, formulas implemented, units consistent, limits applied, assumptions documented. Not a paragraph describing the calc. The calc itself.
Step 4 — Edit and verify. A senior engineer reviews it the way they'd review a junior's work. Wrong assumption? Change the variable. Different load case? Adjust. The calc updates live.
Step 5 — Reuse. The next project that needs the same check doesn't start from scratch. It starts from the calc, with new inputs.
Steps 1, 2, and 4 already exist in pieces across today's tools. Step 3 — the bridge from conversation to artifact — is the missing piece.
The reseller corollary
There's a second-order implication of this workflow that matters for the engineering content economy.
Every author of engineering content today — codes bodies, textbook publishers, consultancies with proprietary design guides, manufacturers with technical libraries — produces PDFs. PDFs are a fundamentally passive medium. The reader does all the work of turning them into action.
A workflow that bridges PDFs to calculations changes the economics of engineering content. A code becomes a computable product. A textbook becomes a working library of design checks. A manufacturer's datasheet becomes a tool that sizes their product into your project. The IP is the same; the medium is different.
For content owners, this is a real distribution opportunity. For engineers, it means the reference materials they already pay for start carrying their weight.
What this means right now
You don't need to wait for the perfect workflow to start capturing the half-one productivity gains. If you're not yet using a document-chat tool with your firm's internal content — design manuals, project archives, SOPs — you're leaving real time on the table. Start there.
But know that's half the answer. The half-two productivity gain — turning answers into calculations without rebuilding them in Excel every time — is the bigger one. It's coming. We've been working on it.
[Join the list →] for more on what's next.
.jpg)
