A desktop tool that handles the notice backlog before the deadline.

Saturdays disappear. Then a deadline gets missed.

This is the failure shape Chronos Notice is built against. A firm handling compliance for a few hundred businesses — GST registrations, returns, scrutiny notices, the full stack. A backlog of notices piling up as unprocessed PDFs in a shared inbox, and partners spending most of every Saturday triaging them.

The manual workflow looks like this:

• A junior opens each notice PDF, reads it, types the client GSTIN, the notice type (DRC-01, ASMT-10, REG-17, etc.), the demand amount and the response-by date into a master Excel sheet on Google Drive.
• They look up which partner is assigned to that client from a separate “client-partner mapping” sheet.
• They copy the relevant block into that partner’s personal tab, paste a response-template link, and DM the partner on WhatsApp with the due date.
• The partner replies, the junior marks it done. Or the partner forgets, the deadline passes, and someone notices on Monday.

The Saturday work is painful but tolerable. What breaks a firm is the first time a notice slips past the response deadline — the client gets hit with a penalty and the relationship turns awkward fast. You’re losing trust because you’re losing PDFs in a spreadsheet.

The constraints are tight, and they shaped the product. No cloud upload of notice contents. No subscription with per-notice metering — a one-time install. No new login for the juniors — it has to slot into the existing scanner-and-Sheets workflow. And it has to be ready before the next quarter’s notice wave lands.

A desktop tool that watches the scanner folder. Everything else follows.

Chronos Notice is the desktop product behind this. The shape of it: a small Electron front-end a junior actually clicks on, a Python backend that does the heavy lifting, and a strict local-first posture on the notice contents themselves. The architecture below is the build.

Stack

Architecture, in five hops

1. Scanner inbox watcher. A Python watchdog Observer pointed at the firm’s shared scanner output folder. Debounced (3 second window so a double-scan doesn’t double-index). One worker thread drains the queue, runs one notice at a time.
2. OCR extraction. Tesseract first — it’s fast, local, and handles 80% of cleanly-scanned notices on its own. If the OCR confidence is below threshold or page layout looks unusual, we promote to Claude vision for the same page. The page bytes leave the machine only on the promote path, and only with the user’s OCR-provider choice in config.
3. Claude structured-output extraction. The text payload is handed to Claude with a strict JSON schema for the extracted record — notice_type, gstin, client_name, demand_amount, response_by, hearing_on, issuing_authority, din, plus a per-field confidence score. No prose, no narrative — JSON or it doesn’t commit.
4. Routing to assigned partner. Look up the GSTIN in the client-partner mapping table (we imported their existing sheet on day 9). Attach the partner ID to the notice record. On ambiguous matches (a multi-entity client, say), surface the candidates to the junior for one click.
5. Response template + sheet write + Telegram ping. The notice lands in SQLite. A row appends to the partner’s tab in the master Google Sheet (same sheet they were using before — we did not replace it, we wrote into it). A Telegram message goes to the assigned partner: “GST ASMT-10 for ABC Traders · due 14 Aug · ₹2,84,500 · response template attached.” Three reminders fire after that: 1 week, 1 day, 1 hour before deadline. State machine tracks reply / extension / closed.

How a build like this runs, in order.

• Days 1–3 · samples & shape
  Start from real notice samples, not assumptions.

  Gather representative PDFs across every notice type a firm actually sees (GST DRC-01, ASMT-10, REG-17, IT scrutiny, TDS default, MCA). Don’t start coding. Sit with the juniors, watch them process a real notice each, and write down every field they type into the sheet. The schema comes from that exercise.

• Days 4–7 · the extraction pipeline
  Tesseract first, Claude vision second, JSON-schema strict.

  Build the watcher, the OCR dispatch, and the Claude structured-output extractor. The interesting decision is the OCR fallback ladder: Tesseract local first for minimal cloud exposure, Claude vision as the promote path only when local confidence drops. The hard cases are predictable — a faxed-and-rescanned notice that’s genuinely unreadable, or a GSTIN rotated 90 degrees on weird letterhead.

• Days 8–10 · partner routing + sheet write-back
  Import the client-partner mapping. Write into the existing sheet.

  This is where it’s tempting to over-build. A confidence-weighted classifier can look at GSTIN, entity-name fuzz, and historical routing to pick the assigned partner. Then the write-back wires into the firm’s existing master Google Sheet — same tabs, same column order, so the juniors don’t learn a new layout. Writing into the sheet they already use saves days of change-management friction.

• Days 11–14 · testing on the backlog & deploy
  Run the tool against the full backlog. Ship on day 14.

  Point the tool at the backlog and watch the queue drain — a small fraction need a junior intervention on a low-confidence field, the rest go through clean. Then Telegram-reminder testing on a separate test bot, and hardening: corrupted PDFs out of the scanner, Google Sheets API rate-limits, a missing GSTIN field entirely. Day 14 is install on the partner machines and junior workstations plus a walkthrough.

What the tool is built to change.

We don’t have paying customers yet, so there are no client numbers to post here — we won’t invent them. What we can describe is what the tool does on a clean notice, and the design choices that make it hold up.

Wall-clock from PDF-in-folder to partner-Telegram-ping for a clean GST notice is seconds, not the 20+ minutes a manual pass takes. Tesseract handles the OCR in roughly 4 seconds; Claude extraction takes 6–9 seconds depending on document length; the rest is routing, sheet write, and the reminder schedule. For low-confidence notices that need junior review the wall-clock stretches — but the work surfaces the moment it’s reviewed, not the next Saturday.

The deadline discipline is the part we care about most. The Telegram reminder ladder (1 week / 1 day / 1 hour) is unremarkable engineering — what makes it work is that the message contains the response-template URL and the GSTIN in one line, so a partner can act from the lock screen without opening a sheet first. Friction matters more than cleverness.

And the Saturday triage doesn’t have to exist. The watcher fires extraction the moment a scan lands, the partner gets the ping, and the response template is open by the time they decide to look — so the queue gets handled in short bursts during the work week instead of one painful block.

Honest build lessons, written down before we forget them.