Munitas
A governed data platform that can prove what happened to your data.

1. Registers a new dataset, naming the department that owns it and where the data came from. The registration is refused if the department does not exist or the origin is left unstated.
2. Loads the data in, either by uploading files or by importing from HuggingFace. The import runs in the background, so the screen responds immediately no matter how large the source is.
3. Seals the version once loading has finished. The system refuses to seal it while an import is still running, so a version can never be sealed halfway through arriving.
4. Uploads recordings for de-identification and seals them as recordings rather than as anonymous files. The platform reads each one and tells Devi its length and sample rate, so a truncated file is refused as it is added instead of surfacing later. If the set is incomplete, sealing is refused with every problem listed at once and nothing is sealed.
5. Starts the de-identification personally, from the screen where the recordings were just sealed, instead of asking whoever has a terminal on the machine that does the work. Devi is refused, in writing and before anything starts, if the version holds ordinary files rather than recordings, if a recording arrived without the answer key the scoring needs, or if nothing is running to do the work. A refused start leaves nothing behind to clean up.
6. Follows the run on its own page while it happens, step by step, rather than waiting without knowing whether it is working or stuck. At the end Devi is told it is waiting on a reviewer, and that Devi cannot be that reviewer, because Devi is the one who started it.
7. Does not read the sensitive data the pipeline later produces from it. Running the loading process does not grant access to the results.
8. Starts the triage agent against the review queue the pipeline left behind. Devi opens the agent, picks that dataset version, and says what the run is for.
9. Is told before starting that the agent cannot read that data, which custodian would be asked, and that the request will be filed in Devi's name. Nothing is asked of anybody until Devi confirms.
10. Sees the run listed as waiting for data access rather than as running. It has not begun, the screen does not pretend otherwise, and it moves only when the custodian decides.
11. Registers an agent for a department and proposes a level for it. A new version that would let the agent do more waits for the approvals its level asks for, and nothing is deployed until they have said yes.

1. Requests access to one specific dataset version, stating what the work is for and why it needs that data. Blanket requests for a whole department are not possible.
2. Waits for an approver of the department that owns the data. Only the approvers of that department can say yes, and any one of them can.
3. Asks the system for access once approved. It checks whether the role already allows this, and if not, whether an approved and still-valid grant covers it.
4. Receives a credential for their own organisation's storage only, and only after the decision has been written to the audit record. A credential that rests on an approved lease opens that one dataset version and stops working when the lease ends.

1. Opens the datasets an organisation has published and works with them. Published is the least restricted of the five sensitivity levels.
2. Has no power of its own beyond reading published data. To see anything more sensitive, asks for access to one dataset version and gives the purpose, like anybody else, and an approver of the owning department decides.
3. Cannot approve a request to read data, register code, or decide whether a de-identified result may be released.

1. Checks claims about how sensitive a dataset is. If whoever registered it said the data is less sensitive than the cautious default, an approver of the owning department has to agree before that claim takes effect. A custodian may also bring data in, but never confirms their own claim: another approver of the department does, and a claim made by a department's only approver waits until a second approver has been added.
2. Reviews access requests for Cardiology's datasets. Each request names a specific dataset version, what it will be used for, and why that use needs this data.
3. Is refused when trying to approve a request for Radiology's data, because Okonjo is an approver of that department and Hartley is not. Ownership is what grants the authority.
4. Approves or refuses. Hartley cannot approve a request of their own, or one somebody filed on their behalf. Both the policy engine and the database enforce this independently.
5. Sees a written reason with every refusal, naming which rule caused it, rather than only an error code.
6. Sees requests made for an agent in the same queue as requests made for a person, showing which agent will read the data and which engineer asked for it. Approving one starts the waiting run; refusing it closes that run with Hartley's reason attached, so nothing is left waiting on a decision that has already been made.
7. Manages who the approvers of Cardiology are. Hartley can add a person who already holds the data custodian role, give temporary cover that ends by itself, or remove an approver. Every change needs a written reason and stays in the history, and at least one permanent approver who can act must always remain.
8. When an organisation is being closed down, its custodian can still cancel during the first 15 days. When records are produced for a legal matter, the custodian named by the legal hold confirms what the package covers.
9. Agrees to the first version of an agent owned by Cardiology, with the AI risk owner confirming its level. A version that adds only tools on the approved list needs at most the department that owns the agent.

1. Opens a queue of finished pipeline runs waiting on a decision. Each one shows what the run scored, what the check recommends, and why it recommends it.
2. Reads the identifiers that survived redaction, one row each: which record and which character positions it sat at, what kind of identifier it was, how much of it was removed, and how it failed. This is the material the judgement is made on, so it is shown rather than summarised into a score.
3. Promotes the result, or holds it back. Either way Imani writes a reason, and neither is possible without one.
4. Cannot decide a run Imani started. The database refuses it, not only the interface.
5. Is the only role that may make this call. A custodian owns the data and would be judging their own department's output; an administrator operates the system and holds no standing access to what it protects; and the data protection officer is the one later asked whether the release was sound, which is not a question you can answer about your own signature.
6. Is under no deadline, and neither is the queue. Nothing expires, escalates or promotes itself while a decision is outstanding.

1. Reads every access decision the platform has recorded, both grants and refusals, across every department and customer Nakamura is responsible for overseeing.
2. Reads no more of the underlying data than any other member of staff. Being able to review decisions is kept separate from being able to see what those decisions were about.
3. Cannot approve access requests. This keeps the oversight independent of the decisions being reviewed.
4. Writes the organisation's de-identification standards. Imani chooses one when deciding a release, and a later change to a standard never changes what an earlier decision says.
5. Can suspend an agent, and makes an evidence pack for an auditor: what the platform holds about one agent over a period, with no personal data in it.

1. Writes the organisation's risk levels, a short list that says how strictly each kind of agent is held: whether a change needs a second approver, how often the agent must be confirmed again, and whether it may be deployed at all. Every change is saved as a new version with who made it and why.
2. Confirms the level of each agent, together with the first version, after an approver of the owning department has agreed. A first version is always decided by people.
3. Writes the list of tools the organisation has approved in advance, each with the highest risk level it is approved for, the conditions it is approved under and a date to look at it again. A version that adds only listed tools is approved in advance.
4. Can suspend an agent.
5. Reads no more data than anyone else, and cannot approve access requests.

1. Reads the evidence of how locked data was used: who read it, who was refused, and which keys were opened. The evidence holds no names and no values.
2. Makes the evidence pack of an agent and checks that its records have not been changed.
3. Can ask for a short, approved lease to see the real values of locked data, for a stated purpose. Somebody else approves it.
4. Can report an incident about an agent. Cannot approve a request to read data, so that the checking stays independent, and cannot register code or decide a release.

1. Reads the outside hosts that a new agent version declares it needs to call.
2. Approves or refuses each host and writes the reason. An approved version can then be deployed, and a refused one cannot.
3. Cannot decide a version that Joaquin uploaded personally, cannot approve a request to read data, and cannot register code.

1. Keeps the platform running: starting services, monitoring jobs and traces, and freeing up storage. The last of these is done from a screen rather than from a shell: what each organisation is using, on which storage backend, what can be freed, and a rehearsal of exactly what a clean-up would remove before anything is removed.
2. Closes a customer account when the relationship ends, in two stages. For the first 15 days the account is read-only, and the organisation's custodian can still cancel. For the next 15 days it is closed. After that everything inside it is deleted, unless a legal hold stands, and only a short record that the deletion happened is kept. A legal hold is recorded by one administrator and approved by a different one. Records for a legal matter are produced the same way: one administrator asks, a different one approves, and the custodian named by the hold confirms the scope. Nobody reads the records themselves, because the result is an encrypted, signed package.
3. Holds the most powerful account in the system, and deliberately has no standing access to the data it protects and no ability to approve access requests for anyone, Priya's own included.
4. Cannot change who holds which role, either. Anybody may ask to hold one and somebody else decides it, so the account that runs the system is not also the account that decides who may read what. The role that administers roles cannot be obtained from the running system at all: a second administrator is made the way the first one was, deliberately and from outside.

1. Works from telemetry about how the platform is running, never from records.
2. Sees the storage housekeeping record of every organisation, which names no data.
3. Cannot approve a request to read data, and cannot reclaim storage or close down an organisation.

1. Works through six steps to strip personal information out of audio recordings: transcribe, detect identifiers, hand off for human correction, replace the identifiers, measure what was missed, and write down what it found for a reviewer to decide on. Names in the transcript are replaced with consistent substitute names, and the matching stretch of audio is overwritten with low-level noise of the same length, so the timing of the recording is kept.
2. Saves its progress after each recording while it transcribes, which is the slowest step, so a transcription that fails partway through resumes rather than starting again.
3. Is the only account that reads raw, unredacted data, because removing personal information from raw recordings is exactly what it exists to do.
4. Records whether each run was started by a person or by a schedule, so there is never any doubt about what set it off.
5. Releases nothing, whatever it scored. Its last step records what it found and the pipeline ends there, waiting on a reviewer, whether the score passed the standard or not.
6. Gives every step of a run the same identifier, so a run that grows into more than one workflow is still one traceable execution rather than several unrelated ones.

1. The derivation runner executes the query that makes a new dataset, inside an isolated container with no network connection and no passwords. The platform checks the result before the new dataset appears.
2. The table worker writes large tables in the background as a job, so the screen responds at once however large the table is.
3. The closing sweep runs on a schedule and moves an account that is being closed down from one stage to the next when its date arrives. An account under a legal hold is not deleted.

The job it does. When the pipeline has finished detecting personal information in a batch of recordings, it leaves a queue of transcripts for a person to check, because a missed identifier is a leak and only a human confirmation closes that risk. The queue is normally far longer than reviewers can work through in a day. This agent reads each waiting transcript and ranks it high, normal or low with a one-line reason, so the riskiest are checked first instead of whatever happens to be at the top of the list.

A transcript in that queue looks like this, with the identifiers still in place because that is exactly what a reviewer is there to confirm. The name and the date of birth are invented:

clinician: Right. Let me pull up the notes. Eoghan Bell, born 12 February 1965, is that correct?

It produces a judgement and nothing else. It cannot release data, change anyone's permissions, or read a dataset on its own authority.

1. Is deployed as one specific sealed version, identified by the exact code it contains. Deploying a newer version while a run is in progress does not change which version that run is using.
2. Cannot read the review queue by default. The queue holds unredacted transcripts, so it is held at the most restricted level, and this agent is trusted only with published data.
3. Gets access the same way a person would. Starting a run against data it cannot read files a request naming the agent as the reader and the person who started the run as the one who asked. The custodian who owns that data approves it, and that approval is what sets the run going.
4. Runs under an identity held by the surrounding program, not by the AI model. An instruction hidden in a transcript cannot change the identity its permissions are checked against.
5. Raises any document that appears to address it to high priority, rather than doing what it says. Text aimed at the reader is itself a reason for a person to look at that document.
6. Stops before its final step and reports that it is waiting for sign-off, rather than reporting success it has not earned. A different person accepts the findings, and the paused state is stored so that can happen days later.
7. If it runs sandboxed rather than natively, and its version declares it needs a copy of the data, fetches that copy itself over an isolated network only after the same access decision above has been granted, capped at a fixed size before a single byte moves.