Fidelity methodology

Every fidelity number Rendlio publishes links here, because a number without its method is an adjective with a decimal point. This page is that method: what the reference is, how a page is scored against it, what the corpus is, what a published result file has to carry, and which claims are structurally not allowed.

The short version: Microsoft Excel’s own print output is the oracle, scoring is per rendering area under a rubric fixed before the run, results are reproducible on your machine, and until the harness publishes a number, the number does not exist.

Pre-launch

The corpus harness is being built now. Per-area acceptance scores publish on the fidelity page as they land, area by area, and the full public corpus ships at GA as an Apache-2.0 repository — so every number can be reproduced by anyone. Nothing is ever typed in by hand: the tables are generated from the harness’s committed result files, and the site build fails if a score appears without a data file behind it.

The oracle

The reference for every fixture is what Excel itself prints for that workbook — not a rival library, not our own judgement, not a screenshot of the on-screen grid. Print output is the right oracle for three reasons:

• It is the artifact Rendlio actually produces. Comparing a PDF page to a printed page compares like with like: pagination, print areas, repeated titles, headers and footers, scaling.
• It is deterministic enough to diff. Excel resolves the same workbook to the same print geometry, so the reference page is a stable target rather than a moving one.
• It is not ours. When Rendlio and Excel disagree, Excel is right by definition and the difference is Rendlio’s defect. That is what makes a score falsifiable.

Oracle pages are rasterised for comparison, so an Excel print and a Rendlio render meet as pixels under the same conditions.

The rubric

Fidelity only means something if the reference and the rules are fixed before the run. Each rendered page is compared to its oracle page under a written rubric — geometry, text, and colour tolerances a reviewer can read, check, and sign — rather than an eyeballed impression. Two consequences worth stating plainly:

• A tolerance is part of the claim. “Matches within the rubric” is a bounded statement, and the bound is published with the score rather than implied by it.
• The rubric does not move to fit a result. Loosening a tolerance after seeing a failure would turn every earlier score into a different measurement. A rubric change invalidates prior scores and is re-run, not retro-fitted.

The corpus

Real-world workbooks, not toy sheets: invoices, financial closes, dashboards, exports from real systems. Every feature in the engine’s feature registry must hold at least one fixture before its quality gate closes, so an area cannot publish a score by testing the easy half of itself.

The registry is public — spec/features.yaml in the engine repository — and it is the same registry that drives the engine’s fixtures and the feature ids in every compatibility report. The rendering areas it defines (PARSE, STY, NUM, LAY, CF, CHT, IMG, TXT, PDF, PNG) are the axes every score is reported along.

Scoring — one vocabulary, end to end

The bands a score uses are exactly the statuses the engine writes into every compatibility report. What we score ourselves on is what your pipeline gates on:

Band	Meaning	What the report carries
SUPPORTED	Renders to match the oracle within the rubric’s tolerances	The feature id and where it occurred; no warning code — there is nothing to warn about
PARTIAL	Rendered with a documented deviation — typically an interactive behaviour flattened to its current state, or a date-dependent rule evaluated at conversion time	A warning code naming exactly what differs and why, plus the affected locations
SKIPPED	Present in the file but intentionally outside conversion semantics — macros are never executed, live external data is never fetched (cached values render instead). Not a fidelity gap, still disclosed	The feature id, its locations, and a warning code where one applies
UNSUPPORTED	Not rendered faithfully, and therefore not silently approximated. The element is omitted or substituted, and the report says so before your customer sees the page	A warning code, the locations, and a non-zero exit code your CI can gate on

The engine’s own features[] statuses (rendered, approximated, unsupported, skipped) draw the same four distinctions at conversion time; the status semantics are normative for both. An area’s published pass rate is the share of its fixtures scored SUPPORTED — nothing is reclassified for marketing.

Alongside the pass rate, each area reports SSIM against the oracle: the structural similarity of the rendered pages to the rasterised Excel prints. Pass rate answers “how many fixtures met the rubric”; SSIM answers “how close were the pages that did”. Neither substitutes for the other, so both are published.

Determinism — why a score stays honest

A score you cannot reproduce is an adjective. Three properties make re-running possible:

1. Deterministic runs. Engine code contains no clock, no randomness, and no network — enforced by analyzers in CI. The same corpus renders to the same bytes, every run. In your own pipelines, --deterministic plus an explicit --reference-date give you the same guarantee (see the CLI reference).
2. Cross-platform proof. Each published run re-renders the corpus on multiple platforms. Any byte difference between them fails the gate and the score never publishes.
3. Auditable inputs. The corpus is content-addressed: its sha256 prints next to every score, so you can verify you are re-running exactly what was scored.

What a published result file carries

Scores on this site are generated from result files the harness commits — never hand-typed. Every such file carries its own provenance, and the site prints it beside the table it produced:

Field	Why it is required
corpus	Which corpus was scored. A score without a named corpus describes nothing.
sha256	The content hash of that corpus, so you can prove you hold the same inputs.
generatedAt	When the run happened, so a stale score is visibly stale rather than quietly current.

Per area, a result file carries the registry entry count, the pass rate, the SSIM figure, and the band — the four columns the fidelity page renders. The site build fails if a score appears without a result file behind it, which is what makes “generated, not written” a gate rather than a habit. The full machine-readable schema publishes with the first harness run; until then there is no file to describe.

Claims that are structurally not allowed

These are rules about what may be published at all, not editorial preferences:

• No aggregate percentage. There is no single headline fidelity figure for Rendlio, and there will not be one. A spreadsheet format this large cannot be summarised into one number honestly — the number would depend entirely on which features you weighted, which is precisely the judgement a reader is trying to avoid delegating. Fidelity is evidenced feature by feature, in the compatibility report and in per-area scores.
• No number without a run behind it. No projection, no extrapolation from a neighbouring area, no rounding a partial result up to the next milestone. An area with no published run shows no number at all.
• Every number links here. Any fidelity figure on this site carries a link to this page, so the method is always one click from the claim.
• Comparative numbers come later, and publicly. Figures against other engines are a separate publication that appears only once the corpus and harness are public, so anyone can re-run them. Until then the site compares licensing and deployment — facts you can check today — and makes no fidelity comparisons.

The measurement that matters to you

Corpus scores describe our fixtures. Your workbook is the benchmark you actually care about, and the engine applies the same standard to it: convert it and read the compatibility report, which names every deviation with a location, in the same four-status vocabulary above. The playground does exactly that in a browser, with no account.

Next steps

• Fidelity evidence — the per-area board these rules govern
• Compatibility report — the schema, statuses, and CI gating recipes
• Playground — run the same standard against your own workbook
• Security model — what the engine does with a file it cannot trust