Aelira Core v0.9.10: scores measured from the files
Aelira Core v0.9.10 replaces estimated remediation scores with paired checks of original and saved files, with clear reasons when comparison is unavailable.
Why v0.9.10 exists
An accessibility tool that shows a before-and-after score is making a specific claim: it checked the original, checked the saved result, and can fairly compare them.
We found a gap in that claim. Some Aelira remediation paths estimated an after-score from the changes attempted. That could produce a number that did not describe the saved file. Other results lacked enough source detail to establish a valid comparison.
Aelira Core v0.9.10 addresses both problems. This hotfix replaces estimated outcomes with measurements from the original and saved output where compatible verification is available. It also retains the scanner findings needed to make those comparisons, including for Word, PowerPoint and Excel uploads.
The whole self-hosted product remains free and open source.
The v0.9.9 hotfix addressed how scanner findings were recognised and accounted for during remediation. v0.9.10 addresses a separate question: whether the before-and-after numbers describe a valid comparison of the files themselves. Accounting for attempted work does not establish the saved document's score.
Compare the files, using the same checks
Supported comparisons scan the original and saved output with the same deterministic settings. A verified result records the scoring-method version and SHA-256 fingerprints of both files, so the measurement is tied to the exact artifacts that were checked.
That matters when a result is downloaded, reviewed later, or passed to someone else. A score should describe that file, not an earlier candidate or a count of fixes the software tried to apply.
The comparison can report a lower score. Remediation does not earn an automatic increase, and v0.9.10 does not raise a lower measurement to make the result look better. A lower result is information a reviewer needs to see.
The original findings have to survive the workflow
Simply hiding an unreliable number would leave the underlying problem unresolved. The system also needs the original findings and the saved file available for comparison.
Word, PowerPoint and Excel scans now retain the canonical finding details used by their scanners. For older Office records with incomplete details, Aelira can recover uniquely matching findings from a retained original. It preserves the original scan record and does not silently expand the findings selected for remediation. Ambiguous matches remain review-required.
When a valid comparison still cannot be made, the after-score stays unavailable with a specific reason. A missing original calls for recovery or re-upload. An output that could not be fully scanned needs investigation. If a new measurement cannot reproduce the recorded baseline, the next step is a fresh scan of the original.
These are different problems, and the result now distinguishes them. An unavailable score is never replaced with zero or a projected improvement.
Verification has limits
The appropriate comparison depends on what was scanned. PDF verification requires complete paired checks. HTML, CSS, JavaScript and LaTeX source comparisons use their corresponding source scanners. Static source checks cannot certify browser findings on a website or in Canvas; Canvas stored content has a separate paired browser-verification path. Multimedia output without a comparable verifier remains unverified.
An automated score is a summary of implemented checks. It is not a WCAG conformance certificate, and it does not establish that generated descriptions preserve meaning or that a document works well with assistive technology. Review remaining findings and the actual downloaded file before use.
The public workflow continues to withhold partial remediation output. Recovering missing findings does not add a new Office approval workflow or enable automatic upload.
What the regression tests cover
The regression suites cover the evidence used to calculate and present the comparison. They exercise canonical Office findings and pre-hotfix records, paired scores, exact file identity, unavailable-result diagnostics, and the presentation of older results.
These checks matter because a successful remediation job and a verified comparison are different outcomes. The result must not become a verified score simply because a job finished or recorded a number of fixes.
Browser checks supplement those automated tests. They do not imply complete user-journey certification in CI, or establish that every document will produce a comparable result. The release notes describe the supported comparisons and diagnostics explicitly.
What operators need to do
v0.9.10 needs no new database migration or environment variable. Back up the database and retained files, then deploy the API, worker and dashboard from the same 0.9.10 release. If you are upgrading from an older version, preserve the earlier operator requirements, including the v0.9.8 upgrade steps.
Older estimated results are not retroactively verified. An old result may now show an unavailable after-score. Where the original is retained, rerun remediation to produce new evidence; if its findings cannot be reproduced, create a fresh scan first. If the original is missing, recover it from your source system and upload it again.
Scanning an already-remediated file can establish its current score. It cannot reconstruct the missing before-score.
Why this was a hotfix
The comparison sits at the point where someone decides whether to trust a remediation result. Leaving an estimated score there until the next feature release would leave that decision based on a number the saved file might not support.
Suppressing the number was only the first safeguard. The correction also had to preserve enough source detail to make the comparison possible, recover older evidence where it could be matched safely, and explain the cases that still could not be verified.
The standard is straightforward: a before-and-after score must be traceable to the original and saved files. Where that trace is incomplete, the result needs to say what is missing and what the operator can do next.

Aelira Team
•Accessibility EngineersThe Aelira team is building AI-powered accessibility tools for higher education. We're on a mission to help universities meet WCAG 2.1 compliance before the DOJ ADA Title II deadline (April 26, 2027 for large public entities).
Related Articles
Aelira Core v0.9.9: Why We Shipped a Hotfix
Aelira Core v0.9.9 fixes a scanner-to-remediator contract mismatch in v0.9.8 and strengthens testing across the full remediation path.
Aelira Core v0.9.8: evidence that travels with the document
Aelira Core v0.9.8 adds portable evidence, safer deferrals, clearer operations, SARIF output, and a more dependable self-hosted stack.
Aelira Core v0.9.7: broader STEM support, stricter verification
Aelira Core v0.9.7 expands STEM remediation, strengthens saved-file and human-review checks, and gives institutions clearer evidence and provider control.