BuildReady

Inspiration

A part can look finished in CAD and still be far from ready to manufacture.

Between the model and the machine are questions about geometry, material, strength, cost, and supplier requirements. Those answers often live in separate tools—and when the design changes, it is easy for the reasoning to stay attached to the old version.

We built BuildReady to explore a different workflow: an engineer and an AI agent working from the same visible evidence, with a clear record of what is known, what has changed, and what still needs human review.

What it does

BuildReady is a WebMCP-powered manufacturing-readiness workspace. Our prototype brings together Onshape design context, CNC manufacturability checks, a SimScale integration workflow, and supplier comparison.

An agent can inspect the active design context, explain findings, and prepare bounded next steps. The engineer sees the evidence in the interface and retains approval authority. In the controlled demonstration, a proposed radius correction is a preview—not an automatic edit to the source CAD.

We also built a private quotation workspace for preserving original supplier documents, recording their terms, and comparing compatible offers. It separates unit price from setup, shipping, tax, and other charges. Unknown shipping stays unknown rather than quietly becoming zero. A preferred-supplier directory lets users maintain their own options.

The central principle is traceability: a finding, simulation record, or quotation should make clear which design and assumptions it describes.

Why WebMCP

Manufacturing review requires more than knowing which button to click. An agent needs to understand the active revision, the meaning of a measurement, whether evidence is current, and which actions require approval.

WebMCP lets BuildReady expose that context through structured, page-owned tools. The agent and the engineer use the same underlying handlers, so tool results connect to the evidence visible in the application.

We implemented tools with document.modelContext.registerTool, explicit input schemas, and route- and state-dependent availability. Tools are refreshed as the workflow changes, and downstream evidence is invalidated when its source changes.

This makes collaboration more direct: the agent can help inspect and explain a finding while the engineer reviews the same information, without repeatedly copying context between applications. The agent does not gain authority to approve production, modify source CAD, or purchase parts.

How we built it

We used plain JavaScript, HTML, and CSS for the interface, with Python and SQLite for local services, durable records, and private evidence storage. The project runs through uv without npm or PyPI package dependencies.

The Onshape integration supplies design context. The operator-assisted SimScale workflow includes CAD preparation, reviewed topology mappings, durable operation tracking, and retained result evidence. Simulation records bind results to their source design and setup rather than treating a completed run as a universal pass.

We built the quotation workflow around preserved originals and structured human review. Source, review status, design match, validity, and missing terms remain separate.

Codex helped us turn our research into staged implementation work, develop the application and integrations, debug failures, and expand regression coverage. Our latest local checkpoint passed 203 Python tests and 24 JavaScript tests.

Challenges we faced

The hardest challenge was keeping context consistent. A small design revision can invalidate a manufacturing finding, simulation result, or commercial comparison. We had to treat freshness and identity as part of the workflow, not just labels in the interface.

External operations introduced another problem: a request can succeed even when its response is lost. We added durable tracking and operator-assisted reconciliation so uncertainty does not trigger a blind duplicate operation.

We also had to distinguish evidence from confidence. A solver finishing does not prove numerical correctness. A price without shipping is not a delivered total. A realistic-looking fixture is not a genuine supplier quotation.

What we learned

We learned that useful engineering AI depends as much on boundaries as capabilities. Structured tools help an agent understand what it can do; explicit unknowns help it understand what it cannot conclude.

We also learned that trustworthy integration means preserving relationships between records—not simply connecting APIs. The design revision, exported geometry, simulation setup, and quoted scope all matter.

What we are proud of

We built a prototype where AI assistance is inspectable. Engineers can see the findings, assumptions, human decisions, and evidence behind the next step.

We are especially proud of keeping historical evidence without allowing it to silently become a current claim, and of designing supplier comparisons that expose missing information instead of hiding it.

What's next

Our demonstration uses clearly labeled fictional supplier quotations and distinguishes recorded simulation examples from live provider evidence. Full live numerical validation and production readiness are not claimed.

Next, we want to complete real-run engineering verification, broaden geometry support, finish the combined live review package, and add an authorized supplier API.

Our goal is not an AI that declares a part ready. It is a workspace that helps engineers understand what readiness requires—and what evidence they still need.

Built With

• api
• fea
• onshape
• python
• webmcp