Capabilities
Everything it does. And everything it doesn’t.
One table, every discipline, with the standard named on each row. The blanks are published with the same weight as the ticks — a capability list you cannot check is a brochure, and this one is meant to be checked.
What is in this table
- 111 capabilities
- across 11 disciplines
- 86 shipped
- built, wired, reachable in the product
- 9 partial
- real but bounded — the bound is on the row
- 16 not available
- published deliberately
- Machine-readable
- /capabilities.json, same source
Verified against the product source, then adversarially reviewed.
The matrix
Shipped means built, wired and reachable — not planned, and not present in code that nothing calls. Partial means real but bounded, with the bound stated. Not available means exactly that, and there are 16 of them below.
Building model
| Capability | Status | Standards |
|---|---|---|
| Multi-floor facility model with GPS floor-plan anchoring Ordinal/cross-floor plane has open internal caveats; GPS anchoring verified at data-model level. | Shipped | — |
| Wall modeling with per-material RF/physics profile Same wall/material data feeds Wi-Fi attenuation; does not drive camera occlusion (see Cameras: glass). | Shipped | NIST IR 6055 |
| AI-assisted wall/door/window detection (human confirm-first) AI proposes; technician confirms before it becomes canonical. | Shipped | — |
| Canonical door object model (handing, fire/smoke rating, ADA flag, hardware) Backs both the access-control and life-safety/compliance surfaces. | Shipped | ADA |
| Ceiling type rendering (six types, 2D + 3D) | Shipped | — |
| Shared occlusion/obstacle engine (walls, racking, ceilings) One engine feeds both the interactive canvas and every export, by construction, for camera line-of-sight and coverage heatmaps. | Shipped | — |
Network
| Capability | Status | Standards |
|---|---|---|
| Network topology derivation (5 tiers: WAN/perimeter/core/distribution/access) Pure function derived from the placed design; same design always produces the same topology. | Shipped | — |
| MDF/IDF closet modeling | Shipped | — |
| Rack elevations (2D/3D design-time, BICSI-ordered, per-suggestion standard references) + as-built export + rack-unit assignment | Shipped | BICSI TDMM |
| Switch-port assignment/planning | Shipped | BICSI · TIA-606 |
| Patch-panel assignment (device→panel→switch, both sides tracked) | Shipped | — |
| VLAN groupings Suggestion-only; the platform never pushes network configuration. | Shipped | — |
| HA/stacking interconnect classification Per-zone Wi-Fi redundancy is live; the broader HA/stacking program is mid-flight with later slices still open. | Partial | — |
| Network topology diagram export The interactive topology view and an as-built topology section exist; a dedicated exportable topology diagram (PDF/PNG) does not. | Not available | — |
Cabling & fiber
| Capability | Status | Standards |
|---|---|---|
| Copper category validation (Cat5e–Cat8) Full distance/bend-radius/PoE-support validation exists for all categories; the survey's cable-path drawing tool only places Cat6/6a/7 runs. | Partial | ANSI/TIA-568 |
| Fiber type registry (OM1–OM5, OS1/OS2) + backbone planning (strand counts, TIA-598 color reference) A more granular strand-by-strand allocator exists in code but is not wired to any customer-facing surface — only strand counts are marketed. | Shipped | TIA-598 |
| Cable-path routing & optimization incl. pull-tension modeling Manual routing tool plus an opt-in ILP solver that models capstan pull tension and splits runs at bend/tension/length limits. | Shipped | — |
| Calculated cable lengths incl. service loop, within-floor riser Validated against copper/fiber distance limits. | Shipped | TIA-568 |
| Cross-floor vertical cable-length automation Floor-to-floor height is captured but not yet consumed by the cable-length calculation for cross-floor runs. | Partial | — |
| Cable & drop schedules | Shipped | — |
| TIA-606-D administration labeling | Shipped | TIA-606-D |
Power
| Capability | Status | Standards |
|---|---|---|
| PoE budget & headroom calculation (20% power / 25% port) | Shipped | IEEE 802.3bt |
| UPS sizing & runtime Explicitly labeled a planning estimate, not a certified battery study. | Shipped | IEEE 485-2020 |
| BTU/thermal load calculation, altitude-corrected | Shipped | ASHRAE |
| NEC breaker/circuit sizing (125% continuous, standard-rating step-up) + voltage-drop calculation (3%/5%) | Shipped | NEC 240.6(A) · NEC 210/215/220 |
| Electrical safety screening (arc-flash + short-circuit) Explicitly framed on-page as a screening tool, not a certified arc-flash study. | Partial | IEEE 1584-2018 · IEEE 141 |
| Panel schedule generation (phase rotation, spare slots, BOM deltas) | Shipped | — |
| Redundancy modeling (N/N+1/2N/2N+1) + three-phase load balance + facility power/breaker allocation optimizer | Shipped | BICSI 002 · ANSI/TIA-942 · NEMA MG-1 |
| Permit-ready electrical package (NEC load calc, one-line + riser diagrams, NFPA 72 battery calc) | Shipped | NEC · NFPA 72 |
Wi-Fi
| Capability | Status | Standards |
|---|---|---|
| Predictive RF propagation engine (one shared calculation chain feeds heatmap, planner, walkthrough, remediation) | Shipped | — |
| Standards-based path loss, diffraction & material reflection (multi-floor penetration, knife-edge + UTD + Deygout multi-edge diffraction, complex-permittivity reflection, uplink/downlink asymmetry) Multi-edge diffraction follows the Deygout method per ITU-R P.526 §4.5.4, alongside knife-edge and UTD. | Shipped | ITU-R P.1238 · ITU-R P.526 · ITU-R P.2040 |
| Per-material, per-band wall attenuation | Shipped | NIST IR 6055 |
| Vendor antenna radiation patterns Per-model patterns are derived from published gain and beamwidth figures rather than from imported pattern files. | Partial | — |
| Datasheet-driven AP radio specs with a no-invented-numbers rule Named hardware without usable datasheet radio data is planned generically and disclosed as such, never assigned fabricated numbers. | Shipped | — |
| Field calibration (measured vs. predicted RSSI correction) | Shipped | — |
| AP auto-planner incl. per-zone RF parameter overrides and per-zone redundancy planning Redundancy planning discloses spare AP counts; the failover-safe acceptance threshold is not yet proven — never claim "proven failover." | Shipped | — |
| Per-band heatmap exports (2D + 3D) | Shipped | — |
| Channel planning (apply/revert, DFS eligibility, 6 GHz AFC) | Shipped | — |
| Deterministic walkthrough remediation Physics-based math only, no AI calls in the remediation calculation itself. | Shipped | — |
| RF spectrum analysis Only a disabled adapter stub exists; no hardware spectrum-analyzer integration. | Not available | — |
| Measured Wi-Fi survey capture hardware (e.g. dedicated survey adapter/sensor) The same stub reports "no supported adapter" — site data is entered/predicted, not captured from measurement hardware. | Not available | — |
Cameras
| Capability | Status | Standards |
|---|---|---|
| DORI distance calculation with per-zone targets | Shipped | IEC 62676-4 |
| Real FOV projection (rectilinear, fisheye, 180°/360° panoramic) + varifocal lens interpolation from datasheet endpoints | Shipped | — |
| IR/night-vision reach Range comes from the datasheet; the 3D beam angle is an HFOV/2 heuristic, not a datasheet field — say "IR range from the datasheet," not "beam specification." | Partial | — |
| Occlusion: walls, racking, and ceilings (height-aware shadow casting) | Shipped | — |
| Occlusion: glass Windows are correctly transparent to cameras, but glass-material walls block camera line-of-sight identically to concrete (no material differentiation) — never claim glass and concrete "block cameras very differently." | Partial | — |
| Coverage heatmaps per DORI tier, with canvas/export parity | Shipped | IEC 62676-4 |
| Per-camera 3D point-of-view + POV report | Shipped | — |
| PTZ simulation | Shipped | — |
| Deterministic camera placement advisor Physics-confirmed placement, not an LLM guess. | Shipped | — |
| Camera exports (Coverage Map, interactive Heatmap, POV Report, System Requirements) | Shipped | — |
Access control
| Capability | Status | Standards |
|---|---|---|
| Access device catalog + rich per-device configuration (protocol, fail-safe/secure, supervised end-of-line, credential type) | Shipped | OSDP · Wiegand |
| Canonical door object modeling with life-safety/access-control linkage | Shipped | — |
| Door-hardware-schedule ingestion (XLSX/CSV import, AI normalization, fuzzy door matching) and output across 4 surfaces (plan-set sheet, requirements PDF, mobile report, report builder) | Shipped | — |
| Canonical door labeling (auto-numbering, format-locked) | Shipped | — |
| Door hardware sets A specific hardware-set number is omitted when the standard reference is uncertain, rather than guessed. | Shipped | ANSI/BHMA A156 |
| Door↔access-control coordination and compliance checks (fail-mode-on-egress life-safety flag; fire/ADA/egress rules) + controller capacity resolution Controller port/door capacity is resolved from Product Library data with no invented fallback numbers. | Shipped | NFPA 101 · ADA |
| Access cabling (protocol distance limits, BICSI-style run model with service loop) | Shipped | BICSI |
| Power for access hardware (PoE via the canonical resolver + dedicated PSU sizing with battery backup) | Shipped | UL 294 |
| Camera-to-door pairing | Shipped | — |
| Access Control Requirements deliverable (door/reader/controller schedules, wiring topology, PSU sizing, compliance) | Shipped | UL 294 · NFPA 101 · ADA |
| Turnstile lane modeling A turnstile device type and engine-level service-time defaults exist; no dedicated placement/design UI. | Partial | — |
| Automatic reader placement Readers are placed manually; there is no auto-placement engine for readers (unlike cameras, APs, or paging speakers). | Not available | — |
| Access-control throughput/queueing analysis A full queueing engine (lane throughput, Erlang-C door banks, anti-passback impact, SPOF/availability modeling) exists in code but is not reachable from any UI, panel, or export. | Not available | — |
| Multi-floor access riser diagram A per-controller wiring-topology diagram exists; a dedicated multi-floor access riser diagram does not. | Not available | — |
| Credential/badge management (issuance, licensing, revocation) The data model supports credential technology types on the door schedule; there is no credential-count/licensing calculator or badge-management workflow. | Not available | — |
AV & paging
| Capability | Status | Standards |
|---|---|---|
| AVIXA DISCAS display sizing with full readability analysis (off-axis viewing angle, ambient brightness, mount height, arc-minute text size) | Shipped | AVIXA/InfoComm V202.01:2016 (DISCAS) · SMPTE RP 166-1995 |
| Speech Transmission Index per seat with room acoustics (Sabine RT60) | Shipped | IEC 60268-16 |
| Microphone SNR and polar-pattern modeling (omni/cardioid/supercardioid/beamforming) Speech is referenced to ISO 9921 normal vocal effort at 60 dBA at one metre. | Shipped | IEC 60268-16 · ANSI S3.5 · ISO 9921 |
| Camera framing analysis (pixels-per-face at each seat) | Shipped | — |
| Unified 4-dimension per-seat probe with composite room scoring The four dimensions combine as a weighted composite, and a seat is only scored when every dimension has real product data behind it. | Shipped | — |
| Ambient light and ambient noise estimation pipelines | Shipped | IES Handbook · ASHRAE 90.1 |
| Room grading (A–F) with worst-seat identification and deterministic remediation (published numeric thresholds) | Shipped | — |
| Equipment recommender (tier-based, product-library matched) with placement-advisor coverage heatmap | Shipped | — |
| Conference Room Report exporter | Shipped | — |
| Paging / voice-alarm speaker layout (PAVA): deterministic ceiling-speaker auto-placement, SPL/STI coverage heatmaps | Shipped | IEC 60268-16 |
| Sound-masking auto-design (vendor-constrained) | Shipped | — |
| Line-array / ray-traced (geometric) acoustic modeling Acoustics are statistical models only (Sabine RT60, inverse-square SPL, cone off-axis, wall transmission loss, IEC 60268-16 STI) — no line-array or ray-tracing/geometric acoustic simulation exists; keep any EASE comparison bounded to statistical acoustics. | Not available | — |
Commercial
| Capability | Status | Standards |
|---|---|---|
| Unified BOM platform (provenance reconciliation across 8 source types, sealed revisions + diffs, auto-derived from placed devices) | Shipped | — |
| Technician & project SOW generation (org-saved presets, gap analysis, 3-state scope) | Shipped | — |
| Labor/cost estimating + ROM budget-band estimate Includes a reproducibility hash and versioned diffs. | Shipped | BICSI TDMM · RS Means |
| Quote builder with versioning/approval workflow, plus quote → order → invoice-draft conversion | Shipped | — |
| Customer design proposal document | Shipped | — |
| Contract lifecycle: e-signature & agreements (OTP/KBA identity verification, reminders/expiry, HMAC-signed webhooks, sealed completion certificate) + change orders bound to BOM revisions | Shipped | — |
| Smart order/document import (AI-parsed emails/PDFs into structured orders) | Shipped | — |
| Append-only portal asset ledger with inventory projection | Shipped | — |
| Invoicing / AR with a credit-utilization + dollars-past-due risk model Collections tooling is real; no automated dunning email has yet been sent from production — never claim proven automated collections. | Shipped | — |
| Renewal tracking with auto-spawned discovery session | Shipped | — |
| Adaptive requirements engine (12 domain packs, 5-way fact/assumption/inference/recommendation/risk classification) | Shipped | — |
| Customer portal with per-customer branding and two-layer tenant isolation Branding is logo/colors/name, not a custom domain — see below. | Shipped | — |
| Project-level helpdesk/ticketing Built but NOT RELEASED: the surface and its backing functions exist, and as of 2026-09-13 it belongs to no licensing package, so no plan can reach it. Raising a support ticket with SiteOps is unaffected — that runs through the Help Center, which every plan has. | Not available | — |
| Downstream commercial automation left unwired (vendor purchase-order generation, estimate→quote push) Both exist as code, imported only by their own tests — not reachable from any UI. | Not available | — |
| Role-priced seats (viewer / field / engineer tiers) A seat-type field exists in the data model, but billing does not read it — every assigned seat bills the same regardless of role. | Not available | — |
| Customer portal on your own domain The portal is branded per customer — your logo, colours and name. Serving it from a domain you own is not built. | Not available | — |
| General-ledger accounting (replacing QuickBooks, NetSuite, Sage) There is an internal billing plane — invoices, AR, payments, credit memos — but it is not a general ledger and does not replace an accounting system. | Not available | — |
Delivery & field
| Capability | Status | Standards |
|---|---|---|
| FieldOps v2 mobile shell (today/plan/walk/punch/timeline) with discovery site walk (checklist, voice capture, photo capture) | Shipped | — |
| Resilient/offline-safe job tracking with offline photo capture and background sync | Shipped | — |
| Field install workflow (mark-installed, flag-issue, batch install, punch list) | Shipped | — |
| Acceptance/QA testing with evidence requirements and dual (customer + internal) sign-off | Shipped | — |
| Interactive standalone HTML as-built (single self-contained offline file: overview, floor plans, equipment, cabling/IP, racks, topology, sign-off) | Shipped | — |
| Full as-built document package (PDF/PNG/DXF), incl. rack elevations, schedules, camera install-verification photo pairs | Shipped | — |
| Installation drawings: Installer Plan + Site Plan Set v2 (ARCH-D multi-floor, per-trade schedules, cross-sheet hyperlinks) plus true-scale CAD (DXF) export | Shipped | US National CAD Standard |
| Mobile field HTML reports (cabinet, walkthrough/punch-list, access control, rack, Wi-Fi) These live in the legacy mobile-reports tab; the newer FieldOps v2 shell does not yet host them. | Shipped | — |
| Permit submittal + closeout package (NEC load calc, one-line + riser diagrams, NFPA 72 record of completion, acceptance-test report) | Shipped | NEC · NFPA 72 |
| Closeout binder and Universal Report Builder (18 report templates across PDF/DOCX/XLSX/CSV/HTML/PPTX) | Shipped | — |
| Photo report (site-survey / before-after install / issue / closeout templates) and compliance audit packet / evidence pack | Shipped | — |
| Named "technician work package" bundle and an in-shell FieldOps v2 report launcher The underlying pieces (Tech SOW, WorkItems, Installer Plan) exist as separate artifacts, not one named bundle; the v2 shell's "reports" tab is currently a placeholder — mobile reports live in the legacy tab (row 8 above). | Not available | — |
Platform
| Capability | Status | Standards |
|---|---|---|
| Read-only REST API (Command tier, key-based auth, rate limiting, entitlement gating) Zero measured production adoption as of the audit date; read-only across 8 resource types — no write operations. | Shipped | — |
| Write API The shipped API surface is read-only; there is no write/mutate API. | Not available | — |
| Single sign-on (SAML) Sign-in only; does not provision new accounts or support self-serve signup. | Partial | SAML |
| Service desk / ticketing / RMM (MSP PSA platform) A narrow project-scoped helpdesk surface exists; there is no remote monitoring & management or standalone ticketing/PSA product. | Not available | — |
The same table, machine-readable
/capabilities.json carries every row above — identifiers, statuses, standards and caveats — generated from the same source at build time, so the two versions cannot disagree with each other. The not-available rows are in there too.
Frequently asked questions
Why publish the things it cannot do?
Because a capability list with no negatives tells you nothing. Every vendor claims the ticks; the value of this page is that the blanks are here too, in the same table, with the same weight. If you are evaluating platforms, the fastest way to judge one is to ask what it admits to — and a build check stops these rows from quietly disappearing.
What does "partial" mean?
That the capability is real but bounded, and the bound is stated on the row rather than left for you to discover during a deployment. A partial row always carries its caveat — the platform validates copper categories it cannot draw, for example, or computes cable length within a floor but not between floors.
How was this verified?
Each row was checked against the product source during a capability audit, then attacked by independent reviewers whose job was to disprove it. Two claims died in that pass and were corrected here rather than published: a fiber allocation engine that exists in code but is reachable from nothing, and an API that an earlier draft wrongly said did not exist.
Is there a machine-readable version?
Yes — the same rows are served as JSON at /capabilities.json, rendered from the same source at build time so the two cannot disagree. It carries the identifiers, statuses, standards and caveats, including every not-available row.
How current is it?
It reflects the platform as audited on 28 August 2026. Capabilities are added here only after they are shipped and reachable in the product — not when they are planned, and not when they exist in code but no interface reaches them. That distinction is the reason two entries on this page are marked not available despite having working code behind them.
Check it against your own requirements
Bring the capability list your project actually needs and we will walk this table against it — including the rows where the answer is no. Talk to us about what your team needs.