name: redline-conventions
description: House conventions for editing matter documents — choosing exact-text anchors, picking redline vs tracked-changes, attributing changes to the firm, and applying playbook approved language byte-exact. Use whenever editing, redlining, amending, or applying tracked changes to a matter document.
Every edit to a matter document is a proposal: the tools record a pending
redline the lawyer accepts or rejects in the doc.haus app, and the canonical
.docx is not modified until they accept. Your job is to locate the right text,
propose the right replacement, and explain it.
Both editing tools locate text by exact-text match, never by position or
offset. The anchor IS the address.
- Copy anchors verbatim from a verified source — a search-document citation
excerpt, or text returned by read-document. Never type an anchor from memory
or normalize its punctuation, capitalization, or spacing: a paraphrased
anchor will not be found.
- Make the anchor unique before calling. Short phrases ("the Receiving
Party", "30 days") recur throughout a contract; the tool anchors to the
FIRST occurrence, which may be the wrong clause. Extend the anchor with
surrounding words from the same sentence until it can only match the
intended passage.
- If the result reports more than one occurrence, treat the anchor as
ambiguous: the proposal may have landed on the wrong instance. Re-anchor with
a longer, unique string and let the new proposal supersede the old one
(the tools retire conflicting pending proposals automatically).
- If the text is not found, the tool says so and nothing is recorded.
Re-read the passage (read-document / search-document) and anchor to text the
document actually contains — never guess at a nearby clause or retry with an
invented variant.
- `tracked-changes` — a surgical word or phrase swap: `find` exact text,
`replace` it. Use for the smallest change that satisfies the instruction.
- `redline` — rewrite a whole clause: `clause` locates the paragraph (pass the
citation excerpt or a sentence within it) and `replacement` replaces the
paragraph's entire text. Use when the instruction reworks a clause rather
than swapping a term — including when applying a playbook's approved
replacement text.
- `word-integration` (action `replace`) — a silent, untracked edit. Use ONLY
when the lawyer explicitly asks for a clean change with no tracked revision.
Never choose it on your own judgment.
- Every change is tracked and every change is explained. After each proposal,
state the document, the clause affected, the old wording, the new wording,
and why — and that it is pending the lawyer's accept/reject review.
- Make exactly the change instructed. Do not also "improve" neighbouring
wording, fix typos you were not asked about, or fold several instructions
into one anchor.
- One instruction, one proposal. If a change spans several clauses, make one
tool call per clause so each can be accepted or rejected independently.
Pass `author` on every redline and tracked-changes call, set to the firm or
the supervising lawyer's name as the matter uses it. Never leave it to default
and never use a tool or product name: the author field travels in the .docx to
opposing counsel, and a tool name in the revision history discloses how the
document was prepared. If you do not know the right name, ask before editing.
When a playbook provides text in an ```approved``` or ```approved-fallback```
fence, copy it into `replacement` byte-exact — no rewording, no "fitting it to
the contract's style", no dropped or added sentences. The fence is
firm-approved language; any deviation is unapproved language presented as
approved. Use a fallback fence only when its stated "when" condition is met,
and say which condition triggered it. If the fence contains a bracketed
`[insert ...]` placeholder you cannot resolve from the matter, stop and ask —
never send a placeholder into a client document.