CentralSquare

How it connects

Incident and dispatch records would come across from CentralSquare over its API: the call for service, the units assigned, the times and the location. Those identifiers would arrive as custom attributes on the media, so the incident number is part of the evidence record rather than a note beside it.

Matching would be by time and unit, because both sides hold those two facts. A body camera recording carries its start time and the device it came from, and the incident timeline carries the units and their times, so correlation happens on ingest. An engagement would settle the awkward cases before they arise: two units on scene inside the same minute, a device with clock drift, a recording that starts before the call was created.

CentralSquare would stay the system of record for the incident, and dispatch would not change. A workflow could act on the result, most usefully by finding the recordings that matched nothing, which in a small agency is where a misconfigured device is discovered.

What you can do together

• Retrieve every recording on a call by its incident number, without knowing who was on shift.
• Have the incident number, unit and location land as attributes on ingest rather than being typed in later.
• Assemble the media for one call with a workflow when a request or a review needs it.
• Find recordings that matched no incident, which is the check a small agency rarely has time to run by hand.

A scenario

1. ScopingThe engagement would agree which incident fields come across and what the rule is when two units match the same recording.
2. SetupThe connection would be configured once against the CentralSquare API with the attribute mapping.
3. End of shiftRecordings ingest and correlate to their calls, the incident number arriving as an attribute under the library's retention and access control.
4. A complaintA supervisor searches the incident number and has every unit's footage in one place within a minute.
5. MonthlyA workflow lists unmatched recordings, and a camera whose clock had drifted by four minutes is corrected.

What stays where

Products and solutions

• Nexus and AI Intelligence Hub
• Digital Evidence Management

The Case Number Decides Where Evidence Files

This connector is not prebuilt. It would be built to your requirement on the REST API and ingestion path the platform already uses for records systems, with scope and effort agreed per engagement. CentralSquare RMS holds incident reports and case records for agencies running its public safety suite. Where the CAD connection answers which call a recording belongs to, this one answers which case, and the case number is the identifier that follows a matter to a prosecutor.

How it connects

Case and report records would come across from CentralSquare RMS over its API, and the case number would arrive as a custom attribute on the media. Attribute mapping carries that identifier across the boundary, which is the whole point: the case number is usually the only reference shared by the records system, the evidence store and whatever the prosecutor works in.

Evidence would file against the case rather than into a folder someone picked. On ingest an item attaches to its case number, so the library's organization follows the record rather than drifting from it. An engagement would settle what a case closing means for the evidence attached to it, because a records retention schedule and an evidence retention schedule are usually written by different people and rarely agree.

CentralSquare RMS would stay the authoritative case record. A workflow could read it to assemble a case file, or to check that every item a report cites is actually present, which is a different question from whether the library looks organized.

What you can do together

• File evidence against the RMS case number on ingest, so filing does not depend on someone choosing correctly.
• Assemble what a case file needs from the record rather than from a list someone maintains.
• Check that every item a report cites exists, and find the gaps before a deadline does.
• Carry the case number as an attribute so it survives export and transfer.

A scenario

1. ScopingThe engagement would agree which case fields come across and whether a closed case changes evidence retention.
2. SetupThe connection would be configured once against the RMS API with the case number mapped to an attribute.
3. FilingA recorded interview ingests and attaches to its case, under the library's access control, retention and custody record.
4. Case preparationA workflow reads the case, gathers the attached media, and lists cited items that are missing.
5. HandoverThe file goes to the prosecutor with the case number on every item, so nothing is re-identified at the other end.

What stays where

Products and solutions

• Nexus and AI Intelligence Hub
• Digital Evidence Management

Next step

See it on your own CentralSquare instance. We will show the connection made, the data moving and the output, then size it for your deployment.

Request a demonstration →  or write to sales@vidizmo.ai

sales@vidizmo.ai  ·  vidizmo.ai/integrations/catalog/centralsquare