--- title: "Find and export personal data" description: "Find and export personal data for tenant admins and governance reviewers." canonical_url: "https://docs.oz0.ai/govern/personal-data/export" --- # Find and export personal data > Find and export personal data for tenant admins and governance reviewers. For: tenant admins and governance reviewers. ## Find what you hold ```bash [Terminal] oz0 subject find alice@example.com ``` ```text [Output] Subject hash: 8e71c42de9472845a912a7b270e1add4ea7a193a6d1c8c70ca22283c35f076a5 Keys: 2 live, 0 destroyed Audit entries: 7 (0 redacted) Jobs: 2 job-2b39f8cf-0ab4-47d9-9252-fc67fb848fc0 2026-10-03 06:35 readable support job-71c0e2a4-5d6f-4c35-9a0e-3b8f0d7c1e55 2026-10-04 09:12 readable bookkeeper keep_for 7y until 2033-10-06 09:12 ``` It also lists the person's [restrictions and objections](https://docs.oz0.ai/govern/personal-data/restrictions-and-contests#restrict-and-object), how many [decision records](https://docs.oz0.ai/govern/personal-data/restrictions-and-contests#decision-records-and-contests) their jobs have, and an erasure that waits for a second person, including those recorded under the spelling's hash from before identifiers had one normal form. Each job shows its agent, what keeps it (an agent's [keep-for period](https://docs.oz0.ai/govern/personal-data/retention#keep-what-a-law-asks-you-to-keep)), whether it is `readable`, `deferred` (an erasure waits for its period), `erased`, or `off` (started while [erasure was off](https://docs.oz0.ai/govern/personal-data/erase#the-erasure-policy)), and how many people it is about. After an erasure that deferred jobs, `Keys` counts the person's keys that are kept only for those jobs as `closed`. `job get` and `job trace` on those jobs show what they hold. In the console, the Data subjects tab of **Govern → Privacy** shows the same. ## Give a person their data You need `subjects.find` and the content permission to export a person's data. Check that `--account`, if used, names that person's account: a wrong link puts another member's chats in the bundle. Export the bundle, verify it, then review its omissions before handing it over: ```bash [Terminal] oz0 subject export alice@example.com --out ./alice oz0 subject export alice@example.com --tar alice.tar --account alice oz0 subject export --verify ./alice --key ``` The bundle is a folder (or a tar file) you can hand over:
File What it holds
index.html everything below as one page to read in a browser; it loads nothing from the network and runs no script
subject.json the person's jobs with their agent, start and the date each is kept until; erasures with the jobs a keep-for period keeps and why; restrictions and objections; decision records and contests; the purposes the jobs named, each with the tenant's legal basis and its description
audit/entries.jsonl the audit entries about the person
recipients.json for each agent that ran a job about the person, where it can send data ( recipients ), as its records say today
content/jobs/ each of the person's jobs, child jobs included, with what it was started with, its steps' inputs and outputs and its answer, the tenant's secrets redacted in every form a job's content can hold them; a job whose own input and answer could not be read says so in its entry and in not_included
content/board/ the notes agents pinned to the boards of the person's job trees
content/records.jsonl the records plugins (such as the memory plugin) kept from those job trees
content/chats/ the chats of the person's own account, when they are a member
manifest.json , manifest.sig , content/manifest.* , keys/ every file's size and SHA-256, signed with the cluster's audit key and the edge's gateway key
How it is made: an edge reads what the person's jobs read and wrote, their boards, records and chats, which only edges can open, and signs what it read; management adds its records, checks the edge's signature, and signs the whole. `--verify` checks a bundle anywhere, without the cluster or the network: both signatures, every file, nothing missing or added. Pin the audit key with `--key` and the fingerprint `oz0 audit key` prints, handed over by another channel. What it holds and what it does not: - Chats: the bundle holds the chats of the account that is the person, read as that account may read them. A member whose sign-in name is the person's ID (often an email address) is linked by itself; `--account` names another, and the export's audit entry records which account was linked and how. Reading those chats is a read of someone else's chat like any other: each is audited as `conversation.view.private` with the export as its reason, and the account's owner sees it. Check the link before you hand the bundle over: a wrong `--account` puts another member's chats into it. - Another member's private chat about the person is listed without what was said, as everywhere else. The board notes and plugin records of such a chat's job trees are left out too, and `not_included` says how many. Whether the person's copy should hold it is a legal question the platform does not answer. - Staff appear by role, never by name: audit entries name the kind of actor (`user`, `apikey`, `system`), and so do the fields of their details that say who acted (who approved a step, who asked for a change), the jobs' records (who exported them, who decided their approvals) and the bundle's own "made by". Decision records name who took part by role. The person's own account stays named. What a job read and wrote is the person's data and is in the copy as it was written, so a name someone typed into a job's input is there too. Whether that is right for your copy is a legal question too; the audit log keeps the names for those who may read it. - Walls: the [walls](https://docs.oz0.ai/govern/taint-and-labels/label-policies#walls) of the tenant's label policies hold for the person who makes the bundle, and, for the account's chats, for that account too. A job, a chat's turn or an audit entry's private part a wall closes is in the bundle without its content, marked as withheld by a wall (`walled` on an audit line, a note on a chat). A board note or a plugin record a wall closes, by its job tree's compartments or by its own, is left out, as the board and the records route leave it out, and `not_included` says how many. An audit entry's private part is decided by the job's compartments when the entry was recorded, so one written after its job joined a walled compartment is withheld too. A bundle made by someone the walls do not apply to holds it. - Jobs past Temporal's history retention are listed with what management keeps of them, and the bundle warns that what they read and wrote is gone. - An erased person's bundle holds the erasure's record and the redacted audit entries' count, nothing of their jobs. - A job about several people is in each of their bundles whole, with the others' data in it. It needs the `subjects.find` permission and the content permission (a tenant admin with content), and is audited about the person (`subject.export`, `subject.export.content`), so erasing them redacts the entries too. Whether the bundle is a complete answer to a request is for you and your data protection officer to judge. ## Exports A person's own copy is their [bundle](https://docs.oz0.ai/govern/personal-data/export#give-a-person-their-data). A [whole-tenant export](https://docs.oz0.ai/admin/tenant-export) carries people's data the tenant holds: who started, owned and decided jobs, members and teams, audit entries' actors, and with `--content` what jobs read and wrote. It is audited, and its content needs the content permission. What erasure took stays out of it: an erased subject's jobs are left out of the tables and of the jobs' content even before the edge has deleted them, their audit entries are exported redacted, and their erasure is exported as a record that names a hash, never the person. Someone else's private chat is exported without what was said unless the exporter gives a reason, which is audited per chat and shown to the chat's owner. ## Sitemap See the full [sitemap](https://docs.oz0.ai/sitemap.md) for all pages.