Trust model · 01
Classified before it exists
Sensitivity is decided before the submission is persisted. A sensitive intake is
sealed at the moment of arrival: content is encrypted to the named recipient's
key, and no tracking reference is returned to the shared device it was submitted
from. There is no window in which a sensitive case sits readable in a queue.
Trust model · 02
Sealing is server-side and immediate
When a case is sealed — at intake or later, during review — access is revoked on
the server before anything else runs. Open sessions are pushed a notice; an edit
in flight is refused and logged. The submitter sees only that a restricted case
exists. Sealed content, the raw payload and attachments all move under the
recipient's key; watchers are purged.
Trust model · 03
Named people, not just roles
Sensitive cases route to a named recipient and a designated backup, so cases never
sit unread when the recipient is absent — or implicated. Admins can reassign the
role but cannot read content themselves; every reassignment is logged and notified.
If a case names the recipient, routing escalates to the next level automatically.
Trust model · 04
Nothing rewrites the record
Every case carries a complete, ordered accountability trace — received, classified,
assigned, viewed, edited with before-and-after values, referred, responded, closed.
It is append-only and hash-chained, verified nightly and anchored. No role can
edit it or delete it.
What the person who reported gets
“Every case must be closed with a response to the community.”
Submitters return with a tracking code and PIN — no account required. They can
view and edit their own submission and follow its accountability trace as it is
worked. If their case is classified as sensitive, they are told a restricted case
exists, with no details, and their access ends there — which is the only honest
thing a system can do for them.
Closing the loop is not a report someone generates at quarter end. It is the last
required step of every case.