Vom Gespräch zum Modell — die KI schreibt IFC, ein unabhängiges Werkzeug prüft

Worum es geht: um die Frage, ob ein Sprachmodell aus einer Beschreibung in Alltagssprache ein belastbares Bauwerksmodell erzeugen kann, und wer das prüft. Belastbar heißt hier: ein Modell im offenen Austauschformat IFC, das eine Maschine lesen, prüfen, auswerten und weitergeben kann. In diesem Blog hat ein Sprachmodell bisher Pläne gezeichnet. Pläne sind Bilder, und ein Bild lässt sich ansehen, aber nicht auswerten. Dieser Text geht den nächsten Schritt: Die KI schreibt nicht die Zeichnung, sondern das Modell selbst, über die quelloffene Bibliothek IfcOpenShell. Geprüft wird das Ergebnis von einem Werkzeug, das die KI nicht geschrieben hat, gegen eine Anforderung, die sie nicht kannte.

Der Prüfkörper ist das Haus aus Von der Hand ins Auge. Ein Einfamilienhaus ohne Keller, 11 × 15 Meter, Erdgeschoss und ausgebautes Dachgeschoss mit Kniestock, Satteldach mit 25 Grad Neigung, auf einem Hanggrundstück. Gebaut hat das Modell Claude von Anthropic, in zwei Anläufen: am 15. Oktober 2026 ein erster Bau, am 30. Oktober ein zweiter auf einer Projektvorlage, diesmal mit Dachstuhl, Dachaufbau und Außenanlagen. Gemessen habe ich am 2. November 2026 am zweiten Stand. Ein Vergleich mit einer kommerziellen Autorensoftware gehört nicht dazu; was hier über solche Programme steht, stammt aus der Literatur, nicht aus einer eigenen Messung.

Ein Wort vorweg, weil es beim Zeigen dieses Hauses fast immer als Erstes kommt: Gemessen wird hier die Methode, nicht die Architektur. Das Haus ist ein Prüfkörper aus dem Unterricht, kein Wettbewerbsbeitrag, und es soll niemandem gefallen. Dieselbe Messung ließe sich an jedem anderen Gebäude machen, auch an einem schönen; an den Ergebnissen über Datei, Prüfung und Änderung würde das nichts ändern.

Das Ergebnis in einem Satz: Das Modell der KI ist sauber gebaut, reproduzierbar und lässt sich Zeile für Zeile ändern, und an der unabhängigen Prüfung fällt jede Außenwand durch. Gerade das spricht für den Weg. Ein Modell, das sich prüfen lässt, sagt einem, was ihm fehlt. Ein Bild sagt das nicht.

Vom Bild zum Modell

In Von der Hand ins Auge hat Claude für dasselbe Haus einen Plansatz bis zum Eingabeplan gezeichnet, und ich habe ihn geprüft. Das Ergebnis waren 36 Befunde, acht davon in der Konstruktion. Die Pläne waren, freundlich gesagt, mehr oder weniger richtig, und gefunden hat die Fehler, wer die Zeichnung lesen konnte.

Der Text hatte eine Grenze, die er selbst benannt hat: Das Skript leitete die Pläne nicht aus einem Bauwerksmodell ab, sondern zeichnete jede Ansicht für sich. Ein Plan ist ein Bild. Aus ihm lässt sich keine Mengenliste ziehen, er besteht keine automatische Prüfung, und wenn ein Fenster breiter wird, muss jemand jede Ansicht, in der es vorkommt, neu zeichnen. Was ein Plan zeigt, weiß nur, wer ihn liest.

Genau das soll BIM ändern. Ein Bauwerksmodell trägt neben der Geometrie die Bedeutung: dass diese Wand eine tragende Außenwand ist, aus welchem Material sie besteht, welchen U-Wert sie hat. Und es trägt sie so, dass eine Maschine sie lesen kann. Die naheliegende Konsequenz aus dem Plansatz war deshalb, dasselbe Haus nicht noch einmal zu zeichnen, sondern zu modellieren, und zwar wieder durch die KI, diesmal mit IFC als Ergebnis.

Die These, wie sie in der Literatur steht

Dass ein Sprachmodell aus Text ein Bauwerksmodell erzeugt, ist kein neuer Gedanke. An der TU München haben Changyu Du, Sebastian Esser, Stavros Nousias und André Borrmann mit Text2BIM ein System aus mehreren LLM-Agenten beschrieben, das eine Beschreibung in Programmcode übersetzt. Dieser Code ruft die Programmierschnittstelle eines Autorenwerkzeugs auf, im Prototyp Vectorworks. Ein regelbasierter Modellprüfer ist in den Ablauf eingebaut und hilft den Agenten, Fehler im erzeugten Modell zu beheben. Das Modell entsteht dort im Format des Autorenwerkzeugs; IFC ist ein Export.

Näher an diesem Text liegt eine Arbeit von der EC³-Konferenz 2026. Tobias Sesterhenn, Bharathi Kannan Nithyanantham, Stefan Lüdtke und Christian Bartelt beschreiben einen Text-to-BIM-Ablauf mit eingebauter Selbstprüfung: Für jede Eingabe leitet das System zwei Prüfungen ab, eine Information Delivery Specification (IDS) für die regelbasierte Prüfung und eine vom Sprachmodell geschriebene Prüfung für alles, was IDS nicht abdeckt. Mit dem Ergebnis wird das IFC-Modell in einem geschlossenen Kreis verbessert. Bemerkenswert ist, wer dort die Anforderung schreibt: das System selbst, aus derselben Eingabe, aus der es auch das Modell baut.

Wie weit die Modelle dabei kommen, zeigt ein zweiter Beitrag derselben Konferenz. Der Benchmark BIBIMBAP von Clemens Kujat und anderen stellt 100 Aufgaben zum Anlegen, Lesen, Ändern und Löschen in IFC-Modellen. Das beste getestete Verfahren löst 50,2 Prozent; häufig scheitert es daran, Randbedingungen einzuhalten und räumlich richtig zu schließen, und manche richtigen Ergebnisse entstehen trotz falscher Begründung.

Und es gibt ein altes Problem, an dem jeder dieser Wege vorbeimuss: den Austausch selbst. Huahui Lai und Xueyuan Deng haben 2018 Modelle aus drei Autorenwerkzeugen über IFC in vier Programme geladen und wieder exportiert. Dabei gingen Objekte verloren, Träger wurden zu allgemeinen Platzhalterobjekten, Eigenschaften und Beziehungen fehlten, und eine Datei wuchs auf ein Vielfaches ihrer Größe. Der GeoBIM-Benchmark 2019 von Francesca Noardo und anderen kam zu einem ähnlichen Bild: Nur sehr wenige Programme gaben ein importiertes Modell unverändert wieder aus, und parametrische Geometrie wie Drehkörper, Rohre entlang einer Linie oder Boolesche Körper kam oft als Sammlung einzelner Flächen und Punkte zurück. Das Fazit der Autoren: Erreicht werde wenig Interoperabilität.

Die These dieses Textes hat vier Teile. Erstens: Wenn die KI das IFC-Modell direkt schreibt, lässt es sich von einem unabhängigen Werkzeug gegen eine unabhängige Anforderung prüfen. Zweitens: Weil die IFC-Datei selbst die Quelle ist und nicht das Exportprodukt eines anderen Formats, entfällt die Rundreise zwischen proprietärem Format und IFC, an der die beiden Studien so viel verloren haben. Drittens: Wer IFC direkt schreibt, kann besseres IFC schreiben als ein Export, mit extrudierten Profilen statt Flächennetzen und mit konsequent genutzten Typen. Viertens: Einmal bauen, dann nur ändern. Wird ein Fenster breiter, ändert die KI wenige Zeilen in der bestehenden Datei, statt eine neue zu erzeugen, und alles, was auf andere Bauteile verweist, behält seine Gültigkeit.

Der Aufbau

Die Werkzeuge und wem sie gehören. IfcOpenShell ist eine quelloffene Bibliothek zum Lesen und Schreiben von IFC unter LGPL-3.0-or-later. Bonsai ist die BIM-Erweiterung für Blender aus derselben Gemeinschaft (GPL-3.0-or-later) und arbeitet direkt auf der IFC-Datei, ohne eigenes Zwischenformat. Die IDS-Prüfung übernimmt IfcTester, das Prüfmodul von IfcOpenShell, das auch Bonsai benutzt. Mit dem laufenden Blender spricht das Sprachmodell über das Model Context Protocol; wie das eingerichtet ist, steht in Wie aus Claude Klaus wurde. Die Skripte, die dabei entstanden sind, sind eigene, unveröffentlichte Arbeit: geschrieben von Claude im Gespräch mit mir.

Die Kette hat fünf Glieder. An der Vorlage und am Skript hat die KI mitgearbeitet, an der Anforderung, gegen die geprüft wird, nicht:

1. Eine Projektvorlage mit 234 Bauteiltypen, Materialien und Darstellungsregeln, entstanden in den Wochen davor.
2. Die Beschreibung des Hauses in Alltagssprache und Zahlen: die Vorgaben für den Unterricht und der korrigierte Plansatz aus dem vorigen Text.
3. Ein Bauskript, das Claude geschrieben hat. Es nimmt eine leere Kopie der Vorlage und baut das Haus mit IfcOpenShell, rund 1.600 Zeilen Python. Auf meinem Rechner läuft es in 3,4 Sekunden.
4. Die IFC-Datei, die Bonsai danach öffnet, zeichnet und aus der es die Pläne ableitet.
5. Die Prüfung, in zwei Stufen. Die Schemaprüfung fragt, ob die Datei den Regeln von IFC folgt, unabhängig vom Projekt. Die Bedarfsprüfung fragt, ob das Modell die Information enthält, die ein bestimmter Empfänger braucht. Diese zweite Stufe ist die IDS.

Die Anforderung stammt nicht aus diesem Projekt. Die IDS habe ich im Juli 2026 für Außenwände geschrieben und getestet, für einen anderen Zweck und lange bevor es dieses Modell gab. Sie verlangt neun Dinge von jeder Außenwand mit Wärmedämmverbundsystem, vom Geschoss über die Kostengruppe nach DIN 276 bis zum Nettovolumen. Claude hat sie beim Bauen nicht gesehen.

Der Bauweg ist nicht der eines Anwenders. Ein Skript, das ein Haus über die Programmierschnittstelle anlegt, zeigt, was die Datei enthalten soll, nicht, wie man es in Bonsai mit der Maus anlegt. Für die Frage dieses Textes ist das ohne Belang; für jemanden, der Bonsai lernen will, ist es ein anderer Weg.

Messstand: Gemessen am 2. November 2026 zwischen 9:03 und 9:25 Uhr auf meinem Rechner, in Blender 5.2.0 LTS mit Python 3.13.13, IfcOpenShell und IfcTester 0.9.1a261027. Der Prüfkörper ist der zuletzt gespeicherte Stand des zweiten Baus vom 30. Oktober 2026, von Bonsai 0.9.1-alpha261027 im Schema IFC4 geschrieben, 1.821.615 Byte. Der erste Bau vom 15. Oktober 2026 entstand mit IfcOpenShell 0.9.1a261013 im Schema IFC4X3_ADD2. Gemessen wurde nur lesend, an der Datei auf der Platte oder an Kopien; das geöffnete Projekt blieb unberührt.

Die Messungen

Was die KI selbst geprüft hat

Schon beim ersten Bau am 15. Oktober hat Claude eigene Prüfskripte geschrieben und das Modell damit durchgesehen. Die Schemaprüfung von IfcOpenShell meldete null Fehler, und jedes der 181 Bauteile ließ sich als Geometrie berechnen. Eine Prüfung auf Überschneidungen fand zuerst 39 Paare; fünf davon waren echte Fehler im Modell, die übrigen hingen am Gelände. Danach waren es null. Neunzehn Höhen stimmten auf einen halben Millimeter mit der Vorgabe, die Raumflächen auf einen hundertstel Quadratmeter, und die Georeferenz traf einen Eckpunkt, den ein anderes Programm unabhängig berechnet hatte. Nach allem, was die KI gefragt hatte, war das Modell in Ordnung.

Das Bild über diesem Text stammt nicht aus einem Bildgenerator. Es zeigt dasselbe Modell, in Blender gerendert und über seine Georeferenz auf das amtliche Geländemodell mit Luftbild gesetzt; die Nachbarhäuser kommen aus den amtlichen 3D-Gebäudemodellen. Kein Fenster ist dazuerfunden, keine Dachneigung geschönt. Eine Umgebung zu beschreiben und daraus ein ansprechendes Bild erzeugen zu lassen, wäre leichter gewesen. Prüfen ließe sich so ein Bild nicht.

Zur Gegenprobe habe ich den Render durch einen Bildgenerator geschickt, ChatGPT, mit der ausdrücklichen Anweisung, die Geometrie nicht zu verändern. Das Haus hat er weitgehend gehalten. Ringsum hat er erfunden: Aus dem Schwimmbecken im Nachbargarten wurde ein Teich, aus dem Putzsockel Naturstein, und die Nachbarhäuser bekamen Fenster, Türen und Garagen, die es nicht gibt. Ein zweiter Durchgang mit einer Liste von Korrekturen brachte das Becken zurück, als Betonkasten auf einem Rasen, der das Luftbild überdeckt. Schöner werden die Bilder dabei. Welches Detail stimmt, sagen sie nicht mehr.

Die Prüfung von außen

Am 2. November habe ich den zweiten Stand gegen die Außenwand-IDS laufen lassen. Von den 21 Wänden des Modells greift die IDS acht, genau die Außenwände mit Ziegel und Wärmedämmverbundsystem; der Filter trifft also, was er treffen soll. Alle acht fallen durch. Von 72 Einzelprüfungen bestehen 24.

Vier Angaben fehlen im Modell wirklich: die Kostengruppe, der U-Wert, der Feuerwiderstand und das Nettovolumen. Keine davon hatte jemand im Gespräch verlangt, und keine davon hatten die eigenen Prüfskripte der KI gefragt.

Zwei Zeilen der Tabelle verdienen einen zweiten Blick. Ob eine Wand außen liegt und ob sie trägt, steht im Modell richtig, als Wahrheitswert am Wandtyp. Die IDS fragt danach mit dem Wert TRUE in Großbuchstaben, IfcTester in der gemessenen Fassung erwartet true in Kleinbuchstaben und lässt beide Angaben deshalb durchfallen. Mit true in einer Kopie der IDS bestehen sie an allen acht Wänden; an den übrigen Ergebnissen ändert sich nichts. Woran das liegt, steht im Abschnitt über den Befund gegen die eigene These.

Wird zweimal dasselbe Modell gebaut?

Ein Modell aus einem Skript ist nur dann ein Fortschritt gegenüber einem Gespräch, wenn dasselbe Skript dasselbe Modell erzeugt. Ich habe es zweimal auf je eine frische, leere Kopie der Vorlage laufen lassen. Die beiden Dateien sind gleich groß, aber nicht gleich: Sie unterscheiden sich in 1.693 von 30.696 Zeilen. Jedes neu angelegte Objekt bekommt eine neue weltweit eindeutige Kennung, die GlobalId, die Datei bekommt einen neuen Zeitstempel, und einige Objekte entstehen in anderer Reihenfolge und tragen deshalb andere laufende Nummern.

Inhaltlich sind die beiden Modelle gleich. Ich habe jedes der 685 Bauteile mit Klasse, Name, Typ, Lage, Geometrie und Material vollständig aufgelöst und ohne Nummern und Kennungen verglichen: keine Abweichung, weder zwischen den beiden Läufen noch gegenüber der Projektdatei. Reproduzierbar ist das Modell, nicht die Datei. Das klingt nach einer Spitzfindigkeit und hat eine handfeste Folge, zu der die fünfte Messung kommt.

Stimmen die Mengen?

Mengen hat die KI nur an den zehn Räumen eingetragen, an keinem Bauteil; das hat die IDS schon gemeldet. Aus der Geometrie lassen sie sich trotzdem rechnen. Die vier Streifenfundamente unter den Außenwänden ergeben zusammen 72,96 Kubikmeter, das Fundament unter der tragenden Innenwand 4,595. Eine Handrechnung für dieselben Fundamente, die unabhängig vom Modell für den Unterricht entstanden war, kommt auf 72,96 und 4,60: auf den hundertstel Kubikmeter dasselbe, beim Innenfundament bis auf die Rundung.

Was für ein IFC ist das?

Wie die Datei gebaut ist, sieht man ihr von außen nicht an. Ich habe gezählt, aus welchen Körpern die Bauteile bestehen; ein Bauteil kann aus mehreren bestehen. 612 Körper sind extrudierte Profile: ein Querschnitt und eine Länge, so wie man ein Bauteil auch beschreiben würde. 87 weitere sind extrudierte Profile mit einem Schnitt, etwa die Sparren mit ihrer Kerve. Fenster und Türen teilen sich die Geometrie ihres Typs; 42 Bauteile verweisen darauf, statt sie zu wiederholen. Als Netz aus Dreiecken ist genau ein Objekt geschrieben: das Gelände, das aus einem Höhenmodell stammt und anders gar nicht zu beschreiben ist.

Ebenso systematisch sind die Typen. 316 der 432 Bauteile mit Geometrie hängen an einem Typ. Die 46 Sparren etwa gehören zu einem einzigen Typ Sparren KVH 10/20 C24; Material und Eigenschaften stehen einmal am Typ, nicht 46-mal an jedem Sparren. Die übrigen Bauteile sind solche, für die ein Typ wenig bringt: Putzflächen, die es so nur an dieser Fassade gibt, die Fundamente, die Geländer, die Räume.

Ein Fenster wird breiter

Die fünfte Messung prüft den vierten Teil der These. In einer Kopie der Projektdatei habe ich ein Fenster in der Küche von 126 auf 151 Zentimeter verbreitert: neuer Fenstertyp aus der Vorlage, neue Breite am Bauteil, eine um 25 Zentimeter breitere Öffnung in der Wand.

Geändert haben sich 8 von 30.696 Zeilen. Eine Zeile trägt die neue Breite des Fensters, zwei Zeilen die Zuordnung zu altem und neuem Typ, drei Zeilen die Verweise auf die Geometrie des neuen Typs, zwei Zeilen die beiden verschobenen Eckpunkte der Öffnung. Keine einzige GlobalId hat sich geändert; vorher wie nachher sind es dieselben 2.283.

Darauf kommt es an. Ein Prüfbericht, ein Vorgang im BIM Collaboration Format oder eine Absprache zu einem anderen Bauteil verweist über dessen GlobalId. Bleibt die erhalten, bleibt der Verweis gültig, auch nach der Änderung. Und wer die Datei in einer Versionsverwaltung führt, sieht die Änderung als acht Zeilen, wie in Git als gemeinsame Datenumgebung für IFC. Daraus folgt auch, wie die zweite Messung zu lesen ist: Neu gebaut wird einmal. Danach wird geändert.

Eine Beobachtung am Rand: Die Funktion von IfcOpenShell, die einem Bauteil einen anderen Typ zuweist, brach in der gemessenen Fassung mit einer Fehlermeldung ab. Den Typwechsel habe ich deshalb von Hand gemacht, mit denselben drei Schritten, die die Funktion ausführen soll.

Der Befund, der gegen die eigene These arbeitet

Erstens: Die eigenen Prüfungen waren grün, die fremde war rot. Das ist kein Widerspruch, sondern der Kern der Sache. Claude hat geprüft, ob gebaut ist, was es gebaut hat: Geometrie, Höhen, Flächen, Überschneidungen. Ob etwas fehlt, das niemand gesagt hat, konnte es so nicht finden. Eine Prüfung, die aus derselben Quelle stammt wie das Modell, teilt dessen blinde Flecken. Bei Sesterhenn und Kollegen leitet das System die IDS aus derselben Eingabe ab wie das Modell; unabhängig ist dort das Prüfwerkzeug, die Anforderung nicht. Die Anforderung muss von woanders kommen, oder sie prüft nur, was ohnehin schon gesagt wurde.

Zweitens: Auch die Anforderung ist eine Datei, und sie altert. Dieselbe IDS lief im Juli grün; im November lässt sie zwei Angaben durchfallen, die im Modell richtig stehen. Der Grund liegt nicht im Modell. Im Oktober 2023 hieß es im OSArch-Forum noch, Wahrheitswerte seien in IDS großzuschreiben. Im Mai 2024, kurz vor dem endgültigen Standard IDS 1.0, hat buildingSMART das auf die Schreibweise von XML umgestellt, also klein. Die gemessene Fassung von IfcTester setzt das durch. Ohne die Gegenprobe mit true wäre das ein Fehlalarm geworden, und ein Leser des Prüfberichts hätte das Modell nachgebessert, das richtig war. Was im Juli anders war, das Prüfwerkzeug oder die Testmodelle, habe ich nicht nachgesehen.

Drittens: Schemagültig heißt nicht richtig. Im ersten Bau stand an der Terrasse das Gelände höher als die Unterkante eines Trägers, sodass für die Stütze kein Platz blieb; und für die Firstpfette war im Giebel kein Auflager modelliert. Beides stand in einer schemagültigen Datei. Claude hat beides beim Durchsehen der Geometrie selbst gemeldet; eine Schemaprüfung meldet so etwas nicht, und die Außenwand-IDS fragt nicht danach. IDS prüft Information, nicht Konstruktion. Eine Pfette ohne Auflager besteht jede IDS, die nicht nach Auflagern fragt.

Viertens: Beim Ändern muss jemand die Folgeteile mitdenken. Am verbreiterten Fenster hängen ein Fensterblech, drei Stücke Außenputz in der Laibung, drei Stücke Innenputz und die Öffnungen in den beiden Putzflächen. In der Messung habe ich nur Fenster und Öffnung geändert, und danach stand das linke Laibungsstück im Fenster. Eine Autorensoftware zieht solche Teile oft selbst nach. Hier muss es die KI tun oder das Skript, das sie geschrieben hat, und eine Prüfung auf Überschneidungen muss es kontrollieren. Wenige Zeilen heißt nicht: wenig nachzudenken.

Fünftens: Die Rundreise entfällt nur, solange die IFC führt. Muss das Modell in eine Autorensoftware mit eigenem Format, kommt sie zurück. Und IFC kann nicht alles sagen, was ein Autorenwerkzeug intern kann. Verschieden hohe Schichten in einer Wand gibt es in IFC nicht; das Wärmedämmverbundsystem vor der Deckenstirn musste deshalb ein eigenes Bauteil werden, wo ein Autorenwerkzeug die Schicht einfach höher zieht. Und was den Plan zum Plan macht, Schraffuren, Maßketten, Höhenkoten, entsteht in der Nachbearbeitung und reist mit der IFC nicht mit; das war schon der Befund in Der Quelltext sagt, was das Werkzeug tut.

Die Grenzen

Ein Haus, eine KI, eine Anforderung. Gemessen ist an einem einfachen Einfamilienhaus, gebaut von einem Sprachmodell über mehrere Sitzungen und geprüft mit einer IDS für eine einzige Bauteilart. Was diese IDS nicht fragt, hat diese Messung nicht gefunden.

Die Werte sind übernommen, nicht neu entworfen. Das Bauskript liest die Maße aus dem Plansatz, den ich im vorigen Text korrigiert hatte. Die Firstpfette steht im Modell, weil sie im korrigierten Plansatz stand. Ob sie in einem Modell, das die KI frei aus der Beschreibung entwirft, genauso gefehlt hätte wie im ersten Plan, beantwortet diese Messung nicht.

Keine Autorensoftware gemessen. Die Argumente zur Rundreise und zur Qualität der Datei stützen sich auf die beiden genannten Studien und auf dieses Modell, nicht auf einen Export, den ich selbst nach derselben Änderung erzeugt hätte. Ob ein bestimmtes Programm seine GlobalIds über Exporte hinweg hält und wie viele Zeilen sich bei einer Änderung dort verschieben, ist eine eigene Messung.

Archivierbar heißt hier etwas Bestimmtes. IFC ist als ISO 16739 genormt und eine Textdatei; das Bauskript liegt daneben und erklärt, wie die Datei entstanden ist. Ob beides in dreißig Jahren noch jemand lesen kann, misst niemand heute.

Das Sprachmodell ist nicht Gegenstand der Messung. Ein anderes Modell hätte anders gebaut und anders geirrt. Die Befunde über die Datei, die Prüfung und die Änderung gelten unabhängig davon.

Was daraus für die Praxis folgt

Schreiben Sie die Anforderung, bevor Sie mit der KI reden. Eine Vorlage mit Typen und Materialien und eine IDS für den Empfänger gehören an den Anfang. Was erst im Gespräch entsteht, prüft nur, was im Gespräch schon gesagt wurde.

Behandeln Sie die IFC als Quelle, nicht als Export. Solange das Modell in IFC gebaut und geändert wird, gibt es keine Rundreise, auf der Information verloren geht.

Bauen Sie einmal, und ändern Sie danach. Ein Neubau aus dem Skript ist für den ersten Stand richtig. Jede spätere Änderung gehört in die bestehende Datei, damit die GlobalIds und alles, was auf sie verweist, erhalten bleiben. Und zu jeder Änderung gehört die Frage, was an dem geänderten Bauteil sonst noch hängt.

Legen Sie das Skript neben die Datei. Es ist der lesbare Bauplan des Modells. Zusammen mit einer Prüfsumme belegt es, welcher Stand weitergegeben wurde.

Halten Sie die beiden Prüfstufen auseinander, und prüfen Sie die Prüfung. Die Schemaprüfung sagt, ob die Datei gültig ist. Die IDS sagt, ob sie enthält, was der Empfänger braucht. Ein rotes Ergebnis ist erst ein Befund, wenn klar ist, dass Anforderung und Prüfwerkzeug zueinander passen; eine Gegenprobe kostet eine Minute.

Ziehen Sie Mengen aus dem Modell, nicht aus dem Plan. Aus der Geometrie gerechnet, stimmten sie hier mit der Handrechnung überein.

Räumen Sie vor der Weitergabe auf. Eine Vorlage bringt mehr Typen, Materialien und Profile mit, als ein Projekt braucht; von den 234 Typen nutzt dieses Haus 36. Unbenutzte Typen gehören vor der Weitergabe entfernt. Und nicht jedes Bauteil braucht einen Typ, vor allem wenn es nur in diesem Projekt so vorkommt.

Und das Auge bleibt zuständig. Eine IDS fragt nach Information, nicht nach Konstruktion. Ob die Pfette aufliegt, prüft weiter jemand, der bauen kann.

Wie es weitergeht

Offen sind drei Dinge. Das Modell muss die vier Angaben bekommen, die ihm fehlen, und danach noch einmal gegen dieselbe Anforderung laufen. Beim Ändern müssen die Folgeteile mitgehen, am besten so, dass das Skript sie selbst findet. Und der Vergleich mit einer Autorensoftware steht aus: dasselbe Fenster, in einem kommerziellen Programm verbreitert und neu exportiert, und dann gezählt, was sich in der Datei ändert.

Was bleibt, ist ein Satz. Die KI kann aus einem Gespräch ein Modell machen, das sich prüfen lässt. Ob es stimmt, sagt ihr erst eine Prüfung, die sie nicht selbst geschrieben hat.

Wie dasselbe Haus als Zeichnung geprüft wurde, steht in Von der Hand ins Auge. Warum ein lesbarer Quelltext beim Arbeiten mit einem Sprachmodell den Unterschied macht, in Der Quelltext sagt, was das Werkzeug tut.

Grundlage der im Beitragsbild verwendeten Geobasisdaten: Bayerische Vermessungsverwaltung – www.geodaten.bayern.de (DGM1, DOP20, LoD2), bearbeitet. Lizenz: CC BY 4.0.