Munshi : The Clerk

THE PROBLEM. Between a signed petition and an accepted e-filing sits a day of work nobody bills for: annexures marked, pages numbered consecutively, a master index with page ranges that are actually right, everything merged into one OCR-searchable PDF and bookmarked to that index. .

WHAT MUNSHI DOES. Choose the forum (NCLT, Supreme Court, Delhi High Court, or the district courts on eCourts) and it loads that portal's rules. Drop in the signed petition and annexures. It reads them, does an OCR scan, classifies each paper from its content, marks every annexure, numbers every page following its own size and rotation, builds the master index from your descriptions with page ranges counted from the assembled bundle, bookmarks the bundle to that index, splits at the upload cap when it must, and runs a preflight that says what the counter would have said: encrypted files, pages with no text layer, illegal filenames, missing vakalatnama or fee, each against the rule it comes from. Then it pulls the case details out of the petition itself (parties, Act and section, claim value, and for NCLT the bench, registered addresses and date of default) and lays them out as a paste sheet alongside the further fields the chosen portal's e-filing form asks for, so the advocate pastes rather than retypes. Anything Munshi guessed is shown amber until confirmed.

THE CHECK WE ARE PROUDEST OF. Munshi reads the petition, extracts every citation, and checks that every cited annexure was filed, every filed annexure is cited, and they are bound in the order the pleading introduces them. A cited annexure that is not on record is a guaranteed objection and, at hearing, a submission you cannot make. No human reliably catches it in a 300-page bundle. This takes a second.

IT NEVER SIGNS AND NEVER SUBMITS. The digital signature and the submit button stay with the advocate. Portal terms generally prohibit automated access, the DSC is personal under the IT Act, and the Supreme Court portal is tied to an AOR code. That is a design constraint, not a limitation.

NOTHING IS UPLOADED. The whole tool runs in the visitor's browser. Petitions are privileged material; they never reach a server, because nothing is sent anywhere: the page is served once, and everything it does to your papers happens in the browser.

HOW IT WAS BUILT, Munshi was vibe-coded with Claude, end to end, by two litigators in Udaipur. No model runs at filing time. Judgment-shaped work, such as reading a registry's defect memo or naming an annexure from its contents, is where AI belongs, and it is the next layer.

Annexure cross-reference: every annexure the petition cites must be filed, every annexure filed must be cited, and the binding order must follow the pleading. A missing cited annexure is a hard failure, named.

Portal packs for NCLT, Supreme Court, Delhi High Court and the district courts (eCourts e-Filing 3.0), each carrying its own requirement list, format rules and citations. Rules are data, not code.

Preflight against the rules: encrypted or locked PDFs, pages with no text layer (counted per paper), page size and rotation, digital signature presence, the 20 MB cap, illegal filenames, missing core papers. Each check cites its source.

OCR in the browser: on the advocate's say-so, every upright page with no text layer is given an English text layer by an OCR engine running locally in the browser (tesseract.js), and preflight re-runs itself, so a scanned invoice or receipt becomes searchable as Rule 8.1 requires. English only for now; the engine comes down from a CDN, the page image never goes up anywhere.

One bookmarked bundle: annexure marks stamped, pages numbered following each page's own size and rotation, a master index with page ranges counted from the assembled bundle, and a PDF outline built to that index, as Rule 8.1 requires.

Split at the cap, bookmarks intact: parts that each sit under the portal's upload limit, each carrying its own outline.

Content-based classification and auto-fill: petition, affidavit, vakalatnama, board resolution and demand notice recognised from their text; parties, Act, section and claim value read from the cause title, and every auto-filled value visibly marked as unconfirmed until the advocate confirms it..

Per-portal paste sheet: parties, Act and section, claim value, and for NCLT the bench, registered addresses and date of default, pulled from the petition itself and laid out with the further fields that portal's form asks for (the advocate's own particulars are typed once), guessed values shown amber until confirmed, copied as one sheet. Munshi never touches the portal, captcha, OTP, password, DSC or submit.

Runs entirely in the browser. No server, no upload, no document ever leaves the machine.

Honest by construction: every claim in the interface was audited against the code, a regression harness builds 1,920 bundles across every option combination, and what is not built says so on screen.