Skip to content

Summary-Diff Review

Review — instantiates Summary-Substance Alignment Audit

Reviews the change between two versions of a summary, so an edit that quietly flips a modal verb or drops a not is caught at the diff rather than after it ships.

A Summary-Diff Review is triggered by change. When a summary is edited — across drafts, redlines, translations, or a regeneration after the body moved — it reads the diff between versions and asks whether any change crossed the materiality line: a "may" that became a "will," a dropped "not," a softened caveat, a number that shifted. Its defining move is that it audits the delta, not the document: it catches drift introduced by editing that a fresh read of the final version would never notice, because the final version reads perfectly coherent — it is only wrong relative to the version everyone already approved.

Example

A corporate legal team negotiates a services agreement. The 40-page body is redlined heavily and everyone scrutinizes those changes; the one-paragraph cover summary on the signature page is treated as boilerplate and barely re-read. A Summary-Diff Review runs on that summary across the last three versions and surfaces a single change: the line "Provider may suspend service for non-payment after notice" became "Provider may suspend service" — the "after notice" clause, still present in the body, silently vanished from the summary between v6 and v7. Because a scope change in a signature-page summary sits above the materiality threshold, it is routed to the clause owner and, unresolved, the escalation owner for explicit re-sign-off before signing. The change was caught at the diff; it was invisible in a clean read of v7 alone.

How it works

The review is version-aware and change-first: (1) diff the summary's claims across versions, ignoring formatting-only edits; (2) apply a materiality threshold to each real change — modal verbs, negations, scope words, and numbers weigh heavy; (3) route each material change to the party who owns that claim, and to an escalation owner if it is not resolved. It consumes an existing claim decomposition rather than building one, and it deliberately sees only what changed — establishing whether the baseline was ever right is a different mechanism's job.

Tuning parameters

  • Diff unit — word, clause, or whole claim. A word-level diff catches a flipped modal; a claim-level diff cuts noise but can miss a one-word inversion.
  • Materiality threshold — how large a change must be to flag. Set low, every copy-edit routes for sign-off; set high, a quiet scope change slips.
  • Trigger scope — every edit, or only edits made after a sign-off milestone (the point past which silent change is most dangerous).
  • Routing depth — straight to the claim owner, or through a tier that clears trivial diffs before they reach an owner.
  • Noise control — how aggressively formatting, reordering, and synonym swaps are suppressed so real semantic changes stand out.

When it helps, and when it misleads

Its strength is catching the distortion that enters after authoring — when attention has moved on and the summary is assumed settled — where a small edit can flip meaning and no one is reading the summary closely anymore. Its blind spot is structural: a diff review sees changes, not the baseline, so if the first version was already wrong there is no diff to catch it — that is the alignment reviews' job, not this one's. The classic misuse is clearing a batch of diffs wholesale to empty a queue, which defeats the entire point. The discipline is that each material change gets a named owner and an explicit re-sign-off, never a bulk approve — the review exists precisely because a one-word change like "shall" versus "may" can change an obligation while looking like a typo fix.[1]

How it implements the components

Summary-Diff Review fills the change-detection-and-routing side of the archetype:

  • material_divergence_threshold — the bar that separates a cosmetic edit from a material one; what makes a diff worth flagging at all.
  • claim_owner_and_escalation_owner — the routing: each flagged change goes to whoever owns the claim, and onward to an escalation owner if it is not resolved.

It audits changes between versions; it does not establish the baseline claim-to-evidence mapping — that is Summary-Claim Traceability Matrix, which it consumes — nor propagate an approved correction out to cached previews (Social-Preview Cache Invalidation).

References

[1] The distinction between shall, will, and may is the canonical example, in legal and technical drafting, of a one-word change that alters an obligation — mandatory versus permitted. It is exactly the kind of edit a summary-diff review exists to flag. ↩