How your documents become a knowledge graph.
What reaches us, what it becomes and what you check with it. The building runs automatically, the judgement stays with your experts. No workshop marathons, no modelling by hand.
A construction project does not hand you a model. It hands you everything else.
The clean formats are the exception, not the rule. What is binding usually sits in a document that was never built to be read by a machine.
This is what a single project brings together:
- Schule_IFC4.ifcthe model, when there is one
- Grundriss_final_V2(3).pdfdrawn in CAD, delivered as PDF
- Bill of quantitiesitems, quantities, prose
- Contract, VOB/B, BGBwhat was agreed
- Variation 0034the change after signing
- Site diarywhat actually happened
- Minutes, week 11who decided what
- Fire safety concept60 to 80 pages of prose
- Mailboxthe approval that never reached a drawing
- SharePoint, shared foldersthree revisions, one of them current
Exactly one of these is structured. Everything else carries what is binding, and carries it as prose. A system that only reads the model reads the smallest part of the project.
And every finding is checked against what is binding and publicly available:
- Acts
- Ordinances
- Administrative rules, e.g. ASR
- Permits and their conditions
- Municipal by-laws
- Your own contracts and documents
And it stays with you: the documents are read where they already are. Nothing is copied into a vendor pipeline, and no third party sits between you and your own project.
What happens in between, in four steps:
Connect, do not collect
We attach to your file store where it already is. Nothing is copied, nothing is moved. What arrives is the material listed above: models, drawings, contracts, minutes, email.
Read what is not a data record
From the model the components arrive ready made. From the drawing they arrive through the drawing itself: line, dimension chain, label, from a scan as well. From minutes, contract and email comes what someone said about them.
Bring the same component together
F-14 on the drawing, “the window in room 2.14” in the minutes, item 3 in the variation order: three spellings, one component. From here on it is one node and no longer three search hits.
Attach the rules and your own decisions
Everything that applies is attached to each component: the rule from the list above, the official notice, the commitment from the contract. Plus what your office decided once and what is written in no document.
Every place hangs on its component.
It is not the file that hangs on the component, it is the page, the paragraph, the item. The same fire safety concept hangs on the wall with page 9, on the door with page 12, on the window with page 15. And because every relationship has a name, it can be queried, not just found.
Window F-14 · 6 places from 6 documentsThe run shows one component after another. A click holds one.
- Window F-146 places from 6 documents
- sits in FloorPlan_A-102.pdfRoom 2.14
- FireSafetyConcept.pdf provides forp. 15 · 5.2
- settled in Minutes_week11.docxItem 4
- changed by VariationOrder_0034.docxItem 3
- approved by RE: approval 0034Paragraph 2
- LBO Baden-Württemberg applies to§ 34 (2)
- Door T-045 places from 5 documents
- sits in FloorPlan_A-102.pdfCorridor 2.10
- FireSafetyConcept.pdf requiresp. 12 · 4.3
- settled in Minutes_week11.docxItem 7
- confirmed by RE: approval 0034Paragraph 3
- LBO Baden-Württemberg applies to§ 15 (4)
- Wall W-214 places from 4 documents
- sits in FloorPlan_A-102.pdfGrid line B
- FireSafetyConcept.pdf requiresp. 9 · 3.2
- changed by VariationOrder_0034.docxItem 5
- LBO Baden-Württemberg applies to§ 15 (1)
Three references and still no answer.
One window, three rules, three different reference dimensions: structural opening, glazed area, clear opening. Finding all three places is easy and it gets you nowhere. They only become comparable once it is settled which dimension belongs to this component and which rule applies to it. A language model does not have that structure, so it guesses. The knowledge graph from the section above does have it.
Your project does not wait for your question.
Most systems wait for a question. That assumes you know what to ask for, and in a running project nobody knows that in advance. Two things change it. One reports itself. The other takes in what is written in no file.
What reports itself
The contradiction comes to you, marked in the drawing. You do not have to look for it or put it into words.
What only you know
Your judgement stays in the project. What is written in no document applies from then on to every further check.
Together they make a base that every work stage draws on differently.
Window F-14, room 2.14: two valid rules, two different areas.
ASR A3.4 · sect. 5.1requires 2.30 m², converted to the structural opening.
LBO § 34 (2)requires 1.84 m² of structural opening, one tenth of the floor area.
You say what to check. You get the drawing back, marked.
No query language and no new interface to learn. You pick the rule sets, the check runs across every drawing in the project, and what comes back is a document you can pass on.
“Check every drawing in the project.”
148 drawings · every component against 3 of 5 rule sets. Tick and untick. The drawing answers.
Nothing is silently harmonised. The contradiction goes to the architect, the structural engineer or the building-services planner, whoever owns the component. Their decision is recorded and applies to every comparable case in the project from then on.
What is written nowhere, you decide once.
Folaint shows you the place where something no longer fits. You judge. After that it stands in the project: every further answer knows your decision.
Every project holds knowledge that sits in no file. Why this room is treated differently, which requirement wins in case of doubt, what was agreed in the meeting. It sits in people’s heads, and it leaves with them.
Something changes
A new drawing revision, an email with an approval, a variation order. Folaint reads it where it lies.
The place is shown
No report. The contradiction is marked in the drawing, with the reference that triggers it.
You decide
Confirm, correct, discard. What is written in no file, you say once.
The project remembers
The next check knows your decision. It is not a model on someone else’s server that learns. Your project does.
The same loop runs in conversation. The designer no longer models, they validate: what cannot be drawn from the data they answer once, and the answer stays in the project. That is how the knowledge that only applies in this practice grows.
Nine stages. One knowledge graph.
The structuring happens once. After that every stage asks about the same component differently, with the documents that arise in it. What runs on top, our checks or your own workflows, is your decision.
The contradiction comes to you, marked in the drawing.
What is written in no document, said once and valid from then on.
Design development
Several sets of rules act on the same component at once. Today that is noticed by whoever happens to know both.
- Design 1:100plans, sections, elevations
- Fire safety concept, draftescape routes, compartments, classes
- Cost calculationDIN 276, the budget decision
- Component catalogue, startedU-value, fire resistance, acoustics per build-up
Both valid, both on the same window. You decide.
- Code compliance checkComponent against the rules. On window F-14: LBO-BW § 34 and ASR A3.4, both brought onto the same dimension.
- ResearchWhat the fire safety concept requires for the corridor wall and the door, with the page, on the component instead of on page 12.
- DecisionDuty or extra. Decided once on this component, it applies to every comparable case in the project.
Which window does room 2.14 need?
Two rules, two reference dimensions. Nobody notices the contradiction as long as each one holds on its own.
Both requirements sit side by side on the window, converted onto the same dimension: 1.84 m² against 2.30 m². You decide.