Place-Ranking-API für Kundenabsichten

Eine Place-Ranking-API ordnet zulässige Standorte für eine konkrete Kundenentscheidung anhand von räumlichem Kontext, Kundenabsicht, Geschäftsregeln und Aktualität. Harte Vorgaben wie Berechtigung, Verfügbarkeit, erforderlicher Service und Servicegebiet sind Filter, keine Scores. Das Sprachmodell kann eine Anfrage in strukturierte Anforderungen übersetzen; Geodaten- und Geschäftssysteme liefern die Fakten, die der Ranker kombiniert.

Im Folgenden geht es um Retrieval und Ranking, Ranking-Modi von Anbietern, harte Filter, geografische Merkmale, Grenzen der Intent-Erkennung, Feature-Design, Authentifizierung, die derzeit öffentlichen Kaleidr-Schnittstellen und Evaluation. Ergänzend: Location-Intelligence-Karten für die Customer Experience, Was ist eine Location-Intelligence-API?, Standortbezogene Buchung, KI-Filialfinder mit Kartenchat und So entsteht ein kartenfähiger KI-Assistent.

Grundlagen des Place Rankings

• Eignung vor Bewertung: Berechtigung, Verfügbarkeit, benötigte Fähigkeit und Servicegebiet entfernen ungültige Orte; sie senken nicht nur einen Zahlenwert.
• Das räumliche Merkmal muss zur Aufgabe passen: Luftlinie, Reisezeit, Routenumweg, Gebietszugehörigkeit und Multi-Anchor-Fit beantworten unterschiedliche Fragen.
• Intent ist strukturierte Eingabe: Das Sprachmodell interpretiert Präferenzen; Orts-, Bestands- und Routingsysteme bleiben die maßgeblichen Faktenquellen.
• Begründungen sind besser als undurchsichtige Scores: Kunden und Betreiber brauchen prüfbare Signale wie Reisezeit, Öffnungsstatus und erforderlichen Service.
• Die Entscheidung messen, nicht nur Klicks: Kandidatenabdeckung, Regelverstöße, veraltete Daten und Folgeergebnisse gehören zum Qualitätsvertrag.

Was ist eine Place-Ranking-API?

Eine Place-Ranking-API beantwortet, welche gültigen Standorte für diesen Kunden, diese Aufgabe und den aktuellen Zustand zuerst erscheinen sollen. Eine Such- oder Retrieval-API findet üblicherweise Kandidaten: Restaurants in der Nähe einer Stadt, Filialen im Kartenausschnitt oder Hotels entlang einer Route. Das Ranking ordnet anschließend die Orte, die nach Autorisierung und harten Eignungsprüfungen verbleiben. Produktive Location Intelligence benötigt meist alle drei Stufen – abrufen, filtern, ordnen. Ein hoher Score für einen ungültigen Datensatz ist ein Produktfehler, kein Ranking-Erfolg.

Das nützliche Ergebnis ist eine mit der Karte synchronisierte Reihenfolge, nicht eine einzelne undurchsichtige Zahl. Jeder Treffer sollte Ortskennung, Rang und wenige, auf realen Signalen beruhende Gründe enthalten. „Discover“ ruft zulässige Datensätze ab, „Compare“ macht Reisebeziehung, Service-Fit und Aktualität sichtbar, „Act“ führt zu Hervorhebung, Route, Buchungs- oder Abholübergabe beziehungsweise gespeichertem Ort.

Warum unterscheidet sich Ranking von der Suche nach dem nächsten Ort?

„Am nächsten“ ist eine legitime Regel, wenn der Kunde ausdrücklich den nächstgelegenen zulässigen Ort sucht und alle anderen Bedingungen erfüllt sind. Eine reine Distanzsortierung scheitert, sobald die nächste Filiale keine Abholung anbietet, geschlossen ist, keinen Bestand hat, einen großen Umweg erfordert oder außerhalb des Servicegebiets liegt. Die robustere Reihenfolge lautet: gültiger Ort, erforderlicher Service, aktuelle Verfügbarkeit, Reisebeziehung, Präferenz – erst dann sortieren.

Auch für die Produktsprache ist das wichtig. Filialfinder, Buchungslisten, Immobiliensuchen nach Pendelzeit und Ausstattungsführer für Veranstaltungsorte können alle wie „in meiner Nähe“ aussehen, benötigen aber unterschiedliche räumliche Merkmale. Harte Regeln gehören in die Eignungsprüfung; nur die verbleibenden Kandidaten werden bewertet.

Wie ordnen Suchanbieter Orte heute?

Aktuelle Kartensuch-APIs bieten bereits mehrere Ranking-Modi. Google Places Nearby Search (New) dokumentiert für rankPreference die Werte POPULARITY und DISTANCE (Nearby Search (New)). Text Search (New) unterstützt bei passenden kategorialen Anfragen RELEVANCE oder DISTANCE; bei nicht kategorialen Anfragen wie einem Städtenamen soll rankPreference laut Dokumentation unset bleiben (Text Search (New)). Diese Optionen ordnen den Kandidatenbestand des Anbieters, kennen aber keine privaten Bestände, Ticketregeln oder Buchungsfenster des Hostsystems.

Mapbox Search Box dokumentiert rank_strategy mit distance oder relevance, außerdem Proximity Bias, routenbezogene Suche und optionale ETA-Berechnung (Search Box API). Bei einer Eingaberoute können Vorschläge added_distance in Metern und added_time in Minuten enthalten – ein Umwegsignal statt bloßer Nähe. Google Places kann Text Search über searchAlongRouteParameters an einer Routenpolylinie ausrichten (Search along route). Anbieter-Ranking eignet sich zur Kandidatensuche; Produkt-Ranking beginnt bei der Anreicherung mit hosteigenen Fakten.

Welche Entscheidung soll eine Place-Ranking-API optimieren?

Beginnen Sie nicht mit der Forderung nach einem KI-Ranking-Modell, sondern mit der Entscheidung, die die Liste verbessern soll. Im Handel geht es um die passende Filiale, bei Buchungen um die verfügbare Option zur Reiseroute, bei Immobilien um Standortanforderungen, in Hotels um einen geeigneten Partner, bei Events um einen relevanten Aussteller oder Service und in Marktplätzen um den geografisch am besten passenden verfügbaren Anbieter.

Diese Entscheidung bestimmt Kandidaten, harte Bedingungen, räumliche und geschäftliche Merkmale, Labels und Messgrößen. Ein Pendelzeit-Ranker braucht Reisezeiten zu mehreren Ankern; ein Abhol-Ranker prüft zuerst Bestand und Öffnungsstatus; ein Ranker entlang einer Route braucht Umweg statt Luftlinie. Formulieren Sie die testbare Aufgabe in einem Satz. Ein vages „Relevanz“ verdeckt, dass zwei berechtigte Kunden für denselben Katalog gegensätzliche Reihenfolgen benötigen können.

Welche Pipeline sollte eine Place-Ranking-API verwenden?

Eine robuste Pipeline besteht aus Anfrageinterpretation, Kandidatenabruf, Autorisierung, harter Eignungsprüfung, Feature-Berechnung, Ranking, Begründung, Darstellung in Karte und Liste sowie Ergebnismessung. Ungültige Orte verlassen die Menge vor dem Scoring. Reisezeit, Umweg, Präferenz-Fit, Aktualität und Geschäftspolitik werden nur für die verbleibenden Orte berechnet. Die Gründe werden aus denselben Signalen abgeleitet, nicht unabhängig als Text erfunden.

Große Kataloge verteilen Kosten auf mehrere Stufen: Retrieval liefert eine begrenzte Menge; ein günstiges Vor-Ranking nutzt ungefähre Entfernung, Kategorie und grobe Verfügbarkeit; teure Reisezeitmatrizen, Umwege und tiefe Anreicherung laufen nur für die Shortlist. Größen und Latenzbudgets sind anwendungsspezifisch und sollten pro Stufe gemessen werden.

Warum müssen harte Filter vor Ranking-Signalen laufen?

Ein harter Filter ist binär: Ein Kandidat darf teilnehmen oder nicht. Typische Schranken sind aktiver Eintrag, gewünschter Service, aktueller Bestand, buchbares Zimmer, Zugehörigkeit zum Servicegebiet, Ticketberechtigung, Öffnung im gewünschten Zeitfenster und Leseberechtigung. Ranking-Signale vergleichen nur die Überlebenden: Reisezeit, Umweg, Distanz, Preis- oder Kategorien-Fit, Präferenz, Aktualität, Geschäftspriorität und historische Conversion. Eine Regel wie „nicht verfügbar = minus 20 Punkte“ kann einen ungültigen Ort weiterhin gewinnen lassen.

Erforderliche Barrierefreiheit, Berechtigungen, Rechtsgebiet, Bestand und Pflichtfähigkeiten folgen demselben Muster: zuerst ausschließen, dann die gültige Menge ordnen. Fehlende Daten sind dabei nicht automatisch ein schlechter Score. Fehlt etwa eine Bewertung, sind neutraler Standardwert, spezifischer Fallback, geringere Konfidenz oder – nur bei Pflichtfeldern – Ausschluss sicherer als eine Null. Die Missing-Data-Regel gehört zur versionierten Ranking-Policy.

Welche geografischen Signale sollte das Ranking verwenden?

Ein Ort besitzt keinen universellen Rang. Luftlinie ist eine günstige Näherung, wenn das Verkehrsnetz unwichtig ist. Reisezeit beschreibt Bequemlichkeit für Termine, Filialbesuche, Hotels und Pendelwege besser. Routenumweg passt zu Roadtrips, Lieferstopps und Serviceeinsätzen; added_time und added_distance von Mapbox zeigen diese Produktform (Search Box API). Containment prüft Servicegebiet, Schulbezirk oder Veranstaltungsfläche. Multi-Anchor-Fit bewertet einen Ort relativ zu mehreren Zielen, etwa ein Hotel zu Flughafen, Konferenz und Büro.

Eine Multi-Anchor-Regel kann Reisezeiten mitteln, die schlechteste Strecke minimieren oder für jeden Anker einen Grenzwert verlangen und dann nach Preis ordnen. Aus demselben Feature-Vektor entstehen unterschiedliche Gewinner. Funktion und sichtbare Karten-/Listenreihenfolge müssen deshalb zur Kundenentscheidung und zur gleichen Policy-Version passen.

Wie sollte Kundenabsicht in das Ranking einfließen?

Natürliche Anfragen verbinden oft Pflichtbedingungen und Wünsche. „Finde ein ruhiges Café nahe der Konferenz, das auf dem Weg zum Flughafen liegt“ enthält Typ, implizites Zeitfenster, Eignung für Gespräche, Nähe zu einem Anker und eine Routenbedingung. Die strukturierte Interpretation hält Pflichtfelder von Präferenzen getrennt. Das Sprachmodell interpretiert, das Ortssystem löst Kandidaten auf, der Routingdienst berechnet Beziehungen, und der Ranker kombiniert geprüfte Signale.

Das Intent-Modell darf keine Faktenquelle sein. Eine generierte Behauptung über Öffnung, Lagerbestand, Zimmerverfügbarkeit oder elf Minuten Umweg ist nur dann ein Feature, wenn ein freigegebenes System den Wert geliefert hat. Die OWASP Top 10 for LLM Applications 2025 nennt dies unter LLM06:2025 Excessive Agency. Wie beim kartenfähigen Assistenten schlägt das Modell strukturierte Anforderungen vor; deterministischer Code kombiniert autorisierte Merkmale, und der Host validiert Kartenaktionen.

Personalisierung darf erklärte Wünsche wie Gehen, Parken, ruhige Umgebung, gespeicherte Kategorien oder bevorzugte Viertel verwenden. Kunden müssen sie ändern, zurücksetzen oder ignorieren können. Sensible Eigenschaften dürfen nicht ohne legitime Grundlage abgeleitet werden; wenn abgeleitete Merkmale genügen, sollten keine sensiblen Rohdaten protokolliert werden. Das NIST Privacy Framework behandelt Datenschutz als Unternehmensrisiko. Private Standortdaten in KI-Kartenworkflows beschreibt dieselbe Grenze zum Hostkatalog.

Wie sollten Ranking-Merkmale kombiniert und erklärt werden?

Ein Merkmal muss für die Aufgabe sinnvoll, verfügbar, aktuell genug, korrekt normalisiert, zulässig und testbar sein. Meter, Bewertungen, Währungen und Präferenzwerte lassen sich nicht roh addieren. Jedes Signal wird in einen vergleichbaren Fit-Wert überführt; die Normalisierung ist Produktpolitik. Eine transparente gewichtete Summe aus Reise-, Intent-, Aktualitäts- und Geschäfts-Fit ist als erste Version oft besser prüfbar als ein gelerntes Modell. Gewichte sind Richtlinie, kein Beweis.

Veröffentlichen Sie nicht den internen Score 87.4, sondern nachvollziehbare Gründe: zwölf Minuten zu Fuß, im gewünschten Zeitraum geöffnet, benötigter Service, ausgewählte Präferenz. Geschäftsprioritäten können die Reihenfolge ändern, sollten aber von geografischer Relevanz trennbar bleiben. Kommerzielle Platzierungen unterliegen gegebenenfalls Offenlegungspflichten.

Aktualität ist zentral, weil Öffnungszeiten, Bestand, Veranstaltungsräume und Verfügbarkeit veralten. Kritische alte Fakten werden neu geprüft oder ausgeschlossen. Popularität ist eine Rückkopplungsschleife und sollte bewusst eingesetzt werden. Vielfalt und geografische Abdeckung können in einem zweiten Schritt helfen, wenn fünf fast identische Filialen oder ein enger Kartencluster die Anfrage nicht gut bedienen.

Wie unterscheidet sich Anbieter-Ranking von Produkt-Ranking?

Ein Ranker kann keinen Ort zurückholen, den Retrieval nie geliefert hat. Messen Sie Kandidatenabdeckung getrennt von Ranking-Qualität. rankPreference bei Google und rank_strategy, Proximity- sowie Routenfelder bei Mapbox ordnen den jeweiligen Anbieterindex (Nearby Search (New), Text Search (New), Search Box API). Der Host kann eine begrenzte Menge mit Bestand und Eignung anreichern, Routen berechnen und für die Produktaufgabe neu ordnen.

Bewertet wird place unter Nutzerkontext, Aufgabenkontext und aktuellem Zustand – nicht abstrakt. Vor-Ranking, Ranking und Re-Ranking konzentrieren teure Merkmale dort, wo sie die Entscheidung verändern.

Wie sollte eine Ranking-Anfrage authentifiziert und aufgebaut sein?

Eine architektonische Anfrage kann Aufgabe, Ursprung, Kandidaten-IDs, harte Anforderungen, Präferenzen und Ergebnislimit enthalten. Die Antwort liefert geordnete placeId-Werte und prüfbare Gründe. Das ist ein Designbeispiel, keine dokumentierte Kaleidr-Route. Übermitteln Sie Kandidaten-IDs und reichern Sie sie im autorisierten Backend an, statt private Datensätze aus dem Browser zu senden. Der Nutzer authentifiziert sich beim Host; dieser lädt erlaubte Kandidaten, und das Ranking läuft nur darauf.

Kaleidr nutzt Publishable Keys im Browser und Server Keys für vertrauenswürdige Backend-Vorgänge (Auth & Scopes). Publishable Keys werden gegen eine kurzlebige, an den Ursprung gebundene Session getauscht; Server Keys bleiben im Backend. Private Bestände, Ticketstatus und Ranking-Zugangsdaten gehören nicht in den Seitenquelltext. Reisezeit- oder Matrixabfragen sollten gebündelt werden, wenn der Routinganbieter das unterstützt.

Wie positioniert Kaleidr Ranking derzeit?

Kaleidr Enterprise beschreibt die Plattform derzeit als Location-Intelligence-Infrastruktur mit Inference APIs, Ranking-Systemen und Analytics für moderne räumliche Produkte (Location Intelligence APIs and Map SDK). Die Anbieterseite ist maßgeblich für Kaleidrs Positionierung, ersetzt aber nicht die aktuelle Endpunktliste.

Die öffentliche Platform-API-Referenz dokumentiert Chat-, Routen-, POI-Anreicherungs- und Designrouten unter https://api.kaleidr.com/inference-api/b2b/v1/, darunter POST /chat/control/stream, POST /chat/control/route, GET /retrieval/poi/enrich und Design-Endpunkte im Scope design (Endpoints). Eine eigene öffentliche /rank-Route ist nicht dokumentiert. Kundenspezifisches Ranking ist daher als Enterprise-Integrationsanforderung zu behandeln; POST /rank darf nur bei entsprechendem Deployment-Vertrag implementiert werden.

Öffentliche Inference-Schnittstellen können Intent, Routen und POI-Anreicherung beitragen, sind aber kein eigenständiger Ranker. Kaleidr Enterprise bleibt die Oberfläche für organisationsweite räumliche Inferenz, Verträge und Deployment-Support (Location Intelligence APIs and Map SDK).

Wie sollte die Qualität des Place Rankings bewertet werden?

Offline braucht es einen eingefrorenen Aufgabensatz aus Anfrage, Ursprung, harten Regeln und bevorzugten Signalen. Messen Sie Kandidaten-Recall, Eignungsgenauigkeit, Top-K-Qualität, Regelerfüllung, Korrektheit der Begründungen und geografische Verzerrung. Paarweise Labels – „Soll A für diese Aufgabe vor B stehen?“ – sind häufig leichter als ein perfekter absoluter Score und bleiben für spätere gelernte Modelle nützlich. Ein Spitzenergebnis, das eine Pflichtbedingung verletzt, ist auch bei hoher Klickrate ein Fehler.

Online zählen Auswahl, geöffnete Route, gestartete Buchung oder Abholung, gespeicherter Eintrag, Anfrage oder erneute Suche. Klicks sind positionsverzerrt. Diagnosen wie kein Ergebnis, Regelverstoß, veraltete Daten, Latenz pro Stufe und fehlende Pflichtmerkmale müssen sichtbar bleiben. Ergebnisse fließen in eine versionierte Policy mit Rollback ein. Auch der Leitfaden zu KPIs für Spatial Analytics priorisiert Aufgabenerfüllung vor bloßer Interaktion.

Frischetests gehören dazu: eine vor 20 Minuten geschlossene Filiale, ein deaktivierter Eingang, ein inaktiver Eintrag oder ausverkaufter Bestand darf nicht wegen gestriger Beliebtheit oben bleiben.

Mit welchen Fehlermustern sollten Produktteams rechnen?

Mobile Erlebnisse brauchen große Ziele, lesbare Gründe und eine nutzbare Karte auch bei Timeouts. Direktsuche muss weiterhin funktionieren. Basisgeometrie und Labels lassen sich cachen, Anreicherung kontrolliert reduzieren. Mehrdeutige Namen, vertauschte Ursprünge, geschlossene Orte und alte Bestände sollten getestet werden, bis Karte, Liste und Gründe gemeinsam aktualisieren.

Eine Place-Ranking-API in Ihr Produkt integrieren

Das Produktionsmuster lautet: abrufen, autorisieren, harte Regeln filtern, räumliche Merkmale berechnen, ordnen, erklären und messen. Distanz, Beliebtheit und semantische Relevanz können nützlich sein, sind aber nie universell richtig. Die Policy muss die Kundenentscheidung abbilden und auf der Karte nachvollziehbare Gründe zeigen.

Kaleidr Enterprise entdecken, um Location-Intelligence-APIs, Ranking-Systeme und Deployment-Support zu besprechen. Prüfen Sie vor der Festlegung eines Integrationspfads die aktuellen Inference-, Retrieval-, Auth- und SDK-Oberflächen in der Kaleidr-Entwicklerdokumentation.

Häufig gestellte Fragen

Was ist eine Place-Ranking-API?

Sie ordnet Kandidatenstandorte für eine bestimmte Aufgabe anhand geografischer, geschäftlicher und kundenspezifischer Signale, nachdem harte Eignungsregeln angewendet wurden.

Ist Place Ranking dasselbe wie eine Suche nach dem nächsten Ort?

Nein. Die Nächstensuche sortiert primär nach Distanz; Place Ranking kann auch Reisezeit, Umweg, Verfügbarkeit, Eignung, Präferenzen, Aktualität und Geschäftsregeln einbeziehen.

Sollten nicht verfügbare Orte nur einen niedrigeren Score erhalten?

Ist Verfügbarkeit zwingend, müssen sie vor dem Ranking entfernt werden. Eine Strafe könnte dennoch von anderen Signalen überstimmt werden.

Was unterscheidet Retrieval und Ranking?

Retrieval findet Kandidaten; Ranking ordnet die gültigen Kandidaten. Ein nicht abgerufener relevanter Ort kann vom Ranker nicht zurückgewonnen werden.

Kann ein Produkt Anbieter-Ranking verwenden und danach neu ordnen?

Ja. Der Anbieter liefert Kandidaten nach Relevanz, Beliebtheit, Distanz, Nähe oder Route; die Anwendung reichert an, filtert und ordnet für ihre Geschäftsaufgabe neu.

Welches räumliche Signal sollte das Ranking verwenden?

Das zur Entscheidung passende: Luftlinie für einfache Nähe, Reisezeit für reale Bequemlichkeit, Umweg entlang einer Route und Containment für Servicegebiete.

Was ist Multi-Anchor-Ranking?

Es bewertet einen Kandidaten relativ zu mehreren wichtigen Orten, etwa ein Hotel im Verhältnis zu Flughafen und Konferenzzentrum.

Sollte ein Sprachmodell den Ranking-Score berechnen?

Es kann natürliche Präferenzen interpretieren. Geprüfte Merkmale sollte deterministischer Code oder ein kontrolliertes Ranking-Modell kombinieren; Reisezeit, Bestand und Verfügbarkeit stammen aus maßgeblichen Systemen.

Wie sollte Place Ranking erklärt werden?

Mit kurzen Gründen aus realen Signalen – etwa Reisezeit, Abholverfügbarkeit oder Öffnung im gewünschten Fenster – statt mit einem rohen internen Score.

Wie sollte Place Ranking bewertet werden?

Mit Kandidaten-Recall, Erfüllung harter Regeln, Top-K-Qualität, Ranking-Metriken wie NDCG oder MRR bei geeigneten Labels und nachgelagerten Kundenergebnissen.

Hat Kaleidr einen öffentlichen Place-Ranking-Endpunkt?

Kaleidr Enterprise beschreibt Ranking-Systeme und Location-Intelligence-APIs für Ranking und Analyse. Die aktuelle öffentliche Platform-API-Referenz dokumentiert keinen eigenständigen /rank-Endpunkt. Bestätigen Sie die unterstützte Enterprise-Integration.

Referenzen

• Google Maps Platform. Nearby Search (New). Places API. Accessed 26 August 2026. https://developers.google.com/maps/documentation/places/web-service/nearby-search
• Google Maps Platform. Search along route. Places API. Accessed 26 August 2026. https://developers.google.com/maps/documentation/places/web-service/search-along-route
• Google Maps Platform. Text Search (New). Places API. Accessed 26 August 2026. https://developers.google.com/maps/documentation/places/web-service/text-search
• Kaleidr. Auth & Scopes. Kaleidr Developer Docs. Accessed 26 August 2026. https://docs.kaleidr.com/platform-api/auth-and-scopes
• Kaleidr. Endpoints. Kaleidr Developer Docs. Accessed 26 August 2026. https://docs.kaleidr.com/platform-api/endpoints
• Kaleidr. Location Intelligence APIs and Map SDK. Accessed 26 August 2026. https://kaleidr.com/enterprise
• Mapbox. Search Box API. Accessed 26 August 2026. https://docs.mapbox.com/api/search/search-box/
• National Institute of Standards and Technology. NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0. NIST.CSWP.01162020. 16 January 2020. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf
• OWASP Gen AI Security Project. OWASP Top 10 for LLM Applications 2025. Accessed 26 August 2026. https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf

@misc{google_nearby_search_2026_08_26,
  title  = {Nearby Search (New)},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 26 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/nearby-search}
}

@misc{google_search_along_route_2026_08_26,
  title  = {Search along route},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 26 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/search-along-route}
}

@misc{google_text_search_2026_08_26,
  title  = {Text Search (New)},
  author = {{Google Maps Platform}},
  note   = {Places API; accessed 26 August 2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/text-search}
}

@misc{kaleidr_auth_scopes_2026_08_26,
  title  = {Auth \& Scopes},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 26 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/auth-and-scopes}
}

@misc{kaleidr_endpoints_2026_08_26,
  title  = {Endpoints},
  author = {{Kaleidr}},
  note   = {Kaleidr Developer Docs; accessed 26 August 2026},
  url    = {https://docs.kaleidr.com/platform-api/endpoints}
}

@misc{kaleidr_enterprise_2026_08_26,
  title  = {Location Intelligence APIs and Map SDK},
  author = {{Kaleidr}},
  note   = {Accessed 26 August 2026},
  url    = {https://kaleidr.com/enterprise}
}

@misc{mapbox_search_box_2026_08_26,
  title  = {Search Box API},
  author = {{Mapbox}},
  note   = {Accessed 26 August 2026},
  url    = {https://docs.mapbox.com/api/search/search-box/}
}

@techreport{nist_privacy_framework_2020,
  title       = {NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0},
  author      = {{National Institute of Standards and Technology}},
  number      = {NIST.CSWP.01162020},
  institution = {National Institute of Standards and Technology},
  year        = {2020},
  month       = jan,
  url         = {https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf}
}

@misc{owasp_llm_top10_2025,
  title  = {OWASP Top 10 for LLM Applications 2025},
  author = {{OWASP Gen AI Security Project}},
  note   = {Accessed 26 August 2026},
  url    = {https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf}
}