Not a list of claims. Each capability below runs as an animation of the thing itself — the report being scanned, the fields flying into the case, the sections lighting up, the search being understood. Press replay on any of them.
Drop the first information report into the create-case box. Text is lifted in the browser — a scanned report never crosses the network — and between twenty and thirty labelled particulars are pulled out along with every identifier in the narrative body.
Numbers are attributed to a role as they are extracted, so an action aimed at the accused is never aimed at the victim.
The script is detected before anything is parsed. A Tamil report whose embedded text layer is corrupt — a common failure when the font was subsetted badly — is caught automatically and sent to optical character recognition rather than being read as garbage.
The particulars then come back in English while the original stays exactly as filed, so nothing in the record is altered.
The narrative is matched against the offence definitions, and the sections that follow from it are proposed — under the Bharatiya Nyaya Sanhita and, where the conduct is electronic, the Information Technology Act.
Proposed, not applied. The investigating officer accepts, removes or adds; what Argus removes is the blank page.
One box across the whole case. The question is separated into a number, a time filter, a place, a period and a minimum duration — and Argus prints how it understood you before it answers.
The parser is rules, not a language model, so it runs on an air-gapped server and gives the same answer every time it is asked. For output that goes into a case diary, repeatability beats eloquence.
Not a summary. Specific claims — the rented mule layer, the absence of any GSM contact, the five-hour session covering the transfer window — each one clickable through to the row it came from.
Which is what makes a finding usable in a case diary rather than merely interesting.
The findings say what is there. The direction says what to do about it — eight prioritised steps in the order they should be taken, each naming the record it needs and what it is expected to prove.
A junior officer can work the list without a briefing, and a supervisor can see at a glance whether the obvious step was taken.
Nothing above changes what a record contains. What changes is how long it takes to become readable — and on a multi-source case almost the whole saving comes from the days that normally go on making four operators’ exports line up before any analysis can start.
Against a two-year retention window and money that leaves a layer-one account in hours, days are the currency that matters.
Comparison against a conventional single-source workflow on a case carrying a first information report, two operators’ call records, an internet detail record, one phone extraction and a bank statement. Your own figures will vary with the case.
Every capability on this page, in the order an actual investigation meets them — as one continuous sequence.