Same data home
Records live on the same self-hosted host as dispatch. One database, one backup pipeline, one compliance review. No second vendor, no second migration story.
In development Architecture & approach
Records on the same backbone. Defensible by design.
ctHelixRMS™ is engineered to share the spine your dispatch operation already runs on — same data home, same audit thread, same self-host story. Below: what RMS shares with the rest of the suite, what it adds for records-specific defensibility, and what it deliberately stays out of.
Shares the spine
One backbone, two surfaces.
ctHelixRMS™ doesn’t introduce a second platform to operate. It runs on the same backbone as ctHelixCAD™ — your IT, security, and DBA teams don’t need to learn anything new.
Same audit thread
The dispatch incident, the RMS report, the supplement, and the supervisor sign-off all share one audit log. Every mutation is attributed and timestamped — the chain is the chain.
Same identity model
Console operators, supervisors, and approvers use the same identity that runs dispatch. Field officers writing reports authenticate through the same mobile surface — built on the same auth primitives.
Same self-host story
Run it on your hardware, your VM, or your air-gapped network. Or let us host. Single-tenant either way — your data, your database, your isolation.
Defensible by design
The properties records work depends on.
Records management lives or dies by the audit thread. Every primitive below is engineered into the platform — append-only where it matters, reversible only with attribution, and inheriting the same hardened defaults the rest of the suite uses.
Defensible records
- Append-only narratives — corrections supersede prior entries with attribution; nothing is overwritten or quietly edited.
- Versioned approval history — kickbacks, revisions, and re-submissions preserved as a complete chain a supervisor or auditor can replay.
- Person merge with rollback — when duplicate identities are reconciled, the action is reversible and fully audited.
- Per-agency yearly numbering — incidents, arrests, and FI cards each carry their own deterministic, gap-free numbering inside your agency.
CJIS-aware primitives
- Multi-factor authentication available for accounts handling criminal-justice information.
- Configurable password rotation cadence to the policy your agency operates under.
- Per-query audit logging on sensitive lookups — the query and the reason given are recorded; the full sensitive response body never is.
- Encrypted storage of sensitive identifiers with reveal-with-permission and a distinct audit trail for each reveal.
- Granular role-based permissions for create, edit-own-draft, submit, read-own, read-agency, approve, and reopen.
Operationally portable
- Same Linux VM, same systemd supervision, same deployment pipeline as ctHelixCAD™. Your existing IT team already knows the shape.
- Standard SQL backbone — your DBAs and security team recognize every piece of it on first read.
- Air-gap-friendly — operates without outbound calls between periodic license check-ins.
- No telemetry on operational data. No phone-home with reports, persons, or sensitive records.
Deliberately not in scope
What ctHelixRMS™ doesn’t try to be.
Smaller agencies have spent years inheriting features that came with legal and compliance weight they didn’t ask for. We tell you up front what we stay out of.
No direct NCIC / NLETS brokerage
We don’t broker your federated-system access. Your existing terminal stays where it is; we log the request and the outcome through per-query audit, not the response body.
No facial recognition or biometric matching
Not v1, not roadmap. Smaller agencies rightly don’t want this inside their records system, and the legal posture is still in motion.
No intelligence or SAR-style analytics
Records management is not an intelligence platform. 28 CFR Part 23 governs intelligence systems for a reason — we deliberately stay out of that scope.
Compliance posture
CJIS-aware primitives, transparently deployed.
ctHelixRMS™ is engineered with the primitives a CJIS-style framework expects — MFA, configurable rotation cadence, per-query audit on sensitive lookups, encrypted storage of sensitive identifiers, granular RBAC, single-tenant isolation, and self-hosting. Final compliance against CJIS or any specific framework is always a function of how an environment is operated; we publish what the platform provides so your security team can map it to the controls they own.
Want to shape the records approach with us?
Early agencies tell us what their records reality looks like and what their CJIS posture demands. That shapes what ships first.