PUBLIC REVIEW — Sovereign Compute Access Act Draft v1

[satonakaoshimoto]

TitleChain Foundation has published the Sovereign Compute Access Act — Draft v1 as model legislation for public review and comment.

The proposal addresses private and local access to open-weight AI, human authority over agent actions, state-primary administration, vendor neutrality, disclosures, and anti-capture safeguards. It is not enacted law, has not been introduced by a legislative office, and is not an adopted ICSN standard.

Review the draft

• Public-review hub
• Official model-act text
• Draft v1 package
• Publication pull request and review history

Comment here

We welcome legal and constitutional analysis, privacy and civil-liberties review, technical and security review, accessibility feedback, implementation and cost analysis, factual corrections, and proposed amendments.

When possible, identify the document and section, explain the concern and affected communities, link supporting evidence, and propose replacement text or another resolution. For exact text changes, open a focused pull request against the published files and link it here.

Do not post privileged, personal, classified, or security-sensitive material in this public discussion. Nonpublic inquiries may be sent to support@titlechainfoundation.org.

GitHub comments are public-review input. They are not an official legislative submission, endorsement, vote, or promise of adoption.

[satonakaoshimoto]

Seed question 1: Spatial and world-model classification

Document and section: OFFICIAL-TEXT.md, Sec. 105(d) - Spatial and World-Model Classification

Comment type: Technical

My comment: Section 105(d)(3) allows the registry to use the EU AI Act threshold of $10^{25}$ cumulative training FLOPs as a reference point. That threshold is associated with general-purpose AI models presenting systemic risk; it was not developed specifically for spatial or world-model architectures. Is it a useful reference for this category, or should Draft v2 use an architecture-specific threshold or a different capability measure?

Why this matters: A poorly calibrated threshold could over-classify an efficient model or under-classify a model with significant real-world capability through another axis, such as action-space complexity, persistent environment modeling, multimodality, or real-time control.

Supporting evidence or sources: Appendix A lists Meta V-JEPA 2 as a 1.2B-parameter open-weight world model. That example illustrates why parameter count alone does not resolve training-compute or capability classification. We invite measured training-compute evidence and world-model-specific research rather than inferring FLOPs from parameter count.

Affected communities or organizations: Spatial and world-model developers, independent evaluators, and state registries using the classification for disclosure or procurement decisions.

Proposed language or resolution: Before Draft v2, determine whether the reference threshold is technically defensible for world models, should be lower or multi-factor, or should be replaced by an evidence-based process for setting architecture-specific thresholds.

Relevant jurisdiction or experience (optional): We especially welcome input from researchers or engineers with direct world-model training, evaluation, or compute-measurement experience.

[satonakaoshimoto]

Seed question 2: State administration and interstate commerce

Document and section: OFFICIAL-TEXT.md, Sec. 302 - Jurisdiction; State Administration; Limitation on Federal Agency Creation

Comment type: Constitutional and legal

My comment: For a state enactment of this model act, could state-by-state enforcement of the Section 101 access mandate face a dormant Commerce Clause challenge because AI distribution, training, and inference routinely cross state lines? If so, does Section 302 adequately distinguish conduct a state may regulate from conduct requiring federal treatment? A federal enactment raises a different Commerce Clause analysis, so comments should address the state and federal versions separately.

Why this matters: The state-primary structure is central to the draft. If a state version would regulate commerce outside the adopting state, discriminate against interstate commerce, or impose inconsistent obligations across jurisdictions, the administration and enforcement model may need revision before introduction.

Supporting evidence or sources: This is a request for legal authorities and analogous cases, not an assertion that the provision is unconstitutional. State privacy, consumer-protection, internet-platform, and technology laws may offer useful comparisons.

Affected communities or organizations: Adopting states, Covered Tier I Holders, compute providers operating across state lines, state regulators, and interstate compact participants.

Proposed language or resolution: Request a written analysis separating the state and federal enactment paths and identifying any recommended nexus, territorial limitation, safe harbor, reciprocity, or preemption language.

Relevant jurisdiction or experience (optional): We especially welcome constitutional scholars and counsel with dormant Commerce Clause or state technology-regulation experience.

[satonakaoshimoto]

Seed question 3: Public-support reciprocity window

Document and section: OFFICIAL-TEXT.md, Sec. 102(b) - Compute Reciprocity for Publicly Supported Training

Comment type: Economic and implementation

My comment: Section 102(b)(2) proposes an 18-month deadline for releasing an open-weight or open-research variant after the first commercial or public release of a model trained with publicly supported compute. Is 18 months appropriate for AI model cycles, or should the obligation use a different period or trigger, such as the end of a defined exclusivity period or loss of frontier status?

Why this matters: A long period could make reciprocity ineffective as model generations turn over; a short period could undermine legitimate commercialization or conflict with grant, procurement, national-security, licensing, or technology-transfer obligations.

Supporting evidence or sources: The draft invokes the public-benefit principle associated with Bayh-Dole but expressly does not import its march-in or patent-specific provisions. The proposed 18-month period therefore needs an independent policy and economic justification based on AI development and public-compute programs.

Affected communities or organizations: Compute providers using public support, funding agencies, research institutions, technology-transfer offices, taxpayers, and Covered Tier I Holders.

Proposed language or resolution: Develop an evidence-based recommendation for the trigger, deadline, qualifying threshold, acceptable open-research alternative, waiver criteria, and treatment of national-security or third-party-rights constraints.

Relevant jurisdiction or experience (optional): We especially welcome input from federal grant administrators, technology-transfer professionals, public-compute program operators, AI developers, and economists.

[satonakaoshimoto]

Seed question 4: Tamper-evident baseline for registered nodes

Document and section: OFFICIAL-TEXT.md, Sec. 104(d) - Registration and Validation

Comment type: Security and implementation

My comment: Section 104(d) requires a tamper-evident baseline for a Registered Sovereign Node. What minimum evidence should that phrase require across heterogeneous consumer hardware, operating systems, chipset generations, and prior-use histories? Should the act name a standard, require the registry to publish a technology-neutral profile, or leave the mechanism entirely to implementing rules?

Why this matters: Without a defined assurance objective, implementations could range from a simple software checksum to hardware-rooted measured boot and remote attestation. Those approaches offer materially different security, privacy, accessibility, recovery, cost, and vendor-lock-in properties.

Supporting evidence or sources: We invite comparisons among TPM 2.0 measured boot and attestation, platform-native secure hardware, confidential-computing attestation, reproducible software measurements, and privacy-preserving or owner-mediated evidence models. A cited threat model and deployment evidence would be particularly useful.

Affected communities or organizations: Covered Tier I Holders, independent implementers, hardware and operating-system vendors, state registries, accessibility users, refurbishers, and parties relying on validation status.

Proposed language or resolution: Define the security and privacy outcomes first, then identify a vendor-neutral minimum profile with alternatives, owner consent, data minimization, revocation, recovery, and support for older or refurbished hardware. The process should not grant access to prompts, models, files, or usage.

Relevant jurisdiction or experience (optional): We especially welcome applied cryptographers and engineers who have deployed device attestation or heterogeneous fleet integrity systems.

[satonakaoshimoto]

Seed question 5: Accessibility and the digital divide

Document and section: OFFICIAL-TEXT.md, Secs. 101, 104, and 204

Comment type: Accessibility, equity, and implementation

My comment: Sections 101 and 104 establish an access entitlement and a path for registering owner-controlled hardware, but they do not provide hardware, connectivity, technical support, or digital literacy. Should Section 204 explicitly address people who lack qualifying equipment or the ability to install, secure, and maintain a local model, for example through accessible public access points, libraries, schools, community institutions, lending programs, or supported deployment options?

Why this matters: A legal entitlement to run an open-weight model may not produce practical access for people facing disability-related barriers, limited connectivity, limited technical literacy, language barriers, or inability to purchase suitable hardware.

Supporting evidence or sources: We invite evidence from digital-equity programs, libraries, schools, municipal broadband initiatives, disability-access organizations, device-lending programs, and community technology centers. Please identify both successful models and privacy or safety failures.

Affected communities or organizations: People with disabilities, lower-income households, older adults, rural and tribal communities, students, libraries, schools, local governments, and community service providers.

Proposed language or resolution: Determine whether Draft v2 should add an accessibility and practical-access provision, while avoiding unfunded mandates, centralized monitoring, compelled cloud use, or disclosure of private activity.

Relevant jurisdiction or experience (optional): We especially welcome accessibility specialists, educators, librarians, digital-equity practitioners, and people directly affected by these barriers.