Industrialist Paper No. 13
The Minimum Viable Work Package
At 4:12 p.m. the quote desk gets the usual bundle: a drawing PDF, a STEP, and one line that says “need it fast.” The email subject says “Rev C,” the title block on the PDF says “Rev B,” and the STEP filename is “bracket_final.step,” which tells you nothing. The estimator opens the tolerance block, skims the notes for finish, and then stops at the same point every experienced estimator stops: you cannot price risk until you know which artifact governs, what evidence closes acceptance, and which requirements are real versus implied.
This series is a systems blueprint for coordinating American manufacturing without central command, by making work routable and verifiable across company boundaries using artifacts like drawings, travelers, and closure evidence. Paper 11 gave the network a canonical Request object; Paper 12 showed how free form RFQs become structured requests without forcing shops into a portal. This paper draws the line the quote desk already draws in practice, then makes it explicit so the system can enforce it and learn from it.
Paper No. 13’s Claim: When inbound requests are promoted to a Minimum Viable Work Package before quoting, meaning drawing and model precedence plus revision lock, material and certification requirements, tolerancing scheme, finish and special process requirements, inspection requirements, and shipping constraints are explicitly recorded against the drawing PDF and STEP fingerprints, the median clarification cycles per quote and the NCR rate attributable to spec ambiguity both fall compared to quoting from document bundles.
Definition: A Minimum Viable Work Package (MVWP) is the smallest version controlled packet of artifacts and declared constraints that lets a shop issue a quote and draft a traveler without hidden assumptions, while recording any remaining uncertainty as explicit questions or buyer approved defaults tied to the same revision locked packet.
Mechanism: a quote is a commitment gate, and the gate needs a packet-of-record
Every serious quality system treats “commitment” as a controlled moment, because after commitment you are on the hook for meeting requirements whether you liked the inputs or not. ISO 9001’s contract review concept is blunt about the direction of travel: review requirements before committing, retain documented information about what you reviewed, and control changes when requirements change. An estimator does this anyway with a drawing PDF, a traveler skeleton in their head, and a mental list of the two missing facts that will trigger rework if they guess.
The MVWP is simply that contract review gate made concrete for quoting, with one additional discipline: a packet-of-record. A packet-of-record is the controlled drawing PDF and STEP, plus a cover sheet that records the decisions the estimator had to make to quote honestly, and it carries a packet ID derived from fingerprints or a revision lock token. That packet ID shows up on the quote PDF, the traveler header, and the inspection report request, so “what did you build to” is not a debate that starts over in receiving.
The estimator’s three decisions, and why they are always the same
Before an estimator can send a quote, they have to make three decisions that map directly to downstream artifacts. First, they must decide what governs, meaning drawing versus model precedence when the PDF and the STEP disagree, and they need a revision lock tied to the title block and file fingerprints. Second, they must decide what closes acceptance, meaning whether the job requires an MTR in the cert packet, a CMM report, an FAI packet, or a specific report format that receiving inspection will enforce. Third, they must decide what can be assumed safely, meaning which silent details the shop can fill in without creating a dispute later, and those assumptions must be written down on the cover sheet so the quote is not secretly priced on an invisible spec.
Those decisions are not paperwork, they are defensive work the shop does to avoid late surprises that explode into NCRs. If the decisions are not recorded against the drawing PDF and STEP, they will be re-litigated when the PO arrives, again when the traveler is written, and again when a receiving inspector holds parts against an expectation that only existed in someone’s head. MVWP exists to force those decisions forward, bind them to the packet, and make the remaining uncertainty visible as a short, prioritized clarification list.
Machining example: precedence and tolerance scheme determine whether the traveler is even coherent
In machining, the classic failure starts with a mismatch between the STEP geometry and the drawing’s title block revision, followed by a tolerance scheme that is either incomplete or interpreted differently by two parties. If the model has a fillet that the drawing omits, or a hole pattern that does not match the PDF, the shop has to choose what to cut before a fixture plan exists, and the wrong choice becomes scrap, not a question. The MVWP cover sheet forces an explicit “spec of record” line, plus the revision lock token that binds the drawing PDF and STEP to the quote and traveler, so a later “quick update” is treated as a new packet version, not a casual email attachment.
This is also where model based definition realities collide with small shop life. Standards like ASME Y14.41 exist specifically because digital product definition data sets can be the defining authority, and that authority has to be stated and controlled, especially when you are using an annotated model with or without a drawing sheet. Most custom job work still arrives as PDF plus STEP, and the MVWP’s job is not to win a standards argument. The MVWP’s job is to force the buyer to declare precedence and lock revision, because without that declaration the quote is a guess, and the traveler is a liability.
Sheet metal example: bend assumptions and grain direction create silent defects that show up at assembly
Sheet metal quoting looks fast until it hits forming and finish assumptions that the drawing packet never stated. Grain direction relative to the bend line affects cracking risk and bend integrity, and the difference between bending with the grain versus across it is not theoretical, it is a real driver of whether a flange survives. If a drawing PDF has tight bends and cosmetic requirements but never constrains grain direction, bend radius, or which face is cosmetic, the estimator can only price by guessing, and those guesses surface as assembly fit problems after the parts leave the brake.
The MVWP makes those assumptions explicit in the packet-of-record, and it ties them to the traveler and inspection plan. The cover sheet records whether grain direction is constrained, whether bend deduction is fixed or shop standard, and whether flat pattern comes from the STEP, from the PDF, or from the shop’s CAM export. When this is missing, clarification loops happen at the wrong time, on the floor with parts half-formed, not at the quote desk with a clean drawing PDF and a stable packet ID.
Welding example: symbols and examination expectations define acceptance, not just geometry
Welding is where acceptance criteria can be completely undefined even when the drawing PDF looks “complete.” A weld symbol can specify type, size, and other requirements, and the symbol system exists to communicate process and examination information concisely in the drawing block. If the packet never states the governing code, the required documentation, and whether NDE is expected, the shop is pricing a job without knowing what “pass” means, and receiving inspection will define pass later in a way that the shop cannot satisfy without rework.
The MVWP forces the symbol driven requirements into the packet-of-record and into the traveler before the quote is issued. The cover sheet records required process documentation, any WPS or welder qualification constraints if applicable, and the acceptance evidence required at close, even if that evidence is simply “visual inspection only” documented on an inspection plan. The result is fewer late fights, because the cert packet and any NDE report expectations were declared before anyone welded metal.
Finish and special processes: the difference between “anodize” and a real spec is where rework hides
Finish is the quiet multiplier that turns a clean machining quote into a surprise schedule blowup. “Anodize” is not a requirement, it is a category, and specs like MIL-A-8625 exist precisely because type and class matter, including distinctions like Type II versus Type III and whether dyeing or hardcoat behavior is intended. If the drawing note says “anodize black” but does not state the type, class, masking, and cosmetic expectations, the estimator either pads margin, asks questions, or loses money later when parts come back from finishing and do not meet an unstated expectation.
MVWP handles this with one hard rule and one relief valve. The hard rule is that finish and special process requirements that affect fit, wear, corrosion, masking, or acceptance evidence must be declared on the cover sheet and bound to the drawing PDF. The relief valve is that the system can propose a candidate finish spec extracted from the drawing notes, then ask only the one question that changes routing and inspection, such as “Type II dyed black versus Type III hardcoat,” and it records the buyer’s answer as a packet update, not as tribal memory.
What the system infers, what it flags, and what it routes to a human
A Minimum Viable Work Package is not created by making buyers type more. It is created by extracting what is already present in the drawing PDF, the title block, the tolerance block, and the notes, then enforcing a short decision list where missing facts are made explicit. The system should auto-read revision, units, material callouts, tolerance blocks, and common process keywords, then compare them across artifacts and flag mismatches as blockers, especially revision conflicts between subject line, title block, and file fingerprints.
When extraction cannot resolve a decision that changes liability, the request becomes a clarification state with a question that names the exact artifact conflict. “PDF Rev B, email says Rev C, STEP untagged, which governs” is a real question an estimator asks because it prevents a wrong traveler, a wrong fixture plan, and a downstream NCR. When extraction yields a safe default, the system records an explicit buyer approved assumption on the cover sheet, because assumptions that are not recorded are the seed crystals for disputes in receiving inspection.
Implications
A network that quotes from loose RFQ bundles will keep selecting for incumbents, because incumbents have shared context that substitutes for a packet-of-record, and that context is not portable. Quote desks will keep defending themselves with padding, silence, and phone calls because they are rational responses to an unstable drawing PDF, an untagged STEP, and unclear acceptance evidence. Buyers will interpret that defense as “domestic is slow,” even when machine time is simple, because the real bottleneck is contract review work happening in private instead of being captured once on a cover sheet tied to a packet ID.
A network that enforces MVWP promotion will discover that many lead time problems were actually spec stability problems. Clarification cycles drop because the three estimator decisions are forced early and bound to the traveler and cert packet, and NCRs tied to ambiguity drop because acceptance evidence is declared before the first chip is cut or the first weld is laid. The system also gets a measurement loop that generalists can understand, because it can count revision churn events, clarification cycles, and ambiguity driven NCRs per packet-of-record, then improve extraction and question routing where the data points.
Outro
Sovereignty depends on being able to commit domestic capacity under stress with enforceable requirements and verifiable closure, using drawings, travelers, and cert packets that do not drift as they cross firms. The practical failure mode is spec drift, where the “real requirements” change between quote, traveler, and receiving inspection because precedence, revision lock, and acceptance evidence were never bound to a packet-of-record. Paper 14 takes the next step and tightens closure, the cert packet and inspection evidence that turns “we shipped” into “we closed,” so reputation can compound across transactions instead of resetting every time.
Questions to Ask
What is your packet-of-record today, and does your quote PDF and traveler header reference a specific drawing PDF revision and a STEP fingerprint that can be audited after an NCR?
In your last ten quotes, how many clarification cycles were caused by revision ambiguity, tolerance scheme ambiguity, finish ambiguity, or missing acceptance evidence like an MTR or CMM report, and do you record the reason code against the RFQ record?
Where do buyer approved assumptions live, such as grain direction, masking, sampling plan, or inspection report format, and can you point to the cover sheet or traveler note where that assumption is recorded?
When requirements change after quoting, do you treat it as a new packet version with a new validity window, or do you let changes smear across email attachments and side notes on the drawing PDF?
For welding and special processes, what is your minimum acceptance definition, meaning the weld symbol interpretation, any examination expectation, and the evidence that must ship in the cert packet for receiving inspection to accept the work?