# Datenverträge

Diese Referenz beschreibt die implementierten portablen Formate der Browseranwendung. Sie führt weder eine REST-API, ein SDK, einen MCP-Server noch einen Automatisierungsendpunkt ein. Verwende die tatsächliche Oberfläche für unterstützte Aufgaben. Dokumentationsbeispiele sind passive Daten und enthalten keine Produktionszugangsdaten.

## Netzwerkschema Version 1

Das dauerhaft gespeicherte Netzwerkdokument hat `schemaVersion: 1`. Seine Felder auf oberster Ebene sind `id`, `title`, `description`, `entities`, `relationships`, `sources`, `citations`, `layout`, `createdAt` und `updatedAt`. Der Quellvertrag liegt in `contracts/graph-document.schema.json`; die Implementierung validiert zusätzlich datensatzübergreifende Invarianten in `src/domain/schemas/network.ts`.

Es folgt ein minimales, vollständiges synthetisches Netzwerk. Feste ID und Zeitstempel gehören zum Beispiel, nicht zu einer tatsächlichen Untersuchung oder einem Veröffentlichungsdatum. Importiere es nur einmal in ein Browserprofil, sofern die vorhandene Kopie nicht bewusst über einen unterstützten Ablauf entfernt wurde. Der Beispielinhalt bleibt in beiden Dokumentationssprachen identisch.

```json
{
  "schemaVersion": 1,
  "id": "b584a8f6-49b3-4d46-8d77-dd0d51fb1171",
  "title": "LB Docs — Empty practice Network",
  "description": "Fictional documentation example. No real entities or evidence.",
  "entities": [],
  "relationships": [],
  "sources": [],
  "citations": [],
  "layout": {
    "positions": {},
    "viewport": { "x": 0, "y": 0, "zoom": 1 }
  },
  "createdAt": "2026-09-05T00:00:00.000Z",
  "updatedAt": "2026-09-05T00:00:00.000Z"
}
```

## Referenz- und Vokabularregeln

IDs sind im gesamten Netzwerk und über alle seine dauerhaft gespeicherten Datensätze hinweg eindeutig. `sourceEntityId` und `targetEntityId` einer Beziehung müssen auf vorhandene Entitäten verweisen und für den Beziehungstyp zulässig sein. `sourceId` und Ziel eines Zitats müssen aufgelöst werden können. Layoutpositionen müssen vorhandenen Entitäts-IDs entsprechen; jede Entität benötigt eine Position.

Das Typenregister definiert 15 Entitäts- und 33 Beziehungstypen. Gespeicherte Codes wie `person`, `company`, `online-account`, `director-of` und `operates-account` bleiben auf Englisch und Deutsch identisch. Auch registrierte Eigenschaftsnamen und Optionswerte bleiben stabil. Ein Unternehmen kann beispielsweise `jurisdiction`, `registrationNumber` und `legalForm` verwenden; ein gewählter Status verwendet einen zulässigen Code wie `active` oder `unknown`.

Jede Entität und Beziehung enthält `confidence`: `confirmed`, `probable`, `unconfirmed` oder `disputed`. Die Einordnung eines Zitats lautet separat `supports`, `disputes` oder `context`. Der Entstehungsursprung `origin.kind` ist `manual`, `csv`, `ai` oder `legacy`. Füge einer registrierten Feldzuordnung keine unbekannte Eigenschaft hinzu; eigene importierte Attribute besitzen eine separate Zuordnung mit zugehörigen Attributbeschreibungen.

## Grenzen des Datenaustauschs

| Format              | Eingabe- und Ausgabegrenze                                                                                                                                    |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Netzwerk-JSON       | Vollständiger Netzwerk-Import und -Export; Schemaversion und Verweise werden validiert; IDs bleiben erhalten und Kollisionen führen zur Ablehnung des Imports |
| CSV                 | Kopfzeilenzuordnung und Zeilenvorschau ausschließlich zur Erstellung von Entitäten; kein vollständiges Netzwerkaustauschformat                                |
| KI-Graphvorschlag   | Nicht vertrauenswürdige strukturierte Vorschläge, die gegen Anfrage, Vokabular, Belege und angenommene Abhängigkeiten validiert werden                        |
| Gehosteter Snapshot | Separat veröffentlichte, unveränderliche Datenhülle; Kopieren ordnet alle dauerhaften IDs einem unabhängigen lokalen Netzwerk neu zu                          |

Angenommene Zitate aus eingefügtem Text können UTF-16-Werte für `startOffset` und `endOffset` enthalten. Der genaue Quelltextausschnitt muss dem Auszug entsprechen; Offsets sind keine Bytepositionen. URL-Quellen akzeptieren HTTP- und HTTPS-Adressen ohne eingebettete Zugangsdaten. Aufbewahrter eingefügter Text ist Teil des Netzwerks und seines JSON-Exports.

## Kompatibilität und Versionsprüfung

Der Importer akzeptiert unterstützte Dokumente der Version 1 und ergänzt bei älteren Datensätzen ohne Herkunftsmetadaten den Ursprung `legacy`. Dieses Kompatibilitätsverhalten ist kein allgemeines Versprechen, beliebiges Graph-JSON, Exporte anderer Anwendungen, Desktop-Tresore oder künftige Schemaversionen anzunehmen. Kontotokens, Anbieterzugangsdaten und Renderer-Interna gehören nicht in ein Netzwerkdokument.

Vergleiche vor der Veröffentlichung einer Dokumentationsänderung die im Dokumentationsindex erfasste App-Revision, Vertragshashes und sichtbaren Beschriftungen. Validiere die Beispiele erneut und spiele die betroffene Aufgabe in der Oberfläche durch, wenn sich eine dieser Quellen ändert. Schemavalidierung belegt strukturelle Gültigkeit; sie beweist nicht, dass eine Rechercheaussage wahr ist.