Insurance rate / rule / form filings
The SERFF redline exhibit, proven on every filing.
US insurance is regulated state by state. Insurers and advisory organizations file rates, rules and forms with each state's insurance department through SERFF — NAIC's System for Electronic Rate and Form Filing — and state checklists routinely require a marked-up copy showing changes from the previously approved version. That strikeout/underline exhibit is exactly what this tool produces, and every copy carries its own proof.
sha256sum. Produced on your server · nothing stored.Why it fits the filing, not just the document
The full redline is the artifact; the proof travels inside it.
State checklists expect complete documents, so the design follows: the full redline is the filing artifact, excerpts are review aids, and every output carries a runtime verification, a SHA-256 certificate of its exact inputs, and a tamper-evident record embedded in the file. It is deterministic — the same two versions always produce the same redline — which is precisely the property a regulator needs to trust the exhibit.
Scenario 01 · rate revision
Rate revision filing — Excel in, Word exhibit out.
An actuary revises the rate workbook. Drop the approved and revised versions: the worksheet print areas become a paged Word redline mirroring the printed rate pages — tracked changes a reviewer can accept or reject, cell addresses that match the page, and a report that opens with the number every regulator asks first.
A 23,000-row rate table works too: pages without changes are automatically omitted — and say so. Beyond the readable-Word-table size, the redline shows changed pages only, every omission explicitly marked.
Leans on: the spreadsheet engine, rate impact, changed-pages fallback, round-trip verification. Prefer a workbook reviewers can act on directly? Produce the colored Excel review copy instead.
✔ VERIFIED
6 cells changed — average +13.8 %, range +0.1 % to +25 %.
37. Sheet 'BOP' · G12 1.000 → 1.138 (+13.8 %)
Scenario 02 · form / endorsement revision
Form and endorsement redlines that catch the header.
A revised endorsement gets a tracked-changes redline including the running headers and footers where the form number and edition date live — the detail generic tools miss and states notice. Assertions check your conventions on every run:
- ✔Edition date must bump when the content changed.
- ✔Form number must not drift between versions.
- ✔Header and footer must agree.
Failures are warnings on the report page — loud, never silent — so they surface before the filing goes out, not after an objection comes back.
Leans on: the Word engine, header/footer redlining, metadata assertions, per-state profiles.
Scenario 03 · objection letter
Answering an objection — cite the item, jump to the change.
A state analyst asks about specific changes. The report numbers every change, none truncated, so a response can cite "items 12–15" — and each line is a click-to-jump link straight to the change itself.
For the response package, "changed content only" produces a short document of just the changed paragraphs or pages — explicitly marked as an excerpt, with the full redline still on file as the filing artifact.
Leans on: the complete numbered report, report links, excerpts.
Scenario 04 · pre-filing QA gate
A QA gate that fails at startup, not during a filing.
Before anything is filed, a compare against the last approved version runs the declared checks: the per-state profile ("State of New York" asserts stateCode = NY), the edition-date and form-number rules, and the metadata extraction that classifies the filing — line of business, state, document type — recorded tamper-evident inside the output.
A misconfigured rule fails when the app starts, not in the middle of a filing window. You choose the profile; the tool never guesses.
Leans on: metadata extraction, assertions, profiles, fail-fast config.
And through the rest of the filing lifecycle
Draft, review, audit, and no-human-in-the-loop.
-
Scenario 05 · draft vs approved
Draft on the desktop, approved in the DMS
From the version-pick page, one side is the stored version, the other a local draft — no premature check-in. One click saves the verified redline back into Alfresco, filed next to the source and stamped with the extracted metadata.
Alfresco integration → -
Scenario 06 · Excel reviewers
Review by people who live in Excel
The colored review copy is the real revised workbook with green/amber/red fills, previous values in cell comments, and deleted rows spliced back struck-through. A review view — the Word redline remains the deliverable.
The Excel copy → -
Scenario 07 · the audit, years later
Prove a stored redline is authentic
A dispute or market-conduct exam asks whether a stored redline is genuine. Drop it on the Verify page: the integrity manifest proves it is unaltered since generation, and the certificate ties it to exactly the input files. No database, no log trawling — the file proves itself.
The Verify page → -
Scenario 08 · no human in the loop
A DMS workflow does the whole thing
The REST API compares two versions, reads the verification header, and archives the artifact — which carries the machine-readable
REST API →change-set.jsonandmetadata.jsoninside it, so downstream systems classify and route filings without parsing prose.
See it on your own filings
Bring two versions of a real filing.
Rate workbook or endorsement, Word or Excel — the demo lands in three minutes: compare, read the report, verify the result, save it back. It runs on your infrastructure; no document leaves the building.