Was das hier ist

Das vollständige Produktkonzept für die immorise-Plattform: 134 Bildschirme in 22 Bereichen, 154 entschiedene Regeln, die Abläufe als Klickwege, das Rechtemodell und das Bezahlmodell. Alles auf einer Seite, damit ein Entwickler einen Bereich bauen kann, ohne nachzufragen.

In 60 Sekunden

immorise ist die digitale Akte eines Gebäudes. Ein Scan wird zur begehbaren 3D-Tour mit Punktwolke; darin wird gemessen, geschnitten und markiert. Was dabei entsteht, hängt nicht irgendwo, sondern an einer Aktivität — der Einheit, in der auf der Plattform gearbeitet wird: Aufgabe oder Information, mit Frist, Person und Ort im Gebäude. Dokumente liegen im Datenraum, mit Rechten, Fassungen und Protokoll. Erledigte Aktivitäten speisen das Zwilling-Wissen — Kerninfos zum Gebäude, automatisch übernommen und mit Quelle belegt.

Wo man anfängt

• Sehen, wie es aussieht → Reiter Bildschirme. Für Vollbild in Druckqualität das PDF immorise-2030-entwurf-plattform.pdf.
• Verstehen, wie es funktioniert → Reiter Abläufe. Jeder Weg mit Ziel, Schritten, Abbruchweg und Fehlerfall.
• Nachschlagen, was entschieden ist → Reiter Regeln, durchsuchbar.
• Etwas bauen → Abläufe + Rechte + Regeln. Was dort nicht steht, ist nicht entschieden — dann fragen.

Der Aufbau der Plattform

Links eine feste Navigation: Cockpit (was heute wichtig ist), Portfolio (alle Objekte), darunter das offene Projekt mit seinen Bereichen, und unten die Organisation (Team & Rollen, Integrationen, Abrechnung). Im Projekt: Übersicht · Modell · 3D-Tour · Aktivitäten · Datenraum · Zwilling-Wissen.

Wie dieses Konzept zu lesen ist

Die Oberfläche ist auf Deutsch, und das bleibt so. Sie ist das Produkt — ein Facility Manager sieht deutsche Knöpfe. Die englische Fassung inklusive Oberfläche ist beschlossen und kommt nach der Abnahme der deutschen, mit einem Sprachumschalter in derselben Datei, damit nichts auseinanderläuft.

Wer was bekommt

Alle 134 Bildschirme

Gruppiert nach Bereich, in der Reihenfolge, in der man sie benutzt. Klick auf ein Bild zeigt es groß.

Login & Onboarding

12

Login, Signup mit Consent, Verify, Account-/Mandanten-Wahl.

Add-Flow

10

Objekt hinzufügen: Absicht → Scan-Weiche → Bezahlen → Verarbeitung → Fertig. Dazu der Nachscan: einen Teil zu einer vorhandenen 3D-Tour ergänzen oder tauschen, mit beiden Kostenfolgen.

Cockpit

3

Startbildschirm — Portfolio-Gesundheit, „was braucht dich heute“, Zwilling-Live.

Portfolio

6

Alle Objekte in drei Ansichten — Galerie, Liste, Karte (Koordinaten liegen im Backend vor).

Projekt-Details

4

Ein Objekt: Zwilling-Bühne, Gebäudedaten, Aktivitäten, Team, Lage.

Viewer · Ansehen (3D-Tour)

6

Weg A — durch das Gebäude gehen und etwas finden. Ein Weg pro Datei, in Ablaufreihenfolge (V25). Abläufe VA1–VA5.

Viewer · Messen

7

Weg B — eine Länge oder Fläche wissen und behalten. EINE Mess-Werkzeugleiste, überall dieselbe (V13/V16). Abläufe VB1–VB7.

Viewer · Schneiden

6

Weg C — hineinsehen, wo keine Kamera hinkommt. Ein Werkzeug, drei Arten; danach greift die normale Mess-Leiste (V16). Abläufe VC1–VC5.

Viewer · Ebenen & Fachmodelle

4

Weg D — steuern, was man überhaupt sieht. Punktwolken-Teile und IFC-Fachmodelle in einer Liste (V21–V24). Abläufe VD1–VD5.

Viewer · Modell (BIM)

9

Weg E — ein Bauteil und seine Daten. Autodesk-Forge-Rahmen im immorise-Look. Abläufe VE1–VE5.

Viewer · Objekte

1

Weg F — was im Gebäude verbaut ist. Getrennt von „Ebenen": zwei Fragen, zwei Panels (V24). Abläufe VF1–VF4.

Aktivitäten

17

Erst der Blick über das ganze Portfolio, dann die Arbeitsliste im Projekt — plus die Wege, die aus dem Rechtemodell dazugekommen sind: Zuständigkeit (gesperrt mit Grund, immorise als Eintrag in derselben Auswahl), der Gastzugang von außen, die Aktivität aus einer Messung und die vier Zustände als eigene Bildschirme.

Aktivität erstellen

4

Anlegen inkl. Validierung und Verortung direkt am 3D-Bauteil.

Datenraum

18

In Ablaufreihenfolge: hineinbringen → ansehen → unterschreiben → freigeben → Rechte prüfen → Nachweis → Sonderfall Deal-Raum.

Zwilling-Wissen

2

Das aus Aktivitäten wachsende Gebäude-Gedächtnis — mit Korrektur-Fluss.

KI-Assistent

3

Sparkle-Assistent auf jeder Seite. Consent → Chat mit nachprüfbaren Quellen → Datenschutz.

Reports

2

Report-Center + automatischer Wochen-Report (regelbasiert, ohne KI, jede Zahl nachprüfbar).

User-Management & Rechte

11

In der Reihenfolge des Klickwegs: Nutzerliste, Nutzer anlegen, der Abzweig in den Rollen-Editor (im Haus und von außen), Projekte, dann Katalog, Start-Rollen, Gruppen und die eigene Sicht. Ordner freigeben geht im Datenraum weiter.

Kunden & Übergaben

4

Partner-Portal: Projekte an Kunden übergeben, gemeinsamer Zugriff.

Integrationen

1

Offene Anbindung statt Katalog: verbundene Systeme, die drei Wege (REST-API · MCP · Webhooks/Data-Bridge, bidirektional) und ein Anfrage-Weg.

Abrechnung

1

Ein Verarbeitungs-Guthaben statt vieler Kontingente — Verbrauch, Zahlungsart, Rechnungen (R136).

System & Global

3

Drei eigene Themen: global suchen und springen (⌘K) · was mich erreicht (Glocke) · was mich erreichen soll (Einstellungen).

Die Abläufe als Klickwege

Jeder Weg mit Ziel, den Schritten, dem Abbruchweg und dem Fehlerfall. Die Kennungen (VB1, DA3, AA2 …) sind feste Bezeichner — sie bleiben, auch wenn Wege dazukommen.

Modell und 3D-Tour — sechs Wege

Was das hier ist: Für jeden Weg durch den Viewer: Ziel, Schritte, Abbruch, Fehler, Ergebnis — dieselbe Form wie im Datenraum (Doku 63) und bei den Aktivitäten (Doku 67). Auftrag ist Doku 71, Abschnitt 2.

Warum zuerst schreiben, dann zeichnen: Sechs ' 25 Punkten (V15–V20) sind keine Knöpfe, sondern Wege. „Wie speichere ich das?" lässt sich nicht mit einem Knopf beantworten. Erst wenn der Weg steht, ist klar, welcher Knopf überhaupt gebraucht wird — und welche drei wegfallen. Grundlage: die Referenzbilder in 29-viewer-referenz/ (51 Standbilder aus die Geschäftsführung' eigenen Aufnahmen des heutigen Viewers), der Bauteil-Katalog Doku 55 Abschnitte B3/B5/B6 und die Entscheidungen Doku 62.

0 · Die sechs Wege — und warum es genau sechs sind

Der Viewer hatte 28 Bildschirme in sieben Dateien, sortiert nach Technik (Punktwolke, BIM, Tour). die Geschäftsführung arbeitet aber nicht nach Technik, sondern nach Absicht. Deshalb sechs Wege, jeder eine Datei, jeder in Ablaufreihenfolge (V25, Q3, QQ1):

Was dadurch verschwindet: die Datei „IFC-Modelle" (zeigte dasselbe Panel wie „Ebenen" — V24) und die Trennung „Tour-Messen" / „BIM-Messen" / „Split-Messen" / „Schnitt-Messen", die vier verschiedene Mess-Werkzeugleisten hervorgebracht hatte (V16).

0.1 · Was für alle Wege gilt

Damit es unten nicht dreißigmal wiederholt wird. **Jeder dieser Punkte ist gleichzeitig ein Befund aus ahinter.

Bedienung

1. Das Werkzeug im linken Rahmen ist der Schalter. Anklicken schaltet ein, nochmal anklicken

schaltet aus. Es gibt kein „Abbrechen" und kein „Fertig" in einer Werkzeugleiste (V19). Prüfbar: In keiner .vctx steht mehr das Wort „Abbrechen" oder „Fertig".

1. Ein Menü hängt an seinem Symbol — mit Abstand und einer Spitze, die darauf zeigt. Nicht am

Bildschirmrand, nicht halb über der Werkzeugleiste (V1, V2, V3; Vorlage: das Ebenen-Panel, V4). Technisch: die Spitze wird nicht mehr je Bildschirm ausgerechnet, sondern das Menü hängt im Symbol — dann kann sie gar nicht verrutschen.

1. Oben mittig = Zustand, unten mittig = Bedienung. Nie beides doppelt (Katalog B5).
2. Symbole statt Wörter, Wort im Tooltip. Wo der Viewer sonst überall mit Symbolen bedient wird,

darf ein einzelner Umschalter nicht aus Text bestehen (V7, V8).

1. Der gewählte Zustand steht in der Leiste, nicht nur im Menü. Begründung von Menü wählt, Leiste zeigt (V6).
2. Ein Regler ist ein Regler. Wo ein Wert stufenlos ist (Punktdichte, Panorama-Abstand,

Deckkraft, Splitscreen), gibt es keinen Auswahlkasten (V11), und überall denselben Regler (V12).

1. Die Karte gehört sich selbst. Klein (Ecke) oder halb (Split) wird an der Karte umgeschaltet,

nicht in der Werkzeugleiste; die Größe im Split macht der Splitscreen-Regler. Es gibt kein „Karte groß" (V17, V18).

Messen (V13, V16)

1. Es gibt genau eine Mess-Werkzeugleiste — im Panorama, in der Punktwolke, im Modell, im 2D-Plan,

im Split und im Schnitt. Reihenfolge fest: Messen │ Auswählen · Abstand · Höhe · Winkel · Fläche▾ │ Hilfslinien │ Meter▾ │ Messungen n▾

1. Wählbar ist die Einheit — mm · cm · dm · m, voreingestellt Meter. Sie fehlte in zwei der vier

alten Mess-Leisten und ist zurück. Die Anzahl der Nachkommastellen ist nicht wählbar: immer zwei. die Geschäftsführung am 03.08. zu seinem eigenen Punkt V13: (→ R106).

1. Hilfslinien sind die Funktion, das Einrasten kommt mit ihnen. Ein Symbol, Tooltip

„Hilfslinien", an = Symbol aktiv gekennzeichnet — genau wie beim orthogonalen Messen. Aus: keine Hilfslinien sichtbar und kein Einrasten. „Freies Messen" fällt weg; eine Strecke ist ohnehin frei messbar (→ R96, präzisiert 03.08.).

1. Kalibrieren erscheint nur im 2D-Plan. Ein Plan hat keinen Maßstab, bis man ihm einen gibt;

eine Punktwolke hat ihn immer. Das ist der einzige kontextabhängige Zusatz in der Leiste.

Ergebnisse (V14, V20; Katalog B5)

1. Ein Messergebnis ist ein Ding, eine Aktivität ist eine Aufgabe daran. Eine gespeicherte

Fläche, Strecke oder Schnittsituation wird ein Objekt am Gebäude — dieselbe Gattung wie ein KI-erkanntes Bauteil, nur von Hand gemessen. Zum Speichern braucht es keine Aktivität. Das ist die direkte Antwort auf.

1. Jedes Ergebnis wird auf demselben Weg gesichert — nicht über eine Karte, die aufgeht und

den Wert wiederholt, sondern am Maß (zwei kleine Knöpfe) oder in der Werkzeugleiste (Schloss, und das Menü „Messungen n") (R142, R148). Ausgänge: Sichern (wird ein Objekt und ist festgesetzt) · Als Aktivität anlegen (wird eine verortete Aufgabe) · Umbenennen · Löschen.

1. Kein Bild-Download (R142). Wer ein Maß nach außen zeigen will, teilt es über die

Plattform — dann gilt das Rechtemodell und der Zugriff steht im Protokoll.

Zustände (R49)

1. Fünf Zustände je Bildschirm: lädt · leer · gefüllt · Fehler · keine Berechtigung. Im Viewer heißt

„lädt" konkret: Punktwolke lädt in Stufen (erst grob, dann dicht) — nie ein grauer Kasten.

1. Gesperrt statt versteckt (D6/R89): Wer nicht messen oder nichts speichern darf, sieht das

Werkzeug gesperrt mit Grund und dem Weg „anfragen".

VA · Ansehen — durch das Gebäude gehen

Ziel: Ich will nicht nur dort stehen, wo die Kamera stand, sondern das Ganze sehen.

1. Werkzeug Ansicht (Auge) → das Ansicht-Panel hängt am Auge.
2. Umschalter Panorama ↔ Punktwolke oben im Panel.

Regel dazuPanoramen lassen sich nicht schneiden. Im reinen Panorama-Modus erscheint Schnitt nicht in der Werkzeugleiste; sobald Punktwolke oder ein überlagertes Fachmodell im Bild ist, erscheint er (Katalog B3).

ErgebnisDieselbe Stelle, andere Darstellung. Die Etage und der Standpunkt bleiben.

Ziel: Ich will sehen, wohin ich gehen kann — oder ein sauberes Bild ohne Punkte.

1. Ansicht-Panel → Laufpunkte (Schalter, standardmäßig an) und Scan-Positionen.

Regel dazuDas Symbol zeigt, was im Bild zu sehen ist — flache Kugeln auf dem Boden, wie in 0705_navigationspunkte-boden-sphaeren.png. Kein Pfeilkreuz (V9, T2).

ErgebnisDie Punkte im Bild folgen sofort; nichts lädt neu.

Ziel: Auf einem großen Objekt ruckelt es — ich will Übersicht statt Detail.

1. Ansicht-Panel → Panorama-Abstand: ein Regler mit Zahlenfeld und Einheit „m", genau wie im

heutigen Viewer (0965_anzeige-einstellungen-abstand.png) (V11).

1. Darunter dieselbe Erklärung wie dort: *kleinerer Abstand = mehr Panoramen; größerer = mehr

Übersicht.*

Regel dazuPunktdichte ist ebenfalls ein Regler und liegt in derselben Gruppe „Leistung" zwei Regler, dieselbe Bauform.

ErgebnisSichtbar weniger Laufpunkte, flüssigere Bewegung. Die Einstellung gilt für dieses Projekt und diesen Nutzer, nicht global.

Ziel: Ich weiß nicht, wo ich bin.

1. Minikarte unten rechts anklicken → sie wird zur rechten Hälfte (Split).
2. Größe: Splitscheider ziehen. Zurück zur Minikarte: das Symbol in der Kartenkopfzeile.

Regel dazuEs gibt kein „Karte groß" und kein „Karte klein" in der Werkzeugleiste (V17, V18). Die Karte trägt ihre eigenen zwei Zustände.

AbbruchNicht nötig — es ist ein Umschalter.

ErgebnisLinks die Ansicht, rechts der Grundriss der aktuellen Etage, der eigene Standpunkt darin markiert.

Ziel: Es ist gebaut worden; die 3D-Tour ist alt. Bleibt wie gebaut (2030-tour-rundgang-aktualisieren) — das ist ein Auftrag an immorise, kein Viewer-Werkzeug. Bestellt wird im Verarbeitungs-Weg — 2030-verarbeitung-beauftragen, mit Bezahlfenster; wer kein Bestellrecht hat, fragt die Freigabe an (R26, R151).

VB · Messen — und das Ergebnis behalten

Ziel: Wie breit ist diese Tür?

1. Werkzeug Messen → die Mess-Werkzeugleiste erscheint unten. Abstand ist vorgewählt,

Hilfslinien sind an.

1. Zwei Punkte anklicken. Die Lupe mit Fadenkreuz erscheint beim Zielen — ohne sie trifft man den

Wandfuß nicht.

1. Das Maß steht an der Linie (3,12 m), in der gewählten Einheit und Genauigkeit.

AbbruchWerkzeug Messen nochmal anklicken. Die unfertige Messung verschwindet mit.

FehlerKlick trifft keine Tiefe (Himmel, Spiegelung, Glas) → „Hier lässt sich kein Punkt bestimmen — bitte auf eine Fläche klicken." Kein stiller Fehlschlag.

ErgebnisEine Messung im Bild. Noch nicht gespeichert — dafür VB4.

Ziel: Ich will Quadratmeter, nicht Meter.

1. Mess-Werkzeugleiste → Fläche ▾.
2. Das Menü hängt an der Kachel „Fläche" (Spitze zeigt nach unten darauf) und zeigt **drei

farbige Symbole**, kein Text (V5, V7):

Die Farben sind aus dem heutigen Viewer übernommen: dort ist die gemessene Wandfläche grün, die Grundrissfläche orange (1375_messen-grundrissflaeche-map.png).

1. Gewählt → das Symbol steht ab jetzt in der Leiste in der Kachel „Fläche" (V6). Das Menü

schließt.

Regel dazuFlächenarten heißen nach ihrer Ausrichtung, nicht nach einem Bauteil — senkrecht kann auch eine Werbetafel sein (Katalog B5). Die Farbe ist eine Zuordnungsfarbe, kein Status; kein Konflikt mit „eine Bedeutung = eine Farbe".

ErgebnisDer Flächentyp ist gesetzt und bleibt sichtbar, auch wenn das Menü zu ist.

Ziel: Wie groß ist diese Wand?

1. VB2 → Senkrecht.
2. Ansage oben in der Hälfte, die dran ist: „Wandfläche: Grundlinie setzen — 2 Punkte am Wandfuß."

Die Karte öffnet dafür selbst als Split, weil die Grundlinie im Grundriss gezogen wird.

1. Zwei Punkte am Wandfuß → dann die Höhe im Bild antippen.
2. Die Fläche liegt grün im Bild, das Maß steht darin (18,40 m²).

AbbruchWerkzeug Messen aus → alles weg, auch die geöffnete Karte kehrt in die Ecke zurück.

FehlerNur ein Punkt gesetzt und weitergeklickt → die Ansage bleibt stehen und zählt mit (1 · Punkt gesetzt), nichts wird stillschweigend angenommen.

ErgebnisEine Flächenmessung. Weiter mit VB4.

Ziel: Das Maß soll nicht weg sein, wenn ich das Fenster schließe.

Berichtigt am 05.08.2026: Dieser Ablauf beschrieb eine Ergebnis-Karte, die nach jeder Messung aufging und den Wert wiederholte, der schon im Bild steht. Die Karte ist abgeschafft (R142), und der Download als Bild ebenfalls — geteilt wird über die Plattform. Was hier stand, gilt nicht mehr.

1. Die Messung liegt im Bild, das Maß steht darin. Nichts geht von allein auf.
2. Zwei Wege führen zum Sichern, beide zum selben Ergebnis:

• Am Maß hängen zwei kleine Knöpfe: sichern und an eine Aktivität hängen (R142).
• In der Werkzeugleiste steht das Schloss, und der Knopf Messungen n ▾ öffnet das

Menü — auch bei nur einer markierten Messung, nicht erst bei mehreren.

1. Das Menü zeigt die markierte Messung mit Maß, Name und Etage, darunter vier Ausgänge:

Kein Bild-Download (R142). Wer eine Messung nach außen zeigen will, teilt sie über die Plattform — dann gilt das Rechtemodell, und der Zugriff steht im Protokoll.

FehlerKein Speicherrecht im Projekt → Sichern und Als Aktivität anlegen stehen gesperrt mit Grund und dem Weg „anfragen" (R89).

ErgebnisDie Messung ist festgesetzt — oder sie hängt an einer Aktivität und ist es auch.

Ziel: Ich lese die Aufgabe und will sehen, wovon sie redet.

1. Aktivität öffnen. Weil sie aus einer Messung entstand, trägt sie oben die Fläche statt einer

allgemeinen Verortung: Maß, Name, Etage — und den Knopf Fläche zeigen.

1. Klick → der Viewer steht wieder an derselben Stelle, in derselben Darstellung. Dasselbe Maß liegt

im Panorama und in der Punktwolke; gemessen wurde einmal.

1. Das Schloss an der Fläche sagt, dass das Maß sich nicht mehr unter der Aktivität ändern kann.

Löst jemand die Sicherung und ändert es doch, steht das im Verlauf der Aktivität.

ErgebnisDer Bezug ist in beide Richtungen begehbar, nicht nur behauptet.

Ziel: Ich habe vier Wände gemessen.

Berichtigt am 05.08.2026: Hier stand als Voreinstellung eine Aktivität für alle vier Flächen. Das widerspricht der Nebenregel zu R142: Eine Aktivität ist immer an einem Ort verortet. Vier Flächen ergeben deshalb vier Aktivitäten, keine gemeinsame — sonst wäre der Weg zurück aus VB4a nicht eindeutig.

1. Mehrere Messungen aufnehmen (VB3 wiederholen).
2. Messungen n ▾ → Liste → mehrere anhaken, oder im Bild mit „Auswählen" mehrere anklicken.

Die Summe der markierten Flächen steht in der Werkzeugleiste.

1. Ausgänge für die Markierung: alle sichern · je Fläche eine Aktivität ·

Markierung löschen. Es gibt keine Wahl „eine Aktivität für alle" — die Regel lässt sie nicht zu, und der Bildschirm sagt das als Satz, nicht als ausgegraute Möglichkeit.

AbbruchAuswahl aufheben → alle Messungen bleiben, nichts ist verloren.

ErgebnisVier gesicherte Messungen, und auf Wunsch vier verortete Aktivitäten.

Ziel: Ich stehe im Panorama und will hier messen, nicht erst in die Punktwolke wechseln.

1. Werkzeug Messen im Panorama der 3D-Tour → dieselbe Werkzeugleiste erscheint wie in der

Punktwolke, mit demselben Schloss und demselben Menü.

1. Gemessen wird auf der Fläche, die das Panorama zeigt; die Tiefe kommt aus der Punktwolke, die

darunter liegt. Deshalb ist das Maß in beiden Darstellungen dasselbe und wandert mit.

1. Sichern und „Als Aktivität anlegen" verhalten sich wie in VB4 — **kein zweiter Weg, kein

zweites Bild**.

ErgebnisSichern geht in beiden Darstellungen. Was in der einen gilt, gilt in der anderen.

Ziel: Ich habe das gestern gemessen.

1. Messungen n ▾ → Liste mit Name, Maß, Etage, Urheber, Datum. Anklicken springt hin.
2. Zeilenmenü: umbenennen · ausblenden · löschen · an eine Aktivität hängen.
3. Mehrere im Bild wählen geht auch über Auswählen (Cursor-Symbol, wie

1200_messen-auswahl-loeschen.png).

FehlerLöschen einer Messung, an der eine Aktivität hängt → „An dieser Messung hängt 1 Aktivität. Die Aktivität bleibt, der Bezug entfällt." Bestätigung nötig.

ErgebnisDie Liste ist die einzige Stelle, an der Messungen verwaltet werden.

Ziel: Ich habe nur einen Plan, kein Modell.

1. Weg E → Pläne → Blatt öffnen → Werkzeug Messen.
2. In der Leiste erscheint zusätzlich Kalibrieren: eine bekannte Länge im Plan abgreifen und

eintippen. Vorher steht in der Leiste „nicht kalibriert", und Maße werden mit ? angezeigt nie eine erfundene Zahl.

1. Danach wie VB1/VB3.

ErgebnisMaße mit nachvollziehbarem Maßstab; der Maßstab steht im Menü zur Messung mit dabei.

VC · Schneiden — hineinsehen

Dieser Weg war der unklarste. (V16)

Ziel: Ich will die Decke weglassen, oder senkrecht durch das Haus schauen.

1. Werkzeug Schnitt → die Schnitt-Werkzeugleiste erscheint. Drei Arten, als Symbole:

Regel dazu (V10, B6): Das Schnitt-Symbol ist an die Referenz angelehnt (0478_schnittanalyse.png): ein Körper mit einer schräg durchgehenden Ebene und Richtungspfeil — visuell eindeutig, nicht ein abstraktes Rechteck.

ErgebnisDer Schnitt ist die eine Funktion an einer Stelle — vorher lag er im Ansicht-Panel und im BIM-Panel und als Linie in der Karte (Katalog B3).

1. VC1 → Box. Die Box liegt um das Sichtbare, Griffe an den Seiten.
2. Seiten ziehen. Der Wert steht an der Seite (Ost 4,20 m, Höhe 2,80 m).
3. Box zeigen aus → die Box wird unsichtbar, der Schnitt bleibt. Zustandspille oben:

„Schnitt aktiv · Box ausgeblendet" mit den Auswegen Box zeigen und Aufheben (T7).

AbbruchWerkzeug Schnitt aus → voller Blick zurück.

ErgebnisFreigestellter Bereich. Zusätzlicher Zweck: Ausschnitt exportieren (E57 des zugeschnittenen Bereichs) — von mehreren Kunden angefragt (Katalog B5).

1. VC1 → Querschnitt. Die Karte öffnet selbst als rechte Hälfte, weil die Linie im Grundriss

gezogen wird.

1. Ansage in der Kartenhälfte: „Schnittlinie ziehen — 2 Punkte durch den Grundriss."
2. Zwei Punkte → die rechte Hälfte wechselt von Grundriss auf Schnittansicht mit Höhenmaßstab.
3. Verschieben: an den Endpunkten der Linie im Grundriss ziehen. Es gibt **kein „Linie

versetzen"** (V15) — der Knopf beschrieb eine Funktion, die es nicht gibt.

AbbruchWerkzeug Schnitt nochmal anklicken (V19) — kein „Abbrechen".

FehlerBeide Punkte an derselben Stelle → die Ansage bleibt stehen; kein leerer Schnitt.

ErgebnisLinks die 3D-Ansicht, rechts der Schnitt. Zustandspille oben: „Schnitt aktiv".

Ziel: Die Deckenhöhe im Schnitt abgreifen.

1. Schnitt steht (VC2 oder VC3) → Werkzeug Messen anklicken.
2. Die Schnitt-Leiste wird ersetzt durch die normale Mess-Werkzeugleiste — dieselbe wie

überall. Die Schnitt-Pille bleibt oben sichtbar und aktiv (B7, T7, V16).

1. Messen wie VB1. Auch Flächen gehen im Schnitt.

Regel dazuNie zwei Werkzeugleisten übereinander. Ein Werkzeug ist aktiv, seine Leiste steht unten; alle anderen aktiven Zustände stehen als Pille oben (Katalog B5).

ErgebnisMaße im Schnitt, gesichert auf demselben Weg wie in VB4.

Wie VB4, mit einer Ergänzung im Menü zur Messung: bei einer Box steht zusätzlich Ausschnitt exportieren (E57). Das ist der einzige Export, der hier bleibt — der Bild-Download ist weg (R142).

ErgebnisDie Schnittsituation ist gesichert, an eine verortete Aktivität gehängt oder als Punktwolken-Ausschnitt geliefert — drei benannte Ausgänge, kein „und dann?".

VD · Ebenen — steuern, was man sieht

1. Werkzeug Ebenen → das Panel hängt am Symbol (das ist die Vorlage, auf die alle anderen

Menüs gezogen werden — V4).

1. Zwei Gruppen, deutlich verschieden gebaut (V21, T6):

Regel dazuDie beiden waren zu ähnlich — „E57" und „IFC" am Gruppenkopf allein waren nicht genug (V21). Das Farbfeld trägt die Unterscheidung, weil man es in jeder Zeile sieht.

ErgebnisEine Liste beantwortet eine Frage: Was sehe ich gerade?

Ziel: Das oberste Geschoss stört.

1. VD1 → am Teil … ▾ → Menü klappt im Panel auf (Q4), nicht nach rechts ins Bild:

Ausblenden · Nur dieses Teil zeigen · Teil ersetzen · Teil exportieren · Teil entfernen.

Regel dazuDieses Menü fehlte vollständig und muss genauso aufklappen wie beim Fachmodell (V21).

Fehler„Teil entfernen" bei einem Teil, auf dem Messungen liegen → „Auf diesem Teil liegen 3 Messungen. Sie bleiben, verlieren aber ihren Untergrund." Bestätigung nötig.

ErgebnisNur sichtbare Teile werden geladen — das hält große Objekte flüssig.

1. VD1 → am Modell … ▾: Ins Bild holen · Ausrichten · Neue Fassung laden · Modell entfernen.
2. Farbe und Deckkraft stehen in der Zeile selbst, nicht im Menü (T19) — man will sie beim

Schieben sehen.

Regel dazu (V22): „Struktur dieser Datei" ist kein Menüpunkt mehr. Die Struktur erscheint, wenn man die Datei anklickt — siehe VD4.

ErgebnisDas Menü enthält nur noch Aktionen, keine Ansichten.

Ziel: Alle Türen im Untergeschoss sehen.

1. VD1 → auf den Modellnamen klicken → die Struktur klappt im Panel darunter auf: Etagen,

darin Bauteilarten in Klartext mit der IFC-Klasse als nachprüfbarer Wert darunter und der Anzahl rechts (Türen · IfcDoor · 17).

1. Zwei Filterfelder in Feldhöhe: Etage und Art.
2. Einfärben, zwei Wege (T16, V22):

• ganzes Modell in einer Hauptfarbe (das Farbfeld in der Modellzeile) — und
• einzelne Bauteilarten abweichend (Farbfeld je Zeile in der Struktur).

Darunter Farben zurücksetzen.

AbbruchNochmal auf den Namen klicken → die Struktur klappt zu, Farben bleiben.

ErgebnisKein eigener Bildschirm „Bauteile nach Etage" mehr — die Struktur hängt an ihrer Datei (T16).

Ziel: Die Planung liegt 18 cm neben dem Bestand. Der Weg — das war V23/T17: er fehlte.

1. Werkzeug Ebenen → Modell … ▾ → Ausrichten.
2. Das Ebenen-Panel klappt auf einen schmalen Streifen (250 px): Anleitung in einem Satz,

aktueller Versatz als Zahl (X +0,42 m · Y −0,18 m · Z 0,00 m · Drehung 1,4°).

1. Die Ansicht wird Split: links 3D, rechts Grundriss. Greifer in beiden Hälften — Pfeile zum

Verschieben, der Ring zum Drehen. Beide Hälften bewegen sich mit.

1. Ausrichtung speichern · Zurücksetzen. Abbrechen verwirft.

FehlerKein Scan im Projekt → der Weg ist gesperrt mit Grund: „Ausrichten braucht einen Scan als Bezug" (R89).

ErgebnisDer Versatz ist gespeichert und gilt für alle, die das Modell sehen. Protokolleintrag.

VE · Modell — ein Bauteil und seine Daten

1. Ins Modell klicken → das Bauteil leuchtet, ein Menü hängt am Bauteil (nicht am Bildrand):

Kopf mit Name und Klasse, darunter Eigenschaften · Isolieren · Ausblenden.

1. Unten links die Info-Pille: Bauteil: Tür E-0.04 (ohne Genauigkeitsangabe — R107; nachgezogen 03.08.).

ErgebnisAus dem Betrachten führt ein Weg in die Arbeit — jeder Eintrag ist ein Weg, keine Anzeige.

Rechtes Panel mit Gruppen (Kennung, Geometrie, Material, Bezüge). Bezüge sind anklickbar: 1 Aktivität, 2 Dokumente.

1. Werkzeug Markierung → Pfeil, Wolke, Text, Farbe.
2. Setzen → Aktivität daraus → das Formular öffnet mit Bild und Bezug schon angehängt.

Regel dazu (B3): Ob der Bezug als Fläche, Bauteil oder Bild gilt, entscheidet der Inhalt, nicht die Ansicht. Eine Markierung im 3D-Modell ist eine Markierung; ein angeklicktes Bauteil im 2D-Plan ist ein Bauteil. Deshalb heißt der Knopf „Aktivität" — nicht „3D-Aktivität" oder „2D-Aktivität" (B3, noch offen bis hier).

ErgebnisAktivität mit Ortsbezug, ohne Formular-Fleißarbeit.

Werkzeug Ansicht → Reiter Pläne → Blatt wählen. Messen darin: VB7.

Werkzeug Mehr → das Menü hängt am Symbol (V2 — es klebte am oberen Bildschirmrand): Auswahl als Excel exportieren · KI-Assistent · Explosionsansicht · Screenshot · Ansicht speichern · Viewer-Einstellungen. „Karte" ist heraus — die Karte gehört sich selbst (V17, V18). „Ebenen & Etagen" ist heraus — das ist das Werkzeug Ebenen (V24, keine zweite Tür).

VF · Objekte — was im Gebäude verbaut ist

1. Werkzeug Objekte → Panel: Suche, Filter, Liste (Name, Kategorie, Sichtbarkeit, Datum),

Schalter Objekte im Bild anzeigen.

1. Anklicken springt zum Objekt und rahmt es ein.

Regel dazu (V24): „Objekte" und „Ebenen" sind zwei verschiedene Fragen und zeigen deshalb nichts Gleiches:

• Ebenen = Was sehe ich? → Punktwolken-Teile und Fachmodelle, Sichtbarkeit, Farbe, Deckkraft.
• Objekte = Was ist verbaut? → erkannte Bauteile und Ausstattung, Kategorie, Export.

„IFC-Overlay" ist kein eigener Bereich — ein IFC ist ein Fachmodell und wohnt in Ebenen. Das zweite Ebenen-Panel in der Objekte-Datei ist damit aufgelöst.

1. + Neu → im Bild anklicken → die KI erkennt das Bauteil und setzt die Box; nachziehen möglich.
2. Benennen, Kategorie wählen, Sichtbarkeit.

ErgebnisEin Objekt am Gebäude — dieselbe Gattung wie eine gespeicherte Messung (VB4). Kein drittes System.

Die KI schlägt weitere Objekte vor; die Zeile trägt prüfen & übernehmen. Nichts wird ohne Bestätigung angelegt.

Excel · IFC · ERP/EAM. Der Weg steht im Panelfuß, nicht in einem Menü.

1 · Was daraus zu bauen ist

Neu:

Umgebaut: alle Mess-Leisten auf eine (V13, V16) · alle Menüs auf Andocken am Symbol (V1–V4) · Flächenarten auf farbige Symbole (V5–V7) · Hilfslinien auf ein Symbol (V8) · Laufpunkte- und Schnitt-Symbol (V9, V10) · Panorama-Abstand auf Regler (V11) · ein Splitscheider (V12) · Karte losgelöst (V17, V18) · Punktwolken-Menü (V21).

Gestrichen: „Linie versetzen" (V15) · „Karte groß" (V17) · „Abbrechen" (V19) · „Fertig" · „Freies Messen" (R96) · das zweite Ebenen-Panel in der Objekte-Datei (V24) · „Karte" und „Ebenen & Etagen" im Mehr-Menü (V24).

2 · Neue Regeln, die daraus folgen

Diese vier gehören nach Doku 62:

3 · Was hier bewusst offen bleibt

Datenraum

Was das hier ist: Für jeden Weg durch den Datenraum: Ziel, Schritte, Abbruch, Fehler, Ergebnis — dieselbe Form wie Abschnitt 5 der Spezifikation 57. Erst wenn die Wege stehen, sieht man, welche Bildschirme wirklich fehlen und welche nur eine Einblendung brauchen. Die Antwort darauf steht am Ende. Grundlage: die Befundliste Doku 61 und die Entscheidungen Doku 62. Das Rechtemodell selbst steht in Doku 57, Abschnitt 7 ist der Vertrag zwischen beiden Seiten.

0 · Die Bildschirme und ihre Kennungen

Vorhanden (in mockups-v2/2030-datenraum.html):

Fehlend, aus den Abläufen unten hergeleitet:

0.1 Was für alle Abläufe gilt

Damit es unten nicht dreißigmal wiederholt wird:

• Jede Einschränkung nennt ihre Ursache — Rolle oder Ordner, nie unbestimmt (R56).
• Niemand gibt weiter, was er selbst nicht sieht — weder Ordner noch Stufe (R65, R16).
• Der Ordner kann nur einschränken, nie erweitern. Die wirksame Stufe ist immer die niedrigere

von Rolle und Ordner (R55).

• Nach außen teilen und zur Unterschrift geben sind eigene Schalter, keine Stufen der Leiter

(R54, R75).

• Fehlende Rechte verstecken keine Funktionen. Wer ein Recht nicht hat, sieht das Bedienelement

gesperrt, erfährt den Grund und kann es anfragen (Entscheidung die Geschäftsführung 02.08.; Maßstab Drooms, idgard). Prüfbar ist nicht „der Knopf fehlt", sondern: es entsteht kein Link, kein Download, kein Signaturlauf. Ausnahme bleibt die Stufe kein Zugriff: Was gar nicht sichtbar sein darf, wird auch nicht als gesperrt angedeutet — sonst verrät die Sperre den Inhalt.

• Jeder Zugriff und jede Rechteänderung steht im Protokoll (R27).
• Abbrechen mit geänderten Eingaben fragt nach (R51); Speichern bleibt auf der Seite (R20).
• Fünf Zustände je Bildschirm: lädt, leer, gefüllt, Fehler, keine Berechtigung (R49).

DA · Dateien und Ordner

Ziel: Das gesuchte Dokument öffnen, ohne den Ordnerbaum zu kennen.

1. D1. Entweder im Baum links klicken oder oben rechts in die Suche tippen.
2. Die Suche greift auf Name und Inhalt zu und zeigt Treffer mit ihrem Ordnerpfad.
3. Klick auf die Zeile → das Detail rechts füllt sich.

AbbruchSuchfeld leeren → zurück zum zuletzt geöffneten Ordner.

FehlerKein Treffer → „Nichts gefunden" mit den zuletzt geänderten Dateien als Angebot, nicht mit einer leeren Fläche (D17).

ErgebnisDatei ausgewählt, Detail offen. Wichtig: Die Suche findet nur, was die Person sehen darf — ein gesperrter Ordner erzeugt keinen Treffer und keinen Hinweis, dass es ihn gibt.

Ziel: Den Inhalt lesen, ohne herunterzuladen.

1. D1 → Vorschau im Detail, oder Doppelklick auf die Zeile → D5.
2. Kopfzeile: Dateiname, Seite, Fassung, Ordnerpfad, Hosting-Hinweis.
3. Rechts die KI-Auslese mit Sicherheitswerten; unsichere Felder sind hervorgehoben.

AbbruchX oben links → zurück zu D1, dieselbe Zeile bleibt ausgewählt.

FehlerDatei beschädigt oder Format nicht darstellbar → Hinweis mit dem Angebot herunterzuladen, sofern die Stufe das erlaubt.

ErgebnisDokument gelesen, Zugriff im Protokoll. Rechte: Bei Stufe Ansehen stehen Herunterladen und Teilen gesperrt in der Kopfzeile, mit dem Grund daneben: „Deine Rolle erlaubt hier nur Ansehen" und einem Anfrage-Weg (R56). Das Wasserzeichen trägt Name, Adresse und Zeitpunkt.

Ziel: Neue Dokumente ablegen.

1. D1 → Hinzufügen oben rechts, oder Dateien in die Ablagefläche am Listenende ziehen → D10.
2. Zielordner steht im Kopf und ist änderbar.
3. Dateien wählen oder ziehen; ein ganzer Ordner behält seine Struktur.
4. Hochladen.
5. Während des Hochladens bleibt die Liste bedienbar; die KI liest die Eckdaten aus und die Zeile

zeigt das („KI liest Eckdaten aus … du kannst weiterarbeiten").

AbbruchWährend des Hochladens abbrechbar; bereits fertige Dateien bleiben liegen, der Rest nicht.

FehlerDatei zu groß → Grenze nennen, Datei einzeln markieren, die anderen laufen weiter. Format gesperrt → dasselbe. Speicher voll → Hochladen wird verweigert, mit Angabe wie viel fehlt. Verbindung bricht ab → angefangene Dateien werden fortgesetzt, nicht neu begonnen.

ErgebnisDateien liegen im Zielordner und erben dessen Rechte. Gleichnamige Dateien werden zur neuen Fassung, nicht zum Duplikat. Rechte: Nur ab Stufe Bearbeiten. Darunter stehen Hinzufügen und die Ablagefläche gesperrt da, mit Grund und Anfrage-Weg.

Ziel: Ein Dokument ersetzen, ohne die Vorgeschichte zu verlieren.

1. Wie DA3, gleicher Dateiname im selben Ordner.
2. Das System erkennt es und legt v(n+1) an; die Vorfassungen bleiben abrufbar.
3. Im Detail listet Versionen alle Fassungen mit Datum und Urheber.

FehlerGleicher Name, anderes Format → Rückfrage, ob Fassung oder eigene Datei.

ErgebnisNeue Fassung aktiv. Offene Freigaben zeigen ab sofort die neue Fassung — das steht in der Rückfrage, weil es sonst überrascht.

Ziel: Struktur schaffen.

1. D1 → + Neuer Ordner über der Liste, oder in D10.
2. Name eintragen, Position im Baum bestätigen.

FehlerName bereits vergeben → Hinweis am Feld.

ErgebnisOrdner angelegt. Er erbt die Rechte des übergeordneten Ordners und lässt sich anschließend über D11 weiter einschränken — nie erweitern (R55).

Ziel: Ordnung nachziehen.

1. Zeilen auswählen → Auswahl-Pille → Verschieben, oder Zeilenmenü (D18) → Umbenennen.
2. Zielordner wählen.

FehlerZiel gesperrt → das Ziel erscheint gar nicht in der Auswahl (R65).

ErgebnisDatei liegt im neuen Ordner und nimmt dessen Rechte an. Wenn das für jemanden Verlust bedeutet, sagt es die Rückfrage vorher: „Drei Personen verlieren dadurch den Zugriff."

Ziel: Aufräumen, ohne etwas endgültig zu verlieren.

1. Auswahl → Löschen → Rückfrage mit Anzahl.
2. Die Dateien liegen im Papierkorb und bleiben 30 Tage wiederherstellbar.
3. Papierkorb im Baum unten → Wiederherstellen oder Endgültig löschen.

FehlerDatei hat offene Freigaben → Rückfrage nennt sie: „Zwei Gast-Links verlieren ihr Ziel." Datei hängt an einer laufenden Signatur → Löschen nicht möglich, mit Begründung.

ErgebnisIm Papierkorb, Freigaben darauf sofort unwirksam. Endgültiges Löschen nur ab Stufe Bearbeiten und immer im Protokoll.

Ziel: Der Vorgang und sein Nachweis gehören zusammen.

1. Aus D1: Zeilenmenü → Mit Aktivität verknüpfen → Auswahl der Aktivitäten dieses Objekts.
2. Oder aus der Aktivität heraus: Dokument aus dem Datenraum.

FehlerKeine Aktivität vorhanden → Angebot, eine anzulegen.

ErgebnisVerknüpfung in beide Richtungen sichtbar. Rechte — der Fall, der leicht übersehen wird: Die Verknüpfung vergibt keine Rechte. Wer die Aktivität sieht, aber den Ordner nicht, sieht den Dateinamen und den Hinweis, dass der Zugriff fehlt, mit Grund und der Möglichkeit, ihn anzufragen — er sieht nicht den Inhalt (R55, R56).

Ziel: Ein Dokument an einer Stelle im Gebäude verankern.

1. D10 → Aus dem Zwilling verknüpfen.
2. Ein Mini-Viewer öffnet: Bauteil im Modell oder Punkt in der 3D-Tour wählen.
3. Bestätigen.

Abbruchschließt nur den Viewer, das Hochladen läuft weiter.

ErgebnisDas Dokument hängt an einer Stelle im Zwilling und ist von dort aus auffindbar. Das ist der Datenraum-Teil des 3D-Versprechens und deshalb kein Nebenweg.

TE · Teilen

Ziel: Ein Externer soll ein Dokument sehen, ohne Zugang zur Plattform.

1. D1 → Teilen im Detail, oder Zeilenmenü → D4, Reiter Extern als Gast-Link.
2. Adresse eintragen. Der Gast bestätigt sie später, bevor er das Dokument sieht.
3. Stufe wählen: Ansehen · Laden mit Wasserzeichen · Original laden.
4. Frist wählen; Voreinstellung sieben Tage.
5. Benachrichtigung bei jedem Zugriff an/aus.
6. Gast-Link erstellen.

Abbruchjederzeit, nichts wird erzeugt.

FehlerAdresse ungültig → Hinweis am Feld. Adresse bereits mit gültigem Link versorgt → „Diese Person hat seit dem 05.07. Zugriff" mit Verweis auf die bestehende Freigabe statt einer zweiten. Versand scheitert → die Freigabe besteht, der Link lässt sich erneut senden.

ErgebnisFreigabe erzeugt, in D2 sichtbar, jederzeit widerrufbar. Rechte — zwei Deckel: Ohne das Recht nach außen teilen ist der Weg sichtbar, aber gesperrt, mit Grund und Anfrage-Knopf (R54). Und angeboten werden nur Stufen bis zur eigenen wirksamen Stufe; höhere stehen gesperrt da, mit Grund (R55, R65, R56) — gesperrt und nicht versteckt, damit man sieht, dass es sie gibt.

Wie TE1, ausgelöst über Ordner teilen über der Liste. Zusatzschritt: Die Rückfrage nennt Anzahl und Umfang: „05 Finanzen — 31 Dateien, davon 4 in Unterordnern." Untergeordnete Ordner sind eingeschlossen; einzelne lassen sich ausnehmen.

ErgebnisEine Freigabe auf den Ordner, nicht 31 einzelne. Neue Dateien im Ordner fallen automatisch darunter — auch das steht in der Rückfrage.

— (D19) Ziel: Eine Kollegin soll an ein Dokument, das ihre Rolle nicht abdeckt.

1. D4, Reiter Im Team teilen.
2. Person oder Gruppe wählen — angeboten wird nur, wer im Projekt ist.
3. Stufe wählen, gedeckelt wie in TE1, zusätzlich gedeckelt durch die **Firmen-Rolle der

Empfängerin**: Was ihre Rolle nicht hergibt, lässt sich hier nicht erteilen (R55).

1. Optional befristen.

FehlerPerson hat den Zugriff bereits über ihre Rolle → „Hat bereits Original laden über die Rolle Facility Manager" — kein zweiter Eintrag.

ErgebnisEine benannte Freigabe, in D2 als im Team geführt und dort widerrufbar.

— (D15) Ziel: Teilen, ohne vorher die Datei zu suchen.

1. D2 → Freigabe erteilen → D15.
2. Erst wählen, was geteilt wird: Baum und Suche, aber nur der eigene sichtbare Bereich

(R65). Was man selbst nicht sieht, erscheint hier nicht.

1. Dann mit wem: Team oder Gast-Link.
2. Weiter wie TE1 ab Schritt 3.

FehlerNichts gewählt → Weiter bleibt inaktiv, mit Hinweis darauf, was fehlt.

ErgebnisWie TE1.

1. D2 → in der Zeile Verlängern (befristet) oder Befristen (unbefristet).
2. Neues Datum wählen.

ErgebnisFrist geändert, der Empfänger wird einmal informiert — sonst merkt er den Ablauf erst, wenn nichts mehr geht.

1. D2 → Widerrufen in der Zeile → Rückfrage.
2. Bestätigen.

ErgebnisSofort unwirksam, auch für einen offenen Browser-Tab beim Empfänger. Die Zeile bleibt eine Weile grau mit widerrufen am … stehen, statt spurlos zu verschwinden — sonst zweifelt man, ob es geklappt hat.

— (D16) Ziel: Ein Dienstleister ist raus.

1. D2 → Umschalter Nach Empfänger.
2. Die Liste bündelt je Person oder Firma alle Freigaben mit Anzahl.
3. Zeile aufklappen zum Prüfen, oder direkt Alle widerrufen → Rückfrage mit Anzahl.

ErgebnisAlle Freigaben dieser Person unwirksam, ein Eintrag im Protokoll je Freigabe. Grenze: Was die Person über ihre Rolle hat, bleibt — das ändert man im User-Management. Der Bildschirm sagt das, sonst hält man den Widerruf für vollständig.

(Gegenseite)

1. Gast klickt den Link in der Mail → Adresse bestätigen.
2. Dokument öffnet in der Vorschau, mit Wasserzeichen.
3. Je nach Stufe: herunterladen möglich oder nicht.

FehlerLink abgelaufen → „Dieser Zugang ist am 19.07. abgelaufen" mit Knopf Verlängerung anfragen, der beim Ersteller als Mitteilung ankommt. Widerrufen → dieselbe Form, andere Begründung. Falsche Adresse → keine Auskunft darüber, ob es den Link gibt.

ErgebnisZugriff im Protokoll, mit Zeitpunkt. Der Ersteller sieht in D2 letzter Zugriff.

ZU · Zugriff und Rechte

Ziel: Sehen und ändern, wer im Datenraum was darf.

1. D1 → Tab Zugriff → D3: Ordner in den Zeilen, Rollen in den Spalten, je Kreuzung die

Fünf-Stufen-Leiter. Über jeder Rollenspalte steht ein Lineal aus fünf Buchstaben, das die Positionen benennt; wo es keinen Zugriff gibt, steht das durchgestrichene Auge statt einer leeren Leiter, weil „kein Zugriff" keine Stufe ist (R146).

1. Klick auf eine Kreuzung → Auswahl der Stufe → gilt sofort, mit Angabe für wie viele Personen.

FehlerDie gewählte Stufe liegt über dem, was die Rolle hergibt → sie ist gesperrt, mit dem Satz „Die Rolle Dienstleister erlaubt höchstens Ansehen — zu ändern im User-Management" (R55, R56). Das ist der wichtigste Fehlerfall des ganzen Bereichs: Sonst stellt jemand Original laden ein und glaubt, er hätte etwas erlaubt.

ErgebnisWirksam ab sofort, Unterordner erben, Protokolleintrag. Sicht: Wer selbst nur einen Teil des Datenraums sieht, sieht auch nur diese Zeilen (R65).

— (D22, R155) Ziel: Für eine Rolle die Ordner öffnen, ohne die Matrix erst suchen zu müssen.

1. User-Management → Rolle → Zeile Datenraum → Einzelne Ordner abweichend regeln → D22.
2. D22 ist dieselbe Matrix wie D3, mit drei Unterschieden: die Spalte dieser Rolle ist

hervorgehoben, über jeder Spalte steht ihr Kennzeichen (im Haus · von außen), und oben führt ein Rückweg zur Rolle.

1. Eine Zeile nennt den Stand: „*Planer · Architekt ist von außen und beginnt bei keinem Ordner.

Freigegeben sind 3 von 12.*" Dieselbe Zahl steht im Rollen-Editor an der Datenraum-Zeile.

Warum getrennt von ZU1: ZU1 ist die Sicht des Datenraum-Verwalters — alle Rollen nebeneinander. ZU1a ist die Sicht dessen, der gerade eine Person einlädt und nur wissen will, was diese eine Rolle sieht. Ohne den Verweis in beide Richtungen bleiben es zwei Bildschirme statt eines Modells.

ErgebnisWie ZU1 — wirksam ab sofort, Unterordner erben, Protokolleintrag. Für viele Ordner auf einmal: Ordner-Vorlage anwenden, statt Zeile für Zeile zu klicken.

— (D11) Ziel: Alles zu einem Ordner an einer Stelle.

1. D1 → Zeilenmenü am Ordner → Rechte, oder aus D3 der Ordnername → D11.
2. Der Bildschirm zeigt für diesen Ordner:

• die Stufe je Rolle und Gruppe, als dieselbe Fünf-Stufen-Leiter,
• den Schalter nach außen teilen (R54),
• den Schalter zur Unterschrift geben (R75),
• benannte Ausnahmen einzelner Personen mit Frist,
• je Zeile die Ursache im Klartext: aus der Rolle, aus dem übergeordneten Ordner oder hier

gesetzt (R56).

1. Ändern → Speichern.

FehlerEine Änderung nimmt jemandem etwas weg → Warnung mit Anzahl und Namen, vor dem Speichern.

ErgebnisRechte des Ordners gesetzt, Unterordner erben, alles im Protokoll.

— (D12, R53) Ziel: In einem Klick beantworten, wer an ein Dokument oder einen Ordner kommt.

1. D1 → im Detail Zugriff → Verwalten oder Alle ansehen, oder aus D11 → D12.
2. Eine Personenliste, nicht eine Rollenliste: je Person Name, wirksame Stufe und **woher sie

kommt** — Rolle, Gruppe, Ausnahme oder Freigabe.

1. Umschalter nur Interne / auch Gäste.
2. Aus jeder Zeile heraus: entziehen, befristen, oder zur Person springen.

ErgebnisDie Frage ist beantwortet, ohne drei Bildschirme zu vergleichen. Das ist die Ansicht, die im Zweifel vor dem Prüfer zeigt, wer an welchem Vertrag war.

— (R56) Ziel: Kein Support-Fall aus einer fehlenden Zeile.

1. Wer über einen Verweis oder eine Verknüpfung auf einen gesperrten Ordner stößt, bekommt **keine

leere Seite** und keinen Fehlercode, sondern einen Satz: „Dieser Ordner ist auf Ansehen beschränkt — festgelegt im Datenraum von M. Krüger" oder „Deine Rolle erlaubt hier keinen Zugriff."

1. Darunter: Zugriff anfragen → geht als Mitteilung an die genannte Stelle.

ErgebnisDie Person weiß, woran es liegt und wen sie fragen muss. Die Anfrage läuft denselben Weg wie die Freigabe-Anfrage bei höheren Rechten (R73). Grenze: Ordner der Stufe kein Zugriff erscheinen gar nicht — dort gibt es auch nichts zu erklären, sonst verrät die Erklärung ihre Existenz.

Ziel: Einer einzelnen Person an einem einzelnen Ordner mehr oder weniger geben.

1. D11 → Ausnahme hinzufügen → Person wählen, Stufe wählen, Frist optional.

FehlerDie Stufe liegt über der Firmen-Rolle der Person → gesperrt, mit Grund (R55).

ErgebnisBenannte Ausnahme, sichtbar in D11 und in D12, mit einem Klick rücknehmbar.

— (D13) Ziel: Zeigen, wie der Datenraum für jemanden aussieht, der wenig darf — das ist der häufigste Fall und der am wenigsten gestaltete.

1. Der Baum zeigt nur zugängliche Ordner.
2. Auf eingeschränkten Ordnern steht die Stufe als leiser Hinweis in der Kopfzeile.
3. Fehlende Bedienelemente sind gesperrt mit Schloss, nicht entfernt; einmal je Bildschirm steht der Grund, und daneben steht Anfragen.
4. Der Freigaben-Tab zeigt nur die eigenen Freigaben; Zugriff und Protokoll stehen gesperrt da.

ErgebnisEin ruhiger Bildschirm ohne Sackgassen. Für die Übergabe an die Entwickler ist das der wichtigste der fehlenden Bildschirme, weil sich jeder andere daraus ableiten lässt.

SI · Unterschrift

Ziel: Rechtsverbindliche Unterschriften einholen.

1. D1 → Zeilenmenü → Zur Unterschrift geben → D8.
2. Unterzeichner in Reihenfolge eintragen — interne Personen und externe Gäste.
3. Je Unterzeichner festlegen, was er setzt: Unterschrift, Unterschrift und Datum.
4. Signaturfelder im Dokument platzieren.
5. Frist wählen, Nachricht schreiben.
6. Zur Signatur senden.

Abbruchjederzeit; nichts wird versendet.

FehlerKein Signaturfeld gesetzt → Senden bleibt inaktiv mit Hinweis. Adresse ungültig → Hinweis am Feld. Dokument ist bereits in einem laufenden Lauf → Hinweis mit Verweis darauf.

ErgebnisLauf gestartet, Dokument gegen Änderung gesperrt, Zustand in D1 sichtbar. Rechte: Nur mit dem Recht zur Unterschrift geben (R75). Ohne das Recht steht der Menüpunkt gesperrt da, mit Grund und Anfrage-Weg (R89 — nachgezogen 03.08., die alte „fehlt"-Formulierung stammte von vor D6).

1. Der Unterzeichner öffnet den Link → D9.
2. Rechts der Signaturlauf: wer schon unterschrieben hat, wer wartet, wer dran ist.
3. Jetzt signieren → Identitätsprüfung → Unterschrift setzen.

ErgebnisSignatur mit Zeitstempel; der Nächste wird benachrichtigt. Nach der letzten Unterschrift werden Zertifikat und Audit-Trail automatisch als neue Fassung im selben Ordner abgelegt.

Ziel: Der wahrscheinlichste Abbruchweg, und bisher der einzige ohne Bildschirm.

1. D9 → Ablehnen / Änderung anfragen.
2. Auswahl: Änderung anfragen (mit Text) oder endgültig ablehnen (mit Begründung).
3. Bestätigen.

ErgebnisDer Lauf hält an — er wird nicht gelöscht. Alle Beteiligten bekommen eine Mitteilung. Der Auslöser kann eine neue Fassung hochladen und den Lauf neu starten; die alte Unterschrift gilt dann nicht mehr, und das steht in der Rückfrage.

1. Drei Tage vorher: Erinnerung an die, die noch fehlen.
2. Am Stichtag: Lauf läuft ab, Dokument wird wieder entsperrt.

ErgebnisZustand abgelaufen mit Datum, im Protokoll. Neu starten ist ein neuer Lauf, keine Fortsetzung — sonst stimmt der Nachweis nicht mehr.

NA · Nachweis

— (D14) Ziel: Belegen, wer wann was gesehen, geladen, geändert oder freigegeben hat.

1. D1 → Tab Protokoll → D14.
2. Filter: Zeitraum, Person, Datei oder Ordner, Art des Vorgangs.
3. Jede Zeile: Zeitpunkt, Person, Vorgang, Ziel, Herkunft (Oberfläche, Gast-Link, Support).
4. Exportieren als Tabelle.

FehlerZeitraum ohne Vorgänge → „Keine Vorgänge in diesem Zeitraum", nicht leer.

ErgebnisNachweis lesbar und exportierbar. Rechte: Das Protokoll ganzer Ordner sieht, wer den Ordner verwalten darf. Änderungen durch immorise erscheinen als immorise Support, nicht als Kundenkonto (Spec 2.9).

1. D2 → Freigaben-Report.
2. Zeitraum wählen → Tabelle: wer, was, welche Stufe, seit wann, bis wann, letzter Zugriff.

ErgebnisEine Datei, die man einem Prüfer geben kann, ohne Bildschirmfotos zu machen.

IM · Import

Ziel: Einen bestehenden Datenraum aus Drooms, Architrave, Evana, idgard oder als ZIP verlustfrei übernehmen.

1. D1 → Importieren → D7.
2. Herkunft wählen, Datei oder Zugang angeben.
3. Vorschau: erkannte Ordnerstruktur und Anzahl Dateien; die Zuordnung ist änderbar.
4. Struktur übernehmen.

Abbruchvor dem Start folgenlos.

FehlerStruktur nicht lesbar → Hinweis mit dem Angebot, es als flachen Ordner zu übernehmen. Rechte: Import legt Ordner und Dateien an, gilt also als Bearbeiten — und erzeugt keine Rechte aus dem Fremdsystem. Alles landet zunächst mit den Rechten des Zielordners; die Freigaben werden neu vergeben. Das ist Absicht und steht im Bildschirm.

1. Fortschritt mit Anzahl und geschätzter Dauer; man kann weiterarbeiten.
2. Nach Abschluss ein Ergebnisbildschirm: übernommen, übersprungen, fehlgeschlagen — je mit Grund

und der Möglichkeit, Fehlgeschlagenes einzeln erneut zu versuchen.

ErgebnisStruktur steht, Protokolleintrag mit Herkunft. Ohne diesen zweiten Schritt endet der heutige Ablauf im Nichts (Befund F22).

DD · Deal-Raum — vorgemerkt, nicht jetzt gebaut

Nach der Entscheidung vom 02.08. wird der Deal-Raum nicht gebaut, aber getragen. Die drei Abläufe stehen hier, damit die Datenstruktur sie später aufnehmen kann.

— (D20)

1. D6 → Partei einladen.
2. Name der Partei, Personen, Phase wählen.
3. Die Phase ist eine Gruppe mit eigener Ordner-Einschränkung (Entscheidung D3).

ErgebnisPartei angelegt, sieht genau die Ordner ihrer Phase, getrennt von den anderen Parteien.

1. D6 → in der Parteizeile Phase ändern.
2. Rückfrage nennt, was dadurch zusätzlich sichtbar wird — Anzahl Ordner und Dateien.

ErgebnisGruppenwechsel, sofort wirksam, im Protokoll.

— (D21)

1. Aus D5 → Schwärzen → Bereiche markieren.
2. Die geschwärzte Fassung wird als eigene Fassung abgelegt.
3. Je Gruppe festlegen, welche Fassung sie sieht.

ErgebnisBieter sehen die geschwärzte, das Verkäufer-Team das Original. Das ist die eine technische Voraussetzung, die schon jetzt an die Entwickler gehört: Eine Datei braucht die Fähigkeit, je Gruppe eine andere Fassung zu zeigen. Nachrüsten ist teuer.

ZW · Mit dem Zwilling verknüpfen (Nachtrag 03.08.2026)

Warum das hier steht: Er hat in beidem recht. Das Wort ist geändert — „mit" statt „aus", weil die Datei im Datenraum bleibt und dort eine Verbindung bekommt; sie wird nicht aus dem Zwilling geholt. Und es sind tatsächlich zwei Wege, die es beide geben muss, weil sie aus zwei verschiedenen Absichten entstehen.

Was eine Verknüpfung ist: eine Verbindung zwischen einer Datei im Datenraum und einer Stelle im Zwilling — einer Aktivität, einem Bauteil oder einem Ort in der 3D-Tour. Die Datei wird dabei nicht kopiert und nicht verschoben. Sie bleibt genau ein Mal im Datenraum liegen, mit ihren Rechten. Die Verknüpfung ist ein Zeiger, kein zweites Exemplar. (Das ist der Grund, warum es keine „Anhänge" gibt, die neben dem Datenraum ein zweites Leben führen.)

Ziel: Der Wartungsvertrag liegt im Datenraum und soll am Aufzug hängen.

1. Datei markieren → Drei-Punkte-Menü → „Mit dem Zwilling verknüpfen".
2. Wählen, womit: Aktivität · Bauteil im Modell · Ort in der 3D-Tour. Suche und Struktur wie in AK19

— keine zweite Ordnung (T16).

1. Bestätigen.

AbbruchSchließen ohne Auswahl → nichts geändert.

FehlerEs gibt kein Modell und keine 3D-Tour im Projekt → der Weg ist gesperrt mit Grund („Für dieses Objekt gibt es noch keinen Zwilling") und dem Weg zum Anlegen (R89).

ErgebnisDie Datei zeigt rechts „Verknüpft · 1 Aktivität · Aufzug A"; die Aktivität zeigt die Datei. Eine Verbindung, an zwei Stellen sichtbar — nicht zwei Dateien.

Ziel: In der Aktivität „Aufzug TÜV-Prüfung" fehlt der Wartungsvertrag.

1. Aktivität → „Datei hinzufügen". Zwei Möglichkeiten in einem Fenster:

• Aus dem Datenraum wählen (Voreinstellung) — der Ordnerbaum, gefiltert auf das Projekt.
• Neue Datei hochladen — sie landet im Datenraum, im Ordner, der zur Kategorie der

Aktivität passt (Vorschlag, änderbar), und ist von dort an verknüpft.

1. Bestätigen.

Regel dazuEs gibt keinen dritten Ablageort. Ein Upload aus einer Aktivität ist ein Upload in den Datenraum — mit den Rechten des Ziel-Ordners (wie jeder andere Upload). Nur bei einem Gast ist es anders: seine Dateien hängen an der Aktivität und er sieht den Datenraum nie (R79, R80).

FehlerKein Hochladerecht im vorgeschlagenen Ordner → der Ordner-Vorschlag ist gesperrt mit Grund, ein anderer Ordner wählbar, sonst Anfrage (R89).

ErgebnisDieselbe Verbindung wie in ZW1. Welchen Weg man genommen hat, ist danach nicht mehr erkennbar — und das ist beabsichtigt.

1. An der Datei (rechtes Panel, „Verknüpft") oder an der Aktivität → Verbindung lösen.
2. Rückfrage: *„Die Datei bleibt im Datenraum, die Aktivität bleibt bestehen — nur die Verbindung

entfällt."*

ErgebnisNichts wird gelöscht. Protokolleintrag (R27).

Gebaut 03.08.2026:

Warum der Ziel-Ordner groß steht und nicht im Kleingedruckten: Weil dort die Rechte greifen. Ein Upload aus einer Aktivität ist ein Upload in den Datenraum — wer das erst nach dem Hochladen merkt, hat eine Datei an einer Stelle liegen, die er nicht wollte.

ZW3 (Verknüpfung lösen) braucht keinen eigenen Bildschirm: Der Weg steht an der Datei im rechten Panel („Verknüpft · 1 Aktivität · Aufzug A") und an der Aktivität. Die Rückfrage sagt, was nicht passiert: „Die Datei bleibt im Datenraum, die Aktivität bleibt bestehen — nur die Verbindung entfällt."

Was die Abläufe über die Lücken sagen

Die Befundliste Doku 61 nannte elf fehlende Bildschirme. Nach dem Durchgehen der Wege ist klarer, was davon wirklich ein eigenes Bild braucht:

Fünf eigene Bildschirme, zwei Erweiterungen bestehender, ein Muster. Das ist deutlich weniger als elf — und die fünf tragen zusammen das, was heute im Datenraum vom entschiedenen Rechtemodell fehlt.

Was zuerst

1. D11 Ordner-Rechte — ohne ihn gibt es die Schalter nach außen teilen und *zur Unterschrift

geben* nirgends.

1. D13 Eingeschränkte Sicht — daraus leiten sich die Regeln für alle anderen Bildschirme ab.
2. D12 Wer darf das sehen? — die Antwort auf die Frage, die sonst beim Support landet.
3. D15 Freigabe erteilen und D14 Protokoll.
4. Danach die Erweiterungen (D16, D19, D18) und die Aufräum-Befunde A1 bis A12 aus

Doku 61 in einem Durchgang.

Aktivitäten

Was das hier ist: Für jeden Weg durch die Aktivitäten: Ziel, Schritte, Abbruch, Fehler, Ergebnis — dieselbe Form wie im Datenraum (Doku 63) und in Abschnitt 5 der Spezifikation 57. Erst wenn die Wege stehen, sieht man, welche Bildschirme wirklich fehlen. Die Antwort darauf steht am Ende. Grundlage: die Befundliste Doku 66 und die Entscheidungen Doku 62, insbesondere D2 (zwei Tore), D4 (die KI ist ein Leser) und D6 (gesperrt statt versteckt).

0 · Die Bildschirme und ihre Kennungen

Vorhanden:

Fehlend, aus den Abläufen unten hergeleitet — die vier wichtigsten sind am 02.08. abends gebaut worden und liegen in mockups-v2/2030-aktivitaet-wege.html:

0.1 Was für alle Abläufe gilt

Damit es unten nicht dreißigmal wiederholt wird:

• Zwei Tore. Das Rechtemodell sagt, ob jemand in diesem Projekt überhaupt Aktivitäten sieht;

die Sichtbarkeit an der Aktivität sagt, welche davon. Tor 2 kann nur enger machen (D2).

• „Nur für mich" heißt: für alle anderen nicht vorhanden — keine Zeile, kein Zähler, kein

Hinweis, dass es sie gibt. Auch die KI kennt sie nicht (R76, R87).

• Fehlende Rechte verstecken keine Funktionen. Das Bedienelement bleibt sichtbar, ist gesperrt,

nennt den Grund und bietet Anfragen an (R89). Prüfbar ist die Wirkung: es entsteht keine Zuweisung, keine Einladung, kein Auftrag.

• Zuweisen geht nur an Personen, die hier Aktivitäten sehen dürfen. Alle anderen stehen

ausgegraut mit Grund in der Liste, nicht unsichtbar (R77, R78).

• Externe werden Gäste. Ein Gast sieht die ihm zugewiesenen Aktivitäten und nie den Datenraum;

seine Dateien hängen an der Aktivität (R79, R80).

• Die KI ist ein Leser wie jeder andere — kein zweiter Speicher, kein automatisches Einfließen,

keine Abschlussfrage. Offene Aktivitäten werden in Antworten als Arbeitsstand gekennzeichnet (R83, R86).

• Jede Zuweisung, jede Sichtbarkeits- und jede Statusänderung steht im Protokoll (R27).
• Abbrechen mit geänderten Eingaben fragt nach (R51); Speichern bleibt auf der Seite (R20).
• Fünf Zustände je Bildschirm: lädt, leer, gefüllt, Fehler, keine Berechtigung (R49).

AA · Anlegen

Ziel: Etwas festhalten, das keine Stelle im Gebäude hat (ein Vertrag, eine Frist).

1. AK1 → „Hinzufügen" oben rechts oder Tastenkürzel.
2. AK6 öffnet. Titel und Typ genügen — alles andere ist optional.
3. „Aktivität erstellen".

Abbruch„Abbrechen" mit Eingaben → Rückfrage (R51).

FehlerTitel oder Typ fehlt → AK7, rot am Feld und in der Fußzeile, Knopf gedimmt.

ErgebnisDie Aktivität steht oben in AK1, für den Verfasser markiert als neu.

Regel dazuDer Typ steuert das Formular. Information zeigt weder Frist noch Priorität, Erinnerung oder Wiederholung — sie hat keine. Aufgabe zeigt sie (Befund F27).

Ziel: „Hier ist der Wasserfleck" — und alle finden die Stelle wieder.

1. AK9, Werkzeug „Aktivitäten" → „Direkt Position setzen".
2. In das Panorama klicken. Der Pin sitzt; AK6 öffnet mit Screenshot und Ort bereits angehängt.
3. Speichern.

AbbruchVor dem Speichern → der Pin verschwindet mit.

FehlerKlick trifft keine Tiefe (Himmel, Spiegelung) → „Hier lässt sich keine Position bestimmen — bitte auf eine Fläche klicken." Kein stiller Fehlschlag.

ErgebnisVerortete Aktivität. Der Pin ist nachträglich verschiebbar — am besten aus zwei Blickrichtungen prüfen.

Ziel: Die Aufgabe hängt an genau dieser Tür, diesem Aufzug, dieser Lüftung.

1. AK6 → „3D-Element hinzufügen" → AK19.
2. Bauteil finden: im Modell anklicken oder über die Suche oder über die Struktur der

IFC-Datei — dieselbe Struktur wie im Viewer (T16), keine zweite Ordnung.

1. „Zur Aktivität hinzufügen".

AbbruchZurück ohne Auswahl → AK6 unverändert.

FehlerKein Modell im Projekt → der Weg ist gesperrt mit Grund: „Für dieses Objekt gibt es noch kein Modell" + Weg zum Anlegen (R89).

ErgebnisDas Bauteil hängt als Bezug an der Aktivität; ihre Eigenschaften (Fläche, Volumen) stehen zur Verfügung. Offen aus T11 → AK20: Wer mehrere Flächen gemessen hat, wird einmal gefragt: eine Aktivität für alle oder je Fläche eine. Voreinstellung: eine, weil eine Maßnahme meist eine Maßnahme ist.

Ziel: Aus dem Betrachten direkt in die Arbeit.

1. Markierung setzen → „Aktivität daraus".
2. AK6 mit angehängtem Bild und Bezug.

Regel dazu (B3): Ob der Bezug als Fläche, Bauteil oder Bild gilt, entscheidet der Inhalt, nicht die Ansicht, aus der er kommt. Eine Markierung im 3D-Modell ist eine Markierung; ein angeklicktes Bauteil im 2D-Plan ist ein Bauteil.

AB · Zuweisen und Zuständigkeit

Ziel: Jemand anderes soll das übernehmen.

1. AK4 → „Zuständig & Termin · Ändern" → AK10.
2. Die Liste zeigt alle Personen des Mandanten. Wer in diesem Projekt keine Aktivitäten sehen

darf, steht ausgegraut mit Grund: „sieht in diesem Projekt keine Aktivitäten" (R77).

1. Person wählen → speichern.

AbbruchSchließen ohne Auswahl → nichts ändert sich.

FehlerDie gewünschte Person ist gesperrt → aus der gesperrten Zeile führt ein Weg heraus (R78): Wer Nutzer verwalten darf, springt ins User-Management; wer nicht, löst eine Anfrage an einen Administrator aus → AK12.

ErgebnisZuständigkeit gesetzt, Person benachrichtigt, Protokolleintrag.

Ziel: Zwei Personen arbeiten daran. Wie AB1, mehrere Personen wählbar. Eine davon ist verantwortlich — sonst fühlt sich niemand zuständig. Die Verantwortliche steht zuerst und trägt das Wort „Verantwortlich".

Ziel: Eine Frage an immorise stellen oder ein Problem melden — jemand außerhalb des eigenen Teams soll sich darum kümmern.

Berichtigt am 05.08.2026: Hier stand, die Auswahl führe weiter zu einem Auftrag mit Preis, und wer kein Bestellrecht habe, sehe den Eintrag gesperrt. Beides war ein Missverständnis (siehe R33, berichtigt). immorise auszuwählen ist eine Zuweisung wie jede andere.

1. Zuständig-Feld öffnen → AK10. Oben in derselben Liste steht immorise GmbH, mit derselben

Auswahlmarke wie eine Person und der Notiz, dass es nicht im eigenen User-Management steht (R32, R28).

1. Auswählen, speichern. Weiter mit AB4.

Warum der Eintrag überhaupt dort steht: immorise taucht im Rollensystem des Kunden nicht auf. Ohne diesen Eintrag wäre immorise über die Plattform nicht erreichbar.

ErgebnisEine Aktivität, deren Zuständiger immorise ist — ohne Preis und ohne Freigabe.

AB4 / AB5 — hinfällig, weil sie auf einem Missverständnis beruhten

Berichtigt am 05.08.2026. Hier standen zwei Abläufe: „immorise beauftragen — mit Bestellrecht" (Auftragsart, Umfang, Fläche, Preis, Termin, Knopf „Kostenpflichtig beauftragen") und „ohne Bestellrecht" als Freigabe-Anfrage. Beides gehört nicht in die Aktivitäten.

Verkauft werden die Twin Factory und die Verarbeitung hochgeladener Punktwolken, BIM-Modelle und Pläne. Die laufen über ihren eigenen Weg mit eigenem Bezahlfenster (siehe Doku 84, §2 und §3.2a). Eine Aktivität an immorise ist etwas anderes und Kleineres: eine Anfrage (R33, berichtigt).

Ziel: Eine Frage stellen, ein Problem melden — oder ankündigen, dass man etwas bestellen will.

1. Zuständig-Feld öffnen → AK10. immorise steht oben in derselben Liste, mit demselben

Auswahlzeichen wie eine Person (R32).

1. Auswählen, speichern. Kein Preis, keine Auftragsart, kein Bezahlschritt.
2. Die Aktivität verhält sich wie jede andere: Titel, Beschreibung, Verlauf, Anhänge.

Was dabei entsteht: immorise sieht diese Aktivität und was daran hängt — der Zugriff steht im Protokoll. Das ist der Weg, auf dem immorise überhaupt in ein Projekt kommt, denn immorise steht nicht im User-Management des Kunden (R28).

ErgebnisEine offene Anfrage bei immorise, sichtbar wie jede Aktivität.

Wohin der Auftrag und die Freigabe gewandert sind. Der Gedanke war richtig, nur am falschen Ort: Wer im Projekt kein Bestellrecht hat, darf keine Verarbeitung auslösen und muss sie anfragen können. Das gehört dorthin, wo bezahlt wird. Am 05.08. umgewidmet statt gelöscht — die drei Bildschirme stehen jetzt im Verarbeitungs-Weg und heißen:

Kein Inhalt ist verloren, und eine echte Lücke ist geschlossen: Der Fall „kein Bestellrecht" fehlte im Verarbeitungs-Weg vorher ganz. Ausführlich in Doku 84.

Die Richtung ist wichtig: Bestellung → Aktivität, nicht umgekehrt. Damit ein Auftrag verfolgbar bleibt, entsteht dazu eine Aktivität mit dem Status In Bearbeitung bei immorise. Eine Aktivität, die jemand an immorise zuweist, ist dagegen eine Anfrage und kostet nichts (R33).

AC · Arbeiten an einer Aktivität

Ziel: Den Stand fortschreiben.

1. Direkt in der Zeile (AK1) oder im Status-Feld (AK4).

Regel: Der Statuswechsel geht überall gleich — dasselbe Bedienelement in Zeile, Vorschau und Detail. Heute hat nur eine Zeile ein Auswahl-Zeichen (Befund A4).

ErgebnisStatus gesetzt, Protokolleintrag, Zuständige benachrichtigt.

Ziel: Fertig.

1. AK4 → „Erledigt" als eigener, sichtbarer Knopf — nicht versteckt in einem Auswahlfeld

(Befund F13).

1. Erledigt-Datum und Person werden festgehalten.

FehlerPflichtangaben, die eine Kategorie verlangt (z. B. Prüfnachweis bei Sicherheit & Prüfung), fehlen → Hinweis mit dem, was fehlt. Kein Zwang, aber eine klare Ansage.

ErgebnisAktivität in AK5. Es wird nichts gefragt, nichts fließt automatisch irgendwohin (D4) — die Daten sind da, die Leserechte gelten, die KI liest daraus wie jeder andere.

Ziel: Rückfrage stellen.

1. AK4 → Kommentarfeld, @ erwähnt eine Person.

FehlerErwähnte Person darf die Aktivität nicht sehen → beim Tippen Hinweis, nicht nach dem Absenden: „Tim sieht diese Aktivität nicht — zuweisen oder Sichtbarkeit ändern?" (R77).

ErgebnisKommentar steht, Erwähnte bekommen eine Mitteilung.

Ziel: Der Prüfbericht gehört dazu.

1. AK4 → „+ Aus Datenraum" → Auswahl nur aus dem, was die Person selbst sehen darf (R65, R16).
2. Anhängen.

Regel (Befund F16): Der Anhang wird mit der Aktivität sichtbar, nicht mit dem Datenraum. Wer die Aktivität sieht, sieht die Datei — auch ein Gast, der den Datenraum nie betritt. Das steht am Bildschirm, wenn eine Aktivität Gäste hat: „Diese Datei wird auch für den Gast Herrn Weber sichtbar."

FehlerDie Datei liegt in einem Ordner, den die Person nicht teilen darf → gesperrt mit Grund und Anfrage-Weg (R54, R89).

Ziel: Foto vom Schaden anhängen.

1. AK4 → „Datei hochladen".

Regel: Ein Gast lädt an die Aktivität, nie in den Datenraum (R80). Der Verantwortliche entscheidet danach, ob und wohin die Datei im Datenraum abgelegt wird — mit einem Knopf an der Datei: „In den Datenraum übernehmen".

Ziel: Aus einer Notiz wird eine Sache fürs Team.

1. AK4 → AK18: Nur für mich ↔ Für alle im Projekt.
2. Beim Wechsel auf Für alle eine Zeile Wahrheit: *„Ab jetzt sehen alle im Projekt diese

Aktivität — auch die bisherigen Kommentare."* Umgekehrt: Für alle → Nur für mich geht nur, solange niemand anderes kommentiert oder zugewiesen ist. Sonst gesperrt mit Grund.

ErgebnisSichtbarkeit gesetzt, Protokolleintrag.

Ziel: Weg damit.

1. AK16 (Zeilenmenü) oder AK4 → „Löschen" → AK17 mit Rückfrage.

Regel: Eigene Einträge löscht man selbst (R87). Fremde zu löschen ist ein Recht, kein Normalfall — wer es nicht hat, sieht den Knopf gesperrt mit Grund (R89).

FehlerErledigte Aktivitäten werden nie automatisch gelöscht. Endgültiges Löschen einer erledigten Aktivität braucht das Recht und eine Rückfrage.

ErgebnisWeg aus allen Listen; der Protokolleintrag über das Löschen bleibt.

AD · Zusammenarbeit nach außen

Ziel: Der Aufzugsmonteur soll den Schaden sehen und antworten.

1. AK6 oder AK4 → „Externen einladen" (heute missverständlich „Per E-Mail teilen", Befund F24) →

AK13.

1. AK13 sagt in einem Satz, was daraus wird: *„Herr Weber bekommt einen Gastzugang. Er sieht

diese eine Aktivität mit ihren Anhängen — sonst nichts. Den Datenraum sieht er nie."* (R79)

1. Einladen.

FehlerWer selbst nicht einladen darf, sieht den Weg gesperrt mit Grund und löst daraus eine Anfrage aus — keine stille Ablehnung (R82, R73).

ErgebnisGast eingeladen, erscheint in der Nutzerliste als Gast mit der Angabe, über welche Aktivität er hereinkam.

→ AK14 Ziel: Beweisen, dass die Regel greift. Der Gast landet direkt in der Aktivität, nicht in einem Portfolio (R15). Er sieht: Titel, Beschreibung, Anhänge, Kommentare, den Ort — und wenn die Aktivität verortet ist, den Zwilling für genau diese Stelle (R81). Er sieht keinen Datenraum, keine anderen Aktivitäten, keine Nutzerliste. Was er nicht darf, ist nicht angedeutet — hier gilt die Ausnahme von R89, weil die Sperre sonst die Existenz verriete.

→ AK22 Ziel: Jemandem die Stelle zeigen.

1. AK4 → „Teilen".
2. Eine Zeile Wahrheit: *„Wer diesen Link öffnet, sieht die Stelle im Zwilling — dieses Objekt,

diese Verortung. Nicht das übrige Gebäude."* (R81)

FehlerOhne Teilen-Recht gesperrt mit Grund und Anfrage-Weg (R54, R89).

AE · Finden, Filtern, Übersicht

Ziel: „Wo war das mit dem Aufzug?"

1. AK1 → Listensuche (Titel, Beschreibung, Kommentare) oder Filter.

Regel (Befund A5): Zwei Suchfelder brauchen zwei Beschriftungen — oben „Alles durchsuchen", in der Liste „In diesen Aktivitäten suchen".

FehlerKein Treffer → nicht die leere Fläche, sondern die zuletzt geänderten Aktivitäten als Angebot — dieselbe Haltung wie im leeren Zustand (2030-aktivitaeten-leer, R15).

ErgebnisDie Suche findet nur, was die Person sehen darf. Eine Aktivität Nur für mich einer anderen Person erzeugt keinen Treffer und keinen Hinweis (R76).

Ziel: „Was hängt am Gebäude?" AK1 → Filter „Nur verortete" (als Pille, nicht als Beschriftung — Befund A6).

Ziel: Nachweis führen: Was ist im Juli passiert?

1. AK1 → Filter „Erledigte" → AK5.
2. Gruppiert nach Zeit, mit Datum, Person und Nachweis-Anhängen.

Was hier nicht mehr steht: kein „Wissen automatisch gesichert", kein „Wissen im Zwilling ✓", keine Historie in einem zweiten Speicher (D4 — Befunde F19–F21). Was stattdessen dort steht: die Nachweis-Sicht — was ist erledigt, wer hat es erledigt, welcher Nachweis hängt dran, und ein Weg, das als Bericht auszugeben.

ErgebnisEin Zeitraum ist belegbar.

→ AK21 Ziel: Wer zwölf Objekte betreut, will nicht zwölfmal klicken. Gehört ins Cockpit — dort steht die Zusammenfassung, der Klick führt in das Projekt. Die Aktivitätenliste selbst bleibt projektgebunden (Befund F7).

Ziel: Zehn Aufgaben auf einmal zuweisen.

1. AK1 → „Auswählen" → AK2 → markieren → Sammelaktion.

Die Aktionen: Status ändern · Zuständig ändern · Verknüpfen · Sichtbarkeit · Löschen. Das heutige rote „Ausblenden" entfällt — es gibt Sichtbarkeit und es gibt Löschen, nichts dazwischen (R87, Befunde F8/F9).

FehlerEnthält die Auswahl Aktivitäten, an denen die Person die Aktion nicht darf → die Aktion läuft für die erlaubten und sagt danach klar: „8 von 10 geändert — bei zweien fehlt dir das Recht." Kein stiller Teil-Erfolg.

AF · Zustände und Rechte

→ 2030-aktivitaeten-leer Nicht die leere Fläche, sondern der Einstieg: „Hier ist noch nichts. Halte fest, was am Gebäude zu tun ist" + der Knopf zum Anlegen + der Hinweis, dass sich Aktivitäten in der 3D-Tour verorten lassen (R15).

→ 2030-aktivitaeten-gesperrt Der Bereich ist sichtbar, aber gesperrt, nennt den Grund (Rolle „Betrachter" · Projekt Quartier Neckarbogen) und bietet anfragen an (R89, R73). Der Bereich verschwindet nicht aus dem Menü — das würde verbergen, was die Plattform kann.

→ 2030-aktivitaeten-fehler Was schiefging, was das für die Person heißt, was sie tun kann. Kein Fehlercode allein.

→ 2030-aktivitaeten-laedt Die Struktur ist schon da — Kopf, Werkzeugleiste und Spaltentitel; die Platzhalter tragen dasselbe Spaltenraster wie eine echte Zeile, damit beim Nachladen nichts springt. Zahlen, die noch nicht bekannt sind, bleiben leer — auch in der Navigation.

Geändert am 05.08.2026: Diese vier Zustände lagen als eine Vergleichstafel nebeneinander (2030-ak15-zustaende) — ein Regelblatt, kein Bildschirm. Jetzt ist jeder Zustand ein echter Bildschirm im App-Rahmen, der zeigt, in welcher Situation man ihn sieht. Die Tafel ist entfernt; die allgemeine Geltung für Datenraum, Portfolio, Viewer und Reports steht in den Erklärzeilen und in R49.

1 · Was daraus zu bauen ist

Sofort, weil es einer Entscheidung widerspricht:

Die echten Lücken:

Später, mit dem jeweiligen Bereich: AK19 (3D-Element mit Suche — mit dem Viewer), AK20 (viele Flächen — T11, mit dem Viewer), AK21 (alle Projekte — mit dem Cockpit), AK22 (Teilen — mit den Mitteilungen).

2 · Was in andere Bereiche abgegeben wird

• Mitteilungen: die Twin-Factory-Anfrage (R26) und die Ablehnung mit Begründung.
• User-Management: der Gast erscheint in der Nutzerliste mit der Aktivität, über die er kam.
• Cockpit: „meine Aufgaben über alle Projekte" (AK21).
• Viewer: „Floor" → deutsche Bezeichnung, die Struktur-Suche für Bauteile (AK19), T11 (AK20).
• Datenraum: aus dem Dokument ein Weg zurück zu den Aktivitäten, die es verwenden (Q-A4).

Personen und Rollen

5 · Abläufe

28 Abläufe, jeder mit Schritten, Abbruchweg und Fehlerfall. Die Kennungen sind gruppiert: NU Nutzer · RO Rollen · GR Gruppen · PR Projekte · SE Sehen und verstehen · PA Partner und Support. Wo ein Ablauf einen bekannten Fehler behebt, steht er dabei.

Für alle gilt: Abbrechen bei geänderten Eingaben fragt nach (R51), Speichern bleibt auf der Seite (R20), und jede Rechteänderung landet im Protokoll (R27). Das wird unten nicht wiederholt.

NU · Nutzer

Ziel: Eine neue Kollegin bekommt Zugang.

1. Nutzer einladen in B1 → B3 öffnet.
2. E-Mail eintippen. Das System prüft im Hintergrund, ob es das Konto schon gibt.
3. Rolle aus der Vorlagenliste wählen; daneben steht im Klartext, was sie darf.
4. Projekte wählen über B9 — einzeln, als Gruppe oder alle.
5. Einladung senden.

Abbruchjederzeit, mit Rückfrage bei Eingaben. Nichts wird angelegt.

FehlerAdresse ungültig → Hinweis am Feld. Adresse gehört schon zu einem Nutzer dieses Mandanten → „Diese Person ist seit dem 12.03. Nutzerin" mit Verweis auf ihre Seite. Versand scheitert → die Einladung bleibt als versendet, Zustellung fehlgeschlagen stehen und lässt sich erneut senden; sie geht nicht verloren.

ErgebnisEinladung im Zustand versendet, sichtbar in B1b. Noch kein Nutzer.

— behebt F7

1. Wie NU1 bis Schritt 3.
2. Keine Vorlage passt → letzter Eintrag der Auswahl: Neue Rolle anlegen.
3. Ein Bereich klappt an Ort und Stelle auf: Name, Startpunkt (Vorlage, bestehende Rolle oder

Beschreibung), Rechte.

1. Rolle übernehmen → der Bereich schließt, die neue Rolle ist ausgewählt, **E-Mail und alle

bisherigen Eingaben stehen unverändert da** (R17).

1. Weiter mit Schritt 4 aus NU1.

Abbruchschließt nur den Rollen-Bereich; das Einladen läuft weiter.

FehlerRollenname schon vergeben → Hinweis am Feld mit Vorschlag.

ErgebnisRolle angelegt und zugewiesen, ohne den Vorgang verlassen zu haben.

1. In B3 Weitere Person hinzufügen oder Liste einfügen (Adressen durch Komma oder Zeilenumbruch

getrennt).

1. Eine Rolle und ein Projektset gelten für alle.
2. Ab der zweiten Person mit gleicher Rolle bietet das System die Gruppe an (R38).
3. Einladungen senden → eine Bestätigung mit Anzahl.

FehlerEinzelne Adressen ungültig oder bereits vorhanden → diese Zeilen bleiben markiert stehen, die gültigen werden trotzdem verschickt, und die Bestätigung nennt beide Zahlen.

ErgebnisMehrere Einladungen, gegebenenfalls eine neue Gruppe.

— E7

1. Aus B2 oder dem Zeilenmenü in B1: Rechte kopieren.
2. B3 öffnet mit gefüllten Rechtefeldern und leeren Personenfeldern.
3. Übernommen: Firmen-Rolle, Gruppen, Projektzuweisungen, Ausnahmen. Nicht übernommen: Name,

E-Mail, Telefon, Foto.

1. Ausnahmen mit Ablaufdatum werden einzeln zur Bestätigung angezeigt, statt still

mitzuwandern.

1. Personendaten eintragen, senden.

ErgebnisNeue Einladung mit identischen Rechten. Dasselbe funktioniert von einer Gruppe aus.

— behebt F6

1. B2 → Bearbeiten → B4.
2. Änderbar: Name, Telefon, Sprache, Foto, Rolle, Gruppen, Projekte, Ausnahmen.

Nicht änderbar: E-Mail (A10).

1. Die Vorschau zeigt Vorher und Nachher.
2. Speichern → bei Rechteverlust erst die Warnung nach R11, dann speichern.

ErgebnisÄnderung sofort wirksam; die betroffene Person erfährt es beim nächsten Anmelden (W7).

1. B2 → Menü → Deaktivieren.
2. Rückfrage mit den Folgen im Klartext: Anmeldung gesperrt, Rechte eingefroren, Aktivitäten und

Dokumente bleiben erhalten und behalten ihren Namen, Zuweisungen bleiben bestehen.

1. Bestätigen.

FehlerLetztes Administratorkonto → nicht möglich, mit Begründung (R22). Eigenes Konto → nicht möglich (R21).

ErgebnisStatus deaktiviert. Die Person bleibt in Listen sichtbar, grau, mit Datum. Rückgängig über Wieder aktivieren — dieselben Rechte wie vorher.

1. B2 → Menü → Löschen.
2. Das System zeigt vorher, was daran hängt: Anzahl Aktivitäten, hochgeladene Dokumente,

erstellte Messungen, offene Freigaben nach außen.

1. Es bietet zwei Wege an: Deaktivieren (empfohlen, Historie bleibt) oder Löschen.
2. Bei Löschen: Bestätigung durch Eintippen des Namens.

Was mit den Inhalten geschieht: Aktivitäten, Dokumente und Messungen bleiben und tragen weiter den Namen der Person mit dem Zusatz (ehemalig). Offene Freigaben nach außen, die diese Person erstellt hat, erlöschen — sonst hätte niemand mehr Kontrolle darüber. Zuweisungen und Ausnahmen verschwinden.

Fehlerwie NU6.

ErgebnisKonto entfernt, Inhalte erhalten, Protokolleintrag bleibt bestehen.

Deaktivieren ist der Standardweg (E-Entscheidung, bestätigt) — aber nichts darf ewig liegen bleiben. Weder rechtlich noch wirtschaftlich: Ein Löschkonzept ist Pflicht, und Altlasten kosten Speicher.

Rechtlicher Punkt für die Anwaltsliste: Die konkreten Fristen und das Löschkonzept nach Artikel 17 DSGVO gehören juristisch geprüft — zusammen mit dem Support-Zugang (2.8) und der KI-Klausel. Die 30 Tage sind ein fachlicher Vorschlag, kein Rechtsrat.

— behebt A2

1. B2 des eigenen Kontos zeigt statt Bearbeiten den Verweis auf Mein Profil.
2. In B12 änderbar: Name, Telefon, Foto, Sprache, Passwort.
3. Nicht änderbar: eigene Rolle, eigene Gruppen, eigene Projekte, eigene Ausnahmen (R23).

FehlerDirekter Aufruf der Bearbeiten-Adresse des eigenen Kontos → ein erklärender Satz mit Verweis auf Mein Profil, nicht „Zugriff verweigert".

Zustände: versendet → angenommen · abgelaufen (nach 14 Tagen) · zurückgezogen.

1. B1b zeigt alle offenen Einladungen mit Datum.
2. Erneut senden setzt die Frist neu.
3. Adresse korrigieren ändert die Empfängeradresse und verschickt neu — der alte Link wird

ungültig.

1. Zurückziehen macht den Link sofort ungültig.

FehlerAufruf eines abgelaufenen oder zurückgezogenen Links → eine Seite, die das erklärt und sagt, an wen man sich wendet. Keine Fehlermeldung ohne Ausweg.

RO · Rollen

1. B5 → Rolle anlegen → B7, Weg aus Vorlage.
2. Vorlage wählen; die Rechte sind vorbelegt, der Klartext steht daneben.
3. Name anpassen, Rechte feinjustieren, speichern.

ErgebnisRolle ist ab sofort auswählbar und unabhängig von der Vorlage (R1).

— „wie Facility Manager, aber ohne Finanzen"

1. B7, Weg beschrieben. Ein Textfeld.
2. Eingabe absenden → das System schlägt eine Rechteauswahl vor und begründet jede Abweichung

von der genannten Rolle.

1. Der Vorschlag ist vollständig editierbar. Nichts wird ohne Bestätigung gespeichert.

FehlerEingabe nicht verständlich → das System sagt das und bietet den Weg aus Vorlage an, statt zu raten. Dienst nicht erreichbar → derselbe Ausweg. Datenschutz: Es werden nur Rollen- und Rechtebezeichnungen übermittelt, keine Kunden-, Objekt- oder Personendaten (E5).

1. B6 → Bearbeiten → B7.
2. Beim Speichern erscheint die Vorschau: *„Betrifft 12 Personen. 3 verlieren den Zugriff auf den

Datenraum, 12 gewinnen das Recht, Aktivitäten anzulegen."* Die Namen sind aufklappbar (R11).

1. Bestätigen oder zurück.

ErgebnisÄnderung wirkt sofort für alle Trägerinnen der Rolle.

1. B5 → Zeilenmenü → Duplizieren.
2. B7 öffnet mit allen Rechten und dem Namen „… (Kopie)", der sofort geändert werden soll.

ErgebnisNeue eigenständige Rolle. Keine Verbindung zum Original.

1. B6 → Löschen.
2. Hat die Rolle keine Trägerinnen: einfache Rückfrage, fertig.
3. Hat sie welche: Das Löschen ist nicht einfach bestätigbar. Das System verlangt eine

Ersatzrolle und zeigt, wer betroffen ist und was sich für jede Person ändert.

1. Nach Bestätigung werden alle Trägerinnen auf die Ersatzrolle umgestellt, dann wird gelöscht.

FehlerSystemrolle → gar nicht löschbar (R2).

ErgebnisNiemand bleibt ohne Rolle zurück. Es gibt keinen Zustand „Nutzer ohne Firmen-Rolle".

B6 zeigt sie vollständig, aber ohne Bearbeiten und ohne Löschen, mit einem Satz, warum (R2).

GR · Gruppen

1. B8 → Gruppe anlegen.
2. Name, Rolle, Mitglieder, Projekte (über B9).
3. Speichern → alle Mitglieder haben ab sofort die Rolle der Gruppe in den Projekten der Gruppe.

Mitglied hinzufügen: wirkt sofort; die Person sieht es beim nächsten Anmelden. Mitglied entfernen: zeigt vorher, was diese Person dadurch verliert (R11).

Es gilt die großzügigere Kombination (R4). Die Klartext-Zusammenfassung nennt beide Gruppen als Quelle, damit nachvollziehbar bleibt, woher ein Recht kommt. Soll die Person weniger dürfen, ist der richtige Weg nicht, eine Gruppe zu ändern, sondern eine Projekt-Ausnahme zu setzen — nur sie wirkt nach unten (R6).

1. B8 → Menü → Löschen.
2. Vorschau: „7 Personen verlieren den Zugang zu 18 Objekten." Wer über eine andere Gruppe oder

die Firmen-Rolle weiterhin Zugang hat, ist ausgenommen und wird getrennt ausgewiesen.

1. Bestätigen.

ErgebnisDie Mitglieder verlieren genau die Rechte aus dieser Gruppe (R5), nicht mehr.

PR · Projekte

Über B9 — aus dem Einladen, dem Bearbeiten oder der Gruppe heraus. Auswahl mit Kästchen, Rolle einmal für die ganze Auswahl (R41). Bereits vergebene Objekte sind gekennzeichnet und nicht erneut wählbar (R39).

1. B2 → Projektliste → Zeile → Ausnahme einrichten.
2. Auswahl: entweder eine andere Rolle für dieses Objekt, oder einzelne Rechte abweichend schalten.
3. Optional ein Ablaufdatum — freiwillig (R8).
4. Speichern. Auf der Nutzerseite steht danach der Klartext-Satz mit dem „außer bei …".

ErgebnisDie Ausnahme ersetzt für dieses Objekt, was Rolle und Gruppen ergeben hätten (R6). Firmenweite Fähigkeiten bleiben unberührt (R9).

— behebt Bug 3 aus dem Testing Heute lassen sich Berechtigungen für Projekte speichern, zu denen die Person gar keinen Zugang hat. Das ist ein toter Klick ohne Wirkung. Soll-Verhalten: Der Fall kann nicht mehr entstehen. Ausnahmen sind nur an bestehenden Zuweisungen einrichtbar; in B9 nicht ausgewählte Objekte bieten kein Ausnahme-Feld an. Wer eine Ausnahme für ein nicht zugewiesenes Objekt anlegen will, bekommt das Objekt in einem Schritt zugewiesen — mit sichtbarem Hinweis: „Das Objekt wird dieser Person zugewiesen, damit die Ausnahme wirken kann."

R52 — Eine Projekt-Ausnahme ohne zugehörige Projekt-Zuweisung kann nicht entstehen. Prüfbar: Der Versuch, eine Ausnahme ohne Zuweisung zu speichern, wird abgewiesen oder erzeugt die Zuweisung mit — nie stillschweigend nichts.

Alle Zuweisungen und Ausnahmen zu diesem Projekt werden mitgelöscht. Vorher zeigt das System, wie viele Personen betroffen sind. Verliert jemand dadurch seinen letzten Zugang und hätte danach gar nichts mehr zu sehen, wird das gesondert genannt — sonst steht die Person nach dem Anmelden vor einer leeren Plattform (R15).

SE · Sehen und verstehen

Die Klartext-Zusammenfassung nach R12. Sie steht an drei Stellen und ist überall wortgleich (R10): auf der Nutzerseite B2, in der Live-Vorschau von B3 und B4, und in der Selbstsicht B11.

— die Gegenfrage Aus einem Projekt oder einem Datenraum-Ordner heraus: eine Liste aller Personen mit Zugang, je Person die Angabe woher — Firmen-Rolle, Gruppe oder Ausnahme — und was sie dort dürfen. Filterbar nach Aktion („wer darf herunterladen?").

R53 — Zu jedem Projekt und jedem Datenraum-Ordner ist in einem Klick eine vollständige Liste der Zugriffsberechtigten mit Begründung abrufbar. Prüfbar: Die Liste stimmt mit der Berechnung aus 2.3 für jede genannte Person überein.

B11. Wer wenig darf, sieht keine leere Seite, sondern einen Satz und den Hinweis, an wen er sich wendet.

B10. Filter nach Person, Projekt und Zeitraum. Support-Änderungen erscheinen als immorise Support (R30).

PA · Partner und Support

1. Multiplikator öffnet B13, trägt Firmenname sowie Name und E-Mail des ersten Administrators ein.
2. Mandant wird angelegt, der Multiplikator richtet das Projekt ein.
3. Übergeben → Einladung geht raus.
4. Bis zur Annahme: änderbar, erneut versendbar, zurückziehbar (R44).
5. Nach der Annahme: Die Person ist Administrator, der Multiplikator verliert die Nutzer- und

Rollenverwaltung in diesem Mandanten und bleibt Mitglied im Projekt (R45).

FehlerTippfehler in der Adresse → über Schritt 4 korrigierbar, keine Sackgasse.

ErgebnisDer Kunde ist Herr seines Kontos und kann den Multiplikator jederzeit entfernen.

1. Das System erkennt drei oder mehr gleiche Ausnahmen bei einer Person (R34) oder fünf insgesamt

(R35) und zeigt den Hinweis.

1. Zwei Wege werden angeboten, jeder mit seiner Folge im Klartext: in die Firmen-Rolle aufnehmen

(gilt dann überall) oder Gruppe daraus machen (gilt für genau diese Projekte).

1. Vorschau nach R11, bestätigen.

ErgebnisWeniger Ausnahmen, unveränderte effektive Rechte. Das System prüft das nach und meldet, falls sich doch etwas verschoben hätte.

Was entschieden ist

154 Regeln, R0 bis R155. Eine Regel ist eine getroffene Entscheidung, kein Vorschlag. Wer eine für falsch hält, schreibt sie auf und fragt, statt sie zu umgehen — so bleibt das Gesamtbild stimmig.

Wer darf was

Ein Rechtesystem, nicht zwei: fünf Aktionen je Bereich — Ansehen, Anlegen, Bearbeiten, Löschen, Teilen. Wo ein Bereich mehr braucht, hängt die Erweiterung an der Spalte, die es betrifft. Dazu Rollen, Gruppen, Projekt-Ausnahmen — und die Regel, dass niemand still Rechte verliert.

2 · Was gelten soll

Wie dieser Abschnitt zu lesen ist: Wo eine Produktentscheidung offen war, steht meine Empfehlung im Text und ist mit **[E*n*]** markiert. Alle zehn stehen am Ende in 2.10 nochmal gesammelt, mit Begründung und der Folge, wenn du anders entscheidest. Beim Lesen genügt es, dort zu widersprechen, wo es sich falsch anfühlt.

2.1 Der Grundsatz

Ein Werkzeug pro Frage — und keine Frage mit dem falschen Werkzeug beantworten.

Der heutige Zustand hat eine einzige Ursache: Es gibt nur ein Werkzeug, die Rolle. Also muss jede Frage mit einer Rolle beantwortet werden — auch die, für die eine Rolle das falsche Mittel ist. Aus „diese eine Person soll bei diesem einen Objekt weniger dürfen" wird Collaborator 3, und die steht dann für immer in der Liste. So sind aus einer Handvoll echter Berufsbilder 24 Rollen geworden (Abschnitt 1.3, N2).

Das Zielmodell trennt drei Fragen und gibt jeder ein eigenes Werkzeug:

Daraus folgt die wichtigste prüfbare Regel des ganzen Konzepts:

2.2 Die drei Werkzeuge im Einzelnen

Die Firmen-Rolle — was jemand kann

Die Firmen-Rolle beschreibt das Berufsbild: Was für eine Art Mensch ist das im System — ein Facility Manager, eine Asset Managerin, ein Mieter, ein externer Planer? Sie gilt firmenweit und ist die Grundlinie in jedem Projekt, zu dem die Person Zugang hat.

Jede Person hat genau eine Firmen-Rolle. [E1]

Das ist eine Änderung gegenüber heute, wo mehrere gleichzeitig möglich sind (Abschnitt 1.4, A6). Der Grund ist nicht Ordnungsliebe: Solange jemand drei Rollen gleichzeitig trägt, lässt sich der Satz „diese Person darf …" nicht bilden — und dieser Satz ist der Kern des ganzen Redesigns. Was heute über eine zweite Rolle gelöst wird, löst künftig eine Gruppe oder eine Ausnahme.

Zwei Dinge stecken in der Firmen-Rolle, die es sonst nirgends gibt:

• Firmenweite Fähigkeiten, die kein Projekt betreffen: Nutzer einladen, Rollen ändern, Projekte

anlegen, Rechnungen der Plattform-Lizenz sehen und — neu, siehe 2.13 — den KI-Assistenten nutzen. Diese sind nicht pro Projekt abweichbar — sie gelten überall oder nirgends.

> R82 — Wer einen Externen einlädt, braucht selbst das Recht, Nutzer einzuladen. Reicht die > eigene Befugnis nicht, wird daraus eine Anfrage (R73), keine stille Ablehnung. > Prüfbar: Ohne Einladerecht entsteht kein Gastzugang, sondern ein Vorgang bei einem Administrator.

• Die Grundlinie je Modul, die in jedem Projekt gilt, solange keine Ausnahme greift.

Korrektur gegenüber der ersten Fassung: Das Auslösen von Twin-Factory-Aufträgen stand hier fälschlich als firmenweite Fähigkeit. Es ist projektbezogen. Der typische Fall: Ein Projekt besteht aus einer hochgeladenen Punktwolke und einem Panorama-3D-Tour; später soll zusätzlich ein Modell daraus entstehen. Das ist kein neues Projekt, sondern eine Bestellung zu diesem Projekt. Wer bestellen darf, ist deshalb ein Projektrecht (R40) — nur der Budgetdeckel bleibt an der Rolle, weil er firmenweit gilt. Bei „Rechnungen sehen" ist die Plattform-Lizenz gemeint — nicht Rechnungen, die im Datenraum eines Objekts liegen. Die unterliegen den Datenraum-Rechten.

Rollen kommen aus Vorlagen. Startset [E2], entstanden aus den A5-Nutzergruppen, gegengehalten mit den 13 alten deutschen Rollen und ergänzt um den Property Manager:

**Schreibweise, festgelegt beim Screen-Abgleich am 03.08. (R48): Portfolio-Manager, Asset-Manager, Property-Manager — mit Bindestrich, wie es die deutsche Rechtschreibung für gemischte Zusammensetzungen verlangt und wie es in allen Bildschirmen steht. Facility Manager bleibt ohne, weil beide Teile englisch sind. Und Geschäftsführung**, nicht „Eigentümer / GF": Ein Schrägstrich-Paar ist genau die Synonymform, die R48 verbietet.

Der Gast — keine zwölfte Vorlage, sondern eine eigene Teilnehmerart

Hier ist eine Verwechslung möglich, und sie muss vorweg geklärt werden: In der Tabelle oben steht „Gast" als Altname, der auf die Vorlage Betrachter abgebildet wird. Das bleibt so. Der Gast, um den es ab hier geht, ist etwas anderes — und ausdrücklich keine Firmen-Rolle:

R79 — Externe bekommen einen Gastzugang und nie Zugang zum Datenraum. Ein Gast sieht die Aktivitäten, die ihm zugewiesen sind — sonst nichts. Prüfbar: Im Menü eines Gastes gibt es keinen Datenraum; der direkte Aufruf einer Datei-Adresse wird abgewiesen.

R80 — Ein Gast lädt Dokumente an die Aktivität, nicht in den Datenraum. Der Verantwortliche entscheidet, ob und wohin es im Datenraum abgelegt wird. Prüfbar: Die Datei eines Gastes erscheint an der Aktivität und in keinem Ordner, bis jemand mit Datenraum-Recht sie ablegt.

R92 — Der Gastzugang endet mit der Aktivität. Voreinstellung: wenn die Aktivität abgeschlossen ist. Ein fester Termin ist wählbar; ein unbefristeter Gastzugang ist es nicht. Prüfbar: Nach Abschluss der Aktivität führt der Einladungslink ins Leere, mit Erklärung.

Warum das keine Rolle ist: Eine Firmen-Rolle gilt firmenweit und ist die Grundlinie in jedem Projekt, zu dem jemand Zugang hat (2.2). Ein Gast hat keinen Zugang zu einem Projekt, sondern zu einer Aktivität — und nur so lange, wie es sie gibt. Ihn als zwölfte Vorlage zu führen würde bedeuten, dass er in Rollenlisten, Rechtevergleichen und Kennzahlen mitläuft, wo er nichts zu suchen hat. Er steht deshalb im Verzeichnis (3.1) als eigener Begriff.

Gezeichnet ist der Weg schon: Externen einladen und Gast-Sicht liegen als Bildschirme in mockups-v2/2030-aktivitaet-wege.html (AK13, AK14), die Ablaufbeschreibung in 67-aktivitaeten-ablaeufe.md, Gruppe AD.

Für den Entwickler: Ein Gast bekommt ein Konto (3.1: ein Konto existiert einmal, mandantenübergreifend), aber keine Firmen-Rolle und keine Projektrechte. Er zählt nicht in die Kennzahl „Nutzer" — steht aber mit eigener Zahl daneben:, und in der Liste mit einer eigenen Zeilenart, die Herkunft und Ende nennt. Korrigiert am 03.08. beim Screen-Abgleich: Hier stand zuerst, ein Gast erscheine „nicht in Listen und Kennzahlen". Das war falsch und wäre gefährlich gewesen. Ein Administrator muss jeden Zugang zu seinem Mandanten sehen und entziehen können — ein unsichtbarer Gast ist eine Hintertür. Richtig ist: Er ist kein Nutzer, aber er ist sichtbar. Der Unterschied zum Support-Zugang (R28) bleibt: Der Support ist für Kunden unsichtbar, weil er zu immorise gehört und vertraglich getragen ist; ein Gast gehört zum Kunden und muss von ihm kontrollierbar sein.

Was nur der Administrator darf

Heute hat ein Administrator keine echten Mehrrechte gegenüber einem Manager — das ist Finding 7 aus dem Testing. Künftig unterscheiden ihn drei Dinge, und nur diese drei:

R58 — Nur der Administrator sieht Lizenz und Rechnungen der Plattform. R59 — Nur der Administrator gibt Twin-Factory-Aufträge frei, die jemand anderes ausgelöst hat (R26). R60 — Der Administrator hat Zugang zu allen Objekten des Portfolios, ohne einzeln zugewiesen zu werden. Ein Manager sieht nur, was ihm zugewiesen ist. Prüfbar: Ein neu angelegtes Objekt erscheint sofort bei jedem Administrator, ohne Zuweisung.

Was ausdrücklich nicht administratorexklusiv ist: Nutzer einladen und entfernen sowie Rollen anlegen und ändern. Das darf auch eine Managerin oder eine Asset Managerin, die ein eigenes Team führt — begrenzt durch R16, sie kann also nie mehr weitergeben, als sie selbst hat. Genau deshalb braucht es dafür keine eigene Sperre.

Festgelegt am 02.08. — mein erster Vorschlag hatte Einladen und Rollenpflege beim Administrator eingeschlossen. Das war zu eng: Wer ein Team führt, muss es auch einrichten können.

Zwei Altrollen sind bewusst nicht übernommen: „Firmenadministrator" geht in Administrator auf — zwei Verwaltungsrollen nebeneinander waren schon vorher niemandem erklärbar. Und „Ansprechpartner" ist keine Rolle, sondern eine Eigenschaft am Objekt („wer ist hier zuständig?"). Sie gehört an das Projekt, nicht in das Rechtesystem — sonst wiederholt sich der Fehler N4, bei dem eine Funktion als Rolle geführt wird.

R1 — Vorlagen sind Startpunkte, keine Zwangsjacke: Eine aus der Vorlage erzeugte Rolle ist danach frei änderbar und hängt nicht mehr an der Vorlage. Prüfbar: Ändert man die Vorlage, ändern sich bereits erzeugte Rollen nicht.

R2 — Systemrollen (Root Owner) sind sichtbar, aber nicht änderbar und nicht löschbar. Prüfbar: Auf ihrer Seite existieren die Schaltflächen zum Bearbeiten und Löschen nicht, und der direkte Aufruf der Bearbeiten-Adresse wird abgewiesen. (Heute bereits erfüllt, siehe S3.)

Die Gruppe — wer zusammengehört

Eine Gruppe ist ein Bündel aus drei Angaben: diese Personen · diese Projekte · diese Rolle. Beispiel: Gruppe „Asset Management Süd" — zwölf Personen, achtzehn Objekte, Rolle Asset Manager.

Was sie löst: Heute wird jede Person einzeln mit jedem Projekt verdrahtet. Bei sechzehn Projekten sind das sechzehn Blöcke im Formular (Abschnitt 1.4, A14). Über eine Gruppe ist es ein Vorgang, und eine neue Kollegin ist mit einem Handgriff vollständig eingerichtet.

R3 — Eine Person kann in mehreren Gruppen sein. R4 — Gruppen erweitern die Rechte, sie schränken nie ein. Ist eine Person in zwei Gruppen, die im selben Projekt unterschiedliche Rollen tragen, gilt in diesem Projekt die großzügigere Kombination — und die Klartext-Zusammenfassung nennt beide Gruppen als Quelle. Prüfbar: Person in Gruppe A (darf ansehen) und Gruppe B (darf bearbeiten) darf in den Projekten beider Gruppen bearbeiten, und die Begründung nennt Gruppe B. R5 — Wird eine Gruppe gelöscht, verlieren die Mitglieder genau die Rechte, die aus dieser Gruppe kamen — nicht mehr und nicht weniger. Vor dem Löschen zeigt das System, wie viele Personen wie viele Projektzugänge verlieren.

Gruppen sind von Anfang an sichtbar. [E3] (Geändert — mein erster Vorschlag war, sie zu verstecken, bis sie gebraucht werden. widersprochen, und zu Recht: Wer nicht weiß, dass es Gruppen gibt, glaubt beim dritten Nutzer, er müsse das jetzt hundertmal einzeln machen. Genau dieses Gefühl soll das Redesign beseitigen.)

Sichtbar heißt aber nicht „im Weg":

R37 — Der Gruppen-Bereich ist immer erreichbar, steht aber eine Ebene unter Nutzern und Rollen. Ist noch keine Gruppe angelegt, erklärt er in einem Satz, wofür Gruppen da sind, statt eine leere Liste zu zeigen. Prüfbar: Ein frischer Mandant ohne Gruppen zeigt dort eine Erklärung und einen Anlege-Knopf, keine leere Tabelle.

Das dreht die Wirkung um: Statt dass jemand fünfzehnmal dasselbe einträgt und erst danach merkt, dass es einen kürzeren Weg gab, sieht er den kürzeren Weg beim zweiten Mal.

Die Projekt-Ausnahme — wo einmal etwas anderes gilt

Der Fall: Jemand soll bei einem einzelnen Objekt nur kurz hineinsehen, aber nicht in die Verträge. Heute erzeugt das eine neue Rolle. Künftig ist es eine benannte Ausnahme an der Person, in genau diesem Projekt.

R6 — Die Projekt-Ausnahme ersetzt für dieses eine Projekt, was Rolle und Gruppen ergeben hätten. Sie kann nach oben und nach unten abweichen. Prüfbar: Person mit Rolle „Asset Manager" und Ausnahme „Betrachter" in Objekt X darf in Objekt X nur ansehen, in allen anderen Objekten weiterhin alles, was Asset Manager darf.

Warum Ersetzen und nicht Ergänzen: Nur so lässt sich einschränken. Bei „es gilt immer die großzügigste Einstellung" wäre die Geschäftsführung' Beispiel nicht abbildbar — die Einschränkung käme nie zum Tragen. Ausnahmen sind damit das einzige Werkzeug, das nach unten wirkt; Rolle und Gruppen wirken nur nach oben. Diese Asymmetrie ist beabsichtigt und macht das Ergebnis vorhersagbar.

Ergänzt am 04.08.2026 — „Woher weiß ich überhaupt, dass jemand eine Ausnahme braucht?" Der Einwand trifft eine echte Lücke. Bisher setzte das Modell voraus, dass die zuweisende Person schon weiß, wo es klemmt. Das weiß sie nicht — sie kennt die Person, nicht den Rechteumfang.

R118 — Beim Zuweisen einer Person zu einem Projekt steht neben der Rolle, was sie in diesem Projekt bedeutet — und was sie dort nicht kann. Zwei Zeilen in Klartext, aus derselben Berechnung wie R12: „Darf hier Aktivitäten anlegen und Dokumente mit Wasserzeichen laden. Kann hier keine Verträge im Original laden und keine Twin-Factory-Bestellung auslösen." Von dort führt ein direkter Weg zur Ausnahme.

WarumDie Entscheidung über eine Abweichung fällt genau hier — also muss die Information hier stehen, nicht in einem anderen Bereich, den man vorher hätte lesen müssen. Prüfbar: In der Projektzuweisung sind Fähigkeiten und Grenzen der gewählten Rolle genannt, und die Ausnahme ist von dort in einem Klick erreichbar.

R7 — Jede Ausnahme ist sichtbar begründet und mit einem Klick rücknehmbar. Auf der Nutzerseite steht sie im Klartext: „Asset Manager — außer bei Objekt Alaunstraße, dort nur Betrachter." R8 — Eine Ausnahme kann ein Ablaufdatum bekommen — als Angebot, nicht als Pflicht. Das Feld steht direkt neben der Ausnahme, im selben Arbeitsschritt; wer es leer lässt, richtet eine dauerhafte Ausnahme ein, und das System fragt nicht nach. Nur wenn ein Datum gesetzt wurde, gilt danach wieder die Rolle und die betroffene Person wird einmal informiert. [E4] Prüfbar: Eine Ausnahme ohne Datum bleibt unbegrenzt bestehen und erzeugt keinerlei Hinweise oder Nachrichten. Eine Ausnahme mit Datum in der Vergangenheit wirkt nicht mehr.

Der Fall dahinter war „soll mal kurz reingucken" — dafür ist die Befristung genau richtig. Aber eine Abweichung darf auch schlicht dauerhaft sein, ohne dass jemand sie regelmäßig bestätigen oder Erinnerungen wegklicken muss. Deshalb ist das Ablaufdatum ein Angebot an der Stelle, an der man die Ausnahme ohnehin einrichtet — und sonst nirgends.

R9 — Firmenweite Fähigkeiten (Nutzer, Rollen, Vertrag, Projekte anlegen) sind nicht per Ausnahme veränderbar. Sie kennen kein Projekt. Prüfbar: In der Ausnahme-Ansicht eines Projekts tauchen die Ressourcen „Nutzer" und „Rolle" nicht auf.

R40 — Das Auslösen einer Twin-Factory-Bestellung ist ein Projektrecht, kein firmenweites. Es kann pro Projekt per Ausnahme gegeben oder entzogen werden. Der Budgetdeckel (R26) bleibt firmenweit an der Rolle. Prüfbar: In der Ausnahme-Ansicht eines Projekts erscheint „Twin Factory: bestellen" als schaltbares Recht; der Budgetbetrag erscheint dort nicht.

Die Gegenprobe: Ausnahmen dürfen nicht zur neuen Unordnung werden

Wenn jede Abweichung eine Ausnahme wird, sitzt „Maria Schmidt, Manager, 20 Ausnahmen" auf der Seite — und das ist genauso unbrauchbar wie 24 Rollen. Nur an anderer Stelle.

Das Zielmodell braucht deshalb nicht nur ein Werkzeug für Abweichungen, sondern auch einen Weg zurück: Das System muss selbst merken, wenn aus Ausnahmen ein Muster geworden ist, und anbieten, sie aufzulösen. Sonst tauschen wir Rollenwildwuchs gegen Ausnahmenwildwuchs.

Damit hat das Modell in beide Richtungen ein Werkzeug: R0 verhindert, dass Abweichungen zu Rollen werden. R34 verhindert, dass sie sich als Ausnahmen stapeln.

2.3 Wie sich die Rechte einer Person berechnen

Für eine Person in einem Projekt, in dieser Reihenfolge:

1. Grundlinie: die Firmen-Rolle.
2. Plus alle Gruppen, die dieses Projekt enthalten — großzügigste Kombination (R4).
3. Ersetzt durch die Projekt-Ausnahme, falls für dieses Projekt eine existiert (R6).
4. Eingeschränkt durch die Ordner-Rechte im Datenraum — die können nur enger machen, nie

weiter (Abschnitt 7).

R10 — Das Ergebnis muss an jeder Stelle der Oberfläche identisch berechnet und identisch formuliert sein. Prüfbar: Der Klartext auf der Nutzerseite, in der Live-Vorschau beim Bearbeiten und in der Selbstsicht „Meine Rechte" ist für dieselbe Person Wort für Wort gleich.

R11 ist die konzeptionelle Antwort auf den Befund aus 1.2 — dort geht heute genau das schief, nur unbemerkt.

2.4 Was in Klartext heißt

„Klartext statt Zahlen" ist beschlossen. Damit es prüfbar wird, hier festgelegt, was ein Klartext-Satz leisten muss:

R12 — Eine Rechte-Zusammenfassung nennt immer drei Dinge: was die Person darf, wo es gilt, und woher es kommt (Rolle, Gruppe oder Ausnahme). Beispiel: „Darf Aktivitäten anlegen und Dokumente ansehen — in 18 Objekten, aus der Gruppe Asset Management Süd. Bei Objekt Alaunstraße nur ansehen (Ausnahme bis 31.10.)." Prüfbar: Kein Satz in der Oberfläche nennt eine Berechtigungsanzahl ohne diese drei Angaben.

R13 — Nirgends steht eine nackte Zahl als Kennzahl. Statt „24 Rollen · 148 Berechtigungen" stehen Kennzahlen, aus denen eine Handlung folgt: „3 Rollen ohne Nutzer", „2 Personen mit mehr Rechten als ihre Gruppe", „7 Ausnahmen laufen diesen Monat ab". Prüfbar: Auf keiner Übersichtsseite steht eine Kennzahl, zu der es keine zugehörige Liste gibt.

Klartext ersetzt die Zahlen — er darf aber nicht die Tiefe ersetzen. Wenn irgendwo eine Rolle steht, muss man von dort aus sofort sehen können, was genau drinsteckt, und es auch gleich ändern können. Nicht in einem anderen Reiter, nicht drei Klicks weiter.

Die Leitlinie dahinter: Einfach als Voreinstellung, vollständig als Möglichkeit. Wer nur jemanden einladen will, sieht Klartext und sonst nichts. Wer wissen will, was „Facility Manager" genau bedeutet, kommt in einem Klick zur Matrix — und muss dafür nicht wissen, dass es einen eigenen Rollen-Bereich gibt.

Wie der Klartext erzeugt wird [E5]: aus festen Textbausteinen, nicht über ein Sprachmodell. Der Satz muss bei jedem Aufruf identisch sein, sofort erscheinen und darf nichts kosten. Ein Sprachmodell kommt nur beim assistierten Rollen-Erstellen zum Einsatz („wie Facility Manager, aber ohne Finanzen") — dort wird freie Eingabe verstanden, und das Ergebnis ist ein Vorschlag, den ein Mensch bestätigt. Datenschutz: In beiden Fällen verlassen nur Rollen- und Rechtebezeichnungen das System, niemals Kunden-, Objekt- oder Personendaten.

2.5 Die Wege auf die Plattform

Deshalb hier für jede Ausgangslage festgelegt, wer einlädt, was die eingeladene Person bekommt und was sie als Erstes sieht. Der letzte Punkt ist der wichtigste — er entscheidet, ob jemand die Plattform versteht.

R14 — Jede eingeladene Person sieht nach der Annahme im Klartext, was sie darf, bevor sie irgendetwas anklickt. Prüfbar: Nach Annahme einer Einladung erscheint eine Zusammenfassung nach R12.

R15 — Niemand landet in einem leeren Bereich. Hat eine Person Zugang zu genau einem Objekt, beginnt sie dort, nicht in einer Liste mit einem Eintrag. Prüfbar: Nutzer mit genau einem Projekt wird nach der Anmeldung in dieses Projekt geleitet.

R16 ersetzt eine ganze Reihe von Einzelregeln und schließt zugleich die Privilege-Escalation-Lücke aus dem Testing (rollenkonzept.md, Finding 4) an der Wurzel.

Aber R16 allein wäre eine Sackgasse — und das Dokument, das dem Entwicklungsteam bereits vorliegt, löst es besser. Von dort übernommen:

Das ist dieselbe Denkfigur wie bei der Twin Factory (R26): Wer nicht selbst darf, löst nicht aus, sondern fragt an — und niemand steht vor einer Tür ohne Klinke. R16 bleibt die harte Grenze (niemand vergibt eigenmächtig mehr, als er hat), R73 ist der Weg darum herum.

Der Multiplikator — kein Sonderfall des Einladens, sondern eine Übergabe

Meine erste Fassung hatte den Multiplikator als eingeschränkten Einlader beschrieben. Nach die Geschäftsführung' Schilderung des echten Ablaufs ist das falsch gerahmt. [E6]

Was tatsächlich passiert: Ein Vermesser, Architekt oder Fachplaner erstellt für seinen Kunden ein Projekt und lädt es auf immorise hoch, um es zu zeigen. Dafür legt er einen neuen Mandanten an in dem er in diesem Moment naturgemäß alles darf, weil er ihn erzeugt hat. Er richtet das Projekt ein. Und dann übergibt er: Er lädt seinen Ansprechpartner beim Kunden ein, der damit die vier Wochen Testzeit bekommt und danach entscheidet, ob eine Lizenz gekauft oder die Daten heruntergeladen werden.

Der springende Punkt: Das ist keine Einladung unter Gleichen, sondern eine Staffelübergabe. Der Kunde muss danach sein eigener Herr sein — eigenes Team aufbauen, Rollen vergeben, und den Multiplikator auch wieder hinauswerfen können, wenn er will.

Daraus folgt, dass „Multiplikator" keine Rolle im Mandanten des Kunden ist, sondern eine Fähigkeit im eigenen Mandanten: darf einen neuen Kundenmandanten anlegen und ihn übergeben. Sie taucht deshalb nicht im Rollen-Set der Kunden auf und verwirrt dort niemanden.

Was aus dem Root Owner wird

Der Ist-Stand am 02.08. zeigt, wie die Übergabe heute behelfsmäßig gelöst ist: Im Kundenmandanten WGA ZT GmbH hält der Planer die Rolle Root Owner mit genau einer Berechtigung, die ALL heißt — angelegt beim Anlegen des Mandanten. Damit kann er alles, ohne eine Rolle definieren zu müssen. Der Gedanke stimmt, die Umsetzung hat drei Probleme: Der Name erklärt sich niemandem, der Zähler zeigt „1 Berechtigung" für unbegrenzte Rechte, und der Partner behält den Vollzugriff dauerhaft, auch lange nachdem der Kunde übernommen hat.

R69 — Root Owner bleibt als technische Systemrolle bestehen, erscheint aber nirgends unter diesem Namen in der Kundenoberfläche. Während der Einrichtung wird der Partner dort als „Projekt-Partner" geführt, mit einem Satz, was das bedeutet und wie lange es gilt. Prüfbar: Die Zeichenfolge „Root Owner" erscheint in keiner Kundenansicht.

R70 — Wo eine Rolle unbegrenzte Rechte hat, steht kein Zahlenwert, sondern das Wort „Alle Rechte". Prüfbar: Für die Systemrolle erscheint nirgends „1 Berechtigung".

Der Auslöser ist genau der Moment: beim Anlegen eines Projekts die Frage „eigenes Projekt oder Kundenprojekt?" (R61). Nur bei „Kundenprojekt" entsteht die Stellung als Projekt-Partner — sonst gibt es sie nicht. Niemand muss vorher wissen, dass er Multiplikator ist, und niemand sieht den Begriff, der ihn nicht betrifft.

Was sich bei der Übergabe genau ändert — die Tabelle für die Entwicklung (ergänzt 04.08.2026, weil im Termin danach gefragt wurde):

Zur Frage „darf der Partner zwei Personen einladen?" [E23] — am 04.08. besprochen, Antwort: nein, es bleibt bei einer. Bei zwei müsste festgelegt werden, ob die Testzeit mit der ersten oder der letzten Annahme startet, was gilt, wenn nur einer annimmt, und wem das Konto gehört. Der Aufwand steht nicht im Verhältnis. Das Ziel — nicht nur ein Administrator im Konto — wird eine Stufe später und einfacher erreicht:

Warum das so und nicht anders. Meine erste Fassung hat den Partner nach der Übergabe auf seine eigenen Hochladungen eingedampft und den Kunden gefragt, ob er ihn behalten will. Das war aus der Sicherheitsbrille gedacht und geschäftlich falsch herum.

Der Multiplikator bringt uns Kunden. Sein Gegenwert dafür ist, im Dunstkreis seines Kunden zu bleiben — als sichtbarer Ansprechpartner, der weiter für ihn arbeiten kann. Genau das macht es attraktiv, den nächsten Kunden auch auf immorise zu holen. Eine Rückfrage direkt nach der Übergabe („soll der überhaupt bleiben?") sät stattdessen Zweifel in genau dem Moment, in dem die Zusammenarbeit gerade erst anfängt.

Die Kontrolle des Kunden bleibt trotzdem vollständig: Der Partner steht sichtbar in der Nutzerliste, ist erklärt, und ist mit denselben zwei Klicks entfernbar wie jeder andere. Was er nicht mehr hat, ist die Verwaltung — Nutzer, Rollen, Vertrag. Das ist die Grenze, die zählt.

Damit sind beide Sorgen gelöst: Der Partner kommt bei einem Tippfehler nicht in die Sackgasse (R44), und er hat nach der Übergabe trotzdem keinen Zugriff mehr auf die Nutzerverwaltung eines fremden Unternehmens (R45). Rollen muss er nie definieren — die übergebene Person bekommt Administrator, alles Weitere entscheidet der Kunde.

Wer Multiplikator sein darf: jeder — ohne Freischaltung

Entschieden am 02.08., gegen meine erste Empfehlung. Ich hatte vorgeschlagen, die Fähigkeit von immorise freischalten zu lassen. Ein Vermesser lädt einen Architekten ein, der Architekt hat kurz darauf selbst einen Kunden — und niemand bei uns weiß davon. Müsste er sich erst bei uns als Partner registrieren, bricht die Kette genau dort ab, wo sich die Plattform verbreiten soll. Die Verbreitung ist wichtiger als die Lücke.

R61 — Jeder Nutzer, der ein Projekt anlegt, wird gefragt: eigenes Projekt oder Kundenprojekt? Bei „Kundenprojekt" entsteht ein neuer Mandant, und der Anlegende wird dort automatisch Projekt-Partner. Keine Freischaltung, kein Antrag, keine Rolle, die vorher existieren muss. Prüfbar: Ein beliebiger Nutzer kann ohne Vorbedingung einen Kundenmandanten anlegen und übergeben.

Die Lücke wird nicht durch eine Hürde geschlossen, sondern dadurch, dass sich Missbrauch nicht lohnt. Drei Mechanismen, keiner davon spürbar für ehrliche Nutzer:

Die Begründung, in zwei Anläufen entstanden. Meine erste Fassung ließ 60 Tage Einrichtungszeit zu — damit wäre genau das Gratis-Arbeiten möglich gewesen, das sie verhindern sollte. Die zweite begrenzte auf zwei gleichzeitige Konten und war ebenso falsch: Ein Vermesser, der die Woche über draußen ist und freitags zehn Aufnahmen hochlädt, hätte an der eigenen Plattform angestanden.

Die Regel darf deshalb nicht an der Menge ansetzen, sondern daran, wozu ein Kundenkonto da ist: Es gehört einem Kunden. Wer eins anlegt, bekommt Zeit, es einzurichten — und muss dann jemanden einladen. Wer niemanden einlädt, hatte keinen Kunden. Das begrenzt kostenlose Nutzung auf rund zwei Wochen je Konto, ohne irgendjemanden im Alltag zu bremsen.

Was offen bleibt, bleibt bewusst offen. Wer sich selbst unter zweiter Adresse einlädt und annimmt, bekommt vier Wochen Testzeit. Verhindern ließe sich das nur mit Hürden, die ehrliche Partner genauso träfen. erst einmal darauf ankommen lassen. Kunden sind nicht darauf aus zu betrügen, und R72 zeigt uns die Fälle, falls doch. Eine Systematik lässt sich nachziehen, wenn es überhaupt vorkommt.

Verwandt, aber ein eigenes Thema: der Empfehlungslink („schau dir immorise an") führt zur Registrierung eines eigenen Mandanten und hat mit der Übergabe nichts zu tun. Er gehört ins Marketing, nicht in diese Spezifikation.

2.6 Der Anlege-Weg — ein Bildschirm, vier Handgriffe

Der Normalfall (W2) muss ohne Nachdenken funktionieren:

1. E-Mail eintippen. Das System erkennt selbst, ob es schon ein Konto gibt (funktioniert heute

bereits und bleibt).

1. Rolle wählen — kurze Vorlagenliste, und daneben steht in Klartext, was sie darf. Nicht

„25 Berechtigungen".

1. Projekte wählen — einzeln, als Gruppe oder „alle".
2. Einladen.

Rechts läuft die Live-Vorschau mit und zeigt durchgehend den Satz nach R12.

Schritt 3 ist der, an dem es heute kippt. Man wählt ein Projekt, dann eine Rolle, dann wieder ein Projekt — aus derselben flachen Liste, in der nichts markiert ist. Man muss selbst im Kopf behalten, welches Objekt man schon vergeben hat. Bei zwanzig Objekten wird das nervig, bei hundert unmöglich, und bei mehreren Nutzern nacheinander verliert man den Überblick vollständig.

Das ist auch die Antwort auf Befund A14 aus Abschnitt 1: Die heutigen sechzehn gestapelten „ZUWEISUNG"-Blöcke sind das Symptom davon, dass Projekt und Rolle immer paarweise gedacht werden. Sobald die Rolle für eine Auswahl gilt statt für ein einzelnes Objekt, verschwindet die Stapelung von selbst.

R18 — Beim Anlegen einer Rolle gibt es drei Wege, alle im selben Bildschirm: aus Vorlage, wie eine bestehende Rolle (Duplikat als Startpunkt), oder beschrieben („wie Facility Manager, aber ohne Finanzen"). Prüfbar: Alle drei führen zu einer speicherbaren Rolle, ohne den Bildschirm zu verlassen.

Ergänzt am 04.08.2026 — CTO: Die Frage trifft genau die Ursache des heutigen Rollenwildwuchses und braucht eine festgeschriebene Antwort.

Warum das eine eigene Regel ist: Genau hier sind die heutigen Collaborator 1 bis 4 entstanden. Der CTO hat bestätigt, was wir im Befund vermutet hatten: Es waren Personen mit unterschiedlichen Rechten, und weil es nur ein Werkzeug gab, wurde daraus jedes Mal eine neue Rolle. Ohne R121 wiederholt sich das im neuen System innerhalb eines Jahres.

R20 — Nach dem Speichern bleibt man, wo man war. Prüfbar: Die Adresse im Browser ändert sich beim Speichern nicht. (Behebt F3.)

2.7 Schutzregeln

Nicht verhandelbar, unabhängig von Rolle und Rechten:

R21 — Niemand kann das eigene Konto löschen. (Heute erfüllt, S2 — aber siehe A2 in 1.4: die Meldung muss erklären, wo man sich stattdessen selbst bearbeitet.) R22 — Das letzte Konto mit Administratorrechten kann weder gelöscht noch herabgestuft noch deaktiviert werden. Die Meldung nennt den Grund. R23 — Niemand kann die eigenen Rechte erhöhen. Ergibt sich bereits aus R16, wird aber zusätzlich am eigenen Konto geprüft. R24 — Ein Administrator darf Administratorrechte vergeben, ohne dass ein zweiter zustimmen muss. Vor dem Speichern erscheint eine einmalige Bestätigung, die die Tragweite benennt: Die Vergabe steht im Protokoll (R27). [E8, geändert] Prüfbar: Die Vergabe ist nach einer Bestätigung sofort wirksam, ohne Zustimmung einer zweiten Person, und erzeugt einen Protokolleintrag. Geändert nach. Meine erste Fassung sah ein Vier-Augen-Prinzip vor. Ein zweiter Administrator dient der Redundanz für den Ausfall, nicht der gegenseitigen Kontrolle — und wer Rechte vergeben darf, trägt dafür auch die Verantwortung. Das ist zudem konsistent mit R16: Was ich selbst habe, darf ich weitergeben. R25 — Systemkonten von immorise sind für Kunden nicht sichtbar und nicht löschbar. Prüfbar: Über alle Seiten der Nutzerliste hinweg erscheint kein immorise-Konto, und der direkte Aufruf gibt keine Daten zurück. (Serverseitig, nicht nur ausgeblendet — siehe S1.) R26 — Twin-Factory-Aufträge kosten Geld. Kein fester Budgetbetrag — stattdessen eine Freigabe: Löst ein Administrator den Auftrag aus, geht er sofort raus. Löst ihn jemand anderes mit Bestellrecht aus, wird er als Anfrage eingestellt und braucht die Freigabe eines Administrators — unabhängig von der Größe. Jeder Auftrag wird protokolliert. [E9, geändert] Prüfbar: Ein Auftrag eines Nicht-Administrators erscheint als Anfrage und löst erst nach Freigabe aus; ein Auftrag eines Administrators löst sofort aus. Geändert am 02.08. Ein fester Betrag lässt sich nicht sinnvoll vorgeben: Die Kosten hängen von der Projektgröße ab, und immorise kann nicht für ein Kundenunternehmen entscheiden, welche Summe dort angemessen ist. Die Freigabe löst dasselbe Problem, ohne eine Zahl zu erfinden.

R93 — Eine Anfrage zeigt den Preis. Wer ohne Bestellrecht einen Auftrag an immorise anfragt, sieht denselben Preis wie ein Besteller und gibt eine Begründung mit — sonst entscheidet der Administrator im Blindflug. Wird abgelehnt, geht eine Mitteilung mit Begründung zurück. Prüfbar: Anfrage und Bestellung zeigen dieselbe Summe; eine Ablehnung ohne Begründungsfeld ist nicht absendbar. R27 — Jede Rechteänderung wird protokolliert: wer, wann, was vorher, was nachher. Das Protokoll ist für Administratoren einsehbar und nicht änderbar.

2.8 immorise selbst — zwei Dinge, die nie dasselbe sein dürfen

immorise kommt im System an zwei völlig verschiedenen Stellen vor. Sie sehen sich oberflächlich ähnlich, und genau ihre Vermischung ist der heutige Fehler S1: Ein einziges Nutzerkonto (info@immorise.com) muss beides leisten — und ist deshalb für Kunden sichtbar und löschbar.

Der Support-Zugang

Wir müssen jeden Kundenmandanten vollständig sehen und bedienen können, sonst können wir nicht helfen. Dieser Zugang ist kein Nutzerkonto im Mandanten des Kunden. Er steht daneben, nicht darin.

R28 — Der Support-Zugang erscheint nicht als Nutzer: nicht in der Liste, nicht in den Kennzahlen, nicht in Rollen, nicht in Gruppen, nicht in Projektzuweisungen. Prüfbar: Über alle Seiten der Nutzerliste hinweg erscheint kein immorise-Konto, die Kennzahl „aktive Mitglieder" zählt es nicht mit, und der direkte Aufruf seiner Adresse gibt dem Kunden keine Daten zurück. (Strenge Fassung von R25 — behebt S1 an der Wurzel, statt das Konto nur auszublenden.)

R29 — Der Support-Zugang unterliegt nicht dem Rollensystem des Kunden. Er lässt sich nicht einschränken, nicht entziehen, nicht löschen. Er sieht alle Bereiche, ändert alle Einstellungen und kann Administratoren ernennen. Prüfbar: Kein Bedienelement im Kundenmandanten hat eine Wirkung auf ihn.

R30 — Support-Zugriffe werden intern protokolliert: welche Person bei immorise, wann, in welchem Mandanten, was geändert. Das Protokoll ist nicht Teil der Kundenoberfläche; es wird ausgelesen, wenn ein Kunde nachfragt oder es einen Streitfall gibt. Was der Support ändert, erscheint im Protokoll des Kunden allerdings als und nie unter dem Namen eines Kundenkontos — sonst stünde dort eine falsche Urheberschaft. [E10, geändert]** Prüfbar: Eine im Support geänderte Rolle trägt im Kundenprotokoll immorise als Urheber; eine reine Ansicht ohne Änderung erzeugt beim Kunden keinen Eintrag. Geändert nach. Meine erste Fassung stellte das vollständige Zugriffsprotokoll dem Kunden zur Verfügung. Ball flach halten — so etwas gibt es heute überhaupt nicht, und der Kunde muss nicht proaktiv sehen, wo wir überall waren. Das trägt auch datenschutzrechtlich: Die Auskunftspflicht verlangt, dass wir auf Nachfrage Auskunft geben können — nicht, dass wir es von selbst anzeigen. Ein internes Protokoll reicht dafür.

R31 — Während einer Support-Sitzung sieht die immorise-Mitarbeiterin durchgehend, in welchem Mandanten sie arbeitet. Prüfbar: Der Hinweis ist auf jeder Seite sichtbar und nicht wegklickbar.

R31 klingt nach einer Kleinigkeit, ist aber der Schutz gegen den teuersten denkbaren Fehler — eine Änderung im falschen Kundenmandanten.

Rechtlicher Punkt, nicht von uns entscheidbar: Ein unsichtbarer Vollzugriff auf Kundendaten muss im Auftragsverarbeitungsvertrag ausdrücklich gedeckt sein. die Geschäftsführung' Formulierung trifft es und sollte dem Anwalt so vorgelegt werden: dass geschulte Mitarbeiterinnen unter Einhaltung der Datenschutzstandards in Kundenprojekten arbeiten können — zu Support-Zwecken, zur Fehlerbehebung und zur Verbesserung des Dienstes. Das gehört zusammen mit der ohnehin offenen KI-Klausel auf die Anwaltsliste. R30 ist die technische Voraussetzung dafür, dass wir auf Nachfrage Auskunft geben können.

immorise als Auftragnehmer

Der zweite Fall: Ein Kunde will eine Punktwolke in ein BIM-Modell umwandeln lassen, eine 3D-Tour aktualisieren oder meldet ein Problem. Dann legt er eine Aktivität an — und muss immorise als Zuständigen auswählen können.

R32 — In jeder Auswahl „wer ist zuständig" steht neben Personen und Gruppen der feste Eintrag immorise. Er ist kein Nutzer, keine Rolle und keine Gruppe — und er ist ein Eintrag in der Auswahl, kein eigener Knopf daneben. Zuweisen an immorise funktioniert wie Zuweisen an eine Person: dieselbe Liste, dieselbe Handlung. Prüfbar: immorise ist als Zuständiger auswählbar, taucht aber in Nutzer- und Rollenverwaltung an keiner Stelle auf und lässt sich dort weder bearbeiten noch entfernen. Neben dem Zuständig-Feld steht kein zweiter Weg zu immorise.

R33 — Eine an immorise zugewiesene Aktivität ist eine Anfrage, kein Auftrag. Sie verhält sich wie jede andere Aktivität: Titel, Beschreibung, Verlauf, Anhänge. Sie hält fest, wer sie wann zugewiesen hat, und sie ist der Weg, auf dem immorise überhaupt in ein Projekt kommt denn immorise steht nicht im User-Management des Kunden (R28). Typische Fälle: etwas am Modell funktioniert nicht, eine Frage zur Plattform, oder der Wunsch, später etwas zu bestellen. Kein Preis, keine Freigabe, kein Bezahlschritt in der Aktivität. Prüfbar: Beim Zuweisen an immorise erscheint kein Betrag und keine Auftragsart. Im Verlauf steht ein Eintrag mit Auslöser, Zeitpunkt und Gegenstand. Berichtigt am 05.08.2026 — die erste Fassung war ein Missverständnis. Hier stand, eine an immorise übergebene Aktivität sei ein Auftrag, Twin-Factory-Bestellungen liefen über denselben Weg und unterlägen dem Bestellbudget. Daraus sind ein eigener Knopf „immorise beauftragen", ein Leistungskatalog im Zuständig-Fenster und zwei Bildschirme mit Preis und Freigabe entstanden. Das war nicht gemeint. Verkauft werden Twin Factory und die Verarbeitung hochgeladener Punktwolken, BIM-Modelle und Pläne — die laufen über den eigenen Weg mit eigenem Bezahlfenster (siehe Doku 84). Das Anliegen hinter R32 war ein anderes und kleineres: immorise muss in der Auswahl stehen, wem man eine Aktivität zuweist — weil immorise im Rollensystem des Kunden nicht auftaucht und sonst nicht erreichbar wäre.

Warum die Trennung so wichtig ist. Der Support-Zugang ist eine technische Notwendigkeit und für den Kunden unsichtbar. Der Auftrag ist eine bewusste Handlung des Kunden und muss sichtbar und belegbar sein. Löst man beides über ein Nutzerkonto — so wie heute — hat man beides falsch: ein Konto, das der Kunde sieht und versehentlich löschen kann, und einen Auftragsweg, der nirgends dokumentiert ist.

2.9 Was das Modell bewusst nicht kann

Damit später niemand danach sucht:

• Keine Rechte an einzelnen Aktivitäten oder Modellen. Die feinste Ebene, auf der Rechte

berechnet werden, ist außerhalb des Datenraums das Projekt. Der Datenraum ist die Ausnahme, weil dort Verträge liegen.

> Präzisiert am 03.08., weil es sonst wie ein Widerspruch zu 2.12 aussieht: Die Sichtbarkeit > an einer einzelnen Aktivität (R76, R87) ist kein Recht. Sie wird nicht aus Rolle, Gruppen > und Ausnahmen berechnet, sondern von der verfassenden Person am Eintrag gesetzt, und sie kann > nur enger machen als das, was das Rechtemodell ohnehin erlaubt. Deshalb bleibt der Satz oben > richtig: Es gibt kein Recht „darf Aktivität 4711 sehen", das jemand vergeben könnte. > Dasselbe gilt für den Gast (R79): Er bekommt kein Projektrecht, sondern einen Zugang zu > einem Eintrag, der mit ihm endet (R92). > Für den Entwickler: zwei getrennte Prüfungen, in dieser Reihenfolge — erst das Projektrecht, > dann die Sichtbarkeit. Nie eine gemeinsame Tabelle, sonst entsteht genau das > Aktivitäten-Rechtesystem, das dieser Abschnitt ausschließt.

• Keine zeitgesteuerten Rollen. Ein Ablaufdatum gibt es nur bei Ausnahmen (R8) und

Einladungen, nicht bei der Firmen-Rolle.

• Keine Vertretungsregelung („während meines Urlaubs übernimmt X"). Sinnvoll, aber ein eigenes

Thema — bewusst nicht in dieser Ausbaustufe.

• Kein Genehmigungsverfahren für gewöhnliche Rechteänderungen. Vier Augen gilt nur für

Administratorrechte (R24) und Budgetüberschreitungen (R26).

2.10 Die Entscheidungen — vollständig, Stand 03.08.

Dreiundzwanzig Entscheidungen, alle mit die Geschäftsführung durchgesprochen. Keine ist mehr offen. Wo eine gegen meine erste Empfehlung ausging, steht der Grund dabei — der ist wichtiger als die Empfehlung. E16–E21 sind am 02./03.08. bei den Bereichs-Durchgängen dazugekommen; sie stehen ausführlich in 62-entscheidungen-gesamtkonzept.md als D1 bis D8.

Was jetzt noch offen ist — und es ist nichts Konzeptionelles mehr:

Zwei Punkte gehören dem Anwalt, nicht uns: die Fristen des Löschkonzepts (E13) und die Formulierung zum Support-Zugang im Auftragsverarbeitungsvertrag (2.8) — zusammen mit der ohnehin offenen KI-Klausel. Beides hält die Umsetzung nicht auf.

Damit ist das Rollenkonzept fachlich entschieden. Der Weg zur Umsetzung steht in Abschnitt 10 und ausführlich in 59-umsetzungsplan-user-management.md.

2.11 Wie der Altbestand in dieses Modell kommt

Der Weg im Groben — die Einzelheiten stehen in Abschnitt 8, sobald das Rollen-Set bestätigt ist:

1. Zuordnen statt löschen. Jede der heute 24 Rollen wird einer der zehn Vorlagen zugeordnet.

Die Nummern-Dubletten (Collaborator 1 bis 4) fallen dabei zusammen — sie unterscheiden sich nur in wenigen Rechten, und diese Unterschiede werden zu Projekt-Ausnahmen an den betroffenen Personen. Genau dafür ist das dritte Werkzeug da.

1. Legacy-Rechte übersetzen, nicht streichen: TICKET → Aktivität, FILE MANAGER → Datenraum,

SCAN2BIM → Twin Factory, DOWNLOAD und SHARE als eigene Aktionen (Abschnitt 1.2).

1. Vorher-Nachher-Vergleich pro Person, bevor irgendetwas umgestellt wird — nach R11. Niemand

verliert unbemerkt Rechte, niemand gewinnt unbemerkt welche dazu.

1. Verwaiste Rollen (0 Nutzer, siehe A15) werden gelöscht, nachdem 1–3 durch sind.

2.12 Sichtbarkeit, Gäste und der Grundsatz „gesperrt statt versteckt"

Zur Reihenfolge: 2.12 und 2.13 sind am 03.08. hinten angefügt, damit die Nummern von 2.1 bis 2.11 stabil bleiben — es verweisen zu viele Stellen darauf. Inhaltlich gehören beide zum Modell (2.2 bis 2.9), nicht zur Migration, die in 2.11 davorsteht.

Diese Regeln sind zwischen dem 02. und 03.08. bei den Durchgängen durch Datenraum und Aktivitäten entstanden. Sie gehören hierher, weil sie Rechte beschreiben — nur wirken sie an einer Stelle, die es im ersten Entwurf noch nicht gab: an der einzelnen Aktivität.

Zwei Tore, nicht eines

Das Rechtemodell aus 2.2 sagt, ob jemand in einem Projekt überhaupt Aktivitäten sieht. Die Sichtbarkeit an der Aktivität sagt, welche davon. Das zweite Tor kann nur enger machen, nie weiter — dieselbe Richtung wie beim Datenraum-Ordner (R55).

R76 — Nicht sichtbare Aktivitäten sind für alle anderen nicht vorhanden. Andere sehen auch nicht, dass es sie gibt — keine Zeile, kein Zähler, kein „1 verborgener Eintrag". Prüfbar: Zwei Personen mit demselben Projektrecht sehen unterschiedliche Zählerstände, und keine Summe verrät die Existenz der anderen Einträge.

R87 — „Nur für mich" ist eine Sichtbarkeit, kein Sonderfall. Der Eintrag ist gespeichert und normal vorhanden; anderen wird er nicht angezeigt — nicht in Listen, nicht in Zählern, nicht in Berichten, nicht durch die KI. Für den Verfasser zählt er normal mit. Wer ihn nicht mehr braucht, löscht ihn wie jeden eigenen Eintrag; es braucht dafür keinen eigenen Mechanismus. Prüfbar: Es gibt keinen zweiten Speicher und keine zweite Löschfunktion für „nur für mich".

R88 — Im Zweifel hat der Administrator Zugriff — ansehen, zuordnen, löschen. Der Anlass ist in der Regel das Deaktivieren eines Zugangs: Das ist das einzige Ereignis, an dem die Plattform ein Ausscheiden erkennen kann, und es hängt an keiner Mitwirkung der ausscheidenden Person. Der Zugriff läuft im Protokoll mit (R27), wie jeder andere. Keine Warnzeile beim Anlegen — das steht in der Rechteübersicht, wo es hingehört. Prüfbar: Nach dem Deaktivieren eines Nutzers sind seine „nur für mich"-Einträge für einen Administrator erreichbar, und der Zugriff steht im Protokoll.

Das ist die einzige Stelle, an der die beiden Regeln aneinanderstoßen — und es ist gewollt: R76 schützt vor Kolleginnen, nicht vor dem Unternehmen. Wer das anders erwartet, hat kein Unternehmenssystem vor sich, sondern ein privates Notizbuch. Deshalb steht es in der Rechteübersicht und nicht im Kleingedruckten.

Zuweisen kann nur, wer den anderen sehen lässt

R77 — Zuweisen geht nur an Personen, die Aktivitäten in diesem Projekt sehen dürfen. Wer das Recht nicht hat, steht in der Auswahl ausgegraut mit Grund — nicht unsichtbar, sonst sucht man ewig nach jemandem, der nie erscheinen wird. Prüfbar: Die Auswahl zeigt alle Personen des Mandanten; die nicht wählbaren tragen den Grund.

R78 — Aus der ausgegrauten Zeile führt ein Weg heraus, passend zur eigenen Befugnis. Wer Nutzer verwalten darf, kommt direkt ins User-Management. Wer nicht, löst eine Anfrage an einen Administrator aus — derselbe Weg wie die Freigabe-Anfrage bei höheren Rechten (R73). Prüfbar: Jede gesperrte Zeile hat genau einen weiterführenden Klick, und welcher es ist, hängt an der eigenen Rolle.

Teilen nimmt den Zwilling mit

R81 — Wer eine verortete Aktivität teilt, teilt den Zugang zum Zwilling mit. Im Modell den BIM-Viewer, in der 3D-Tour die 3D-Tour — aber nur für dieses Objekt und diese Verortung. Prüfbar: Der Empfänger erreicht die Stelle im Zwilling und kein anderes Objekt, keinen Datenraum, keine andere Etage über die Etagenauswahl.

Das ist die Regel mit der größten Tragweite in diesem Abschnitt, weil sie eine Rechtegrenze überschreitet: Eine Aktivität liegt in den Aktivitäten, ein Zwilling im Viewer. Ohne R81 wäre eine geteilte verortete Aktivität wertlos — der Empfänger sähe einen Ort, den er nicht ansehen darf. Mit R81 muss die Umsetzung den Zugang auf die Verortung beschneiden; ein Zugang „zum Viewer" wäre falsch.

Gesperrt statt versteckt — der Grundsatz für die ganze Plattform

R89 — Fehlende Rechte verstecken keine Funktionen. Das Bedienelement bleibt sichtbar, ist gesperrt, nennt den Grund und bietet Anfragen an — derselbe Weg wie die Freigabe-Anfrage (R73). Geprüft wird die Wirkung, nicht die Sichtbarkeit: Es entsteht kein Link, kein Download, kein Signaturlauf. **Einzige Ausnahme: die Stufe kein Zugriff.** Was niemand sehen darf, wird auch nicht als gesperrt angedeutet — sonst verrät die Sperre seine Existenz. Prüfbar: Zu jedem gesperrten Bedienelement gehören ein Grund und ein Weg; und ein Ordner der Stufe kein Zugriff erscheint überhaupt nicht (R56, 7.4).

Warum das eine eigene Regel ist und nicht Geschmackssache: Eine ausgeblendete Funktion erzeugt zwei Kosten. Die Nutzerin weiß nicht, dass es sie gibt — sie fragt beim Support, nicht bei ihrem Administrator. Und wir wissen nicht, dass sie sie braucht — es entsteht kein Vorgang. R89 macht aus einer stillen Grenze einen sichtbaren, zählbaren Vorgang. R56 ist dieselbe Regel für Datenraum-Ordner, R78 ihr Weg heraus.

2.13 Der KI-Assistent im Rechtemodell

Das fehlte in der ersten Fassung dieser Spezifikation vollständig: „KI" kam nur in der AVV-Klausel und beim Erzeugen einer Rolle vor. Der Assistent ist aber ein Leser — und damit eine Rechtefrage.

R83 — Der KI-Assistent ist ein Leser wie jeder andere. Er beantwortet jeder Person nur das, was sie selbst lesen darf, und arbeitet dabei auf dem aktuellen Stand — „zeig mir alle offenen Aktivitäten" muss gehen. Kein eigener Speicher, keine eigene Rechtewelt. Prüfbar: Zwei Personen mit unterschiedlichen Rechten erhalten auf dieselbe Frage unterschiedliche Antworten, und keine enthält etwas, das die Fragende nicht auch selbst öffnen könnte.

R84 — „Den KI-Assistenten nutzen" ist ein eigenes, firmenweites Recht. Es hängt an der Rolle, der Administrator schaltet es ein oder aus. Wie weit die KI für eine Person reicht, ergibt sich aus ihren Projektrechten — es braucht keine zweite Einstellung. Prüfbar: Das Recht steht in der Rollenbearbeitung (B7) unter den firmenweiten Fähigkeiten; ohne es ist der Assistent auf jeder Seite gesperrt mit Grund (R89), nicht ausgeblendet.

R85 — Zugestimmt wird einmal, im Vertrag — nicht im Arbeitsalltag. Weder beim Anlegen noch beim Abschließen einer Aktivität wird gefragt. Grundlage ist die KI-Klausel im Auftragsverarbeitungsvertrag, die noch fehlt; das Recht aus R84 ist ihre Umsetzung in der Oberfläche. Beides gehört dem Anwalt zusammen vorgelegt (Abschnitt 9). Prüfbar: In der Oberfläche gibt es keine wiederkehrende KI-Zustimmung.

R86 — Offene Aktivitäten sind Arbeitsstand, und die Antwort sagt das. „laut offener Aktivität vom 12.07., noch nicht abgeschlossen". Damit geht Halbfertiges nicht als Tatsache durch ohne dass jemand gefragt werden muss. Prüfbar: Jede Antwort, die eine offene Aktivität heranzieht, kennzeichnet sie als offen.

Was diese vier Regeln zusammen bedeuten — für den Entwickler in einem Satz: Die KI braucht keine eigene Rechteprüfung. Sie stellt ihre Fragen mit der Identität der Fragenden an dieselben Schnittstellen, die die Oberfläche benutzt. Ein zweiter Rechtepfad wäre die wahrscheinlichste Quelle eines Datenlecks in diesem Produkt — deshalb ist R83 nicht als Empfehlung formuliert, sondern als Bauvorschrift.

Nachtrag vom 04.08.2026 — der Assistent schreibt nicht. Aus der Rückmeldung des Entwicklers: Der Assistent kann heute Aktivitäten anlegen, ändern und löschen, ohne dass geprüft wird, ob die fragende Person das dürfte. Das war im Konzept nicht vorgesehen und wird ausdrücklich ausgeschlossen:

R120 — Der Assistent verändert nichts von sich aus. Will man ihm später das Schreiben erlauben, legt er einen Vorschlag vor, den ein Mensch bestätigt —. Erst dieser Knopf löst die Änderung aus, und zwar über denselben Weg, den die Oberfläche benutzt. Damit gilt automatisch das Recht der bestätigenden Person, und es entsteht kein zweiter Rechtepfad. Jeder so entstandene Eintrag ist als über den Assistenten erstellt erkennbar. Prüfbar: Eine Person, die keine Aktivitäten anlegen darf, kann über den Assistenten keine anlegen auch nicht, wenn sie ihn ausdrücklich dazu auffordert. (Von die Geschäftsführung entschieden; dieselbe Mechanik wie die Twin-Factory-Freigabe, R26.)

die Tür selbst: Bei jeder Anfrage an den Assistenten wird mitgeschickt, um welchen Mandanten es geht. Laut Rückmeldung wird nicht geprüft, ob das angemeldete Konto zu diesem Mandanten gehört. Das ist keine Konzeptfrage, sondern eine fehlende Prüfung — sie steht als Arbeitspaket AP34 im Plan und geht allem anderen vor.

Begriffe

3 · Begriffe

Jeder Begriff wird hier genau einmal festgelegt und danach überall so verwendet — in der Oberfläche, im Code und in diesem Dokument. Der heutige Zustand mischt Modul und Rolle (Befund N4) und führt englische und deutsche Wörter nebeneinander (N1). Beides kommt aus unscharfen Begriffen.

Die Regel dazu:

R48 — Für jeden Begriff gibt es genau ein deutsches und genau ein englisches Wort. Synonyme sind in der Oberfläche verboten. Prüfbar: Eine Volltextsuche über die Sprachdateien findet für keinen Begriff aus dieser Tabelle ein zweites Wort mit gleicher Bedeutung.

3.1 Das Verzeichnis

3.2 Wörter, die nicht mehr vorkommen

Diese Begriffe stehen heute in der Oberfläche oder im Datenbestand und werden ersetzt. Sie dürfen nach der Bereinigung nirgends mehr auftauchen — weder sichtbar noch als gespeicherter Wert:

R95 — Die Person, die ein Projekt für einen Kunden aufsetzt und übergibt, heißt „Projekt-Partner" — englisch „Project Partner". Ein Wort, überall. Es beschreibt, was sie für das Projekt ist, nicht wie sie hineinkam. Welche Art Partner (Vermesser, Architekt, Verwalter) muss die Rolle nicht sagen — das steht im Firmennamen. Prüfbar: In Oberfläche, Spezifikation und Übergabe-Dokument kommt keines der vier alten Wörter mehr vor.

Nicht zu verwechseln — drei Begriffe, die nebeneinander bestehen bleiben: Projekt-Partner ist das, was die Person für das Projekt ist (R95). Multiplikator ist die Fähigkeit in ihrem eigenen Mandanten, Kundenmandanten anzulegen (3.1). Root Owner ist die interne Systemrolle, die in der Kundenoberfläche nicht vorkommt (R69). Drei verschiedene Dinge, deshalb drei Wörter anders als vorher, wo ein Ding vier Wörter hatte.

Was Verarbeitung kostet

Die Plattform verdient an zwei Dingen: der Lizenz je Quadratmeter und Jahr und der Verarbeitung von Scans und Modellen. Alles andere — der Assistent, die Auslese von Dokumenten, Reports — ist in der Lizenz enthalten und wird nicht einzeln berechnet.

Das Modell in drei Sätzen

Jedes Objekt bringt ein Verarbeitungs-Guthaben in Euro mit, das in der Jahreslizenz enthalten ist. Jede Verarbeitung zieht davon ab; die Abrechnung zeigt jederzeit, was verbraucht ist und wofür. Erst wenn das Guthaben aufgebraucht ist, erscheint ein Bezahlfenster — nicht bei jedem Klick.

Die Bezugsgröße: Brutto-Grundfläche

Abgerechnet wird nach Brutto-Grundfläche (BGF) — der Nutzfläche zuzüglich Konstruktions- und Technikflächen, also der gesamten Geschossfläche. Der Nutzer gibt sie beim Anlegen eines Objekts an. Nach der Verarbeitung wird sie gegen die Punktwolke abgeglichen, mit einer Toleranz von ±10 % in beide Richtungen: zu niedrig angegeben wird nachberechnet, zu hoch angegeben wird erstattet.

Ganze Objekte rechnen nach Quadratmeter, Teile nach Gigabyte. Bei der Erstverarbeitung eines Objekts ist die Fläche bekannt. Bei einem Nachscan, der nur einen Bereich austauscht, ist sie es nicht und ließe sich auch nicht prüfen — dort ist die Datenmenge die einzige belastbare Größe.

Vollständige Kostenstellen

Zwanzig Vorgänge kosten Rechenzeit, Speicher oder Datenverkehr. Sie sind hier vollständig erfasst. Die Spalte Kostenklasse ist der Aufwand für immorise, nicht der Verkaufspreis.

Scan-Verarbeitung — die teure Klasse

Modell-Verarbeitung — die mittlere Klasse

Auslese und Assistent — die günstige Klasse

Laufendes — die stille Klasse

Wo die Zahlen stehen

Die Sätze sind an genau einer Stelle hinterlegt und werden von dort in jeden Bildschirm übernommen. Kein Bildschirm nennt eine Zahl, die dort nicht steht — das ist maschinell geprüft. Wer einen Satz ändern will, ändert ihn dort, und alle Bildschirme stimmen wieder.

Die endgültige Preisliste entscheidet die Geschäftsführung. Die im Konzept eingesetzten Sätze sind rechnerisch tragfähig — sie decken die Selbstkosten in den geprüften Größenordnungen — aber sie sind keine Preisfreigabe. Sie stehen im Konzept, damit die Bildschirme vollständig und die Rechenwege prüfbar sind.

Drei Entscheidungen, die noch fehlen

Was danach kommt

Nicht Teil der ersten Umsetzung, aber bereits durchdacht — damit heute nichts gebaut wird, das morgen im Weg steht.

Zeitachse für Aktivitäten

Ein Überblick, wann Vorhaben anfangen und enden — Terminplanung über das Portfolio hinweg.

Kein neuer Bereich, sondern eine vierte Ansicht der Aktivitäten neben Liste, Split und Erledigte: derselbe Umschalter, dieselben Daten, dieselben Filter. Eine Zeitachse ist keine neue Datengattung, sondern eine andere Darstellung dessen, was schon da ist. Aktivitäten haben Frist, Kategorie, Zuständige, Objekt und Ort im Gebäude.

Waagerecht die Zeit, senkrecht die Objekte oder Gewerke. Jede Aktivität ein Balken in ihrer Kategorie-Farbe, Meilensteine als Raute, überfällig mit derselben roten Kante wie in der Liste. „Heute" als senkrechte Linie. Ein Balken, der an einem Bauteil hängt, trägt die Ortsmarke — ein Klick springt ins Modell. Damit ist die Zeitachse kein fremdes Terminwerkzeug, sondern Teil der Plattform.

Was dafür fehlt: ein Feld „hängt ab von" in der Aktivität. Ohne Abhängigkeiten ist es eine Übersicht, keine Planung.

Prozessvorlagen

Heute wird jede Aktivität einzeln angelegt. Wiederkehrende Vorgänge — Wartungszyklus, Prüfzyklus, Mieterwechsel, Umbau — folgen aber fast immer demselben Muster. Eine Bibliothek von Vorlagen, die zum größten Teil auf ein neues Objekt passen und dann angepasst werden, würde den größten Teil der Anlegearbeit ersparen.

Zum Vergleich lohnt ein Blick auf beeboard, eine Prozess-Software für Bau und Immobilien mit Drees & Sommer und Instone als Gesellschaftern. Interessant sind dort drei Ideen: standardisierte Master-Prozesse aus einer Bibliothek, Wissen und Vorlagen direkt am Prozessschritt, und Termine, die von denen bestätigt werden, die die Arbeit tun, statt zugewiesen zu werden. Das ist eine Referenz zum Vergleich, keine Vorlage zum Nachbauen — immorise hat mit Zwilling-Wissen und Datenraum das Rohmaterial schon; es fehlt die Verknüpfung „Schritt → Vorlage → Dokument".

Aufwand ehrlich: Die Zeitachse ist ein überschaubarer Bildschirm und passt ins System. Die Prozessvorlagen sind ein eigenes Paket — sie berühren Datenmodell, Rechte und den Weg zum Anlegen.

Automatisch erzeugte Aktivitäten

Fristen stehen in Verträgen, Prüfzyklen im Zwilling-Wissen. Beides liest die Plattform heute schon aus. Daraus Aktivitäten selbst anzulegen — mit Frist, Kategorie und Objekt — ist der nächste naheliegende Schritt: der Nutzer prüft und bestätigt, statt zu tippen.

Weitere Anwendungsfälle

Was noch offen ist

Ehrliche Liste. Was hier steht, ist nicht entschieden — und darf nicht gebaut werden, ohne zu fragen. Nichts davon hält die Umsetzung auf.

Entscheidungen

Noch zu bauen

Was bewusst nicht im Konzept steht

Mobile Ansichten. Die Plattform ist für den Schreibtisch entworfen. Was auf dem Telefon gebraucht wird — Aktivität aufnehmen, Foto anhängen, 3D-Tour ansehen — ist ein eigenes Paket mit eigenen Entscheidungen.

Der Bezahl- und Kaufabschluss der Twin Factory. Der Weg bis zum Preis ist entworfen, der Kaufabschluss selbst folgt dem bestehenden Bezahlfenster.

Bauteil-Klassifizierung im Detail. Dass sie kommt und was sie kostet, steht fest. Wie die Erkennung im Einzelnen arbeitet, ist ein technisches Vorhaben für sich.

Wichtig zum Verständnis dieses Konzepts

Das ist ein roter Faden, kein Bauplan zum Abarbeiten. Es gibt die Richtung vor und macht das Gesamtbild sichtbar. Zu jeder Oberfläche wird vor der Umsetzung noch einmal abgestimmt: manche Wege lassen sich mit den vorhandenen Schnittstellen und dem Backend anders lösen als hier gezeichnet, und einige werden sich in der Umsetzung als unpraktisch erweisen. Wer einen Bildschirm baut, prüft ihn gegen das Gesamtbild — und meldet zurück, wenn er nicht funktioniert. Das Konzept darf sich dabei ändern; es darf nur nicht unbemerkt auseinanderlaufen.