SDDT VERIFIED COMPUTE Strategic contact
SDDT · one verification platform for technical buyers

Verification-First Evidence & Settlement Layer for AI/GPU Compute

One platform.
Two trust layers.

Review SDDT’s existing verification foundation and Agent Trust Runtime v1.0 alongside the latest bounded GPU evidence—with the open execution and output bindings stated plainly.

For a technical buyer, the value is a reviewable record of what was authorized, what was checked, and what remains unproven—so a provider completion signal or signed assertion is not mistaken for trusted execution.

Review current assurance evidence Request a scoped technical review Explore the continuity/provider-failover demo Open the Documentation Center

Public technical preview / prelaunch asset. The recorded H100/TDX co-residence result is not authenticated CUDA execution or output binding. That binding is blocked on a documented vendor-supported primitive/API; production authorization is not granted.

The public continuity/provider-failover demo uses preserved mock fixtures. It is not the Agent Trust Runtime v1.0 13-scenario local/synthetic demo and is not H100 evidence.

SDDT Agent Trust Runtime v1.0 · Private release

Agent authorization, gated secrets & signed receipts

REUSE BOUNDARY Core Adapter

Reuses existing verification primitives

SDDT Core / Verified Compute

Existing verification foundation

Current assurance · buyer readout

What SDDT proves today.

One recorded run adds useful confidential-computing evidence. Its exact classification is non-promotable: co-residence is established for this record, not authenticated GPU execution of a workload or its output.

RECORDED RUN · 37775602109 PASS_NON_PROMOTABLE

Live assurance evidence

The run succeeded in Google Confidential Space with Intel TDX and an NVIDIA H100. Signature, GCE, GPU, and workload identities were verified, and a CUDA probe was observed.

Recorded classification: ATTESTED_WORKLOAD_AND_GPU_CORESIDENCE. This is evidence of co-residence in that run—not authenticated proof that the attested GPU executed the CUDA workload or produced a particular output.

Environment
Google Confidential Space · Intel TDX
GPU
NVIDIA H100
Verified
Signature · GCE identity · GPU identity · workload identity
Observed
CUDA probe
execution_context_bindingUNAVAILABLE workload_output_bindingUNAVAILABLE hardware_workload_binding_provenfalse Internal binding stateBLOCKED_UNBOUND GPU_GATECLOSED B04false B05false Tier3false

This is a run-specific recorded result, not a benchmark, independent audit, production authorization, or general assurance claim.

B04 requires authenticated binding to the exact CUDA execution context; B05 requires the same backend to execute the authorized workload through that context with bound execution and result evidence. Neither requirement is satisfied by this co-residence record. Read the binding-control definitions.

01 / BUYER VALUE

Why it matters

Infrastructure identity and isolation checks are useful signals, but they do not by themselves show which GPU context executed work or generated an output. SDDT keeps that distinction visible so a buyer can review the evidence without treating co-location as execution proof.

02 / OPEN GATES

What remains open

Vendor-interface limitation (reviewed October 2026): Based on the documented public NVIDIA and Google 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 cannot be established through additional internal testing alone; it requires a vendor-supported mechanism or a newly documented supported path from NVIDIA or Google. Status: BLOCKED_BY_VENDOR_PRIMITIVE_AVAILABILITY. Independent review, operational readiness, customer validation, and production authorization remain separate decisions. Read the status vocabulary and assurance boundary.

03 / REVIEW CHECKLIST

Buyer due diligence

  • Review the run record, identity checks, signatures, and verifier scope.
  • Separate this H100/TDX result from the historical RTX 4000 RunPod pilot and local/synthetic agent scenarios.
  • Assess the unavailable bindings and closed release gates directly; do not infer production authorization or stronger execution assurance.
  • Run independent technical, security, ownership, and third-party-rights review before any transaction or deployment.
04 / CONTROLLED EVALUATION

Pilot path

Start with qualified review of the recorded evidence and documented boundaries. Agree a bounded, owner-approved evaluation scope before any pilot; a proposal or review does not open GPU_GATE, authorize production use, or grant integration or licensing rights.

Discuss a controlled review or pilot Review evidence documentation
05 / R&D WATCH

What could change the result

A newly documented vendor-supported path from NVIDIA or Google would need separate qualification of authenticated execution/output binding. That qualification must preserve device and session identity, the exact authorized workload, result commitments, and substitution/replay rejection. It would not automatically open any release gate. Until a supported path is available and separately qualified, this result remains PASS_NON_PROMOTABLE; local inference or co-residence checks do not substitute for that binding. Review the current vendor-interface dependency.

H100 · TDX Recorded run 37775602109
Google Confidential Space
IDENTITIES Signature, GCE, GPU
and workload verified
CUDA PROBE Observed · not execution
or output binding
NON-PROMOTABLE Co-residence evidence
not execution/output proof
The infrastructure gap

Capacity is easy to advertise. Useful execution is harder to prove.

Technical buyers face two related but distinct trust questions: did compute follow an authorized, verifiable path, and can an AI agent be constrained before it reaches tools or secrets? A declaration or signed receipt alone is not proof of execution, provider behavior, trusted identity, or hardware binding. SDDT presents its existing Core foundation and an additive agent trust layer without conflating their evidence or readiness.

01

Is agent identity and declared capability checked against separately configured policy?

02

Is secret release freshly authorized for this exact request before provider access?

03

Can receipts be checked against an independently trusted signer and expected bindings?

Why SDDT exists

One platform, with the trust boundary made explicit.

SDDT Core / Verified Compute is the existing verification foundation. SDDT Agent Trust Runtime v1.0 is an additive AI-agent trust layer above it: Agent Trust Runtime → Core Adapter → Existing SDDT Core. The Core Adapter reuses frozen canonical JSON, hash, signature, and verification primitives; it is not a new deployed orchestration or backend. The agent demo does not exercise Core settlement.

01 / CREATED FOR

Reviewable execution

Keep the authorized workload, execution record, and result commitments connected for later technical and transaction review.

02 / CURRENT LIMITATION

Capacity is not proof

A listed GPU or completed job does not by itself prove workload identity, useful execution, or a single eligible settlement.

03 / CONTROL POINT

Verify before settlement

Keep missing, mismatched, duplicate, or unbound evidence from silently becoming a value-movement decision.

01 / SIGNED MANIFESTS

Validate declared identity

Signed agent manifests are checked against separately supplied keys; a declaration does not establish identity provenance or policy approval.

02 / DETERMINISTIC POLICY

Deterministic ALLOW / DENY

Evaluate an exact request against separately configured policy and trusted runtime context, with explicit fail-closed decisions.

03 / SECRET RELEASE

Policy-gated secret release

Policy-gated release freshly re-evaluates the exact request immediately before resolving provider access; the public fixture is synthetic and in-memory.

04 / SIGNED EXECUTION RECEIPTS

Check assertions against expectations

Receipts use an independently trusted signer and pre-built expected bindings. Signatures authenticate assertions, not independent proof of execution or hardware.

05 / GOLDEN-PATH EVIDENCE

Thirteen local scenarios

Golden-path evidence covers 13 local/synthetic scenarios, including specified rejections; not production orchestration, settlement, or hardware evidence.

06 / DEMO + DOCS

Review the bounded implementation

Demo and documentation describe the frozen implementation, component boundaries, reproducible fixtures, and limitations for technical review.

Public technical preview / prelaunch asset. Agent Trust Runtime v1.0 evidence is local/synthetic only; the separate H100/TDX record establishes co-residence, not strict execution/output binding. No production/Mainnet readiness, independent audit, or live-GPU/CUDA binding is claimed.

Neutral comparison of approaches

Where the verification-first layer sits.

These are positioning differences, not competitor claims or performance claims.

Control question Traditional compute marketplace Verification-first layer
Evidence continuity Records may be distributed across provider, scheduler, and billing systems. Evidence is structured as a bound, reviewable sequence.
Fail-closed verification Verification may be separate from marketplace settlement policy. Required evidence can stop the next stage when data is missing or mismatched.
Settlement control Settlement logic may follow platform state or provider records. Settlement eligibility remains downstream of verification and recovery controls.

Technical comparison: Sigstore/in-toto, SPIFFE/SPIRE, OPA and Vault

Capability map / buyer readout

The stack, separated from the gates.

This capability map describes the existing SDDT Core / Verified Compute foundation. Agent Trust Runtime v1.0 is an additive layer above it; “Implemented / reviewable” describes repository-level evidence and does not imply production authorization, customer validation, or independent assurance.

READ THIS KEY Implemented / reviewable Controlled validation Open gate NDA data-room detail
01 / CONSENSUS SUBSTRATEImplemented / reviewable

Validator + quorum consensus

Distributed validator coordination, quorum decisions, signed state transitions, and compact verified commitments form the substrate beneath the compute path.

Boundary: internal engineering scope; not independent assurance or Mainnet authorization.
02 / SCHEDULINGImplemented / reviewable

Deterministic provider scheduling

Stable provider selection and bounded worker/provider adapters keep execution policy explicit and reviewable.

Adapters are integration surfaces, not proof of external provider operation.
03 / INTENTImplemented / reviewable

Signed intent + V1–V4 verification

Pre-issued signed jobs, immutable commitments, expiry, resource ceilings, and policy-selected verification classes.

Class selection does not promote missing hardware or provenance evidence.
04 / EVIDENCE CONTROLSImplemented / reviewable

Receipts, replay protection, fail-closed controls

Provider-signed receipts bind job identity, inputs, outputs, timing, and commitments. Duplicate, expired, modified, or unbound records remain rejected or quarantined.

Evidence controls are repository-tested; they are not a production security certification.
05 / CONTINUITYImplemented / reviewable

Recovery + checkpoint durability

Checkpoint continuity and recovery paths preserve job identity and guard against duplicate finalization.

Production host, disk, KMS, and disaster-recovery drills remain separate gates.
06 / SETTLEMENTImplemented / reviewable

Four ledgers, one boundary

Customer paymentcharge for authorized work Provider payouteligible provider economics Network feeprotocol/service allocation Bounded issuanceseparate, policy-controlled path
These accounting paths are kept distinct; workload demand does not silently become issuance.
07 / NETWORK VALIDATIONControlled validation

WAN + multi-provider validation

Coordinator and provider paths are structured for distributed validation across more than one provider.

WAN status is active, not complete; completion must be coordinator/evidence sourced.
08 / HARDWARE BOUNDARYOpen gate

Controlled GPU pilot + attestation boundary

The recorded Google Confidential Space + Intel TDX + NVIDIA H100 run is non-promotable co-residence evidence. A historical RTX 4000 Ada runtime pilot and internally tested composite-attestation implementation are separate records.

Strict execution/output binding remains blocked on a documented vendor-supported primitive/API. Complete composite-profile qualification, trusted source time, and release provenance remain separate requirements; the recorded run does not close them. Review the binding dependency.
09 / TRANSFER + INTEGRATIONNDA data-room detail

Buyer transfer package and integration options

Architecture, source, tests, evidence tooling, scheduler/verification/accounting components, and documentation can be scoped for review.

Technology / IP acquisitionField-limited licenseBuyer-owned infrastructure integrationStaged validation pathway
Any transfer is subject to ownership, licenses, provider terms, counsel review, and a signed transaction perimeter. Brand and domain assets are not promised.
Status labels describe the current evidence boundary, not a forecast. Review the External Assurance Framework for authoritative non-authorizations.
Commercial value / CTO and acquisition review

Practical value before deep architecture.

SDDT presents one platform for technical buyers: the existing Core verification foundation and an additive Agent Trust Runtime with explicit authorization and evidence boundaries. The practical value is a reviewable control model—not a claim that every infrastructure or production gate is closed.

01 / AMBIGUITY

Reduce settlement ambiguity

Keep the evidence needed to evaluate authorized work and settlement eligibility in view.

02 / EVIDENCE

Preserve execution records

Bind job identity, commitments, runtime context, and results for technical and transaction review.

03 / RECOVERY

Support controlled recoverability

Make checkpoint, replay, duplicate, and finalization paths explicit rather than implicit in platform state.

04 / VALUE MOVEMENT

Separate verification from settlement

Position value movement downstream of verification without requiring a replacement marketplace.

External Assurance Framework

Assurance is layered, not assumed.

Each layer answers a different buyer question. A passing repository or cryptographic check does not silently promote hardware evidence, operational controls, or production readiness. Verification answers whether required checks succeeded; assurance answers what confidence can legitimately be claimed.

01RECORDED

Repository assurance

Canonical files, validation controls, release mapping, and reproducible local checks are preserved for review.

Open repository scope
02RECORDED

Cryptographic verification

Hashes, signatures, evidence bindings, and the repository-local verification result can be reproduced.

Open verification guide
03BLOCKED

Tier 3 GPU/workload binding

Status: BLOCKED_BY_VENDOR_PRIMITIVE_AVAILABILITY. The October 2026 review found no supported primitive/API in the documented public NVIDIA and Google interfaces reviewed that binds GPU attestation to a specific CUDA execution context or output. Internal testing alone cannot establish the missing binding; a vendor-supported mechanism or newly documented supported path requires separate qualification. Existing cryptographic checks and recorded evidence remain within their stated scope.

Open GPU evidence
04REVIEWABLE

External Assurance

The framework separates verified checks from missing provenance, workload binding, independent review, and release promotion.

Open assurance framework
05PENDING

Operational readiness

Trusted source-device time and identity and durable operational review remain separate open items. Strict execution/output binding remains blocked on a documented vendor-supported primitive/API; see layer 03.

Open release controls
06NOT CLAIMED

Production readiness

Independent review, customer validation, production authorization, and Mainnet status remain separate gates.

Review non-authorizations
The public continuity/provider-failover demo replays preserved mock fixtures. It is not the Agent Trust Runtime v1.0 13-scenario demo, H100 evidence, production proof, or a certification. Review the evidence summaries and External Assurance Framework separately.
Evidence, not adjectives

What has been demonstrated so far.

The latest recorded Google Confidential Space + Intel TDX + NVIDIA H100 result is classified ATTESTED_WORKLOAD_AND_GPU_CORESIDENCE / PASS_NON_PROMOTABLE; it does not establish authenticated execution-context or workload-output binding. Separate historical Core materials include a RunPod RTX 4000 Ada Controlled Runtime Pilot Record and a strict AMD SEV-SNP + NVIDIA NRAS composite-attestation implementation recorded and internally tested. These evidence sets answer different questions and do not close the GPU gate. Evidence package assembled for review. Internal implementation and CI verification recorded within their scoped environments and revisions. Agent Trust Runtime v1.0's 13 scenarios remain local/synthetic.

CONTROLLED RUNTIME PILOT RECORD

RUNTIME EXECUTION EVIDENCE
CONTROLLED RUNTIME PILOT RECORD

✓ Controlled Runtime Pilot Record
PILOT HARDWARENVIDIA RTX 4000
Ada Generation
RUNTIME EXECUTION EVIDENCE v2SDDT-RUNPOD-
REAL-GPU-PILOT-v2
EXECUTION DETAIL3/3 JOBS VERIFIED
Runtime Execution Evidence
Boundary: Runtime Execution Evidence only Endpoint deleted · no live-chain mutation
01

Evidence version

SDDT-RUNPOD-REAL-GPU-PILOT-v2

02

Recorded Runtime Execution Evidence archive fingerprint

bbb224696abc60f791723cf0c2055e971c6e8ba1cac4945bbf28ec70644eef1a

This is not a hardware-attestation archive hash.
03

Secret scan

NO_SECRET_PATTERNS_FOUND

Security Policy Fail-Closed

Trust is granted only when required evidence is complete.

StatusActive
GPU Assurance Prelaunch

GPU Gate remains intentionally closed until all assurance requirements are satisfied.

StatusClosed
Verification Open for Independent Technical Review

Source, verification data, artifacts, documentation, and disclosed repository gate exceptions are available for independent technical review.

StatusReviewable
The Controlled Runtime Pilot Record contains Runtime Execution Evidence only; it is not live composite hardware attestation, an independent human audit, or final provenance promotion.
Architecture

Agent Trust Runtime above the existing Core.

The v1.0 integration boundary is additive: Agent Trust Runtime → Core Adapter → Existing SDDT Core. The Core Adapter reuses frozen canonical JSON, hash, signature, and verification primitives. It is not a new deployed orchestration layer or backend. Existing Core settlement and recovery evidence remain distinct from the local/synthetic agent demonstration.

01 / ADDITIVE LAYER
SDDT Agent Trust RuntimeSigned manifests · deterministic policy · guarded secret release · signed execution receipts
↓
02 / REUSE BOUNDARY
Core AdapterReuse frozen canonical JSON, hash, signature, and verification primitives; no new deployed orchestration/backend
↓
03 / EXISTING FOUNDATION
Existing SDDT Core / Verified ComputeThe existing verification foundation; Core gates remain unchanged
Existing Core verification lifecycle

Core execution, evidence, and settlement boundaries.

This existing Core lifecycle is not the v1.0 Agent Trust Runtime demo. The 13 agent scenarios are local/synthetic and do not exercise Core GPU execution or settlement.

01IntentSigned workload, expiry, resource limits

Define the bounded job and immutable workload commitments before a provider runs it.

View system model
02VerificationPolicy and fail-closed checks

Select the evidence path required for the workload and reject expired, modified, duplicate, or replayed work.

View verification guide
03EvidenceBounded execution and result commitments

Preserve Runtime Execution Evidence, receipts, provider context, and result commitments for review.

Review current Runtime Execution Evidence
04SettlementEligibility after verification succeeds

Keep customer charge, provider payout, network fee, and future issuance separate until verification succeeds.

View settlement boundary
05ReceiptsDurable record and recovery paths

Retain receipts and bound checkpoints so an authorized recovery path does not silently create a new or duplicate job.

View continuity controls
06External AssuranceReview, provenance, release boundaries

Keep the complete claim chain reviewable; open provenance or binding gates remain closed rather than promoted.

View assurance boundaries

Fail-closed boundary: Runtime Execution Evidence that cannot be bound to the authorized job, source, device, or release remains quarantined rather than promoted. Public technical preview / prelaunch asset; no production/Mainnet readiness, independent audit, or strict execution/output binding is claimed. Follow the verification journey

Verification journey

Follow one workload from intent to settlement.

Open each stage to see the decision it makes. The Architecture describes system components, while the Verification Journey describes the runtime decision flow; current gates remain stated separately.

01IntentDefine the authorized work

A signed job envelope fixes the workload, inputs, expiry, and resource ceilings before execution.

02AttestationEvaluate device evidence

Hardware evidence can contribute to the decision, but vendor checks do not replace freshness, provenance, or workload binding.

03VerificationApply the required policy

Choose the verification class for the workload and fail closed when required evidence is missing or mismatched.

04Runtime Execution EvidencePreserve the execution record

Keep receipts, commitments, runtime context, and result data together for later reproduction and review.

05ReceiptRecord the verified result

A structured receipt gives downstream systems a durable reference without turning an unverified result into a settlement event.

06SettlementRelease value only when eligible

Settlement eligibility follows successful verification; production and Mainnet authorization remain separate governance decisions.

Engineering readiness posture

Engineered for the next validation stages.

SDDT is engineered for external provenance review, lightweight technical audit, controlled buyer diligence, and staged integration review. Those gates are prepared for, not presented as completed outcomes.

RECORDEDInternal implementation and CI verification
RECORDEDControlled Runtime Pilot Record: 3 of 3 jobs verified
IMPLEMENTEDComposite attestation implementation is recorded and internally tested
BLOCKEDStrict GPU execution/output binding depends on a documented vendor-supported primitive/API, not more internal testing alone. Imported Hardware Evidence subchecks remain separately reviewable.
PENDINGLive compatible-hardware composite attestation and final provenance claim promotion remain separate open work; neither alone establishes strict execution/output binding.
NOT CLAIMEDIndependent audit, Customer validation, Production / Mainnet authorization
Commercial Positioning & Technical Readiness

Advanced assurance architecture. Bounded evaluation.

SDDT Verified Compute is an advanced, early-stage architecture addressing distributed AI verification, execution assurance, and settlement friction. It combines SDDT Core / Verified Compute with the additive Agent Trust Runtime v1.0 layer and is designed to reduce the internal R&D effort needed to build comparable assurance infrastructure.

Current Status & Architectural Integrity. Recorded run 37775602109 succeeded in Google Confidential Space with Intel TDX and an NVIDIA H100; signature, GCE, GPU and workload identities were verified, and a CUDA probe was observed. Its classification is ATTESTED_WORKLOAD_AND_GPU_CORESIDENCE / PASS_NON_PROMOTABLE. The separate historical RunPod RTX 4000 Ada pilot recorded 3/3 verified jobs; it is not the latest assurance result.

Evaluation safeguards. Co-residence and an observed CUDA probe do not establish authenticated GPU execution or output binding. The main assurance record preserves the exact unchanged gate values. That binding depends on a documented vendor-supported primitive/API; additional internal testing alone cannot establish it. No production/Mainnet authorization or independent audit is claimed.

Strategic Review & Diligence Access. The project is available for bounded technical evaluation, strategic review, and structured pilot discussions. Technical due-diligence materials, reproducibility workflows, and owner-approved private repository access may be provided to qualified evaluators under NDA where required.

Any production deployment, commercial integration, licensing, investment, or acquisition remains subject to applicable technical, legal, security, intellectual-property, and commercial diligence.

01
Verification-first evidence and settlement layerTechnical review framing
→
02
Strategic acquisition reviewDefined scope and separate diligence
→
03
Full GPU marketplaceNot the current positioning
—
Strategic pathways
01

Strategic acquisition

Review a defined technology/IP scope, subject to ownership, third-party rights, transfer diligence, and signed agreements.

02

Technology licensing

Assess a defined licensing scope with rights diligence and separately agreed terms. Review access does not grant licensing rights.

03

Enterprise integration

Evaluate infrastructure fit through bounded technical review and structured pilot preparation. Production integration requires separate diligence and authorization.

04

Controlled evaluation

Qualified evaluators may discuss bounded CPU/offline pilots, reproduction materials, and agreed deliverables through owner-approved access under NDA.

Who may care
01GPU infrastructure operators

Teams that need verifiable job completion and safer settlement controls.

02AI compute platforms

Marketplaces or schedulers evaluating a verification layer beneath existing supply.

03Protocol & infrastructure teams

Organizations that value recoverability, evidence, and distributed systems IP.

04Enterprise AI platform builders

Product groups exploring controlled, reviewable external compute workflows.

Claim boundaries

Conservative by design.

Technical review materials are prepared, but buyer-readiness certification, rights clearance and completed transaction diligence are not established. Qualified reviewers may request controlled private repository access under NDA where required, independently reproduce the bounded CPU checks, retain their actual results and assess the stated claim limits. A prepared pack is not reviewer execution or sign-off.

The assurance gate remains closed. No production/Mainnet readiness or authorization, independent audit, or live GPU/CUDA binding is claimed. See the recorded evidence and exact gate values.

✓
Recorded scope

SDDT Agent Trust Runtime v1.0 has 13 local/synthetic scenarios described for qualified controlled review. Separate historical Core materials include a preserved Controlled Runtime Pilot Record and an internally tested strict AMD SEV-SNP + NVIDIA NRAS implementation. These are scoped records, not a comprehensive acceptance or independent review.

×
Explicitly Not Claimed

No live compatible-hardware composite attestation, final provenance promotion, production/Mainnet readiness or authorization, independent audit, customer validation, buyer-ready certification, cleared title, or completed acquisition/licensing diligence is claimed.

×
Future Validation

Source-device provenance and complete NVIDIA policy/RIM acceptance remain separate requirements. Strict execution/output binding is blocked until a vendor-supported mechanism or newly documented supported path can be separately qualified. Independent evaluator execution and sign-off, integration, external review, and customer validation are not established.

Next validation gates

Open questions for any future evaluation.

01
Preserve reproducible pilot evidence

Keep signed job, receipt, commitments, device, and integrity records together.

02
Exercise recovery paths

Test checkpoint/failover continuity and preserve the resulting evidence.

03
Measure cost and latency

Record controlled performance evidence for defined workloads and verification classes.

04
Invite focused external review

Use an architecture or security review when transaction stage and budget justify it.

Demo asset

See the evidence flow in the 2-Minute Buyer Demo.

This video is a historical product presentation, not a current acceptance report, Agent Trust Runtime v1.0 13-scenario demo, or H100 evidence. The scoped status in the Documentation Center takes precedence over readiness wording in the recording. The separate continuity/provider-failover demo replays preserved mock fixtures without running a workload.

Audio narration is included. Use the player volume control to enable or adjust sound.

Sound ready
  1. 01Why SDDT exists
  2. 02What SDDT does
  3. 03Architecture
  4. 04Trust model
  5. 05Verification journey
  6. 06Controlled pilot
  7. 07Readiness boundaries
  8. 08Boundaries
  9. 09Technical review
Accessible transcript / chapter summary — updated status clarification

01 · Why SDDT exists. A GPU marketplace can show a device. It cannot, by itself, prove the authorized workload ran, produced the expected result, or will settle only once.

02 · What SDDT does. SDDT is a verification-first evidence and settlement layer for distributed AI and GPU compute.

03 · Architecture. The complete path is Intent, Verification, Runtime Execution Evidence, Receipt, Settlement, and External Assurance. Missing or mismatched data stops the next stage.

04 · Trust model. Repository, Cryptographic Verification, Hardware Attestation, External Assurance, Operational Readiness, and Production are separate layers with separate states.

05 · Verification journey. One workload moves through Intent, Attestation, Verification, Runtime Execution Evidence, Receipt, and Settlement. Data that cannot be bound to the authorized job, source, device, or release remains quarantined.

06 · Historical Controlled Runtime Pilot Record. The separate RunPod Controlled Runtime Pilot Record reports 3/3 verified jobs on an NVIDIA RTX 4000 Ada Generation GPU under Evidence Protocol v2. It is not the latest assurance result. This is a controlled runtime pilot record, not completed composite hardware attestation. The latest Google Confidential Space + Intel TDX + NVIDIA H100 run and its non-promotable classification are summarized in the current assurance section above.

07 · Readiness boundaries — updated clarification. Engineering acceptance is fail-closed and scoped to the revision, environment and checks evaluated. Historical Core / Commercial RC1 records include failed or incomplete checks; later scoped local acceptance checks and the recorded technical-core CI checks passed within their stated scope. These results do not establish comprehensive acceptance or close external assurance gates. Strict execution/output binding remains blocked by vendor-primitive availability; no production/Mainnet readiness or authorization, independent audit, or live GPU/CUDA binding is claimed. See the scoped verification status for the distinction between recorded passes and incomplete gates.

08 · Boundaries. Independent Review, Production Authorization, and Mainnet remain future operational milestones. This is not completed composite hardware attestation, final provenance promotion, production readiness, independent audit, or customer validation.

09 · Technical review. Reviewed public documentation and controlled diligence materials support qualified technical review.

This existing Version 2 recording presents the Core verification journey and historical Controlled Runtime Pilot Record; that pilot is separate from Agent Trust Runtime v1.0 synthetic evidence. It does not claim completed hardware attestation, final provenance promotion, production readiness, Mainnet authorization, independent audit, or customer validation.

Documentation Center

Choose the depth required for your review.

Executive readers can start with the review map. Engineers and security reviewers can move directly into architecture, verification, evidence, assurance, and release sources without any reduction in technical detail.

01OverviewTechnical scope and source map 02ArchitectureSystem boundaries and evidence flow 03VerificationReproduce the assurance checks 04External assuranceAuthoritative claim boundaries 05EvidenceEvidence intake and handling 06SecurityDisclosure and security posture
Open for strategic conversations

Request a scoped technical review.

For a preliminary discussion about qualified technical review or a possible pilot proposal, use the public mailto route below. A proposal is not evaluator execution, sign-off, integration, completed diligence, or a commitment to transact.

Access, pilot, licensing, acquisition, and transfer terms require separately reviewed and signed agreements. A mailto link does not confirm inbox activation or delivery.
PRIMARY PARTNERS INBOX partners@sddtcompute.com Open a buyer inquiry in your email app. Include your review goal, bounded workflow, required evidence, and interest in acquisition, licensing, or integration. Send non-confidential context only.
GENERAL INBOX hello@sddtcompute.com Secondary contact route for general buyer and partnership inquiries.
The contact links open the visitor's mail application. No web form or delivery confirmation is provided.