Personal data held by plugins
For: tenant admins and governance reviewers.
What plugins keep
A plugin may keep records of its own beyond a job, such as the notes, decisions and definitions of the memory plugin. They are kept by the platform, not by the plugin, so the same rules reach them:
- Erasure.
A record written in a job about a person is that person's: its text is sealed with the job's key, as the job's board is, and reads as erased the moment the key is destroyed.
The erasure then deletes every version written in the person's job trees.
Every later version of such a record goes too, wherever it was written, since a later version can carry the person's text forward (a decision proposed in the person's job and accepted in another job, say): the erasure reaches it whatever the plugin copied, and the person's export lists it.
A version of a record that other jobs also wrote is emptied instead of deleted: its text, labels and author go, its number and state stay, so an older version does not come back in force and no later version takes its number. A record written in a job about nobody is not about anyone the platform knows; whether it names a person is for its writer to judge.
- Retention. Versions older than the tenant's days are deleted, a record's newest version too, even one still in force: a decision accepted longer ago than the tenant's days goes with them, and agents no longer get it at their start.
A tenant whose agents must keep working under older decisions sets a longer retention, or none, or has them written again.
Whether such knowledge may be kept past the days that hold for everything else is a legal question the platform does not answer for you.
- Legal holds stop the deletions, as they do for jobs.
- Exports. The whole-tenant export carries the records, their text only with
--content. - The audit log records every read with the records and versions it returned, and every write, never the text. So "which version of this decision did the agent see" has an answer.
- Keep-for. Retention keeps the records an agent with a keep-for period wrote until that period ends, as it keeps the agent's jobs.
Memory about people
Plugins' records are memory about work or about people. Memory about people (a preference, what someone asked or decided) is off for every agent:
- Whatever a job with a data subject writes counts as memory about people, whatever the plugin says it is, and is refused while it is off. The refusal says why and how to turn it on.
- Turning it on is per agent and purpose, with
oz0 memory person AGENT --purpose PURPOSE --reason ....
The purpose must be one the agent declares, with a legal basis in your lists (oz0 inventory purposes); only the agent's jobs that run for that purpose keep such memory, and only while the basis is in your lists.
It is a governance change: it needs a reason, waits for another admin while four eyes is on, and always does in works-council mode, since the platform cannot tell which people are employees.
- It stays in the agent's own scope unless you share it with another agent, a project or the tenant (
--share). - It ends. Every record ends, on the date its writer gives within your longest end or after your default (90 days unless you change it with
oz0 memory settings set).
A record about people is deleted at its end, every version of it, and an older version is deleted at its own end even while the record is written again, unless the writing agent's keep-for period runs longer; a legal hold stops it.
Records about work stay until retention, out of agents' start-up context and recall after their end until someone renews them.
- It is bound to its purpose. A record carries the purpose of the job tree that wrote it; only jobs of that purpose, or of one you map as compatible, read it, and only jobs of that purpose write it: a job for another purpose never adds to what is kept about a person.
What you must decide yourself: whether to keep memory about people at all, for which agents and purposes, on which legal basis, how long, who may see it, and what to tell the people it is about. The platform enforces what you set; it does not say what is lawful.
Records written before memory had kinds count as about people when their job tree had a data subject and as work otherwise, have no purpose (so only jobs without a purpose read the ones about people), and end 90 days after the upgrade unless renewed.
Retain records and restore backups
Retain records and restore backups for tenant admins and governance reviewers.
Taint and labels
How a job's labels track what it read: outside text taints the job tree, a tainted job asks before tools that can send data out, a quarantine child reads what its parent should not, and label policies withhold, narrow egress, pick models and wall off compartments by label.