Skip to content
The engine room, for those who lift the bonnet

No story about AI. The actual chain, line by line.

What runs at night, where the amounts come from, which rules decide whether a question arises, what the gates stop and why we went that way at every fork. Every number on this page was taken from the running machines on 17-09-2026.

Four machines, one network

in-house, no cloud

11.6 GB source database

the full back office, rebuilt every night

Measured 17-09-2026

measured live, no mock-ups

01, what it runs on and why that split

Four roles in-house. No cloud, no external inference.

Orchestrator

Schedules, stores and orchestrates. Deliberately runs no language model.

Heavy models

Carries the knowledge layer and the largest language models.

Bulk and OCR

Reads the document stream in parallel and does the text recognition.

Source and backup

Holds the archive and the backups. Always source, never target.

Why this way

Each role on its own machine. One machine may fail without the others stopping, and what stores does not compute, what computes does not store.

What we got wrong ourselves

One machine blocks ping. We used ping as a presence check and got a false outage. The check belongs on the service port, not the protocol. That is now a lesson in the register.

0
personal data leaving the network. All inference is local

Measured on our own machines, 17-09-2026.

02, from backup to card in 30 phases

Every phase proves itself before the next one starts.

One orchestrator. Every phase logs four numbers, source, processed, errors, status, and writes its own partial log. A non-critical phase may fail, reports it, and the chain continues on the previous value. Only the phases every amount depends on can stop the chain.

01
Fetch the source
Gate on the document source, delta sync of the archive, transport of the newest complete backup set
02
Restore
Full restore of the source database, no export from yesterday
03
ETL and date gate
All source tables into the measurement layer, three skipped for privacy. If the invoice date is not fresh, it stops here
04
Reference sets
Debtors, hours, work orders, period ripeness, client and contract sync, additive
05
Knowledge layer
Contracts into the vector store, fresh archive scan, classification, delta and re-indexing
06
Freshness gates
Source freshness gate against silent staleness, carry-on file, indexation register
07
Agents and conductor
Analysis, card build, card writer, question register, effect measurement, queue, cross-validation
08
Mailroom
One exit to the platform, with destination, amount, evidence and deadline
03:15
starts from the scheduler, no human needed
89
minutes, was 322 minutes until 02-09
11.6 GB
source database, rebuilt every night
14 / 14
nights completed since 04-09, all phases OK
Critical and non-critical

If the document scan fails, yesterday's index stays and the chain continues. If the restore or the ETL fails, everything stops. That distinction is in code per phase, it is not improvised at night.

Duration measured over 31 runs before versus 14 runs after the change of 03-09.

03, where an amount comes from

Every amount is one SQL sum. No model touches a number.

One measurement core that adds up revenue, cost and result per client, per contract group, per object and per period. The outcome is the gap against the norm. A model then phrases the sentence, but the amount is already calculated and re-checked.

The rule

The gap is norm times revenue minus result. The key is never the debtor code alone but debtor code plus administration. Every join always runs on year and administration. Those are three working rules, not software.

Why the administration is in the key

One client can exist in several administrations at once. Deduplicating on debtor code alone throws whole companies away. Without the administration in the key, the contract dimension yields 13,233 rows on 10,334 contracts. We made that mistake once and then fixed it as a hard rule.

The norm is not one number

Every contract group has its own norm. Glass and floors run differently from cleaning, regie work should cover cost, and sickness counts in the wage norm. A generic margin norm across everything produced 26 of 38 false signals in our own audit. That refinement is sector knowledge, not a parameter. The norms themselves belong to the company and are not on this page.

04, the hardest decision in the whole system

We asked for a closing date. There is none.

We asked the back office for a fixed closing date per period. The answer was a counter-question, what do you mean by closing, our periods are never closed. That turned out to be measurably true, and it forced the most important part of the system.

periodendedinvoiced after period endlast booking
P128-01-202651.6 %14-08-2026
P225-02-202644.3 %14-08-2026
P325-03-202642.6 %21-08-2026
P812-08-20265.5 %27-08-2026
What this means

The first period of the year ended on 28 January and kept growing for seven more months. More than half of that period's revenue was booked after the period ended. Closed is not a state that arrives, it is an asymptote. A system waiting for a closing email waits forever, and a system that trusts the calendar asks questions about figures that are not finished.

1. Ready day

A period may only count from the back office's ready day, measured consistently 32 days after period end. This is a company parameter, every company closes differently and it is one of the four things re-established per connection.

2. Pipeline check

If a draft or a pending invoice is still open for that client and that period, it is not ready, whatever the calendar says.

3. Late-client check

If this client materially booked after its ready day in earlier periods, it gets four extra weeks. For P5 that was 80 known late bookers from P1 to P4.

4. Two limits, separate

Cost-ripe and invoicing-ripe do not run in step. On 17-09 the portfolio was cost-ripe through P8 and invoicing-ripe through P6. The window is also per client, not portfolio-wide.

92
times a question would have been asked too early with the calendar rule alone, 20.6 percent wrong
40
times with all three checks added, 10.1 percent wrong. This is what runs now
88 %
less euro in questions asked too early, measured over P3 to P5, in count from 92 to 40. The difference between a system that helps managers and one that annoys them

Backtest over P3 to P5, material from 5,000 euro. Rule set on 10-09-2026, measured before it was deployed.

05, how it picks which question it becomes

Twenty-five card types, walked in a fixed order.

A client can have an invoicing problem, an absence problem and a rate problem at the same time. The ladder runs from hard and explainable to soft and interpretable. The first type that closes wins, the rest stays on the card as fact, but does not become the question.

  • 01terminationclient or object stopped, costs continue. Hardest, because the end date is in a document
  • 02creditingcredit notes net over the whole series, not per item
  • 03invoicingdraft invoices and completed work orders that have not gone out yet
  • 04rechargingpurchased work without covering revenue on the same contract
  • 05allocationrevenue or cost booked on the wrong contract or object
  • 06scopethe work was reduced or moved, contract continues
  • 07sicknessabsence above the norm, replaced or not, recharged or not
  • 08ratesoftest, because this only becomes the question once every other explanation is gone
  • 09smallbelow the big threshold but above 500 euro, one point to steer on
  • silentchecked and healthy. 503 of 639 monitored client files on 17-09. Silent is an outcome, not an absence
Every type carries three outcomes

Every card type comes with three possible explanations and the matching action, defined in advance. Not because the system knows which one is right, but because the recipient then sees at a glance what kind of answer is being asked. For rate, for instance, the rate does not cover the effort, or the effort is higher than agreed, or the contract can no longer be made to cover cost.

The hard ordering rule

No signal without a contract basis. Without a contract the system does not know what was agreed, so no question comes out, however skewed the figure. That is the oldest rule in the system and it has saved us more often than any threshold.

06, what stands between the measurement and the human

Four gates. All four fail-closed.

A system that sends unchecked questions to managers every night is one bad run away from zero credibility. So four gates stand between the measurement and the human, and every gate stops on doubt instead of letting through.

1. The card gate

Re-checks the card against its own text. Is the headline amount also in the facts? Is there exactly one question? Does the text mention a period outside the window? Is a mandatory field empty? Is the question itself measurable, something the system should have calculated instead of asked? One hit and the card goes into quarantine.

2. The fact gate

Every number in the written text must trace back to the measurement beneath it. A number the model invents does not survive the night. On 17-09 that counter stood at zero across 639 cards.

3. The knowledge check

A card is a question with an offer to help, never an order. Imperatives are blocked. The destination duty lives here too, no signal without a recipient. A card without an owner lands on an owner-less list and is reported, it does not go blindly into the organisation.

4. The window guard

May refine an amount, may never remove a card. Any error in the re-measurement leaves the original outcome standing and flags a measurement error. Fail-closed in both directions.

21
cards stopped in the night of 17-09, from 157 to 136
0
measurement and format errors that did get through, on 639 cards
20 / 20
headline amounts from a random sample of 17-09, recalculated by hand on the source, all twenty exact
68–97
score per item from a second, different model that reviews every reading round before anything is deployed. A gate on building, not on the night
07, one signal from start to finish

One client, six steps, from raw booking to one question.

Real client from the night of 17-09, name and amounts omitted.

01
What it reads
facts per contract groupcontract dimensionproject dimensioninvoiceswork-order lineshours registerripeness per clientdocument archive

Per contract group, per object and per period. Key is debtor code plus administration, window P1 through P8.

02
What it measures

client as a whole 23.8 percent, healthy

contract groupmarginnormverdict
Cleaning14.4 %below the normgap
Glass per month49.2 %above the normsilent
Glass per visit31.8 %on the normsilent
Miscellaneous100 %above the normsilent
03
What it rejects

Glass per month and Miscellaneous run above their norm, Glass per visit sits on it. No question. What remains, cleaning below the norm. The client as a whole runs 23.8 percent and is called healthy in every summary. That is exactly what a total hides.

04
Which question it becomes
terminationcreditinginvoicingrechargingallocationscopesicknessrate

Not stopped, no credit notes, no open drafts or work orders, no third parties without cover, revenue on the right contract, revenue stable, absence below the norm. Seven explanations ruled out, only then rate.

05
The gate
  • headline amount is also in the facts
  • exactly one question on the card
  • no period mentioned outside window P8
  • type, fact, question and amount filled
  • question is not something the system can measure itself
  • recipient known, district manager and project manager found
The 21 that did not make it

Same night, other cards. A period mentioned outside the window. A question the system should have calculated itself. A rate question for a stopped client. A card without a recipient. Those go into quarantine with the reason attached and onto a list, not to a person.

06
What lands with the human

started 03:15, done 04:44

Client A. RATE.

Cleaning runs 14.4 percent over P1 through P8, below the norm for this contract group, while the client as a whole is healthy.

Does the cleaning rate still cover the effort, or should it be revised?

Possible outcomes
  • a. rate does not cover the effort, propose a rate revision
  • b. effort is higher than agreed, back to the contract
  • c. can no longer be made to cover cost, wind down or terminate

owner project manager · 14 working days · escalation district manager above the threshold · source card per period

This client is one of 136 with a question, alongside 503 that were checked and healthy tonight and that the organisation hears nothing about.

08, three real cards from the same night

What it reads, what it thinks about, and what comes out.

Measured on our own back office, night of 17-09. Names and amounts omitted, the reasoning is real.

INVOICING
The money is ready and does not go out
This is what it reads
facts per groupcontract dimensioninvoices in draft statuswork-order lines
This is what it thinks about
  1. 01On Floors per visit there are costs without cover over P1 through P8.
  2. 02But 9 draft invoices are open, the oldest from late April.
  3. 03If those drafts go out, the shortfall disappears. So not a recharging question but an invoicing question.
This is what comes out
INVOICING

Why are the drafts not yet final, and can they go out now for the work on Floors per visit?

owner project manager · escalation district manager · source card per period

RECHARGING
Work purchased, never recharged
This is what it reads
facts per contractcontract dimensionfinal invoicescredit notes
This is what it thinks about
  1. 01One regie contract carries costs and zero revenue in P2 through P8.
  2. 02The client itself runs 19.2 percent and went up 11.6 points. That is not the problem.
  3. 033 credit notes were re-invoiced within 45 days, net no crediting. What remains, the contract.
This is what comes out
RECHARGING

Was that work agreed as non-rechargeable, or should it still be recharged?

owner project manager · escalation district manager · source card per period

TERMINATION
Client gone, costs continue
This is what it reads
project dimension end datefacts after end datetermination fileripeness per client
This is what it thinks about
  1. 01All objects with revenue carry end date 30-04-2026 or are set to stopped in the source system.
  2. 02After that date there are still costs and a remnant of revenue in P6 through P8.
  3. 03Window therefore P1 through P4. A stopped client gets no question about periods that no longer exist.
This is what comes out
TERMINATION

The client stopped as of 30-04, but costs and revenue still appear after that date. Is that correct?

owner project manager · escalation district manager · source card per period

Three different types, the same route. Read from the source, reason until one explanation remains, and one question with amount, owner and deadline.

09, where the sector knowledge lives

131 measurement flags, each one a decision someone once made.

The selector carries 131 named flags that can be switched on and off individually. Every flag has a number, a reason, a date and a GO. That is how a behaviour change can be reverted without touching the rest, and how you can see afterwards why the system does what it does.

Why in code and not in a prompt

A prompt is not testable, not versionable and not traceable. With the termination guarantee we proved that an instruction in a prompt alone is not enough for a critical fact, the model deviated as soon as the context changed. Hard rules have lived in code ever since, and code always beats the prompt.

The system documents its own mistakes

The selector contains 57 notes that literally start with OWN MISTAKE, with the time and what went wrong. That is not tidy code style but it is why the same mistake is not made twice. Alongside it, a register of 61 numbered measurement lessons.

example of a rulewhat it enforces
13 periodsnever divide by 12, P13 can be five weeks
fixed revenuemeasure on fixed revenue, not on total or extra
allocation booking separatean allocation across locations makes the margin look better than it is
group by numbergroup names change per year, match on the number before the dash
invoice status draftdraft is not revenue, even if the source system says invoiced
credit notes netover the whole series, not per note
relation type debtorwithout that filter an employee name surfaces as a client name, GDPR risk
7.645
documents reduced to an arbitration-ready rule set. How a service company works, where the margin sits and where the money leaks
10, the division of roles between code and model

Code fetches the facts. The model does the wording.

A language model makes mistakes, code does not. A sum is right or it is wrong, there is no judgement in it. So the model touches no fact at all. It receives the measurement ready-made and does what it is better at than we are, explaining what is going on in plain language, written so the right person understands it at once and can act on it.

Code fetches

Amounts, dates, keys, balances, periods, norms, thresholds. Deterministic. Same input always gives the same number, today and a year from now.

Code decides

Which signal it becomes, which card type, who the recipient is, when to escalate. Explicit, testable, versionable.

The model writes

The opening line, the explanation, the question and the offer to help. And the tone, because a district manager wants to read something different from a project manager. Fixed settings, always the same answer to the same measurement.

And if the model is off

Then it is a sentence that reads badly. Not an amount that is wrong. That is a very different kind of error, and it is the only kind we have left.

The measurement that decided this

On the same 59 fresh cards the best language-model variant scored 47 right and 3 wrong. The deterministic route scored 52 right and 0 wrong. The model did not win. So code calculates and the model writes, until a measurement proves otherwise.

Why a model swap costs us nothing

When a better model arrives, the sentence gets better and nothing changes in the measurement, the rules or the gates. That is exactly why we dare to deliver this to more companies.

0
tokens leaving the building for a production measurement
11, the document layer

From ledger to tender, one picture per client.

The figures say what is happening, the documents say what was agreed. In every company those live in separate worlds, and that is where the day goes. We read both every night and hang them on the same client key.

what is on the diskcountwhere it lands on the card
Contracts, addenda, terminationsper clienttermination, scope, rate
Indexation letters1,434rate and indexation
Collective invoicing, man-day registers1,217regie, invoicing, peak
Work-order overviews and corrections690invoicing
Credit invoicing, underlying documents272crediting, joinable on note number
Purchase invoice archive98,251third parties and recharging
Agency timesheets8,156hired-in staff and sickness
Quarterly management reports2,082recharging and scope
Tender desk, procurements and references85,039contract structure and new business
Payroll and personnel filesdeliberately kept out, personal data
What this delivers

The card that says a rate does not cover the effort points straight to the change form in which that effort was altered. Not as a reference but as a document, with date and path. Nobody has to search which system it was in again.

What already works

Of the 137 question cards of 15-09, 97 found a candidate record in the client's own folder. Change forms, specifications, indexation letters, terminations, with date and effective date taken from the file name.

What does not close yet

34 of those 137 fail on group structure. One client folder covers several debtors. The source system does know that hierarchy. That is one link that closes this in one go.

And what we measured ourselves

In 68 percent of cases the client field in the knowledge layer holds a truncated client name instead of a real code. Measured across the whole knowledge layer. Exactly why the key has to come from the source system.

1,098,279
files indexed, 417,325 of them substantively useful
530
of 631 clients with their own document folder, together 93.3 percent of revenue
One searchable knowledge layer
every document, on the same client key

Full inventory measured on 15 and 16-09-2026, read-only.

12, the choices and the mistake that preceded each

Every architecture choice here was paid for with a measurement error.

This is the part you never see in a demo. Six choices, with the mistake that forced each one.

Everything local, nothing to the cloud

Not on principle but out of necessity. Personal data in contracts and absence files. Special categories are left out, not masked, because masking leaves the content in place and a person stays recognisable through role, location and date.

Full restore, no incremental export

An export from yesterday that breaks halfway looks exactly like a complete export. A full restore of 11.6 GB is slower and is the only form in which you know for certain what you have.

Stops at the first error

A chain that continues after an error delivers a half truth that looks like a whole one in the morning. Error handling that logs and continues hides errors, one measurement layer failed for 76 nights that way while everything stayed green.

Four numbers per phase, always

Source, processed, errors, status. Done without those four does not exist. Zero rows is never a conclusion but always a reason for a second measurement, because a wrong file pattern produces a false zero just as easily.

The storage scans itself, the chain only collects

The document scan across 1,098,279 files no longer runs inside the chain. The storage runs it in its own time, the night chain collects the finished result and immediately starts the scan for the next night without waiting for it. That phase now takes minutes instead of hours. The cause was measured before we built anything, not the network but a cold metadata cache, so raising the timeout would have been a guess.

One exit, the mailroom

Agents may not send to people themselves. Everything goes through one door with a verification block. Otherwise, after six months you no longer know who sent what to whom, and that is exactly the moment an organisation loses trust.

Sources, 61 numbered measurement lessons in our own register plus 57 OWN MISTAKE notes in the selector.

13, what a second connection costs

The engine is generic. Only the keys and the norms belong to the company.

Debtors, projects, contracts, contract groups, hours, work orders, invoices. Anyone running a back office with that structure has most of the translation done already. What took us over a year is, at a second company, re-establishing four things. In September that was measured, eight working days.

what you re-establishwhy it differs per company
which administrations counttest administrations out, several entities side by side
norms per contract groupevery company calculates glass, floors and regie differently
thresholds and escalationwho gets which question, from which amount upwards
ripeness limitswhen this back office reports a period ready
What does not move along

What stays is everything the year went into, the measurement core, the 131 flags, the card types, the gates, the night chain and the sector knowledge. That is exactly the layer you cannot buy and a software house does not just build.

Pitfall 1

One client sits in several administrations. Deduplicating on debtor code throws entities away. The key is code plus administration.

Pitfall 2

Two debtor numbers side by side, short for reporting and long for contract management, without a mapping table. Matching on name gets 97 of 271 exact. You need to know that before you start.

Pitfall 3

One export yields 108 fewer debtors in one file format than in the other. Same source, two formats, two truths.

Pitfall 4

Thirteen periods, not twelve. Every generic reporting tool that divides by 12 gives a systematically wrong answer.

8
working days for a second company, different sector, its own measurement layer and card routeRead the case →
Finally

The human decides. The system informs.

What you just read runs every night on real data. What is live has been measured, what is not finished we call roadmap and do not present as product. The open items sit in the same register as the working parts, and we are happy to show them.

What we ask

Access to a source system, one domain expert who reviews the first questions, and one first priority that yields money or time.

What we bring

The measurement core, 131 flags, 25 card types, four gates, the night chain and twenty-five years of sector knowledge as testable rules.

What we are open about

The receiving end is the weakest link and we know that from measurement. A question nobody picks up delivers nothing, however good the measurement.

All figures on this page were measured on 17-09-2026 on the running machines.