drawing-rev-watcher

Watches Gmail for drawing-revision emails. For each PDF attachment, AI reads the title block to extract part number and revision. Looks the part up in a DrawingsTracker Sheet; if the rev is newer than what's on file, archives the old drawing to a "Superseded" Drive folder, uploads the new drawing to the workflow's working folder, updates the tracker, and emails the estimator + production. The "customer sent rev D mid-production and nobody noticed until parts came off the machine to the old rev" failure mode, automated away.

Use case

Mid-production drawing revisions are a top-five cost center at every machine shop. A customer engineer makes a change (tolerance loosened, hole pattern shifted, surface finish tightened), emails the new rev. The estimator opens it, says "looks fine," and forgets to tell the floor. The floor finishes the lot to the old rev. The customer rejects the shipment. Now there's a 4-week argument about who pays for the scrap.

The fix isn't more discipline. It's a watcher that sees every incoming drawing the second it lands, identifies the part, compares the rev, and pages the right people. This workflow is that watcher.

It does NOT decide for you whether to scrap WIP or get a deviation — that's the engineer's call. It does ensure the engineer KNOWS within 10 minutes that a rev change happened.

Setup

1. Credentials (Credentials view): - google-workspace — Google Workspace service-account JSON - claude-api — Anthropic API key
2. Runtime environment (Runtime Environments view): - python — auto-created on every OS install
3. System binary: pdftotext (Poppler utils). Install: - Linux: apt install poppler-utils - macOS: brew install poppler - Windows: install Poppler-Windows binaries and add to PATH
4. Gmail prep: - Create label drawing-update - Create label drawing-processed - Create a Gmail filter that auto-applies drawing-update to incoming drawing-revision emails. Common filter rules:
   • From customer domains: from:(@customer1.com OR @customer2.com) has:attachment filename:pdf
   • By subject: subject:(revision OR revised OR "new rev" OR "drawing update") has:attachment
   • Replies to existing RFQ threads: combine label:RFQ with has:attachment and subject:re:
5. Drive prep: - Create a Drive folder called Superseded (or any name) to receive archived old drawings. Copy its FOLDER ID. - Each active workflow already has its own Drive folder (typically created by rfq-triage). The tracker rows below point at those.
6. DrawingsTracker Sheet (one-time): - Create a Sheet with a tab DrawingsTracker and 6 columns: A part_number | B current_rev | C drive_folder D last_updated | E customer | F notes - Row 1 is the header. Data starts at row 2. - When a new workflow goes into production, add a row: part_number, current_rev, drive_folder (the workflow's working folder ID), customer. Leave last_updated blank (the workflow writes it). - The workflow updates columns B and D when revs change. You maintain A, C, E, F.
7. Edit workflow.yaml — replace the six placeholders: - <<DRAWING_LABEL>> — drawing-update (or whatever Gmail label you used) - <<DRAWINGS_TRACKER_SHEET_ID>> — DrawingsTracker spreadsheet ID - <<SUPERSEDED_FOLDER_ID>> — Drive folder ID for archived drawings - <<ALERT_EMAIL>> — estimator + production lead email (use a group address; the alert is high-importance and shouldn't single-point) - <<SHOP_NAME>> — for the alert signature
8. Schedule every 10 minutes.

Pipeline

1. fetch — runtimeenv (python). Finds the oldest email labeled drawing-update and not yet drawing-processed. Downloads every PDF attachment to a temp directory. Runs pdftotext -layout -l 1 on each to extract first-page text. Emits a JSON blob with the message id, sender, subject, and a drawings list (filename, local_path, first_page_text).

2. classify — anthropic (claude-sonnet-4-6). For each drawing in the list, identifies whether it's actually an engineering drawing (vs a cover letter, spec, photo), extracts part_number, rev, description, and drawing_number from the title block, and gives a confidence rating. Returns strict JSON.

3. act — runtimeenv (python). For each classified drawing: - Unknown part (not in tracker): adds a line to the alert digest. Doesn't move the file (no home for it). - Same rev as tracker: silent no-op. Just a resend. - Older rev than tracker: adds a line to the alert noting an old rev arrived; doesn't apply. - Newer rev (the real case): finds existing PDFs in the workflow's Drive folder, renames each {part_number}_rev{old_rev}_archived_{date}.pdf, moves them to the Superseded folder. Uploads the new PDF as {part_number}_Rev{new_rev}.pdf to the workflow's folder. Updates the tracker row: new rev, today's date. Emails the alert recipient with old rev, new rev, customer, Drive links, and an explicit "verify production isn't running the old rev" note. Finally, applies drawing-processed label and removes drawing-update.

Sample alert email

Subject: DRAWING REV CHANGE: ACME-12345 Rev B → Rev C

A new drawing revision has arrived for an active part.

Part number:   ACME-12345
Description:   Hydraulic mount bracket
Customer:      Acme Aerospace
Old rev:       B
New rev:       C
Filename:      ACME-12345_C.pdf
New drawing:   https://drive.google.com/file/d/.../view

Old drawing(s) archived to the Superseded folder:
  - ACME-12345_revB_archived_2026-05-12.pdf (id 1xyz...)

VERIFY production isn't running the old rev. If parts have already
been made to B, contact the customer before continuing.

— Acme Manufacturing drawing-rev-watcher

Customization

• Sender allowlist — change the Gmail filter to apply drawing-update only to senders on your AVL. Cuts noise from unrelated emails that happen to have PDF attachments.
• Tighter classification — adjust the confidence threshold in the act task to skip low-confidence rows pending human review.
• Multi-PDF email handling — already handled in the current pipeline; each PDF in a single email is processed independently.
• Customer-specific alert recipients — extend the DrawingsTracker schema with a 7th column alert_email_override. The act task can read it and route alerts per-customer instead of using the default.
• CC the customer — adding --cc <customer_engineer> to the gmail send confirms back to the customer "we got rev C and updated production." Some customers expect this as a confirmation step.
• Auto-pause the workflow — if you want absolute safety, add a Sheet column pause_until per part; when a rev change is detected, set it; downstream workflows (e.g. coc-generator) check it and refuse to act on rows where a manual review is pending.

Edge cases

Companion workflows

• rfq-triage — uploads the original drawing when an RFQ arrives. The DrawingsTracker row should be created at the same time (manual step, or extend rfq-triage to write the initial tracker row).
• coc-generator — ships the part. If a drawing rev changes mid-workflow, this watcher catches it before coc-generator runs.
• shop-status-digest — could count "rev changes today" if you want; add the tracker's last_updated == today rows.

Verified

gog gmail messages search/get/attachment, drive ls/rename/move/upload, sheets get/update, and gmail messages modify flag/command syntax all confirmed against the bundled gog v0.19.0 (2026-06-01); re-verify the --plain TSV output shapes on first run. pdftotext confirmed on PATH. The AI classification step uses the standard anthropic tool with the verified claude-sonnet-4-6 model identifier.

Source

See workflow.yaml.