Sync Open Location Hub docs into website

content/_index.md

@@ -5,7 +5,7 @@ hero_tagline: "Liberate your location data"
 hero_title: "Open source location infrastructure that is free to use, adapt, and white-label"
 hero_text: "Open Location Stack gives RTLS vendors, integrators, and solution providers a permissively licensed MIT foundation for interoperable location products. Open Location Hub is the centerpiece: an open hub for connecting mixed RTLS deployments and surfacing their location flows on one operational map."
 hero_aside_title: "Commercially usable by design"
-hero_aside_text: "The stack is intended to be free to use, adaptable to existing delivery models, and practical for embedded, branded, and customer-specific RTLS solutions."
+hero_aside_text: "The stack is free to use, adaptable to existing delivery models, and practical for embedded, branded, and customer-specific RTLS solutions."
 hero_highlights:
   - "Permissive MIT licensing"
   - "Business-friendly white labeling"
@@ -19,16 +19,16 @@ opensource_points:
     description: "Start from open hub, connector, and mapping building blocks instead of rebuilding the same infrastructure for every deployment."
   - title: "Credible shared foundation"
     description: "An open codebase makes it easier to evaluate, adapt, extend, and integrate the platform across mixed RTLS estates."
-opensource_license_note: "Open Location Stack is intended to be released under the permissive [MIT License](https://opensource.org/license/mit), making it practical to embed, adapt, extend, and white-label while still building on a shared ecosystem."
+opensource_license_note: "Open Location Stack is released under the permissive [MIT License](https://opensource.org/license/mit), making it practical to embed, adapt, extend, and white-label while still building on a shared ecosystem."
 opensource_repos:
   - title: "Floor Plan Editor"
     link: "/floor-plan-editor/"
     github_link: "https://github.com/Open-Location-Stack/floorplan-editor"
-    description: "Early access editor for creating and maintaining indoor floor plans and IMDF-based venue data. [Product page](/floor-plan-editor/) · [GitHub](https://github.com/Open-Location-Stack/floorplan-editor)"
+    description: "Open editor for creating and maintaining indoor floor plans and IMDF-based venue data. [Product page](/floor-plan-editor/) · [GitHub](https://github.com/Open-Location-Stack/floorplan-editor)"
   - title: "Open Location Hub"
     link: "/open-location-hub/"
     github_link: "https://github.com/Open-Location-Stack/open-location-hub"
-    description: "Early access interoperability hub for OMLOX-compatible position and event exchange. [Product page](/open-location-hub/) · [GitHub](https://github.com/Open-Location-Stack/open-location-hub)"
+    description: "Open interoperability hub for OMLOX-compatible position and event exchange. [Product page](/open-location-hub/) · [GitHub](https://github.com/Open-Location-Stack/open-location-hub)"
 mission_title: "Mission"
 mission_text: "Open Location Stack is an open source initiative focused on the missing shared layer between RTLS hardware, hubs, indoor maps, and downstream applications. Real-world deployments still rebuild the same venue models, connectors, hub adapters, and operational map capabilities vendor by vendor. We are building shared components so vendors and integrators can spend more effort on customer-facing products and less on proprietary plumbing. The project is initiated by [FORMATION](https://tryformation.com), where we build production RTLS solutions and encounter these integration gaps directly."
 problem_title: "Why Open Location Stack is needed"
@@ -46,11 +46,11 @@ hub_points:
   - title: "Reduce lock-in"
     description: "An open hub creates a cleaner way to work across vendor-specific deployments, custom APIs, and hybrid infrastructure."
   - title: "Connect mixed estates"
-    description: "The hub is intended to aggregate location flows from different plants, providers, and technologies instead of forcing a single-vendor stack."
+    description: "The hub aggregates location flows from different plants, providers, and technologies instead of forcing a single-vendor stack."
   - title: "Support product and integration teams"
     description: "Vendors, integrators, and enterprise teams get a reusable foundation for auth, event exchange, interoperability, and operational map integration."
 connectors_title: "Connectors turn existing RTLS deployments into an open ecosystem"
-connectors_intro: "Open Location Hub is intended to support a wide range of connectors so existing RTLS deployments and location technologies can participate without a rip-and-replace project."
+connectors_intro: "Open Location Hub supports a wide range of connectors so existing RTLS deployments and location technologies can participate without a rip-and-replace project."
 connectors_points:
   - title: "Connect existing hubs"
     description: "Plug in on-premise or cloud hubs such as Corriva Hub, Deephub, or other existing deployments where location data is already flowing."
@@ -72,12 +72,12 @@ mapping_points:
   - title: "Reusable map capabilities"
     description: "Semantic hierarchy and the location graph provide the foundation for reusable authoring, validation, rendering, and map maintenance instead of repeated project-specific work."
 ai_readiness_title: "AI readiness for agentic logistics and manufacturing"
-ai_readiness_intro: "Agentic logistics and manufacturing requires a fully integrated and accessible view of the workplace. Open Location Hub is intended to enable that by bringing together map context, live location flows, system events, and connector-based interoperability in one unified operational view."
+ai_readiness_intro: "Agentic logistics and manufacturing requires a fully integrated and accessible view of the workplace. Open Location Hub enables that by bringing together map context, live location flows, system events, and connector-based interoperability in one unified operational view."
 ai_readiness_points:
   - title: "Accessible operational context"
     description: "AI systems need a usable picture of facilities, fleets, flows, and constraints rather than disconnected location feeds."
   - title: "Integrated workplace visibility"
-    description: "Open Location Hub is intended to connect workplace systems, indoor maps, and mixed tracking technologies so automation has one unified operational view to act on."
+    description: "Open Location Hub connects workplace systems, indoor maps, and mixed tracking technologies so automation has one unified operational view to act on."
   - title: "Foundation for agentic workflows"
     description: "A shared hub, semantic map structure, and connector ecosystem create a better base for orchestration, monitoring, and AI-assisted decision making."
 roadmap:
@@ -128,7 +128,7 @@ component_groups:
         description: "Reusable integrations for RTLS hubs, hardware vendors, software systems, AGV environments, and enterprise workflows so each deployment does less bespoke integration work."
       - title: "MQTT Support"
         description: "Built-in [MQTT](https://mqtt.org/mqtt-specification/) connectivity for ingesting and distributing real-time updates around the operational map."
-components_note: "These components are available as early access versions and are not yet feature complete. Please try them out, share feedback, and help spread the word. Pull requests and issues are very welcome."
+components_note: "These components are being built in the open. Explore them, share feedback, and help spread the word. Pull requests and issues are very welcome."
 github_org_link: "https://github.com/Open-Location-Stack"
 audience_title: "Opening up the location ecosystem"
 audience_intro: "Open Location Stack aims to lower the cost of interoperability and raise the quality of map-aware RTLS products across the ecosystem by giving the market an open hub, open map foundation, and reusable connector model."

content/floor-plan-editor.md

@@ -23,7 +23,7 @@ It is part of Open Location Stack's mapping foundation and focuses on the practi
 
 Most RTLS and indoor-location projects still treat map authoring as a side problem, which usually leads to ad hoc tooling, brittle import flows, and inconsistent map quality.
 
-Floor Plan Editor is intended to reduce that friction by providing a reusable foundation for indoor map creation and maintenance. Instead of rebuilding a one-off editor for every deployment, teams can start with a focused tool that already understands the shape of the problem.
+Floor Plan Editor reduces that friction by providing a reusable foundation for indoor map creation and maintenance. Instead of rebuilding a one-off editor for every deployment, teams can start with a focused tool that already understands the shape of the problem.
 
 Just as importantly, it shifts teams away from bitmap-first indoor mapping. Static image floor plans may be workable for small demos, but they do not scale well to industrial campuses, terminals, hospitals, and factories that span tens or hundreds of thousands of square meters. Vector map data stays crisp at every zoom level, is easier to validate and edit, and provides the structure needed for downstream applications instead of just a picture of a building.
 
@@ -62,11 +62,9 @@ Floor Plan Editor gives Open Location Stack a practical authoring front end for
 
 For integrators, that means less time spent stitching together fragile map tooling. For product teams, it means a cleaner starting point for map-aware workflows such as wayfinding, zoning, asset visualization, and operational UX.
 
-## Early access
+## Get involved
 
-The project is still evolving quickly, and compatibility-breaking changes may still happen while the data model and workflows are being refined.
-
-That said, this is exactly the stage where outside feedback is useful. Try it, stress it, file issues, and send pull requests if you want to help shape the editor into a stronger shared foundation.
+Try it, stress it, file issues, and send pull requests if you want to help shape the editor into a stronger shared foundation.
 
 [Learn about Open Location Hub](/open-location-hub/)
 

content/open-location-hub.md → content/open-location-hub/_index.md

@@ -11,13 +11,15 @@ Open Location Hub is an OpenAPI-first hub implementation for interoperable RTLS
 
 It is the integration-layer counterpart to Open Location Stack's mapping work: once indoor spaces are modeled clearly, for example with the [Floor Plan Editor](/floor-plan-editor/), the hub becomes the place where live location data, events, security, connectors, and system-to-system interoperability come together.
 
-The current repository is still evolving quickly, but the intended direction is already clear: a production-grade, open source hub that teams can run, extend, adapt, and integrate without being locked into vendor-specific middleware.
+The project is moving toward a production-grade, open source hub that teams can run, extend, adapt, and integrate without being locked into vendor-specific middleware.
+
+The software documentation for the current implementation is published at [Open Location Hub Docs](/open-location-hub/docs/). That section is generated from the repository's `docs/` directory and is intended to stay aligned with the code as the project evolves.
 
 ## Business value
 
-Open Location Hub is intended to give vendors, integrators, and enterprise teams an open integration backbone they can actually use in commercial delivery models.
+Open Location Hub gives vendors, integrators, and enterprise teams an open integration backbone they can actually use in commercial delivery models.
 
-Because the project is part of Open Location Stack's MIT-licensed foundation, it is meant to be free to use, adapt, extend, embed, and white-label. That matters for companies that need a shared technical base without giving up their own service model, product packaging, deployment approach, or customer-specific integration layer.
+Because the project is part of Open Location Stack's MIT-licensed foundation, it is free to use, adapt, extend, embed, and white-label. That matters for companies that need a shared technical base without giving up their own service model, product packaging, deployment approach, or customer-specific integration layer.
 
 The point is not to replace all commercial offerings with a single open product. The point is to reduce repeated work in the non-differentiating layers so more effort can go into customer value, operational UX, deployment quality, and reusable partner ecosystems.
 
@@ -27,13 +29,13 @@ Many RTLS deployments end up depending on proprietary hub behavior, custom APIs,
 
 Open Location Hub exists to give the ecosystem a transparent, standards-oriented foundation. The goal is not just to expose an API, but to provide a credible base for secure, testable, deployable hub infrastructure that can participate in real deployments.
 
-It is also intended to be cloud-native, horizontally scalable, and lightweight enough to run in very different environments. You should be able to run it on premises close to local devices, in a regional cloud deployment, or as part of a larger multi-region setup that aggregates multiple sites and multiple continents. The federation work in the repository is explicitly aimed at supporting that progression from small local setups to larger distributed deployments.
+It is cloud-native, horizontally scalable, and lightweight enough to run in very different environments. Teams can run it on premises close to local devices, in a regional cloud deployment, or as part of a larger multi-region setup that aggregates multiple sites and multiple continents. The federation work in the repository supports that progression from small local setups to larger distributed deployments.
 
 ## Connectors for existing RTLS estates
 
-Open Location Hub is not intended as a rip-and-replace story. In many cases, the practical requirement is to work with the hubs and deployments that already exist across plants, warehouses, terminals, and production environments.
+Open Location Hub is not a rip-and-replace story. In many cases, the practical requirement is to work with the hubs and deployments that already exist across plants, warehouses, terminals, and production environments.
 
-That is why connectors are an important part of the product direction. The hub is intended to support integration with existing on-premise and cloud-based hubs such as Corriva Hub, Deephub, and other RTLS deployments already used for AGVs, fork lift trucks, and site-specific operational systems.
+That is why connectors are an important part of the product direction. The hub supports integration with existing on-premise and cloud-based hubs such as Corriva Hub, Deephub, and other RTLS deployments already used for AGVs, fork lift trucks, and site-specific operational systems.
 
 The business value is straightforward: instead of asking every customer to standardize on one vendor stack immediately, Open Location Hub can become the open layer that aggregates, normalizes, and routes location flows from multiple sources. That gives integrators and solution providers a practical path to interoperability while preserving existing investments.
 
@@ -53,7 +55,7 @@ For RTLS vendors and location solution providers, this also creates a partner op
 
 ## Technology overview
 
-The hub is written in Go, which is a strong fit for the intended deployment model: low footprint, high performance, simple operations, and a clean path to containerized or cloud-hosted runtime environments. The current architecture separates durable storage, transient state, protocol surfaces, and shared hub logic so the same core behavior can support multiple transports and deployment shapes.
+The hub is written in Go, which is a strong fit for the deployment model: low footprint, high performance, simple operations, and a clean path to containerized or cloud-hosted runtime environments. The current architecture separates durable storage, transient state, protocol surfaces, and shared hub logic so the same core behavior can support multiple transports and deployment shapes.
 
 At the API layer, the repository already shows a broad protocol surface:
 
@@ -66,7 +68,7 @@ That protocol mix matters because real RTLS deployments rarely have just one int
 
 ## Security and control plane
 
-The authentication model is standards-based JWT bearer auth with support for `oidc`, `static`, and `hybrid` verification modes. In OIDC mode, the hub discovers provider metadata and JWKS automatically, caches verifier state, and validates standard JWT claims. The repository includes a Dex setup for development, but the same model is intended to work with production OIDC providers such as Keycloak and other enterprise identity systems.
+The authentication model is standards-based JWT bearer auth with support for `oidc`, `static`, and `hybrid` verification modes. In OIDC mode, the hub discovers provider metadata and JWKS automatically, caches verifier state, and validates standard JWT claims. The repository includes a Dex setup for development, and the same model works with production OIDC providers such as Keycloak and other enterprise identity systems.
 
 Authorization is more than simple bearer validation. The hub already includes role-based and ownership-aware authorization, route-level permissions, RPC-specific method permissions, and separate WebSocket topic permissions. That makes it possible to use the hub as the policy boundary between user-facing applications and lower-level RTLS infrastructure.
 
@@ -84,16 +86,16 @@ In practical terms, the open location hub can sit above local hubs, beside exist
 
 ## Product pitch
 
-Open Location Hub is meant to be the open integration backbone of Open Location Stack: a hub that can sit between RTLS infrastructure, applications, enterprise systems, and federated site deployments while staying aligned with omlox-style interoperability.
+Open Location Hub is the open integration backbone of Open Location Stack: a hub that can sit between RTLS infrastructure, applications, enterprise systems, and federated site deployments while staying aligned with omlox-style interoperability.
 
 For integrators and vendors, that means a shared place to build the non-differentiating but critical parts of the stack: API contracts, auth, event exchange, deployment scaffolding, connectors, federation patterns, and operational discipline. For customers, it creates a better path toward portability, mixed-technology aggregation, and less dependence on closed middleware.
 
-## Early access
-
-This project is still early and not yet feature complete. It should be treated as an active implementation effort rather than a finished hub product.
+## Get involved
 
 If you care about interoperable RTLS infrastructure, now is the right time to get involved. Try the code, review the API direction, open issues, and contribute pull requests to help shape the implementation.
 
+[Browse the generated docs](/open-location-hub/docs/)
+
 [Learn about Floor Plan Editor](/floor-plan-editor/)
 
 [View the repository on GitHub](https://github.com/Open-Location-Stack/open-location-hub)

content/open-location-hub/docs/_index.md

@@ -0,0 +1,16 @@
+---
+title: "Software Documentation"
+description: "Use the documents in this directory for software behavior, runtime configuration, and integration guidance."
+draft: false
+generated: true
+generated_from: "docs/index.md"
+github_url: "https://github.com/Open-Location-Stack/open-location-hub/blob/main/docs/index.md"
+---
+_This page is generated from the Open Location Hub source documentation and should not be edited in the website repository._
+
+Use the documents in this directory for software behavior, runtime configuration, and integration guidance.
+
+- `architecture.md`: system structure, processing flows, and trust boundaries
+- `configuration.md`: environment variables and runtime tuning
+- `auth.md`: JWT auth modes, authorization model, and permission file behavior
+- `rpc.md`: REST-facing RPC usage and control-plane behavior