Combine is correct-or-refuse
When you combine two sets of changes, the engine re-reads its own output and checks it against exactly what you approved. If anything does not match, you get a refusal and an explanation instead of a workbook.
The claim, stated plainly
We do not claim every combine succeeds. We claim that a combine which does hand you a file has been checked against the decisions you made, and that a combine which cannot be checked hands you nothing at all.
That distinction is the whole design. A tool that occasionally refuses costs you a manual merge. A tool that occasionally writes a wrong number into a model someone relies on costs considerably more, and, this being the part that matters, you would not know.
What is checked
After the merged bytes are written, the engine re-parses its own output and re-compares it against the version it patched. Six properties have to hold.
- 1
The result re-opens cleanly
The merged workbook is re-parsed and validated before it is handed back. See the limits below; this is checked with our own reader, not with Excel.
- 2
Nothing changed except what you approved
The merged workbook is compared against the version it was patched into. The sheet set matches, and every channel we do not touch (merged ranges, comments, hyperlinks, data validation, conditional formats, hidden rows and columns, sheet visibility, protection, auto-filters, tables, array formulas, unlocked cells) is preserved. An unapproved change anywhere is a refusal.
- 3
Everything you approved is present, and nothing you rejected is
Every approved change is checked cell by cell against the value it was supposed to carry. A change you declined appearing in the output is a refusal.
- 4
A real conflict is never quietly resolved
Where both sides changed the same thing, the planner surfaces it as a conflict for a person to decide. An unresolved conflict leaves the target value untouched, which the check above enforces.
- 5
Formulas point where they were meant to
Each written formula is compared to its intended text exactly, after reference rewriting. Any error the writer introduces (a #REF!, a #NAME?) that the intended formula did not carry is a wrong value, and a refusal. A #REF! that legitimately follows from a deleted reference is what Excel would produce, so it is reported to you as an advisory rather than hidden.
- 6
"Clean" means what it says
A combine is reported clean only when there are no unresolved conflicts.
What is not checked
The limits are as much a part of the claim as the checks. If your model-risk function is assessing this, these are the paragraphs to read.
We verify with our own reader, not with Excel
Invariant 1 above is a stand-in. "Opens in Excel with no repair prompt" is the property that matters, and the checkable statement is that we check the achievable proxy: the merged bytes re-parse and validate with our own OOXML reader. A differential check against real Excel on Windows is designed but not built.
The independent oracle is LibreOffice, which is not Excel
Our corpus runs through headless LibreOffice 24.2 as a second opinion. It catches a large class of malformed output, and it is not the application your team opens the file in.
The corpus is constructed, not collected
The 314 scenarios are paired-edit cases we wrote to be representative and adversarial. They are not a sample of real customer workbooks, because we do not have one. A number measured on constructed inputs is evidence, not proof.
Some of this is a policy choice, not a fact
What a formula should mean after rows are inserted beneath it is a judgement, not an objective truth. We make a defensible choice and apply it consistently; we do not claim it is the only correct one.
A writer bug is always possible
Combine manipulates OOXML by hand, so that half of the work can only earn statistical confidence. Self-verification does not make the writer correct. It makes a writer bug loud instead of silent.
The measurement
Measured 2026-07-23, on a 314-scenario paired-edit corpus, with headless LibreOffice 24.2 as an independent check on every emitted file.
| Completed cleanly | 278 / 314 (88.5%) |
| Surfaced a conflict for a person to resolve | 28 |
| Completed with a formula-rewrite advisory | 8 |
| Refused (fail-closed) | 0 |
| Emitted a file that was wrong and not caught | 0 |
| Failed to load in the oracle | 0 |
This is an instrument, not a promise. It moves as the engine changes, and it describes a corpus we built rather than workbooks you own.
Frequently asked questions
What happens when verification fails?
How often does a combine succeed?
Has a combine ever produced a silently wrong file?
Why not simply say it is 99.999% correct?
Can we run this ourselves?
Want to put this in front of your model-risk team?
Happy to walk through the verification design, the corpus, and where the limits are.
