An incident routed to the wrong viewer can leave responders acting on the wrong scene. Check first responder drone software by assigning an owner to each dispatch, live-video and evidence handoff, then recording whether the intended recipient received the correct incident context. Drone as first responder (DFR) and computer-aided dispatch (CAD) are the terms used below.
An empty office chair beside a desk with two dark monitors, a headset, keyboard and closed blue notebook.
Start with a handoff checklist that follows the incident from dispatch to the operator, the authorized viewer and the retrieved evidence record. For every boundary, name the sending and receiving owners, open the installed interface documentation, and keep the observed result separate from the expected behavior. This page provides a blank responsibility matrix and eight proposed acceptance checks for an approved local exercise. It is based on public documents, not our deployment testing. A missing record, an untested network path or an unassigned owner remains unknown; none counts as a passed check.
- A working stream establishes viewing, not successful evidence intake.
- A flight reference and an incident reference need an explicit relationship.
- A supplier’s named integration still needs local configuration evidence.
- Exceptions need a receiving owner and an approved fallback channel.
Which handoffs need their own owner?
Assign an owner to each information boundary, including the return acknowledgement. The proposed flow is dispatch record → operator view → authorized field or command viewer, with a separate recording-and-metadata path to evidence intake and retrieval. These are information responsibilities, not aircraft-control instructions or a required system architecture.
The contributed Commercial UAV News program guide, read on 15 October 2026, asks who watches feeds, who relays important information, which channels carry it and what backup is available. Those planning questions inform the matrix; the guide does not establish your staffing rule.
The CJTTEC implementation brief distinguishes flight-management software, CAD interfaces and evidence-management functions. Its “Document” section discusses mission metadata and possible evidence-system uploads. That supports checking each boundary separately; it does not prove an automatic transfer in an installed system.
Copy the following matrix into your local review record. Suggested roles describe responsibilities; replace them with the people and titles your agency actually uses. Empty cells are intentional.
| Boundary | Responsible roles to name locally | Local document and observation needed | Local owner / source / record |
|---|---|---|---|
| Dispatch → operator | Dispatch owner and receiving UAS role | Versioned field map and routing rule; sent incident reference, location and update state compared with received item and acknowledgement | |
| Operator → viewer | Video service owner and receiving supervisor | Sharing/access configuration; intended role sees the correct incident and current, stale or unavailable state | |
| Recording → evidence intake and retrieval | Recording/integration owner and evidence custodian | Export/ingest mapping; repository receipt and retrieved video/metadata preserve the intended incident association | |
| Exception → receiving owner | Named supervisor and support owner | Approved fallback/escalation runbook; missing item, acknowledgement and disposition recorded |
For each row, also record the installed versions, configuration date, source document/page, sender and receiver clock basis, test device/network, observer and run date. An illustrative entry would read: “Dispatch → operator; training incident EXAMPLE-A; compare sent and received reference; owner and result still unfilled.” EXAMPLE-A is a fictional label for explaining the sheet, not an observed incident or a prescribed ID format.
What does a supplier integration claim establish?
It identifies a connection to investigate; it does not establish that your installed CAD, viewer and evidence repository interoperate.
As read on 15 October 2026, RapidSOS describes a link between RapidSOS Unite and Skydio Command, with incident markers and drone location/video in Unite. DroneSense names Versaterm CAD, MDT and Mobile in its CAD workflow description. Each is a supplier statement about named products. Neither supplies your connector version, enabled fields or observed acknowledgements.
DroneSense’s Magic Video Link description says video can be shared by email or text with designated viewers while some telemetry and pilot details are omitted. Check which incident context the receiving role actually sees. That page does not establish your local authentication, expiry or revocation behavior.
Before an exercise, collect the installed product/version, interface owner, enabled connector, field map, permissions and approved exception rule. Record unknown where a document is missing. CJTTEC’s compatibility checklist asks whether software fits existing agency systems and what supporting infrastructure or staffing is needed; it does not answer those questions for your deployment.
How do incident, flight and evidence records stay linked?
Keep the incident-to-flight relationship explicit, then verify the stored record by retrieval. Do not assume that one flight represents one call or that a flight log proves video was ingested.
A laptop with a dark screen, connected external drive, folders and a memory-card case on a desk.
DroneSense’s Calls for Service section, read on 15 October 2026, describes support for multiple calls per flight and call data in flight logs. This is a reason to test your local mapping, not a claim that every product implements the same relationship. In an approved training example, associate two fictional incidents with one test mission and check each intended association after export and retrieval. Whether the repository uses one recording or several is a local mapping decision.
The Montgomery County FAQ, read on 15 October 2026, says mission video/photo evidence follows its existing body-worn and in-car storage and access rules. This is one agency’s practice, not a universal repository design or retention period.
For your local check, have the custodian retrieve the intended record under the intended role. Keep the repository receipt, retrieved record reference and approved incident association together. A successful viewer session, flight log or public dashboard entry alone does not supply those observations.
What should the acceptance exercise test?
Test the approved normal route and the exceptions that could hide a wrong incident, wrong recipient or missing recording. The eight scenarios below are proposed editorial checks; local owners must approve the preconditions and expected behavior before execution.
Use non-sensitive training records and explicitly approved test accounts in an isolated exercise. Record the actual installed configuration. Any flight-control response remains governed by approved flight procedures; these checks concern information delivery only.
| ID / scenario | Approved exercise action | Evidence needed to mark pass |
|---|---|---|
| T01 Correct route | Send a training incident through the agreed information path | Sent/received incident reference and location match; intended operator and viewer acknowledge the correct context |
| T02 Missing incident ID | Submit an approved test item without its reference | The agreed rejection, quarantine or manual reconciliation is visible and acknowledged; no invented ID or silent proximity match |
| T03 Update or cancel | Change a training incident’s information state | Sender and receiver states follow the versioned update/cancel rule, with the required acknowledgement; no flight action is specified |
| T04 Multiple incidents per flight | Associate approved training incidents with a test mission | Each approved incident/flight/record relationship survives retrieval without overwrite or wrong association |
| T05 Wrong viewer or removed permission | Use explicitly approved unauthorized and permission-removed test roles | Access matches the approved local policy and the observation is recorded; confirm the local mechanism before testing |
| T06 Lost and restored feed | Interrupt only the viewer’s test feed/network path, then restore it | Agreed stale/unavailable status, owner notification and fallback occur; restored current context is identified |
| T07 Failed evidence intake | In the approved setup, interrupt a non-sensitive test recording transfer, then reconcile it | Failed/missing intake is visible to its owner; subsequent receipt and retrieval preserve the approved incident link |
| T08 Receiver network boundary | Repeat agreed viewing and retrieval from the intended receiver’s permitted network | The intended role/device/network/configuration combination can view and retrieve the correct context |
Pass means the specified observation is recorded. Fail means an observed contradiction. Unknown means the scenario was not run, the rule is unapproved or the required evidence is unavailable. Unknown does not satisfy acceptance. A wrong incident or recipient, silently stale video, or footage declared stored without the required receipt is a failure against the corresponding agreed check. No universal delay target or product capability is implied.
For T06, agree how users recognize loss and recovery before interrupting a test path. Do not treat the last visible frame as current merely because it remains on screen. The UAS data-relay explainer helps distinguish link availability from useful information delivery; the local exercise must still establish what the viewer sees.
A rugged tablet with a dark screen and a radio on the open tailgate of a utility vehicle.
Blank run record
Use one copy of this run header per exercise, then complete every scenario row. The table is an unexecuted worksheet, not sample results.
| Run field | Local entry |
|---|---|
| Run ID, configuration snapshot and source document/version/page | |
| Approved input, preconditions, exception/fallback rule and expected behavior | |
| Sender/receiver/custodian roles; clock/time-zone basis | |
| Device, network and test environment | |
| Observer and run date |
The scenario table defines the expected observation for each ID; record the actual outcome separately below. Evidence references should locate the sender item, receiver view/acknowledgement and custodian receipt/retrieval where applicable. Record “not applicable” with a reason for a boundary the scenario does not exercise.
| Test ID | Actual observation | Evidence references | Result | Discrepancy owner / follow-up / retest |
|---|---|---|---|---|
| T01 | Unknown / not run | |||
| T02 | Unknown / not run | |||
| T03 | Unknown / not run | |||
| T04 | Unknown / not run | |||
| T05 | Unknown / not run | |||
| T06 | Unknown / not run | |||
| T07 | Unknown / not run | |||
| T08 | Unknown / not run |
What happens to unresolved handoffs?
Keep each unresolved boundary open with an owner, missing evidence and a retest action. The exercise is complete only for the scenarios and configuration combinations actually observed; a connector change or a different receiving network needs its own relevant check.
Before treating a boundary as accepted, confirm that its local mapping and permissions are approved, required acknowledgements and evidence references exist, and every discrepancy has a recorded disposition. A manual fallback belongs in the record only after local approval, with its receiving role and acknowledgement specified. This worksheet proposes no response-time threshold, legal retention schedule or aircraft launch procedure.
For access, retention and governance decisions, continue with the DFR policy owner-and-evidence matrix. Where a separate emergency authorization review is needed, use the emergency drone authorization and SGI checklist. Software handoff results do not supply flight authority. Browse the publication archive for the surrounding operational explainers.
Method and sources
This is an independent editorial worksheet compiled from public material checked on 15 October 2026. No agency deployment, vendor console, permission change, network interruption or evidence transfer was tested for this article. The matrix, scenario criteria and blank run record are proposed review tools, not a published technical standard or a certification.
The supplier pages support only the named examples attributed above. CJTTEC supports the separation of software functions and local compatibility questions; the county FAQ supplies one evidence-policy example. The contributed program guide supplies workflow planning questions. The RapidSOS developer portal did not provide readable API documentation in the research, so no endpoint, payload or general CAD compatibility is inferred. The photographs show workstations, recording media and a field receiver; they do not depict a department installation, an incident or a live dashboard.
Last updated: 15 October 2026.
