From X83 to X84 in one afternoon: a DatumOS pilot, screen by screen
A synthetic school-renovation tender goes through DatumOS from GAEB X83 to a checked X84: import, dossier, scope, matched and priced positions, the bid file. Then what a four-to-six-week pilot asks of you, and where the AI is allowed to speak.
The X83 arrives on Monday. The X84 has to be with the client by Friday, priced, in the structure they sent, with nothing retyped and nothing that their software will reject. Between the two sit the seven stages every estimator knows: open it, retype what did not import, read the package, interpret each position, price it, write the prices back, check nothing broke.
This post is every screen between Monday and Friday, for one tender, in DatumOS. At the end is what a pilot on your own tenders looks like, week by week, and what we ask of you.
What arrived
One file: 01_sanierung_grundschule.x83, GAEB DA XML 3.3, nine positions in three titles. Site setup, PVC window elements, aluminium exterior doors. An opening date in the header, and no PDFs, which matters later.
Stages one and two, opening the file and retyping what did not import, are one upload.

Nine positions fit on a screen, which is why this tender was chosen. To be clear that the same path holds at real size: the 300-position hospital tender from the same sample set was imported and matched against the catalogue in under ten seconds on our development machine. The full five-step run, with the model reading each position, is what the screen says: typically one to four minutes.
Everything in this post is synthetic. The tender was written by our own engine so that all of it can be shown, with an invented client and made-up prices. The bidding company, its 24-article catalogue and its price rules are demo data. No pilot company's tender appears here, and none will without their say-so.
Stage three: the dossier
The dossier is the tender package read for you: deadlines, client, submission form, eligibility and exclusion criteria, contract flags, alternative positions. Every fact carries a chip naming the document it came from, so it can be checked rather than trusted.

This is the dossier on the worst possible input, a bare X83, and it says so. The verdict is Review, not Go, with the reason printed: no eligibility requirements found, no submission form found. A bare X83 does not contain them. They live in the preliminary remarks and the contract terms that come with the bill of quantities, and this tender arrived without those PDFs. When they are part of the package, the same sections fill from them, with the page cited.
Where the model is allowed to speak
We build LLM applications for a living, the kind that have to be right on messy, high-stakes data, and the dossier is where that discipline shows. The facts are extracted deterministically first: header fields, position counts, dates, the patterns a contract clause follows. The model comes second, writes the narrative for each section, and may only cite sources that are shown on the page. When nothing was retrieved for a section, it says "nothing found in the documents" instead of answering. A dossier that had produced a confident Go from this file would have been dangerous. One that tells you what is missing before you have read a page is the point.
Stage four, first half: what is yours to bid on
Before any position is interpreted, each one is classified as in your scope, uncertain, or another trade. A real bill of quantities for a school mixes masonry, electrical work and windows, and a window maker prices a tenth of it. The scope filter is the difference between reading three hundred positions and reading thirty. On this tender all nine are in scope, and the four counters at the top of the review screen are where the estimator starts on a mixed one.
Stages four and five: matched and priced
This is the judgement work, and it stays with the estimator. The software proposes; the estimator decides.

Five of nine positions were matched to catalogue articles from a demo catalogue of 24. Each match shows the article code and a confidence label, and the label is worth reading: the fixed glazing under the PVC windows title was matched to an aluminium article, flagged Low. That is the catalogue talking, not the tender. Matching quality is a function of how your articles are described and which attributes they carry, which is why the first pilot weeks are spent on the catalogue and its rules rather than on the software. In a pilot that row is corrected in one click, and the rule that caused it is fixed so it does not recur.
The other four had no catalogue match: site setup, two window sills, door closers. The estimator typed four unit prices, which took about a minute.
The matched prices are not a lookup. They come from the company's price profile: material cost with markup, labour hours at the labour rate, overhead, profit and risk, plus rules such as a size deviation or an RC 2 surcharge. The breakdown is stored per position and written into the bid file as unit-price components, so the client sees material, labour and other, as DA XML allows.
Stages six and seven: the X84, checked
The quote is generated from the review, not re-entered.

Bid readiness answers the two questions a strict procurement platform asks: are all price-required positions priced, and is the structure the client sent still intact. Both are checked before the download button does anything. Stage seven, the anxious re-check, is what this replaces: the position numbers cannot drift because they were never re-entered.
We then dropped the downloaded X84 into the free GAEB-Check, the way the client's estimator would check an incoming bid.

Recognised as a bid, declared total equal to the recomputed total, position numbers unique, all positions counting toward the total, nothing to ask the sender about. One detail for the curious: a bid carries prices, not texts. The X84 schema makes the description optional and has no unit on a position at all, because the client's software keeps both from its own X83 and takes only your prices. The check knows that and does not mark a bid down for it.
What goes where afterwards
The X84 goes back into whatever the client uses. It is DA XML 3.3, validated against the official schemas, and every current AVA package reads it. On your side, the catalogue comes in from the Excel price list you already have, one upload, and the internal PDF carries the cost breakdown for your own records. Handing the finished bid to your ERP as Excel is next on the roadmap.
What a pilot looks like
The example above is one tender in an afternoon. A pilot is your tenders over four to six weeks, free, with us setting up the catalogue and rules with you. The terms are the ones on the product page: a monthly price per estimator seat afterwards, unlimited tenders, no per-document fee, and a founder rate fixed for twelve months for companies that continue.
This is how we run it.
Week one: scoping and setup. One call to understand what you bid on and what you bid with. From your catalogue or price list we build the catalogue and the first price profile, and we load three to five of your recent tenders, GAEB files and the PDFs that came with them.
Weeks two to four: live tenders. Your estimators run real tenders through it as they arrive. We sit next to them, remotely, and fix what is wrong: a match that misfires, a rule that prices the wrong thing, a dossier section that missed a clause. This is where the product gets better, and it is why the first companies get the founder rate.
Weeks five and six: the measurement. The seven stages timed on your tenders, before and after. You keep the numbers whatever you decide. When pilot companies allow it, those numbers will appear on this blog with the method attached, and not before.
What we need from you: the recent tenders, the price list, and one estimator with about two hours a week. What you need from us is on the product page under security: EU hosting, no training on your data, a data processing agreement on request.
Who you are dealing with
Four people, all of whom write the code. We build LLM applications in production, and the open-source engine that reads and writes the GAEB files here, pyGAEB, is ours and MIT-licensed, so what the platform does to your file can be inspected by anyone. There is no sales team. The people on the pilot call are the people who fix the match that misfired.
If you price GAEB tenders and want to see your own file on the other side of stages one and two, request a pilot. We reply within two working days.
Was this article helpful?
No cookies, no tracking — one vote per reader per day.
Comments
Comments are reviewed before they appear.
Loading comments…