Changelog & Roadmap¶
Changelog¶
v2026.09.1 — Choosing the NLP Model (September 2026)¶
How to use it: Using NLP suggestions. The endpoint: API endpoints.
The interpreter chooses which model labels the text. Role detection had one model, fixed at deploy time by the MODEL_PATH environment variable. nlp-api now carries a registry of selectable models — bertje_2022_e4, the existing default, and legal-bert-dutch-english — and POST /api/predict takes an optional model field naming one. The Act frame form gained an NLP model dropdown beside the suggestion controls, so the choice is per request rather than per deployment.
Unknown and missing keys fall back rather than fail. A model value the registry does not know, or no value at all, resolves to the default, and the response echoes the model actually used — so a caller can always tell which one produced the labels rather than assuming its request was honoured. Adding a model to the registry is what exposes it in the GUI; there is no separate list to keep in step.
A missing model file is reported, not guessed at. The resolved path is checked before loading, and an absent directory answers 500 with "Model does not exist on filesystem." rather than surfacing a loader traceback. That check matters because model files are no longer part of the image.
Model storage moved out of the container. nlp-api takes its model root from configuration, and the Azure infrastructure adds a storage account to hold the model files. Previously a model shipped inside the image, so adding one meant rebuilding and redeploying the service; they are now mounted, and the registry decides which of them a request loads.
The state-debug panel is removed — it slowed the editor down enough to be worth losing.
v2026.07.4 — Python Packaging and Pipeline Steps (July 2026)¶
The Python services gain pyproject.toml files and their packages are upgraded, nlp-api among them. The backend's tests move to light-my-request, which exercises Fastify's routes in-process rather than over a real socket — faster, and with no port to collide on.
The GitLab pipeline gains its build steps, completing the two-stage shape that the test jobs from v2026.07.3 had started.
v2026.07.3 — A Test Suite and a CI Pipeline (July 2026)¶
Measured inventory and commands: Testing.
Automated tests arrive across the stack, in one release: the GUI's domain logic, the backend, and the wrap-up API. This is the release that took the Norm Editor from no automated tests to a suite covering both languages it is written in.
A GitLab CI pipeline runs them. .gitlab-ci.yml defines a test stage with five jobs — test_gui and test_backend on node:24, test_wrap_up_api, test_unwrap_api and test_nlp_api on python:3.14.6 — ahead of a build stage that builds and pushes a container image per service to Azure Container Registry. The Norm Editor is the only IOU component whose CI runs on GitLab rather than GitHub Actions; see Code Standards.
v2026.07.2 — Changelog Generation on Commit (July 2026)¶
A pre-commit hook regenerates the changelog, so gui/public/changelog.json — which the in-app changelog viewer reads — stays in step with the git history rather than being regenerated by hand at release time.
v2026.07.1 — Filesystem Import Fixed (July 2026)¶
Importing an interpretation from the filesystem was reading the wrong format and failing. Fixed, and the GUI version bumped.
v2026.07.0 — First Tagged Release (July 2026)¶
The Norm Editor starts version-tagged releases. Previously the component shipped without
git tags or a generated changelog; 2026.07.0 is the first annotated release tag, and
scripts/generate-changelog.mjs now builds gui/public/changelog.json from
Conventional Commits history for the in-app changelog
page. Commit messages are enforced as Conventional Commits via git hooks going forward. This
entry therefore documents everything in the tag's range, not just what changed since a prior
release — most of the application's core functionality (task definition, source collection,
annotation, FLINT frame authoring, NLP suggestions, TriplyDB round-trip) predates this tag and
is described in the Features and User Guide
pages rather than here.
Server-side rendering removed; the frontend is now a plain SPA. src-ssr/ (the Quasar SSR
server, its Triply-fetching middleware, and the render pipeline) was deleted. Client-side
routing (router/routes.js) now drives six routes — task, sources, interpretation,
visualization, executable, execute — each a thin pages/*.vue wrapper around the existing
views/*.vue step UIs. See Frontend and Architecture, both
updated to describe the current SPA + router setup instead of the removed SSR mode.
In-app changelog page restyled. The changelog viewer (gui/src/components/Changelog.vue)
now renders status pills, emoji-grouped sections, and a document header for the JSON produced
by generate-changelog.mjs.
Internals backported from the TNO mirror. Graph-processing internals, several
wrap-up-api endpoints, and UI styling/layout were backported from the TNO mirror of the
project, alongside removal of duplicate view components and assorted small style/layout
fixes.
Deployment and infrastructure hardening. Azure Container App templates gained a
revisionSuffix (utcNow) so ./deploy.sh always forces a new revision instead of an ACA
deploy silently reusing a cached image; a DNS zone was added; SSL termination and the release
workflow (tagging, changelog generation, redeploy) were documented in the repository README.md;
and a Docker Compose port conflict on the web host mapping was resolved.
Roadmap¶
Planned¶
The five-stage interpretation workflow described in the Overview has two
stages still scaffolded as placeholders in the router (pages/ExecutablePage.vue and
pages/ExecutePage.vue both render a "Coming soon" state):
| Feature | Stage |
|---|---|
| Validate — making an interpretation executable | executable route |
| Perform — executing a task | execute route |