Aelira Core v0.9.8: evidence that travels with the document

Aelira Core v0.9.8 is available

Accessibility remediation does not end when a tool produces a new file. Someone still needs to know what changed, what evidence supports it, what remains unresolved, and whether the result still belongs to the source that was reviewed.

Aelira Core v0.9.8 strengthens that chain. This release adds portable evidence packages, owned and expiring review deferrals, durable visual-analysis records, clearer worker health, SARIF output for CI systems, and a fixture-backed PDF acceptance corpus. It also fixes several production failures found by exercising the complete packaged workflow.

The theme is trust that survives beyond one screen. Evidence can be downloaded and checked offline. Review decisions remain tied to the right source and output. Work that cannot be verified remains review-required instead of being presented as complete.

The whole self-hosted product remains free and open source.

Evidence can travel with the document

Reviewers can now download evidence for a remediation candidate and create a versioned evidence package that can be verified offline. The package records the source and output identities, review state, and relevant evidence without requiring the recipient to trust a live dashboard view.

That portability matters when a document moves between a faculty member, an accessibility team, central IT, a records process, or an external reviewer. The evidence has to remain connected to the exact document that was assessed.

The checks fail closed. A stale, missing, altered, or cross-tenant artifact is rejected. The package does not turn automated findings into a legal or accessibility determination; it preserves a verifiable record of what Aelira checked and what the workflow decided.

Why we added it: accessibility work often outlives the session in which it was performed. Evidence that only exists inside one application view is difficult to retain, review, or hand over.

Deferrals now have an owner and an end date

Some accessibility issues cannot be resolved immediately. The source file may need to be recreated, a subject-matter expert may need to confirm meaning, or an unusual structure may require specialist work. A useful workflow has to represent that reality without letting “later” become a permanent hidden state.

v0.9.8 adds owned, expiring deferrals. A reviewer can record who is responsible and when the decision must return for attention. Deferrals remain part of the evidence rather than disappearing from the record.

The release also makes an important reporting distinction clearer. Aelira reports aggregate remediation outcomes when that is the evidence the job actually produced. It does not invent per-issue success or failure attribution when the underlying remediation run cannot support it.

Why we added it: honest incompleteness is more useful than false precision. Institutions need to see both the work that has been completed and the decisions that still carry risk.

Visual analysis has a durable, reviewable lifecycle

Images and charts can require several attempts before a proposal is useful. v0.9.8 gives that work a durable lifecycle with bounded retries, provenance, and explicit human-review states.

Each proposal remains bound to the exact source bytes and the durable attempt that produced it. Unsupported or unverifiable output stays review-required. A proposal cannot quietly become an approved remediation because it looks plausible or because a later attempt changed the evidence underneath it.

This extends the same refusal line used throughout Aelira's STEM work: recognition can assist a reviewer, but it does not establish authorial intent or semantic correctness on its own.

Why we added it: the most dangerous accessibility error is a confident description attached to the wrong visual, or a plausible result that no longer matches the source a person reviewed.

Operators can see whether work is actually moving

Long-running accessibility jobs depend on more than an available API. The worker may be offline, leases may be expiring, or a queue may be growing while the front end still appears healthy.

Administrators can now inspect worker and queue health from the dashboard. The production readiness checks are tighter, and the packaged stack exposes the signals needed to distinguish an available API from a system that is ready to process documents.

The CLI also gains SARIF 2.1 output, making it easier to carry Aelira findings into code-scanning and CI workflows that already understand the standard format. Network commands now use one predictable configuration order: an explicit flag, then AELIRA_API_URL, then the active profile, then localhost.

Why we added it: self-hosting should be observable and scriptable. An operator needs to know whether the queue is healthy, while a developer needs stable output that can join the tools already used in delivery pipelines.

Production failures found in the full workflow are fixed

Several fixes in v0.9.8 came from running the same packaged path a self-hosted operator or user would run, rather than testing isolated components alone.

Local uploads are now persisted before durable enqueue. This prevents a queued scan from losing access to its input after the upload request ends. Pa11y and its Chromium launcher are included in the production API and worker images. The production Compose configuration accepts the documented environment format, routes dashboard API traffic through a same-origin proxy, and derives public links and email branding from deployment settings.

The dashboard now shows each PDF issue location once, keeps scan actions usable at narrow widths, and presents remediation outcomes at the level the job actually reports. PDF rollback comparisons are stable across serialization differences, invalid role-map self-mappings are removed, and genuine null ScanFix outcomes remain null instead of being converted into a misleading value.

Why we added it: a capability is only useful if it survives the production container, queue, browser, and downloaded artifact. These fixes close gaps that component-level checks did not expose.

The release process checks the thing people install

Production images now exclude development dependency trees, upgrade reviewed runtime packages, and verify the final installed package state before publication. Runtime and development Python dependencies are separated and fully pinned, with release checks covering both sets.

The release also refreshes CLI, dashboard, Python, GitHub Actions, OCRmyPDF, and transitive dependencies. Artifact-producing jobs receive only the metadata permission they require, and release actions use reviewed Node 24-compatible revisions.

The exact v0.9.8 candidate passed the backend, dashboard, CLI, formatting, dependency-audit, production-image, and fixed high/critical vulnerability gates. The packaged stack then completed an independent browser journey through upload, scan, remediation, artifact download, and a rescan scoring 100 with zero remaining issues.

The published release is tied to a GitHub-verified signed tag. It includes seven SBOM files, the @aelira/cli package, and API and dashboard images for both linux/amd64 and linux/arm64.

What operators need to know

This release includes database, production Compose, worker, dashboard, and dependency changes. Before upgrading, back up PostgreSQL and verify the restore path, drain active work, then run the database migration and confirm the single migration head is 20260905_visual_analysis.

Reconcile the deployment environment with the new Compose template and replace every required secret placeholder. Configure PUBLIC_API_URL, PUBLIC_DASHBOARD_URL, and CORS_ORIGINS for the public deployment. Deploy the API, worker, and dashboard from the same v0.9.8 release, then verify API readiness, worker health, dashboard health, the same-origin /api/live path, queue age, and failed or quarantined jobs before resuming intake.

Active deferrals should be reviewed for both an owner and an expiry. Visual-analysis and remediation outputs that remain manual or review-required must not be promoted as fixed.

Read the complete upgrade procedure and compatibility notes in the v0.9.8 release before updating a deployment.

The direction of the project

v0.9.7 broadened what Aelira could handle while making its refusal line clearer. v0.9.8 makes the resulting work easier to operate, review, retain, and verify.

That is the direction for Aelira Core: open accessibility capability that can run in an institution's own environment, preserve human judgment, and produce evidence that does not depend on taking the software's word for it.

The source, installation instructions, release assets, and full changelog are available on GitHub.