Digitising 1.2 lakh land-record pages within 30 days on a 200 GB drive
A district office must digitise 1,20,000 pages of legacy land records within 30 calendar days (26 working days). It has two desktop scanners rated at 40 pages per minute in simplex mode, four clerks and two data-entry operators; the office works 7 hours a day. A vendor quotes ₹2.20 per page for 300-dpi colour scanning with OCR and PDF/A output; in-house scanning at 150-dpi grayscale costs ₹0.35 per page but produces no OCR. The shared drive has 200 GB free. A clerk proposes saving files with names like 'record1.pdf' in a single folder; another proposes a register with a unique 12-character ID, a read-only master folder and a separate working folder. The office also has a legal requirement that the scanned copy be admissible as a true copy and that originals be preserved.
1. Recommend a scanning specification and show whether the deadline and storage are feasible.
Read the worked answer
Recommendation: 300-dpi colour, OCR text layer, PDF/A output, with a checksum recorded for each file. The specification is driven by legal admissibility and searchability, not by cost alone.
Deadline. 1,20,000 pages over 26 working days is about 4,615 pages a day. Two scanners at 40 pages per minute give 80 pages per minute, so continuous scanning takes about 58 minutes a day. Even allowing for misfeeds, indexing and quality checks at three times that figure, the work fits within a 7-hour day. The deadline is not the binding constraint; indexing and verification are.
Storage. At 300 dpi colour, a compressed PDF page is typically 0.5–1 MB, so 1,20,000 pages need roughly 60–120 GB, within 200 GB. The 150-dpi grayscale option would use perhaps 12–18 GB but would fail on legibility of old stamps, would have no OCR, and would weaken the true-copy claim. The vendor's ₹2.20 per page is ₹2.64 lakh; the in-house option is cheaper but does not meet the legal and retrieval requirement.
Feasibility depends on keeping originals, recording a hash, and not treating the scan as a replacement until the true-copy procedure is complete.
2. Evaluate the two file-organisation proposals against office-procedure and audit requirements.
Read the worked answer
The 'record1.pdf' single-folder proposal fails on almost every audit test. It has no link to the original register, no village or survey number, no date, no operator name and no way to detect duplicates. Two files can receive the same name, and a later user cannot tell which is the true copy. It also makes retrieval dependent on someone's memory.
The register-plus-ID proposal is the right direction. A unique 12-character ID should encode or link to a register row containing village, survey number, document type, number of pages, date of scanning, operator, scanner, checksum and storage path. The read-only master folder protects the archival copy; the working folder allows OCR correction and indexing without altering the master. Access should be role-based, with deletions prohibited and an audit log retained.
I would add three controls: a daily reconciliation of pages scanned against pages in the register, a backup on a separate device following the 3-2-1 rule, and a sample quality check of at least 5% of files. The legal true-copy requirement also means the register must record who certified the copy and when.
3. What control would you put in place for the two data-entry operators editing the same index spreadsheet?
Read the worked answer
The underlying problem is that a shared spreadsheet with two editors has no reliable version history and no way to resolve conflicting edits. A control that relies on good behaviour will fail under deadline pressure.
The practical fix is to separate the work by record range and reconcile daily: operator 1 handles, say, survey numbers 1–500 and operator 2 handles 501–1000, each in a separate sheet, with a supervisor merging the sheets at a fixed time each day. The merged file is saved as a dated version, and the previous version is retained. If the office has access to a database or a form-based data-entry tool, that is better because it enforces unique IDs and prevents duplicate rows.
Three supporting controls matter: a unique-ID check that rejects duplicate register entries; a daily count reconciliation (pages scanned, rows entered, files in the master folder); and a read-only master so that corrections are logged as amendments rather than silent overwrites. The operators should not both hold write access to the same live file, and the supervisor should sign off the daily reconciliation.