Protocols Create Markets

Two buyers, two mornings. One uploads a DXF and a STEP, picks a material and a finish, and gets a price he can act on immediately. The other emails a PDF drawing and a STEP, the rev letter is unclear, the tolerance block is generic, and the message says "same as last time." The part might be equally simple in both cases. Only one of those requests turns into something a shop can accept without a phone call.

This series is about rebuilding industrial coordination by tightening interfaces, so the work becomes legible to strangers before it becomes expensive. Claim (falsifiable): in a side by side trial on comparable custom part RFQs, a lightweight intake protocol that enforces revision lock, acknowledgement states, and explicit acceptance criteria will reduce median clarification cycles per RFQ by at least 30% and increase on time quote rate by at least 15% within 90 days, measured from the RFQ record, the quote PDF, and the acknowledgement receipt.

When I say "protocol" I mean a shared request shape plus a shared state machine, with receipts tied to artifacts — the drawing, the STEP, the inspection plan. No committee standard. No demand for perfect inputs. Just a small set of fields that forces ambiguity into named buckets, and a small set of states that forces silence to become visible. The control point is the RFQ packet, carrying a revision lock that points to the exact files that were quoted, and that lock follows the work into the PO and the traveler.

This is why verticalized shops can deliver instant pricing and fast parts. It's why shops and buyers think they want instant quoting. What they're all really saying is "let's be clear and stick with a protocol so I get what I want fast." There are pros and cons to every approach. Scaling it to work across many disparate shops is something we believe to be possible, but not easy. When done right, we have a functional market for US manufacturing.

Enforcing protocols

The mechanism is translation cost, and it shows up on the calendar as latency. In custom work the first expensive step belongs to the estimator: turning a drawing and a STEP into a quoteable job, deciding precedence, reading the tolerance block, inferring an inspection plan nobody wrote down. Every missing fact becomes a negotiation with risk, and every shop negotiates it differently, which is why two quotes at the same number are not actually comparable. When the request arrives as prose plus attachments, the "market" is a pile of private interpretations and the only protocol in the room is the email thread. What fixes that is a completeness check on the RFQ record that names what is missing out loud, instead of leaving it to live and die inside the estimator's head.

Verticalized shops are the cleanest proof that protocols create markets, because they make the protocol unavoidable by owning the intake loop. A platform that instant quotes sheet and plate work does not accept a PDF drawing and hope a human sorts it out later. It forces the request into a constrained shape up front. SendCutSend publishes its accepted file formats for quoting and says plainly that it does not accept PDFs or raster images for instant quoting, which pushes buyers toward DXF and STEP — inputs a machine can actually check. The artifacts are the protocol surface. The uploaded file becomes the unit of truth that pricing and production both reference.

OSH Cut makes the same point from a different angle: upload parts, set units, materials, finishing options, and quantities, then get instant pricing and design feedback through an online app. That flow is enforcement wearing the costume of convenience. Wrong units, missing bends, impossible features — each becomes a deterministic check, and "what did you mean" becomes an explicit selection that lands on a cut sheet and an order record. The control point is the ordered configuration, because it binds the buyer's intent to a specific set of manufacturing choices before the job ever hits a schedule board.

What lets these verticals scale isn't nicer customers. They converted translation into validation. The quote is bound to an uploaded DXF or STEP, the option set is explicit, and the platform can reject, flag, or price the risk before a human reviews anything. A buyer can be a total stranger, because the request is checkable and the acceptance criteria are already implied by the published rules, and the order can become a PO without a bespoke phone call. That is what "market" means in practice — strangers transacting at low friction because the request has a shared structure. Watch the quote record here: it points back to the file and the option set, and it flows into a traveler without anyone re-interpreting anything.

The transferable lesson is not "everyone should become a vertical." A general market spans processes, materials, and exceptions, so it cannot enforce one rigid upload template the way a sheet metal or machining platform can. It can still enforce a lightweight protocol that captures the minimum facts needed to quote, and it can do that without demanding perfect inputs. In practice that means hard gates and soft fields. Hard gates: revision lock for the drawing and the STEP, a precedence field, an identity bound to a real buyer role. Soft fields: "unknown" is a legal answer for finish, inspection plan, or cert packet, as long as it carries a priced assumption flag. Under both sits a state transition log — submitted, acknowledged, clarification requested, clarified, quoted, awarded, closed — with each state tied to an artifact like the quote PDF or the NCR record. And there's a truth about US manufacturing that the rigid-upload instinct misses: buyers don't always know their requirements, and they look to the shop to help connect the dots on manufacturability. That's where AI can carry the cost for US shops instead of shoving it back onto the buyer as a stricter form (see Paper No. 14).

What scaling actually looks like

Protocols scale markets in other industries because they replace bespoke negotiation with shared message shapes. FIX is the concrete example — a set of messaging specifications used for trade communications, standardizing message types and fields that mirror the steps of a transaction cycle. A manufacturing transaction has a cycle too: RFQ, quote, award, PO, shipment, dispute. Today almost all of it is carried by emails with attachments. The point isn't to copy finance. It's to accept that an RFQ and a quote are message types with required fields, and that the field list is the thing that lets strangers transact without a relationship first.

Manufacturing already has serious protocols. They just start too late for the small shop custom front door. X12 defines and maintains transaction sets that establish the data content exchanged for specific business purposes, which is what makes structured POs and invoices flow between enterprises. Those transaction sets assume you are already past the "what job is this" moment and into repeatable document exchange, and that usually implies stable identifiers and stable commercial relationships. For a one off RFQ anchored in a drawing and a STEP, the pain sits earlier — what the tolerance block applies to, what the inspection plan needs to be, whether the quoted assumptions will survive the buyer's expectations. So the RFQ protocol has to sit before the EDI layer and hand clean outcomes into the PO level protocols once the job is real.

QIF and MTConnect follow the same pattern: useful, real, downstream. QIF is positioned as an XML based, CAD agnostic standard that defines, organizes, and associates quality information like measurements, part geometry, and PMI, which is powerful once you are inside the measurement workflow and producing inspection results. MTConnect is described as an ANSI standard semantic vocabulary for manufacturing equipment data, providing structured, contextualized data without proprietary formats, which helps once the job is running and you want equipment state and telemetry. Neither one helps the estimator staring at a drawing and a STEP trying to work out what is even quoteable, because that problem is missing intent, missing acceptance criteria, and missing revision discipline. The control point stays where it started — the RFQ packet and the quote package, not the CMM report export or the machine data feed.

Implications

Put the protocol at intake and you can finally measure the bottleneck instead of guessing at it. Acknowledgement time becomes a metric because "acknowledged" is a state and not a feeling, and the RFQ record can tell no response apart from active rejection. Clarification cycles become countable because "clarification requested" ties to a specific missing field: revision lock, cert packet requirement, inspection plan. Quote to award improves for a duller reason than anyone expects — the buyer receives quotes that share a structure, every quote PDF names the same assumptions, and the PO references the same revision locked drawing and STEP. Then run a weekly report that ties acknowledgement time and clarification count back to the specific gaps in the RFQ packet. That report is the control.

Shared signals become feasible too, and that changes selection pressure across the whole market. Tie on time shipment, inspection report completeness, and NCR closure time to artifacts — the traveler, the CMM report, an NCR closure code — and performance becomes legible between strangers. It also creates a predictable counter pressure: participants will game any signal that is cheap to fake. Which is the entire argument for receipts over self attestation. When the closeout packet carries a cert packet, the inspection report, and any NCR with a closure artifact, the system can reward execution without asking anyone to trust a claim. Watch the closeout packet closely. It is where disputes either converge or metastasize.

Outro

If the United States wants manufacturing sovereignty, it has to reduce the cost of working with strangers, because domestic capacity does not matter if the interface is too expensive to use. The failure mode runs in a straight line — ambiguity turns into latency, latency turns into distrust, distrust turns into silence on the next RFQ — and you can read every step of it in the RFQ record as unanswered requests and endless clarification loops. The verticalized platforms already demonstrated the core truth: markets scale when the request is machine checkable and the states are explicit, even when the buyer is imperfect.

Which raises the next problem. Protocols only hold when identity and performance signals are anchored to artifacts like the PO, the traveler, the inspection report, and the NCR closure. Paper 16 is about verification and receipts.

Questions to Ask

1. When an RFQ arrives with a PDF drawing and a STEP, where is revision lock recorded, and can you prove later that the quote PDF referenced that exact rev letter? If you cannot, which part of your RFQ record or email thread is acting as the substitute?

1. Do you require an "acknowledged" state on every RFQ, and can you report median acknowledgement time from the RFQ record? If not, how many RFQs die as silence, and how often do you learn that only after a buyer calls back about the same drawing?

1. Which fields create the most clarification churn today — precedence, tolerance block interpretation, inspection plan, finish, or cert packet requirements? Can you tie each clarification to a named missing field in the RFQ packet instead of letting it live in an email thread?

1. Does every awarded job produce a closeout packet that includes the traveler, the inspection report or CMM report if required, and any NCR with a closure code? If that packet is missing, where do disputes actually originate, and how long do they stay open?

1. When you price assumptions, do you record them explicitly in the quote package, and does the PO acknowledge them by referencing the same revision locked drawing and STEP? If you do not record assumptions, are you actually pricing risk, or are you hoping the tolerance block and tribal knowledge will save you?