Insight map

SHARE

The Crown Solved Delivery. Your Firm Now Owns Custody

Ontario's Criminal Digital Disclosure Hub does the hard part well. Defence counsel apply once, verify their Law Society identification, and digital and multimedia disclosure arrives without USB keys, courier bags, or a trip to the Crown's office. Distribution is solved. What arrived with it is a set of custody obligations that attach to individual files, run on their own clock, and sit entirely outside what any practice management or document management system models.

What comes with the download

Access to the Hub is conditional, and the conditions are not boilerplate. Among them:

 

You should that list as a data problem rather than a legal one and three things stand out.

These obligations attach to files, not to matters. A retention clock does not run against a client. It runs against specific material, some of which is marked sensitive and some of which is not, inside a matter that may hold hundreds of items.

One of them is a derived deadline. Sixty days after the case is completed is a rule and an anchor, exactly like every other derived obligation in a criminal file. The anchor — case completion — is an event that happens months or years after the material arrives, and that itself can move.

Several of them are custody-chain facts. Who received a copy, when, under what conditions, and whether they accepted them. That is a log, and it has to be written while it is happening.

Why your document system doesn't hold this

Document management was built around a different question: where is the file and what version is it.

It answers that well. It typically does not model:

    • A per-file classification that changes what rules apply to it. Sensitive and non-sensitive disclosure live in the same folder, distinguished by a naming convention if at all.
    • A retention clock keyed to a matter event. Retention policies in most systems run from upload date or last-modified date, not from the completion of a proceeding.
    • A distribution log. Who was sent what, when, under what conditions, with their acknowledgement recorded.
    • Receipt as a first-class fact. When a tranche arrived, from whom, and what it contained — distinct from when someone got around to uploading it.
    • Outstanding against received. What was requested and has not come is not a document, so a document system has nowhere to put it.

The result is that the most consequential facts about disclosure are not in the disclosure system. They are in email, in a spreadsheet, or in somebody’s recollection.

The Workarounds

Every criminal firm has solved this, and they have solved it the same way:

The disclosure log spreadsheet. Date received, source, description, format, page or file count, whether reviewed. Maintained by one person. Not connected to where the files actually live.

The email folder as the receipt record. The Crown’s covering email is the proof of what arrived and when, so the mailbox becomes the authoritative timeline and nobody can query it.

Folder naming as metadata. 2024-03-11 Disclosure 3 - SENSITIVE carries classification, receipt date and tranche number in a string, because there is no field for any of them.

A calendar reminder for deletion, set manually, if someone remembers at the moment the case completes — which is the moment everyone is least likely to be thinking about file retention.

The drawer. Physical media that arrived before the Hub, still held, with no record of what is on it.

None of this is carelessness. It is what competent people build when the system cannot represent the obligation.

What the gap costs

The deletion obligation is the clearest exposure. It is a condition of access, it runs from an event the file system knows nothing about, and the trigger arrives at the least convenient moment in the life of a matter. A firm with no systematic way to know which files are sensitive, which matters have completed, and what the resulting date is, is relying on memory for a compliance term it signed.

The custody chain is reconstructed rather than recorded. If it is later necessary to establish who had a copy of sensitive material and on what terms, that answer comes from searching email.

Receipt dates live outside the system that needs them. When disclosure arrived, and what was outstanding at a given point, is material that matters downstream. Keeping it in a spreadsheet beside the file store means it is accurate only as long as one person maintains both.

And the workaround degrades under load, as workarounds do. A disclosure log is maintained carefully on a quiet file and loosely on the file where disclosure is arriving in six tranches across four months.

What solving it at the model looks like

Not a better folder structure. A different representation.

Classification as a field, not a filename. Sensitive or not is a property of the item, set once on receipt, and the thing that determines which rules apply to it.

Retention as a rule against an anchor. “Case completion plus 60 days” stored as the rule it is, so the date exists as soon as the matter completes rather than being calculated by whoever remembers. The same architecture as every other derived obligation in the file — and the same reason it should not be a manually entered date.

Receipt as an event with its own record. A tranche arrives: date, source, contents, format, what it was responsive to. That is a fact about the matter, not a property of a folder.

Distribution recorded at the time. Who received what, when, on what conditions, with acknowledgement captured — written when it happens, queryable afterwards.

Outstanding tracked alongside received. What was asked for and has not arrived belongs in the same place as what has, because the gap between them is the thing counsel actually needs to see.

The common thread, as with court dates, is that the system should hold the relationships rather than making a person hold them.

What software cannot do here

They cannot tell you whether disclosure is complete. Whether what has arrived is everything that should have is a judgment about the case, made by counsel, and no system makes it.

They cannot decide whether to seek written authorisation from the Crown for longer retention, or make that request for you.

And they cannot review the material. A system that claims to tell you what is in a disclosure package is making a much larger claim than the one worth making.

What a software can do is ensure that the facts: what arrived, when, from whom, classified how, sent to whom, can it be deleted; when were captured as they occurred, in a form that can be queried, so that none of them depends on a spreadsheet and a good memory.

Pluton Legal Software is built for Canadian criminal defence firms, around how a criminal file actually behaves.

Disclosure is modelled as tranches with receipt dates, sources and classification, not as files in a folder. Retention obligations are stored as rules against matter anchors, so a deletion date exists the moment a matter completes rather than depending on someone setting a reminder. Distribution is logged when it happens. Outstanding items sit alongside received ones. And because matter management, document automation and calendar management run on one set of records, a disclosure receipt date is available to everything downstream that depends on it, rather than living in a spreadsheet beside the system.

Pluton launches for Ontario firms next year. Join the waitlist.

Posted by:

The Law Tech