Feasibility is a property of the workflow, not of the model. Two supplier-compliance workflows can consume the same documents, run on the same stack, and produce output that looks identical on the page — and only one of them will survive an OEM review. That difference is decidable in advance, before any pilot is scoped, by scoring the workflow rather than shopping for a model.
The pattern we see most often in automotive supplier-compliance programmes is a pilot chosen by volume. Someone counts the document types, finds that supplier questionnaires or deviation packages dominate the queue, and points a generation model at whichever pile is loudest that quarter. Sometimes that lands well. Sometimes the team discovers at first OEM review that the workflow they automated was the one where the AI’s output is the compliance assertion, not a draft of it — and there is no prompt, no fine-tune, and no retrieval design that fixes that.
The four properties that decide feasibility
Score each candidate workflow against four questions. They are ordered so that a failure on an earlier one usually makes the later ones moot.
- Is the source input structured and retrievable? Can the pipeline point at a specific supplier artifact — a questionnaire field, a material certificate, a test report revision — as the origin of each generated statement? If the input is an unindexed pile of PDFs and email attachments, you are automating invention, not drafting.
- Is the output a draft or an assertion? A draft is text a reviewer will check. An assertion is a conclusion a reviewer will rely on. This is the single highest-leverage distinction in the rubric.
- Can a reviewer reconcile output back to source, line by line? Not “can they read both documents” — can they take a generated clause and land on the field that produced it, with its revision state? Traceability that lives in the engineer’s head or in the prompt ordering does not count.
- Where does an error surface — internally or at the OEM? Errors caught in an internal reconciliation step cost a rework loop. Errors caught in an OEM compliance finding cost a remediation cycle, and in our experience that remediation cycle is the largest single line item in the whole economics of document automation.
How do you score a workflow you have never automated?
Run the rubric on the existing manual version. The four properties are all observable today: look at where the source evidence actually lives, read the sign-off language on the finished document, and ask a reviewer how long it takes them to trace one statement to its origin. If a human reviewer cannot reconcile the current manual output back to source line by line, automation will not create that ability — it will hide its absence behind fluent prose.
Workflow-by-workflow feasibility
| Workflow | Source structured? | Output type | Line-by-line reconcilable? | Error surfaces | Verdict |
|---|---|---|---|---|---|
| Questionnaire pre-fill | Yes — governed answer library keyed to prior evidence | Draft | Yes, per answer | Internal review | Feasible |
| Evidence-pack assembly | Yes — named artifacts with revision state | Draft + index | Yes, per section | Internal review | Feasible |
| Multi-vendor reconciliation | Partly — normalisation required first | Draft + flagged disagreements | Yes, per field alignment | Internal review | Feasible with extraction discipline |
| Gap-list triage across a supplier portfolio | Yes — derived from pack completeness | Prioritised list, not evidence | Yes | Internal | Feasible as routing, not output |
| Conformity assertion | Varies | Assertion | No — the conclusion has no source line | OEM | Not feasible |
| Deviation adjudication | Rarely | Assertion + judgement | No | OEM | Not feasible |
The three workflows on the feasible side share one structural property: automation moves text around while the traceability chain stays intact. Questionnaire pre-fill retrieves an answer that already has an evidence owner. Evidence-pack assembly collects artifacts that already exist and indexes them. Multi-vendor reconciliation aligns twelve supplier answers to one requirement schema and — done properly — makes every disagreement explicit rather than averaging it away.
Conformity assertions and deviation adjudication fail on property two, and failing property two is terminal. When the output is “this supplier conforms” or “this deviation is acceptable”, there is no source field the sentence derives from. The sentence is the new fact. A reviewer cannot reconcile it; they can only agree or disagree with it, which means they are now reviewing a model’s judgement instead of a supplier’s evidence. That is the boundary we treat as non-negotiable, and the reasoning behind it is developed further in drafting assistance versus compliance adjudication.
When the same document sits on both sides
The hardest cases are workflows where the artifact looks identical in either mode. A supplier questionnaire response is a draft when the answer is retrieved from governed evidence and the reviewer confirms the retrieval; the same response becomes an assertion when the model infers an answer no supplier input supports and the reviewer has no way to tell which is which. The document is the same. The workflow is not.
The practical test: cover the generated text and ask what the reviewer would have to do to reproduce it. If the answer is “look up the source field”, it is drafting. If the answer is “form a view”, it is adjudication. We apply this test per step, not per document type, because most real workflows contain both — and the automation boundary belongs at the seam, not at the document edge.
Partial automation for high-volume workflows that score badly
A bad feasibility score is not a reason to leave a high-volume workflow untouched. It is a reason to automate the parts of it that are not the assertion:
- Retrieval and assembly of the inputs the adjudicator needs, with source references attached — the reviewer still decides.
- Completeness checking — flag missing, stale, or superseded supplier inputs loudly rather than filling gaps.
- Consistency detection across revisions, surfacing where a supplier’s current answer contradicts an earlier accepted one.
- Prioritisation of which packages need reviewer attention first, treated as routing rather than as evidence.
Each of these keeps the human on the assertion while removing the search-and-collate work around it. That is usually where the reviewer-hour savings actually live.
Sequencing across an onboarding programme
Order matters more than breadth. A workable sequence starts with questionnaire pre-fill, because the answer library it forces you to build is a prerequisite for everything downstream. Evidence-pack assembly comes second, since it consumes that same governed source mapping. Multi-vendor reconciliation comes third, because it needs both the normalised extraction layer and enough packs in flight to be worth the schema work. Adjudication-class workflows get partial automation only, at any point, and never graduate.
The metric that tells you whether the sequencing worked is not throughput. It is pilot abandonment. Teams that scope by workflow property rather than by document volume tend to retire fewer pilots after first OEM review — an observed pattern across our regulated-document engagements, not a benchmarked rate. Alongside that, track supplier onboarding cycle time on the automated subset only, reconciliation throughput per reviewer-hour, and traceability completeness on generated documents. Blended programme-wide numbers hide exactly the distinction this rubric exists to make.
This feasibility scoring is the intake step for a broader supplier-compliance document pipeline; the structural argument for why traceability governs the whole thing sits in our work on supplier-compliance document automation in automotive, and the engagement side of that work is described under our services. The same four-property test transfers to pharma supplier qualification with different reviewers and the same failure mode, which is a useful way to separate the pattern from the automotive specifics.
One thing this rubric does not settle: how much of a workflow can be automated before the reviewer’s attention quietly degrades from checking to skimming. We do not have a clean threshold for that, and we would not trust one that was offered without measurement.
Frequently Asked Questions
What does asking which supplier-compliance document workflows are AI-feasible in automotive mean in practice? On Supplier Compliance Document Workflows, the short answer is this. It means replacing a single yes/no question about AI and documents with a per-workflow score. In practice you enumerate the document workflows in the supplier programme — questionnaire handling, evidence-pack assembly, reconciliation, conformity assertions, deviation handling — and evaluate each one separately against fixed properties before committing a pilot.
Which four workflow properties decide feasibility, and how do you score a workflow against them? Whether the source input is structured and retrievable, whether the output is a draft or an assertion, whether a reviewer can reconcile output back to source line by line, and whether an error surfaces internally or at the OEM. Score them on the existing manual workflow, since all four are observable before any automation exists, and treat a failure on the draft-versus-assertion property as terminal.
Which specific supplier-compliance workflows sit on the feasible side, and why? Questionnaire pre-fill, evidence-pack assembly, and multi-vendor reconciliation. All three move existing text and evidence around while the traceability chain from supplier input to generated statement stays intact, so a reviewer can still verify each output against its named source.
Which workflows should stay manual because the output is a compliance assertion rather than a draft? Conformity assertions and deviation adjudication. In both cases the generated sentence is a new fact rather than a restatement of a supplier input, so there is no source line for a reviewer to reconcile against — they can only agree or disagree with a model’s judgement.
How do you tell a drafting workflow from an adjudication workflow when the document looks identical? Cover the generated text and ask what the reviewer would have to do to reproduce it. If they would look up a source field, it is drafting; if they would have to form a view, it is adjudication. Apply the test per step rather than per document type, because most real workflows contain both.
If a high-volume workflow scores badly, what partial automation is still worth doing? Automate everything around the assertion: retrieving and assembling the inputs with source references attached, checking completeness and flagging stale or missing supplier inputs, detecting contradictions across revisions, and prioritising which packages a reviewer sees first. The human keeps the assertion; the search-and-collate work goes away.
In what order should a supplier-compliance team sequence workflows across an onboarding programme? Questionnaire pre-fill first, because it forces the governed answer library everything else depends on; evidence-pack assembly second, since it consumes the same source mapping; multi-vendor reconciliation third, once the normalised extraction layer exists. Adjudication-class workflows receive partial automation only and never graduate to full automation.
Document workflows that tolerate AI error rates
Requirement extraction from supplier datasheets, cross-reference validation, and formatting unification handle mistakes gracefully because engineers review every delta; root-cause narratives and hazard arguments do not. Revisit it when your workload shifts.
