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 condition recording. Which defect sits on which element and what condition rating follows from it is something your system handles reliably, and we have no intention of improving on that. The point is that condition is only one of several statements about the same element. Three others sit beside it, and none of them lives in a field: what the planning consent imposes at that location. What the original structural calculation says about the reinforcement. What the last design team meeting ruled on it. None of the three is a condition record, and all three are decided between an element and a text. That is where we work: not condition against condition, but the element against what the consents, calculations and minutes say about it.

Especially then. A structure from the sixties comes with its original structural calculation, formwork drawings, a structure record book and thirty years of inspection reports, and most of that is paper, scans or prose. Which reinforcement sits where, which condition from which consent still applies, which repair was carried out when and why: that is written in sentences and drawings, not in fields. Which is precisely why no model-checking tool touches it: they all assume a cleanly classified model, and for this structure one never existed. We read both and hang them on the same element: the statement from the consent and the cross-section from the drawing. Where a scan is no longer legible, we say so instead of guessing. What stands out we put forward as a candidate. Your specialist engineer decides.

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.