Part 3 ran into the wall. A shop can automate every handoff inside its own building and still stop cold the moment a job has to cross to the plater, the heat treater, or the shop down the road that takes your overflow. Today that job leaves as an email, a PDF, and a phone call to confirm they got it. Then someone in their office types it in again.
This post is the top rung: a job that can travel. It's also the one thing we've built that doesn't belong to any single shop — so we've published it in the open, and we'd rather show you how it works than ask you to take our word for it.
What actually needs to cross the wall
Part 2 followed one purchase order getting typed three times inside one building. Between two buildings it's worse. The buyer's office types the job, the seller's office types it again, and the rev C versus rev B problem now spans two companies. The seller quotes against a drawing rev nobody can prove they saw.
What the two sides need is narrower than it sounds:
- Both sides looking at the same job, at the same rev.
- A quote tied to exactly what it priced, so it can't drift onto a job it never saw.
- Proof of who sent it, and that nobody changed it on the way.
- None of that requiring either shop to hand its customer list to a middleman.
Plain email can't give you any of that. A PDF can't either. EDI (electronic data interchange, the order-exchange standard big manufacturers use) does part of it, but usually through a paid network, a VAN, that sits in the middle and sees who you trade with.
A file, not a platform
The Secure Job Envelope is an open file format for a job. The job object is called a traveler: one part family moving between a buyer and a seller — the part, the material, the quantity and price breaks, the need-by date, the ship-to, the quotes it attracted, and the award.
A shop seals the traveler into an encrypted .sje file and sends it over whatever it already uses. Email works. There's no portal to log into, no network to join, and no broker in the middle.
That's deliberate. Every shop already has systems: an ERP (the main business system for orders, inventory, and books) it rents, a desktop app nobody wants to touch, spreadsheets holding it together. A coordination platform asks everyone to move in. A file format meets every shop where it is — anything that can read and write the file can take part.
How it keeps both sides honest
You don't need to follow the cryptography to follow the idea. There are four pieces.
A fingerprint of the job. The fingerprint is a short code computed from a set of the job's details; change any of them and the code changes. Every program that follows the spec computes the same fingerprint for the part of the job 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), along with the job's own id, revision, and creation time. A quote is bound to that fingerprint. Change the job — new rev, new quantity — and the traveler's revision goes up and every earlier quote is marked stale. A rev B quote can't quietly ride onto a rev C job.
Signatures. The buyer signs the job as quoted, and each seller signs their own quote. Signatures are checked against a signed directory of shop keys, so a signature from the wrong company fails. Today that lives in the reference libraries and their tests; the desk and the demo below don't sign jobs or quotes, or check those signatures, yet.
A sealed envelope. The file you send is encrypted end to end, so whatever carries it — your email server, theirs, anything in between — carries something it can't read. Only the shop it's addressed to can open it, and once open, that shop can read all of it. We picked post-quantum algorithms (designed to hold up against future quantum computers) on purpose: the goal is that a file someone copies off a mail server today isn't readable in ten years either.
The receiver checks for itself. The receiving side recomputes the fingerprint on its own instead of trusting the sender's, and it refuses a file with anything in it the format doesn't allow.
Checkable, not marketing
In an earlier post we said the honest test of any builder is whether you can read the platform before you sign anything. This one you can:
- The spec and both reference implementations are MIT-licensed and public: github.com/rivletio/secure-job-envelope.
- There are two independent implementations, one in TypeScript and one in Rust, with no shared code. Both have to produce the same results on the same public test files, byte for byte, and on every change a test program throws thousands of altered documents at both and checks that they agree.
- A claims register maps every written security claim to the test that proves it, and says plainly which statements don't have proof yet.
- A two-desk demo has a buyer and a seller compose a job, seal it, refuse a tampered copy, quote, award, and refuse an edit after the job is locked. It proves the sealing and the checks; it doesn't sign anything yet.
The name carries no company on purpose. We write the spec today and build services on it, but it's designed so that anyone can implement it and check their work against the same public test files, without asking our permission. We ask one thing in return: attribution. If you implement it or build on it, credit the Secure Job Envelope and Rivlet.
What it doesn't do yet
The same honesty applies to the gaps:
- No real trade between two outside shops yet. We use it internally today. The first job passed between two shops that aren't us is the milestone we're working toward.
- Drawings don't travel inside it yet. The traveler records the drawing rev, not the drawing file.
- Signatures aren't in the exchange yet. They're built and tested in the reference libraries, covering the job as quoted and each quote, but the desk and the demo don't use them yet. The award, ship-to, and routing aren't signed at all yet.
- It hasn't been independently audited. And choosing strong algorithms isn't a certification: it is not ITAR, SOC 2, or NIST 800-171 compliant, using it doesn't make you compliant, and controlled technical data doesn't belong on the demo desk.
- You swap keys with a partner once, up front, the way you'd trade phone numbers. There's no central broker doing that for you.
- It's a format, not a product you log into. The desk in the repo is a demonstration, not a hosted service.
What to do with this today
If you run a shop, there's nothing to install yet. Ask your office two questions instead. When work leaves your building, how many times does somebody retype it before it's on the other shop's floor? And if a quote and a job disagree about the rev, can either side prove which one was priced?
If you have a developer, or an ERP vendor who'll listen, send them the repo. And if you send a lot of work out — plating, heat treat, overflow machining — and you'd be willing to be one end of that first real trade, we'd like to hear from you.
This is where the ladder was always headed. Measure one station, stop retyping the PO, get the floor telling the truth, promise one number every two weeks. Then let the job leave the building as data, with both sides able to check it's the same job.