Redlineo

Features

Every output verifies itself.

Redlineo is a comparison engine and three renderers wrapped around one idea: you should never have to trust a redline, because you can always check it. Here is what it produces, what the report tells a reviewer, and how each output proves it is authentic.

The three outputs

Two versions in — the marked-up copy the reader needs out.

You give it the older ("original") and newer ("revised") version of the same document. Both files must be the same kind — Word with Word (.docx, .docm), Excel with Excel (.xlsx). Sensible defaults are pre-selected; the output panel only ever shows controls the active engine honours.

  • .docx · tracked

    Word tracked changes

    Real Word revisions the recipient reviews with Word's own accept/reject tools. This is the filing artifact: accepting all changes reproduces the revised document, rejecting all restores the original — and the tool verifies that on every run. How marks display (colors, balloons) follows each viewer's own Word settings.

    Endorsement · form BP 04 30 The policy period begins at 12:01 a.m. 12:01 A.M. Standard Time at the address shown in the Declarations.
  • .docx · baked

    Baked colors

    The same changes flattened into fixed colors — insertions underlined, deletions struck through. Looks identical in every viewer, ideal for PDF conversion or e-mail; can no longer be accepted or rejected. Two color pickers appear (insertion / deletion), and the report page shows a color key with those exact colors.

    • insertion
    • deletion
  • .xlsx · colored copy

    Colored Excel review copy

    The actual revised workbook with colored fills — green inserted, amber changed (previous value on a was: … cell comment), red struck-through deleted rows spliced back at their aligned position. Three fill pickers, text auto-contrasted. Formulas stay live. A review view for reviewers who live in Excel; the Word redline remains what you file.

    • inserted
    • changed
    • deleted

An Excel pair can produce either a Word redline — the worksheets' print areas laid out as Word tables mirroring the printed rate pages — or the colored review copy. Understanding the outputs →

The report a reviewer can act on

It opens with the number every regulator asks first.

With Report on (the default), the redline's first page — or the prepended Legend sheet on an Excel copy — is the comparison report:

  • Every change, numbered — none truncated. Grouped by sheet or under the nearest heading; the numbers are citable ("see item 37" in an objection response).
  • Click-to-jump. Each change line is a link — Ctrl+Click jumps to the change itself. This matters most for the baked output, which has no tracked changes for Word's Review navigation to walk.
  • Summary statistics & rate impact. Added / removed / changed / moved / formatting — and, for rate workbooks, the aggregate delta.
  • Moved text recognized. Identical content deleted in one place and inserted in another reads as "moved (content identical)", not a false delete + insert.
  • Color key on baked output — the effective insertion/deletion colors as real colored samples.
Comparison report — rate impact

✔ VERIFIED

6 cells changed — average +13.8 %, range +0.1 % to +25 %.

— print pages 4–21 of 23 unchanged — not shown —

37. Sheet 'BOP' · G12   1.0001.138  (+13.8 %)

The same information is embedded machine-readably as pleodox/change-set.json. A .docx/.xlsx is a zip, so unzip -p redline.docx pleodox/change-set.json reads it directly.

Changed content only

Honest excerpts everywhere — one checkbox.

"Changed content only" (off by default) trims any output to just what changed, with every omission explicitly marked. The unit follows the output. In every case the report still lists all changes with working links, and the full redline remains the filing artifact — regulators expect complete documents; the excerpt is for reading, sharing, and drafting objection responses.

— print pages 4–21 of 23 unchanged — not shown —
What "changed content only" produces per output — every gap is declared on the page and on the report.
OutputWhat you get
Excel pair → Word redline Only the print pages containing changes; each gap says "— print pages i–j of N unchanged — not shown —". A wholly unchanged sheet contributes no page at all. Sheets too large for a full Word render (over 2,000 print-area rows) use this automatically, with a warning.
Word pair → Word redline Only the changed paragraphs/tables, plus one context block each side; gaps say "— N unchanged paragraphs omitted —". A wholly unchanged section disappears entirely, noted at the next kept section.
Excel colored copy Unchanged sheets are hidden — never deleted, so formulas keep their references; right-click a tab to unhide. The Legend states the count.

Verification & the certificate

The differentiator: redlines that defend themselves.

After producing an output, the tool independently simulates accept-all and reject-all and compares the resulting text against the actual input documents (the Excel copy replays the change stream against both grids). Pass → the ✔ badge, the stamp, and X-Compare-Verified: true. Fail → the output is still delivered, loudly, with a warning naming where the texts diverge.

  • Certificate of comparison. SHA-256 fingerprints of the exact input files — recompute them with sha256sum and confirm which inputs produced this output.
  • Integrity manifest. Every part of the file is hashed into pleodox/integrity.json at generation. The Verify page re-hashes the uploaded bytes and reports ok / failed / missing.
  • Origin mark. With a signing secret configured, the manifest carries an HMAC only servers holding that secret can produce — proving the file came from your server.
  • One-drop re-verification. Everything is recomputed from the uploaded bytes — no database, no lookup. The file proves itself, years later, in an audit or a dispute.

The verification claim covers text content; formatting-only differences are outside it. Re-saving a produced file in Word/Excel rewrites the zip and will typically break integrity — consume produced artifacts as produced.

Filing metadata, assertions & profiles

Your conventions, checked on every comparison.

Company, state, form number and edition date are extracted by your own declared conventions — nothing hardcoded; the AAIS conventions ship as editable YAML. Assertions run on every comparison and land on the report as ✔/✖, never silent warnings buried out of sight.

  • Assertions per run. "Edition date must bump", "form number must not drift", "header and footer must agree", "state must be NY" — declared checks, verified every time.
  • Per-state profiles. A named bundle of extra extraction rules and assertions (e.g. State of New York asserts stateCode = NY). You choose it from the dropdown; the tool never guesses.
  • Fail-fast configuration. A misconfigured rule fails at app startup, not during a filing.
  • Travels tamper-evident. The extracted record — found / not found, sources, drift between versions, each assertion's verdict — is recorded inside the output as pleodox/metadata.json, under the integrity manifest.
On the report The Filing metadata block shows the extracted properties (found / not found, with sources), the selected profile, the drift between versions, and each assertion's ✔/✖.

Metadata scrubbing

Nothing leaks out the side of the file.

A metadata scrub policy runs on every output: no leaked author names, no company fields, no editing time, no revision fingerprints. The redline you hand to a regulator carries the change record you intend — and nothing you don't.

Large rate tables

Tens of thousands of rows, compared in seconds.

Print areas of tens of thousands of rows compare in seconds. Beyond the readable-Word-table size — over 2,000 print-area rows — the redline automatically shows changed pages only, every omission explicitly marked, with a warning so you know it happened. A 23,000-row rate table works; pages without changes are omitted and say so.

The tool never hides a limitation. Anything it couldn't render faithfully — a picture dropped from a print area, content outside the compared scope that differs, a formatting-only change — appears as a fidelity warning on screen and on the report page. A warning never blocks the output; it tells you where to look manually.

Honest scope Spreadsheet comparison covers displayed values within the print area. A formula whose printed value didn't change is surfaced as a warning, not a silent mark. Upload and concurrency limits are configurable deployment policy (standard Spring Boot multipart settings), not code constants — so we describe them as such rather than claiming "unlimited".
  • edition date comparison
  • tracked changes rate pages
  • compare Excel rate tables
  • actuarial rate impact
  • verifiable document comparison
  • tamper-evident redline

Classify — one document, checked and sealed

The ingest-side sibling of a comparison.

Classify works on one document — no pair, no redline. Use it when a document enters your repository: it is checked against your filing conventions and sealed with the same proof stack every comparison output carries. One drop does four things, in order:

  • Extract + check. Your configured metadata extraction and assertions run in single-document mode — checks that need two documents are skipped, and the classification says so explicitly.
  • Sanitize. The deployment's metadata-scrub policy applies, exactly as on every produced output.
  • Seal. The classification record and the integrity manifest are embedded — the sealed copy passes the Verify page like any other produced file.
  • Prove content untouched. The text content is fingerprinted before and after and must be identical — a runtime proof, shown as the ✔ badge, that classification changed properties, never content.

Failed checks are findings, never blockers: the tool computes and proves; the receiving system — a DMS rule, a workflow — decides. Nothing is stored; the sealed copy just downloads. Same caller-selected profiles as Compare, and a single call in the REST API for automated intake. The intake-gate story, hands on →

Classification — result panel

✔ CONTENT UNTOUCHED

formNumber  found · BP 04 30

stateCode   expected "NY", found "AK" — finding

2 two-document assertions skipped

Typical uses An intake gate — check an incoming filing against naming and metadata conventions before it lands in the repository, and store the sealed, re-verifiable copy. Or retroactive sealing — give existing repository documents the same integrity + metadata record your comparison outputs already carry.

Next

Read the guide, or ask for a walkthrough.

The documentation covers every control on the Compare page, the Alfresco round-trip, the Classify page, the Verify and Bake pages, and the full REST API. Or see the three-minute demo live.