Multi-INT einheitliches Datenmodell für militärische Aufklärungsplattformen

Jede ernsthafte militärische Aufklärungsplattform begegnet früher oder später demselben strukturellen Problem: Fünf oder mehr Aufklärungsdisziplinen produzieren Daten in ihren eigenen Formaten, in ihrer eigenen Geschwindigkeit und mit ihrer eigenen Semantik — und Analysten benötigen ein einheitliches Bild, das alle Quellen gleichzeitig berücksichtigt. Der vollständige Leitfaden zur Verteidigungsdatenfusion behandelt die Verarbeitungspipeline in allgemeinen Zügen. Dieser Artikel geht tiefer auf die Schemaebene ein — das kanonische Datenmodell, das unterhalb der Fusion Engine liegt und ihr etwas Kohärentes zum Arbeiten gibt.

Das Datenmodell richtig zu gestalten ist keine Kleinigkeit. Ein schlecht entworfenes Schema zwingt INT-spezifische Logik in die Anwendungsschicht, macht quellenübergreifende Abfragen fehleranfällig und verwandelt Schema-Migrationen in wochenlange Plattformstillstände. Ein gut entworfenes Modell absorbiert neue INT-Typen, unterstützt bi-temporale Abfragen und bewahrt die Herkunft durch jede Phase der Fusion. Dieser Artikel behandelt alle Entscheidungen, die bestimmen, in welche Kategorie Ihre Plattform fällt.

Warum jede INT eine andere Schema-Anpassung benötigt

Die fünf wichtigsten Aufklärungsdisziplinen unterscheiden sich nicht nur in dem, was sie sammeln, sondern auch darin, wie diese Daten strukturiert sind, mit welcher Geschwindigkeit sie eintreffen und welche Metadaten inhärent verfügbar sind. Diese Unterschiede sind nicht oberflächlich. Sie bestimmen, welche Adapterlogik benötigt wird, bevor ein einheitliches Modell eine Quelle aufnehmen kann, und sie schränken ein, welche quellenübergreifenden Abfragen durchführbar sind.

HUMINT (Humane Intelligence) ist primär textbasiert. Ein HUMINT-Bericht ist ein narratives Dokument, das beschreibt, was eine Quelle beobachtet, gehört oder erfahren hat. Zeitstempel sind oft ungenau — der Bericht kann ein Ereignis beschreiben, das über mehrere Tage stattgefunden hat, mit Unsicherheit sowohl in der Zeit als auch im Ort. Die wichtigsten Metadaten sind die Quellenbewertung: Wie zuverlässig ist diese bestimmte Quelle, und wie glaubwürdig ist dieses spezifische Informationsstück? Die HUMINT-Datengeschwindigkeit ist gering — Dutzende bis Hunderte von Berichten pro Tag an einem stark frequentierten Sammelpunkt, nicht Tausende pro Sekunde.

SIGINT (Signals Intelligence) — sowohl COMINT (Kommunikationsaufklärung) als auch ELINT (Elektronische Aufklärung) umfassend — ist hochfrequent, hochstrukturiert und millisekundengenau zeitgestempelt. Ein SIGINT-Abfang oder eine Emitterdetektierung trägt Frequenzparameter, Peilwinkel, Zeitdifferenz-Ortungsdaten und Modulationscharakteristiken. Der semantische Inhalt (was gesagt wurde) ist oft getrennt von den Signalparametern klassifiziert. Die SIGINT-Datengeschwindigkeit kann für ein modernes Sammelsystem, das ein umkämpftes elektromagnetisches Umfeld abdeckt, Millionen von Datensätzen pro Stunde erreichen.

IMINT (Bildaufklärung) produziert strukturierte Beobachtungsdatensätze, die aus der Bildanalyse abgeleitet werden: Begrenzungsrahmen mit Entity-Klassen-Labels und Konfidenzwerten, Geokoordinaten, Bodenauflösungsabstand und Erfassungszeitstempel. Ein einziger Satellitenpass oder Drohnenflug kann Tausende von Objektdetektionsdatensätzen erzeugen. Die Herausforderung besteht darin, dass IMINT-Detektierungen räumliche Momentaufnahmen sind — sie sagen Ihnen, wo sich etwas zu einem bestimmten Moment befand, nicht wohin es sich bewegt.

OSINT (Open-Source Intelligence) ist strukturell die heterogenste. Sie umfasst Social-Media-Posts, Nachrichtenartikel, Analysen kommerzieller Satellitenbilder, Flugverfolgungsdaten und maritime AIS-Feeds. Jeder Quellentyp hat sein eigenes Schema. OSINT ist auch am wenigsten kontrolliert — die Quellenqualität reicht von autoritativen Regierungspublikationen bis hin zu anonymen, unverifizierten Social-Media-Behauptungen.

MASINT (Measurement and Signature Intelligence) umfasst physikalische Phänomenmessungen: seismische, akustische, nukleare Strahlung, chemische/biologische Signaturen und Radar-Querschnittsprofile. MASINT-Beobachtungen sind oft indirekt — sie erkennen ein Phänomen (Explosion, Fahrzeugbewegung, HF-Emission), anstatt direkt eine Entity zu identifizieren. Die Kette von der MASINT-Beobachtung zur Entity-Identifizierung erfordert explizite Inferenzschritte, die im Schema modelliert werden müssen.

Die Implikation für ein einheitliches Modell ist, dass das Schema diese Vielfalt aufnehmen muss, ohne sie zu nivellieren. Die Antwort ist ein typisiertes Kern-Envelope mit disziplinspezifischen Erweiterungs-Payloads — ein Designmuster, das ausführlich in der Serie Aufbau einer Verteidigungsfusion-Pipeline Teil 1 behandelt wird.

Kanonische Entity-Typen für ein einheitliches Modell

Der Ausgangspunkt für das Schema-Design ist die Definition der Entity-Typ-Taxonomie — die vollständige Liste der realen Objekte, die die Plattform verfolgen und analysieren muss. Für die meisten militärischen Aufklärungsplattformen decken sechs Entity-Typen die große Mehrheit der Aufklärungsobjekte ab:

• Person — individuelle menschliche Subjekte: Kombattanten, Befehlshaber, Unterstützer, Zivilisten von Interesse
• Organisation — Gruppen, Einheiten, Netzwerke, Befehlsstrukturen
• Ort — feste geografische Standorte: Einrichtungen, Infrastruktur, Wahrzeichen, benannte Interessengebiete
• Ausrüstung — Fahrzeuge, Waffensysteme, Sensoren, Kommunikationsgeräte
• Ereignis — diskrete Vorfälle: Gefechte, Explosionen, Treffen, Übertragungen
• Dokument — erbeutete Materialien, Publikationen, Aufklärungsberichte als Analyseobjekte

Jeder Entity-Typ hat einen Kern-Feldsatz, der INT-agnostisch ist — Felder, die unabhängig davon ausgefüllt werden müssen, welche Aufklärungsdisziplin die Information beigesteuert hat:

EntityCore {
  entity_id:       UUID           // global eindeutig, unveränderlich
  entity_type:     Enum           // Person | Organisation | Ort |
                                  // Ausrüstung | Ereignis | Dokument
  classification:  ClassMarkings  // siehe Herkunftsabschnitt
  valid_time:      TimeInterval   // [Start, Ende) wann Fakt wahr war
  transaction_time:TimeInterval   // [Start, Ende) wann Zeile aktuell war
  confidence:      Float[0..1]    // fusionierte Konfidenz über Quellen
  source_obs_ids:  UUID[]         // beitragende Beobachtungsdatensatz-IDs
  schema_version:  SemVer         // für Evolutionskompatibilität
  created_at:      Timestamp
  updated_at:      Timestamp
}

Über den Kern hinaus hat jeder Entity-Typ typisierte Attribut-Erweiterungen. Eine Person-Entity trägt biometrische Kennungen, Aliase, Nationalität und Links zu zugehörigen Organisationen. Eine Ausrüstungs-Entity trägt den Plattformtyp, Serienkenner falls bekannt und den Link zur zugehörigen Einheit. Eine Ereignis-Entity trägt die Ereignisklasse, Verweise auf beteiligte Entities und den räumlichen Fußabdruck. Diese Erweiterungen werden als typisierte Payloads gespeichert, die dem Kern-Envelope angehängt sind — nicht als Spalten in der Kerntabelle. Diese Trennung ermöglicht es dem Schema, neue Attribute für einen Entity-Typ aufzunehmen, ohne andere zu beeinflussen.

Dasselbe Trennungsprinzip gilt für INT-Beiträge. Wenn ein SIGINT-Abfang mit einer Person-Entity verknüpft ist (weil eine IMSI einer bekannten Person zugeordnet wurde), wird dieser Link als Beobachtungsdatensatz mit einem SIGINT-typisierten Payload gespeichert, der auf die UUID der Person-Entity zeigt. Die Person-Entity selbst enthält keine SIGINT-spezifischen Spalten — diese Kopplung würde das Schema anfällig für jede Änderung der SIGINT-Erfassung machen.

Herkunft und Quellenverfolgung

Herkunft ist die wichtigste nichtfunktionale Anforderung jedes Intelligence-Datenmodells. Jedes Informationsstück im fusionierten Bild muss bis zu seiner Quellbeobachtung, dem Sammelsystem, das es erzeugt hat, und den menschlichen Bewertungen zurückverfolgbar sein, die auf seine Zuverlässigkeit angewendet wurden. Ohne diese Kette können Analysten die Qualität des Bildes, mit dem sie arbeiten, nicht bewerten, und die Plattform kann kein Rollback durchführen, wenn eine Quelle als unzuverlässig erkannt wird.

Ein Herkunftsblock, der jedem Beobachtungsdatensatz beigefügt ist, sollte mindestens Folgendes enthalten:

ProvenanceBlock {
  int_type:            Enum     // HUMINT | SIGINT | IMINT | OSINT | MASINT
  source_id:           UUID     // interner Quellenregistrierungsverweis
  source_reliability:  Char     // A–F (NATO-Admiralty-Skala)
  info_credibility:    Integer  // 1–6 (NATO-Admiralty-Skala)
  collection_time:     Timestamp
  report_time:         Timestamp  // wann Bericht ins System kam
  originator:          String     // Einheit oder System, das Bericht erzeugte
  classification:      ClassMarkings
  handling_caveats:    String[]   // NOFORN, ORCON, REL TO, etc.
  dissemination_ctrl:  String[]
}

Die NATO-Admiralty-Skala kodiert zwei unabhängige menschliche Bewertungen für jedes Aufklärungsstück. Die Quellenzuverlässigkeit (A bis F) bewertet die historische Erfolgsbilanz und Vertrauenswürdigkeit der Quelle — eine A-bewertete Quelle war durchgängig genau und zuverlässig; eine F-bewertete Quelle hat eine unbekannte oder schlechte Bilanz. Die Informationsglaubwürdigkeit (1 bis 6) bewertet die Plausibilität der spezifischen Information unabhängig von der Quellengeschichte — ein mit 1 bewerteter Eintrag wird durch andere unabhängige Quellen bestätigt; ein mit 6 bewerteter Eintrag ist angesichts des übrigen Wissens unwahrscheinlich.

Diese beiden Bewertungen sind menschliche Einschätzungen von ausgebildeten Aufklärungsoffizieren. Sie sind verschieden von dem maschinenberechneten Fusionskonfidenzwert der Entity und dürfen nicht damit verwechselt werden. Die Fusionskonfidenz spiegelt die statistische Übereinstimmung über korrelierende Quellen wider; die Admiralty-Bewertungen spiegeln das menschliche Urteil über die Quellenqualität wider. Beide müssen bewahrt und Analysten separat präsentiert werden.

Klassifizierungsmarkierungen erfordern eine strukturierte Darstellung, keinen Freitext. Ein ClassMarkings-Typ muss kodieren: Klassifizierungsstufe (UNCLASSIFIED bis TOP SECRET), Kompartments und Codewörter sowie Handhabungsvorbehalte als aufgezählte Liste. Die Struktur ermöglicht die programmgesteuerte Durchsetzung der Zugangskontrolle — die Plattform kann zur Abfragezeit bewerten, ob die Freigabe eines bestimmten Benutzers die Klassifizierung jedes Feldes erfüllt, und kann Felder, die die Freigabe des Benutzers übersteigen, selektiv redigieren oder zurückhalten, anstatt die gesamte Entity zu verweigern.

Quellenübergreifende Entity-Auflösung

Entity-Auflösung — die Feststellung, dass Datensätze aus verschiedenen Quellen auf dieselbe reale Entity verweisen — ist das zentrale Fusionsproblem, und es ist genau an der quellenübergreifenden Grenze am schwierigsten. Innerhalb einer einzelnen INT sind Identifikatorschemata konsistent: Zwei SIGINT-Datensätze, die eine IMSI teilen, beziehen sich auf dasselbe Gerät. Über INTs hinweg existiert standardmäßig kein gemeinsamer Identifikator. Eine IMINT-Detektierung eines Fahrzeugs, eine SIGINT-Peilung auf einen Emitter, der mit diesem Fahrzeug kolokiert ist, und ein HUMINT-Bericht, der eine in diesem Fahrzeug gesehene Person benennt, müssen durch probabilistische Inferenz verknüpft werden, nicht durch einen gemeinsamen Schlüssel.

Die Entity-Auflösungs-Pipeline für ein einheitliches Modell muss drei Verknüpfungsszenarien handhaben:

Harte Links — gemeinsame Identifikatoren, die Datensätze definitiv mit derselben Entity verknüpfen. Eine bekannte IMSI, ein Kennzeichen, das von zwei IMINT-Pässen gelesen wurde, eine biometrische Übereinstimmung. Harte Links sollten automatisch ohne Konfidenzabfall propagiert werden.

Weiche Links — probabilistische Assoziationen basierend auf Attributähnlichkeit innerhalb von Unsicherheitsgrenzen. Zwei Beobachtungen, die ein Fahrzeug derselben Klasse an sich überlappenden Orten innerhalb eines Zeitfensters melden, das mit einer Bewegung zwischen ihnen vereinbar ist. Weiche Links tragen einen vom Auflösungsmodul berechneten Übereinstimmungskonfidenzwert.

Abgeleitete Links — Assoziationen, die aus Domänenwissen abgeleitet werden: Wenn eine SIGINT-Emitterpeilung konsistent mit einer IMINT-Fahrzeugspur mitbewegt, handelt es sich wahrscheinlich um dieselbe Plattform. Diese Links erfordern explizite Regeldefinitionen und tragen eine geringere Konfidenz als weiche Links, die auf direkter Attributüberlappung basieren.

Die Auflösungs-Pipeline erzeugt Übereinstimmungshypothesen. Hypothesen über einem hohen Konfidenz-Schwellenwert werden automatisch in den Golden Record fusioniert. Hypothesen im mittleren Bereich werden zur Analyst-Überprüfung markiert. Hypothesen unterhalb des niedrigen Schwellenwerts werden als separate Entities beibehalten. Die Schwellenwerte sind konfigurierbar und sollten pro Entity-Typ abstimmbar sein — Fusionen von Person-Entities erfordern höhere Konfidenz-Schwellenwerte als Ausrüstungsfusionen, weil falsche Personenfusionen schlimmere analytische Konsequenzen haben als falsche Ausrüstungsfusionen.

Das Golden-Record-Management erfordert eine definierte Zusammenführungsrichtlinie für Attributkonflikte. Wenn zwei Quellen bei einem Attribut nicht übereinstimmen — ein HUMINT-Bericht sagt, eine Person war an Ort A, eine IMINT-Detektierung platziert sie eine Stunde später an Ort B — muss die Zusammenführungsrichtlinie angeben, wie das Attribut im Golden Record verrechnet werden soll. Übliche Richtlinien umfassen: neueste Gültigkeitszeit gewinnt, höchste Quellenzuverlässigkeit gewinnt, gewichtete Kombination für numerische Attribute. Die gewählte Richtlinie muss als Metadaten im Golden Record gespeichert werden, damit Analysten verstehen können, warum der Golden Record einen bestimmten Attributwert zeigt.

Das JDL-Datenfusionsmodell rahmt die Entity-Auflösung als Level-1- (Objektverfeinerung) und Level-2-Problem (Situationsverfeinerung) ein. Das hier beschriebene Schema-Design ist das, was diese JDL-Ebenen in der Praxis implementierbar macht.

Zeitliche Modellierung: Gültigkeitszeit vs. Transaktionszeit

Bi-temporale Modellierung ist für eine militärische Aufklärungsplattform keine Option. Es ist die minimale zeitliche Struktur, die benötigt wird, um die zwei kritischsten Abfragetypen zu unterstützen: „Was war zum Zeitpunkt T in der Welt wahr?" (Gültigkeitszeitabfrage) und „Was wusste das System über X zum Zeitpunkt T?" (Transaktionszeitabfrage). Das sind verschiedene Fragen, die verschiedene Antworten erfordern, und ein Schema, das sie vermischt — indem es einen einzelnen Zeitstempel pro Datensatz verwendet — kann keine von beiden korrekt beantworten.

Gültigkeitszeit gibt an, wann eine Tatsache in der realen Welt wahr war. Für eine IMINT-Detektierung eines Fahrzeugs an einer Gitterkoordinate ist die Gültigkeitszeit der Bildgebungszeitstempel. Für einen HUMINT-Bericht, der ein Treffen beschreibt, ist die Gültigkeitszeit die beste Schätzung des Analysten, wann das Treffen stattfand — was ein Bereich von Tagen sein kann, kein präziser Zeitstempel. Die Gültigkeitszeit ist eine Eigenschaft der Welt, nicht der Datenbank.

Transaktionszeit gibt an, wann ein Datensatz in der Datenbank aktuell war. Für dieselbe IMINT-Detektierung beginnt die Transaktionszeit, wenn der Detektierungsdatensatz eingefügt wurde, und endet, wenn der Datensatz jemals überholt wird (z. B. wenn die Geolokalisierung neu verarbeitet und korrigiert wird). Die Transaktionszeit ist eine Eigenschaft der Datenbank, die automatisch vom System verwaltet wird.

Die Kombination ermöglicht zwei kritische Operationen. Erstens, Zeitpunktabfragen: „Rekonstruiere das vollständige Aufklärungsbild, wie das System es um 14:00 Uhr an Tag D hatte." Dies erfordert die Abfrage über die Transaktionszeit — nur Datensätze zurückgeben, die in der Datenbank um 14:00 Uhr an Tag D aktuell waren, unabhängig davon, wann ihre Gültigkeitszeit liegt. Dies ist unerlässlich für die Nachfallanalyse und für die Prüfung von aufklärungsbasierten Entscheidungen. Zweitens, historische Faktenabfragen: „Welche Ereignisse fanden an Ort X zwischen Tag D-7 und Tag D statt?" Dies fragt über die Gültigkeitszeit ab — Datensätze zurückgeben, deren Gültigkeitszeitintervall das Abfragefenster überlappt, unabhängig davon, wann sie eingefügt wurden.

Die Implementierung in PostgreSQL verwendet Period-Spalten. Die Gültigkeitszeitdimension wird als tstzrange-Spalte (zeitzonenbewusster Zeitstempelbereich) dargestellt. Die Transaktionszeitdimension verwendet entweder eine System-Period-Temporaltabelle (in einigen PostgreSQL-Erweiterungen nativ unterstützt) oder ein explizites transaction_start- und transaction_end-Spaltenpaar, wobei transaction_end auf Unendlichkeit für aktuelle Zeilen gesetzt und bei Updates gestempelt wird, um anzuzeigen, wann die Zeile überholt wurde. Alle Updates müssen als neue-Zeile-einfügen / alte-Zeile-stempeln implementiert werden, niemals als direkte Überschreibungen.

Versionskontrolle und Herkunftslinie für fusionierte Objekte

Aufklärungsentities sind nicht statisch. Eine Person-Entity kann als vorläufige Identifikation aus einem einzigen HUMINT-Bericht beginnen, drei Tage später eine räumliche Bestätigung durch eine IMINT-Detektierung erhalten und eine Woche danach eine biometrische Bestätigung von einem separaten Sammelereignis erhalten. Jedes dieser Updates ändert den Golden Record — aber die früheren Zustände müssen wiederherstellbar sein, nicht überschrieben.

Die Standardimplementierung ist ein nur-Anhang-Ereignisprotokoll pro Entity. Jede Zustandsänderung eines Golden Records erzeugt ein Update-Ereignis. Jedes Ereignis ist nach dem Schreiben unveränderlich und trägt:

• Die Entity-UUID
• Den Ereignistyp (Erstellt / Aktualisiert / Zusammengeführt / Getrennt / Zurückgezogen)
• Den vorherigen Zustands-Snapshot (vollständige Kopie des Golden Records vor der Änderung)
• Den neuen Zustands-Snapshot
• Die IDs der Beobachtungsdatensätze, die das Update ausgelöst haben
• Den angewandten Fusionsrichtliniennamen und die Version
• Den Transaktionszeitstempel
• Die Operator-ID (menschlicher Analyst oder Systemprozess)

Der aktuelle Golden Record ist das Ergebnis der Anwendung aller Ereignisse in Sequenz vom Beginn des Protokolls an. Dies ist das Event-Sourcing-Muster, angewendet auf Aufklärungsdaten. Es liefert einen vollständigen Audit-Trail für jeden Entity-Zustand zu jedem Zeitpunkt, was für die Aufklärungsverantwortlichkeit in den meisten militärischen Rahmenbedingungen erforderlich ist.

Rollback ist eine erstklassige Operation: Angesichts einer Entity-UUID und eines Ziel-Transaktionszeitstempels re-materialisiert die Plattform den Golden Record, wie er zu diesem Zeitstempel existierte, indem sie das Ereignisprotokoll bis zu, aber nicht einschließlich der Ereignisse nach der Zielzeit abspielt. Rollback wird ausgelöst, wenn eine Quelle als täuschend oder fehlerhaft bewertet wird — alle Golden Records, die Beobachtungen aus dieser Quelle enthielten, müssen mit den kontaminierten Beobachtungen neu bewertet werden.

Ein Rückzugsereignis ist der Mechanismus zur Handhabung dieses Szenarios in großem Maßstab. Wenn Quelle S invalidiert wird, erzeugt das System ein Rückzugsereignis für jede Beobachtung, die S zugeschrieben wird, und führt dann die Fusion für jede Entity neu aus, die eine dieser Beobachtungen referenziert hat. Entities, die ausschließlich durch die zurückgezogene Quelle unterstützt wurden, kehren zu einem niedrigeren Konfidenz-Zustand zurück oder werden als unbestätigt markiert. Entities, die korrelierende Quellen aus anderen INTs hatten, absorbieren den Rückzug mit einer Konfidenzstrafe, bleiben aber im Bild.

Das Herkunftslinienmodell ermöglicht auch Trennereignisse — das Gegenteil der Entity-Auflösung. Wenn zwei Entities fälschlicherweise zusammengeführt wurden (eine falsch-positive Fusion), trennt ein Trennereignis sie wieder auf: Der fehlerhafte Golden Record wird zurückgezogen, und zwei neue Entity-Datensätze werden erstellt, von denen jeder die Quellbeobachtungen erbt, die eigentlich zu ihm gehören. Das Trennereignis bewahrt die vollständige Geschichte des zusammengeführten Zustands und der Trennentscheidung, sodass spätere Analysten verstehen können, warum die Trennung stattgefunden hat.

Schema-Evolution im Produktionsbetrieb

Eine militärische Aufklärungsplattform ist kein statisches Produkt. Neue Sammelsysteme gehen online, neue INT-Disziplinen werden in den Umfang aufgenommen, und bestehende Schemata benötigen Attributzusätze, wenn neue analytische Anforderungen entstehen. Die Schema-Evolution in einer Produktionsplattform, die keine Ausfallzeiten tolerieren kann, erfordert von Anfang an bewusste Designentscheidungen.

Das Kernprinzip ist Rückwärtskompatibilität als Vertrag. Das Kern-Entity-Envelope — die EntityCore-Felder — muss mit einem schema_version-Feld streng versioniert werden. Jede Änderung am Kern-Envelope, die ein Feld entfernt oder den Typ eines Feldes ändert, ist eine bahnbrechende Änderung und erfordert einen Major-Version-Bump mit einem definierten Migrationspfad. Das Hinzufügen optionaler Felder zum Kern ist eine Minor-Version-Änderung. Das Versionsfeld ermöglicht es Konsumenten, die von ihnen unterstützten Schema-Versionen zu deklarieren, und ermöglicht es der Plattform, während eines Migrationszeitraums verschiedene Versionen an verschiedene Konsumenten zu liefern.

Erweiterungs-Payloads sind das richtige Vehikel für das Hinzufügen neuer INT-Typen oder neuer Attribute. Wenn ein neues Bildanalysesystem online geht und zusätzliche Attributtypen produziert (zum Beispiel strukturelle Schadenbewertungswerte aus SAR-Bildern), gehen diese Attribute in eine neue oder aktualisierte IMINT-Erweiterungs-Payload-Version — nicht in das Kern-Entity-Schema. Bestehende Konsumenten, die keine SAR-spezifischen Attribute benötigen, sind nicht betroffen.

Die Herkunftstaxonomie muss erweitert werden, wenn ein neuer INT-Typ hinzugefügt wird. Die INT-Typ-Aufzählung erhält einen neuen Wert, und die Definitionen der Quellenzuverlässigkeits- und Glaubwürdigkeitsbewertungen müssen auf Anwendbarkeit für den neuen Quellentyp überprüft werden. Einige neue Quellentypen erfordern möglicherweise neue Glaubwürdigkeitskriterien, die sich nicht sauber auf die bestehende sechspunktige Admiralty-Skala abbilden lassen — in diesen Fällen sollte der Herkunftsblock die quellenspezifischen Rohdaten zur Zuverlässigkeit zusätzlich zur übersetzten Admiralty-Bewertung tragen und dabei die Genauigkeit bewahren.

Entity-Auflösungsregeln sind der arbeitsintensivste Evolutionspfad. Wenn ein neuer INT-Typ dem einheitlichen Modell beitritt, müssen Auflösungsingenieure angeben, wie Beobachtungen aus der neuen Quelle mit bestehenden Entity-Typen verknüpft werden können. Dies erfordert sowohl Datenanalyse (welche Attribute stehen zum Abgleich zur Verfügung?) als auch Domänenwissen (welche Attributnähe-Schwellenwerte sind operativ sinnvoll?). Diese Regeln müssen von erfahrenen Aufklärungsanalysten begutachtet werden, nicht nur von Softwareingenieuren — falsche Auflösungsregeln produzieren falsche Fusionen, die das Aufklärungsbild still und heimlich verfälschen.

Schema-Migration in einem bi-temporalen Modell hat eine zusätzliche Überlegung: Historische Zeilen müssen migriert werden, ohne ihre Transaktionszeitgeschichte zu verändern. Eine Migration, die bestehende Zeilen neu schreibt und ihre Transaktionszeitstempel aktualisiert, bricht die historischen Abfragesemantiken. Migrationen müssen additiv sein: neue Spalten mit Standardwerten für historische Zeilen hinzufügen, niemals bestehende Spaltenwerte in historischen Datensätzen aktualisieren.

Das Testen der Schema-Evolution erfordert eine mehrschichtige Strategie: Unit-Tests für die Serialisierung und Deserialisierung jeder Schema-Version; Integrationstests für die versionsübergreifende Konsumenten-Kompatibilität; und Regressionstests mit historischen Aufklärungsdatensätzen, um zu bestätigen, dass bestehende Abfragen nach einer Migration noch identische Ergebnisse liefern. Die historischen Datentests werden am häufigsten übersprungen und erfassen die meisten produktionsbrechenden Regressionen.

Das in diesem Artikel beschriebene Datenmodell stellt ein Design-Ziel dar, keinen Ausgangspunkt für eine Ein-Sprint-Implementierung. Die meisten Plattformen bauen schrittweise auf diese Architektur hin — beginnend mit einem einfacheren Schema für zwei oder drei INT-Typen und fügen das bi-temporale Modell, vollständige Herkunftsblöcke und ereignisgestützte Herkunftslinien hinzu, wenn sich die operativen Anforderungen festigen. Wichtig ist, dass die grundlegenden Designentscheidungen — typisierte Erweiterungs-Payloads, INT-agnostische Entity-Envelopes, getrennte Gültigkeits- und Transaktionszeit — früh getroffen werden, denn diese nachträglich auf ein monolithisches Schema aufzurüsten ist weitaus teurer als sie von Anfang an einzubauen.