← Back to blueprint

AI call 4 · Place redlines in the document

runs once, immediately after the proposal

A precision pass that maps each proposed change onto the exact numbered paragraph of the original uploaded document, so the on-screen redline and the downloadable Word markup show identical changes in identical places.

When it runs Right after AI call 3 succeeds, in the same request. Its output (paragraph_redlines) is stored on the proposal and reused for both the web view and the .docx build.
Model settings Single user message, temperature 0.0, max tokens 4000. Response parsed as a JSON object.
Template variables
  • paragraphs_blob — every paragraph of the uploaded .docx (including paragraphs inside table cells), numbered like [ 12] Board composition remains…; if no .docx was uploaded, the extracted draft text split on newlines
  • changes_blob — the proposal's proposed_changes as pretty-printed JSON (title, section, current_text, proposed_text, why_this_is_improvement)
Output contract {"operations": [{"idx": 12, "redlined_text": "…"}]} — one operation per paragraph that actually changes; untouched paragraphs are omitted.

The prompt (verbatim template)

You are applying redlines to a term sheet. The document is given as a numbered list of paragraphs (paragraphs inside table cells are included). You will produce, for each proposed change, the redlined version of the affected paragraph(s).

ORIGINAL DOCUMENT (numbered paragraphs):
{paragraphs_blob}

PROPOSED CHANGES:
{changes_blob}

For each proposed change:
1. Find the paragraph(s) in the original document that most directly correspond to the change. The "current_text" field in the proposed change is a paraphrase — you must match it to the closest paragraph by SEMANTIC similarity, not by exact substring.
2. Produce the redlined version of that paragraph using these inline markers:
   - [[-text to delete-]] for text being removed (will be rendered as red strikethrough)
   - [[+text to add+]] for text being added (will be rendered as bold green)
3. If a change ADDS A WHOLLY NEW PROVISION (an entirely new clause / new titled section, not just modifying existing wording), the addition must read as its OWN paragraph. Format it like:
       <verbatim original paragraph text>\n\n[[+New Provision Title: new content here.+]]
   The renderer splits on \n\n so the addition shows up as a separate paragraph below the verbatim original. Use \n\n EVERY time the addition is logically a new paragraph; do NOT cram a new provision inline at the end of the previous sentence.
4. If the change is a modification to existing text in place (rewording, replacing a phrase), keep the markers inline within the same paragraph and do not introduce \n\n.
5. The non-changed portions of the original paragraph should remain VERBATIM (no paraphrasing of unchanged text).

Hard rules:
- ONLY emit operations for paragraphs that actually change. Skip everything else.
- If you can't confidently locate a paragraph for a change, skip that change.
- Never invent paragraph indices that aren't in the list above.
- Keep "redlined_text" focused: original paragraph (verbatim) with deletions / additions marked inline, plus optional \n\n+[[+new paragraph+]] tails for whole-new-provision additions.

Return ONLY a JSON object with the schema:
{
  "operations": [
    {"idx": <paragraph index from list>, "redlined_text": "<paragraph with [[-...-]] and [[+...+]] markers>"},
    ...
  ]
}

Server-side handling of the response