The system of record for How.
How your shop actually does the work lives in the heads of the people who have been there longest. Revari is where it gets written down, kept current, and put in front of whoever needs it next — with the evidence an auditor wants as a byproduct, not as the point.
The problem
Three versions of the same problem
A folder called CONTROLLED
Revision numbers live in filenames. A spreadsheet says which file is current. Nobody at the machine trusts either one, which is why the real procedure is the copy taped inside the cabinet door.
Software nobody opens until the audit
The big QMS platforms made compliance the point and the procedure an afterthought. When following the documented method is the slow way to work, people stop following it. You can’t really blame them.
Audits that become archaeology
A few weeks out, somebody starts reconstructing who approved what, and when, and against which version — out of email, memory, and a signature on a printout that could match any of four revisions. Next year, the same dig.
What it’s for
Getting what your people know out of their heads
Every other system in the shop records what happened — the order, the part, the result. None of them record how. That knowledge sits with the people who have been there longest, and it leaves when they do.
So the whole product points at one job: making that knowledge seamless to capture, genuinely useful once it’s captured, and controlled enough to stake an audit on. Everything further down this page is one of those three, made specific.
Capture that isn’t a documentation project
Nobody has a spare month to write procedures, which is why the ones you have are five years old. Revari drafts the first version, so the person who knows the job is editing rather than starting at a blank page — a much smaller ask of somebody with a shift to run. And questions your procedures don’t answer get written down as they come up, so the gaps arrive as a list instead of as an audit finding.
Knowledge that reaches the floor
Captured knowledge only counts if somebody uses it, which means the procedure has to be quicker to follow than to work around: findable in seconds, readable on the screen that’s actually mounted at the bench, and current without anyone having to go and check. Every shop already has knowledge written down somewhere nobody opens. That’s the failure to avoid, not to repeat.
Controlled without being locked away
Every revision has an owner, an approval trail, and a fingerprint that stops matching if the content changes. That is what makes the knowledge worth relying on a year later. Control here means the record is trustworthy — not that the procedure is hard to reach. Knowledge only the quality office is allowed to touch is knowledge that quietly goes out of date.
What it does
Built for the procedure, not the paperwork
Every feature gets the same test before it goes in: does this make it easier for the person doing the work to find, follow, and improve the procedure? If the answer is no, it stays out, however good it would look in a demo.
An editor that understands steps
Numbered steps renumber themselves when you reorder them. References to other controlled documents stay pointed at the right revision when those documents change. Flowcharts get drawn inside the procedure itself, not in some diagram file on a shared drive that quietly goes stale.
Routes you configure, an approval nobody skips
Draft, review, approve, publish. You decide who reviews and how many. If you want authors approving their own routine work, that’s your call to make, and the record will show it plainly. The one thing nobody can do is publish with no approval at all.
One current revision, and everyone can tell which
The floor sees the revision that’s in force, full stop. Superseded revisions stay readable and clearly marked, because deleting the old copy was never control — it was just losing your own history. And the reading view is built for shop lighting, since a dark screen under bright overheads is a mirror.
Ask it in plain words
Someone on second shift asks how to run a changeover and gets the answer from your procedures, citing the exact step. When the procedures don’t cover it, it says so instead of improvising — and writes the question down. That list of unanswered questions is a gap analysis you didn’t have to schedule.
The lifecycle
Five states, and no way around them
A procedure gets drafted, reviewed, approved, published, and eventually superseded or retired. Every transition records who did it and when. Sending it back for changes keeps the review marks. And a rejection wipes out the approvals already collected, so nobody quietly resubmits and publishes on signatures that were given before the change.
Evidence
Proof as a byproduct
When a revision publishes, Revari fingerprints it: the content, the approvals, and the fingerprint of the revision before it. Each one contains the last, so they form a chain. Change one published word a year later and every link after it stops matching. There is no admin setting that turns this off, including for me.
You shouldn’t have to take my word for any of that, so you don’t. The fingerprint rule is written down and versioned, the engine that computes it is built and passing its conformance tests, and a standalone checking script ships with every export. An auditor can verify your records on their own laptop, with no access to Revari and no cooperation from me.
The AI part
What the AI does, and what it can’t
Writing a procedure from a blank page is miserable, so the AI drafts. It also reads: it will point out where a procedure contradicts itself or another document, and it answers questions from your controlled content with citations.
What it can’t do: approve, publish, or touch a released procedure. Its only write permission is a draft block that a person accepts or throws away. That limit lives in the permissions underneath the application, not in a policy document — “we promise the AI is careful” isn’t something I’d accept from a vendor, so I’m not going to ask you to.
Straight answer
Where this actually stands
There is nothing to demo yet. I’m not going to pretend otherwise, least of all to people whose job is checking claims.
What exists so far is the part that’s expensive to get wrong: the data model, the approval rules, who is allowed to do what, and the evidence format. All of it specified, reviewed, and tested before any screens get built on top. Screens are the fixable part. The foundations aren’t, so they came first.
What an early customer gets:a real say in what gets built next, a direct line to me instead of a support queue, pricing that respects the risk you’re taking, and your own procedures as the proving ground instead of a vendor’s tidy demo data.
Early access
If document control is your problem, let’s talk
You already know which of those three cards up top is your shop. Tell me that much and I’ll take it from there — an email, maybe a call. There’s no sales team. There’s me.