Every hour spent reconciling documents is an hour your project does not move forward.

Two building blocks. First an ontology: a fixed model of what exists in a construction project at all (building elements, rooms, rulings, deadlines, trades, the people involved), and which relationships between them are permissible. Second a graph database that stores your project knowledge in exactly that shape: not as blocks of text, but as named points with named connections. What separates this from a language model on its own is the obligation to a form. A model without an ontology has no rule about what belongs together, so it answers plausibly. With an ontology it is fixed that a ruling without a date, a source and an author is not a ruling. Every answer can therefore be traced back to those details. When they are missing, you see it immediately instead of merely suspecting it. That is why ontologies start to matter the moment AI has to be reliable rather than just eloquent. Which language model runs underneath is deliberately interchangeable: our layer is the ontology and the graph, not the model. That comes from an AI provider of your choice.

The usual build breaks documents into snippets and fetches the most similar ones. That works as long as the answer sits inside a single snippet. Your questions are usually multi-step: which standard applies to this room, was the ruling on it changed later, and does that change affect the trade going out to tender next week? Similarity search finds three passages that know nothing about each other. The graph walks the path instead: from the room to the ruling, from the ruling to the change, from the change to the affected trade. And it can show each step separately. In published comparisons, graph-based methods lead vector search clearly on exactly this kind of chained question. On simple lookups there is little in it. So we use both, with the structure leading.

Nothing to clash detection. Two pipes running through each other in the model is something your tool finds reliably, and we have no intention of improving on that. The point is that this is only one kind of conflict, and the rarer one. Three others are more common: two regulations size the same building element differently. The client's specification demands something other than the standard does. Or the standard requires maintenance access that the available ceiling height does not allow. None of the three is a geometric conflict, and all three are decided between a drawing and a text. That is where we work: not geometry against geometry, but geometry against what the standards, contracts and design concepts say about it.

Especially then. A fire strategy is typically 60 to 100 pages of prose with the requirements scattered across the rooms. Which wall needs which fire resistance rating, which service may pass through an escape route, which cables need to keep functioning: that is written in sentences, not in fields. Which is precisely why no model-checking tool touches it: they all assume a cleanly classified model. In refurbishment and in mid-sized practices the basis is often a 2D drawing or a PDF, not a model. We read both and hang them on the same building element: the statement from the strategy and the service run from the drawing. What stands out we put forward as a candidate. Your specialist engineer decides.

The comparison itself. Shop and installation drawings arrive in the manufacturer's conventions, your detailed design in yours. Today somebody reads both side by side: connections, pipe sizes, routing, fire stopping. Pure document-against-document work, carrying liability, and the German fee scale prices it separately: if checking the shop and installation drawings is not commissioned, § 55(2) HOAI reduces the fee for work stage 5 by 4 percent. Folaint hangs both sets of drawings on the same building elements and puts up every discrepancy with its source. Where four eyes check today, the first pair can be this machine: it misses no item and it is not tired on page 60. The second pair stays your specialist engineer, who decides what is a real discrepancy and what is a permissible variant.

You are. Folaint changes nothing about that. This is not a contract clause but the legal position: design services are owed as a work contract. Whoever releases a result is answerable for it, regardless of whether a person or a machine made the mistake. Which is exactly why Folaint is built to decide nothing and release nothing. It puts things forward: here is a contradiction, here are the two documents, here are the passages. What changes is how complete the check is and how long it takes. Who signs at the end does not change.

Because the graph holds not only what applies but where we got it. Every connection carries which document it was read from, at which point in that document, with which date, and in which processing step it came about. On top of that there are two timelines: when something applied in the project, and when we learned about it. That answers the question actually asked in a dispute: what was known at that point in time? So an answer here is not running text but a path across evidenced points. Every single connection in it can be traced back to its source. That is the proof itself, not a note claiming there is one.

Processing is GDPR-compliant in data centres in Germany, on the basis of a data processing agreement under Art. 28 GDPR. Your project data is not used to train models, neither by us nor by third parties. Where the client or your own policy requires it, operation in your own environment is possible; that comes up regularly on public projects and is therefore designed in from the start. ISO 27001 certification is in preparation and firmly on the roadmap. We deliberately do not write that we already hold it.

No. Folaint is not another tool beside your tools, it is the layer beneath them. It reads what your project produces anyway: folders, emails, drawings, minutes, contracts and, where one exists, a BIM model, and it reads them where they already sit. Nobody has to rename files, copy them into a new system or change format. A complete BIM setup is explicitly not a prerequisite: what most practices actually hold is mostly 2D and spreadsheets. That is precisely where Folaint starts. And we do not start with the whole practice, but with one process.

Yes. We are in a pilot with a multidisciplinary practice, on real project data, not a demo set. The scope is deliberately tight: one process where it can be measured whether the answers are right and whether the time saved actually shows up in the working day. Further pilots are being prepared. We name names only once our partners release them; in conversation we can say more about the setup and what we have learned.

Two parts, because two different things take work. Once at the start: bringing the ontology onto your practice: your trades, your document types, your naming, the logic of your filing. That is the step that turns your existing storage into a graph you can rely on. It is setup, not a licence fee. Then ongoing: keeping the graph current while the project runs, so every new ruling, every design change, every variation. Actual figures depend on project size and data volume, which is why they belong in a conversation rather than on a price list.