Regulated Data and Retention

PriviNet Inc · Last updated July 8, 2026 · contact: brad@privinet.net

This page explains, in plain terms, what data you may send Lumra on a self-serve pilot, how we protect regulated data from entering the system before the right agreements exist, and how retention and deletion actually work. It is a companion to our Privacy Policy and Terms of Service; where they differ, those govern.

Self-serve is for synthetic or non-regulated data

When you sign up on the website and get a key immediately, that account is for synthetic or non-regulated operational metadata only: timestamps, device identifiers, event types, coarse readings, zone labels, and content hashes. It is not for regulated personal data.

What we block at intake, and why

Until an account is approved for regulated data, our API rejects payloads that carry fields which look like direct personal identifiers, health information, biometrics, or embedded raw media. The event is refused with a clear message naming the fields, and nothing is stored. This is a safeguard so a regulated data set cannot quietly enter the system, or an immutable archive, before a legal basis exists for it.

Examples that are blocked on a self-serve account: patient or resident names, dates of birth, government identifiers, medical record numbers, biometric templates, and embedded raw images, audio, or video. Send a hash of media, not the media itself.

Two honest limits of this filter. First, it recognizes fields, not intent: location coordinates on a truck or a pallet are ordinary operational telemetry and pass, and because direct identifiers are rejected, a payload cannot tie those coordinates to a named person. Second, the filter is a safeguard, not a substitute for your obligations: data the filter cannot recognize as regulated (for example, coordinates or schedules that describe an identifiable person, employee monitoring, or data about children) is still prohibited on a self-serve account by your agreement, even when the API accepts the payload.

If your use is regulated

Senior care, health, biometric, and similar uses are welcome, but not through self-serve. Contact brad@privinet.net first. We review the use, and where it applies we execute a Business Associate Agreement (BAA) or Data Processing Agreement (DPA) before any live regulated data is sent. Only then is the account enabled for that data. We will not turn a self-serve pilot into a regulated one silently.

Retention: sandbox by default, immutable is opt-in

Sandbox (default). Self-serve ProofPacks are sandbox copies. They are not written to immutable, retention-locked storage. You can treat them as working exports.
Immutable evidence archive (opt-in). For approved accounts, an exported ProofPack can be written to retention-locked storage so it cannot be silently altered or deleted; that immutability is part of its evidentiary value. Archived ProofPacks are retained for a fixed period (currently up to seven years) and cannot be deleted before that period expires, even on request, except as the law requires or permits. This is enabled per account only after regulated-data review and an explicit retention acknowledgement, so immutable retention is never a surprise.

Deletion and erasure requests

You can ask us to delete your records or close your account, from the Data and deletion panel in your portal or by emailing brad@privinet.net. Each request is logged and worked by a person through audited states (received, authority verified, deleted where possible, retained under a legal basis, scheduled for deletion after a retention lock lifts, or completed).

We delete what we can from the live service. Where records sit in an immutable evidence archive under an active retention lock, we cannot delete them before the lock expires. In that case we tell you which records and the reason, and schedule deletion for when the lock lifts, rather than claim a deletion we did not perform.

What we do and do not claim

Lumra produces tamper-evident, independently verifiable records: signed at intake, with alteration detectable on verification using a standalone tool you run yourself. It is designed to support Federal Rules of Evidence 902(13) and 902(14) authentication. It does not prevent incidents, give legal advice, or guarantee that any record will be admitted in evidence or that any claim or lawsuit will succeed. Whether evidence is admitted is always a decision for the court.