What's *new*.
Spring 2026 — what changed for users
Section titled “Spring 2026 — what changed for users”The single biggest visible change since the start of the year is that search is consistently faster. A single archive node running on standard hardware now handles a few thousand queries per second under realistic load, with sub-millisecond latency on common queries. For a national archive that means the public-facing search no longer slows down at peak hours; for an institutional setup it means the curator’s editor responds the moment they click.
The less visible change is that the system uses less memory for the same work. At rest, a running archive holds onto a few hundred megabytes of working memory rather than several gigabytes. That sounds like an engineering nicety until you remember that it’s the difference between running the platform on a modest server and needing a dedicated machine. Several deployments that previously needed shared hosting can now run on a single box.
Statistics over very large result sets are quicker too. A query like “every page mentioning a place name in this 350,000-page corpus” used to take more than two minutes to summarise; it now returns in a few seconds. This unblocks the kind of meta-question that meaningful archival research depends on.
Better search behaviour
Section titled “Better search behaviour”Some search queries used to misbehave. A wildcard pattern matching too many words could exhaust memory and crash the server; a phrase across many wildcarded terms could take dozens of seconds. Both classes have been fixed. The first is now capped at a sensible upper bound — beyond which the most frequent matches are kept and the long tail is dropped, so the user gets useful results rather than no results at all. The second is faster by a wide margin: phrase queries return roughly three times more quickly than they did, and complex queries with many wildcarded terms perform proportionally better.
The search syntax picked up a small but useful addition: a trailing dollar sign on a name expands the query to match the same name with or without any of the tags the system attaches at index time. A query for Antonio$ now finds Antonio and Antonio tagged as a person name in the same pass. For the user this means they no longer need to know whether the corpus has been annotated to find their name.
Form documents
Section titled “Form documents”Not every old document is prose. Census registers, registry cards, ship manifests and parish forms all have a printed scaffold — labelled boxes — filled in by hand. The system now recognises that structure and treats each labelled field as a typed input, anchored to its region on the page. The result is that a curator working through a hundred parish records sees a form editor with named fields, not a wall of free text. It exports as a spreadsheet directly.
Operational improvements
Section titled “Operational improvements”Several improvements are operational rather than functional. The system now logs detailed diagnostics about its own internal caches, so an operator can see at a glance how well the various levels of caching are working under their workload, and tune the system if needed. A crash handler logs the cause to standard error before re-raising, so if anything ever does go wrong, the operator can see why. Authenticated benchmarking is now supported, for institutions whose deployments require login on every endpoint.
Underneath, the memory allocator was swapped for one designed for long-running mixed workloads. The visible effect is that memory consumption no longer drifts upward over time — the system returns freed pages to the operating system rather than holding onto them. The first night after the upgrade, several deployments reported their archive’s memory footprint dropping by an order of magnitude with no other change.
For AI assistants
Section titled “For AI assistants”The set of tools an AI assistant can call on archAIc grew. Assistants can now read structured form data from form documents, ask for statistics over an entire corpus or a slice of it, propose document boundaries (and wait for a curator to confirm), and run autofill on a specific document. As before, every result they produce carries the source — page, line, region of the image where the evidence lives.
Architecture
Section titled “Architecture”Behind all of this is a long-running migration from an older C++ search engine to a Rust-based one. The two ran side by side for several months on test workloads; the Rust engine consistently used a fraction of the memory of the older one (roughly one fifteenth, on identical archives) and was significantly faster. The Rust engine is now the default. Deployments that wish to continue running the older one can, via a configuration flag; the documentation explains the trade-offs.
The PHP web interface, the search engine and the AI-assistant interface all now run as independent services orchestrated together. An institution can deploy any subset of them — for example, just the search engine, with a custom frontend on top — without touching the rest of the platform. The deployment guide covers each option.
This page is updated on each release. The current production version is 0.3.3, dated March 2026.