The Capacity Ledger is the record of what we said would happen and what actually happened — per shop, per packet, per feature class, accumulated one job at a time. Routing consumes it. The date guarantee is underwritten from it. Once a month it becomes a public index.
It publishes no figures yet. Nothing has been routed as a packet to a shop on the standard, so nothing is measured, and we will not pretend otherwise. What this page publishes instead is the methodology: what gets recorded, how each term is defined, what may leave the network, and what happens when we get something wrong. When the numbers arrive, nobody will have to take our word for what they mean.
These figures measure packet-routed work across shops on the standard. None of it has run yet. Rather than print a zero, animate a counter, or grey out a plausible-looking placeholder, every figure below is drawn the way a drafter draws a dimension that has not been toleranced yet: the callout exists, the value does not.
Each one carries the definition it will publish under. That is the part we can be held to today, and it is the part that is hard to fake later.
Counts shops that have passed the qualification job and graduated to live routing. A shop in the funnel is not a shop on the standard, and we will not report it as one.
Cumulative parts orders delivered to a customer against a released packet. Internal test parts and calibration runs are excluded and stated separately.
Delivered complete, on or before the date on the order at acceptance. Not the revised date. Not the re-promised date.
Median wall-clock time from upload to a priced, dated Catalog-lane offer. Reported as a median with the tail, because the tail is the part that hurts.
Share of declared network capacity consumed by routed work, and how much of that ran inside a batch.
Because a zero is a measurement, and we have not measured anything. A counter that renders as zero without JavaScript is the specific failure mode this page was designed against. When the first job ships, the first figure appears here — dated, and with the job count behind it.
Every field below is captured from the first calibration job onward, whatever the tooling happens to be. Retrofitting history is impossible, which is exactly why this dataset is defensible and exactly why the discipline has to start before it is convenient.
A competitor can copy the idea of this page in an afternoon. They cannot copy the record, because the record is made of delivered jobs.
Per job — the core record
| Group | Fields |
|---|---|
| Quoted | Price · promised date · estimated setup and runtime per operation |
| Actual | Accept timestamp · setup start and end · cut start and end · probe logs · inspection results · ship date |
| Outcomes | On-time (binary and days delta) · first-pass yield · nonconformances, cause-coded to packet, shop, material, or tooling · reroutes with reason |
| Batch | Batch membership, keys matched, and realized savings against the solo baseline |
And per shop, per packet revision, per feature class
| Entity | Fields |
|---|---|
| Per shop | Machine profiles and validated posts · designations (ITAR, tight-tolerance, pallet tier) · declared capacity calendar · standing metrics · financing state |
| Per packet revision | Cumulative first-pass yield across shops · runtime estimate error distribution · issue history · which shops are qualified to run it |
| Per feature class | Achieved-tolerance distributions per shop, by hole tolerance band, pocket ratio, thread class, and material |
The Ledger is not a dashboard we look at. It is wired into the four decisions that make the model work — and the loop closes, which is the whole argument: every delivered job makes the next quote more accurate, the next route better, and the next date cheaper to guarantee.
The router scores eligible shops per job: qualification match, then trust-weighted available capacity, then feature-class capability fit, then standing band, then logistics, then baseload owed. While the router is young, human override stays available with a reason code — and the override reasons are themselves training data. It goes away when the model has earned it, and we will say so when it does.
A guaranteed date is constructed, not hoped: runtime estimate, times the packet revision's error distribution, times shop standing, times calendar trust, plus a buffer priced from historical variance for that feature class. This is why the guarantee is a product a competitor cannot launch cold. They have no loss history to price it from — and until we have run the jobs, neither do we.
Standing is a Ledger output, not a membership tier. Every shop sees its own standing in full, including exactly how routing priority is computed from it. Falling standing triggers a conversation, not a de-listing.
Anonymized aggregates become the Domestic Machining Lead Time Index. It is the only part of the Ledger that leaves the network, and the rules for what may leave are below.
Standing is derived on a rolling ninety days and shown to the shop in full — not a score with a mystery behind it, but the inputs, the weights, and how routing priority falls out of them. A supply side that cannot audit its own grade will not tell you the truth about its calendar, and the entire liquid-capacity promise depends on true calendars.
What routed work looks like| Metric | Definition |
|---|---|
| On-time-in-full | Rolling 90 days. The headline, and the one the router weighs hardest. |
| First-pass yield | Parts accepted without rework or scrap, measured per packet revision as well as per shop, because both halves cause failures. |
| Issue rate | Issues raised per hundred jobs, cause-coded. A high issue rate against a young packet is usually our fault, and the coding says so. |
| Responsiveness | Accept latency and hold-resolution latency. How long a job waits on a human. |
| Calendar honesty index | Declared availability against actual acceptance and throughput. Measured, not moralized: chronic over-declaration simply lowers the router's trust weighting on that shop's calendar. Liquid capacity is only real if calendars are. |
These are constraints on the product, not a policy page. A network that used its shops' performance data to squeeze their rates would poison its own supply permanently, and it would deserve to.
A shop’s data wins it work and underwrites it (routing priority, financing eligibility).
It is never used to negotiate that shop’s rates down.
Each shop sees its own standing in full, including exactly how routing priority is computed.
Public and aggregate uses (the Index, capability claims) are anonymized; no shop-identifiable data leaves the network without written consent.
Every buyer in this industry has an opinion about lead times and almost nobody has the delivery data to settle it. Quoted lead times are published constantly. Delivered lead times are not published at all — which is convenient for everyone quoting them.
The Index is built from anonymized Ledger data and reports both sides of that gap. It is the one artifact a competitor cannot answer with marketing, because answering it requires having delivered the jobs.
Each issue reports
Note 2 — The first issue publishes when there are enough delivered jobs for the anonymization floor to hold, not on a marketing calendar. We would rather publish late than publish a cell built from three jobs and a hope.
Most published manufacturing statistics are unfalsifiable because the terms are never pinned down. These six rules pin ours down before we have a single result to protect, which is the only moment at which doing so costs us nothing and proves anything.
A job is on time if it ships complete on or before the date that was on the order when the customer accepted it. Not a revised date, not a re-promised date, not a date adjusted after the fact because the first one was optimistic. A revised date is recorded as a miss against the first one, and both are kept.
Customer print or spec changes after release, customer material late or out of certification, payment terms breached, source-inspection delays beyond the stated window, and narrowly defined force majeure. That list is published in full on the guarantee page. Anything not on it is our problem, and it counts against us.
Index figures are grouped by part class — material family, envelope band, tolerance class, and operation count. The class definitions publish with the first issue and are versioned. Re-cutting the classes after seeing the results is the oldest trick in industry benchmarking, and versioning is how you can check we did not.
No shop-identifiable data leaves the network without written consent. Index cells publish only above a minimum job count, so that no cell can be reverse-engineered to a single shop or a single customer. That minimum is published with the first issue rather than chosen per issue.
Cancelled jobs, rerouted jobs, scrapped lots, and escapes are in the denominator. The one category we will separate rather than exclude is internal test and calibration work, because counting our own practice runs as delivered jobs would be a lie of arithmetic.
If a published figure turns out to be wrong, the correction runs in the next issue with the original left visible and struck. An index nobody can audit is a brochure.
The first real reroute gets published too — the job, the reason, and whether the date held. A model whose selling point is that work can move should show its work the first time work moves.
Write to us and we will put you on the list for the Domestic Machining Lead Time Index. No newsletter, no drip sequence — one email per issue, and the methodology attached.
hello@praetore.com