Public information, separated from controlled diligence.

SDDT Core / Verified Compute is the existing verification foundation. Agent Trust Runtime v1.0 adds signed agent manifests, deterministic policy checks, freshly authorized secret release, and signed receipts through a Core Adapter. It reuses existing canonical JSON, hash, signature, and verification primitives; it is not a new deployed backend.

Public technical preview / prelaunch asset. The private runtime release includes 13 local/synthetic scenarios, not production orchestration, Core settlement, or GPU evidence. The separate continuity/provider-failover demonstration is neither that agent demo nor H100 evidence.

Core separates signed job intent, policy-constrained scheduling, bounded execution, verification, checkpoint recovery, and settlement eligibility. Customer charge, provider payout, network fee, and any future issuance are separate accounting decisions. A completion signal alone does not authorize value movement.

The agent layer follows Agent Trust Runtime → Core Adapter → Existing SDDT Core. Caller-supplied context is not independently established provenance; external adapters, trusted inputs, secret providers, and independently enforced action boundaries require separate integration.

Verification checks required signatures, hashes, commitments, expected identities, freshness, and policy within the evaluated profile. Signed receipts authenticate assertions, not independent proof that a device executed work. Missing, expired, modified, duplicate, or unbound evidence must not be promoted into an assurance or settlement decision.

Scoped verification status — recorded update 4 October 2026

Historical record. Earlier Core / Commercial RC1 records contain failed or incomplete acceptance checks. They are retained for qualified review, not presented as a verdict on every subsequent revision.

Recorded passes. Later repository-local engineering acceptance checks passed in their recorded local environment. Technical-core CI checks passed on Python 3.12 and 3.13, and the NVIDIA terms-content gate passed. These are scoped original technical-core passes only: each result applies to its evaluated revision, environment and checks; none is comprehensive acceptance, independent sign-off, or NVIDIA permission.

Incomplete gates. Engineering acceptance remains fail-closed: a scoped pass does not satisfy an untested or incomplete requirement. The strict GPU execution/output binding dependency is described under external assurance; local passes do not close it. Independent audit and production/Mainnet readiness or authorization are not established.

The source repository, v1.0 release and original CI evidence are private. Qualified reviewers may request owner-approved, controlled access under NDA where required. Architecture notes, runbooks, and reproduction packs are made available only through a qualified, controlled private review process. Independent reproduction and review matter; materials or founder statements are not an independent certification. This public summary does not expose source, private evidence, or private access paths.

The recorded Google Confidential Space + Intel TDX + NVIDIA H100 run verified signature, GCE, GPU, and workload identities and observed a CUDA probe. Its result is PASS_NON_PROMOTABLE, classified as ATTESTED_WORKLOAD_AND_GPU_CORESIDENCE. It does not cryptographically prove that the attested GPU executed the specific CUDA workload or generated its output.

Recorded values remain execution_context_binding=UNAVAILABLE, workload_output_binding=UNAVAILABLE, hardware_workload_binding_proven=false, GPU_GATE=CLOSED, B04=false, B05=false, and Tier3=false.

Keep this run separate from the historical RTX 4000 Ada RunPod runtime pilot, repository-local agent fixtures, and the continuity demo. Each record applies only to its evaluated revision, environment, and checks; none is an independent audit, benchmark, or production authorization. Detailed records and reproduction materials remain subject to controlled review.

Security controls depend on separately trusted keys and expected bindings, explicit policy, replay handling, and fail-closed validation. Vendor signature, certificate-chain, and revocation checks do not replace approved policy/RIM acceptance, freshness, workload binding, or independent review.

Trusted input provenance, durable replay controls, production key lifecycle, host/disk recovery, and external enforcement remain separate requirements. No certification, independent audit, or complete production security acceptance is claimed. Do not send credentials or private evidence through an unagreed channel.

Tier 3 strict execution/output binding is BLOCKED_BY_VENDOR_PRIMITIVE_AVAILABILITY. Based on documented public NVIDIA and Google interfaces reviewed as of October 2026, no supported primitive/API has been identified that cryptographically binds GPU attestation to a specific CUDA execution context or workload output. Additional internal testing alone cannot establish Tier 3; a vendor-supported mechanism or newly documented supported path is required, followed by separate qualification.

Status vocabulary: BLOCKED_UNBOUND is the established internal state indicating that authenticated execution/output binding is absent. BLOCKED_BY_VENDOR_PRIMITIVE_AVAILABILITY explains the current public-facing reason that this binding cannot progress. They describe the same unresolved gap at different levels, not competing results or a changed gate.

Repository assurance, cryptographic verification, hardware identity, workload binding, release provenance, and independent review are distinct layers. Co-residence cannot promote the binding layer. Independent approval, customer validation, and production/Mainnet authorization remain unestablished.

Agent Trust Runtime v1.0 names the private runtime release, not a production authorization. Historical Core / Commercial RC1 evidence refers to earlier checks and is not the current runtime's public version label. Release references, evaluated environments, original CI records, and evidence provenance must be reviewed together.

Scope-specific acceptance does not imply comprehensive acceptance. A future supported binding mechanism must be separately qualified and reviewed; completing that work would not automatically change release policy or gate values. Production recovery, key lifecycle, independent technical review, customer validation, rights review, and explicit governance decisions remain separate controls.

Public summaries are reviewed allowlisted assets, not a public source repository or an IP/license grant. Request qualified, owner-approved review through the existing mailto contact route; access and transaction terms require separately agreed arrangements.

Founder-led project stewardship; technical review materials are not public downloads and do not confer source or IP rights.