What workload code is running?

From workload ID to source code

A workload ID is a hash of eight TDX measurement values. It cannot reveal the code on its own. Verification follows the saved evidence backward, checking each link from that ID to the exact workload and its source.

1. Start with an on-chain workload ID

   Choose a workload approved for the capability you care about, such as HTTP jobs, or begin with a registered executor. Enter that workload ID above to inspect its provenance record.

2. Look up the TDX measurements

   Retrieve the eight TDX measurement values stored for the selected workload ID (from the provenance record). Hash them in the order below and check that the result equals that workload ID.

   workload_id = keccak256(
       mrTd ||
       rtMr0 ||
       rtMr1 ||
       rtMr2 ||
       rtMr3 ||
       mrConfigId ||
       xFAM ||
       tdAttributes
   )

   || means concatenating the raw bytes of each field in this order. A matching hash confirms that these eight values correspond to the selected workload ID.

3. Reproduce the OS + Docker → TDX measurements

   Combine the verified OS image, digest-pinned Docker images, Docker configuration, and provider-specific TDX boot profile. Recompute the TDX measurements, confirm this matches the expected eight fields from the provenance record.

   For Phala, dstack-mr calculates measurements from an existing published dstack OS release and VM configuration. For Ritual mkosi, one offline process rebuilds and verifies the published guest image, while a separate GCP calibration supplies the firmware, machine configuration, and RTMR0 baseline needed by the pinned cvm-measure tooling. Neither measurement calculation requires the user to own a TDX machine.

4. Verify each GitHub attestation

   For a given Docker compose, connect each image digest to its source code through Github attestations. This gives the source repository, commit, and expected build workflow.

5. (Optional) Rebuild the OS image

   Both Phala and Ritual mkosi support reproducible OS builds. Rebuild the OS image from the recorded source revision and pinned build inputs, then compare the resulting image with the one identified in the provenance record.

   We leave this independent rebuild to users as an optional offline process because OS builds take substantial time, compute, and disk space, making them impractical to repeat for every website lookup. For Phala, use reproduce.sh and Phala’s platform verification guide. For Ritual mkosi, use the recorded VM source and reproducible build instructions.

6. (Optional) Source audit and capability review

   You can then review the application, OS, dependencies, and build instructions, and decide whether their behavior is safe and appropriate for the assigned capability. Governance’s approval records its judgment; provenance supplies the evidence for your own review.

What this verification establishes

Read the result for each evidence link. A mismatch means the claimed inputs disagree; incomplete means required evidence or a dependency is unavailable; unsupported means the verification path is not implemented. Successful provenance verification connects the measured workload to its claimed artifacts and source. It does not establish that the source is safe.

Quote authenticity and freshness are checked through Ritual’s separate attestation path. On-chain capability approval is a governance decision. This provenance lookup does not itself validate a quote or confirm a current capability binding.

Docker build provenance relies on GitHub’s signed build attestations. For Phala, this site measures the published OS release; the optional rebuild above lets you independently check its connection to OS source code.

Phala references: application verification and dstack verification.

From on-chain workload ID to source code

A Ritual workload ID commits to eight TDX measurement values describing a measured platform and workload. Its provenance record connects those values to a base VM and runtime configuration, the configuration to exact container images, and those images through build attestations to source revisions. Each link answers a different question; no single link establishes the whole connection.

This guide explains how to inspect those links and independently check the evidence. The website displays stored provenance results and evidence. Selecting a workload on-chain, checking its capability assignment, independently rebuilding an OS, and auditing source are steps you perform separately.

The chain of evidence

Docker source                    OS source
      |                              |
GitHub build + attestation     Reproducible OS build
      |                              |
Exact container images          Exact OS image
      |                              |
      +---------------+--------------+
                      |
         Docker configuration + platform
                      |
             Eight TDX measurements
                      |
                 Workload ID
                      |
         On-chain capability assignment

Starting with a workload ID means following this chain backward. A hash cannot recover its inputs, so the provenance record supplies the measurements, configuration, artifact identities, and source references needed to check each connection. Independently checking the OS source-to-image link is an optional offline rebuild.

1. Choose a workload ID

Begin with a workload approved for a capability you care about. For HTTP jobs, the capability policy’s getWorkloadsForCapability(HTTP_CALL) identifies approved workload IDs. To start with a particular registered executor, use the service registry’s getServicesByCapability(HTTP_CALL) and select its workload ID.

Several versions can have the same capability without having the same workload ID. A capability assignment represents governance approval for a role; it does not prove that every approved workload behaves identically. Enter your selected ID in the search above.

2. Look up the TDX measurements

Retrieve the eight TDX measurement values from the provenance record and confirm that they hash to the workload ID you selected:

workload_id = keccak256(
    mrTd ||
    rtMr0 ||
    rtMr1 ||
    rtMr2 ||
    rtMr3 ||
    mrConfigId ||
    xFAM ||
    tdAttributes
)

|| concatenates the raw field bytes in this exact order. Hash the decoded bytes, rather than their hexadecimal text representation. A match connects the stored measurement tuple to the selected ID.

All eight fields matter. The Docker image digest is committed indirectly through the measured application configuration and RTMR3. Firmware, the base image, virtual hardware, boot configuration, and TD settings affect the other fields. Checking RTMR3 alone cannot establish the complete workload ID.

3. Reproduce the workload’s TDX measurements

Use the provenance record to retrieve the verified prebuilt OS image, every digest-pinned container image, the measured Compose and environment configuration, and the GCP TDX boot profile. Check artifact digests before using their bytes. Then calculate the expected TDX measurements and compare all eight outputs with the values from step 2.

Tags, branch names, VM names, and deployment names are useful labels. Digests and full source commits identify the exact artifacts and revisions being checked.

Phala / dstack

Phala verification starts with the published dstack OS release identified by os_image_hash, its VM configuration, and the measured application configuration. The verifier uses dstack-mr to calculate expected measurements from these existing artifacts. This tool does not build the OS or container images and does not run as part of the workload.

The published release supplies the firmware and the inputs for Phala’s boot measurement model. VM settings such as CPU count, memory, and QEMU configuration also matter. Reproducing the expected measurements does not require you to own a TDX machine.

Ritual mkosi on GCP

The Ritual VM image supplies the guest disk and boot artifacts. GCP supplies additional platform inputs, including virtual firmware and the boot event log. The image alone is therefore insufficient to reproduce the full measurement tuple.

The mkosi verification path checks the prebuilt Ritual OS image separately from the GCP TDX boot profile. The first connects the published guest disk to its reproducible ritual-images source and build. The second supplies the calibrated Google firmware, machine configuration, and RTMR0 baseline needed by pinned cvm-measure tooling. Measurement verification is available when the isolated measurement worker is configured.

Platform calibration establishes the reference inputs using a real confidential VM. Once the appropriate profile has been accepted, users can reproduce measurements offline without launching their own TDX machine. A different machine type or firmware requires an appropriate accepted profile.

4. Connect container images to source with GitHub attestations

For every image in the measured Docker Compose configuration, verify the GitHub build attestation for its exact digest. Check the source repository, full source commit, and expected build workflow. Repeat this for every container; a valid attestation for one image does not cover the others.

A readable tag can accompany the digest, for example repository:tag@sha256:digest, but the digest is authoritative. An attestation for a different digest does not establish the connection to the measured workload.

Independent verification of private source or attestations requires the corresponding GitHub access. If that evidence is unavailable to you, a displayed verification result remains a report from the verifier rather than a check you have independently repeated.

5. (Optional) Rebuild the OS image

Both Phala and Ritual mkosi support reproducible OS builds. Use the recorded source revision, build instructions, and pinned inputs to rebuild the image, then compare it with the OS artifact identified in the provenance record. This checks the source-to-image connection independently of reproducing measurements from an existing image.

We leave this independent rebuild to users as an offline process because full OS builds consume substantial time, compute, and disk space. Repeating them for every website lookup is impractical. Phala users can follow the platform verification guide and run reproduce.sh. Ritual mkosi users can use the recorded VM source and reproducible build instructions.

6. (Optional) Audit the source and capability assignment

Review the application, Dockerfiles, OS, kernel, launcher, dependencies, and build instructions. Decide whether that code is safe and appropriate for its assigned role. For example, approving HTTP_CALL expresses a judgment that the workload is suitable for handling HTTP jobs.

GitHub attestations connect an image to its source and build workflow. Reproducible builds connect source to an image. Neither establishes that the code is secure. Governance approval expresses a policy judgment that users can independently assess.

How to read the results

The site reports an overall status and individual verification edges. Inspect each edge’s status, reason, and evidence to understand what passed and what remains unresolved.

Trust boundaries

• Quote authenticity, hardware identity, collateral, revocation, freshness, and report-data bindings belong to the separate attestation path. If you start from a quote, validate it there before deriving a workload ID for this lookup. Different valid quotes can contain the same measurement tuple.
• GitHub build provenance relies on GitHub’s build and signing infrastructure. An attestation establishes which source and workflow produced an image, rather than independently reproducing that build.
• Phala measurement verification uses the published OS release. Independently checking that release against OS source is the optional rebuild described above.
• Artifact digest checks protect integrity. Registries and evidence hosts must still make the required bytes available.
• Capability assignments are governance decisions and can change over time. This lookup does not confirm a current on-chain capability binding.
• Unmeasured secrets, external services, models, data, and mutable network responses are outside the code identity unless separately committed and verified.
• Provenance establishes connections between measurements, artifacts, and source. Human review determines whether that source is acceptable.

Further reading

• Phala application verification
• Phala platform verification and OS reproduction
• dstack verification