Relying parties

A relying party is your customer, or anyone else you answer to, holding each version of your AI system to an evaluation they pinned themselves. The workspace decides every version against their pin beside your own gate, and they pull a decision record of each version and check it on their own machine. They never see your cases, labels or traces, and nothing you do to your own requirement changes their pin.

A record is evidence a second party can check, not a certification.

Invite a relying party

On a hosted project, open Relying parties (in the Assurance group of the command palette, or from Governance). Only an Owner can invite: name the organisation, then send the link it shows you, once, yourself. It works for seven days.

The relying party opens the link signed in with an account of its own organisation. An account that is a member of your workspace cannot accept, and an account that later joins your workspace loses the relying party's pages. Both sides see the email of the account that accepted: check it is the one you expect.

What the relying party does

1. Verify a record you sent. Export one from a governed run's page (Download the decision record) and send it. They run:

``bash oloproof record verify record.json --key KEY_ID=PUBLIC_KEY --workspace-keys keys.json ``

with your runner's public key, which your runner's operator gives them directly, and the deployment's published workspace-statement keys saved from /api/workspace-statement-key.

Once you have your relying party's id (on your page), add --relying-party RP_ID to every later check: a record that is another relying party's, or the provider's own, then fails.

2. Pin the evaluation. On their page they paste the record's evaluation.digest, evaluation.policy_digest and its decided run id. The evaluation digest binds the suite (every case and its content), the evaluators by content, the metric specifications and the policy, so a trimmed suite or a laxer policy is another digest. The policy must be one the workspace has checked. The run is the baseline every comparison rule is decided against, shown on their page, so you cannot choose it by the order you push. A pin is never replaced: a new one is added and the latest is in force.

3. Acknowledge your runner keys. Their page lists every registration and revocation of a runner key of the project, as it happened, from a log nobody can edit. A key counts for their pin only once they acknowledge its registration, so a key you register later decides nothing for them until they have compared its public key with the one your operator gave them. A run on Oloproof's managed workers needs no acknowledgement: you neither register nor rotate that key.

4. Pull every record. The page lists every system version decided against their pin, with each rule's state and a Download link for its record. They pull the records themselves, so they do not depend on the ones you choose to send.

How each version is decided

The worker takes the pinned run as the baseline, once it is verified execution signed by a key they acknowledged, and decides each system version on its earliest start of that evaluation, whichever key signed it and whatever became of it. A failed first run cannot be replaced by a luckier rerun, and a version first started under a key they never acknowledged stays withheld. The rules are decided by the same code as your own gate, at verified execution.

A decision does not outlive what it rests on. If the baseline's key is revoked as compromised, or they pin again, every gate the pin in force no longer decides is withheld (MANUAL_REVIEW) with the reason. A key counts only with the public key they acknowledged, and a run on Oloproof's managed workers only under the deployment's own key.

What their record adds

A record exported for a relying party carries, in the workspace's signed statement:

• the relying party it is for, and its pin as the requirement;
• every start of the version on the evaluation, each with the runner's own signed request, which record verify checks against the keys they give;
• the key log of every key that signed a start or a run of the version: its public key, registration, acknowledgement and any revocation.

record verify fails the record if a signed start does not hold or names another run, version, suite, workspace or project, if a logged key's public key is not the one they gave, if a passing gate rests on a key they did not acknowledge or one logged as compromised, or, with --relying-party, if the record is not theirs or its statement is not signed by a workspace-statement key they gave. Without --relying-party, a statement that is not signed reads not checked, never verified. Its exit codes are unchanged: 0 when every check that could be made passed, 5 when one failed, 2 when a key or file cannot be read.

What it cannot tell you

• That the account which pinned and acknowledged belongs to the relying party: the email is shown, not proved.
• That the runner ran only code its operator controls, or that the version evaluated is the one serving production.
• That the evaluation is the right one: choosing the suite is still the provider's, unless the relying party supplies the suite or pins a traffic evaluation drawn from production.
• Anything said after the export: a record is the workspace's word as of its export time; pull a fresh one when in doubt.
• Nothing after the operator ends the relationship. You cannot end it: a project, or your account as its workspace's last Owner, cannot be deleted while a relying party is attached. Still, pull each record as it is decided.
• A PPI interval: the labels behind a human sample are not in the record.