Subject requests and the subject pack

Requests are about people, not records. “Everything you hold about applicant 72819” has to be answered with everything, in one place, in a form the requester or their lawyer can check. That is the subject pack.

How to produce one

Open Subjects, find the person or thing (search by id, type or display name), open them, and press Export evidence pack. The archive downloads as stratl-subject-<type>-<id>.zip. Over the API it is GET /v1/subjects/{type}/{id}/pack.

Before you send it, read the subject page: the history of decisions oldest first, the notices and what was sent, the retention state and any hold. If a hold should be in place because a request has arrived, place it first; the pack will record it.

What is inside

Path	Contents
bundles/<decision_id>.stratl/	One complete evidence bundle per record about the subject, oldest first, including Stratl’s own workflow records about them (notices sent, holds placed)
notices/<notice_id>.html	Every notice drafted for those records, whatever its status, with who approved it, how it was sent and whether it was withdrawn
subject.json	The records in order, each bundle’s verification result at export time, the notices with their delivery facts, and the active legal holds
keys/<key_id>.jwk	The public key of every key that signed an included record
keys/public.jwk	The workspace’s current key
manifest.json and manifest.sig.json	Every file with its fingerprint, and a signature over the manifest by the workspace key
verification.txt	How to check all of the above

How the recipient verifies it

Three steps, none of which need Stratl:

1. Recompute the fingerprint of every file and compare with manifest.json.
2. Verify manifest.sig.json with keys/public.jwk. Any JOSE or ECDSA library does this; the signature is ES256 over the canonical form of the manifest.
3. Verify each bundle on its own with the command-line verifier: stratl verify bundles/<decision_id>.stratl. Each bundle carries the public key of the key that signed that record, so old records still verify after a key change.

Building the pack signs the manifest with the workspace key, which is itself a key use and appears in the workspace’s key-usage record.

What is not in it

Original content (prompts, documents) is included only if the source uploaded it. Records from other workspaces are never included; a subject id is scoped to a workspace. The search index’s metadata beyond what is in the records is not included, because the records are the evidence and the index is a convenience.