Investigation
Bend Privacy Alliance / Axon patents series, Part 6 of 11 · September 2026
Inside Axon and Fusus’s architecture for ingesting, translating, sharing, and acting on data from systems they did not build.
The camera does not have to be made by Axon. Neither does the alarm system.
A building may already have its own cameras. Its access-control system may come from another vendor. A 911 platform, drone detector, license-plate reader, or tactical robot may belong to still another company. Axon’s Fusus platform is designed to make systems like these legible inside a common operational environment.
That changes how surveillance can expand. A police department does not necessarily need to replace every camera or sensor in a city. It can connect systems that already exist.
Axon’s current Fusus camera-setup documentation describes several ways to do this. A camera can connect through a fususCore, through a direct network connection, or through an external appliance. The setup supports RTSP and RTMP streams and records information such as camera make and model, network location, credentials, map position, direction, and whether the source is internal or external.
That is only the first layer.
Interoperability sounds like plumbing. But the plumbing contains decisions.
Teaching Axon to understand outside surveillance
One of the clearest patent examples begins not with a body camera or a Fusus map, but with an old and messy problem: proprietary surveillance video.
Different CCTV manufacturers may package video, audio, timestamps, and metadata differently. A single exported file may contain streams from several cameras. Frames may be interleaved. Manufacturer-specific software may be required just to make sense of what is inside.
Axon now owns US11825156B1, “Computer system for processing multiplexed digital multimedia files.” The patent describes software that analyzes proprietary surveillance media and uses format definitions to determine where frames begin, how long they are, which camera or other source they came from, their timestamps, and how they should be separated into usable streams.
The commercial version of that idea appears in Axon Evidence Third-Party Video Support. Axon documents automatic conversion of supported non-Axon video into a playable form while retaining the original file. Converted material can later be extracted into separately managed evidence so it can be clipped, marked, transcribed, or redacted.
Some CCTV exports are even more complicated. Axon’s documentation describes directory-based evidence packages containing fragmented video and audio, separate metadata files, index files, and nested folder structures. The interoperability problem is therefore not just decoding a codec. Sometimes the system must reconstruct the structure of an outside evidence package before it can make the media usable.
Not every important capability in this architecture corresponds to a separate Axon patent. The portfolio review behind this article found two strong patent-backed foundations, but many of the most consequential interoperability functions described below appear instead in Axon’s current commercial documentation.
A patent tells us what a company claimed or disclosed. A product guide tells us what the platform currently supports. Neither, by itself, tells us what Bend has enabled.
Interoperability is translation
A third-party system does not necessarily describe the world the same way Fusus does.
One alarm vendor may report an event as panic. Another may use a longer description. One system may send a status as ACTIVE; another may use active. A source system may have its own location names, priorities, and resolution codes.
Fusus’s current Mapping documentation describes a layer that translates those outside values into the Fusus data model. Axon calls this “code mapping.” The system can map five categories of information: location, alarm type, alarm status, alarm priority, and reason code.
The raw source value does not simply disappear. For alarm type, Fusus displays the source-system value and description as read-only fields, then allows those values to be associated with standardized Fusus categories. The same basic process applies to status, priority, location, and disposition.
The same principle has applied to analytical enrichment, not just raw events or video. In Axon’s October 2024 release notes, the company said that U.S. law-enforcement users with the Flock Safety Vehicle Characteristic enrichment service enabled could search Axon ALPR records using fields including Plate State, Vehicle Body, Vehicle Make, Vehicle Color, and Plate Type. In that workflow, outside analytics were not merely displayed beside Axon data; they became searchable fields inside the Axon interface.
That historical example is useful because it shows what interoperability can do to the user’s experience of provenance. A characteristic may have been derived by a third-party service, but once it crosses into a common search environment, the investigator encounters it as another normalized field alongside plate, location, time, and other search criteria. The interface can make data from different technical origins feel like one operational record.
The provider architecture should not be assumed to have remained unchanged. Axon’s current Fusus ALPR documentation independently describes searches using AI-detected vehicle attributes such as color, make, and type, along with additional details, and its current export schema includes a provider field identifying the source of the detection. That establishes that vehicle-attribute search remains part of the present platform, but it does not establish that Axon’s current Vehicle Intelligence or attribute inference is powered by Flock.
Current Fusus release notes also describe Axon’s own VAR Inference as an AI model that can enrich LPR records with missing or low-confidence vehicle attributes such as color, make, and model. The defensible conclusion is therefore narrower: third-party Flock enrichment was documented inside the Axon ecosystem in 2024, while current Axon/Fusus documentation shows vehicle-attribute enrichment and search continuing today under an architecture that should be evaluated on its current sources and configuration.
There are therefore at least two kinds of interoperability.
The first is technical: can one system read another system’s stream, file, or API?
The second is semantic: what does the incoming information mean once it arrives?
That second layer deserves more public attention than it usually receives. Mapping an outside value into “Critical,” “High,” “Medium,” or “Low” is not the same kind of operation as simply opening a video stream. Someone—or some configured process—has decided what an outside system’s value means inside Fusus.
Once those source values are mapped, they become the values used in alarm lists, alert rules, analytics, location mapping, and related camera workflows.
When translation shapes what operators see
Fusus’s Device Configuration documentation says imported alarm and access-control devices can be classified as sensors, actuators, or both. They can be assigned criticality and mapped to specific locations and floors. Axon says proper placement is required so the system can identify nearby cameras when an alarm is triggered.
The Alarm List then shows operators the standardized result: a Fusus-assigned alarm ID, type, priority, triggering device, status, and mapped location.
That does not mean every mapped alarm automatically dispatches police or produces the same response; the current public documentation does not establish that.
But it does establish that the translation layer becomes part of the operational environment.
A wrong location mapping could associate an alarm with the wrong building or floor. A wrong priority mapping could make an event appear more or less urgent. A wrong status mapping could make an active event appear resolved.
Those are not documented Bend failures. They are failure modes created by the architecture itself. A later reviewer may need to reconstruct not merely what the source system reported, but how Fusus interpreted it.
Axon’s public documentation shows whether mappings are manual or automatic. What the material reviewed for this article does not establish is a complete field-by-field historical version record showing every prior mapping and every later change.
The record an operator sees may not be the original record
Interoperability can produce several representations of the same underlying event.
An alarm begins as a source-system event. Fusus may turn it into a normalized operational representation. A related camera recording may enter fususVAULT or Axon Evidence. A proprietary CCTV file may be converted into a playable version. That converted video may later be extracted as a standard MP4 and become a separately managed evidence item.
A partner agency may then see the case by reference—or import its own copy. Another system may receive still another record through an API or webhook.
These objects are related, but they are not interchangeable.
Axon’s Third-Party Video documentation makes the distinction especially visible. The original CCTV format can be retained while Axon creates a playable conversion. Rewrapping or extraction can create another MP4 evidence item intended for downstream editing, clipping, or redaction.
Each stage should remain traceable to the authoritative original.
Even timestamp display can involve interpretation. Axon’s documentation acknowledges that some third-party media may not contain a usable embedded frame timestamp and that playback can depend on configuration, format knowledge, frame-rate interpretation, or manufacturer-specific behavior.
For ordinary playback, these may seem like technical details. For evidence, chronology, and later review, they are provenance.
The question is whether a reviewer can still determine what the outside system actually produced, what Axon changed to make it usable, and which later files are derivatives.
The network can talk back
Information does not flow only into Fusus.
Axon’s current ALPR Hit Alerts documentation describes an API option that can send a hotlist hit to another system through an HTTP webhook. Axon gives examples including CAD/RMS systems, GSOC dashboards, and automation workflows. The documented payload can include the plate, state, hotlist, alert category, camera or source, timestamp, and available vehicle attributes.
Fusus is therefore not only an ingestion layer. In some workflows it is also an event-publishing layer.
That outside system may then create its own record, apply its own retention policy, or initiate another automated process.
This is why describing Fusus only as a dashboard misses something important. It can also function as a translation and routing layer between systems.
The product guide can tell us that Fusus supports this capability. It cannot tell us whether Bend has configured an outbound endpoint, what fields Bend sends, whether the receiving system creates another record, or what happens to that record afterward.
“Shared” does not mean one thing
The same problem appears in evidence sharing.
Axon’s current Advanced Sharing documentation distinguishes between giving a partner access to the originating agency’s case and allowing that partner to import its own working copy.
In the first model, the recipient is looking at source-owned material. In the second, the recipient obtains a copy it can manage independently. Axon’s case-sharing guide describes these as a reference view and an imported working copy.
Axon also documents Auto Import and, for Axon Justice recipients, Auto Synchronization. A sharing relationship can therefore become a continuing interagency pipeline rather than a one-time transmission.
Revoking access is not the same thing as recalling a copy.
Once a receiving organization has imported or copied evidence, the source agency’s later revocation does not necessarily delete that recipient-controlled copy. The copy may instead follow the receiving organization’s own retention rules.
Hidden is not the same thing as removed
Advanced Sharing contains an especially revealing example.
Axon’s Advanced Sharing setup says basic information including EXIF data is always included in every Advanced Share. At the same time, its separate GPS policy allows device-embedded GPS to be hidden from the receiving organization’s interface while remaining in the underlying evidence file.
Manually added GPS is treated differently: when excluded, it is removed from the shared evidence.
Those are materially different privacy outcomes.
Hidden is not the same thing as removed.
In other words, a sharing policy can change what the recipient sees without necessarily changing what the underlying file still contains.
That distinction matters far beyond GPS. Privacy policies often describe information as “hidden,” “excluded,” or “not displayed” without distinguishing whether the underlying data was actually stripped.
Axon’s own documentation gives us a concrete reason to ask.
What disappears, and what refuses to disappear
Interoperability creates a peculiar asymmetry.
Some records may be more temporary than the public assumes. Others may be harder to recall than the originating agency expects.
Axon’s current Fusus Alerts documentation says alerts remain available for up to 24 hours, are not stored as historical records, and should not be treated as the system of record. The outside system that generated the event is expected to maintain the historical source of truth.
So an alert can appear in Fusus, influence an operator, participate in a response, and later cease to exist as a historical Fusus alert.
At the same time, an imported Axon Evidence copy may survive after the originating organization revokes access.
One operational representation can disappear. Another copy can persist.
This is not a simple story about “surveillance data being stored forever.” It is a custody problem.
The architecture can create both ephemeral operational records and durable downstream copies.
Drones and robots cross the same boundaries
The same interoperability logic extends beyond fixed cameras and databases.
The research identifies pathways involving Axon Air, DroneSense, Skydio, Fusus, Respond, and Axon Robotics. One especially clear example is the Robotics Sync Box, which Axon describes as converting analog RF video from tactical robots, UAVs, UGVs, or pole-camera systems into digital streams that can move through Axon Respond, Fusus, or DroneSense.
Axon’s current Robotics evidence documentation says logs and videos are not stored on the robotic devices themselves. Video is sent directly to the connected application.
Where does the first durable copy begin?
It may be in the connected app. It may be in Fusus or Respond. It may be in DroneSense. It may not become durable until it reaches Axon Evidence.
What we know—and do not know—about Bend
Bend’s public records already document some of the prerequisites for interoperability.
The City approved Fusus in 2023. The underlying City-hosted Fusus agreement contemplated community-camera registration and integration, CAD integration, public and private video feeds, mobile live viewing, cloud storage, and related operational capabilities. Bend later expanded Axon Air, and the 2024 Axon Air procurement record included advanced-streaming and API-integration capabilities.
Those records establish that interoperability is not purely theoretical here.
They do not establish that Bend has enabled every broader Fusus connector, mapping, webhook, Advanced Sharing, or partner-cloud feature described in Axon’s current documentation.
The distinction is essential:
Axon supports it.
Bend purchased something related to it.
Bend actually enabled and uses it.
Those are separate propositions.
The current record does not yet establish which external alarm systems, camera connectors, mapping tables, webhook endpoints, Advanced Sharing policies, partner organizations, or drone-cloud integrations Bend has enabled.
A meaningful local surveillance inventory would therefore identify more than products. It would identify connections.
Which camera systems feed Fusus? Which outside vendors send alarms or alerts? Which raw values are translated into Fusus categories? Who maintains those mappings? Which agencies receive Axon Evidence cases by reference, and which can import copies? Is a Sender Audit Trail included? Is GPS stripped, hidden, or still embedded? Which Fusus events leave through webhooks? Where does drone or robot video first become durable?
And which copies remain after the originating record is deleted or access is revoked?
Oversight has to follow the connections
Police surveillance used to be easier to picture.
There was a camera, a recording, and a database.
Integrated systems blur those boundaries.
A private camera can appear in a public-safety interface without becoming an Axon camera. An outside alarm can become a standardized Fusus alarm without Fusus becoming the historical source system. A proprietary CCTV export can become an Axon-playable derivative without replacing the original.
A police case can be viewed by one partner, imported by another, synchronized to a prosecutor, and exported elsewhere. A hotlist hit can leave Fusus through a webhook and create another record in another system. A tactical robot may never store the video it captures.
The connective tissue is becoming as important as the sensors.
That should change how these systems are governed.
An oversight process that looks only at cameras, drones, or license-plate readers will miss much of the architecture. The public also needs to know what connectors are active, which outside systems exchange information, what values are translated, who controls those mappings, where automated outputs go, which partners receive copies, and what survives after access is revoked.
Interoperability is often sold as efficiency. Sometimes it is.
It removes friction between systems that once could not easily communicate.
But friction can also be a privacy boundary.
A camera that had to be requested manually is different from a camera already available on a common map. An alarm that remained inside one vendor’s system is different from one translated into a shared operational model. A case that had to be copied deliberately is different from one that can synchronize automatically.
The question is therefore not simply whether Axon can connect these systems. It is whether the public can still see—and govern—the connections once it does.