Enterprise spatial AI architecture separates language models, maps, business data, spatial calculations, permissions, tools, and actions so each job stays in the layer that can enforce it. A fluent answer can still send someone to the wrong branch. The host keeps identity and transactions. Spatial services calculate geography. The language model interprets the request and explains a result those systems already grounded.
The sections below cover ownership, authorization, credentials, tools, the request path, and three deployment patterns. Related reading includes Spatial AI Accuracy Evaluation and An Enterprise Spatial AI Pilot. A correct refusal can be a better result than a plausible recommendation that no system of record supports.
Enterprise spatial AI architecture essentials
- Separate the jobs: The language model interprets and explains. It does not own inventory, permissions, routes, or transactions.
- Authorize before retrieval: Resolve the user, tenant, objects, and fields before private context reaches the model.
- Keep facts typed: Stable IDs and operational fields stay structured. Prose does not replace them.
- Bound every tool: Read, map, draft, and write actions carry different approval rules.
- Measure the workflow: Watch the location decision and the host outcome, not only tokens and latency.
What Is Enterprise Spatial AI Architecture?
A customer can ask which service center can handle a job today, sits inside the contract area, and adds the least travel time from the current route. That sentence needs an intent layer, customer and contract records, facility data, service-area rules, a routing calculation, and a map workflow. A production system also needs identity, tenant isolation, tool limits, action checks, logs, and a place for a person to approve a high-impact step. Putting every one of those jobs inside one prompt makes the product hard to secure and hard to change. The model can name what should happen next. Enforcement stays outside the model.
The left side connects one model directly to databases, routing, and transactions. The right side keeps identity, data, spatial tools, ranking, and validated action in separate layers. The contrast is an architecture pattern, not a Kaleidr benchmark.
A practical path looks less like a user talking to a model that can reach everything, and more like a sequence the host can inspect. The application holds the user and the current map state. Identity and authorization resolve before retrieval. Intent interpretation then asks only for approved data and spatial calculations. Eligibility removes invalid options before ranking. A validated action updates the map or the workflow, and analytics records whether the job succeeded. That sequence lets a team change models, map providers, or ranking rules without rebuilding the product around one opaque dependency.
Which System Should Own Each Fact?
An architecture workshop should name the owner of each critical fact before anyone picks a model. The host identity provider owns the user. The host application owns tenant membership, product entitlement, the workflow, and the business outcome. Business systems own facility identity, inventory, availability, price, booking status, and policy. An approved location source owns coordinates. Spatial computation owns distance, travel time, and point-in-polygon. The client application owns the viewport and the selected place. The AI layer owns intent interpretation and an explanation written over grounded evidence. The host workflow owns the final transaction.
| Fact or decision | Authoritative owner |
|---|---|
| User identity and tenant | Host identity system |
| Inventory, price, booking, policy | Business system of record |
| Distance, travel time, containment | Spatial computation |
| Map viewport and selected place | Client application |
| Intent and explanation | AI layer, over grounded evidence |
| Final transaction | Host workflow |
Each column has one primary owner. The AI layer coordinates intent and explanation. Host and business systems remain the systems of record, and the board is a framework rather than a product inventory.
If a team cannot name the owner of a critical fact, an assistant usually hides the gap. Kaleidr's grounded Spatial AI guidance uses the same split: the model interprets compound intent, while inventory, policy, permissions, and routing stay with the systems built to hold those facts (Kaleidr, 2026). Retrieval finds context. Authority decides which source may answer a factual question. A retrieved document is not automatically the system of record.
Why Authorize Before Retrieval?
A common mistake retrieves private data, sends it to the model, and then asks the model which rows the person may see. Reverse that order. Authenticate the user, resolve the tenant, resolve roles and entitlements, authorize objects, minimize fields, retrieve the approved records, and only then pass the necessary context onward. The permission boundary should be deterministic and auditable. A language model should not choose whether a regional manager may see a facility, whether one customer may read another customer's location history, or whether an employee may retrieve restricted workplace data.
Private records cross the boundary only after tenant, role, object, and field checks. The lower path, which asks a model to infer permissions from a full database, stays blocked. Platform credentials and end-user authorization remain different checks.
A platform credential can show that an application may use a capability. That credential does not decide which end user may read which rows. CORS, credential authentication, API capability scopes, and application-level user authorization solve different problems, and mixing them produces the wrong failure (Kaleidr, 2026). The private-data path is therefore a stack of checks, not one token that means everything.
How Should Browser and Server Credentials Stay Apart?
A browser is inspectable, so anything shipped to it should be treated as visible to the person running it. A backend is the right place for long-lived secrets, private business-data access, policy enforcement, and server-to-server calls. The browser can hold a publishable, client-safe credential for a scoped map capability. Authenticated product requests go to the host backend, which applies the user context, reaches private data, and calls spatial or AI operations with a server credential. The two runtimes should not share one secret.
The browser side is built for exposure and stays limited to scoped client capabilities. The server side keeps the server credential, private records, and user authorization. The checkmarks are a boundary sketch, not a security certification.
Kaleidr's current key documentation defines a publishable key for browser use and a server key for backend integrations. The publishable key is origin-locked, and the SDK exchanges it for a short-lived session at runtime rather than using that string as a standing server bearer. The server key stays on trusted servers (Kaleidr, 2026). The same documentation set describes Chat, Editor, Tile, and Viewer as separate surfaces, with attach, embed, and tile doorways that do not all mount the same way (Kaleidr, 2026). Follow the current contract for each surface instead of assuming one credential and one mount cover the stack.
Where Should Business Facts and Geography Live?
Enterprise Spatial AI is useful when it can reason over facts a public model does not know: current inventory, partner eligibility, facility capability, contract coverage, temporary closures, and live availability. Those facts belong in systems of record. Do not ask a model to remember a value that can change this afternoon. Do not fine-tune a model on an operational field that a query can return. Do not paste a broad internal database into a system prompt. Interpret the request, decide which authorized records are required, retrieve the minimum set, keep stable IDs and typed fields, run hard filters, calculate geography, and only then explain the grounded result.
{
"branch_id": "b_1042",
"open_now": true,
"inventory_status": "in_stock",
"service_eligible": true,
"lat": 38.91,
"lng": -77.22
}
A typed record can be filtered, logged, checked for permission, and passed to a later action. A sentence that says a branch "appears open" and "probably" has the item cannot. Natural language still belongs in the explanation. It should not replace fields the application can store directly.
Spatial calculations deserve their own layer for the same reason. Point-in-polygon, route distance, drive time, walk time, service-area membership, route deviation, and reachable-within-time analysis should come from a geographic service when the product can compute them. The AI layer can determine that a calculation is required. The spatial service performs it. The explanation then says why that relationship matters to the request. Switching language models does not force the team to relearn how the application measures travel time or containment.
Hard constraints and soft preferences should stay apart. A clinic request might require an accepted plan, hours after 6 PM, an active location, and a record the user may access. Only the candidates that pass those rules should be ranked by drive time, route deviation, or a stated preference. The order is retrieval, authorization, eligibility, spatial calculation, ranking, and explanation. Ranking first, and hoping the model remembered every constraint, hides an invalid option inside a fluent shortlist. Retail, real estate, booking, workplaces, and multi-location networks can share that order because the constraint is about validity, not about industry vocabulary.
How Should Tools and Actions Be Bounded?
Agentic Spatial AI makes the tool catalog one of the important boundaries. Open tools such as an arbitrary SQL string, a shell command, or a free-form internal URL are an execution environment, not a business capability. Prefer narrow tools with known inputs and outputs: search eligible locations, calculate travel time, read branch availability, show places, request a route, or create a booking draft. Each tool can carry its own permission check, validation, rate limit, log line, and failure mode.
Read and map tools can run when the caller is already authorized. Drafts create a reviewable object. Writes that confirm a booking, dispatch work, or change a record wait for an explicit policy gate. The tiers are architectural guidance, not a fixed Kaleidr permission list.
Reading a record and changing business state are different risk classes. A production catalog can group capabilities into read, map, draft, and write. Read and low-impact map actions may run automatically once authorization has passed. A draft can prepare a booking or a service request for review. A write that confirms a reservation, dispatches a vehicle, or publishes a change may require confirmation, a second policy check, and sometimes a person. A confidence score is not a permission system.
OWASP's 2025 excessive-agency guidance treats excessive functionality, excessive permissions, and excessive autonomy as separate causes. It recommends limiting the extensions an agent may call to the minimum necessary, preferring granular functions over open-ended ones, requiring approval for high-impact actions, and enforcing authorization in downstream systems rather than relying on the model to allow the call (OWASP, 2025). The application should still validate every proposed call. For a map action, check that the action is allowed, that the place IDs belong to the authorized result set, that the user can access them, and that the arguments are well formed. For a write, apply a stricter check. A prompt, a retrieved document, or a malformed tool result must not become an authorization bypass.
OWASP's system-prompt guidance makes the same boundary from the other side. The system prompt is not a secret and is not a security control. Privilege separation and authorization checks must not be delegated to the model, through the prompt or otherwise (OWASP, 2025). Map actions should use a semantic vocabulary, such as show places, fit places, select a place, draw a route, or clear a route, and a deterministic adapter should translate those actions for Mapbox, MapLibre, Google Maps, or another renderer. The model should not emit renderer code on each turn.
How Should the Map State Enter the Request?
Map state changes what a person means by "these," "north of here," or "the second option." A useful snapshot can include viewport bounds, the selected place ID, visible result IDs, active filters, a current route ID, and an approved location at the precision the job needs. Mark which fields are always available, optional, private, user-approved, stale, authoritative, or inferred. Do not send precise device location into every request merely because the map can read it. The strongest reference for "which of these is open later" is the stable IDs of the current result set, not a screenshot. Kaleidr's map-aware assistant guidance draws that line: share viewport, selection, filters, and result IDs, and do not ask the model to infer the application from pixels (Kaleidr, 2026).
An orchestration layer can choose whether the request needs business retrieval, routing, a map action, a clarifying question, or a summary of the evidence. That layer can be model-driven, rules-driven, or a mix. It should not be the only security boundary. Orchestration may ask whether to call availability. Authorization answers whether this caller may retrieve availability for these records. Orchestration may ask whether to start a booking. The transaction layer answers whether the person confirmed and whether the operation is valid. The split survives a model error.
Tenant isolation belongs on the same path. Resolve authenticated identity, tenant, role, and permitted objects before the query, and scope the query to that tenant. Do not rely on a prompt that says the model was told not to mention other tenants. The model should never receive another tenant's data unless the application has an explicit cross-tenant purpose and policy. Tenant-scoped queries, object checks, field minimization, and redacted logs are the controls. A sentence in the prompt is not one of them.
How Does a Production Request Move Through the Stack?
A full request can be drawn as twelve stages, and not every request needs all of them. Capture the authenticated user, the tenant, the map state, and the workflow state. Interpret the job, the geographic constraints, the business constraints, and the intended action. Resolve allowed sources, records, fields, tools, and actions before any private retrieval.
Retrieve authorized facts and canonical place IDs, then calculate distance, travel time, containment, or service-area membership. Remove unauthorized, unavailable, closed, or out-of-area candidates, and rank what remains. Explain the grounded result, propose a semantic map or workflow action, and validate that action outside the model. Execute the action, then record the decision and the outcome.
The stages run from map state and intent through authorization, grounding, geography, eligibility, and ranking, then explanation, a proposed action, validation, execution, and measurement. A simple "show this place" request can skip retrieval and ranking. A service recommendation may use nearly the whole path.
Failure behavior is part of the same path. If business data is unavailable, do not fabricate availability. Say that availability cannot currently be verified. If routing is down, do not claim a travel-time ranking, and label any straight-line fallback as a fallback. If no candidate passes the hard rules, return no result instead of relaxing a critical constraint in silence. If authorization fails, do not ask the model to explain private information it was never given. If the model is unavailable, deterministic search and filters can still serve the map. If a tool result is malformed, reject it at validation. When a product has no explicit degraded mode, the language model becomes the accidental fallback for missing infrastructure.
Human approval follows impact, not a single rule for every button. Showing three public places is low impact. Confirming an appointment, dispatching a vehicle, changing a facility record, or submitting a paid booking is not. Classify search, retrieval, and route preview as low impact. Classify a saved preference or a draft as medium impact. Classify a purchase, a dispatch, an operational write, or a permission change as high impact. Automatic execution, user confirmation, and a separate approval can then match the class. NIST's AI Risk Management Framework is voluntary, and it is meant to bring trustworthiness into the design, development, use, and evaluation of AI products. The same NIST page states that AI RMF 1.0 is being revised (NIST, 2023). The framework is context for the product's own risk decisions, and the framework is not a Kaleidr control list.
Where Does the Control Plane Sit?
The request path handles live work: user, authorization, retrieval, spatial tools, model, action, and response. The control plane decides how that path is allowed to run. Credentials, scopes, model choice, prompts, tool policies, data-source configuration, rate limits, environments, evaluation suites, feature flags, and audit settings live there. Separating the two lets a team change policy without rewriting every conversational flow. Disabling a write tool should not require a new interface. The control plane is an architecture pattern for those settings, and the diagram is not a claim that one product ships every box.
The upper row holds configuration: credentials, scopes, models, prompts, tool policies, data sources, limits, evaluation, flags, and audit settings. The lower row is the live request. Policy points into the stages it governs, so a team can change a rule without rewriting the path.
Observability should follow the decision, not only the token bill. Useful events include intent resolved, authorization passed or denied, retrieval completed, candidates removed by eligibility, spatial calculation completed, ranking completed, a no-result response, a tool proposed, a tool rejected, a map action executed, a place selected, and a workflow completed. Those names are a pattern to design, not a list a platform emits automatically. The questions they answer are practical. Are errors coming from place resolution or from ranking? Are people rejecting a valid shortlist? Is one market producing more empty results? Are tool calls failing on permissions or on malformed arguments? Did the person finish the host task after selecting a place? NIST's AI RMF core says that test sets, metrics, and details about the tools used during test, evaluation, verification, and validation are documented (NIST, 2023). For Spatial AI, the documented tests should cover the geographic and business decision, not only the generated sentence.
Spatial analytics and host outcomes answer different questions, and the architecture should join them with stable IDs. Kaleidr Analytics currently describes dashboards for reach, views, and engagement, audience location and activity, sessions, views, and interactions per map, and spatial patterns (Kaleidr, 2026). Bookings, purchases, qualified leads, dispatches, and completed services stay in the host systems that own them. A recommendation ID can point at a selected place ID, then at a host workflow ID, then at the outcome. Public analytics material does not say that every business conversion is captured automatically.
What Are the Three Deployment Patterns?
Three patterns cover most enterprise deployments, and none of them is universally best. A public map assistant fits tourism, discovery, editorial maps, and event exploration. The browser map uses a publishable client capability, map-aware AI, public or approved place data, and spatial tools, then returns a map action. The data boundary is simpler because the workflow is mostly public. An authenticated business assistant fits customer portals, inventory-aware store selection, real estate, partner networks, and private facilities. The browser reaches a host login and a host backend, which applies tenant and object authorization before private data, spatial tools, and the explanation return to the map. A spatial agent with business actions fits booking, dispatch, and operational workflows. The path adds a typed tool proposal, deterministic validation, confirmation where the impact requires it, the transaction system, and an audit of the outcome. That third pattern changes business state, so it carries the strictest governance.
The public pattern stays on approved public places. The authenticated pattern keeps private records behind the host. The action pattern adds validation and confirmation before a transaction. Sample place cards on the figure are illustrative, not measured Kaleidr results.
Where Does Kaleidr Fit in This Architecture?
Kaleidr currently describes Enterprise as location-intelligence infrastructure for product teams, with inference APIs, ranking, analytics, and SDK surfaces a host can add (Kaleidr, 2026). The developer documentation lists four surfaces in one SDK. Chat attaches AI interaction to a map the host already runs. Editor mounts map editing inside a product. Tile serves a designed basemap. Viewer publishes a map for embedding. Current Chat documentation lists Mapbox, MapLibre, and Google Maps as integration paths for that host-owned map (Kaleidr, 2026). The host keeps end users, authentication, tenant authorization, private business systems, workflow rules, transactions, and business outcomes. Kaleidr adds selected spatial surfaces and does not replace the systems that remain authoritative in the host stack.
The host row keeps users, tenant authorization, workflows, private systems, transactions, and outcomes. Chat, Editor, Tile, and Viewer sit beside platform APIs and Analytics. Credential labels follow the public browser and server split, and the figure does not show a live secret.
Which Mistakes Hide Until Production?
Connecting the model directly to every system creates excessive privilege and makes the failing layer hard to find. Treating a prompt as the authorization layer fails for the same reason: a prompt can guide wording, and it cannot deterministically allow or deny a record. Sending the whole internal database into context violates minimization. Mixing hard filters with ranking lets an ineligible place survive inside an average. Asking the model to estimate a distance the spatial service can compute substitutes fluency for a calculation. One unrestricted tool, or a write tool that inherits a read tool's policy, gives a recommendation the authority of a transaction. Treating the map as a picture drops the stable IDs the next turn needs. Monitoring only latency and token cost misses place resolution, eligibility, routing, ranking, tool failures, and the host outcome. A model benchmark, on its own, cannot say the assembled workflow is ready.
NIST's initial public draft of the TEVV-Athlon framework, NIST AI 200-2, announced on August 7, 2026 with comments open through October 6, 2026, describes evaluation as evidence that a system meets individual or organizational goals, with measurement adapted to the application and its real-world impact, including agentic systems (NIST, 2026). The document is a draft seeking input. The draft is not a Kaleidr control list. For this architecture, the evaluation context is the location-dependent decision: intent, authorization, grounding, geography, eligibility, ranking, tools, actions, failure handling, and the host outcome.
How Does Enterprise Spatial AI Architecture Become a Release Gate?
Before a pilot moves toward production, confirm the owners. The user is authenticated where the workflow requires it, and tenant membership is resolved outside the model. Every critical field has an authoritative source, private retrieval happens before inference, fields are minimized, and stable IDs survive the handoff. Geographic services perform the calculations the product claims, and the tolerances used in evaluation are written down. Tools are narrow, read and write are separated, arguments are validated, and high-impact actions can be confirmed and audited. Browser and server credentials stay apart, scopes stay limited, and environments stay separate. The team can see the decision chain and can join a place selection to a host outcome. Unavailable data, empty candidate sets, and degraded modes are explicit, and critical operations fail closed instead of inventing a fact. Explore Kaleidr Enterprise for spatial intelligence APIs, ranking, analytics, and SDK surfaces beside the stack a product already runs. Read the Kaleidr developer docs for the current Chat, Editor, Tile, Viewer, key, and scope contracts before implementation.
FAQs
What is enterprise spatial AI architecture?
Enterprise spatial AI architecture is the system design that connects language models, maps, geographic services, business data, permissions, tools, actions, and analytics, and keeps each responsibility in the layer that can enforce it.
Should a language model have direct access to a business database?
Usually not as an unrestricted interface. Authorize the current user, retrieve the minimum records the task needs, keep fields structured, and expose narrow tools. Open-ended database access makes the model the permission engine.
What should the language model own?
The model fits natural-language intent, orchestration among approved capabilities, and explanation of a grounded result. Authorization, transactions, business truth, and geographic calculations stay in the systems designed for those jobs.
What is the difference between platform authentication and user authorization?
Platform authentication establishes that an application may use a platform capability. User authorization decides which person or tenant may access a record or run a business action. One check does not substitute for the other.
Should Spatial AI use retrieval-augmented generation?
Retrieval can supply relevant documents or records. Retrieval alone does not establish authority. Inventory, availability, price, permissions, and service-area membership should stay tied to their systems of record and to deterministic rules.
How should Spatial AI tools be secured?
Use narrow functions, minimum permissions, authorization in the user's context, argument validation, rate limits, monitoring, and an independent approval for high-impact actions. Do not treat the model or the system prompt as the authorization mechanism.
Should Spatial AI actions require human approval?
Approval follows impact. Low-risk map actions, such as displaying places, may run automatically. Purchases, bookings, dispatches, administrative writes, and permission changes may require explicit confirmation or a separate approval.
How should a map assistant use the current map?
Pass structured state such as viewport bounds, selected place IDs, active filters, visible result IDs, route IDs, and a location at the precision the job needs. Do not require the model to infer application state from a screenshot when structured state exists.
Can Spatial AI work with an existing map?
Yes. A Spatial AI layer can attach to a map and application the host already runs. Kaleidr's current Chat documentation describes attaching conversational Spatial AI to host-run Mapbox, MapLibre, or Google Maps instances.
How should a team evaluate the architecture before scaling?
Evaluate the assembled workflow: intent, authorization, grounding, geographic calculations, eligibility, ranking, explanation, tools, actions, failure handling, and business outcomes. A general language-model benchmark does not replace that test.
References
- Kaleidr. Grounded Spatial AI for Business Data. https://kaleidr.com/blog/grounded-spatial-ai-business-data
- Kaleidr. Map API Authentication. https://kaleidr.com/blog/map-api-authentication
- Kaleidr. Get an API Key. Publishable browser keys and server keys. Accessed September 30, 2026. https://docs.kaleidr.com/get-an-api-key
- Kaleidr. Introduction. Chat, Editor, Tile, and Viewer in one SDK. Accessed September 30, 2026. https://docs.kaleidr.com/
- OWASP Gen AI Security Project. LLM06:2025 Excessive Agency. Accessed September 30, 2026. https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
- OWASP Gen AI Security Project. LLM07:2025 System Prompt Leakage. Accessed September 30, 2026. https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/
- Kaleidr. How to Build a Map-Aware AI Assistant. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant
- National Institute of Standards and Technology. AI Risk Management Framework. Voluntary framework for trustworthiness in design, development, use, and evaluation. Released January 26, 2023. Page states that AI RMF 1.0 is being revised. Accessed September 30, 2026. https://www.nist.gov/itl/ai-risk-management-framework
- National Institute of Standards and Technology. AI RMF Core. Measure 2.1: test sets, metrics, and details about the tools used during TEVV are documented. Accessed September 30, 2026. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/
- Kaleidr. Map Engagement and Location Analytics. Accessed September 30, 2026. https://kaleidr.com/analytics
- Kaleidr. Location Intelligence APIs and Map SDK. Accessed September 30, 2026. https://kaleidr.com/enterprise
- Kaleidr. Chat. Attach AI to a host-run Mapbox, MapLibre, or Google Maps instance. Accessed September 30, 2026. https://docs.kaleidr.com/chat
- National Institute of Standards and Technology. The TEVV-Athlon Framework for Evaluating AI Systems. NIST AI 200-2, initial public draft. Announced August 7, 2026; comments through October 6, 2026. https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems
- Kaleidr. Spatial AI Accuracy Evaluation. https://kaleidr.com/blog/spatial-ai-accuracy-evaluation
- Kaleidr. An Enterprise Spatial AI Pilot Before Scaling. https://kaleidr.com/blog/enterprise-spatial-ai-pilot-before-scaling
@misc{kaleidr_grounded_architecture_2026,
title = {Grounded Spatial AI for Business Data},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/grounded-spatial-ai-business-data}
}
@misc{kaleidr_map_api_auth_2026,
title = {Map API Authentication},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/map-api-authentication}
}
@misc{kaleidr_get_api_key_2026,
title = {Get an API Key},
author = {{Kaleidr}},
year = {2026},
note = {Accessed September 30, 2026},
url = {https://docs.kaleidr.com/get-an-api-key}
}
@misc{kaleidr_docs_intro_2026,
title = {Introduction},
author = {{Kaleidr}},
year = {2026},
note = {Accessed September 30, 2026. Chat, Editor, Tile, and Viewer},
url = {https://docs.kaleidr.com/}
}
@misc{owasp_llm06_2025,
title = {LLM06:2025 Excessive Agency},
author = {{OWASP Gen AI Security Project}},
year = {2025},
note = {Accessed September 30, 2026},
url = {https://genai.owasp.org/llmrisk/llm062025-excessive-agency/}
}
@misc{owasp_llm07_2025,
title = {LLM07:2025 System Prompt Leakage},
author = {{OWASP Gen AI Security Project}},
year = {2025},
note = {Accessed September 30, 2026},
url = {https://genai.owasp.org/llmrisk/llm072025-system-prompt-leakage/}
}
@misc{kaleidr_map_aware_2026,
title = {How to Build a Map-Aware AI Assistant},
author = {{Kaleidr}},
year = {2026},
url = {https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant}
}
@misc{nist_ai_rmf_2023,
title = {AI Risk Management Framework},
author = {{National Institute of Standards and Technology}},
year = {2023},
note = {Released January 26, 2023. Accessed September 30, 2026. Page states AI RMF 1.0 is being revised},
url = {https://www.nist.gov/itl/ai-risk-management-framework}
}
@misc{nist_ai_rmf_core_2023,
title = {AI RMF Core},
author = {{National Institute of Standards and Technology}},
year = {2023},
note = {Measure 2.1. Accessed September 30, 2026},
url = {https://airc.nist.gov/airmf-resources/airmf/5-sec-core/}
}
@misc{kaleidr_analytics_architecture_2026,
title = {Map Engagement and Location Analytics},
author = {{Kaleidr}},
year = {2026},
note = {Accessed September 30, 2026},
url = {https://kaleidr.com/analytics}
}
@misc{kaleidr_enterprise_architecture_2026,
title = {Location Intelligence APIs and Map SDK},
author = {{Kaleidr}},
year = {2026},
note = {Accessed September 30, 2026},
url = {https://kaleidr.com/enterprise}
}
@misc{kaleidr_chat_docs_2026,
title = {Chat},
author = {{Kaleidr}},
year = {2026},
note = {Accessed September 30, 2026},
url = {https://docs.kaleidr.com/chat}
}
@techreport{nist_ai_200_2_2026,
title = {The TEVV-Athlon Framework for Evaluating AI Systems},
author = {{National Institute of Standards and Technology}},
institution = {National Institute of Standards and Technology},
number = {NIST AI 200-2},
year = {2026},
note = {Initial public draft, announced August 7, 2026},
url = {https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems}
}