LitBox: the file layer three other Omnis AI products already read from.

A file system organized around a legal matter, not a generic folder tree

Why a legal AI platform needed to own storage, not rent it

A legal tech company adding "cloud storage" to its roadmap is an easy pitch to over-sell. So before treating it as obviously worth building, I separated what's actually documented from what's a reasonable-but-unproven hypothesis.

Confirmed: AutoDoc's Documents-folder pickup and the in-document "Continue to e-signature" action are both built and working today. Not yet measured: how much time firms actually lose bouncing files between tools — no baseline exists yet, and I'm not inventing one.

What Law Firms Are Documented to Struggle With

This section draws on secondary research — published security and legal-tech sources — not on primary interviews I personally ran with lawyers. I want to be explicit about that distinction up front, because the rest of the case study depends on it.

Research Limitations & Open Questions

In the interest of not overstating what this research package actually is:

• No primary interviews yet. The pain points above are triangulated from published legal-tech and security research, not from sitting with paralegals the way I did on the CasePro matter redesign. That's the single biggest validation gap on this project.
• No adoption or time-savings data. LitBox is in internal beta — there's no usage baseline to compare "before" and "after" against yet.
• Questions I'd want answered before the next design pass: How do paralegals currently decide where a new file "belongs" across your existing tools? What actually stops someone from using a personal Dropbox link for a sensitive attachment today? Which of AutoDoc, OmnisProof, or CasePro would a firm expect to be the "source of truth" for a document if there's ever a conflict?

Why secure storage is a different problem for a law firm

A generic drive protects files. A law firm's drive has to protect privilege — client identities, litigation strategy, medical and financial records, and communications that are confidential by professional obligation, not just by preference. That distinction is what "secure storage" has to mean for LitBox, and it's worth grounding in real incidents rather than abstract risk language.

Five Documented Incidents, Checked Independently

These five cases were supplied to me as potential evidence. I verified each one rather than taking the dates and framing at face value — and in every single case, the date I was given turned out to be when a lawsuit was filed or a settlement was approved, not when the breach itself happened. That gap is worth sitting with on its own: notification and litigation timelines routinely run months to years behind the actual incident.

The Ethical Baseline: ABA Model Rule 1.6 and Comment 8

Two provisions of the ABA Model Rules of Professional Conduct (adopted state-by-state, not federal law) are the actual ethical floor here. Rule 1.6(c), added in 2012, requires a lawyer to "make reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client." Comment 8 to Rule 1.1 (competence), added the same year, requires a lawyer to "keep abreast of changes in the law and its practice, including the benefits and risks associated with relevant technology" — source: American Bar Association ↗. Most U.S. states have since adopted Comment 8 or an equivalent duty. Neither provision mandates a specific technology or certification — they require reasonable safeguards and informed decisions, which is a lower and more contextual bar than "encrypted" or "compliant," and exactly why I'm not attaching either of those words to LitBox without something to back them up.

What "Secure Cloud Storage" Actually Requires

Drawing on Clio's and Sync's own published security guidance (both are legal-software vendors describing their own practices, so I'm treating this as informative rather than independent research) plus CloudLex's incident-pattern write-ups: the baseline components are encryption in transit and at rest, multi-factor authentication, role-based access control, session management, audit logging, and a clear distinction between consumer-grade tools and ones built for legal-grade access control. Sync's own material is blunt about this gap: general-purpose consumer cloud tools are "designed for a broad audience" and often lack the audit trails and access controls firms specifically need. On vendor selection itself, CloudLex's piece on data-privacy certification makes the case that a vendor's own certifications matter when a firm is choosing who to trust with client data — a standard LitBox doesn't yet meet, per the note below.

Established storage products aren't wrong — they're not built for a legal matter

Google Drive, Dropbox, and Box are mature, well-engineered products used by millions of people, including plenty of law firms. The honest question isn't "are they secure" — it's "do they model the thing a law firm actually organizes around: a matter, not a folder."

Three places the shared file layer could have lived. Two were faster to ship — and wrong

Once "every product needs files and none of them own storage" was clear (Section 02), the fix wasn't obvious yet — it rarely is. These are the three real architectural paths I weighed, not a polished single recommendation dressed up after the fact.

Turning research into a defensible scope, not a feature wishlist

Problem Statement

Law firms working inside the Omnis AI ecosystem have no shared, secure place to store case files — so every product either builds its own storage or depends on a general-purpose drive that has no concept of a legal matter, a case team, or an audit trail.

Opportunity Statement

A file layer purpose-built for legal matters — with familiar Drive-like interaction patterns — can become the shared foundation the rest of the ecosystem reads from and writes to, instead of each product solving storage on its own.

Product Principles

Who It's For

Not every persona needs the same surface — that shaped the IA more than any single feature request did.

• Attorneys — need fast retrieval and confidence that a shared file is the current version.
• Paralegals / litigation support — the heaviest daily users: uploading, organizing, and requesting files from clients and co-counsel.
• Firm admins / IT — own storage oversight, user provisioning, and audit exports; a distinct admin-facing surface (Storage Management, Audit Logs & Activity) exists specifically for this group.

MVP Scope

The internal-beta scope covers the core file-management loop end to end — upload, organize, preview, share, request, restore/delete, search, and audit — plus the confirmed ecosystem connections: AutoDoc via File Requests, OmnisProof via in-document e-signature, and embedded search live inside MedChron and AutoDoc itself (Section 12). A conversational AI assistant, deeper CasePro matter-linking, and broader third-party integrations are explicitly out of MVP scope; see Section 10 for what that AI question actually looks like.

A file's trip through four tools, or through one

The scenario below is an illustrative, research-informed composite — not a transcript of an observed user. I'm marking it that way deliberately, because the difference between "this is what I watched happen" and "this is a representative pattern the research supports" matters.

An IA validated against what people actually do with files, not a default sidebar

The navigation below is what's actually built, not a wishlist — it maps directly onto the left sidebar in the shipped screens throughout this case study.

Two Core Flows Worth Walking Through

Uploading into a File Request, end to end. A paralegal opens File Requests → Create New Request, sets a title, a destination folder, an optional deadline and password, and shares it with an external email. The recipient never needs a LitBox account — they land on a scoped upload page. Once submitted, the files route straight into the destination folder, and if that folder is AutoDoc-connected, processing starts without anyone re-uploading anything.

Content search across a matter. Typing into global search surfaces results scoped to Files/Documents, Folders, or Content — the Content tab searches inside text AutoDoc has already extracted, showing the source file, the specific page, and a highlighted snippet, so a user can judge relevance before opening anything.

Designing for the file, and for the moment someone can't access it

Most of a file-management product's design work isn't the happy path — it's what a grid looks like with zero files in it, what happens when someone opens a folder they don't have permission for, and what a delete confirmation says when the action can't be undone after a set window. LitBox's Figma file has more than two dozen empty, error, and permission states designed up front, across core file management, sharing, search, audit, and admin — that scope shaped the workspace as much as the dashboard did.

Three Small Decisions, Kept Small On Screen

Upload favors clarity over cleverness. Restore stays quiet — reversible, one click. Delete inside the retention window costs a second's friction on purpose, so nothing sensitive disappears silently.

The Audit Timeline — the One Security Surface Actually Built

Every upload, download, share, rename, permission change, and restore is written to a single timeline, filterable by action type, with the file, the user and role, and a timestamp on every row. This is the one piece of Section 03's security discussion that isn't a proposed capability — it's built, and it's the concrete answer to "how would a firm know who touched a file."

Admin Gets a Different Dashboard, Not a Hidden Toggle

Storage Management is a separate surface for firm admins — total usage, storage by file type, per-user breakdowns, and quota alerts — rather than a setting buried inside the same view every attorney and paralegal sees. Keeping it separate meant the day-to-day file workspace never had to compromise its simplicity to accommodate governance features most users will never open.

Search that reads what AutoDoc already extracted — and an AI assistant that isn't built yet

Two different things live in this section, and I want to keep them clearly separate: content search across AutoDoc-processed documents is designed and functioning in the prototype today. A conversational AI assistant is a direction worth exploring — and explicitly not something LitBox has built.

How Global Search Actually Works

Why This Matters More Than It Looks

"Search inside documents" sounds like a checkbox feature until you consider what it actually required: LitBox's search only works this way because AutoDoc had already extracted text from the file. Search got meaningfully better specifically because LitBox and AutoDoc share a file — not because of anything search-specific LitBox built on its own. Section 12 shows what that sharing looks like from the other direction.

The AI Assistant Question

The module-architecture research behind LitBox sketches use cases like "find all medical records related to this matter" or "summarize these documents" — a conversational layer on top of content search. None of that is built. I'm including the thinking because the design considerations are real even before the feature is: any answer would need a source citation back to the exact file and page it came from, retrieval would need to respect the same permission model as manual search, and it would sit on top of the existing search index rather than replace it — search stays the fallback a user trusts when they want to see everything themselves.

The part of this product that only makes sense next to the rest of the platform

This section is about LitBox handing files off to the rest of the platform — Section 12 covers the opposite direction, LitBox's own interface running inside other products. Two integrations here are built and working in the current prototype, not proposed on a roadmap slide: File Requests feeding AutoDoc, and e-signature launched directly from a document. Both are shown below exactly as designed.

File Requests → AutoDoc

A File Request isn't just "share a link and wait." It has a title, a description, a destination folder, an optional deadline, password protection, and a defined recipient — and when that destination folder is an AutoDoc-connected folder, submitted files are positioned to be picked up for processing without anyone manually forwarding them.

1 / 3

E-Signature, Launched in Place

Opening a document that needs a signature surfaces a "Continue to e-signature" action that hands off directly into OmnisProof's signer setup — general info, signer list, extra fields, and distribution — without exporting the file and re-uploading it into a separate tool.

Still proposed, not implemented: CasePro matter-linking and a shared permission model spanning the whole ecosystem. MedChron and LitDraft, it turns out, are further along than that — see the next section.

The same search bar, running inside three other products

Search doesn't have to mean leaving the tool you're already in — that was the design brief in so many words, down to the internal Figma section literally named "avoid context switching." LitBox's search is embedded directly inside other Omnis AI products, and what follows are staging screenshots of the real thing, not mockups.

1 / 4

A balanced case, not a "we're just better" claim

"Lawyers will switch because LitBox is more secure" isn't a defensible claim — Drive, Dropbox, and Box are all reasonably secure products. The actual case for LitBox has to rest on something more specific.

The defensible pitch isn't "more secure" — it's "the file layer that gets more useful the more of Omnis AI you already use." That's a narrower claim, and it's one the File Requests → AutoDoc and in-document e-signature flows can actually back up today.

What I can claim, what I can't yet, and what I'd do differently

Impact — Honestly Framed

My Role

I owned LitBox's product design end to end: the competitive and module-architecture research that scoped what "parity with Dropbox and Box" actually required, the information architecture, the full UI system across file management, sharing, search, audit, and admin, and the design of its live ecosystem connections into AutoDoc, OmnisProof, MedChron, and LitDraft. The empty-state, error-state, and permission-state documentation — more than two dozen scenarios specified before a single one shipped — was mine to define, not a gap engineering had to fill in later.

What I Learned