Aelira Core progress toward v1.0
Aelira Core adds stronger checks on saved LaTeX exports and updates its dependency baseline as work continues toward the v1.0 alpha and later releases.
Our September release update followed remediation through to the downloaded file. Our next post examined installation, upgrades and recovery. Both asked whether the evidence matched what an operator actually received.
We have continued that work while preparing Aelira Core for v1.0. The latest changes strengthen checks on saved mathematical content and refresh parts of the dependency baseline. They are merged into the public repository; v0.9.11 remains the latest stable release.
Checking the downloaded mathematics
For a lecturer preparing mathematical course material, small structural changes can matter. Attaching a subscript to a different part of an equation or moving a value within a matrix can alter what the expression says.
The new tests examine those structures in the saved HTML, including equation references and terms near the end of longer expressions. They also deliberately alter outputs to check that the tests detect damage. This gives us evidence about the specific structures covered by the tests. The public test cases show the structures and deliberate mutations used.
A supported export needs a complete path
The latest repair addresses several obstacles in LaTeX-to-HTML exports. Equation layout could trigger a table-related refusal after conversion. An explicitly authored document language had no suitable saved-HTML verifier, and the managed download path accepted LaTeX source files but did not yet accept inspected HTML.
The merged repair uses LaTeXML's native equation layout without HTML tables, checks the declared language against the final saved file, and allows inspected HTML through the managed download path. It keeps checks for unsupported content in place.
The added queue tests cover 26 synthetic cases. They produced 17 managed HTML downloads, seven diagnostic refusals, one refusal retaining a link to the intact project, and one case needing no change. The tests check the delivered bytes and retained records, including after authentication is refreshed.
These results establish a bounded export path. Human review remains required. Assistive-technology acceptance and overall presentation fidelity are still unassessed, and companion stylesheets are not yet packaged with the downloads. The HTML results carry no verified accessibility score.
Keeping unresolved work visible
A withheld file leaves the operator without a delivered repair. Its findings therefore need to remain unresolved in the records used for review. The latest changes preserve that accounting when remediation refuses an output, including through background processing.
When the evidence cannot establish an outcome for an individual finding, that detail stays unreported. An institutional reviewer needs to be able to see where the record ends and where further investigation is necessary.
Updating the release baseline
We also merged the dashboard dependency refresh and the gevent development-dependency update. The dashboard update passed installation, build and code checks, with a limited browser walkthrough covering login and saved scan information.
The combined export candidate passed all applicable CI checks, including both supported container architectures and the real document-processing queue. These checks add evidence for the candidate. Representative document review and assistive-technology testing remain open.
What remains on the road to v1.0
The public release tracker sets out the work required for the first v1.0 alpha. Open items include PDF structure editing, saved slide reading-order repairs, broader document acceptance tests and critical user journeys. Keyboard and assistive-technology checks, dependency reconciliation and verification of the final installation and recovery artifacts also remain part of that work.
The alpha will be an opt-in prerelease. Its gates require evidence for the included functionality, visible unsupported cases, and no known release-blocking authorization defect, unintended content loss or fabricated remediation success within the declared scope.
Beta requires an agreed feature-complete scope and representative workflow evaluation. A release candidate requires verified installation, upgrades and recovery with no known release blockers. Stable v1.0 follows resolution of acceptance and pilot findings, with documentation and support procedures ready.
We have not set dates for those promotions. Each stage depends on the evidence required by its release gates. The whole self-hosted product remains free and open source, and the public tracker is the place to follow progress.

RD (Reg) Crampton
•Founder & CEOFounder, CEO & lead developer of Aelira. Passionate about making education accessible to everyone. Building the tools universities need to meet accessibility compliance.
Related Articles
Aelira Core: testing the installation behind the next release
Our latest Aelira Core work follows the self-hosted installation from a fresh checkout through upgrade and recovery, with clearer evidence for the next release.
Aelira Core v0.9.11: following the result through to the file
Aelira Core v0.9.11 adds source-backed PDF review, corrects remediation status and strengthens tests from document upload through download and rescan.
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.