Industrialist Paper No. 11

The Universal Request Object

Preface: I have been in software long enough to distrust anything labeled “universal.” Most of those efforts are covert standardization campaigns that collapse under edge cases. This one has a narrower goal. The network needs a single internal packet to route work, measure friction, and attach evidence, even while buyers and suppliers keep their own tools, dialects, and habits. Essentially, Lean standard work for intake plus operational definitions for cycle time, clarification loops, and revision churn. The next 14 papers build on this object because you cannot analyze or automate what you cannot represent, and representation is something a translation layer can provide without forcing anyone to change how they run their shop.

No routing without representation

A buyer forwards a drawing PDF and a STEP file with the note “can you take this.” The subject line says Rev C, the title block says Rev B, and the STEP has no revision metadata. The estimator opens the tolerance block, scans the notes for finish and cert language, and starts building a traveler skeleton in their head: setups, fixturing risk, inspection plan, and the one question that will prevent a re-quote after the PO. The work is not “an RFQ” yet. It is intent plus constraints, scattered across artifacts.

In the same hour, the same buyer needs overflow capacity for op 30 only, needs a metrology house to run a CMM report on a ballooned legacy print, and needs material with MTRs because traceability will be audited. Those asks land in different channels because the software landscape assumes demand comes in one shape. It does not. The national supply chain pays for that assumption in clarification loops, misroutes, and, ultimately and perhaps most punishingly, incumbency lock.

This series argues that American manufacturing already exists as a national system, but it is hard to query, hard to verify, and therefore hard to coordinate. 

This Paper’s Claim: When a mixed stream of manufacturing transactions is normalized into a single structured Request object before (or during) routing, median time-to-commit and clarification loops per transaction fall, while dispute rate tied to ambiguity does not rise, compared to free-form intake.

Definition: A universal Request object is a versioned, structured record that carries scope, inputs, constraints, acceptance criteria, time bounds, and closure evidence in a way that can be computed on and audited.

Mechanism: representation creates routability

Routing is computation applied to work packages. Computation requires stable inputs. A “please quote” email with attachments is unstable because the real constraints are implicit and the receiver has to infer them, then re-infer them after questions come back, often with a new drawing revision and a new note buried on page 2. That inference work is the hidden labor inside quoting, subcontracting, and inspection scheduling, and it becomes the bottleneck long before spindle time does.

A Request object makes unknowns explicit and versionable. It gives the network a unit that can be routed, paused, clarified, committed, and closed with evidence. It also lets both sides measure the same operational edges: how many clarifications happened, whether revision churn occurred after routing, whether acceptance evidence was provided, and whether the transaction closed cleanly. A shop does not need to trust a sender’s tone when the request carries declared constraints, declared acceptance, and an audit trail back to the drawing PDF, the STEP, the traveler excerpt, or the cert packet requirement.

Paper 1 argued that manufacturing is a Tower of Babel: too many dialects inside the work package. A universal Request object does not solve that by imposing a new language on the shop floor. It solves it the way routers solve incompatible endpoints: with translation into a canonical internal packet plus adapters back out. The dialects remain. The computation becomes possible. The key is that we apply it in routing. 

Manufacturing demand is broader than RFQs

A coordination system fails when it treats “RFQ for parts” as the only unit of demand. Real demand includes at least these transaction types, each tied to concrete artifacts and acceptance expectations:

• Part fabrication: drawing PDF, STEP, BOM line, quantity, finish, tolerance scheme, cert packet expectations.
• Overflow and ops-only subcontracting: traveler excerpt, op boundaries, datum references, fixture assumptions, in-process inspection expectations.
• Subcontract special processes: spec callouts, masking notes, process cert requirements, acceptance evidence.
• Inspection and metrology: ballooned print, CMM program scope, report format, measurement uncertainty expectations.
• Material sourcing: material spec, substitutions allowed, MTR requirement, lead time bounds.
• Tooling and workholding: fixture interfaces, machine envelope constraints, probe routine expectations, gage plan.
• Maintenance and repair: machine model, symptoms, downtime window, on-site constraints.
• Used equipment and commissioning: exact model, control version, rigging constraints, inspection and commissioning scope.
• Engineering support: DFM review, GD&T interpretation, drawing cleanup, ECO impact timing.

Today these demands fracture into incompatible forms. A PO line item in an ERP cannot carry the same acceptance structure as an inspection request. A maintenance ticket does not carry drawing precedence and revision lock. A metrology request often travels as a PDF plus phone call because the “system” cannot represent the intent and the reporting constraints. The result is that a network cannot treat inspection capacity, special process capacity, and machining capacity as interchangeable resources that can absorb overflow through structured subcontracting.

Existing standards, and the gaps covered

There are serious standards in manufacturing data exchange. The gap is that they cover specific domains, and the Request problem spans domains.

QIF (Quality Information Framework, ISO 23952) covers metrology and quality information: measurement plans, results, resources, and related quality data structures. It is a strong foundation for inspection data exchange and quality evidence, and it is explicitly about the QIF information model and its schema artifacts. It does not aim to represent a buyer’s full work intent across machining, subcontract ops, material sourcing, maintenance, and engineering support as a single routable packet. 

MTConnect standardizes a semantic vocabulary for manufacturing equipment data and enables retrieving machine status and performance data for monitoring and analysis. It solves “what is the machine doing” and “how do systems read device data” using a structured model. It does not solve “what is the buyer asking for” or “what acceptance evidence closes the transaction.” 

OPC UA companion specifications provide information models for specific vertical domains so different systems can share machine and process concepts through a common model. That helps interoperability around equipment and industrial data. It does not define a cross-company request grammar for messy work packages, revision precedence, acceptance evidence, and closure. 

OAGIS (Business Object Documents) covers enterprise document exchange patterns like RFQs, quotes, purchase orders, and maintenance orders, and it is built for application-to-application integration using defined business nouns and verbs. It is closest to procurement and ERP integration. In practice it lives in the enterprise boundary and assumes higher discipline than the long tail of job shops and custom work can maintain, especially when the “real spec” is still a PDF drawing and a STEP that do not agree. 

These standards are not failures. They are domain-accurate. The universal Request object is an integration primitive that sits above them, because routing work across firms needs one thing those standards do not attempt to provide: a single packet that can represent intent plus constraints plus acceptance plus evidence, even when the inputs are imperfect.

The Universal Request Object, as a system artifact

A Request Object should be defined as a versioned interface with required fields, a state machine, routing rules, and a closure discipline. The serialization format does not matter. The semantics do, because the system must compute on the request, audit it, and measure friction without relying on private context.

Paper 1’s Tower of Babel constraint forces one design choice. The Request object is a canonical internal representation, not a new standard imposed on buyers or suppliers. Adapters translate messy inbound reality, email threads, portal exports, PDFs, STEP files, travelers, vendor packets, into the canonical request. Adapters also translate back out into the shapes participants already use. The router speaks one language. Participants keep speaking many.

This is how you avoid adding another dialect. The system does not ask shops to change their ERP, their quoting workflow, or their traveler format. It asks the coordination layer to do the hard work of normalization so routing, verification, and reputation can run on stable primitives.

Interface

A minimal Request object carries these fields, each tied to a real manufacturing artifact or control point:

• Request ID and Version: stable identifier and monotonic change control, used to lock revisions and track churn across a drawing PDF, STEP, traveler excerpt, and supplier onboarding packet.
• Request Type: part fabrication, ops-only overflow, special process, inspection, material sourcing, tooling, maintenance, used equipment, engineering support, plus commercial onboarding and compliance flowdown. Commercial onboarding includes vendor registration, terms, net terms, insurance requirements, audits, and customer-specific onboarding forms.
• Scope: summary plus optional op boundaries, quantities, and units, because “op 30 only” routes differently than “complete part,” and “complete supplier onboarding packet” routes differently than “quote the job.”
• Inputs: pointers to artifacts plus content fingerprints. For production work this includes drawing PDF, STEP, BOM line, traveler, inspection plan, spec, prior NCR, PO reference. For enterprise friction this includes NDA, MSA or terms redlines, net terms application, supplier portal invite link, quality flowdown packet, audit checklist, and insurance requirements. Fingerprints exist because filenames lie, portal uploads change without notice, and revision drift is common.
• Constraints: material spec and traceability, finish and special process requirements, tolerance scheme reference, critical features, shipping constraints, compliance constraints, plus commercial constraints such as payment terms, invoicing requirements, insurance thresholds, portal requirements, and mandated quality system flowdowns.
• Acceptance: required evidence and report formats. For production this includes cert packet, MTR, CMM report, FAI report, process certs, and inspection plan expectations. For onboarding this includes countersigned NDA, approved net terms, completed vendor registration, flowdown acknowledgement, and audit outcome with recorded findings closure requirements.
• Time Bounds: need-by date, earliest start, expedite allowed, response SLA, plus onboarding deadlines that gate award timing.
• Unknowns Register: explicit missing or ambiguous items with severity, including “stop and ask” items that block quoting or commitment. Unknowns can be technical, like drawing-model precedence, or commercial, like net terms approval status.
• Identity and Approval: who is asking, who can approve changes, and where approvals are recorded, including the legal, finance, and quality contacts for onboarding when those are the actual gating functions.
• Closure Evidence Links: cert packets, CMM reports, NCR dispositions, shipment proof, plus onboarding closure artifacts like executed agreements, net terms approvals, portal confirmation, audit pass record, and documented flowdown acknowledgements, each bound back to the Request ID and version lineage.

That list reads obvious to a shop because it is the same skeleton an estimatoror an ops lead reconstruct manually. The difference is that the skeleton becomes explicit, portable, computable, and measurable across company boundaries, including the administrative work that enterprises force onto suppliers.

State machine

The Request object needs a visible state machine because ambiguity is a first-class state, not an error. A minimal set of states that survives real shop behavior:

• Draft: early intake, extraction incomplete, unknowns allowed, onboarding packet may be partial.
• Ready to Route: required fields present, no blocking unknowns.
• Routed: sent to recipients with routing record, including whether routing is for quote, for ops-only capacity, for inspection, or for onboarding completion.
• Clarification: blocked by a declared unknown tied to a field, technical or commercial, such as drawing precedence or net terms status.
• Quoted: quote attached and version-locked for validity, or for onboarding requests, a declared service commitment attached, such as onboarding completion lead time and required customer actions.
• Committed: award reference attached, revision lock satisfied, and any gating onboarding acceptance conditions recorded as satisfied or explicitly waived.
• In Flight: traveler and or subcontract ops underway, or onboarding tasks actively being executed, such as portal registration and audit scheduling.
• Closed: acceptance evidence attached, closure complete, including shipment and cert packets, or executed agreements and audit outcomes.
• Cancelled: cancellation reason code recorded.

The control point is that blocking unknowns push the request into Clarification with a version increment, instead of letting uncertainty smear across email threads and portal uploads. That discipline reduces misroutes and reduces rework caused by revision churn and commercial gating surprises.

Routing rule

Routing uses the Request type and constraints to compute a candidate set, and it routes to the right kind of capacity. Production requests route to shops. Inspection requests route to metrology. Special process requests route to qualified subcontractors. Onboarding requests route to administrative and quality capacity, either inside a supplier organization or through a defined service function.

Now, this is where the magic happens. It’s easy to just say routing blocks when information is missing. But that’s not real-world. Routing must treat ambiguity as a graded signal, not a binary gate. Some uncertainty is routine and can be priced, scheduled, or clarified later. Routing computes candidates from request type and constraints, then attaches an uncertainty profile, STOP, CHECK, and RISK, to the packet. Most gaps produce CHECK or RISK and the request still routes, because the point is to surface ambiguity early, not to pretend it can be eliminated. Routing blocks only on hard stops, conditions that prevent a recipient from forming a valid quote or commitment, like a drawing and model conflict without declared precedence, a missing material spec when traceability is required, or an enterprise audit requirement with no scope owner or deadline. Every stop, check, and risk is recorded as a field-level reason, because those reason codes are the feedback loop that reduces clarification cycles over time.

Metrics

A Six Sigma practitioner will ask for operational definitions and a measurement plan. The Request object supplies both by construction:

• Time-to-commit: elapsed time from Ready to Route to Committed, segmented by request type, including onboarding.
• Clarification loops: count of transitions into Clarification per request.
• Misroute rate: percent of routed recipients who could not accept due to missing or incompatible constraints, including technical mismatches and onboarding gating mismatches.
• Revision churn: number of version increments after routing and before commit, including churn caused by terms redlines or revised flowdowns.
• Disputes tied to ambiguity: fraction of NCRs, disputes, or commercial escalations whose root cause maps to a missing or conflicting Request field.

These metrics are falsifiable. The experiment can be simple: compare a baseline period of free-form intake to a period where routing requires a Request object for the same request types, then segment by type and include a guardrail, like defect-related disputes, so you do not shift pain downstream.

Test fixtures

A Request grammar must survive ugly inputs. A small fixture set keeps the system honest:

• Revision conflict between subject line, title block, and model fingerprint, with missing precedence.
• Ops-only overflow with datum references but missing drawing precedence and missing inspection expectations.
• Traceability required with missing material spec and missing MTR expectation.
• Inspection-only request on a rasterized scan with a required report format and missing ballooning references.
• Special process request with masking notes and required process cert evidence.
• Enterprise onboarding packet with custom NDA redlines, net terms application, supplier portal requirements, and a quality flowdown that introduces new acceptance evidence, with missing owner contacts and missing due date.

If your Request grammar cannot represent these, it cannot route the real world, and it cannot measure where the friction actually lives.

Implications

A network that cannot normalize demand into a Request object will keep over-awarding to incumbents because incumbents carry shared context that substitutes for representation. That reduces supplier diversity, increases concentration risk, and slows recovery after a disruption, and it also hides enterprise onboarding friction as invisible overhead that cannot be throttled or priced.

A network that normalizes into Requests will discover that many capacity problems are information problems. When time-to-commit improves without adding machines, the binding constraint was intake ambiguity and coordination latency. The same is true for enterprise paperwork. When onboarding cycle time becomes visible and routable, the organization can choose policy with data instead of anecdotes.

A universal Request object also creates the substrate for verification and reputation. Closure evidence attached to the Request becomes portable signal. Without a Request ID that binds drawing PDF, traveler, cert packet, onboarding packet, and audit outcome into one lineage, outcomes cannot compound into reputation, and the system will continue to route by private relationships and habit.

Outro

Sovereignty depends on being able to allocate domestic capability under stress, with enforceable constraints and verifiable closure. A nation can have machines and skilled labor and still fail if demand arrives as unparseable blobs that require private relationships to interpret. The failure mode is ambiguity that turns routing into rework.

Paper 12 narrows the next control point: how a free-form RFQ becomes a Request, what the system can infer, what must be declared, and how missing facts become explicit unknowns instead of hidden traps.

Questions to Ask

1. What is your operational definition of a “clarification loop,” and can you tie each loop to a missing field like revision lock, material spec, or required acceptance evidence?
2. How often does revision churn occur after a request is routed, and do you have a stable identifier that binds the drawing PDF, STEP, and traveler excerpt across that churn?
3. What is your misroute rate, and how many misroutes trace back to under-specified constraints rather than true lack of capability?
4. Where does closure evidence live today, such as cert packets, MTRs, CMM reports, and NCR dispositions, and can you link it back to the original intake packet?
5. If you had to route ops-only overflow tomorrow, which traveler fields and datum references would you require before you would let the system route without a phone call?