EvidenceVault

Electronic evidence in India sits across two regimes. The Bharatiya Sakshya Adhiniyam came into force on 1 July 2024, but s.170(2) keeps anything pending immediately before that date under the Indian Evidence Act, 1872. So a suit instituted in 2023 still needs a s.65B certificate with one signatory, while a matter filed in 2025 needs a s.63 certificate in the Schedule format with two — the party and an expert. Get the regime wrong and you file the wrong instrument.

The trigger is when the proceeding was pending — never when the record was created or when it is filed. That distinction is easy to state and easy to get wrong under time pressure, and the boundary cases are genuinely unsettled: an FIR registered before the cutoff where cognizance was taken after it, or an appeal filed after the cutoff from a suit instituted before it.

EvidenceVault takes the proceeding facts — type, institution date, FIR and cognizance dates, appeal dates, whether the original device is being produced — and determines the governing statute deterministically. Where the position is genuinely unsettled it says so, shows both options side by side, and requires a named advocate to choose and give a written reason. That choice is logged alongside the tool's own computation, so the record shows both. An advocate can override any determination, with a reason, always recorded.

The regime then drives everything downstream. Choose the Evidence Act and you get a single-signatory s.65B certificate with no Part B and no mandatory hash. Choose the BSA and you get the Schedule format with Part A, Part B, and the expert's qualification, method of examination and s.79A status. Two genuinely different documents from the same evidence, decided by the law rather than by a dropdown.

Underneath, every file is hashed on intake and re-hashed before any certificate is generated. A mismatch is a hard block, not a warning — the demo includes an invoice where a single byte reads "Net 90" instead of "Net 30", invisible to a reader and fatal to the hash.

None of the legal reasoning uses a language model. The regime function is pure — no database, no network, no clock, no defaulted dates — and a test asserts it imports no AI module at all. 385 tests pass, including the ten regime cases specified in the challenge brief, each named so it can be identified in the output.

Note for reviewers: the hosted demo runs on an ephemeral filesystem, so it starts empty. Click "Load demo data" on the Cases page first — it builds three matters covering all three regime outcomes plus the tamper case, deterministically, every time.

• Regime determination — decides between the Indian Evidence Act, 1872 and the BSA, 2023 from the proceeding's own facts, applying the s.170(2) savings clause. Pure deterministic logic, never a model.

• Honest grey zones — where the position is unsettled (FIR before the cutoff, cognizance after; appeal after, original proceeding before) the tool refuses to guess. It presents both options, requires a named advocate to choose with a written reason, and keeps its own computation alongside the choice.

• Two genuinely different certificates — a single-signatory s.65B(4) certificate under the Evidence Act, and the Schedule-format s.63(4) certificate with Part A, Part B and full expert fields under the BSA. The regime selects the template; an unsettled regime blocks generation entirely.

• Tamper detection as a hard block — files are re-hashed before every certificate. A mismatch refuses generation rather than warning. Demonstrated with a one-byte alteration to an invoice.

• Unconfirmed wording marked on the document's face — s.65B(4) prescribes no form, so the IEA template carries [[VERIFY]] markers in red under a "do not file" banner, not buried in a developer note. Six markers, each appearing inline and in an index.

• Full chain of custody — every intake, hash, regime decision, override and certificate is logged. Decision entries record who chose and why.

• DPDP compliance register — a Record of Processing Activities derived from the data actually held rather than from a policy statement, with retention, legal hold, transfer and destruction records.

• Runs offline on ordinary hardware — Python, Streamlit, SQLite. No GPU, no cloud dependency for the evidence workflow, no recurring cost. Built for district-court practice, not metro law firms.

Two things. First, the wording of the s.65B(4) certificate — the Evidence Act prescribes no form, so the template carries [[VERIFY]] markers rather than text I invented. I'd value wording from practitioners who file these regularly.

Second, the per-filing register. s.63(4) requires a certificate at each instance a record is submitted for admission, so certificates should attach to a filing rather than to an exhibit. I deferred the full data model deliberately — it was the largest item and the least demonstrable in the time — and pulled forward only the integrity half, which is the part that shows. That's the next architectural step and I'd welcome views on modelling it.