Arbitration and Hearing Management Software: What Happens When the Bundle Changes at 11pm Before Day One of the Hearing?

Why a hearing bundle becomes a crisis at 11pm

The evening before day one of a three week hearing. Counsel has just been permitted to add nine documents to the factual exhibits. That sounds small. It is not, because the pleadings, the witness statements and the expert reports all cite exhibits by bundle page number, and inserting documents shifts the pagination of everything after them. Someone has to repaginate, reissue the index, and then check whether the cross references in five hundred pages of pleadings still point where they claim to point. It is done by paralegals, overnight, under time pressure, in a hotel with bad wifi, and errors from that night surface in the hearing room when a member of the tribunal turns to a page and finds the wrong document.

That is the defining failure of hearing preparation, and it is entirely structural. Bundles were designed for paper, where a page number is a physical fact. Digital hearings inherited the convention without inheriting a way to keep references stable when the underlying set changes. Then add the confidentiality problem: in a multi party arbitration the tribunal sees everything, each party sees its own annotations and not the other side's, experts see only their instructions and the material they were given, and a tribunal secretary has a defined and limited role. A shared folder cannot express any of that.

Institutions carry a second layer that firms do not. Appointment and challenge of arbitrators, advances on costs and deposits, fee accounts across tribunal members with different rates and currencies, case timetables under institutional rules, and confidentiality obligations that vary by seat. That work sits in spreadsheets and email in more institutions than anyone would like to admit.

Problem 1: pagination is treated as identity, and it should not be

The root error is using a page number as the identifier of a document. It is a location, and locations move. What survives change is an exhibit identifier plus an internal page offset, so exhibit C-142 page 7 remains C-142 page 7 no matter what gets inserted before it in the bundle.

A build separates the two explicitly. Every document has a stable identifier and internal pagination. A bundle is a compiled view: an ordered set of documents with a deterministic pagination pass and a generated index. References in pleadings and correspondence are captured as links to the stable identifier, not to the bundle page, and the display resolves them to whatever the current bundle pagination says. Recompile the bundle and every reference in every document still points to the right place, with a printed concordance for anyone working from paper. The overnight paralegal exercise disappears, which is worth the project on its own for a firm that runs long hearings.

Problem 2: confidentiality walls that a shared workspace cannot express

Access in a hearing is not a role hierarchy. It is a matrix. The tribunal sees the full record and its own private annotations. Each party sees the common record plus its own work product. Experts see their instructions and the material within their remit. A tribunal secretary may draft and organize but must not be given a decision making footprint. In a multi party case with confidentiality rings, some documents are visible to external counsel but not to the client, which is normal in competition and trade secret disputes and impossible in a folder based system.

A build implements segregation at the data layer rather than in the interface. Annotation layers are owned by a party and are invisible outside it, with no mechanism to expose them accidentally through search, export or a print view, which is exactly how leaks tend to happen. Access is evaluated per document per user with the reason recorded, and every access is logged, so if a question arises about whether someone saw something, the answer is a query rather than an assertion. Confidentiality ring membership is time bounded, because rings change as the case develops.

Problem 3: Opus 2 and Case Center are strong, and they are still products

Opus 2 is genuinely good at hearings and transcripts and is used in large international arbitrations for good reason. Thomson Reuters Case Center, previously CaseLines, is strong at electronic bundling and is widely used in court settings. If you run a handful of hearings a year and your conventions are conventional, licensing one of them per case is the right answer and we would say so before quoting anything.

The constraints are structural rather than defects. They are products with their own bundle and pagination conventions, so an institution or firm with established conventions of its own adapts to the tool rather than the reverse. Per case commercial models are fine occasionally and become material when you run many matters. Hosting and data residency are set by the vendor, which matters when parties or a seat require data to remain in a specific jurisdiction, and in some arbitrations that requirement is not negotiable. And the institutional side of the work, meaning appointments, challenges, deposits, fee accounts and timetables under your own rules, sits outside their scope entirely, so institutions run it separately regardless.

The realistic build case is therefore concentrated: institutions who need case administration and hearing tooling in one system under their own rules, and firms with enough hearing volume and specific conventions that the licensing and adaptation cost has stopped making sense.

Problem 4: the transcript is the spine of the hearing and it arrives as a stream

In a real time hearing the transcript arrives live from the stenographer, and everything anchors to it. Counsel marks a passage for closing. The tribunal notes a concession. A cross examination question points to an exhibit page, and later someone needs to jump from the transcript line to that exhibit in one action. After the day ends, the corrected transcript replaces the rough version, and any note made against the rough version must survive that replacement.

What a build does is ingest the live feed with page and line addressing, index it for search alongside the bundle, and store annotations against a resilient anchor so notes survive the rough to final transition. Links from a transcript line to an exhibit are first class objects. During closings, a search across transcript and bundle together is the thing counsel actually uses, and no folder based approach comes close.

One unglamorous requirement decides whether any of this is usable: the hearing room network. Rooms in arbitration centers and hotels have unreliable connectivity, and a system that stalls when the connection drops will be abandoned mid morning on day one. The build needs local caching of the bundle, offline annotation with reconciliation on reconnect, and a presentation mode that never waits on the network to display a document. This is not a nice extra. It is the difference between adoption and a very expensive unused system.

Problem 5: institutional administration lives in spreadsheets

For an institution, the hearing is one part of a case that runs for years. Requests for arbitration are registered, arbitrators are appointed under the applicable rules, challenges are handled, advances on costs are calculated and called from parties, deposits are held and drawn against, tribunal fees accrue at agreed rates in multiple currencies, and timetables run against procedural orders with deadlines that move.

A build makes each of these a tracked object with the rule reference attached: appointment workflows with candidate disclosure and conflict checking, deposit ledgers per case with calls, receipts and drawdowns, fee accounts per tribunal member with rates, time and expenses, and a timetable engine where a procedural order generates dated obligations for named parties. The reporting a secretariat actually needs is a caseload view showing which cases are awaiting a party payment, which have deadlines in the next fortnight and which are stalled without an obvious owner. Almost every institution assembles that by hand today.

What this costs and how long it takes

A first release covering document management with stable identifiers, the bundle compiler with deterministic pagination and generated index, the reference graph, full text and optical character recognition search, and party segregated access runs $80,000 to $180,000 and ships in 14 to 20 weeks in our delivery experience. A full platform adding live transcript ingestion with page and line anchoring, hearing presentation mode with offline resilience, annotation layers, video and remote hearing integration, and institutional case administration with appointments, deposits, fee accounts and timetables runs $200,000 to $500,000 across 9 to 15 months.

What drives price up specifically in arbitration: data residency requirements, since deploying into multiple jurisdictions with per case placement is an infrastructure exercise rather than a setting. Optical character recognition and translation volume, which is significant in international matters with documents in several languages and scripts. Real time transcript integration, because stenography feed formats vary by provider and market. Video hearing integration if you need synchronized recording with transcript anchors. And per institution rule variation if you administer more than one set of rules.

What keeps it down: the bundle compiler, references and access control. That is the part that fails at 11pm.

Build versus buy, and when buying is right

License a hearing platform per case if you run occasional domestic arbitrations or a few hearings a year with conventional bundling. The per case cost is modest against the exposure, the tools work, and building your own would be an indulgence. We give that advice regularly and it costs us projects.

Build when two or more of these are true. You are an arbitral institution and your case administration, appointments, deposits and fee accounts currently live in spreadsheets alongside a licensed hearing tool. You run several large hearings a year with bundles in the tens of thousands of pages. Your matters carry data residency or confidentiality ring requirements that a vendor's hosting cannot satisfy. Your conventions for exhibit numbering, pagination or transcript referencing are institutional and you are currently bending them to fit a product. Or your per case licensing across a busy disputes practice has quietly become a significant annual line.

The honest threshold is volume plus specificity. Either one alone points to licensing. Together they point to building.

How to choose a developer for hearing and arbitration software

Ask how a reference to exhibit C-142 page 7 stays correct after the bundle is recompiled with nine new documents inserted. If the answer involves page numbers stored anywhere as identity, you will be repaginating overnight exactly as you do now.

Ask how party segregation is enforced. The right answer is at the data layer, with annotation ownership, per document access evaluation, access logging and explicit handling of search, export and print so a private note cannot leak through a side channel. Interface level hiding is not segregation.

Ask what happens when the hearing room network drops. If there is no local caching, offline annotation and reconciliation on reconnect, the system will be abandoned on day one and the team will go back to paper and a laptop full of PDFs.

Ask about data residency explicitly, including whether a single case can be pinned to a jurisdiction. In international arbitration this is a live commercial requirement, not a theoretical one, and it is much cheaper to design for than to retrofit.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. Arbitration records carry confidentiality obligations that outlive any vendor relationship, and your infrastructure should reflect that.