What workload code is running?

Look up a workload ID and follow its public evidence backward. This site verifies the mechanical provenance links; deciding whether the source is safe remains a human judgment.

1. Workload ID
Choose one workload instance to verify.

2. TDX measurements
Recompute all eight fields that determine the ID.

3. OS + Docker
Combine the published Phala OS release, digest-pinned Docker images, and measured configuration. Measure that combination with dstack-mr.

4. GitHub attestation
Verify GitHub bound each Docker digest to its source commit and workflow.

5. Source audit
Review the human-readable OS and Docker source.

Look up a workload ID

Publication

Authenticated publishers can submit a strict v1 manifest and optional named public evidence through the API. Evidence filenames must equal logical names such as measurement_tool.inputs.event_log. Mismatches and unsupported schemes are rejected; genuinely unavailable evidence is retained as incomplete.

For Phala records, dstack-mr is verifier-side tooling only. It calculates expected measurements from an OS release and workload configuration that already exist; it does not build the OS, build a Docker image, or run inside the workload. This site does not rebuild the Phala OS from source. Anyone who wants that source-to-release check can run it offline with Phala's reproduce.sh.

Trust boundary

The Docker build is not currently deterministic: users rely on GitHub's signed attestation because the exact image bytes produced by that run cannot be reproduced independently. Successful provenance verification does not replace source review.

Rebuilding Phala's OS from source is left to the user as an optional offline process. This site does not perform that check and does not treat skipping it as a trust assumption. Use Phala's reproduce.sh and the platform verification guide if you want that leg.

Phala references: application verification, platform verification, and dstack verification.