In brief

For external readers, technical infrastructure matters when it enables a subject-relevant property: changes should be reproducible, test operation must not be confused with production, and security or recovery questions should be addressed before the first real data incident.

Host, application and processing services are therefore deliberately separated.

Three layers with different responsibilities

The current architecture distinguishes:

Host and base infrastructure

The project VM provides the operating system, container runtime, network foundations, tunnel, runner and host security. Its target state is described through Ansible, Docker Compose and versioned scripts wherever practical.

Application

The web platform owns its source code, container build, demo Compose definition and application-level deployment logic.

Processing services

Independent services such as text to speech own their own code, API contract, tests and later containers. A separate integration layer should coordinate only those service versions that are actually integrated.

These boundaries reduce unnecessary coupling. Replacing a TTS engine, for example, should not require changes throughout the web interface and host configuration if the service contract remains stable.

Reproducible target state rather than “it works on this server”

The VM repository follows the principle of describing configuration as code or versioned documentation wherever possible.

This includes the Docker baseline, reproducible performance baselines, local model runtime, operational tools and test-deployment infrastructure.

The long-term benefit is traceability: if a change causes problems, it should be possible to understand what changed and how a defined state can be restored.

The public demo is intentionally only a test path

The vision prototype is publicly reachable. The underlying web application remains locally bound, while external access is provided through an outbound tunnel.

More important than the network detail is the editorial distinction: this path exists for the test demo.

It does not mean that all requirements for real user or examination data have already been satisfied. Productive authentication, full backend persistence and the later processing services are not yet integrated as one production system.

Deployment is not a separate project achievement

The earlier newsroom treated the automated demo deployment path as its own news item. Editorially, that was too technical and granular.

It is more useful to treat deployment as part of the same infrastructure decision: application and host have separate responsibilities, and demo changes can be built, checked and deployed reproducibly.

That is necessary preparation, but not sufficient proof of production readiness.

Rollback is not the same as data restoration

The project distinguishes:

  • application rollback — returning from a faulty software version,
  • data restore — recovering stored data after loss or corruption.

They require different tests and evidence.

While the vision prototype uses synthetic demo data, the risk is limited. Before productive data are introduced, this becomes a central operational requirement.

The deployment runner is a trust boundary

Automated deployment means that a runner is allowed to make changes to the target environment. The runner therefore becomes security-relevant itself.

The infrastructure planning treats it as a separate trust boundary that needs appropriate review before production use. Concrete internal security details are intentionally not published in the newsroom.

Why this matters to partners

Media centres, universities and other organisations do not need to care which repository owns a Compose file.

The relevant questions are:

  • Can a pilot be updated reproducibly?
  • Can a faulty version be rolled back?
  • Are data recovery and software rollback planned separately?
  • Is test operation clearly separated from production?
  • Can individual services later be replaced without rebuilding the whole system?

These questions become more important as the project moves closer to real pilot data.