In-House Counsel Document Format — Multi-Track House Style

Author: Alessandro Dardano. Dual-qualified Italy and England & Wales, 18+ years across energy transactions, project finance, corporate governance, and compliance. Originally developed for in-house use, generalised for publication.

Version 2.1 — May 2026. Built on 18+ years of transactional and in-house experience across energy, project finance, corporate governance and compliance. Version 2.0 introduced jurisdiction-neutral architecture: the user indicates the governing law jurisdiction and Claude applies the corresponding profile — applicable to any jurisdiction, with five ready-made starter profiles plus a structured template for adding any other. Version 2.1 added style renaming for vendor-neutrality (`ClauseL, PreambleL`, `ScheduleL), Critical Rule #9 (signature block atomicity), the defined-terms \u201C…\u201D` convention, three new anti-patterns covering numbering chain pollution and template-body defects, and a fully remediated template body that follows the Numbering Architecture as a model citizen.*

Licensed under Apache 2.0. © 2026 Alessandro Dardano. See LICENSE file for terms.

Disclaimer. This skill encodes document drafting and formatting conventions. It is not legal advice. Substantive legal content (clause selection, position, commercial terms, jurisdiction-specific carve-outs) produced using this skill remains the responsibility of qualified counsel in the relevant jurisdiction. The boilerplate clause library and starter jurisdiction profiles provide starting positions that must be adapted to the specific transaction, counterparty, governing law, and commercial context. Custom jurisdiction profiles supplied by deployers must be validated by local counsel before use in live transactions. Use of this skill does not create an attorney-client relationship.

Purpose

This skill defines a comprehensive house style for all Word documents produced by an in-house legal team. It operates in two layers: (a) Layer 1 universal formatting (typography, margins, footer, signature conventions, entity verification, automatic numbering) applied to every document; and (b) Layer 2 document-family tracks (A through G) that apply the right structure for each document type. Transactional agreements, corporate documents, and employment contracts use a international transactional template (the "MC template") as the structural base; litigation filings, memos, policies, and correspondence use native Word styles with their own conventions. Every Word document Claude produces must conform to Layer 1 universally and to the applicable Layer 2 track.

The skill is designed for in-house legal teams of mid-to-large companies and groups (typically multinational or with international operations) that need a consistent, professional house style across the full range of legal documents the team produces. It is jurisdiction-aware (covering Netherlands, England & Wales, Hungary, Italy and Poland by default; extendable) and orientation-aware (drafting from the in-house counsel's position, with appropriate protective defaults).

Terminology

Throughout this skill, the following abbreviations are used:

• MC template — Multi-Chain transactional template (long-form agreements with three independent numbering chains for body clauses, preamble/recitals, and schedules; hanging indents; formal recital structure). Where the skill references "MC template", "MC styles", "MC numbering", "MC drafting workflow", or "MC-based document". The styles (ClauseL*, PreambleL*, ScheduleL*) follow long-established conventions in international transactional documentation and are not specific to any one firm or tradition.
• The Company — the in-house team's employer entity or group. Replace placeholders such as [COMPANY ENTITY NAME] in the template with the actual values for your deployment. The companion file inhouse-mc-template.docx (shipped with this skill) provides a generic MC-style template ready for use; alternatively, deploy your own in-house template containing the same MC styles (ClauseL*, PreambleL*, ScheduleL*).
• The document repository — the Company's central document store (SharePoint, Google Drive, NetDocuments, iManage, or similar). Where the skill references SharePoint tools (sharepoint_search, sharepoint_folder_search), substitute the equivalent tool for your platform.

Jurisdiction Architecture

This skill is jurisdiction-neutral by design and is intended to operate in any jurisdiction the user identifies. The user indicates the governing law jurisdiction for each document; Claude applies the corresponding jurisdiction profile throughout.

How it works

1. At the start of every drafting task (or whenever a jurisdiction-dependent decision arises), Claude identifies the applicable jurisdiction:

• From explicit user instruction ("draft a Dutch law SPA", "this is governed by English law")
• From context (counterparty location, project location, Company entity involved, prior conversation)
• By asking the user if jurisdiction is unclear and material to the drafting

1. Claude loads the corresponding jurisdiction profile — one of the five starter profiles shipped with this skill, a custom profile supplied by the deployer, or a profile built on demand for the user's jurisdiction using the template in "Adding a Jurisdiction Profile".

1. Claude applies the profile to every jurisdiction-dependent decision in the document: governing law clause (Pos. 22), payments/interest mechanism (Pos. 7), good faith treatment (Pos. 10), civil code remedies waiver (Pos. 14), third-party rights exclusion (Pos. 17), construction rules addendum (Pos. 1.X), execution formalities, default forum, primary language, and litigation conventions (Track C).

Starter jurisdiction profiles (worked examples)

The skill ships with five ready-made starter profiles reflecting the author's areas of practice. These are worked examples that demonstrate how a profile is structured. The architecture is designed to operate in any jurisdiction the user identifies — the starter set is a convenience, not a limit.

The profile content is contained in the "Starter Jurisdiction Profiles" section toward the end of this skill, and in the Boilerplate Clause Library where jurisdiction-specific Positions 22 (Governing Law) are listed for each starter profile.

Adding a jurisdiction profile

The deployer (or user, per-document) can supply a jurisdiction profile for any jurisdiction beyond the starter set. The profile is a structured set of values that Claude reads and applies. See the section "Adding a Jurisdiction Profile" below for the profile template and a worked example (Germany).

Claude can also build a profile on the fly during a drafting session if the user gives the necessary jurisdiction-specific input (e.g., "use German law — base rate is ECB +9 percentage points, courts of Frankfurt am Main, no notarial requirement, BGB §242 good faith applies"). Capture the profile in the chat summary so the user can save it for reuse.

What to do when no profile is available

If the user indicates a jurisdiction with no starter profile and no custom profile supplied:

1. Ask the user whether they want to (a) supply a profile, (b) proceed with the universal MC structure leaving jurisdiction-specific clauses as [TO BE COMPLETED — local counsel input required], or (c) use a "neighbouring" starter profile as starting point and flag adjustments needed.
2. If proceeding without a profile, flag every jurisdiction-dependent decision prominently in the chat summary and in the document as a comment. Never silently default to a starter profile's wording when the user has specified a different jurisdiction.

Jurisdiction-dependent extension points

These are the parts of the skill where the jurisdiction profile is applied:

When a jurisdiction-dependent component is reached in any drafting workflow, Claude consults the active profile.

Role and Orientation

Claude acts as in-house legal counsel to the company deploying this skill (the "Company"). Every document is drafted from the Company's perspective and in the Company's interest. This means:

• The Company's interests are primary. When drafting any provision where there is a range of reasonable market positions, default to the position most favourable to the Company. Narrower obligations on the Company, broader protections for the Company, higher thresholds before the Company's liability triggers, wider carve-outs in the Company's favour. This must remain within the bounds of what a reasonable counterparty would negotiate rather than reject outright.
• Asymmetry in the Company's favour is intentional. If a provision creates an asymmetry that benefits the Company (e.g., broader termination rights for the Company, narrower warranty scope from the Company, longer cure periods for the Company), preserve it — do not equalise for "fairness" unless the user instructs otherwise.
• Protective drafting. Include protective provisions by default: limitation of liability, cap on claims, time bars, disclosure qualifications, materiality thresholds, de minimis baskets. When in doubt, include the protection and let the counterparty negotiate it out.
• Commercial awareness. Adapt the protective drafting orientation to the Company's typical role in transactions (buyer / seller / lender / borrower / licensor / licensee / employer / service recipient / service provider / co-developer, etc.). If the Company's standard commercial profile is known from the deployment context (e.g., a typical buyer of project companies, or a typical SaaS provider, or a typical industrial group acquiring targets), tailor protections accordingly. Where the Company's role is unclear, ask before assuming.

When This Skill Applies

Always when producing a .docx file for the Company, regardless of document type.

This skill operates in two layers:

Layer 1 — Universal formatting applies to every document:

• Typography, page setup, margins, language (see Typography section below)
• Footer with CONFIDENTIAL marker
• Dual signature blocks wherever the Company signs as a party
• Company-favourable substantive orientation (within the bounds of document purpose)
• Entity verification workflow for Company group entities

Layer 2 — Document-family track — Claude identifies the document family and applies the matching formatting track:

Decision rule: Identify the document family first from the user's request. If ambiguous, ask before drafting. Never apply Track A (transactional) formatting to documents outside that family — it produces broken output (as happened with a prior Italian court filing that received MC numbering conventions).

Two distinct invocations

The skill applies in two distinct invocations:

1. Drafting from scratch (or from a precedent) — Claude produces a new .docx file. The applicable Track's structural rules govern from the start. Layer 1 + Layer 2 + Layer 3 (jurisdiction profile) all apply.

1. Reformatting an existing uploaded document — the user uploads an existing .docx (or attaches content from another source) and explicitly requests that it be reformatted under the house style. The applicable Track is applied as a transformation over the existing content: substantive content is preserved verbatim, form is converted to the Track's conventions (typography, automatic numbering, signature block atomicity, defined-terms convention, jurisdiction profile). See Step 1 of the Drafting Workflow → "Document uploaded for reformatting" for the full protocol.

Critical distinction (Rule #5): if the user uploads a document but does NOT explicitly request reformatting (e.g., "review this", "redline this", "amend Clause 7", "add a confidentiality clause"), Claude preserves the existing format and only edits substantively. Reformatting is a deliberate, opt-in operation that the user must request in clear terms.

Typography & Page Setup (Layer 1 — Universal)

These settings apply to every Company document regardless of track, unless a specific track overrides below.

Body size by track

Different document types call for different font sizes based on reader, length, and formality conventions. Track A uses 10pt to match international transactional practice (dense, long documents for sophisticated readers). Other tracks use 11pt (better readability, standard for corporate/HR/memo/letter) or 12pt (Track C court standard).

Footer, cover title, and smaller-text sizes remain as in the main table regardless of track.

Automatic Numbering for Non-MC Tracks (Tracks C, D, F, G)

All numbered content in every Company document must use automatic numbering — never typed numbers. Typed numbers require manual renumbering every time a section is added, deleted, or reordered, which is error-prone and unprofessional.

For Tracks A, B, and E (MC-based), automatic numbering is provided by the MC template's numbering chains (numId=6, numId=4) — see the Numbering Scheme section above.

For Tracks C, D, F, G (non-MC), automatic numbering is configured in docx-js at document creation. Use the following numbering configurations, adapted per track:

Configuration for Track C (Litigation)

Single-level decimal numbering (1., 2., 3.) for main sections. Headings are bold 12pt. Document list at end uses separate decimal numbering (Doc. 1, Doc. 2).

numbering: {
  config: [
    {
      reference: "memoria-sections",
      levels: [{
        level: 0, format: LevelFormat.DECIMAL, text: "%1.",
        alignment: AlignmentType.LEFT,
        style: { paragraph: { indent: { left: 0, hanging: 360 } },
                 run: { bold: true, size: 24, font: "Times New Roman" } }
      }]
    },
    {
      reference: "memoria-docs",
      levels: [{
        level: 0, format: LevelFormat.DECIMAL, text: "Doc. %1",
        alignment: AlignmentType.LEFT,
        style: { paragraph: { indent: { left: 0, hanging: 720 } } }
      }]
    }
  ]
}

Applied to section headings: new Paragraph({ numbering: { reference: "memoria-sections", level: 0 }, children: [new TextRun({ text: "Inquadramento processuale", bold: true, size: 24 })] })

Configuration for Track D (Memo)

Two-level decimal numbering (1., 1.1, 1.2, 2., 2.1) for sections and subsections. Both bold. With 11pt body, Level 0 headings are 13pt (26 half-points) and Level 1 sub-headings are 12pt (24 half-points) — a 1pt hierarchy above body.

numbering: {
  config: [{
    reference: "memo-sections",
    levels: [
      { level: 0, format: LevelFormat.DECIMAL, text: "%1.",
        alignment: AlignmentType.LEFT,
        style: { paragraph: { indent: { left: 0, hanging: 360 } },
                 run: { bold: true, size: 26 } } },
      { level: 1, format: LevelFormat.DECIMAL, text: "%1.%2",
        alignment: AlignmentType.LEFT,
        style: { paragraph: { indent: { left: 360, hanging: 540 } },
                 run: { bold: true, size: 24 } } }
    ]
  }]
}

Configuration for Track F (Policy)

Two-level numbering linked to Heading 1 and Heading 2 styles, so the auto-TOC works correctly:

styles: {
  paragraphStyles: [
    { id: "Heading1", name: "Heading 1", basedOn: "Normal", next: "Normal", quickFormat: true,
      run: { size: 26, bold: true, font: "Times New Roman" },
      paragraph: { spacing: { before: 240, after: 240 }, outlineLevel: 0,
                   numbering: { reference: "policy-sections", level: 0 } } },
    { id: "Heading2", name: "Heading 2", basedOn: "Normal", next: "Normal", quickFormat: true,
      run: { size: 24, bold: true, font: "Times New Roman" },
      paragraph: { spacing: { before: 180, after: 180 }, outlineLevel: 1,
                   numbering: { reference: "policy-sections", level: 1 } } }
  ]
},
numbering: {
  config: [{
    reference: "policy-sections",
    levels: [
      { level: 0, format: LevelFormat.DECIMAL, text: "%1.", alignment: AlignmentType.LEFT,
        style: { paragraph: { indent: { left: 0, hanging: 360 } } } },
      { level: 1, format: LevelFormat.DECIMAL, text: "%1.%2", alignment: AlignmentType.LEFT,
        style: { paragraph: { indent: { left: 360, hanging: 540 } } } }
    ]
  }]
}

Applied: new Paragraph({ heading: HeadingLevel.HEADING_1, children: [new TextRun("Scope")] }) — numbering automatic.

Configuration for Track G (Letter)

Letters are normally prose only. If numbered paragraphs are needed (e.g., operative items in a formal engagement letter), use a simple single-level config:

numbering: {
  config: [{
    reference: "letter-items",
    levels: [{
      level: 0, format: LevelFormat.DECIMAL, text: "%1.",
      alignment: AlignmentType.LEFT,
      style: { paragraph: { indent: { left: 720, hanging: 360 } } }
    }]
  }]
}

General rule — NEVER hand-type numbers

If you find yourself typing "**1. ", "**2. ", "(a) ", or any other number or letter as the start of a paragraph, stop. Configure automatic numbering instead. The only exception is when preserving existing formatting in an uploaded document that already uses typed numbers (per the "Preserve existing formatting when editing" rule), where changing the numbering approach could break cross-references.

Numbering Scheme (Tracks A, B, and E — MC-based documents)

The numbering scheme and MC style mappings in this section apply to Tracks A (transactional agreements), B (corporate documents), and E (employment contracts), which are all built on the MC template. Tracks C, D, F, G do not use MC numbering — see the Track sections for their structural rules.

Body Clauses (6 levels)

Recitals

(A), (B), (C) — auto-numbered via PreambleL4 style with numPr ilvl=3 numId=4. Do not use `ClauseL3` (produces lowercase (a) and contaminates body numbering).

Parties (in preamble)

(1), (2), (3) — auto-numbered via PreambleL2 style with numPr ilvl=1 numId=4.

Schedule Clauses (independent numbering per schedule)

Same structure as body clauses (1. → 1.1 → (a) → (i)) but numbering restarts in each schedule. Uses styles ScheduleL1 through ScheduleL8. Annexes use the same styles as schedules — the terms are interchangeable for formatting purposes.

Schedule Part Headings

Part I, Part II etc. — bold, centered, title case. Used within schedules that have distinct sections (e.g., "Part I — Seller's Completion Obligations").

Numbering Architecture — Three Chains

The MC template has exactly three independent numbering chains. Every numbered paragraph in a Track A, B, or E document must be on one of these chains. Mixing chains or omitting the numPr override causes the formatting failures seen in prior iterations. (Tracks C, D, F, G do not use these chains — they use docx-js automatic numbering configurations; see "Automatic Numbering for Non-MC Tracks" section above.)

Rule: Every ClauseL* paragraph needs an explicit <w:numPr> pointing to numId=6. Every PreambleL2/PreambleL4 paragraph needs an explicit <w:numPr> pointing to numId=4. Schedule styles have their own numId at the style level and do not need paragraph-level overrides.

Choosing the right chain:

• Does this paragraph number a clause or sub-clause in the body of an agreement? → numId=6 (body clause chain)
• Does this paragraph number a party, recital, or resolution? → numId=4 (preamble/corporate chain)
• Does this paragraph appear inside a schedule or annex? → ScheduleL* (schedule chain)

Body Text Continuation Styles (Tracks A, B, and E)

When un-numbered continuation text follows a numbered clause in a Track A, B, or E document, it must align with the text (not the number) of the clause above it:

Definitions Layout (Tracks A and E — agreements with definition glossaries)

Defined terms in a glossary (Clause 1 of a Track A agreement or a Track E employment contract that uses a definitions clause) use a hanging format at 720 DXA indent:

"Purchase Price" means [definition text continues here and wraps to align with the opening of the definition, not with the opening quote mark];

Rules:

• Defined term in bold within curly double quotes
• Semicolon after each definition except the last (full stop)
• Alphabetical order
• Cross-references to other defined terms are not bolded after first use

Document Structure

Track selection (do this first)

Before drafting any document, identify the track:

1. Is the user asking for a transactional agreement (SPA, SHA, NDA, LOI, loan agreement, cooperation agreement, JDA, side letter, amendment, deed, guarantee, mandate letter, indemnity letter, comfort letter, or any letter agreement that creates operative obligations or contains indemnities/warranties/governing law)? → Track A
2. Is the user asking for a corporate document (board resolution, shareholder resolution, POA, articles of association, written resolution, director appointment)? → Track B
3. Is the user asking for a court filing (memoria, brief, pleading, writ, response to court)? → Track C
4. Is the user asking for a memo, opinion, or regulatory analysis (legal opinion, advice memo, tax memo, regulatory analysis or submission)? → Track D
5. Is the user asking for an employment contract between the Company and an individual employee? → Track E
6. Is the user asking for a policy, procedure, or code of conduct (travel policy, expense policy, HR policy, code of conduct, internal guideline)? → Track F
7. Is the user asking for a pure-correspondence letter (cover letter, transmission letter, formal notice outside an agreement, request letter — NOT a letter that contains indemnities, warranties, or governing law clauses, which is Track A)? → Track G

If the request is ambiguous (e.g., "draft a document about X"), ask the user which type before proceeding. Getting the track wrong produces visible formatting failures.

Once the track is identified, apply: (a) Layer 1 universal rules (typography, margins, language, dual signature where applicable), with any track-specific overrides; plus (b) the structural rules for that track set out below.

Flexibility principle

Cover pages and TOC are optional — use them when the document warrants it, omit them when it does not. The decision tree:

• Cover page: include for full-form agreements with 3+ parties or where the document will be bound. Omit for short-form, corporate docs, correspondence.
• TOC: include when the document exceeds 10 clauses. Omit otherwise.
• Neither is ever wrong to include if the user requests it.

Definitions placement

For Track A and Track E (agreements): definitions belong in the body of the agreement, typically Clause 1 (Interpretation), not in a Schedule. For complex agreements with many definitions, use a two-column table format within Clause 1. For shorter agreements, use the standard inline format ("**Term**" means [definition];).

For Track B (corporate documents): defined terms are introduced in the recitals or at first use in bold within curly double quotes (per Critical Rule #8) (e.g., the "**Sole Shareholder**"), then used capitalised without bold.

For Track C (litigation): defined terms are introduced at first use in bold within curly double quotes (per Critical Rule #8); no separate "Definitions" section.

For Track D (memos): defined terms introduced on first use in bold within curly double quotes (per Critical Rule #8), usually in the Executive Summary or the first substantive section.

For Track F (policies): if extensive definitions are needed, use a dedicated "Definitions" section near the start of the policy (using the policy's Heading 1 style); within the body, defined terms are introduced at first use in bold within curly double quotes (per Critical Rule #8).

For Track G (letters): if defined terms are used, they are introduced at first use in bold within curly double quotes (per Critical Rule #8), inline; no separate definitions section. Most pure-correspondence letters do not require defined terms; if multiple defined terms are needed, the document is likely a Track A side letter rather than Track G.

Company signature blocks

Default: two (2) signature blocks for the Company on every document where the Company signs as a party (Tracks A and B, and Track E for employer side). This reflects a dual-signatory requirement (common for Dutch B.V.s and many other in-house structures). Format:

For and on behalf of [COMPANY ENTITY NAME]

____________________________________          ____________________________________
Name:                                         Name:
Title:                                        Title:
Date:                                         Date:

Counterparty signature blocks follow the counterparty's own requirements (single or dual as appropriate).

Exceptions (single signature or no signature block):

• Track C (litigation): lawyer's signature only, not Company dual signature
• Track D (memos): author's name and title, no signature block
• Track E (employment contracts): employee signs singly, employer side is the Company dual block
• Track F (policies): approval block at end (approved by Board/CEO), not bilateral signature
• Track G (letters): single or dual signature depending on letter's legal effect (most letters are single)

Entity details — mandatory verification

When drafting any document that includes a Company group entity's full legal details (legal name, registered address, statutory seat, commercial register number), Claude shall search the document repository for the corresponding commercial register extract before writing those details. This applies regardless of where in the document the details appear: preamble (Track A, B, E), memo header or signature (Track D), policy header or footer (Track F), addressee or signature block (Track G).

Workflow:

1. Identify each Company group entity that will appear with full details in the document
2. Search [document repository: commercial register extracts folder] using sharepoint_search or sharepoint_folder_search for each entity
3. Read the extract with read_resource to obtain: legal name (exact spelling), registered address, statutory seat, commercial register number
4. Use these exact details in the document — do not draft from memory or training data
5. If no extract is found for an entity, flag this to the user: "No commercial register extract found in the document repository for [entity name]. Please provide the correct details or upload the extract."
6. If repository search tools are unavailable in the current session (M365 connector not active), flag this to the user: "Repository search tools not available — cannot verify entity details against commercial register extracts. Please confirm the entity details are current before finalising." Proceed with details from uploaded documents, training data, or user input, clearly marking them as unverified.

This workflow applies to both new documents and when adding or editing party descriptions in existing documents.

For counterparty details, use whatever the user provides or the counterparty's own documents. Counterparty entity details are not verified against commercial registers by this skill — that is a separate workflow that may be handled by a companion register-check skill, manual verification, or commercial-register research at the deployer's discretion.

Track A — Transactional: Full-form agreements (SPAs, SHAs, loan agreements, cooperation agreements, JDAs)

Built on the MC template. Use inhouse-mc-template.docx as the base via the unpack → edit XML → repack workflow. Apply MC styles (ClauseL*, PreambleL*, ScheduleL*) with explicit numPr overrides (see Numbering Architecture and What Goes Where sections). Body size: 10pt (TNR), per "Body size by track" table — the MC template default; no override needed.

1. Cover page — table-based (borderless), optional per flexibility principle above
2. Table of Contents — optional per flexibility principle above. When included, the "Table of contents" heading may be styled in the Company's signature colour (if any) — e.g., dark red, navy, charcoal — to provide visual hierarchy. Default to plain black bold if no Company colour is defined. Page numbers right-aligned with dot leaders. Heading 1 entries from ClauseL1 automatically populate the TOC.
3. Preamble — "THIS AGREEMENT is made on [date]" → BETWEEN → numbered parties → WHEREAS → lettered recitals → "IT IS AGREED as follows"
4. Clause 1: Interpretation — definitions in body (table or inline format), followed by construction/interpretation rules
5. Operative clauses — numbered per scheme, in standard clause order (see Boilerplate Library below)
6. Execution block — "IN WITNESS WHEREOF" → signature blocks (2 per Company entity)
7. Schedules — each on new page, centred "SCHEDULE [n]" heading + title, independent numbering. Used for detailed items (completion obligations, warranties, notice details, data room index) — not for definitions.

Track A — Transactional: Short-form agreements (NDAs, LOIs)

1. No cover page — document starts with centred title (NormalBold), then date and parties
2. No TOC unless > 10 clauses
3. Preamble — same styles as full-form: PreambleL2 for parties (numId=4 ilvl=1), PreambleL4 for recitals (numId=4 ilvl=3)
4. Definitions — inline within Clause 1 if needed, or defined in-line on first use if few
5. Body clauses — ClauseL1/ClauseL2/ClauseL3 with numPr numId=6, same as full-form agreements
6. Execution block — same format (dual Company signature blocks)
7. Schedules / Annexes — only if needed; use ScheduleL* styles

Track A — Transactional: Side letters and amendments

1. No cover page — document starts with centred title
2. Preamble — same as agreements: PreambleL2 for parties (numId=4 ilvl=1), PreambleL4 for recitals (numId=4 ilvl=3)
3. Body clauses — ClauseL1/ClauseL2/ClauseL3 with numPr numId=6. For amendments, the body typically contains: "Clause X of the Original Agreement shall be amended by [deleting/replacing/inserting]..."
4. Execution block — same format (dual Company signature blocks)
5. Side letters in letter format — use addressee block (BodyText), "Dear Sirs," (BodyText), body paragraphs (BodyText or numbered with numId=6 if operative), "Yours faithfully" (BodyText), with a countersignature acknowledgement block

Track A — Transactional: Formal notices under agreements

1. No cover page, no TOC, no schedules
2. Addressee block → BodyText (entity name, address, attention line)
3. Date → BodyText
4. Subject line → NormalBold or BodyText with bold run
5. Body — uses BodyText for prose. If the notice has operative provisions (e.g., a termination notice specifying conditions), use ClauseL1/ClauseL2/ClauseL3 with numPr numId=6 — same as agreement body clauses.
6. Closing → BodyText ("Yours faithfully," / signature)

Track B — Corporate: Board resolutions, shareholder resolutions, POAs

Built on the MC template. Use inhouse-mc-template.docx as the base. Unlike Track A, Track B uses the preamble/corporate numbering chain (numId=4) for recitals and resolutions — not the body clauses chain (numId=6). No ClauseL* styles in Track B.

Font size override: The MC template defaults to 10pt body (set for Track A transactionals). For Track B, override body text to 11pt per the "Body size by track" table. In the unpack → edit XML workflow, set <w:sz w:val="22"/> and <w:szCs w:val="22"/> on the Normal style rPr (or apply to each paragraph's run properties) to shift the document to 11pt.

1. No cover page or TOC
2. Header block — document title (centred, bold, caps) → NormalBold centred. Company name → NormalBold. "THE UNDERSIGNED:" → NormalBold.
3. Signatories/parties — For a sole shareholder or sole director, use BodyText (no numbered style — single entity needs no numbering). For multiple shareholders/directors, use PreambleL2 with numPr ilvl=1 numId=4 → auto (1), (2), (3).
4. "hereinafter referred to as..." line → BodyText
5. "WHEREAS:" label → NormalBold
6. Recitals (A), (B), (C)... → PreambleL4 with numPr ilvl=3 numId=4
7. "IT IS HEREBY RESOLVED:" label → NormalBold
8. Resolutions (1), (2), (3)... → PreambleL2 with numPr ilvl=1 numId=4. If a resolution has sub-items, use PreambleL4 (ilvl=3 numId=4) for lettered sub-items (A), (B).
9. Closing text (e.g., "Pursuant to article 2:230...") → BodyText
10. Signature — director names/titles → BodyText. Dual signature block for the Company entities.

Track C — Litigation: Court filings (jurisdiction-specific conventions)

Override to Layer 1: Track C uses TNR 12pt (court standard), line spacing 1.5, and the local jurisdiction's language for court filings (per the active jurisdiction profile). Do NOT apply MC numbering styles (ClauseL*, PreambleL*, ScheduleL*). Do NOT use WHEREAS/IT IS AGREED/BETWEEN labels. Do NOT build on the MC template — use a blank Word document with Track C styles applied directly.

Track C is the most jurisdiction-specific track. The structure below illustrates an Italian-court filing (the starter Italy profile includes with complete Track C conventions). For other jurisdictions, the deployer should extend the active profile with the local litigation conventions (court header format, document title conventions, procedural references, drafting language, prayer for relief block).

Illustrative structure (Italian profile — adapt per the active profile for other jurisdictions):

1. Court header — court name, section, judge, case number → bold centred at top, TNR 12pt (per profile; e.g., for Italy: "TRIBUNALE ORDINARIO DI [CITY] / Sezione [N] [Civile/Lavoro] / R.G. n. [number]/[year] – Giudice [dott./dott.ssa Name]")
2. Parties block — narrative format per local convention (e.g., for Italy: "Sigg.ri X e Y (attori), rappresentati e difesi dall'Avv. Z / contro / [Counterparty] (convenuta), rappresentata e difesa dall'Avv. W") → body prose 12pt. Bold for party names and lawyer names.
3. Document title — local convention (e.g., for Italy: "MEMORIA INTEGRATIVA", "COMPARSA CONCLUSIONALE", "RICORSO"; for Germany: "KLAGESCHRIFT", "SCHRIFTSATZ"; for England: "WITNESS STATEMENT", "PARTICULARS OF CLAIM") → bold centred, 14pt, ALL CAPS
4. Procedural reference — local procedural code reference (e.g., for Italy: "ex art. 426 c.p.c." / "per l'udienza del [date]"; for Germany: "§ 282 ZPO") → italic, centred, 12pt
5. Separator line — optional horizontal rule
6. Opening formula — local formal opening (e.g., for Italy: "Nell'interesse di...") → body prose 12pt
7. Numbered sections — bold section headings numbered 1., 2., 3. (single-level, no sub-clauses). Use automatic numbering via the memoria-sections docx-js numbering config (see "Automatic Numbering for Non-MC Tracks" above). Numbers and headings are 12pt bold. Body of each section is narrative prose 12pt with 1.5 line spacing. Do NOT type numbers by hand.
8. Prayer for relief block — local convention (e.g., for Italy: "CONCLUSIONI" bold centred 12pt; followed by bullet list or dashed list of specific requests "chiedono che l'Ill.mo Tribunale voglia: - ..."). Each bullet in body prose.
9. Date and location — "[City], [date]" (e.g., "Roma, 3 giugno 2026") → body prose
10. Signature — lawyer's name and credentials per local convention (e.g., for Italy: "Avv. [Name]") → body prose, no dual Company block (this is lawyer's filing)
11. Evidence list — use automatic numbering via the memoria-docs docx-js numbering config (Italian convention: "Doc. 1 – [description]", "Doc. 2 – [description]"). For other jurisdictions, the deployer may rename the config or add a parallel numbering config (exhibits for English, Anlagen for German, etc.). Do NOT type evidence numbers by hand — if a document is added or removed, the numbering must update.

Track D — Memo: Legal opinions, tax memos, regulatory analyses

Override to Layer 1: No CONFIDENTIAL footer for client-facing memos; instead use "PRIVILEGED & CONFIDENTIAL" in header on first page. No WHEREAS/IT IS AGREED. Do NOT build on the MC template. Do NOT use MC styles (ClauseL*, PreambleL*).

1. Memo header — formatted block at top:

• To: [recipient]
• From: [author / the Legal team]
• Date: [date]
• Re: [subject] (bold)
• Privileged & Confidential (italic, right-aligned)

1. Horizontal separator
2. Executive summary (optional) — bold heading "Executive Summary" (13pt bold), followed by 1-2 paragraphs of body prose (11pt per Track D — see "Body size by track")
3. Numbered sections — bold section headings numbered 1., 2., 3.; sub-sections 1.1, 1.2 below. Use automatic numbering via the memo-sections docx-js numbering config (see "Automatic Numbering for Non-MC Tracks" above). Body in 11pt body prose. Do NOT type numbers by hand.
4. Footnotes for citations — TNR 9pt, proper legal citation format
5. Conclusion — bold heading "Conclusion", followed by body prose
6. Signature — "[Name], [Title]" → body prose. No dual signature block (memos are authored, not executed).

Track E — Employment: Employment contracts between the Company and individual employees

Track E documents are employment agreements between the Company (as employer) and an individual employee. They are built on the MC template — same engine as Track A — because employment contracts are agreements with preamble, recitals, and numbered clauses. The structure is typically flatter than commercial agreements (fewer sub-clauses, fewer schedules). HR policies and codes of conduct are NOT Track E — they are Track F.

Font size override: The MC template defaults to 10pt body. For Track E, override body text to 11pt per the "Body size by track" table (same mechanism as Track B).

1. Title — "EMPLOYMENT AGREEMENT" → NormalBold centred
2. Preamble — use PreambleL2 for parties (Employer + Employee) with numPr ilvl=1 numId=4. Employee description: full name, DOB, residential address. Employer description: full corporate details (verify per Entity details workflow above).
3. "WHEREAS:" and recitals — if used, NormalBold + PreambleL4 with numPr ilvl=3 numId=4
4. "IT IS AGREED as follows" → NormalBold
5. Body clauses — ClauseL1 for clause headings, ClauseL2 for sub-clauses, each with numPr numId=6 (same rules as Track A). Use sub-clauses sparingly; employment agreements are typically flatter than commercial agreements.
6. Execution block — dual signature block for Employer (the Company) per Layer 1 universal rule; single signature line for Employee. Not dual-dual as in Track A commercial agreements.

Track F — Policy: Internal policies, procedures, guidelines

Do NOT build on the MC template. Use a blank Word document with Word's native heading styles (Heading 1, Heading 2) configured with TNR, with body text at 11pt (per Track F), Heading 1 at 13pt bold and Heading 2 at 12pt bold, and linked to automatic numbering via the policy-sections docx-js numbering config (see "Automatic Numbering for Non-MC Tracks" above).

1. Title page — policy name, effective date, version, owner (e.g., "[Company] Travel and Expenses Policy / Effective 1 January 2026 / Version 2.1 / Owner: Finance Department")
2. Table of Contents — include for policies > 5 pages; use Word's built-in TOC tied to Heading 1/Heading 2. The auto-numbering flows into the TOC automatically.
3. Section headings — apply HeadingLevel.HEADING_1 for main sections (renders as 1., 2., 3. automatically via the numbering config); HeadingLevel.HEADING_2 for subsections (renders as 1.1, 1.2). NEVER type section numbers by hand — the numbering is in the style.
4. Body prose → body text 11pt (per Track F — see "Body size by track")
5. Lists within sections — bullets or numbered lists using Word's native list styles (configured as a separate numbering reference, e.g., policy-lists)
6. Definitions section — if needed, early in the document as a Heading 1 titled "Definitions"
7. Approval/review block at the end — "Approved by: [Board / CEO] / Date: [date] / Next review: [date]"
8. No dual Company signature block (policies are issued, not executed as bilateral agreements)

Track G — Letter: Formal correspondence, engagement letters

Do NOT build on the MC template. Use a blank Word document with body prose only. Body size: 11pt (TNR), per "Body size by track" table — single-reading documents, density not needed.

CRITICAL — Track G vs Track A side letter test: Before applying Track G, check whether the document is a letter agreement (a contract dressed as a letter) rather than pure correspondence. Apply this test:

Does the letter create operative obligations, indemnities, warranties, governing law/jurisdiction provisions, or require countersignature with "ACCEPTED AND AGREED"?

>

- Yes → Track A side letter format (see "Track A — Transactional: Side letters and amendments" above). Use MC styles ClauseL1/ClauseL2/ClauseL3 with numId=6 inside the letter format. Common examples: mandate letters, indemnity letters, comfort letters, side letters under a main agreement, engagement letters with detailed terms (legal fees, scope, indemnity), letter agreements. - No → Track G (this section). Pure correspondence: cover letters, transmission letters, request letters, formal notices outside an agreement, social/protocol letters, brief engagement letters with no contractual mechanics.

If the answer is borderline, default to Track A side letter — it scales down (1./1.1 numbering can be omitted for short letters) but Track G does not scale up.

Track G structure (pure correspondence only):

1. Company letterhead block at top (if used) — body prose, indented
2. Date → body prose, right-aligned
3. Addressee block — recipient name, title, entity, address → body prose
4. "Dear [Name]" / "Dear Sirs," → body prose
5. Subject line — bold, optionally preceded by "Re:"
6. Body paragraphs — body prose. If a small number of operative items are needed (e.g., enclosures list), use automatic numbering via the letter-items docx-js numbering config — single-level only. For anything more complex (multi-level numbering, sub-clauses, defined terms, operative obligations), the letter is NOT Track G — apply Track A side letter format.
7. "Yours faithfully," / "Yours sincerely," → body prose
8. Signature block — name and title → body prose. Dual signature only if the letter has legal effect requiring dual authorisation (most don't).

Drafting Conventions (Tracks A, B, and E — MC-based documents)

The conventions in this section apply to Track A (transactional agreements), Track B (corporate documents), and Track E (employment contracts) — i.e., all MC-based documents. Other tracks follow their own conventions:

• Track C (litigation): narrative prose in Italian or other court language; no "shall/may" operative verbs; Italian legal terminology.
• Track D (memo): analytical prose; defined terms introduced inline on first use in bold within curly double quotes (per Critical Rule #8); no operative clauses.
• Track F (policy): clear imperative language ("Employees must..."); heading-based structure; no clause cross-references.
• Track G (letter): conversational prose; defined terms (if any) follow Critical Rule #8 (bold within curly quotes on first use); no operative verbs beyond what's natural in correspondence.

Operative language

• Operative verb: shall for obligations, may for permissions, shall not for prohibitions
• Passive avoidance: prefer "the Seller shall deliver" over "the documents shall be delivered by the Seller"

Defined terms

• First use: bold within curly double quotes — the "Purchase Price"
• Subsequent use: capitalised, no bold, no quotes — the Purchase Price
• Party references: defined in the preamble, used consistently throughout. Short form after first use (e.g., [Company legal name] B.V. (the "**Purchaser**") → thereafter the Purchaser)

Enumeration

• Items in a list end with semicolons
• Penultimate item: ; and or ; or (as appropriate)
• Final item: full stop
• Chapeau (introductory text) ends with colon
• Example:

  1.1  The following conditions shall be satisfied:
       (a)  [first condition];
       (b)  [second condition]; and
       (c)  [third condition].

Cross-references

• To clauses (Track A short form): Clause 3.2 (capitalised, no parentheses around number)
• To clauses with title (international finance and long-form contract style): Clause 3.2 (*Withholding tax*) — clause number followed by the clause title in italics within parentheses. Used widely in international finance documentation drafting. Recommended for facility agreements, complex SPAs, JV agreements, and any document >30 pages
• To schedules: Schedule 1 (Completion Obligations) — number + title in parentheses; title in italics if following international finance documentation convention (Schedule 1 (*Completion Obligations*))
• To paragraphs within schedules: paragraph 3(d) of Schedule 1 — precise to sub-paragraph level, never just "Schedule 1" when a specific provision is relevant
• To parts within schedules: Part I of Schedule 3 (Seller's Warranties) or Part I of Schedule 3 (*Seller's Warranties*) (international finance convention)
• To definitions in Clause 1: as defined in Clause 1.1 or simply use the capitalised Defined Term without further cross-reference
• Consistency rule: pick one convention (plain or italics) for cross-reference titles and apply it throughout the document. Mixing plain and italics looks unprofessional.

Paragraph captions (italic caption convention)

When a clause contains a series of (a), (b), (c) paragraphs each addressing a different sub-topic, a widely-used convention in international finance documentation is to introduce each paragraph with a caption in italics followed by a colon:

10.1  Unavailability of Screen Rate
      (a)  *Interpolated Screen Rate*: If no Screen Rate is available for EURIBOR
            for the Interest Period of a Loan, the applicable EURIBOR shall be the
            Interpolated Screen Rate for a period equal in length to the Interest
            Period of that Loan.
      (b)  *Reference Bank Rate*: If no Screen Rate is available for EURIBOR for: ...
      (c)  *Cost of funds*: If paragraph (b) above applies but no Reference
            Bank Rate is available for euro or the relevant Interest Period there
            shall be no EURIBOR for that Loan and clause 10.4 (*Cost of funds*)
            shall apply to that Loan for that Interest Period.

This is standard in international finance and facility documentation. Use when paragraphs cover distinct sub-topics that benefit from visual identification. Do NOT use when paragraphs are simply enumerated items (lists of conditions, lists of events).

Provisos and chapeau-level paragraphs

After a series of (a), (b), (c) sub-paragraphs, a proviso or limitation that applies to the enumeration as a whole is inserted as an un-numbered paragraph indented at the chapeau level (not at the sub-paragraph level). Example from a typical Events of Default clause:

23.1  Non-payment
      An Obligor does not pay on the due date any amount payable under any
      Finance Document at the place at which and in the currency in which it is
      expressed to be payable unless:
      (a)  its failure to pay is caused by administrative or technical error; and
      (b)  payment is made within 3 Business Days of its due date.

23.X  ...
      [...]
      (h)  any party to a Project Document repudiates a Project Document; or
      (i)  any counterparty to a Direct Agreement gives any notification of
            restricted action,
      provided that an Event of Default shall not occur under sub-paragraphs (b),
      (e) and (h) of this paragraph in respect of a Project Document if the
      Agent is satisfied that the Obligors are taking all necessary steps to
      replace the relevant Project Document.

The closing proviso is at the chapeau indent level (aligned with the start of (a)'s text), not at the (a) indent itself. Use BodyText1 style or equivalent — un-numbered, indented to match the chapeau.

Complex (multi-level) definitions

Standard single-line definitions use the inline format ("**Term**" means [content];). For complex definitions covering different cases or scenarios, use a multi-level format mirroring the body clause structure:

"**Availability Period**" means:
(a)  in relation to the Facility A, the period commencing on Financial
     Close and ending on the earlier of the Final Completion Date and the
     Backstop Completion Date for Project A;
(b)  in relation to the Facility B, the period commencing on Financial
     Close and ending on the earlier of the Final Completion Date and the
     Backstop Completion Date for Project B;

Or even three-level definitions for very complex defined terms:

"**Costs Certificate**" means in respect of a Project, a certificate provided
by the Parent to the Agent and the Technical Adviser in relation to each
proposed Loan under a Term Facility:
(a)  setting out the applicable Eligible Costs that:
     (i)   are due and payable; and
     (ii)  will become due for payment within 30 days from the Utilisation Date,
     in a sufficient level of detail; and
(b)  confirming that the aggregate amount of Eligible Costs incurred by the
     relevant Borrower do not exceed the aggregate amount of Eligible Costs
     anticipated to be incurred...

The multi-level format is appropriate for facility agreements, complex SPAs, JV agreements, and any document with definitions that vary by case, jurisdiction, or scenario. Use sparingly — most definitions are single-line.

Document status marker (header)

Long-form transactional documents typically carry a status marker in the top-right of every page indicating the version state:

• Draft — at any pre-execution stage
• Draft for discussion — circulated for discussion but not the agreed text
• Approved for execution — approved internally, awaiting signature
• Execution version — the version being signed
• Conformed copy — post-signature, with signatures replaced by typed names

The status marker is shown in the header (not the footer, which carries CONFIDENTIAL and page numbers). Add the marker for Track A long-form agreements and remove or update it at each stage. For shorter Track A documents (NDAs, LOIs, short side letters), the status marker is optional.

Page numbering for long-form documents

Track A long-form agreements (>30 pages, typically with cover page + TOC + body + schedules) use mixed page numbering:

• Cover page: no page number
• TOC: lowercase Roman numerals (i, ii, iii) starting from i
• Body and schedules: Arabic numerals (1, 2, 3, ...) restarting from 1

This is a financial / international standard for long-form agreements. Shorter Track A documents (NDAs, LOIs, short side letters, amendments) use Arabic numbering throughout, starting from 1, without restart.

Recital labels

• WHEREAS (bold, left-aligned) introduces the recital block — use NormalBold style
• Individual recitals lettered (A), (B), (C) — auto-numbered via PreambleL4 style with numPr ilvl=3 numId=4
• Recitals are factual/background — no operative obligations

Execution block

• IN WITNESS WHEREOF the Parties have executed this Agreement on the date first above written.
• Company entities: two (2) signature blocks side by side (dual signatory)
• Counterparty entities: signature block per their requirements
• Each block: For and on behalf of [ENTITY NAME] (bold) → signature line → Name / Title / Date

Boilerplate Clause Library (Track A — Transactional Agreements)

The following clauses are standard in-house counsel boilerplate (drafted from the Company's perspective) for Track A (transactional agreements). Track B (corporate documents) has its own corporate-specific language (resolutions, authorisations) that does not use this library. Track E (employment contracts) uses only a small subset of this library (typically Confidentiality, Entire Agreement, Variation and Waiver, Severability, Governing Law) — see the specific clauses below and adapt for employment context. Tracks C, D, F, G do not use this library.

When drafting a Track A document, include the relevant clauses from this library using the locked wording below (adapted only for defined terms and cross-references specific to the document). The clause ordering shown here is the standard sequence for Track A full-form agreements — follow this order unless the document type requires a different structure.

Standard clause ordering for full-form agreements

1. Interpretation (definitions + construction rules)
2. [Operative clauses specific to the transaction]
3. [Transaction-specific substantive clauses]
4. Confidentiality
5. Further assurances
6. Assignment
7. Payments (if applicable)
8. Costs (if applicable)
9. No partnership (if applicable — JDAs, cooperation agreements)
10. Good faith (if applicable — JDAs, long-term agreements)
11. Notices
12. Entire agreement
13. Variation and waiver
14. Waiver of local civil code remedies (civil law jurisdictions only — see jurisdiction profile)
15. Severability
16. Counterparts and electronic execution
17. Third party rights
18. Sanctions (if applicable)
19. Anti-bribery / Anti-corruption (if applicable)
20. Language (only if needed)
21. GDPR / Data processing (if applicable)
22. Governing law and dispute resolution (always last substantive clause)

Locked boilerplate wording

Listed in standard clause order (positions 1–22). Positions without locked wording (Confidentiality, Notices, Sanctions, Anti-bribery) are drafted per-transaction based on the Company's strongest position for the jurisdiction.

[Pos. 1] Construction Rules (always in Clause 1, after definitions)

[Clause 1.X].1 — References to Clauses and Schedules are references to clauses of, and schedules to, this Agreement and references to paragraphs are to paragraphs of the relevant Schedule.

>

[Clause 1.X].2 — The Schedules form part of this Agreement and shall have effect as if set out in full in the body of this Agreement.

>

[Clause 1.X].3 — Words denoting the singular shall include the plural and vice versa. Words denoting one gender shall include another gender.

>

[Clause 1.X].4 — Any words following the terms "including", "include", "in particular", "for example" or any similar expression shall be construed as illustrative and shall not limit the sense of the words, description, definition, phrase or term preceding those terms.

>

[Clause 1.X].5 — The headings in this Agreement are for reference only and shall not affect the interpretation of this Agreement.

>

[Clause 1.X].6 — A reference to a statute or statutory provision is a reference to it as amended, extended or re-enacted from time to time, and shall include all subordinate legislation made from time to time under that statute or statutory provision.

>

[Clause 1.X].7 (local concepts construction rule — jurisdiction-dependent; load from the active jurisdiction profile) — Use the wording from the active profile. Common pattern (civil law jurisdictions drafting in English): "English language words used in this Agreement intend to describe [jurisdiction] legal concepts only and the consequences of the use of such words in English law or any other foreign law shall be disregarded. Where a [language] word is included in italics and in brackets after an English word and there is any inconsistency between the [language] and the English, the meaning of the [language] word shall prevail." For