Opaque execution
AI workloads cross providers, operators, and recovery paths. A result without durable commitments makes later review, dispute handling, and settlement harder.
01 / Why SDDT
Compute value is only as strong as the evidence behind it.
SDDT Verified Compute is a verification-first evidence and settlement layer for distributed AI/GPU compute. It is designed for teams that need to know what ran, what was verified, and what can safely settle—without treating an execution claim as proof by itself.
Runtime Execution Evidence
Bind the job, approved workload, execution record, verification policy, and settlement decision into a reviewable sequence.
Claim discipline
Separate what is cryptographically checked today from what still requires fresh provenance, independent review, or production authorization.
Technical comparison / scope boundaries
Different controls address different trust questions.
This is neutral technical positioning, not a superiority or replacement claim. The systems below have distinct roles. SDDT is a proposed complementary layer that describes a path from bounded intent through authorization and verification toward settlement; it does not replace the capabilities of these tools.
Sigstore & in-toto
Sigstore supports signing and verification for software artifacts. in-toto describes software supply-chain steps and attestations. SDDT now has a bounded local in-toto Statement v1 / DSSE format integration; it does not have a Sigstore, Rekor, or Fulcio integration or a verified supply-chain layout.
What SDDT adds around these tools: a custom SDDT evidence predicate and a verifier that checks the subject and claim limits against separately supplied expectations, rather than treating a valid signature as sufficient. The implemented adapter exports a hash-pinned synthetic expected-output reference using the actual in-toto/securesystemslib libraries and an ephemeral Ed25519 signer. The original eight focused adapter tests and local export plus separate verification passed, including an independent Ed25519/DSSE signing-input check. Input hardening is confined to bounded local file reads and JSON nesting checks, not a public verification service. This proves local format, signature and expected-reference verification only—not workload execution, provenance or publisher identity. Identical valid envelopes can verify again; replay prevention is not established. Qualified reviewers can request the reproduction pack and supply their own trust expectations through controlled private review. No independent reviewer sign-off is asserted.
SPIFFE & SPIRE
SPIFFE defines a standard for workload identity; SPIRE is an implementation that issues and attests workload identities. Identity issuance and attestation are separate concerns from SDDT's current local synthetic behavior.
What SDDT would add around these tools: correlate an established workload identity with declared intent, policy context, and an evidence receipt so identity alone is not treated as proof of authorized action. No SPIFFE/SPIRE adapter, identity issuance, or identity attestation is implemented or claimed.
Open Policy Agent
OPA is a general-purpose policy engine for evaluating policy against supplied input. A policy decision is not, by itself, proof that its input was independently authenticated or that the decision was enforced at the point of action.
What SDDT would add around this tool: bind the exact policy snapshot and request to the resulting decision and separately require enforcement at the action boundary. SDDT currently describes deterministic local policy evaluation with injected context; no OPA adapter, context provenance, or external enforcement is established.
HashiCorp Vault
Vault addresses secrets and credential lifecycle, including access controls. It is a distinct system boundary for secret storage, issuance, and access management.
What SDDT would add around this tool: re-evaluate the exact action and secret request immediately before access through a separately trusted provider. Current public behavior is a fresh request and secret-name re-evaluation against an in-memory synthetic fixture only; no Vault adapter, real secret provider, or external credential lifecycle is established.
Proposed complementary layer
Bind intent, authorization, action, and a reviewable receipt.
The proposed sequence is: signed bounded intent/manifests → separately trusted policy and context → per-request secret authorization → bounded action → receipt verification against independent expected bindings. The locally verified in-toto Statement v1 / DSSE adapter described above concerns pinned synthetic reference evidence only; it is not a new runtime execution observation or independent execution proof. Verification-to-settlement is a product direction, not a deployed integration.
01Bound intentCommit to a bounded request and manifest with local synthetic signatures.
02EvaluateApply deterministic policy to context supplied separately by the embedding environment; its provenance is not established locally.
03Authorize requestRe-evaluate each request and exact secret name against an in-memory public fixture.
04Bound actionCurrent local workload is a fixed integer-sum operation, not arbitrary agent-action enforcement.
05Check receiptVerify a signed issuer assertion against independently supplied expected bindings.
A signed receipt is an issuer assertion, not independent proof of execution. Same-context replay remains a gap; receipt-verification rejection may occur after work and does not imply that nothing ran. No durable replay prevention, protected/global at-most-once guarantee, provenance of injected context, independent execution proof, or enforcement of arbitrary agent actions is established.
Status at a glance
Local checks are not external assurance.
Implemented / locally checked
Local synthetic signatures, manifests, and receipt binding; deterministic policy evaluation with injected context; fresh per-request and secret-name re-evaluation against an in-memory public fixture; and a fixed integer-sum workload. The separate in-toto Statement v1 / DSSE export-and-verify adapter passed its new local checks over synthetic reference evidence only. Historical runtime suites were not rerun for this adapter; external reviewer reproduction remains unestablished.
LOCAL SCOPE
Needs integration / enforcement
Real external adapters and trusted inputs, secret-provider integration, independently enforced action boundaries, durable replay controls, and any production-grade execution-to-settlement controls require external integration and enforcement.
NOT ESTABLISHED
Not established
No Sigstore/Rekor/Fulcio, SPIFFE/SPIRE, OPA, or Vault adapter is established. The local in-toto Statement v1 / DSSE format-export and verification adapter is not a Sigstore integration. No independent audit, production or Mainnet readiness or authorization, live GPU/CUDA binding, independent execution proof, protected/global at-most-once behavior, or verified provenance of injected context is claimed.
NO CLAIMGPU_GATE=CLOSED · internal binding state BLOCKED_UNBOUND · public binding block BLOCKED_BY_VENDOR_PRIMITIVE_AVAILABILITY (documented public-interface review, October 2026). No production/Mainnet authorization or readiness, live GPU/CUDA binding, or independent audit is claimed. Review access is qualified and controlled, with NDA where required. Only the local in-toto/DSSE adapter scope described above is established; no additional integrations, endorsements, or customer adoption are claimed. Read the binding dependency and status vocabulary.
Decision lens
A safer path from execution to settlement.
Settlement is the controlled release of financial or protocol value after successful verification. The product direction is not a promise that every workload is automatically trustworthy; it is a control model for making verification requirements visible before value is released.
01CommitDefine the bounded job, inputs, and approved workload.
02ExecuteRun through an eligible provider and preserve the execution record.
03VerifyApply the evidence path required for the workload and risk.
04SettleMake settlement eligible only after verification succeeds.
Current materials describe an early-stage capability and evidence foundation. They do not authorize production or Mainnet use.
Review with the repository
Use the concept layer to frame the diligence questions.
For implementation scope, current evidence, and release boundaries, move from this overview to the authoritative source documents.