Evidence: Same software

One release. A governed identity in each environment.

A vendor's product runs in our estate and in theirs. Is that one identity or two?

  • 3Claims on this page
  • 6Artefacts behind them
  • 3Reads you can run here

Back to Same softwareEvery claim on this site

One release, two governed identities

Your own infrastructure

Tarnbrook Financial Group operates it

Declared artefact digest
sha256:9c1f…9887
Listed by
The Tarnbrook authority
Policy on its envelope
value
It asks for
records.read transfer.status review.submit
Envelope
records.read records.annotate review.submit

The publisher's platform

Quillon Software operates it

Declared artefact digest
sha256:9c1f…9887
Listed by
Quillon's root
Policy on its envelope
subset_of
It asks for
records.read transfer.status transfer.initiate
Envelope
records.read transfer.status

Both agents name one signed release record.

Each agent, in full

Their superior, their policy operator and their envelope differ.

Quillon signs that record for Balance Monitor 2.4.0, and both entity configurations name it by its digest. The record declares an artefact digest, a software bill of materials and the tools the release offers. The digests are declared rather than computed: no artefact is served at the address the record names on this estate. Read on the wire on 29 September 2026, both configurations carry the same record_digest and the same artefact. The two instances are served by different programs on this estate, and they run different tasks, so the record is what they share.

Your own infrastructure

Callum Reid stands an instance up from the Tarnbrook catalogue. The Tarnbrook authority lists that agent directly, and the agent signs with private_key_jwt on a key Tarnbrook holds. It asks for records.read, transfer.status and review.submit. Two value rows replace that ask: tarnbrook.records.reader gives it records.read and records.annotate, and tarnbrook.review.caller gives it review.submit, which lets this agent ask the Batch Reviewer to review a batch. So transfer.status is dropped and records.annotate is added. The token carries no assurance claim, because the platform admits an identity rather than an instance.

The publisher's platform

Yusuf Demir operates a second instance at Quillon, as a service. Quillon's own root lists that agent, and the Tarnbrook authority recognises that root, so the only chain from Quillon's agent to the Tarnbrook anchor passes through the recognition hop. The agent signs with private_key_jwt on a key Quillon holds, and its token carries no assurance claim either. It holds neither Tarnbrook role the other agent holds.

Where each policy sits

Your own infrastructure

  1. The agent
  2. Listed directly
  3. On the statement about the agent value

    • records.read
    • records.annotate
    • review.submit
  4. Tarnbrook authority
  5. Tarnbrook anchor

The publisher's platform

  1. The agent
  2. Quillon's root
  3. On the recognition hop subset_of

    • records.read
    • transfer.status
  4. Tarnbrook authority
  5. Tarnbrook anchor

Quillon's agent asks for

  • records.read
  • transfer.status
  • transfer.initiate

The ceiling on the hop subset_of

  • records.read
  • transfer.status

The resolved envelope

  • records.read
  • transfer.status
  • transfer.initiate Dropped

The ceiling sits on the authority's statement about Quillon's root, so it covers every agent under it.

How each policy folds a claim

A value row replaces what the leaf asks for, so it can add a type as well as drop one. A subset_of row keeps only what the leaf asks for and the row allows, so it can only drop.

Quillon's agent asks for records.read, transfer.status and transfer.initiate. The row on tarnbrook.external.reader allows records.read and transfer.status. Resolved at the Tarnbrook anchor on 29 September 2026, the envelope is those two, and transfer.initiate is gone. The chain has five statements, one more than the Tarnbrook agent's four, and the extra one is the hop.

One record for every agent from the publisher

Quillon Software The publisher

  1. Publishes its root
  2. Holds the root key
  3. Signs the release record
  4. Lists its own agent

Tarnbrook Financial Group The operator

  1. Recognises the root
  2. Sets the hop's ceiling
  3. Grants the role to Quillon

A new agent under Quillon's root

Same record, same ceiling.

One recognition record and one ceiling cover every agent that root lists.

Every step, with the record it writes

Quillon Software, the publisher. It publishes an entity configuration at its own address, so an operator reads the root there. It generates the root key and supplies the public half; the private half stays with Quillon. It signs one release record for Balance Monitor 2.4.0. It lists its own agent under that root, so the operator's authority never lists it, and it sets private_key_jwt as that agent's method.

Tarnbrook Financial Group, the operator. It recognises the publisher's root with one recognition record at the Tarnbrook authority. It sets the ceiling on that hop as a subset_of row on tarnbrook.external.reader, bounding it to records.read and transfer.status. It grants that role to Quillon's organisation. It does nothing further for a new agent under that root, because every such agent reaches the anchor through the same record. The instance Tarnbrook stands up itself it lists directly, with value rows of its own.

What this page proves

Each claim, its label and the artefacts behind it.

Delegated accreditation as a Connect control

Observed

Connect refuses a statement claim that references a claim the organisation does not hold, with a 404 that names the referential rule and scopes it to the organisation.

Lifecycle stage
Govern
Lives in
Raidiam Connect
Checked by
Test verification:D
Artefacts cited
2

This claim on the evidence page

The working

What the figures above leave to words.

What it means for the business

One release can run in more than one environment, and the operator changes with the environment. Each instance runs as an agent with a governed identity of its own. Provenance travels with the software. Your authority decides what each agent may ask for, directly or at the hop that admits the publisher.

Where the authority comes from

Recognition is the governed act by which the Tarnbrook authority becomes a superior of an entity that already publishes its own configuration. Quillon generated its root's key and supplied the public half. The Tarnbrook authority recognised that root with one recognition record.

The rows on the role are what the authority publishes as policy, so the ceiling on a recognition hop is a governance record rather than a setting inside a platform. Observed

Connect refuses a statement claim that references a claim the organisation does not hold, and names the referential rule. On this tenant that was read on a scratch statement: a claim the organisation held was accepted, and a fabricated claim and another organisation's claim were both refused. The same rule would refuse Quillon a role it holds no grant of. That attempt was not made on Quillon's record. Observed

Ten terms
anchor
The root entity of a trust domain whose key a consumer pins from configuration.
authority
A Connect entity that publishes signed subordinate statements, marks and policy about the entities it governs.
trust domain
The set of entities that chain to one anchor.
entity configuration
The self signed statement an entity publishes at its own identifier.
subordinate statement
The statement a superior signs about a subordinate: keys, policy, marks.
trust mark
The signed projection of an active accreditation, with a status endpoint.
envelope
The set of authorization detail types and grant types an authority permits an agent to request. The registered ceiling.
resolve
Walk the chain from a leaf to a pinned anchor and fold the policy.
pin
The anchor key a consumer holds in configuration, written at deploy time, as the pair of anchor identifier and key.
recognition
The governed act by which an authority becomes a superior of an entity that already publishes its own configuration, minting nothing.

The design requires that the statement about a recognised root vouches only the keys that root publishes. On this tenant the statement about a self managed entity whose organisation holds no key vouches one key, the tenant's hosted entity signing key, which the subject does not hold. Read on 29 September 2026, both of the authority's statements on this page also carry that tenant key. Not observed on this tenant

Other runtimes

This estate runs Balance Monitor 2.4.0 in two places, both self managed. It runs no instance of it on a workload domain or on a workstation. The Batch Reviewer and the Analyst Companion run there, and the runtime use case covers what each of those tokens carries.

Check it against the running estate

Every surface this use case touches, and the host that answers for it.

Quillon's host stands in for a third partyquillon-production-ff3b.up.railway.app The Tarnbrook cataloguecatalogue.agents.showcase.raidiam.io Raidiam Connectweb.directory.showcase.raidiam.io

Which supplier's software runs in both your estate and theirs, and who operates each copy?

Ninety minutes, on the shape of your estate: which systems resolve first, which anchor each pins, and which key each party holds.

Book a working session