Flow, Part 7 introduced the Secure Job Envelope as the top rung of the ladder: a job that can leave your building as data instead of an email, a PDF, and a phone call. That post was about what it does. This one is about why it's shaped the way it is.
Five decisions sit underneath it. Each one came from a problem we kept running into on order desks, and each one has a cost, which we'll name.
1. The unit is the job, not the company
Most attempts to connect shops start with the companies: sign everyone up, put them on a network, give each one an account. That's backwards for a job shop. Your customers change every week. The plater you use for one job isn't the one you use for the next. What actually moves between companies is a job.
So the format's one object is a job, and we named it after the paper that already follows a job through every shop. A traveler is one part family moving between a buyer and a seller: the part as drawn, the material, the quantity and price breaks, the need-by date, the ship-to, the quotes it attracted, and the award. Flow, Part 4 argued that the paper traveler is already your system of record on the floor. This is that traveler, made able to cross a wall.
The file is the state. There's no database behind it that both shops have to log into. Each shop keeps its own systems, and anything that can read and write the file can take part.
The cost: there's no central place to look things up. If you want to know where a job stands, you look at the file you have.
2. A job is identified by what it says
Here's the problem this decision exists to kill. The buyer sends rev C. The seller quotes from the rev B print still in their inbox. Nobody finds out until inspection, and then it's an argument about who sent what.
In the envelope, a job's identity is a fingerprint of the part of it a seller prices: the buyer, the part as drawn (part number, drawing rev, material, quantity, processes, finish, tolerances, notes, and a few more), the need-by date, the shipping terms, and whether it's ITAR (US export-controlled defense data), along with the job's own id, revision, and the moment it was composed. Both shops compute that fingerprint for themselves from the file in hand, and any correct implementation gets the identical result. If the fingerprints match, the two sides are looking at the same job. Neither one has to trust the other's database.
A quote is bound to that fingerprint, and in the reference tools the binding is computed from the job in hand, not typed in. You can't claim a quote covers a job it didn't see. Change the job — a new rev, a new quantity — and the revision goes up and every quote on the old revision is marked stale. The rev B quote doesn't quietly ride onto the rev C job. It shows up as stale the moment anyone opens the amended file.
What's left out of the fingerprint is just as deliberate: the quotes themselves, the award, the routing, and the ship-to. Those get added as the job moves forward, and adding them doesn't break the quotes that came before.
The cost: every amendment invalidates every quote, including the ones you'd have been happy to keep. That's on purpose. A seller re-confirms a price against the job as it is now, not as it was.
3. Where a job stands is computed, not declared
Every shop has a job marked "ready to quote" that isn't. The material isn't specified, or the quantity is "TBD," and the seller has to call and ask, or guess.
So nobody marks a traveler's status. The file earns each level by containing what that level needs:
| Level | It means |
|---|---|
| Draft | Missing something a seller needs to price it |
| Quoteable | A seller can price it without guessing the material or quantity |
| Awardable | At least one quote is bound to the current revision |
| Executable | Awarded, operations listed, ship-to present — and now it's locked |
| As-built | What was actually made has been recorded |
Once a job is awarded and locked, edits are refused. A change after award is a new conversation between the two shops, not a silent edit to a file someone already priced and scheduled.
The cost: a traveler can't skip ahead. If the ship-to is missing, it isn't executable, no matter how urgent the job is.
4. Say only what both sides agreed to say
Finding a shop with open capacity usually means telling somebody everything — the customer, the part, the price you're hoping for — before you've agreed to anything. That's how a customer list ends up in a broker's database.
The envelope separates two moments. Before two shops agree to work together, a courier — the service carrying or matching the job — may describe it only in general terms: the part family, material, processes and finish, the target quantity, the need-by date, whether it's ITAR, and the buyer's certifications. Not the customer's name, not the part number, not the drawing rev, not the price, not the ship-to. That list isn't a promise in a PDF. It's code, with a test that fails if a new field is added without being classified or if a name or price shows up where it shouldn't.
After both sides opt in, they exchange the file itself, sealed. The copy that travels is encrypted to the receiving shop, so whatever carries it — your mail server, theirs, anything in between — carries something it can't read. The encryption is post-quantum — built to resist codebreaking by future quantum computers — because a job file is long-lived: the pricing and the part data in it matter for years, and someone copying files off a server today shouldn't be able to open them later. The fingerprint uses a post-quantum-strength hash for the same reason, chosen before the first release so no fingerprint ever has to change.
The cost: you and a new partner exchange keys up front, outside the system, the way you'd trade phone numbers. There's no central broker in the middle doing that for you — on purpose, because a broker in the middle would see who trades with whom.
5. A standard is something two strangers can build
A format that only one company's software can read isn't a standard. It's a product with a file extension.
So we built two implementations that share no code — one in TypeScript and one in Rust — and hold them to the same public test files, byte for byte, with a tester that throws documents at both on every change. Wherever two programs could reasonably disagree, the spec refuses the ambiguity instead of guessing: a number the two languages might write differently is rejected, and money is stored in whole cents rather than decimals that drift.
Conformance is defined by those public test files, not by our software. The spec and both implementations are MIT-licensed and public on GitHub. The name carries no company. And every written security claim is mapped to the test that proves it, including a plain list of the ones that don't have proof yet.
Anyone can implement it without asking our permission. We do ask for attribution: credit the Secure Job Envelope and Rivlet as its author. If you copy our reference code, the MIT license already requires keeping its copyright notice; if you write your own implementation from the spec, credit is a request, not a condition.
The cost: going slower. Anything we add has to land in both implementations and the shared tests before it counts.
What it adds up to
Put the five together and you get a job two shops can pass back and forth without either one moving into the other's software, or into ours. Each side can check for itself that it's the same job, at the same rev, quoted by the shop that says it quoted it, and that nobody changed it on the way.
The README says it better than we can here: "The platform can come later; the envelope has to come first."
Where it stands
It's spec version 0.1.0, and we use it internally. It hasn't carried a job between two outside shops yet, it hasn't been independently audited, and it isn't a compliance certification. Drawings don't travel inside it yet. Signatures are built and tested in the reference libraries but aren't used by the desk or the demo yet, and the award and ship-to aren't signed at all yet. The full list is at the end of Flow, Part 7, and the repo says the same thing in more detail.
If you send a lot of work out and want to be one end of the first real trade, or you build shop software and want to read or write the format, we'd like to hear from you.