Catching drawing revision changes: RevLatch visual diff guide

By J.E. Herizon LLC · Published September 27, 2026

Every cabinet shop has a REV story: the engineer uploaded REV-D, the filename looked familiar, and a 50 mm change on a cabinet elevation went unnoticed between the drawing folder and the CNC nest. RevLatch is a free, fully local Windows app that pairs a reviewed baseline PDF with an incoming revision — it suggests sheet matches and visible changes for a human to confirm, records the decisions, and exports a SHA-256-bound release packet so only the reviewed revision reaches the shop floor.

The change that vanishes between REV upload and the shop floor

Cabinet, joinery and architectural millwork shops live on revisions. REV-C becomes REV-D because a hardware schedule changed, a material note was updated, or a door opening moved 50 mm on an elevation. The sheets arrive as a familiar filename in an email or a WhatsApp chain, nobody re-checks the dimension block, and the cutlist or CNC nest is pulled from the version people remember — not the version on the server.

Revision clouds and delta triangles are only as good as the drafter's discipline, and houses are built by human hands. The fix is not a tool that "certifies" a drawing — no tool can do that for you. The fix is a tool that makes sure a human actually sees what changed, sheet by sheet, before the set is released to the shop.

Two files in, one review job

Start a RevLatch job the way the argument usually starts: with the actual pair of files. You choose the reviewed baseline PDF and the incoming revision PDF, and the job is bound to those exact source bytes — not to filenames, not to memory.

• Byte-exact revision identity. A revision is identified by the SHA-256 of its bytes. Any byte difference is a new revision and resets that revision's review state; re-importing identical bytes changes nothing. "Which revision did we build?" becomes a machine-checkable question.
• One job per drawing family. You can import a new revision into an existing job at any time; each incoming revision is reviewed against the held baseline and gets its own review state, so a REV-C → REV-D → REV-E chain stays one job with one history.
• Refusals with a reason. Admission is strict and the limits are stated up front: encrypted or password-protected PDFs, files larger than 200 MB, sets with more than 25 sheets, and empty or corrupt files are refused at import with a stable refusal code. "Refuse" beats "do something approximate" — a packet can never be built on a half-read document.
• A page-dimension gate. Pages whose width or height differ by more than 2% are treated as "not comparable" rather than "matched," and a minimum render scale guards the comparison below which a page cannot be trusted. A clean-looking diff is never drawn between geometrically different drawings.
• Predictable local data layout. Job data lives only on this PC: jobs/<job>/sources/ holds the exact imported PDF copies, revlatch.sqlite is the review database, and exports go to packets/. There is no hidden derived copy to leak.

Sheet matching: the engine proposes, the reviewer disposes

For a multi-sheet set, the engine compares pages by content — compact grayscale signatures per page, a similarity score, a 0.94 matching threshold — and suggests which revision page goes with which baseline page. It can even suggest changing a pairing you confirmed earlier. Scores are shown, so you see how confident the engine is; every suggested pair requires your explicit confirmation.

And nothing disappears silently:

• An added page — a revision sheet with no trustworthy mate — becomes a review item of its own.
• A deleted page — a baseline sheet nobody mated to — surfaces as a removed-sheet item.
• Unpaired pages stay visible, and when the content matches but the page order changed, the set is flagged as reordered.

These are exactly the changes a busy shop misses: a sheet dropped from a revision, the order scrambled between PDF exports. The engine refuses to hide them inside a "successful" compare. In the build's capacity test, a worst-case 25-sheet set compares in roughly ten seconds of wall time (about 115 MB peak memory) — the minutes that matter are the reviewer's.

Reviewing a revised set: what each method gives you

Side-by-side review with honest registration

Confirmed pairs render side by side, auto-registered to the same canvas, with suggestion and region boxes drawn over the aligned views — you look at the actual drawings, not a report about them.

• Automatic geometric registration. The revision render is aligned to the baseline canvas globally via phase correlation; when that is unreliable, user-confirmed landmark pairs solve a transform whose error is checked against a bound. Any verdict that cannot be made reliable is returned as ok=False with a recorded reason. This is a global alignment model — it is not a promise of perfect registration in every corner of every sheet.
• Changed-region suggestions. A deterministic pixel-diff between the aligned pages produces area-ranked change boxes with a mean-diff strength per box; tiny stragglers are counted rather than shown. These are suggestions, and they need your confirmation.
• The engine's blind spots stay visible. Differing pixels that fall outside every suggestion box, and significant difference in the border band where warping extrapolates, are surfaced as explicit excluded and edge_excluded flags — the system shows you what it is not sure about instead of hiding it.
• A coverage-panic gate. If more than 60% of a page differs, registration is declared untrustworthy and the results are not presented as a clean diff. Reject rather than show deceptively clean.
• Transparent rendering. The renderer and scale are shown per comparison, so you can judge how much detail you are looking at; renders run in a cancellable child process with per-run watchdogs, so untrusted PDF bytes are never parsed in the UI process. (Bring only files you already trust — this is not a sandbox for hostile PDFs.)
• Alignment failures become checklist items. A pair whose registration fails gets an alignment item in the review checklist rather than a clean-but-wrong diff.

The accuracy story is tested where it can be: on labeled synthetic fixtures — a known change is surfaced, an unpaired page is never silent, format-only noise stays low, bad alignment is rejected (8 of 8 gate cases in the build evidence). Honest boundary: suggestions on real-world drawings have not yet been validated across shops, so treat every suggestion as input to review, never as a verdict.

Critical regions: mark it once, recheck it every time

The engine proposes; the reviewer decides. On the baseline page, drag a rectangle over the area that is load-bearing for this job — the dimension block (the default label), a material note, a hardware schedule — and name it. Saved critical regions are stored per job and become review items again on every incoming revision. The areas that cause wrong part orders are re-verified each REV, which is exactly the drift a shop misses.

Every checklist item gets an explicit decision: significant, not_significant, no_change, or acknowledged — and pending items block a "review complete" state, so a half-finished review cannot masquerade as a finished one. Per-item notes travel into the review record and the exported packet, so the "why" of a decision survives for the next reviewer and for disputes with the GC or the customer.

When you want a feature that is not there, the in-app "Suggest a feature" path records it locally and only opens a mailto: to features@jehorizon.com when you click send — RevLatch never sends mail, or your drawings, on its own.

The release packet: what the shop floor actually receives

Export is a folder you choose, and its contents are deliberately boring: drawings/ (exact copies of the baseline and revision PDFs), crops/ (before/after PNG crops of the decided regions, rendered from those copies), review.json (the full item snapshot: matches, decisions, notes, unresolved items), REVIEW_STATUS.txt, manifest.json, and REVIEW_RECEIPT.txt. Every embedded file is hashed with its size and SHA-256 digest into manifest.json; the manifest's own hash is recorded in the receipt and in the store, and the export dialog shows the baseline and incoming hash prefixes up front. Integrity can be recomputed at any time by anyone holding the folder.

• Draft vs. complete, enforced. Any still-pending item and the packet is exported as draft_for_review with a plain-text warning; only when every item is decided for that exact revision does the packet carry a complete status — with an explicit note that "workflow complete" does not mean no undetected changes exist.
• No fake history. A revision the engine never compared cannot be exported at all — an export must describe a real comparison run, never a description of nothing.
• Clean-room re-export. Exports are built in a staging folder and moved into place; a target holding a foreign file is refused, and re-exporting replaces the previous packet rather than merging into it. One export's contents, exactly.

Local processing, a permanent Free tier, and Pro

Processing is 100% local: drawing files are compared on this PC and never uploaded. The only network calls are the bounded HTTPS requests for an explicit Pro checkout or license claim — clicks you make on purpose. Confidential shop drawings stay confidential because they never leave the machine.

• Free — $0, forever. One active review at a time, with the full workflow and full packet export, no account, no card, no time limit. Archive a job to open another; archived reviews stay readable and exportable.
• 30-day Pro trial, no card. The in-app entitlement grants a 30-day trial of Pro capacity without collecting a card.
• Pro — concurrent reviews. Multiple simultaneous active reviews, on an Ed25519-signed subscription license bound to the machine, usable offline until its verified expiry, with zero per-seat fees.
• Graceful downgrade. If a Pro term ends, existing active reviews remain usable — the free-capacity rule applies to creating or reopening jobs, never to locking you out mid-review.
• Explicit activation. License claim and activation are deliberate user actions; nothing is activated in the background.

Pricing

Free — $0. Free tier covers 1 active review with full PDF packet export forever. One active review at a time; archive to open another. No account, card or time limit — archived reviews stay readable and exportable.

Pro — $1.99 / mo · $19.99 / yr. Multiple concurrent active reviews. Existing active reviews remain usable if Pro ends. In-app Microsoft Store subscription with zero per-seat fees.

For context, published pricing research from September 2026 puts the compare features of mainstream PDF tools behind paid tiers — Bluebeam Revu's compare sits in the Core+ tier at roughly $330–$590 per seat per year, and Acrobat's compare is Pro-only at about $19.99 per month. The free local core here is the point: the review workflow should not be gated behind a seat license.

Scope and honesty

RevLatch states its own limits on the page and enforces them at admission, and the honesty lines are the product's own words:

"RevLatch assists a human review — it does not certify a drawing, approve it automatically, or promise to find every change."

"Scanned or skewed drawings are not guaranteed."

The supported scope is unencrypted, computer-generated PDFs with comparable page dimensions, up to 25 sheets per set. There is no CAD or BIM editing, no OCR, and units and decimals are preserved exactly as drawn — never inferred, never converted. A complete packet says the workflow was finished, not that the drawing is perfect. If the project needs a formal sign-off, it needs the reviewer's eyes plus this record — the tool never stands in for either.

A repeatable revision-review workflow

• Confirm the files: baseline and revision identified by bytes, not by filename.
• Import into the job; let the engine propose matches; confirm each pair, then walk the added, deleted, unpaired and reordered lists.
• Review aligned side by side; inspect every suggestion box and any excluded or edge flags; heed the coverage warning if a page differs too much to trust.
• Mark the load-bearing areas once — dimension block, material note, hardware schedule — so they are rechecked on every revision.
• Decide and note every item; leave nothing pending before export.
• Export the packet, confirm the hash prefixes, and hand the folder to the shop with the receipt.

← All articles

Use the current how-to guide