# LEGAL MOTION BRAND SPECIFICATION (GENERIC)
## Document formatting standard for court motions and pleadings — Part 2 of Legal Preferences
**Status:** Master / reusable spec — de-identified. Not tied to any specific case, court, or party.
**Consolidates:** two case-specific derivative specs (each independently reverse-engineered from
real filed motions), reconciled into one generic standard. Every party name, case number,
address, email, phone number, attorney, court, and locked date from the source documents has
been replaced with a bracketed placeholder or generalized. This file contains no real
identifying information from either source matter.
> **Purpose.** This is a reusable visual/formatting standard for building motions and pleadings
> as Word (`.docx`) documents — page setup, caption box, small-caps usage, footers, page
> numbers, indentation, signature block, and Certificate of Service. The OOXML shown is literal
> markup meant to be reused directly, not paraphrased. Where a real filing project derives its
> own case-specific spec from this one (party names, case number, court, addresses filled in),
> keep this master current and reconcile the derivative when this file changes.
> **Jurisdiction note.** The structural mechanics below (page setup, the caption table's border
> logic, footer/page-number construction, pagination control) are jurisdiction-agnostic Word
> engineering and travel well across courts. The *content* conventions — caption wording like
> "Civil File Action Number," small-caps party names, three-line court heading blocks, specific
> e-filing system names — reflect the two source matters (both Georgia Superior Court, Family
> Division). Always check the actual court's local rules before relying on any content
> convention here; treat this spec as a formatting engine to adapt, not a substitute for
> checking what a specific court requires.
---
## ◆ 1. PAGE SETUP
US Letter, 1" margins all sides, header 0.5" / footer 0.5" from edge.
```xml
```
First page uses a different (empty) footer. Content width = 12240 − 1440 − 1440 = **9360 dxa**.
---
## ◆ 2. BASE TYPOGRAPHY
- **Body font:** Times New Roman, 12pt (`sz 24`)
- **Body paragraph (`BodyText`):** 1.5 line spacing (`line 360 auto`), 24pt before/after
(`before 480 after 480`), first-line indent 0.5" (`firstLine 720`)
- **Case number** in the caption renders in **Arial bold** (deliberate visual accent against the
Times New Roman body)
```xml
```
> 1.5 line spacing (`line 360`) plus heavy paragraph spacing (480/480) reads as generously
> spaced. If a specific judge or local rule requires strict double-spacing, change `w:line` to
> `480`. Default here matches the two source filings (`360`).
---
## ◆ 3. MOTION TITLE (Heading 1)
Centered, bold, **no underline**, **no small caps**. Title text in title case.
```xml
[Title Of Motion]
```
> **Brand correction carried over from both source specs:** the underlying `Heading1` style in
> both source templates contained `` by default. Both
> real filings overrode underline to none but left small caps inheriting, so the title rendered
> in small caps until corrected. Always explicitly set `` (and
> ``) on the title run — don't rely on a "clean" `Heading1` style existing;
> assume it needs the override.
---
## ◆ 4. COURT HEADING BLOCK
Three centered, bold lines above the caption. Plain bold (typed in capitals — not small caps).
```xml
[IN THE (COURT NAME) OF (COUNTY) COUNTY]
[STATE OF (STATE)]
[DIVISION, IF APPLICABLE]
```
> This exact 3-line block appears **twice** in every filing that includes a Certificate of
> Service — once before the first caption at the top of the document, and again before the
> caption that precedes the Certificate of Service. Do not build it once and assume it carries
> over after a page break; the Certificate of Service is structurally a second mini-document
> glued to the end of the first, with its own repeated heading and caption.
---
## ◆ 5. CAPTION BOX — border-segmented 3-column table
**Column widths:** 4428 / 630 / 3150 dxa.
**Party names use small caps; party roles are italic with manual leading spaces; `v.` is bold.**
**Structural shape — read this before writing any generator code:** the caption is **one table,
two rows, three columns**. It is NOT three plain bordered cells side by side. The visual divider
and rule lines are produced entirely by selectively turning borders on/off per cell, combined
with a vertical merge:
| Cell | Row | Border config | Why |
|---|---|---|---|
| Col 1 (party names, 4428dxa) | Row 1 | `vMerge="restart"`, bottom=single, right=single, top=nil, left=nil | Starts the vertical merge; right border = the vertical divider line running the full caption height |
| Col 1 (party names, 4428dxa) | Row 2 | `vMerge` (continue, no value), bottom=single, right=single, top=nil, left=nil | Continues the merge into row 2 so the divider line extends down through both rows |
| Col 2 (gutter, 630dxa) | Row 1 | left=single, top/bottom/right=nil | Left border here is the SAME visual line as Col 1's right border — they sit on the same edge |
| Col 2 (gutter, 630dxa) | Row 2 | left=single, top/bottom/right=nil | Same divider, continued |
| Col 3 (case no., 3150dxa) | Row 1 | bottom=single, top/left/right=nil | Horizontal rule directly under "Case No." text |
| Col 3 (case no., 3150dxa) | Row 2 | top=single, left/bottom/right=nil | The SAME horizontal rule, expressed as the top border of row 2 instead of the bottom border of row 1 — this is what creates the stepped/offset look where the case-number rule sits at a different height than the party-name block's bottom border |
Row 1 height ≈ 2048 twips (tall — holds roughly 9 lines of party block). Row 2 height ≈ 593
twips (short — exists almost entirely to carry the continuation of the vertical merge and the
top-border half of the case-number rule).
**MANDATORY — table-level border reset.** In addition to the per-cell border map above, the
table itself (`w:tblPr`) MUST carry an explicit `w:tblBorders` block with every side set to
`nil`/`none`. If this is omitted, document-generation libraries (confirmed with docx-js) silently
default the table to a fully bordered grid at the table level. Per-cell `nil` overrides do not
reliably suppress this table-level default in every renderer — a LibreOffice-rendered PDF preview
can resolve the conflict in favor of the cell-level `nil` (looking correct), while Microsoft Word
resolves the same conflict in favor of the table-level default and renders a full visible grid
around every cell. **A clean rebuild from the same generator code reproduces this defect
identically — it is not a one-off glitch, it is a missing setting**, and it will not show up in a
LibreOffice-only preview. The fix must be applied in the generator source, not just by re-running
the build.
```xml
[Party 1 Name]
,
[Party 1 Role]
v.
[Party 2 Name]
,
[Party 2 Role, e.g. Respondent, Pro Se.]
[Case No. label, e.g. "Civil File Action Number"]
[Case Number]
```
**docx-js equivalent of the table-level reset** (the part most often missing):
```javascript
new Table({
width: { size: 8208, type: WidthType.DXA },
columnWidths: [4428, 630, 3150],
borders: {
top: { style: BorderStyle.NONE }, bottom: { style: BorderStyle.NONE },
left: { style: BorderStyle.NONE }, right: { style: BorderStyle.NONE },
insideHorizontal: { style: BorderStyle.NONE }, insideVertical: { style: BorderStyle.NONE }
},
rows: [ /* ... */ ]
})
```
Without the `borders` key on the `Table` constructor itself, docx-js defaults to a fully
bordered grid regardless of what the individual `TableCell` border settings say.
### ◆ 5A. CAPTION VERIFICATION — DO NOT SKIP
Before marking any caption complete, confirm against a rendered PDF (not just the raw XML) that:
- [ ] A continuous vertical line is visible running the full height of the caption, separating
party names from the case number
- [ ] A horizontal line is visible directly beneath the case number block, NOT directly beneath
the party-name block
- [ ] The vertical line and the case-number horizontal line do NOT align at the same height —
the offset is intentional and correct (see table above)
- [ ] If generated programmatically, confirm the generator used `verticalMerge: RESTART` /
`CONTINUE` (or the library's equivalent) — not just visually similar cell borders that
happen to look like a table. A borderless 3-column table with manually drawn lines is not
the same structure and will silently drift from this spec on the next edit.
- [ ] **Open the unpacked `word/document.xml` and confirm the table's `` block contains
an explicit `` with all six sides set to `nil`/`none`.** A LibreOffice-rendered
preview that looks correct is NOT sufficient proof this is set correctly — LibreOffice and
Word resolve a missing/conflicting table-level border policy differently, and only Word's
behavior matters for the actual filed document.
---
## ◆ 6. SMALL CAPS — usage map
| Where | Small caps? | Markup |
|---|---|---|
| Party names in caption | **Yes** (plain) | `` |
| Signature block name | **Yes** (with bold) | `` |
| Motion title | **No** — see §3 correction | set `` |
| Court heading block, party roles, body text, COS title | No | — |
Use small caps **only** for party names (caption) and the signature name. Never in titles or
headings.
---
## ◆ 7. FOOTER + PAGE NUMBERS
Footer is a **3-cell borderless table** (3192 each), all cells centered, 9pt (`sz 18`):
- **Left cell:** short motion title (update per filing — e.g., "Motion to Compel")
- **Center cell:** "[Party 1] v. [Party 2] – [Case Number]"
- **Right cell:** "Page " + `PAGE` field (label normal weight, number bold)
First-page footer is empty (suppressed). Page numbering label "Page " is plain; the number
itself is bold.
```xml
[Motion Short Title]
[Party 1] v. [Party 2] – [Case Number]
Page
PAGE
1
```
> The **left footer cell carries the motion's short title** — update it per document. Center and
> right cells stay constant across all filings in the same matter.
### ◆ 7A. PAGE NUMBER FIELD — docx-js gotcha
If building this programmatically with docx-js, its `SimpleField` constructor takes **positional
arguments, not an options object**. Passing an options object silently produces the literal text
`[object Object]` as the field instruction — meaning the footer shows "Page" but the number never
resolves. This defect is **not visible in a LibreOffice-rendered preview** in any obvious way
(LibreOffice may render a blank or a stale cached number) — the only reliable check is unpacking
the built `.docx` and reading the raw footer XML.
```javascript
// WRONG — produces "[object Object]" as the field instruction; page number never resolves
new SimpleField({ instruction: "PAGE" })
// CORRECT — first argument is the field instruction string, second (optional) is a cached
// display value shown before Word first recalculates the field
new SimpleField("PAGE", "1")
```
Always verify by unpacking the built `.docx` and confirming the footer XML contains a real field
instruction (`PAGE`), not a stringified-object artifact.
---
## ◆ 8. SIGNATURE BLOCK
Order: closing line → blank → signature rule (36 underscores) → name (**bold + small caps**) →
role → [address, if applicable] → email → phone. Single-spaced within the block (`line 240 auto`
on the rule paragraph).
```xml
Respectfully submitted this ____ day of __________, 20____.
____________________________________
[Signer Name]
[Signer Role, e.g. Respondent, Pro Se]
[Address line 1, if the filing requires it]
[Address line 2 — City, State ZIP]
Email: [Signer Email]
Phone: [Signer Phone]
```
> **E-filing variant:** when filing electronically, replace the blank underscore rule with a
> conformed signature line, and repeat the bold small-caps name directly beneath it as the
> identification line:
>
> `/s/ [Signer Name]`
> **[SIGNER NAME]** (bold + small caps)
> [Signer Role]
> [Address, if applicable]
> Electronic Service: [Signer Email]
>
> Do not use a blank underscore rule in any document filed through an e-filing system. Both the
> `/s/` conformed line and the typeset small-caps name line appear in every e-filed signature
> block — never just one or the other.
> **Pagination requirement (see §11):** every paragraph in the signature block above must carry
> `keepNext="true"` (docx-js: `keepNext: true`) except the final line, and every line must carry
> `keepLines="true"`. This is what prevents the block from splitting across a page boundary —
> e.g., a phone number stranded alone at the top of a new page while the rest of the block sits
> on the prior page. This is a real, observed failure mode, not a theoretical one; see §11.
### ◆ 8A. SIGNATURE + NOTARY SIDE-BY-SIDE LAYOUT (sworn documents only)
For any document requiring a notarized signature (affidavits, verifications, and similar sworn
statements), place the signer's signature block and the notary's acknowledgment block **side by
side in a two-column, one-row, borderless table** rather than stacked vertically. A vertically
stacked version tends to overflow onto a near-empty extra page (the notary's final lines
orphaned alone), and wastes vertical space a side-by-side layout doesn't need.
**Why side-by-side:** the signer's block (signature line, name, role) is short — typically 3
lines. The notary's block (sworn-before-me date, signature line, "Notary Public," commission
expiration, seal space) is longer — typically 5–6 lines plus reserved blank space for an
embossed or ink stamp. Stacking forces the page to accommodate both blocks' full heights
sequentially. Side by side, each column only needs its own height.
**Column layout (4680 / 4680 dxa, borderless):**
| Left column (signer) | Right column (notary) |
|---|---|
| Signature rule line | "Sworn to and subscribed before me this [date]." |
| Signer name (bold, small caps) | blank spacing |
| Signer role | Signature rule line |
| | "Notary Public" |
| | "My Commission Expires: ___" |
| | blank spacing reserved for the physical stamp/seal (≈2 blank paragraph lines, not just one) |
```javascript
// docx-js pattern
new Table({
width: { size: CONTENT_W, type: WidthType.DXA },
columnWidths: [4680, 4680],
borders: { top: nilB, bottom: nilB, left: nilB, right: nilB, insideHorizontal: nilB, insideVertical: nilB },
rows: [ new TableRow({ children: [
new TableCell({ /* signer column — signature rule, name, role; keepNext/keepLines chained */ }),
new TableCell({ /* notary column — sworn-before line, rule, "Notary Public", commission line,
then explicit reserved blank space for the stamp */ })
]})]
})
```
**Reserve real vertical space for the stamp.** A notary stamp/seal is a physical object roughly
1.5–2 inches across; a single blank line is not enough room. Use at least two blank paragraph
lines (or an explicit spacing value of ~480 twips) after the "[NOTARY SEAL]" placeholder text so
the printed document has visibly usable white space for the actual stamp.
> Apply `keepNext`/`keepLines` to every paragraph inside both table cells per §11 — being inside
> a table cell does not exempt a block from the orphan/split risk; if the table itself straddles
> a page boundary, an un-flagged cell can still split internally.
---
## ◆ 9. CERTIFICATE OF SERVICE
The Certificate of Service repeats the court heading + caption box (§4–5), then the title
**"Certificate Of Service"** (Heading 1, no small caps), the certify paragraph, the served-party
block, the date line, and the full signature block (§8) — not a trimmed version.
**Mail-service version:**
```
I hereby certify that I have this day served a true and correct copy of the
foregoing [DOCUMENT TITLE IN CAPS] upon [opposing party / counsel for opposing
party] by depositing a copy in the United States Mail with sufficient
first-class postage prepaid, addressed as follows:
[Opposing Counsel or Party Name]
[Firm Name, if applicable]
[Address]
[Email]
This ____ day of __________, 20____.
```
**Electronic-service version** (adapt the system name to whatever e-filing platform the
jurisdiction actually uses — examples include Georgia's PeachCourt and eFileGA systems, but
every state and many counties run their own):
```
I hereby certify that I have this day served a true and correct copy of the
foregoing [DOCUMENT TITLE IN CAPS] upon [opposing party / counsel for opposing
party] via the [e-filing system name] electronic filing and service system
pursuant to [applicable statute/rule], which delivered notice and a link to a
file-stamped copy of this document to:
[Opposing Counsel or Party Name]
[Firm Name, if applicable]
[Address]
[Email]
This ____ day of __________, 20____.
```
> The served document's title appears in **literal capitals** in the certify sentence (not small
> caps). The COS title line itself is title case: "Certificate Of Service."
---
## ◆ 10. HOW TO USE THIS SPEC
When building any motion or pleading from this standard:
1. Page setup per §1; base styles per §2.
2. Court heading block (§4) → caption box (§5, swap party text/case number only, keep the border
map exactly, including the table-level `nil` reset) → title (§3, no small caps, no underline).
3. Body in `BodyText` style (1.5 line, 0.5" first-line indent, 480/480 spacing).
4. Footer per §7 — update the left cell with the short motion title; build the PAGE field per
§7A using the correct argument shape if generating programmatically.
5. Signature block per §8 (underscore rule or `/s/` for e-filing), with `keepNext`/`keepLines`
per §11. If the document requires notarization, use the side-by-side layout per §8A instead
of a vertical stack.
6. Page break (§11.1) → court heading repeated (§4) → caption repeated (§5) → Certificate of
Service per §9 — pick the mail or electronic-service variant. The COS is its own page; it is
never appended to the bottom of the signature-block page.
7. Small caps only on party names in the caption and on the signature name (§6).
8. Run the post-build review in §11.3 before presenting any document as final — every time,
regardless of how it was generated.
---
## ◆ 11. PAGE BREAK BEFORE CERTIFICATE OF SERVICE — AND PAGINATION CONTROL GENERALLY
### 11.1 — The Certificate of Service always starts on a fresh page
Place exactly one explicit page break immediately after the closing signature block of the main
document and immediately before the second copy of the court heading that introduces the
Certificate of Service. This is not optional spacing — it is a hard page break.
```xml
```
docx-js equivalent: insert a `new Paragraph({ children: [new PageBreak()] })` between the end of
the main signature block and the start of the repeated court-heading + caption block.
**Never let the Certificate of Service simply flow onto whatever page the signature block
happens to end on**, even if it would technically fit. It always gets its own page.
### 11.2 — General pagination control
Two real, observed defects motivate this section: a heading rendering as the last line on a page
with its content stranded on the next page, and the final line of a signature block ("Phone:
[number]") rendering alone at the top of an otherwise blank page while the rest of the block
stayed on the prior page. Both share the same root cause — nothing told the renderer to keep a
heading glued to what follows it, or to keep a short multi-line block together as a single unit.
**The fix — apply these rules to every heading and every short multi-line block:**
- **Every heading paragraph** (court heading lines, section headings, motion titles,
"Certificate Of Service") must carry `keepNext="true"` AND `keepLines="true"`.
```xml
...
```
docx-js: `new Paragraph({ keepNext: true, keepLines: true, ... })`
- **Every line inside a signature block, notary block, COS served-party address block, or any
other short sequential block that must visually stay together** must carry `keepNext="true"`
on every line except the last, and `keepLines="true"` on all of them. This chains the lines so
the renderer treats the block as indivisible — it places the whole block on the current page or
pushes the whole block to the next one, never splitting it mid-block.
- **Ordinary body paragraphs** (the numbered substantive paragraphs of a motion) do NOT need
`keepNext` — they're expected to flow and split normally like any prose paragraph. Only apply
`keepNext`/`keepLines` to headings and short structural blocks that read as a single unit.
- **Prefer the side-by-side layout over a tall vertical stack for combined signature+notary
blocks** (§8A) — a long vertical stack is more prone to overflow and orphaning even with
`keepNext`/`keepLines` applied, simply due to its total height.
### 11.3 — Mandatory post-build review
**Required for every document, every time, regardless of who or what built it.** Generating
correct OOXML does not guarantee correct pagination or correct rendering in the actual target
application — some defect classes are only visible in Microsoft Word and not in a LibreOffice
preview. Both parts below are required.
**Part A — Visual pagination review (render to images):**
1. Convert the `.docx` to PDF.
2. Render every page to an image.
3. Visually inspect every page boundary — not just the first and last page — and confirm:
- [ ] No heading is the last line on a page with its content starting on the next page
- [ ] No signature block, notary block, or address block splits across a page boundary
- [ ] No page contains only a single orphaned line or is near-empty from a stranded fragment
- [ ] The Certificate of Service begins on its own fresh page (§11.1), with the full court
heading and caption repeated above it
- [ ] The caption table renders with the correct vertical divider and horizontal rule lines
(§5A)
**Part B — Raw XML spot-check (catches defects invisible to Part A):**
4. Unpack the built `.docx` and open `word/document.xml` directly.
5. Confirm:
- [ ] The caption table's `` contains an explicit `` block with all six
sides `nil`/`none` (§5A) — do not rely on the rendered preview alone
- [ ] Every footer's field element has a real field instruction (e.g., `w:instr=" PAGE "`) —
not the literal text `[object Object]` or any other stringified-object artifact (§7A)
- [ ] Any pre-filled values (dates, county names, etc.) show the intended filled text, not a
leftover blank or a broken template-literal artifact (stray `{`/`}` characters)
6. If any issue is found in either part, fix it, rebuild, and repeat both parts until clean.
7. Only after both parts are complete should the document be presented as a finished filing.
> **Why this matters beyond cosmetics:** an orphaned line, a heading separated from its content,
> a split signature block, an invisible page number, or a fully-bordered caption table looks
> unprofessional in a court filing and reads as careless. These are exactly the kind of small
> defects a retained attorney would immediately notice — and two of the defect classes above
> were specifically missed by visual-only review and only caught by opening the real file in
> actual Microsoft Word. That is why the XML spot-check exists as a separate, mandatory step.
---
## ◆ 12. PATTERN: PRE-FILLED CONSTANTS FOR REPEATED VALUES
When a filing project has known, locked-in values that repeat across many documents in the same
matter — a signing date used across an entire notary session, a notary's county, a consistent
short case caption — define them as **named constants once**, near the top of whatever builds the
documents, and reference them everywhere via those constants rather than hand-typing the value at
each occurrence.
```javascript
// Example shape — values below are placeholders only, not real locked values
const SIGN_DATE_ORDINAL = "3rd"; // "This 3rd day of ..."
const SIGN_MONTH_YEAR = "September, 2026";
const NOTARY_COUNTY = "Sample"; // renders as "COUNTY OF SAMPLE"
```
This guarantees every instance updates together if a locked value changes, and avoids the
partial-fill inconsistency that's easy to introduce when the same value is typed manually in
several different places across several documents. If a locked value changes, update the
constant in one place and rebuild — don't hand-edit individual strings inside a generated
`.docx`.
Leave values as open blanks (`____ day of __________, 20____`) rather than pre-filling anything,
unless the project has an actual reason to lock a value in advance (a scheduled notary session, a
filing deadline tied to a specific date) — pre-filling is an optimization for a known, repeating
value, not a default behavior.
---
*Legal Motion Brand Spec (Generic) v1.0 · Consolidated and de-identified from two independently
reverse-engineered, case-specific derivative specs · July 2026*