Ford rewrites 13,000 engineering requirements in 4 hours instead of 2,170

The workflow before#

Ford was moving hundreds of thousands of engineering requirements out of Polarion and VSEM and into JAMA. Requirements are the contract between engineering teams, and a vague one turns into a design argument or a test gap later. So each had to be rewritten to the INCOSE and EARS standards for clear, testable requirements, and that took a skilled engineer about 10 minutes. One batch alone held 13,035 requirements, roughly 2,170 hours of engineering time. Then peer reviewers had to check by eye that each rewrite still meant what the original said. That's months of skilled work pulled off vehicle programs to reformat text.

What we built#

We built an LLM pipeline inside Ford's private Azure tenant that does the rewriting and checks its own work. It takes raw requirements, rewrites each one to INCOSE standards, scores the result and refines it until it passes. A second model confirms the meaning hasn't changed. Engineers only see the requirements the pipeline couldn't get right on its own.

Rewrites to the standard at batch scale

Requirements come out of Polarion and VSEM in batches, and the model rewrites each one using INCOSE and EARS patterns. A batch of 13,035 rewrites in about two and a half hours. The models are closed-source and run privately in Ford's own Azure environment, because proprietary engineering data can't leave Ford's boundary.

A score and refine loop

Every rewrite is scored by JAC, JAMA's quality scoring connector, against the rules JAMA itself applies. A low score sends the requirement back for another refinement pass. We built the loop around JAMA's own scoring so that a requirement that passes here also passes once it lands in the target system.

A meaning check on every rewrite

A second model runs in parallel and scores semantic similarity between the original and the rewrite. A requirement can't pass if its engineering meaning has drifted, however clean the new wording is. We kept this check separate from the rewriting model on purpose: the system doing the writing shouldn't also grade whether it kept the meaning.

Engineers on the exceptions

Anything that still falls short after refinement goes to an engineer review queue with its scores attached. Engineers spend their time on the hard cases, the ambiguous or conflicting requirements that need a judgment call, instead of reformatting thousands of clean ones.

How we delivered it

We built the pipeline alongside Ford's requirements engineers and proved it on a real migration batch of 13,035 requirements, measuring time and quality against the manual baseline. The full batch took about four hours: two and a half to rewrite, one and a half to score. Passing requirements load directly into JAMA, so the pipeline slots into the migration Ford was already running.

Before and after#

What's next#

The same rewrite, score and refine loop applies to the rest of the requirements backlog. The bigger opportunity is using it at authoring time, so a new requirement gets checked against INCOSE as an engineer writes it, instead of being caught and fixed during the next migration.