Raidiam
Book a working session

Evidence

Every capability we claim. Labelled, and linked.

Each capability this site claims for the product, in the lifecycle stage it belongs to, with one of four labels. Press one to read what it cites, and what that does not show.

Read every claim Inspect an artefact

  • Observed
  • Deployment evidence
  • Available
  • Not observed on this tenant

Govern

3 claims

Discover

4 claims

Revoke

1 claim

Keys

6 claims

15 distinct addresses cited. 2 trust domains. Press a claim to read what it cites.

Every claim, and what supports it

14 claims. Open one for its artefact, the request that reads it, and what it does not show.

Govern

Discover

The design requires that a consumer pinning a scheme's anchor for marks can ask the enterprise authority whether it recognises that scheme as an issuer of accreditation marks. On this tenant the mark endpoint refuses a subject that is an authority, so the recognition record the estate declares cannot be read. Every consumer that pins a marks anchor therefore fails closed on a leaf reached through an accredited root, which on this estate is the API platform and the workforce platform. Until this changes, an external party's agent resolves at the enterprise authority and is refused at the enterprise platform, and no page may say that platform admits it.

Revoke

The design requires that a withdrawn accreditation stops being issued as a mark and answers not active from the status endpoint within the mint cadence. On this tenant the generated entity configuration and the authority's list drop the accreditation within a minute, while the mark endpoint keeps issuing the mark and the status endpoint keeps answering active. Until this changes, a consumer treats a mark as valid only while the subject is on the issuing authority's list and the subordinate statement carries the role's policy.

Keys

The design requires that each trust domain's anchor is signed by its own key. On this tenant both anchors sign with one federation key and both authorities sign with one authority key. The two trust domains are separated by entity identifier and governance record, and a consumer's pin is the pair of entity identifier and key, so a chain to the wrong anchor is refused on the issuer. Cryptographic separation is absent: the holder of the shared key can mint a statement in either anchor's name, and on this tenant that holder is Raidiam in both cases.

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. In the entity generated model the subject holds its own private key and Connect does not receive it. The key this statement vouches is the tenant's hosted entity signing key, which Connect adds by product behaviour rather than from anything the subject supplied.

Inspect an artefact

6 components. 3 publish an artefact this tenant serves; the rest say so.

The browser fetches an artefact and decodes it. It holds no key a superior vouches and it walks no chain, so nothing here checks a signature.

Agent

Read from the running estate when this opens

Discover

Agent identity

The entity configuration the agent publishes at its own identifier

Proves One organisation under two authorities

Published byrp.directory.showcase.raidiam.io
Last read on the wire2026-09-09
Read in your browserwhen this card opens
How it is supported Observed

Which claim on this page would you want to read off your own estate, and against which anchor?

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

Explore further

curl -s -H "accept: application/json" "https://www.agents.showcase.raidiam.io/evidence"

Reads the showcase tenant of Raidiam Connect.