Aelira Core: testing the installation behind the next release

Start with the public installation

Our v0.9.11 article followed remediation results through to the saved file. The next round of work extends that question to the installation itself. Can someone follow the public instructions, process documents, and retain their work when they upgrade?

We used an NVIDIA DGX Spark to approach Aelira as a university IT engineer encountering the open-core repository for the first time. A fresh checkout matters here. An established development machine can already have the tools and permissions that an installation guide leaves out.

That exercise exposed a Node runtime mismatch in the quickstart and a permissions problem in upload storage. Both corrections are merged into the public repository. The wider review also covered administrator invitations, account preferences and provider routes, alongside the evidence retained for processed documents.

These are changes since v0.9.11. We are preparing the next candidate; the latest stable release remains v0.9.11.

Saved work has to survive an upgrade

A successful build answers only the first installation question. An operator also needs to know whether existing scans remain available and whether a backup can restore a working system.

The current candidate builds on ARM64. In an isolated rehearsal, we upgraded an installation containing saved scans and a downloadable spreadsheet. The scans remained available, and the saved spreadsheet retained exactly the same bytes.

We then restored the earlier database and files into separate storage. Records created after the backup were absent, as expected, and the restored installation completed new work. Checking both outcomes matters: recovery must return the intended data and leave the application able to process another document.

This rehearsal covers the v0.9.11-to-candidate upgrade on ARM64, using synthetic documents with AI providers disabled. It does not establish behaviour for every deployment or model configuration.

After merging the latest fixes, we rebuilt the combined candidate on the Spark and repeated the saved-data checks. Existing scan results and downloadable files were preserved, and the installation processed another spreadsheet. We also checked review selection and navigation with a keyboard, and examined six dashboard pages at narrow and desktop widths. These checks passed; representative assistive-technology testing remains part of the release work.

A corrected response can look like lost data

The upgrade check also caught a distinction that a simple comparison would miss. v0.9.11 could report email notifications as enabled even when the saved preference was disabled. The candidate reports that saved preference correctly.

Comparing the two responses without checking the database would make the correction look like an upgrade had changed someone's setting. We inspected the stored value on both sides. It remained disabled.

The recovery check now accounts explicitly for that reporting correction while retaining its other comparisons. An expected difference needs an explanation grounded in the saved data.

A passing PDF check still leaves questions

Our LaTeX research examined another gap between a reported result and what it establishes about a document. In a pinned experiment covering 120 case-and-profile observations, two experimental tagging profiles each produced 26 PDFs that passed independent PDF/UA validation. Inspection still found missing diagram, table-header and heading structure in particular cases.

For someone reviewing course material, those omissions matter even when a validator passes. Compilation and machine validation need to be considered alongside preservation of source meaning and testing with readers who use assistive technology. This experiment did not establish mathematical equivalence or assistive-technology usability.

The experimental profiles have not replaced Aelira's production profile. The research report records the tested versions and limitations. It also separates an older metadata failure from its subsequent fix, so later work is not counted as evidence from the original experiment.

What operators can expect next

The next candidate also includes a historical confidence correction. An older generic AI path supplied 1.0 by default when a confidence score was missing. Matching historical records become unknown; previously accepted fixes in that set return to review, while rejected fixes remain rejected. The correction retains an audit record of the earlier values and decisions.

That change belongs in the upgrade instructions because it affects work an operator may already have reviewed. An absent score cannot support a claim of certainty, and an upgrade needs to explain why a previous approval has reopened.

Before tagging the next release, we still need to complete the remaining changed-flow browser checks, representative assistive-technology testing and verification of the final distribution artifacts. The ARM64 rehearsal is part of that evidence. It does not replace the remaining release checks.

The whole self-hosted product remains free and open source. The current stable release and upgrade guidance remain available while that work continues.