# Wie es funktioniert ## Der Lebenszyklus eines Gebäudes auf Magma ### 1. Eigentümer erstellt den Digital Twin Token Ein Gebäudeeigentümer (oder sein Asset Manager) abonniert und erstellt den DTT® für sein Gebäude. Dazu gehören: * Eingabe grundlegender Gebäudeinformationen: Name, Typ, Adresse, Grundfläche, Baujahr, Eigentümerdetails und MwSt. * Optionale Angabe von 3D-Modellanforderungen für jede Gebäudeebene * Überprüfung des Preisangebots und Verbindung einer **Gebäude-Wallet** (Venly/VeChain) * Abschluss der Stripe-Zahlung zur Aktivierung des Abonnements Das Gebäude startet im Status **Entwurf** und schreitet zu **Nicht geminted** fort, sobald die Zahlung bestätigt ist. ### 2. Stakeholder werden eingeladen Der Eigentümer lädt jeden Fachmann ein, der am Lebenszyklus des Gebäudes beteiligt ist. Jede Einladung erstellt eine **Stakeholder-Vereinbarung**, die die Rolle und Berechtigungen der Person für dieses Gebäude definiert. Stakeholder-Typen reichen von Architekten und Statikern bis hin zu Mietern, Beobachtern und Finanzinstituten — über 50 spezifische Typen in 8 Kategorien. Einladungen kommen per E-Mail mit einem Link zum Annehmen oder Ablehnen. Nach Annahme erhält der Stakeholder Zugang zum Gebäude basierend auf seiner Rolle. ### 3. Daten werden beigesteuert Je nach ihrer Rolle tragen Stakeholder Daten über drei Oberflächen bei: **Data Room** — Dokumente in die entsprechende Ebene und Kategorie hochladen. Die Plattform zeigt, welche Dokumenttypen für Ihre Rolle erwartet werden, und hebt hervor, welche fehlen. Jeder Dokumenttyp hat benannte Uploader-Rollen und Validator-Rollen, pro Dokumenttyp definiert. **BIM 3D Viewer** — Ingenieure und Architekten laden IFC-Modelle für ihre Gebäudeebene hoch. Jedes Objekt im Modell kann dann mit strukturierten Daten angereichert werden: Identifikation, Materialien, Abmessungen, Zustand, Compliance-Bewertungen, Lebenszyklus-Daten, Finanzdaten, IoT-Verbindungen und mehr. **Scan Viewer** — Gutachter und Diagnostiker laden E57-Punktwolken-Scans hoch. Die KI-Pipeline segmentiert den Scan automatisch, klassifiziert jedes Element und gleicht Elemente mit vorhandenen BIM-Objekten ab, wo möglich. ### 4. Validatoren genehmigen die Daten Jedes Datenstück durchläuft einen **Validierungsworkflow**. Bei Dokumenten hat jeder Dokumenttyp einen primären Validator, einen optionalen sekundären Validator und einen optionalen tertiären Validator. Alle konfigurierten Validatoren müssen genehmigen — eine einzige Ablehnung sendet das Dokument mit einem Grund an den Uploader zurück. Bei BIM-Datenfeldern löst jede Änderung eine Change Request aus. Benannte Validatoren prüfen den vorgeschlagenen Wert und stimmen zu oder lehnen ab. Alle Validatoren müssen zustimmen. Validierte Daten erhalten den Status **Validiert** und sind für das Minting geeignet. ### 5. Der DTT® wird geminted Sobald ausreichend validierte Daten angesammelt sind, initiiert der Eigentümer oder Asset Manager das Minting. Ein 13-stufiger Prozess läuft auf der Blockchain: * Alle validierten Dokumente und BIM-Felder werden mit der Chain synchronisiert * Jedes Element erhält eine Token-ID innerhalb des ERC-1155 DTT®-Vertrags des Gebäudes * Der kryptografische Hash jeder Dokumentversion wird an das Hash-Array seines Tokens im HashStorage-Vertrag angehängt * MRT-Token-Belohnungen werden für jeden Mitwirkenden und Validator berechnet * Belohnungen werden finanziert und an Stakeholder-Wallets übertragen * Die DTT®-Ebene wird erhöht Das Gebäude erhält eine eindeutige Blockchain-Adresse. Seine vollständige Datenhistorie ist jetzt dauerhaft und öffentlich überprüfbar. ### 6. Der DTT® entwickelt sich Gebäude verändern sich. Neue Mieter ziehen ein, Geräte werden ersetzt, Zertifizierungen erneuert. Jede Aktualisierung folgt demselben Workflow: Hochladen → Validieren → Minting. Jeder neue Hash wird an den vorhandenen Token angehängt — die vollständige Geschichte wird erhalten, nie überschrieben. Dokumente mit Gültigkeitszeiträumen (wie Versicherungspolicen oder jährlich ablaufende Diagnoseberichte) generieren Aufgaben, die Stakeholder daran erinnern, erneuerte Versionen vor Ablauf hochzuladen. *** ## Wie Validierung funktioniert ### Dokumentvalidierung ``` Hochladen → PENDING_VALIDATION → Alle Validatoren genehmigen → VALIDATED → geeignet für Minting → Ein Validator lehnt ab → REQUIRING_ACTION → Uploader korrigiert und sendet erneut ein → Korrigierte Version → PENDING_VALIDATION (Zyklus wiederholt sich) ``` Nach Minting: MINTED\ Nach Ablauf der Zeit: EXPIRED (generiert eine UPDATE\_EXPIRED\_DOCUMENT-Aufgabe)\ Nach Validierung einer neuen Version: REPLACED oder CORRECTED ### BIM-Feldvalidierung ``` Benutzer bearbeitet Feld → Change Request erstellt → Validatoren benachrichtigt → Alle Validatoren genehmigen → Feld PENDING_TO_MINT → geminted = On-Chain-Datensatz → Ein Validator lehnt ab → UPDATE_REJECTED_3D_MODEL_FIELD-Aufgabe dem Anforderer zugewiesen ``` *** ## Wie die Blockchain Daten aufzeichnet Magma verwendet drei Smart Contracts pro Gebäude auf der VeChain-Blockchain: 1. **DTT Factory** — Ein einziger gemeinsamer Vertrag, der neue DTT-Verträge bereitstellt, wenn Gebäude erstellt werden 2. **DTT Contract (ERC-1155)** — Einer pro Gebäude. Enthält mehrere Token-IDs — eine pro Dokumentdateiversion und eine pro BIM-Objektversion 3. **HashStorage Contract** — Einer pro Gebäude, gepaart mit dem DTT. Speichert ein Append-only-Array von Hashes pro Token-ID Wenn Sie eine zweite Version eines Dokuments hochladen, wird ein neuer Hash an das Array derselben Token-ID angehängt. Der Hash der Originalversion wird nie überschrieben. Sie können jede historische Version überprüfen, indem Sie den Hash an seiner Indexposition abfragen. Die DTT®-Adresse ist öffentlich. Jeder kann `/dtt/[Adresse]` besuchen, um die vollständige Token-Hierarchie des Gebäudes, alle geminteten Elemente und ihre On-Chain-Hashes einzusehen. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.mymagma.com/magma-documentation/de/einfuhrung/how-it-works.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.