Privacy basics for Cases and Evidence

NearbySpy stores investigative work — Cases, Operations, Evidence, Subjects, and messages — under strict access boundaries that follow how a private investigator actually thinks about confidentiality. This article explains, in plain language, what we do at the database, application, and operational layers so you understand exactly how your Case data is isolated.

Cases are isolation boundaries

Every record that belongs to a Case carries a case_id in the database. That column is the foundation of our row-level security. Postgres policies on each Case-data table compare the requesting account against the Case membership table before a single row is returned. There is no scenario in which one Case's Operations, Evidence, comments, or messages can be queried from another Case — including by Investigators who own multiple Cases. Each request is filtered at the query layer, not in JavaScript, which means an accidental missing filter in application code cannot leak rows.

What "scoped to a Case" means in practice

• An Operator added to Case A cannot see Case B even if you share a teammate.
• A Client invited to Case A only sees Operations explicitly marked visible to that Client.
• Subjects and Persons of Interest never see anything — Subjects are records, not accounts.
• Evidence storage paths use the form case_id/operation_id/file_id/filename, so even raw storage URLs are tied to a Case identifier.

Roles control what each member can do

Within a Case, the role hierarchy is Owner, Admin, Investigator, Viewer, Client. Owners and Admins control settings, members, and visibility. Investigators create and edit work. Viewers are read-only. Clients see only what has been explicitly shared. See Case roles: Owner, Admin, Investigator, Viewer, Client for the full matrix.

Per-Operation visibility

Even inside a Case, individual Operations can be hidden from Clients, shown to all Clients, or shown to a selected subset. Read Controlling what Clients see on Operations for the rules and how visibility changes are recorded.

Evidence integrity and immutability

Every Evidence file is fingerprinted with a SHA-256 hash before upload. The hash is verified server-side after the file lands in storage. Once stored, the Evidence record cannot be edited — only soft-archived by an Admin or Owner. This is the same chain-of-custody discipline you would maintain on a physical exhibit. Detailed coverage lives in Why Evidence is immutable and how archive/restore works.

Audit trails

Sensitive actions — Case creation, Operation edits, Evidence access, permission changes, Client view events, member additions, comment posts, and failed authentication attempts — are written to append-only audit tables. Audit rows are never updated or deleted. This gives you a defensible record if a Case ever needs to be reviewed by counsel, an oversight body, or in court.

Where you control your data

Your account preferences are managed under Investigator settings overview or, for Clients, Client account settings. For platform-wide security policies see Security practices and legal pages.