sboghossian Document Versioning Rule
When to use this
Use this skill to:
- Define and document the firm's versioning policy for a new document management system (DMS) deployment.
- Enforce versioning rules when AI-assisted drafting produces a new document version.
- Train team members on the firm's naming and version-control conventions.
- Recover or reconstruct a document history after an incident.
- Audit whether a document used in a filing, opinion, or transaction was the authorised final version.
In legal practice, document version confusion is a source of costly errors: sending the wrong draft to a counterparty, using a superseded clause in a transaction, filing an unapproved version in court. A clear versioning rule eliminates ambiguity.
Naming convention
Standard format
[MatterID]_[DocType]_[ShortDescription]_v[Major].[Minor]_[YYYYMMDD]
| Component | Description | Example |
|---|---|---|
| MatterID | Firm matter number | 2025-LB-0042 |
| DocType | Document type code (see below) | NDA / SPA / BRIEF |
| ShortDescription | 2–5 word descriptor | DraftMasterAgreement |
| v[Major].[Minor] | Version number | v1.0 / v2.3 |
| YYYYMMDD | Date of this version | 20250514 |
Example: 2025-LB-0042_SPA_SharePurchaseAgreement_v3.1_20250514.docx
Document type codes (standard set)
| Code | Document type |
|---|---|
| NDA | Non-disclosure agreement |
| SPA | Share purchase agreement |
| SHA | Shareholders agreement |
| EL | Engagement letter |
| BRIEF | Court brief / memorial |
| MOT | Motion / application |
| OPN | Legal opinion |
| LTR | Correspondence / letter |
| MEMO | Internal legal memo |
| CONT | Contract (generic) |
| REG | Regulatory filing |
Firms should publish a complete code table in their DMS and in the Knowledge Base ([[efirm-knowledge-base-curation]]).
Version-number scheme
| Version state | Number | When to increment |
|---|---|---|
| First draft | v0.1 | Document first created and saved |
| Substantive draft revisions | v0.2, v0.3 … | Each material revision before partner sign-off |
| Partner-reviewed draft | v1.0 | Partner has reviewed and approved for external transmission |
| External revision received | v1.1, v1.2 … | Each round of counterparty or client comments |
| Agreed / execution version | v[Final] | Parties have agreed; document is ready for execution |
| Post-execution amendment | v2.0 | First amendment to an executed document |
Rule: Only a "v[X].0" document may be transmitted to a counterparty or filed with a court. Odd sub-versions (v0.x, v1.1) are internal working drafts.
Checkout / check-in controls
To prevent simultaneous editing conflicts:
- Checkout: a user locks the document for editing. Others see it as read-only during checkout.
- Mandatory comment on check-in: user describes changes made (e.g., "Revised indemnity clause per partner comments; updated definition of Affiliate per KSA Law").
- Auto-unlock: if checked out for >48 hours without activity, DMS sends a reminder; after 72 hours, an administrator can force-unlock.
- Concurrent editing (if DMS supports): track changes visible to all; merge conflicts reviewed before final save.
Comparison workflow
When a new version is produced:
- Generate a tracked-changes comparison between the new version and the immediately prior version.
- Attach the comparison document as a companion file (same name +
_REDLINE). - For external transmission: send both the clean version and the redline unless the counterparty requests clean-only.
Naming redline: 2025-LB-0042_SPA_SharePurchaseAgreement_v3.1_REDLINE_20250514.docx
Privileged document protections
- Documents marked Legally Privileged must be stored in the privileged sub-folder of the matter.
- Privileged documents must never be transmitted via auto-share or DMS external portal without explicit partner authorization.
- Version history of privileged documents is itself privileged; access is restricted to the matter team.
- Metadata stripping: before external transmission of any Word document, run a metadata clean to remove tracked changes, comments, and author/company fields. Failure to strip metadata has resulted in inadvertent waiver of privilege in reported cases.
Audit trail requirements
The DMS must record for every version save:
- User ID
- Timestamp (UTC + local timezone)
- Action (created / checked out / checked in / transmitted / archived)
- Document hash (SHA-256 or equivalent) for integrity verification
- Matter ID linkage
Audit logs must be immutable — no user should be able to delete or alter a version history entry. Retention: minimum 7 years (matching typical bar file retention requirements; some jurisdictions require longer for certain matter types).
Final / executed documents
- The executed (signed) version is designated
vFINALorvEXEC. - It must be stored in the signed-documents sub-folder.
- A PDF scan or e-signature platform export is the authoritative copy; the Word source version is retained for reference.
- No further edits to a vFINAL document; any change requires a formal amendment document with a new matter sub-file.
Common mistakes
- Email-based versioning ("Draft v3 FINAL FINAL2 revised.docx"): prohibited. All documents go through the DMS.
- Personal desktop saves: documents saved only to a local machine are outside the audit trail and backup system — not permitted.
- Transmitting a v0.x draft: internal working drafts must not leave the firm. Only v[X].0 or vFINAL documents are transmitted externally.
- Metadata in transmitted documents: always strip before sending; metadata reveals tracked changes, prior authors, internal comments.
Related skills
- [[efirm-matter-creation-flow]]
- [[efirm-template-library-firm-branded]]
- [[efirm-knowledge-base-curation]]
- [[efirm-team-handoff-summary]]
- [[efirm-precedent-finder-internal]]