How to read this page
- Every step is one screen, or one moment, in a real run. The label under the title names where it happens, and the step reads in the same order each time: what is happening, the evidence, and then what to look for in it.
- Screenshots are real pictures of the Munitas console, the web app that people open in a browser. Click any picture to enlarge it.
- Every name of a person, patient or card holder in the example data is invented, and every screenshot is unedited apart from being cropped to the part that matters.
Words used on this page
- Organisation
- A company or hospital group that uses Munitas. Each organisation sees only its own data.
- Department
- A team inside an organisation that owns some of its data, such as Cardiology.
- Custodian
- A person who holds the data custodian role, which allows deciding who may read data. A custodian decides for the departments they are an approver for.
- Agent
- A program registered on Munitas, with a named owner, that Munitas runs on somebody’s behalf instead of a person reading data directly.
- Version of an agent
- One uploaded and sealed copy of an agent’s code. Uploading again makes a new version, and the older ones stay.
- Host
- The name of a computer on the internet that a program contacts, such as reports.radiology.example. For an agent, a host is an external address that it asks to be allowed to call.
- Egress approval
- A network architect’s decision on the list of external hosts that one version of an agent asks to call. A version that lists hosts cannot be deployed until the list is approved, and a version that lists none needs no approval.
- Network architect
- A role that decides which external hosts an agent version may call. The person who uploaded the version cannot decide it, and neither can a custodian who does not hold this role.
- Deploy
- To make one version of an agent the one that runs when somebody starts a run. Only one version of an agent is active at a time.
- Run
- One execution of an agent or a pipeline, started for a stated purpose.
- Dataset
- A named collection of records, such as a table of patient admissions.
- Claim
- A statement, made by the person who brings a dataset in, about how sensitive it is. A different approver of the owning department has to confirm it.
- Sealed
- Finished and closed for good, so that it can never be edited.
- Version
- One sealed state of a dataset. Changing the contents means making a new version, never editing an old one.
- Fingerprint
- A value worked out from the exact contents of a file. It changes if even one byte changes, so it shows that a file was not altered.
A version of an agent names the hosts it wants to call
An AI agent is a program that works on data on somebody's behalf, with a named owner, under the same rules as a person. Before a new version of an agent can be put to work, Munitas asks one more question: which external computers will this code contact? Those computers are called hosts, and a host is the name of a computer on the internet, such as reports.radiology.example.
Devi is a data engineer in the Health organisation. The agent is called radiology-intake-triage, and it ranks radiology intake documents for a person to review. It belongs to the Radiology department. Each version of an agent is one uploaded and sealed copy of its code, and a sealed version can never be changed. This agent already has one version, version 1, uploaded on the page before this one. It calls no external host.
Devi chooses the zip file that holds the agent's code, says that it calls no model, and opens the part of the form for tools and hosts. A tool is something the agent may do, here reading a version of a dataset. In this example the code needs to fetch report templates from the hospital group's own reporting service, so Devi lists that one host. The form says plainly that a list of hosts has to be approved before the version can be deployed.
Munitas seals the upload as version 2 and records who registered it and the fingerprints of what it holds. Deploying a version means making it the one that runs when somebody starts a run. Because this version asked to call a host, it has filed an egress approval, which is a request for a network architect to decide the list of hosts. Until that is decided, the Deploy button does not work.
Somebody else decides
The list of hosts is decided by a network architect, a person who holds a role of that name. The person who uploaded the version cannot decide it, and neither can a custodian who does not hold the role, even the custodian of the department that owns the agent.
Devi follows the link to the request. The page shows what the version asked for, and a box for the reason behind a decision. The platform does not let the person who uploaded a version decide its hosts, so both buttons are greyed out for Devi, and the page says why.
Okonjo is the data custodian for the Radiology department, which owns the agent, and decides who may read Radiology's data. Choosing which external hosts an agent may call is a different decision, and it belongs to a role of its own. Okonjo can open the request but has no way to decide it.
Turner holds the network architect role, so the home page is about one thing: the requests that wait for a decision on hosts. A tile counts them, and the first of them is listed with the agent, the host it asks to call, who uploaded the version and when.
The same request is on the Egress approvals page, which keeps every request, those waiting and those already decided. Each line names the agent version, the hosts it asks for, its state and who submitted it.
Turner opens the request and reads what the version asked for. A decision needs a reason, written before the buttons work, because whoever reads the decision later will not have this screen in front of them. Turner holds the right role and did not upload the version, so nothing blocks the decision.
The decision is recorded with who made it, when, and the reason, which is kept with the decision. The label changes from waiting to approved. The page also repeats what the approval is: it lets the version be deployed, and it does not claim that any call to the host has been made.
What the decision allows
The decision is the only thing that changes whether a version can be deployed. The same code, with a different list of hosts, can end up on either side of it.
Devi opens the agent again. The label on version 2 has changed from waiting to approved, and the Deploy button, which was greyed out, now works.
Devi presses Deploy. Version 2 is now the active version of the agent, which means it is the one that runs when somebody starts a run. Version 1, which was active until now, stops being the active version and gets a Deploy button of its own.
Devi uploads the same code again as version 3, this time listing files.unknown-host.example, and the version waits for a decision in the same way. A script checked that, and there is no picture of it. Turner reads the request and refuses it, with a reason that says what is missing. The decision is about the list of hosts, not about the code, which is why the same code can be approved once and refused once.
On the agent's page, version 3 is marked as refused and its Deploy button is greyed out. The grey button is not the only barrier: a script asked Munitas itself to deploy version 3, signed in as Devi, and Munitas refused with the reason that this version asks to call files.unknown-host.example, that the request is refused, and that a network architect has to approve it before the version can run. Nothing was deployed, and there is no picture of that check. Version 2 is untouched: it is still the active version, and it still carries its approval.
