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. :::note[Pre-launch] The corpus harness is being built now. Per-area acceptance scores publish on [the fidelity page](/fidelity) 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](https://github.com/rendlio/rendlio/) — and it is the same registry that drives the engine's fixtures and the feature ids in every [compatibility report](/docs/compat-report#feature-entries). 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](/docs/compat-report#status-semantics-normative) 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](/docs/cli#global-options)). 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](/fidelity) 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](/docs/compat-report), which names every deviation with a location, in the same four-status vocabulary above. The [playground](/playground) does exactly that in a browser, with no account. ## Next steps - [Fidelity evidence](/fidelity) — the per-area board these rules govern - [Compatibility report](/docs/compat-report) — the schema, statuses, and CI gating recipes - [Playground](/playground) — run the same standard against your own workbook - [Security model](/docs/security-model) — what the engine does with a file it cannot trust