A Content-Diff Approval View for Updating One Product Specification

When one product specification is updated, a reviewer often sees a wall of changes. Some are real: a different rated value or a corrected material. Others are noise: trailing spaces, different quote marks, reordered rows, a changed line break. This article proposes, conditionally, an approval view that would show real changes first and prove that everything else stayed the same.

The reader's task

The reviewer must decide whether the new specification says what the editor intended and nothing more. Raw text comparison makes that hard, because noise hides signal.

Normalisation before comparison

If built, the view could compare normalised copies of old and new values, while still storing the originals. Candidate normalisation rules, each to be agreed by the team:

• Trim leading and trailing whitespace.
• Collapse repeated spaces.
• Treat different quote or apostrophe characters as equal.
• Ignore line break style.
• Ignore the order of rows only if row labels are unique.

Normalisation should never touch numbers or units. A change from "12 mm" to "12mm" could be formatting, but "12 mm" to "1.2 mm" must always appear as real. The team may choose to flag spacing around units as a separate, lower category rather than hiding it.

Primary artifact: reviewer change sheet

The sheet would have one line per field in the specification.

Classifications could be: identical, formatting only, text change, value change, added, removed. The view would sort added, removed, value and text changes to the top and collapse the rest.

Unchanged-value verification

Collapsing is only safe if the reviewer can verify it. The proposal is a count and an expand control: "31 fields identical, 2 formatting only". Expanding shows old and new side by side. A reviewer could also tick "I checked the collapsed fields" before approving, if the team wants that friction.

Branching choices

If the specification is free text, not fields, the view could compare by sentence and flag only sentences that differ after normalisation. If fields are renamed, show a removed and an added line, and let the editor mark them as a rename. If the update arrives as a pasted table, run the comparison on parsed cells, and stop with a warning if parsing is uncertain.

Hypothetical worked example

Imagine a specification with six fields. The editor pastes a new version from a document. The sheet shows: Material changed from Steel to Stainless steel; Weight changed from 0.8 kg to 0.9 kg; Length formatting only; three fields identical. The reviewer sees two real changes at the top, expands the collapsed four, confirms Length reads the same, and approves. Had the weight silently become 9 kg through a pasting error, it would still have appeared as a value change.

Stop conditions

Do not approve if a field cannot be classified, if the counts do not add up to the total field number, if a number or unit differs but was classified as formatting, or if the pasted source could not be parsed cleanly.

Acceptance checks

• Feed a version differing only by whitespace and quote style: the sheet reports no real changes.
• Feed one changed digit: it appears at the top.
• Add one field and remove one: both appear.
• Identical plus formatting plus changed counts equal the total.
• Original unnormalised values remain stored and viewable.

Sources