Why SDDT
Clarify the trust gap between advertised compute capacity and evidence that useful work completed correctly.
Explore the problem →Enterprise knowledge layer
Understand the system before you evaluate it.
A concise buyer-facing guide to SDDT Verified Compute, a verification-first evidence and settlement layer for distributed AI/GPU compute, and its additive Agent Trust Runtime v1.0 layer, with their distinct evidence scopes, security posture, practical fit, and validation path.
One platform · two trust layers
Core verification and agent authorization answer different questions.
SDDT Core / Verified Compute is the existing foundation for signed job intent, verification, recovery, and settlement controls. Agent Trust Runtime v1.0 adds signed agent manifests, deterministic policy decisions, freshly authorized secret release, and signed receipts above that foundation. Its Core Adapter reuses existing canonical JSON, hash, signature, and verification primitives; it is not a new deployed backend.
The runtime's 13 recorded local/synthetic scenarios describe bounded agent behavior, not production orchestration, Core settlement, H100 evidence, or independent execution proof. Policy decisions depend on separately trusted inputs and enforcement; a signed receipt authenticates an issuer's assertions, not proof that hardware executed the work. The public continuity/provider-failover demo and recorded GPU co-residence result are separate evidence scopes. No production authorization or independent audit is claimed.
Choose a lens
Concepts for the first enterprise conversation.
These pages frame the decision in sequence: start with the problem, then move through the model, trust posture, buyer fit, and validation path. They do not replace the repository’s specifications, evidence records, or authoritative assurance narrative.
Technology
See the bounded flow from authorized intent to Runtime Execution Evidence, verification, recovery, and settlement.
See the model →Security
Separate Repository Assurance, cryptographic verification, hardware assurance, operational readiness, and production claims.
Review the layers →Use cases
Identify the infrastructure and platform teams most likely to value evidence continuity and safer settlement controls.
Find the fit →Capability roadmap
Distinguish the current foundation, next validation gates, and outcomes the project deliberately does not claim.
View the path →Terminology
A shared vocabulary for technical review.
These concise definitions keep verification results, assurance levels, and claim boundaries distinct.
Evidence
Structured data or artifacts preserved to support a verification decision.
Verification
The checks that answer whether the required conditions succeeded.
Assurance
The confidence that can legitimately be claimed from the available checks and boundaries.
Attestation
Signed device or platform evidence used to evaluate hardware and execution conditions.
Settlement
The controlled release of financial or protocol value after successful verification.
Receipt
A durable reference that records the verified result for downstream systems.
Runtime Execution Evidence
Execution data preserved with workload, provider, timing, and result context for review.
Controlled Runtime Pilot Record
A preserved runtime execution performed under controlled conditions for verification and data collection.
Composite Attestation
A combined AMD and NVIDIA attestation path whose live compatible-hardware assurance remains intentionally unclaimed. Its Tier 3 execution-context/output binding is BLOCKED_BY_VENDOR_PRIMITIVE_AVAILABILITY.
GPU Gate
The assurance promotion gate remains closed. Based on documented NVIDIA and Google public interfaces reviewed as of October 2026, no supported primitive or API has been identified that cryptographically binds GPU attestation to a specific CUDA execution context or a specific workload output. Tier 3 is BLOCKED_BY_VENDOR_PRIMITIVE_AVAILABILITY; additional internal testing alone cannot establish it without a vendor-supported mechanism or a newly documented supported path from NVIDIA or Google.
Fail-Closed
A control posture that withholds promotion when required data is missing, stale, mismatched, or unbound.
Repository Assurance
Confidence based on preserved repository artifacts, canonical references, and reproducible local checks.
Status vocabulary
Implemented describes a capability, Recorded describes preserved data, Reviewable describes available material, Pending describes an unfinished gate, and Closed applies to a policy gate. BLOCKED_BY_VENDOR_PRIMITIVE_AVAILABILITY marks the Tier 3 binding gap that internal tests alone cannot resolve without a vendor-supported mechanism or a newly documented supported path from NVIDIA or Google. Not Claimed marks an unsupported outcome.
Authoritative sources
“The knowledge layer explains the decision. The repository remains the evidence.”
The linked public sections explain scope and controls. Original source and evidence require owner-approved, controlled review.