AMALT

Training as a readiness problem

The Dutch armed forces are growing, and training has to keep up: some 45 Defence schools train roughly 180,000 people a year, and the organisation is scaling toward 200,000. Long, standardised learning trajectories do not fit that reality. If people only have to learn what they do not yet master, they are deployable sooner.

That is the premise of AMALT, short for Automated Monitoring and Advice for optimizing Learning Trajectories: make learning trajectories personal and adaptive, and treat training speed as what it is for a military organisation, a readiness question.

AMALT brings together the Ministry of Defence, TNO, NLR, Next Learning Valley and HOIST IT. Defence contributes domain expertise and real learning trajectories. TNO and NLR investigate which approaches work and provide the evidence needed to evaluate the results. Next Learning Valley translates those insights into learning functionality that supports the intended outcomes in practice. HOIST IT fills the project’s Solution & Data Architect and Software Architect roles. We shape the whole system, from solution design through software architecture and deployment. We also build the data infrastructure underneath it: the layer where learning data has to live, move and stay governed. Development has been under way since the autumn of 2025; the first goal is a working prototype proven in a small number of real training trajectories.

What the platform does

Learning happens in many places: e-learning modules, simulators, AR and VR, the classroom, the field. Each of them produces data. AMALT collects it as xAPI statements (the open standard for recording learning experiences) in a Learning Record Store, enriches it with context such as instructor assessments and HR data, and translates it through analytical models into a current picture of each learner’s competencies. Compare that picture with what the role requires and you get a gap. Compare the gap with what has worked before and you get advice: a next learning step for the learner, a coaching signal for the instructor, a readiness picture for the manager. Then the loop runs again.

A loop like that is only as trustworthy as its data layer. Every piece of advice has to be traceable back to the events behind it, across systems and over years, and the training standards themselves may never be compromised by the drive to optimise.

How adaptive learning actually works

“Adaptive” has a precise meaning here. For every learner the platform weighs four factors: what someone can already do (inferred from activity and assessments), what the role requires (formalised as competency definitions), the gap between the two, and the best next intervention to close it. The interventions themselves are a fixed vocabulary rather than a black box: adjust difficulty, add or fade scaffolding, offer extra practice or let someone test out of mastered material, tune the feedback, change the spacing of repetition, or retire content once mastery is shown.

Two safeguards frame all of it. Guardrails check every recommendation deterministically before it reaches a person: safety limits, policy and clearance rules, pedagogical validity, resource availability. If an AI-generated recommendation violates one, the system falls back to a safe, rule-based default. And people stay in the loop: instructors see the advice, can adjust or override it, and their own assessments feed back into the learner’s picture.

One platform, many models

There is no single “AMALT model”. We architect the AI platform so that the model fits the use case. Learner inference uses locally served pattern-recognition models to read activity into competencies. Recommendations come from a multi-strategy recommender that combines content-based and collaborative filtering, knowledge-based reasoning over competency graphs and context-aware logic, with a meta-controller that weights the strategies by how well they have demonstrably worked. The analytics run from descriptive and diagnostic to predictive and prescriptive. Per trajectory, a strategy can start as explainable rules and grow into machine learning as the evidence accumulates.

The air gap shapes the AI as well. Cloud-hosted models are off the table, so every model is trained and served locally, on the same Kubernetes platform, with features pre-computed in the lakehouse and every recommendation stored together with its rationale and confidence score. Explainability is not a nice-to-have here; the stated quality goal is explainable aggregation, traceable from the advice all the way back to the source events.

The data foundation

The part we build with our own hands is that data layer. The foundation is a “lakehouse”: one open data platform that connects the Learning Record Store for live xAPI traffic with analytical storage on Apache Iceberg, with Kafka as the event backbone and Spark and Trino for processing and querying. Superset serves role-based dashboards, Keycloak handles federated access, and OpenTelemetry provides observability. Deployment follows a strict GitOps model with Argo CD: Git is the single source of truth, and every change reaches a cluster through a pull request.

The standards run deeper than xAPI alone. The architecture aligns with the full open learning-standards ecosystem: xAPI and its profiles (IEEE 9274), IEEE competency definitions (1484.20), learning-activity metadata (IEEE P2881) and enterprise learner records (IEEE P2997), the Total Learning Architecture of the US ADL Initiative with its master object model (TLA-MOM), publicly documented in the 2019 TLA report, and CaSS for competency frameworks. That is what keeps the data usable beyond any single tool, vendor or even this platform.

Sovereignty as a starting constraint

Learning data sounds harmless. Aggregated, it shows how ready units are and how they operate, and data like that cannot depend on infrastructure someone else controls. So the architecture starts from sovereignty: managed cloud services were ruled out early, however convenient, because they require internet connectivity and bring lock-in. What remained is a stack that is open source, self-hosted and installable without an internet connection.

The same platform that runs in a cloud development environment is built to deploy, from the same codebase, inside Defence’s own data centre: air-gapped, with learning data on Defence infrastructure, under Defence control. It is our definition of ownership in practice: the Ministry can possess the data on its own infrastructure, use it through open standards, and dispose of it provably. The organisational layer is arranged to match: open source, open standards and hand-over by design, so that no supplier, ourselves included, is impossible to replace.

Where it stands

AMALT is in development: the analytical models, the dashboards and the data platform underneath them are being built now, to be proven in real training trajectories first. We would rather show a working prototype than tell a finished story.

More on the thinking behind this in our blog series: what it really means to own your data and the layer you sign first and read last.