Changelog
What shipped, and when
Released changes to the platform, most recent first. Anything still in development is described as in development, here and everywhere else.
Version 1.0
Aug 3, 2026
Reference taxonomy and the reporting pack
The reference taxonomy and the standard reporting pack ship together. New deployments now start with the full structure in place: 18 root containers, 12 departmental areas and 80 second-level function folders, with 34 tags defined across 6 namespaces.
The reporting pack adds 28 templates in 8 categories, built to the Data Collection Instrument structure that funders ask for.
Team folders are provisioned against the department rather than the person, so they survive staff turnover.
Search results are filtered by permission at query time rather than after the fact, so a record a user cannot open does not appear in their results.
Version 1.0
Aug 3, 2026
Reference taxonomy and the reporting pack
The reference taxonomy and the standard reporting pack ship together. New deployments now start with the full structure in place: 18 root containers, 12 departmental areas and 80 second-level function folders, with 34 tags defined across 6 namespaces.
The reporting pack adds 28 templates in 8 categories, built to the Data Collection Instrument structure that funders ask for.
Team folders are provisioned against the department rather than the person, so they survive staff turnover.
Search results are filtered by permission at query time rather than after the fact, so a record a user cannot open does not appear in their results.
Version 0.9
Jun 15, 2026
Sensitivity tiers and approval objects
Records now carry a sensitivity tier: Public, Internal, Confidential or Sacred. The fourth tier is not a standard classification and it does not behave like the others. Where an entity marks material as Sacred, the system restricts it to the people the entity names and keeps that restriction out of the hands of general administrators.
Approval is now a separate object rather than a tag. Where an approval object and a Status tag disagree, the approval object is authoritative. The tag is a convenience for filtering; the object is the record of the decision.
Tiers are applied at the folder level and inherited, so a record does not lose its handling rules when it is moved.
Version 0.9
Jun 15, 2026
Sensitivity tiers and approval objects
Records now carry a sensitivity tier: Public, Internal, Confidential or Sacred. The fourth tier is not a standard classification and it does not behave like the others. Where an entity marks material as Sacred, the system restricts it to the people the entity names and keeps that restriction out of the hands of general administrators.
Approval is now a separate object rather than a tag. Where an approval object and a Status tag disagree, the approval object is authoritative. The tag is a convenience for filtering; the object is the record of the decision.
Tiers are applied at the folder level and inherited, so a record does not lose its handling rules when it is moved.
Version 0.8
Apr 20, 2026
Intake, processing, output
Records move through three stages: intake, processing, output. Nothing is filed directly into its final home. Everything arrives in intake, is worked on in processing, and is placed in output only once it is finished.
The intake area is swept every 90 days. Anything still sitting there is either moved on or accounted for, which stops intake becoming a second, unofficial filing system.
The change is deliberately inconvenient. It costs a step at the point of filing and it buys a record you can defend later.
Version 0.8
Apr 20, 2026
Intake, processing, output
Records move through three stages: intake, processing, output. Nothing is filed directly into its final home. Everything arrives in intake, is worked on in processing, and is placed in output only once it is finished.
The intake area is swept every 90 days. Anything still sitting there is either moved on or accounted for, which stops intake becoming a second, unofficial filing system.
The change is deliberately inconvenient. It costs a step at the point of filing and it buys a record you can defend later.
Version 0.7
Feb 16, 2026
Everything executes on the appliance
Storage, the database, search indexing, text recognition, thumbnail and preview generation, document conversion, model inference and the rules engine all execute on the appliance. Nothing in that list depends on a connection leaving the building.
The request path is deliberately short: web server, application runtime, database, file store. Everything else runs in the background through a job queue, so a slow conversion or a long indexing run does not hold up someone trying to open a file.
If the link goes down, the system keeps working for the people on the local network. That is the point of the design, and it is the main reason it costs more than renting space in someone else's data centre.
Version 0.7
Feb 16, 2026
Everything executes on the appliance
Storage, the database, search indexing, text recognition, thumbnail and preview generation, document conversion, model inference and the rules engine all execute on the appliance. Nothing in that list depends on a connection leaving the building.
The request path is deliberately short: web server, application runtime, database, file store. Everything else runs in the background through a job queue, so a slow conversion or a long indexing run does not hold up someone trying to open a file.
If the link goes down, the system keeps working for the people on the local network. That is the point of the design, and it is the main reason it costs more than renting space in someone else's data centre.
Version 0.6
Dec 8, 2025
The EdgePod, and the terms of leaving
First appliance build. The EdgePod is a single self-contained unit that sits in your building and holds the whole system: storage, database, search and the application itself.
Files are converted to a stable, open format on write, with the policy set per entity, so what is stored stays readable without our software.
Export is in open formats, at no charge, and the obligation is written into the customer agreement rather than left to goodwill. Leaving is a supported operation, not an argument.
The entity holds the encryption keys. Key escrow is available and optional. Vendor access is named, scoped, logged and revocable, and there is no standing administrative access.
Version 0.6
Dec 8, 2025
The EdgePod, and the terms of leaving
First appliance build. The EdgePod is a single self-contained unit that sits in your building and holds the whole system: storage, database, search and the application itself.
Files are converted to a stable, open format on write, with the policy set per entity, so what is stored stays readable without our software.
Export is in open formats, at no charge, and the obligation is written into the customer agreement rather than left to goodwill. Leaving is a supported operation, not an argument.
The entity holds the encryption keys. Key escrow is available and optional. Vendor access is named, scoped, logged and revocable, and there is no standing administrative access.