Spatial-AI-Observability

Spatial-AI-Observability verfolgt, wie ein ortsbezogenes System von einer Anfrage zu einem autorisierten Ort, einer geografischen Berechnung, einem gerankten Ergebnis, einer Kartenaktion und einem Ergebnis im Host-System gelangt. Modelllatenz und Token-Zahlen können zeigen, dass ein Aufruf abgeschlossen wurde. Diese beiden Werte zeigen jedoch nicht, ob der Ort zulässig war oder ob der Kunde seine Aufgabe abgeschlossen hat. Der nützliche Datensatz ist der Entscheidungspfad – klein genug gehalten, um das Ergebnis zu erklären, ohne private Standortdaten zu kopieren.

Die folgenden Abschnitte trennen Systemtelemetrie von der geografischen Entscheidung, benennen, was verfolgt werden sollte, und markieren, was nicht ins Log gehört. Verwandte Beiträge sind Spatial AI Accuracy Evaluation und An Enterprise Spatial AI Pilot. Auch ein gesund wirkender Service-Graph kann einen falschen Ort verbergen.

Grundlagen der Spatial-AI-Observability

• Die Entscheidung verfolgen: Autorisierung, Abruf, Ortsidentität, Geografie, Zulässigkeit, Ranking, Tools und das Ergebnis im Host-System sind getrennte Spans.
• IDs statt Kopien speichern: Kennungen für Ort, Route, Richtlinie, Modell und Aktion erklären mehr als eingefügte Prompts.
• Inhalte minimieren: Geheimnisse, rohe private Datensätze und präzise Standorte bleiben standardmäßig außerhalb des Telemetriespeichers.
• Entfernungen mitzählen: Eine Ergebniszahl ist unvollständig, wenn nicht erfasst wird, warum jeder Kandidat aus der Menge entfernt wurde.
• Ein gemeinsames Fehlervokabular verwenden: Offline-Fälle und Produktionsvorfälle sollten dieselben Kategorien nutzen.

Was ist Spatial-AI-Observability?

Ein Kunde kann fragen, welches Geschäft auf dem Heimweg einen Artikel noch auf Lager hat und bei der Ankunft geöffnet sein wird. Die Antwort hängt von Identität, aktuellem Bestand, Öffnungszeiten, einer Route, Zulässigkeitsregeln, einer Ranking-Richtlinie, einer Kartenaktion und davon ab, ob die Person tatsächlich ein Geschäft ausgewählt hat. Ein Trace, der beim Modellaufruf endet, kann Tokens und Latenz melden und trotzdem jeden dieser Schritte verpassen. Observability bedeutet hier, dass das Team die Entscheidung anhand strukturierter Signale rekonstruieren kann – nicht, dass jeder Prompt archiviert wird.

Das linke Panel beobachtet das Modell isoliert. Das rechte Panel behandelt das Modell als einen Span unter Abruf, Ortsauflösung, Zulässigkeit, Ranking, Tool-Validierung und Kartenaktion. Diese Trennung ist ein Observability-Muster, kein Kaleidr-Benchmark.

Drei Arten von Wahrheit müssen zusammenkommen. Systemwahrheit umfasst Latenz, Fehler, Wiederholungsversuche und den Zustand von Abhängigkeiten. Entscheidungswahrheit umfasst, welche Orts-IDs autorisiert wurden, welche Kandidaten an einer harten Regel scheiterten, welche Route ausgeführt und welche Aktion validiert wurde. Ergebniswahrheit umfasst, ob ein Ort ausgewählt, eine Route geöffnet oder ein Host-Workflow abgeschlossen wurde. Ein Dashboard nur mit der ersten Art kann ruhig aussehen, während das Produkt ein geschlossenes Geschäft empfiehlt. Ein Dashboard nur mit Karteninteraktionen kann geschäftig wirken, während im Hintergrund ein teures Tool wiederholt versucht wird.

Was gehört in einen einzelnen Spatial-AI-Trace?

Eine Anfrage sollte eine stabile Request-ID durch die tatsächlich ausgeführten Phasen tragen. Die Autorisierung protokolliert die Richtlinienversion sowie das Erlaubt- oder Abgelehnt-Ergebnis. Der Abruf protokolliert die Quelle und die Anzahl zurückgegebener Datensätze, nicht die privaten Zeilen. Die Ortsauflösung protokolliert die Kandidaten-IDs. Das Routing protokolliert eine Route-ID und einen Status. Die Zulässigkeit protokolliert, wie viele Kandidaten verblieben und warum andere entfernt wurden. Das Ranking protokolliert die Richtlinienversion und die geordneten IDs. Der Modell-Span protokolliert Anbieter, Versionsbezeichnung und Token-Zahlen. Die Tool-Validierung hält fest, ob eine vorgeschlagene Aktion abgelehnt oder ausgeführt wurde. Abschließende Events erfassen einen ausgewählten Ort und – wenn der Host ihn meldet – einen abgeschlossenen Workflow.

Der Parent-Span ist die Anfrage. Child-Spans decken die Phasen ab, die unabhängig voneinander fehlschlagen können; die Abschlussmarken sind „Ort ausgewählt“ und „Workflow abgeschlossen“. Die Dauerangaben in der Abbildung sind ein illustrativer Trace, keine gemessene Kaleidr-Latenz.

Nicht jede Anfrage benötigt jeden Span. Eine Aktion wie „diesen Ort anzeigen“ kann das Ranking überspringen. Eine Serviceempfehlung kann die gesamte Kette nutzen. Der Trace sollte angeben, welche Phasen ausgeführt und welche übersprungen wurden, damit ein fehlender Routing-Span nicht mit einem erfolgreichen Routing verwechselt wird. Versionsbezeichnungen in der Abbildung, einschließlich eines auf einer Karte gedruckten Modellnamens, sind Beispielmetadaten und kein Kaleidr-Modellkatalog.

Wie sollten Traces, Metriken, Events und Logs getrennt werden?

Traces beantworten, wo innerhalb einer einzelnen Anfrage Zeit verbraucht wurde. Metriken zeigen, ob sich eine Rate über viele Anfragen hinweg verschlechtert, etwa p95-Latenz, No-Result-Rate oder Tool-Fehlerrate. Events halten fest, was sich zu einem bestimmten Zeitpunkt geändert hat, etwa dass ein Kandidat entfernt, ein Ort ausgewählt oder eine Aktion abgelehnt wurde. Logs enthalten Diagnoseinformationen, die keine formale Metrik werden müssen, etwa eine Parser-Warnung. Werden diese Aufgaben vermischt, wird der teuerste Speicher schnell zum Standardspeicher.

Die Event-Empfehlungen von OpenTelemetry ziehen dieselbe Grenze. Operationen mit Dauer und sinnvoller Abgrenzung gehören in Spans. Ein Prüfpunkt, eine Zustandsänderung oder ein anderes punktuelles Ergebnis innerhalb einer längeren Operation ist ein Kandidat für ein Event (OpenTelemetry, 2026). Ein Artikel von James Newton-King vom 14. Mai 2026 zeigt Generative-AI-Operationen als Traces, einschließlich Modellaufrufen und Tool-Aktivität, und weist darauf hin, dass Prompt-Inhalte und Tool-Argumente standardmäßig aus der Telemetrie herausbleiben, weil sie sensible Daten enthalten können (Newton-King, 2026). Die Dokumentation zu Semantic Conventions, auf der für diesen Beitrag gelesenen Seite mit 1.44.0 gekennzeichnet, definiert gemeinsame Namen für Traces, Metriken und Logs (OpenTelemetry, 2026). Räumliche Attribute wie eine Orts-Ergebnismengen-ID oder ein No-Result-Grund können daneben stehen. Diese räumlichen Namen sind Anwendungsbeispiele und keine offiziellen räumlichen OpenTelemetry-Konventionen.

Was sollte außerhalb des Telemetriespeichers bleiben?

Observability verfehlt ihr Ziel, wenn das Telemetriesystem zu einer zweiten Kopie von Kunden-, Standort- oder Geschäftsdaten wird. Standardmäßig sollten Kennungen, Versionen, Anzahlen, Status, Latenz und Reason Codes aufgezeichnet werden. Redigierte Ausschnitte, gesampelte Inhalte und verallgemeinerte Geografie sollten nur bedingt und nur mit einem benannten Bedarf, einer Aufbewahrungsfrist und Zugriffskontrolle verwendet werden. Zu vermeiden sind Geheimnisse, rohe private Datensätze, vollständige uneingeschränkte Prompts, präzise Koordinaten, die für die Frage nicht benötigt werden, und Zugriffstokens. Ein Stadt- oder Marktcode beantwortet die operative Frage oft ebenso gut wie eine rohe Adresse.

Die linke Spalte ist der Standarddatensatz. Die mittlere Spalte benötigt eine Schutzmaßnahme. Die rechte Spalte bleibt außen vor, sofern keine spezifische Kontrolle sie rechtfertigt. Die Abbildung zeigt ein Minimierungsmuster, keine Zertifizierung.

Das Attributregister von OpenTelemetry für Generative AI warnt, dass Text aus Retrieval-Anfragen sensible Informationen enthalten kann, und kennzeichnet mehrere inhaltstragende Attribute als wahrscheinlich nutzer- oder personenbezogene Daten enthaltend (OpenTelemetry, 2026). Kaleidrs Leitfaden zu privaten Standortdaten setzt die Autorisierung bereits vor den Moment, in dem das Modell Datensätze erhält, und warnt davor, eine uneingeschränkte interne Datenbank hochzuladen (Kaleidr, 2026). Ein Trace sollte diese Grenze bewahren. Protokollieren Sie, dass die Autorisierung für eine Ergebnismengen-ID bestanden wurde. Protokollieren Sie nicht die privaten Zeilen, die diese Prüfung freigegeben hat.

Warum sollte protokolliert werden, warum ein Kandidat verschwunden ist?

Eine einzelne Ergebniszahl kann eine schlechte Empfehlung nicht erklären. Ein nützlicher Funnel erfasst, wie viele Kandidaten abgerufen wurden, wie viele nach der Autorisierung verblieben und wie viele nach Anwendung harter Regeln übrig waren. Jede Entfernung braucht einen Reason Code: geschlossen, nicht auf Lager, außerhalb des Servicegebiets, fehlende Öffnungszeiten, nicht autorisiert oder unbekannte Aktualität. Ohne diesen Grund sieht ein Rückgang von zwanzig auf sechs Kandidaten wie eine Ranking-Entscheidung aus, obwohl er durch einen Zulässigkeitsfilter verursacht wurde.

Die Zahlen in dieser Abbildung zeigen eine illustrative Anfrage, keine Kaleidr-Messung. Die Seitenkarten zeigen, warum Kandidaten die Menge verlassen haben. Ein Produktions-Trace sollte diese Reason Codes speichern, nicht nur die Endsumme.

Kaleidrs Leitfaden zu grounded Spatial AI empfiehlt bereits strukturierte No-Result-Gründe wie geschlossen, nicht auf Lager, außerhalb des Gebiets, unbekannte Öffnungszeiten oder nicht autorisiert statt eines bloßen Fehler-Flags (Kaleidr, 2026). Ein gültiges No-Result bedeutet, dass jeder Kandidat an einer harten Regel gescheitert ist. Ein Systemfehler bedeutet, dass die Quelle nicht verfügbar oder zu veraltet war, um zu entscheiden. Diese beiden Endzustände brauchen unterschiedliche Alerts. Wird eine kritische Einschränkung stillschweigend gelockert, wird aus einer gültigen leeren Menge eine falsche Empfehlung.

Wie sollte ein Tool-Aufruf verfolgt werden?

Ein Modell kann einen Tool-Aufruf vorschlagen. Ein Vorschlag ist keine Genehmigung, eine Genehmigung ist keine Ausführung und eine Ausführung ist noch keine abgeschlossene Geschäftsaktion. Erfassen Sie Tool-Name, Ergebnis der Schema-Validierung, Autorisierungsentscheidung, Policy-Prüfung, Ausführungsstatus, Latenz und Fehlergrund. Ablehnungspfade sind ebenso wichtig wie der Erfolgspfad: ungültige Argumente, ein nicht autorisierter Aufrufer, eine blockierende Richtlinie oder ein Ausführungsfehler. Das Host-Ergebnis, etwa eine abgeschlossene Buchung, bleibt in dem System, das die Transaktion besitzt.

Jedes Gate kann den Aufruf vor der Ausführung stoppen. Die abschließende Frage lautet, ob der Host-Job abgeschlossen wurde, nicht nur, ob das Tool eine Nutzlast zurückgegeben hat. Die Status-Chips sind eine Architekturskizze und keine feste Kaleidr-Berechtigungsliste.

Kartenaktionen gehören in dasselbe Muster. „Orte anzeigen“, „Bounds anpassen“ und „Route zeichnen“ sind semantische Aktionen. Der Adapter, der mit dem Renderer kommuniziert, sollte ein „ausgeführt“- oder „abgelehnt“-Event ausgeben. Der Modell-Span sollte nicht der einzige Nachweis dafür sein, dass ein Pin erschienen ist. Wenn der Assistent einen Ort beschreibt, den die Karte nie angezeigt hat, sollte der Trace diese Abweichung sichtbar machen.

Wie sollte Produktionsverhalten nach Ort gelesen werden?

Ein globaler Durchschnitt verbirgt lokale Fehler. Segmentieren Sie die Qualität nach Markt, Sprache, Datenquelle, Aufgabentyp und Systemversion und verwenden Sie dabei die gröbste Geografie, die die Frage noch beantwortet. Ein Stadtcode oder eine Markt-ID reicht oft aus. Exakte Gerätekoordinaten sind nicht nötig, um zu erkennen, dass eine Region leere Ergebnismengen liefert oder ein Routing-Anbieter ausfällt. Neue Märkte, ein geänderter Ortsdatenanbieter, eine neue Sprache und eine Verschiebung der gestellten Fragen sind alles Formen von Drift; Modell-Drift ist nur eine davon.

NIST Measure 2.4 besagt, dass Funktionalität und Verhalten eines KI-Systems und seiner Komponenten in Produktion überwacht werden, weil Systeme mit der Entwicklung ihrer Umgebung auf neue Probleme und Risiken treffen können. Die Seite bezeichnet diesen Effekt als Drift und erklärt, dass Drift bedeutet, dass Systeme die Annahmen und Grenzen des ursprünglichen Designs nicht mehr erfüllen. Als vorgeschlagene Maßnahme wird genannt, zu dokumentieren, wie sich in Produktion beobachtete Metriken von denselben Metriken aus Tests vor der Bereitstellung unterscheiden (NIST, 2026). Dieselbe Seite weist darauf hin, dass AI RMF 1.0 aktualisiert wird und das Playbook nach dieser Revision ebenfalls aktualisiert werden soll. Die Seite liefert Kontext dafür, was beobachtet werden sollte. Sie ist keine Kaleidr-Kontrollliste.

Wie treffen Evaluation und Produktion zusammen?

Offline-Evaluation fragt, wie sich das System in kontrollierten Fällen mit bekannter Wahrheit verhält. Produktionsmonitoring fragt, wie es sich mit realen Nutzern, Live-Daten und realer Geografie verhält. Beide Programme sollten dieselben Fehlerkategorien verwenden, etwa Interpretation, Grounding, räumliche Berechnung, Ranking, Aktion und Recovery. Ein Produktionsvorfall wird dann zu einem Testfall. Eine Benchmark-Regression wird zu etwas, das das Produktionsdashboard nach dem Launch erkennen kann. Kaleidrs Accuracy-Leitfaden bewertet diese Entscheidungskette statt eines einzigen vermischten Modell-Scores (Kaleidr, 2026).

Evaluation liefert Fälle, Ground Truth und eine Regressionssuite. Produktion liefert reale Anfragen, Vorfälle, Drift und Ergebnisse. Die gemeinsamen Kategorien in der Mitte sind der Vertrag zwischen beiden. Die Schleife ist eine Methode, kein gemeldeter Kaleidr-Score.

Wo passt Kaleidr Analytics hinein?

Kaleidr Analytics beschreibt derzeit Dashboards für Reichweite, Aufrufe und Engagement, Standort und Aktivität des Publikums, Sessions, Aufrufe und Interaktionen pro Karte, Ortsvergleiche sowie räumliche Muster (Kaleidr, 2026). Diese Signale beschreiben, wie Menschen Karten und Orte nutzen; sie sind jedoch kein verteilter Trace von Autorisierung, Abruf, Routing, Modellaufrufen oder Host-Transaktionen. Der Host sollte weiterhin private Services sowie die Systeme instrumentieren, die Buchungen, Käufe und andere Ergebnisse erfassen. Eine stabile Map-ID, Place-ID oder Workflow-ID kann beide Seiten verbinden, ohne jeden internen Datensatz in die Analytics-Schicht zu kopieren.

Analytics deckt dokumentiertes Karten- und Orts-Engagement ab. Die Host-Spalte deckt private Traces und Transaktionsergebnisse ab. Die Verbindung ist eine Kennung; die Chips für Buchung und Kauf sind Host-Datensätze und keine Behauptung, dass Kaleidr Analytics diese Transaktionen speichert.

Kaleidr Enterprise ist die Spatial-Intelligence-Schicht, die ein Produktteam neben diesem Host-Stack ergänzen kann, einschließlich Inference APIs, Ranking und Analytics (Kaleidr, 2026). Karten- und Assistenzsignale ersetzen weiterhin weder ein vom Host besessenes Ergebnis noch einen von Finance genehmigten Einheitswert. Kaleidrs ROI-Leitfaden macht diese Trennung ausdrücklich: Frühindikatoren erklären den Pfad, und der Host-Datensatz trägt den Wert (Kaleidr, 2026).

Wie wird Spatial-AI-Observability zu einem Release-Gate?

Bevor ein ortsbezogener Workflow skaliert, sollte das Team anhand des Trace allein eine kurze Fragenliste beantworten können. Welche Richtlinienversion hat die Datensätze autorisiert? Welche Place-IDs wurden abgerufen und welche Reason Codes entfernten den Rest? Welche Route und welche Ranking-Richtlinie wurden ausgeführt? Welche Modell- und Tool-Versionen waren aktiv? Welche Kartenaktion wurde ausgeführt, und wurde der Host-Job abgeschlossen? Sensible Inhalte sollten minimiert, Versionen aufgezeichnet und Produktionsvorfälle im selben Fehlervokabular wie die Offline-Suite erfasst werden. Kaleidr Analytics erkunden für dokumentiertes Karten- und Orts-Engagement. Kaleidr Enterprise erkunden, um räumliche Funktionen neben den Systemen hinzuzufügen, die Nutzer, Daten und Ergebnisse bereits besitzen.

Hinweis: Kaleidr verwendet KI-gestützte Tools für Bilderstellung, Inhaltsverfeinerung und Recherche in seinen kreativen und Entwicklungs-Workflows.

FAQs

Ist Spatial-AI-Observability dasselbe wie Sprachmodell-Monitoring?

Nein. Modelllatenz, Tokens und Tool-Fehler decken einen Span ab. Ortsidentität, Berechtigungen, Geschäftsdaten, geografische Dienste, Ranking, Kartenstatus und das Host-Ergebnis können alle beeinflussen, ob das Ergebnis richtig war.

Sollten Nutzer-Prompts protokolliert werden?

Protokollieren Sie Prompts nur bei klar definiertem Bedarf, einer Aufbewahrungsfrist und Zugriffskontrolle. Viele Standortanfragen enthalten private Adressen oder Geschäftsfakten, die ein Trace nicht vollständig benötigt.

Sollte der präzise Nutzerstandort in Traces gespeichert werden?

Verwenden Sie die gröbste Geografie, die die operative Frage beantwortet, etwa einen Marktcode, eine Place-ID oder eine Route-ID.

Was ist der Unterschied zwischen Monitoring und Evaluation?

Monitoring beobachtet Live-Verhalten in Produktion. Evaluation testet definierte Fälle gegen Ground Truth. Ein starkes Programm nutzt ein gemeinsames Fehlervokabular, sodass ein Vorfall zu einem Test und eine Regression nach dem Launch sichtbar werden kann.

Was ist die wichtigste Metrik?

Es gibt keine universelle Metrik. Binden Sie die Messgröße an die Aufgabe: Qualität zulässiger Ergebnisse, Ortsauflösung, Korrektheit von No-Result, Routenerfolg, Autorisierungskorrektheit oder Aufgabenabschluss.

Wie sollten Tool-Aufrufe verfolgt werden?

Erfassen Sie Tool-Name, Schema-Validierung, Autorisierung, Richtlinienergebnis, Ausführungsstatus, Latenz und Fehlergrund. Halten Sie eine vorgeschlagene Aktion getrennt von einer ausgeführten Aktion und von einem abgeschlossenen Host-Ergebnis.

Ersetzt Kaleidr Analytics die Observability der Anwendung?

Nein. Die öffentliche Analytics-Seite beschreibt Karten- und Orts-Engagement, Sessions, Aufrufe, Interaktionen, Publikumsaktivität und räumliche Muster. Traces privater Services, interne Autorisierung und Transaktionsergebnisse verbleiben beim Host, sofern eine konkrete Integration nichts anderes vorsieht.

Kann OpenTelemetry für Spatial AI verwendet werden?

Ja. OpenTelemetry ist eine praktische Basis für Traces, Metriken, Logs, Events und aktuelle Konventionen für Generative AI. Teams können dokumentierte Attribute für Place-IDs, Route-IDs, Zulässigkeit, Ranking, Kartenaktionen und No-Result-Gründe ergänzen, wo die gemeinsamen Konventionen sie nicht bereits benennen.

Referenzen

1. Kaleidr. Spatial AI Accuracy Evaluation. https://kaleidr.com/blog/spatial-ai-accuracy-evaluation
2. Kaleidr. An Enterprise Spatial AI Pilot Before Scaling. https://kaleidr.com/blog/enterprise-spatial-ai-pilot-before-scaling
3. OpenTelemetry. Semantic Conventions for Events. Operations with a duration belong in spans. Checkpoints and point-in-time outcomes are event candidates. Accessed October 1, 2026. https://opentelemetry.io/docs/specs/semconv/general/events/
4. OpenTelemetry. Inside the LLM Call: GenAI Observability with OpenTelemetry. James Newton-King, May 14, 2026. https://opentelemetry.io/blog/2026/genai-observability/
5. OpenTelemetry. Semantic Conventions. Documentation labeled 1.44.0. Accessed October 1, 2026. https://opentelemetry.io/docs/specs/semconv/
6. OpenTelemetry. Generative AI Semantic Convention Attributes. Registry warns that retrieval query text may contain sensitive information. Accessed October 1, 2026. https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/
7. Kaleidr. Private Location Data for AI Map Workflows. https://kaleidr.com/blog/private-location-data-for-ai-map-workflows
8. Kaleidr. Grounded Spatial AI for Business Data. https://kaleidr.com/blog/grounded-spatial-ai-business-data
9. National Institute of Standards and Technology. AI RMF Playbook, Measure. Production monitoring, drift, and the difference from pre-deployment testing. Notes that the AI RMF 1.0 is being updated and that the playbook will be revised afterward. Accessed October 1, 2026. https://airc.nist.gov/airmf-resources/playbook/measure/
10. Kaleidr. Map Engagement and Location Analytics. Accessed October 1, 2026. https://kaleidr.com/analytics
11. Kaleidr. Location Intelligence APIs and Map SDK. Accessed October 1, 2026. https://kaleidr.com/enterprise
12. Kaleidr. Spatial AI ROI Business Case. https://kaleidr.com/blog/spatial-ai-roi-business-case

@misc{kaleidr_accuracy_observability_2026,
  title  = {Spatial AI Accuracy Evaluation},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/spatial-ai-accuracy-evaluation}
}

@misc{kaleidr_pilot_observability_2026,
  title  = {An Enterprise Spatial AI Pilot Before Scaling},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/enterprise-spatial-ai-pilot-before-scaling}
}

@misc{otel_events_2026,
  title  = {Semantic Conventions for Events},
  author = {{OpenTelemetry}},
  year   = {2026},
  note   = {Accessed October 1, 2026},
  url    = {https://opentelemetry.io/docs/specs/semconv/general/events/}
}

@misc{otel_genai_observability_2026,
  title  = {Inside the LLM Call: GenAI Observability with OpenTelemetry},
  author = {Newton-King, James},
  year   = {2026},
  note   = {May 14, 2026},
  url    = {https://opentelemetry.io/blog/2026/genai-observability/}
}

@misc{otel_semconv_2026,
  title  = {Semantic Conventions},
  author = {{OpenTelemetry}},
  year   = {2026},
  note   = {Documentation labeled 1.44.0. Accessed October 1, 2026},
  url    = {https://opentelemetry.io/docs/specs/semconv/}
}

@misc{otel_genai_attributes_2026,
  title  = {Generative AI Semantic Convention Attributes},
  author = {{OpenTelemetry}},
  year   = {2026},
  note   = {Accessed October 1, 2026},
  url    = {https://opentelemetry.io/docs/specs/semconv/registry/attributes/gen-ai/}
}

@misc{kaleidr_private_location_2026,
  title  = {Private Location Data for AI Map Workflows},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/private-location-data-for-ai-map-workflows}
}

@misc{kaleidr_grounded_observability_2026,
  title  = {Grounded Spatial AI for Business Data},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/grounded-spatial-ai-business-data}
}

@misc{nist_rmf_playbook_measure_2026,
  title  = {AI RMF Playbook, Measure},
  author = {{National Institute of Standards and Technology}},
  year   = {2026},
  note   = {Accessed October 1, 2026. Page states the playbook will be updated after the AI RMF revision},
  url    = {https://airc.nist.gov/airmf-resources/playbook/measure/}
}

@misc{kaleidr_analytics_observability_2026,
  title  = {Map Engagement and Location Analytics},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed October 1, 2026},
  url    = {https://kaleidr.com/analytics}
}

@misc{kaleidr_enterprise_observability_2026,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  year   = {2026},
  note   = {Accessed October 1, 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{kaleidr_roi_observability_2026,
  title  = {Spatial AI ROI Business Case},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/spatial-ai-roi-business-case}
}