Product
Capabilities and product relationships can be documented publicly where appropriate.
PRODUCT KNOWLEDGE
Documentation without noise.
Start with the part of the system you work with. Public documentation explains the product; customer and operational material is distributed through controlled access.
PRODUCT KNOWLEDGE
Documentation
Start with the part of the system you work with. Public documentation explains the product; customer and operational material is distributed through controlled access.
01
PlatformThe product core and the relationship between PTT, Dispatch and operations.
→02DispatchOperational control, teams, devices and events.
→03GPS & statusLIVE, STALE and OFFLINE as location context.
→04AlertsPriority, acknowledgement and responsibility.
→05HardwareVerified devices and compatibility.
→06DeploymentCloud, Dedicated, On-Prem and OEM.
→07SafeDeviceControlled device operation.
→DOCUMENTATION MODEL
Documentation should follow how the product is used.
Public docs can explain concepts and workflows. Customer-specific operations, credentials and sensitive integration details belong behind controlled access.
Operations
Deployment, maintenance and customer runbooks may require access.
Release
Client/version documentation should tie back to a concrete release.
01Start with flow
Document from the user task rather than internal architecture.
02Show boundaries
Requirements, dependencies and known limitations should be visible.
03Version it
Client and integration changes should remain traceable over time.
04Control access
Sensitive or customer-specific material should not be public.
The docs index is structured now; the article library expands as verified product documentation is completed.