Legal document naming and version control should answer three questions immediately: what is this file, which matter does it belong to, and is it safe to use? When the answers depend on opening several copies called final, final2, and final_revised, a deadline turns into a forensic exercise. A small set of naming rules, combined with system-controlled history and clear approval states, removes much of that uncertainty.

The aim is not to encode every fact in a filename. It is to make documents findable while the document system preserves richer metadata, permissions, audit events, and earlier versions. Information-security and incident obligations must be assessed separately. Official starting points include the Information Technology Act, 2000 on India Code, CERT-In, and the Ministry of Electronics and Information Technology.

What should a legal filename contain?

A filename needs a stable core. Use fields that remain useful when the file is downloaded, emailed, or placed in an export. A practical pattern is:

MATTERID_DOCUMENTTYPE_SHORTSUBJECT_DATE_STATUS_LANGUAGE.ext

For example:

M1042_WitnessStatement_Rao_20260718_Draft03_EN.docx

The exact pattern matters less than consistent definitions. Keep it short enough for common systems, avoid characters that break across platforms, and never put unnecessary personal, privileged, or strategic information in a filename. Filenames are often exposed in download logs, email subject lines, browser histories, and shared links.

ElementRuleExample
Matter IDUse the system-issued identifierM1042
Document typeSelect from a controlled listWrittenSubmission
Short subjectUse a neutral, recognisable labelJurisdiction
DateUse YYYYMMDD and define what the date represents20260718
StatusUse an approved workflow termDraft03
LanguageAdd only when teams need itEN

Do not include client names if the matter ID is enough. Do not use “confidential” as a substitute for permissions. Do not place the author's initials where the system already records authorship. Gotham's document workflows can be assessed against this model, but the naming policy should remain portable and owned by the firm.

How should document types and dates be standardised?

Create a controlled vocabulary that reflects actual practice. WS, WitnessStmt, and Witness_Statement should not describe the same type in different folders. Start with the documents teams frequently create, then add new values through a named owner rather than letting each matter invent its own list.

Define the date field carefully. A received date, execution date, filing date, effective date, and document date can all be different. One filename cannot safely represent all five. Choose the date most useful for identification and store the others as metadata.

Use a short dictionary:

Document typeFilename valuePrimary dateRequired metadata
Court orderOrderOrder dateCourt, case number, coram, source
CorrespondenceLetter or EmailSent dateSender, recipients, received time
AgreementAgreementExecution date if confirmedParties, effective date, status
PleadingPetition, Reply, or defined typeFiling date when filedForum, case number, filing status
Research noteResearchMemoCurrent version dateAuthor, reviewer, cut-off date

If the date is unknown, do not manufacture one to satisfy the pattern. Use a documented placeholder or omit the field, then create a data-quality task. A false date can mislead users more than an explicit gap.

How should draft numbers and approval states work?

Version and status are related but different. Version describes sequence. Status describes whether the document is ready for a particular use. v7 does not mean approved, and Final does not explain what happens after a filing correction.

Use system-controlled version history for documents stored in the workspace. A filename version is most useful when a copy leaves that system. Define states such as:

  • Working: active authoring, not ready for review;
  • Review: submitted to a named reviewer;
  • Approved: approved for the stated purpose;
  • Issued: sent, signed, filed, or otherwise released;
  • Superseded: retained but not current; and
  • Withdrawn: removed from active use with an explanation.

Only authorised roles should move a document into an approved or issued state. Record the approver, timestamp, intended purpose, and related issued artifact. A PDF filed with a court and the editable document used to prepare it are not interchangeable; link them as separate records.

An approval matrix prevents ambiguity:

TransitionPermitted actorRequired evidence
Working to ReviewAuthor or matter ownerReview assignment and due date
Review to ApprovedDesignated reviewerComment resolution or recorded decision
Approved to IssuedAuthorised matter roleRecipient, channel, and issue timestamp
Issued to SupersededMatter ownerReplacement record and reason

Where should the authoritative copy live?

Choose one approved matter workspace as the source of truth. Email attachments, desktop downloads, shared drives, and messaging applications may be working channels, but they should not become competing archives. Each document record needs a stable identifier and a link that continues to resolve after folders are reorganised.

Establish a check-in rule for offline work. When a lawyer downloads a file for travel or external collaboration, the system should show that a copy is out, and the user should reconcile it before another version is issued. Co-authoring can reduce collisions, but it does not replace approval or change tracking.

Folder structure should support browsing without carrying the entire classification model. A useful matter structure might include 01 Administration, 02 Source Material, 03 Draft Work Product, 04 Correspondence, 05 Filed or Executed, and 06 Research. Keep issued records read-only for ordinary users and link later corrections rather than overwriting history.

Teams can review Gotham's practice workspace, security overview, and pricing as part of a product assessment. Test actual permission inheritance, export behaviour, audit access, and recovery rather than relying on labels alone.

How should access and sharing be controlled?

Naming tells users what a file is; permissions determine who can reach it. Apply access at the matter and restricted-subfolder level, then review exceptions. Avoid broad shared links and personal accounts. Define whether recipients may download, reshare, print, or retain a copy, and set expiry where appropriate.

Before external sharing, require the sender to confirm:

  • the correct matter and current approved version;
  • the intended recipients and their addresses;
  • whether comments, tracked changes, hidden sheets, or metadata remain;
  • the permitted sharing channel and expiry;
  • any password or key is transmitted separately under policy;
  • the issue event is recorded against the document; and
  • later withdrawal or replacement can be communicated.

Treat incident response as a connected workflow. CERT-In publishes official directions and advisories through its site. The firm should determine which requirements apply, who evaluates an event, how evidence is preserved, and who may communicate externally. A generic file-naming guide cannot make those determinations.

What audit history and recovery controls are useful?

The audit trail should show creation, upload, download where supported, edits, status transitions, permission changes, sharing, deletion, and restoration. It should identify the actor, timestamp, document, matter, and action without exposing document content to an unnecessary audience.

Test recovery in practice. A backup statement is weaker than a successful restoration exercise. Select a representative matter, restore a deleted file and an earlier version to a safe test location, verify permissions and metadata, and document the result. Keep the restore path separate from the power to erase audit history.

Use an exception register for files that cannot follow the normal process, such as large evidence exports, specialist formats, or portals controlled by a court or counterparty. Name an owner and record where the authoritative copy resides, how integrity is checked, and how it returns to the matter record.

How can a firm migrate an untidy document collection safely?

Do not begin with a bulk rename across live matters. Inventory first. Identify duplicate hashes, invalid characters, excessively long paths, broken permissions, personal data in filenames, and folders where several “final” documents compete. Preserve originals and migration logs.

Migrate in controlled stages:

  1. approve the naming dictionary and metadata map;
  2. pilot on a closed or low-risk matter copy;
  3. create a source-to-target manifest;
  4. normalise names without changing document content;
  5. validate counts, hashes where appropriate, metadata, and permissions;
  6. obtain matter-owner sign-off;
  7. make the old source read-only for a defined transition; and
  8. retain or dispose of legacy copies under approved policy.

If research files are part of the migration, connect each note and authority table to the legal research workflow for India. A clean filename is helpful, but source provenance and research cut-off dates belong in the record too.

What should teams check before adopting the policy?

Run realistic tests with pleadings, emails, scans, spreadsheets, bilingual documents, executed agreements, and corrected filings. Ask users to locate the current approved copy without help. Then export the file and confirm that its filename still makes sense outside the workspace.

  • Matter IDs are stable and do not reveal unnecessary information.
  • Document types and statuses come from controlled lists.
  • Date semantics are documented.
  • System version history remains authoritative.
  • Approval and issue events identify the responsible person.
  • Superseded documents are retained but clearly unavailable for accidental use.
  • External sharing checks metadata and recipient details.
  • Audit and restore tests have named owners.
  • Exceptions are logged rather than hidden in personal folders.

Good legal document naming and version control makes the correct file boringly obvious. It also accepts that filenames cannot carry security, approval, and provenance alone. To design a controlled document lifecycle around your firm's existing tools, contact Gotham for a workflow discussion.