How are we building Thor 1.0?

What we are developing, by what method, and against what we measure the result. With the terms explained.

Last reviewed: 4 September 2026

Thor 1.0 is an AI assistant that runs on the client's own infrastructure and works directly on its ERP data, without that data passing through a non-European cloud. Development starts on 1 November 2026 and runs for six months.

This is not a product page. Thor does not yet exist. What follows is the process, the method and the standard we have set in advance.

Open or closed: the choice everything rests on

Thor builds on Mistral Small 3, a model from the French company Mistral AI. That choice is not a preference but a requirement.

A closed model exists only on the provider's servers. You cannot download it or run it yourself, so your data has to go to it. An open-weight model publishes its weights: the numbers the model learned during training, which determine how it answers. Those you can download and run on your own equipment, without any connection to the provider.

Thor runs on isolated equipment in a Belgian data centre, without internet access. That presupposes that the model can physically sit there. With a closed model that is impossible by definition, whatever the contract says.

The licence is the second requirement. Mistral Small 3 sits under Apache 2.0, which permits commercial use, modification and redistribution without a revenue threshold. Not every model called "open" goes that far, and open weights is moreover not the same as open source: the weights are public, the training data is not.

In more detail: "What does 'open' mean in an AI model?"

The price of this choice is set out in part 8: an open model of this size performs less well on general tasks than the largest closed models. That is the trade-off we make deliberately.

What "tuning to regulation" means

This is the core of what we are investigating, and it is the hardest part to explain.

The common approach today is a filter around the model. The model gives an answer, and a separate layer then checks whether that answer is acceptable. If it is not, the answer is blocked. The model itself does not change.

We are investigating whether it can also be done differently: by tuning the model so that it reasons within the boundaries of the regulation from the outset, rather than being corrected afterwards.

The method is called Group Relative Policy Optimization, abbreviated to GRPO. In plain terms: the model is given the same question several times, produces different answers to it, and those answers are compared with one another and ranked. The model is then adjusted in the direction of the best-rated answers. It therefore learns not from a single example answer, but from the comparison within a group of its own attempts.

The difficulty lies not in the technique but in the assessment criterion. To rank an answer, you have to convert legal norms into a signal a model can adjust on. That is what we have to work out and measure in this project. GRPO is today applied mainly in academic and reasoning contexts. As far as we have been able to establish, the method has not yet been used to tune compliance behaviour on corporate data.

Whether that works, we do not know. That is why it is a research project and not a product.

The setup

• Dedicated hardware. Thor runs on isolated equipment in a Belgian data centre, not on shared infrastructure.
• 
  
• No internet access. The environment has no open connection to the outside. That makes building harder: every connection has to be set up expressly.
• 
  
• A bidirectional connection to SAP S/4HANA. S/4HANA is the current generation of SAP's ERP package. Bidirectional means the connection works in two directions: Thor reads data from the system and writes its findings back to it.
• 
  
• Containerised clusters. A container is a self-contained package in which a program runs with everything it needs. Each part of Thor therefore runs in its own defined space, which makes it manageable and repeatable.
• 
  
• An independent review. In month five, an external security expert carries out a penetration test: a controlled attempt to break in, to expose weak points before someone else does. That person deliberately sits outside the project, because a review carried out by ourselves has no evidential value.
• 
  
• A DPIA process. A data protection impact assessment maps which personal data is processed and what risks attach to that

How we measure the result

Before the first tuning round starts, we fix two things: a baseline and two thresholds.

The baseline is the performance of the untuned model on the same test set. Without that starting point you cannot say afterwards whether anything has improved.

The thresholds: an error rate below 8 per cent on the test set, with a regression of no more than 3 percentage points on general benchmarks. That second threshold is there because a model tuned more sharply to one task generally becomes worse at others. A model that checks invoices perfectly but loses its general reasoning ability is not a successful result for us.

Both figures are fixed before the first run. That is deliberate: it means the outcome cannot afterwards be bent towards the result we wanted.

Glossary

• Apache 2.0 — a permissive licence permitting use, modification and redistribution, including commercially, without a revenue threshold.
• Baseline — performance before adjustment, as a reference point against which to measure improvement.
• Benchmark — a standardised set of tests by which models are compared with one another on general tasks.
• Bidirectional connection — a connection that works in two directions: reading and writing back. 
• Closed model — a model reachable only through the provider's servers, which you cannot download or run yourself.
• Connector— the software that allows two systems to communicate, here between Thor and the ERP system.
• Container — a self-contained package in which a program runs with everything it needs.
• Dedicated hardware — equipment used for a single client only, as opposed to shared infrastructure. 
• DPIA — data protection impact assessment: an analysis of the privacy risks of a processing operation, mandatory in certain cases. 
• ERP — the system in which a business manages its operational processes. SAP S/4HANA is 
  one such system.
• Error rate — the proportion of cases in which the system flags a discrepancy that is not there, or misses one that is.
• Isolated environment — an environment with no open connection to the internet. Every outward connection has to be set up expressly.
• Weights — the numbers a model has learned during training, which together determine how it answers.
• GRPO — Group Relative Policy Optimization: a tuning method in which a model learns from the comparison of several of its own answers to the same question. 
• Hyperscaler — a very large cloud provider able to add capacity almost without limit.
• Isolated environment — an environment with no open connection to the internet. Every outward connection has to be set up expressly.
• Open-weight model — a model whose weights are publicly available, so that you can run it yourself.. 
• Open source — stricter than open weights: the training data and the training process are then available as well.
• Peppol — the European network for the exchange of structured electronic invoices.
• Penetration test — a controlled attempt to break in, to identify weak points before someone else does.
• Response time — the time between the query and the system's answer.
• Test set — a set of cases held apart to assess the model on, and therefore not used to train it.