What does the Generate Bates Number Plan skill do?

Convert a document set, prefix requirements, and confidentiality designations into a Bates numbering plan and per-document assignment manifest — fixed-width padding, sequential no-gap/no-reuse numbering, family contiguity, confidentiality endorsement, native slip-sheets, and load-file reconciliation, with a worked example

How do I run the Generate Bates Number Plan skill?

Copy the skill and paste it into your own Claude or ChatGPT, then provide your source data. FinchContext skills run inside your own AI assistant, so your financial data never leaves your control.

Which region does the Generate Bates Number Plan skill cover?

United States. It targets the local tax authority / e-invoicing format described on this page.

Generate Bates Number Plan

Skill: Convert a document set + requirements into a Bates numbering plan and manifest

Region: United States Category: Legal / eDiscovery Does: Takes the document-set size, Bates prefix requirements, and confidentiality designations and produces a Bates numbering plan — the scheme (prefix, padding, start number) plus a complete per-document number-assignment manifest, ready to apply in Relativity, Nuix, or DISCO ahead of production. Authority: Industry standard practice · court ESI/production orders · local rules

Bates numbering gives every produced page a unique, sequential identifier so documents can be cited unambiguously across the litigation. The scheme is usually fixed by the ESI protocol or production order (prefix per producing party, endorsement of confidentiality). Plan it once, up front — renumbering mid-litigation after pages are cited is painful and error-prone.

When this applies

Preparing a production volume: assigning Bates ranges to documents and pages and endorsing confidentiality designations.
Coordinating multiple producing parties or rolling productions that must not collide in numbering.

Plan parameters

Parameter	Example	Notes
Prefix	`ACME`	identifies the producing party; agreed in the ESI protocol
Padding width	`7` → `ACME0000001`	fixed width so numbers sort correctly as text
Start number	`1` (or continue from prior volume)	rolling productions continue the sequence
Volume mapping	VOL001 = `ACME0000001`–`ACME0004500`	range per production volume
Family handling	keep family pages contiguous	parent then attachments, no gaps within a family
Confidentiality endorsement	`CONFIDENTIAL`, `HIGHLY CONFIDENTIAL – AEO`	stamped alongside the Bates per the protective order

Manifest structure (CSV/JSON per document)

doc_id, beg_bates, end_bates, beg_attach, end_attach,
page_count, volume, confidentiality, redacted (Y/N), native_produced (Y/N)

beg_bates/end_bates are the document's page range; beg_attach/end_attach are the family range (parent BEGBATES → last child ENDBATES).
For documents produced natively (e.g. spreadsheets), assign a single placeholder Bates to the slip-sheet and track the native file name.

Build rules

Strict sequential, no gaps, no reuse: number documents in a stable order (custodian, then family, then date) and assign contiguous pages; a number is never reused, even after a clawback (track pulled ranges instead).
Fixed-width padding so ACME0000010 sorts after ACME0000009 as text — choose a width comfortably larger than the expected volume.
Family contiguity: all pages of an email and its attachments get a contiguous block; set beg_attach/end_attach across the whole family.
Endorse confidentiality from the review designations onto the same pages (per the protective order); keep it consistent with the produced load file's CONFIDENTIALITY field.
Natives: a natively produced file gets a slip-sheet with one Bates number and a load-file pointer to the native; page-image Bates apply to imaged documents.
Reconcile to the load file: the manifest's beg_bates/end_bates must match the DAT/OPT Bates fields and the OPT DocBreak boundaries (see build-concordance-dat-load-file).

Worked example (manifest excerpt)

prefix=ACME  width=7  start=1  volume=VOL001
doc_id     beg_bates    end_bates    beg_attach   end_attach   pages  conf                 redacted
DOC000001  ACME0000001  ACME0000001  ACME0000001  ACME0000003  1      CONFIDENTIAL         N
DOC000002  ACME0000002  ACME0000003  ACME0000001  ACME0000003  2      CONFIDENTIAL         N
DOC000003  ACME0000004  ACME0000004  ACME0000004  ACME0000004  1      HIGHLY CONF - AEO    Y
DOC000050  ACME0000451  ACME0000451  ACME0000451  ACME0000451  1(native slip) CONFIDENTIAL  N  → native: budget.xlsx

(Email DOC000001 + its 2-page attachment DOC000002 form a family ACME0000001–0000003; DOC000003 is AEO and redacted; DOC000050 is a native spreadsheet on a slip-sheet.)

Validation checklist

Prefix, fixed padding width, and start number set per the ESI protocol / production order
Numbering is strictly sequential with no gaps or reuse; stable document order defined
Family pages contiguous; beg_attach/end_attach span the whole family
Width large enough for the full (and future rolling) volume; rolling productions continue the sequence
Confidentiality endorsement assigned per document/page consistent with the protective order and load file
Natives handled via slip-sheet with a single Bates + native pointer
Manifest beg_bates/end_bates reconcile with the DAT/OPT load file and DocBreak boundaries
Plan finalized before application; no mid-litigation renumbering of cited pages

Last updated: 2026-05-31 — confirm the prefix/format, confidentiality endorsement, and native-production handling against the case ESI protocol, the protective order, and the target platform's Bates/production module before applying.