How it works

Dundir removes the administrative work before the decision and documents the reasoning after it. The buyer reviews and decides. The system computes and records.

The chain

Five steps, one report.

01

You enter a material specification

In plain language, the same way you would describe it today. No form to fill in, no separate notation.

02

The AI layer translates the specification

The system turns it into structured procurement requirements: required certifications, delivery windows, budget limits and weighted objectives. This is the only place in the chain where a language model is at work.

03

The optimisation engine computes the best combination

It runs on your supplier database and finds the mathematically demonstrable best combination given your hard requirements and weighted objectives. Not a suggestion. A computed answer with a full reasoning trail.

04

You review the output and decide

You see a ranked comparison with sources, certification status and the full reasoning trail. You decide. The system records your decision and the reason for it.

05

The audit-ready report is generated automatically

Ready for internal approval, external audit or public procurement review. No extra work afterwards.

Local

Why it runs on your own server.

Three consequences of local deployment that matter directly to municipalities and construction firms:
Data
Your procurement data never leaves your own server. Prices, supplier agreements and contract details stay where they belong.
Continuity
There is no dependency on external APIs or cloud providers. The system does not stop when a vendor changes its pricing or its terms.
Compliance
The system satisfies GDPR and municipal IT policy without anyone having to request an exception for it.
This is not our preference. It is what practice imposes. In a study at the architecture firm Cedervall, GPT-4 was prototyped and rejected on cost and third party dependency; cloud Llama-3 was rejected on twenty second latency and the requirement that data stay on the internal network. On-premise was the only acceptable outcome, and that was an architecture practice, not a municipality.

Friðriksson 2025, KTH · van Duuren 2025, TU Delft

Explainability

Every output shows its reasoning.

Identical

The same input gives the same output. A generic AI system returned different outputs for identical inputs, with errors of up to 8,354 euro on a single line.

Hamppi 2025, Aalto University

Which data sources were used, how each supplier was assessed, why one ranks above another. The system records it explicitly.

For municipalities this is a legal requirement. For construction firms it is the difference between a report a manager signs and a report he sends back.

Limits

What the system does not do.

Dundir does not make procurement decisions. The buyer reviews the output and decides. The system does not replace the buyer.

It removes the administrative work so the buyer can do the actual job: judging, maintaining relationships and escalating. The decision and the responsibility stay with you.

The system is trained on your own procurement history, not on a generic model. The result knows your preferred suppliers, your certification requirements and your earlier decisions. When a senior buyer leaves, that knowledge stays available to the whole team.

Honest about the stage This chain is designed and partly built, not in production at a customer. Anyone joining now does so as a design partner and helps decide what the system is calibrated on.