TAS-095: Named Rust/Wasm profile ladder and claim checker

[AtlantisPleb]

Summary

Define the first post-article named internal-compute profile ladder and claim checker so Tassadar can widen beyond article closure without collapsing into a vague "supports Rust/Wasm" claim.

Problem

The article-closeout tranche leaves the repo with strong bounded evidence, but still only for one narrow family.

Current starting point:

• fixtures/tassadar/reports/tassadar_rust_source_canon_report.json freezes the Rust-only frontend canon for the committed kernel, heap-input, long-loop, Hungarian, and Sudoku fixtures.
• fixtures/tassadar/reports/tassadar_wasm_instruction_coverage_report.json still centers the current article claim on tassadar.wasm.article_i32_compute.v1.
• That article profile is still i32-first only: it admits i32_const, local_get, local_set, i32_add, i32_sub, i32_mul, i32_lt, i32_load, i32_store, br_if, output, and return, with max_locals=16, max_memory_slots=64, max_program_len=4096, and max_steps=131072.
• fixtures/tassadar/reports/tassadar_rust_article_profile_completeness_report.json already makes the current claim boundary explicit: bounded i32-first families only, direct scalar i32 and pointer-length heap-input closure only, and no arbitrary Wasm, broad host-import, or general parameter-ABI claim.

That is enough to replace vague article rhetoric with a bounded profile, but not enough to support the next honest widening step. Without a machine-readable profile ladder and a claim checker, the repo is one sentence away from over-claiming “general Rust/Wasm support.”

Hypothesis

A named profile ladder over article-closeout, generalized ABI, wider numeric or data-layout families, runtime-support, import-mediated, and resumable regimes will keep every future claim challengeable and publication-safe.

Source Papers / Docs

• Can LLMs Be Computers?
• On the Turing Completeness of Modern Neural Network Architectures
• Universal Transformers
• docs/ROADMAP_TASSADAR.md
• docs/TASSADAR_WASM_RUNBOOK.md

Target Surfaces

• psionic-ir
• psionic-compiler
• psionic-runtime
• psionic-provider
• psionic-eval
• psionic-research
• psionic-environments
• fixtures/tassadar/reports/

Initial Scope

• Publish a machine-readable post-article profile ladder instead of one implicit “current article profile”.
• Define per-profile admitted Wasm features, ABI shapes, memory semantics, import posture, exactness posture, portability posture, and refusal classes.
• Add a claim checker that rejects capability publication when a profile claim lacks complete evidence.
• Thread profile identity into environment bundles, capability publication, route negotiation, and benchmark reports.
• Keep still-unsupported families explicit instead of silently widening the current article profile.

Benchmark / Tests

• Profile-checker tests over supported, incomplete, and over-claimed profile declarations.
• Coverage-matrix tests that diff admitted vs refused module, control-flow, numeric, and ABI families.
• Capability-publication suppression tests when a claimed profile lacks evidence or portability posture.
• Environment-bundle and provider-receipt tests that preserve the declared profile id end to end.
• Regression tests ensuring the current article-closeout profile remains intact while new profiles stay separate.

Claim Discipline

This issue exists to prevent vague generality claims. It must not be closed by renaming the current article profile or by publishing a catch-all “Rust/Wasm supported” sentence.

Done When

• Tassadar has a machine-readable post-article profile ladder.
• Every public or served internal-compute claim cites a named profile.
• Each profile names its admitted features, refusal classes, and evidence requirements.
• Publication fails when a claimed profile lacks complete benchmark, portability, or refusal evidence.

[AtlantisPleb]

Landed on main in f633806.

Implemented the named post-article internal-compute profile ladder and claim checker across the shared model contract, environment bundles, served capability publication, provider envelopes, planner route descriptors, and committed eval/research artifacts. psionic-models now freezes the ladder with tassadar.internal_compute.article_closeout.v1 as the only currently implemented rung and keeps generalized ABI, wider numeric/data-layout, runtime-support subset, deterministic-import subset, resumable multi-slice, portable broad-family, and public broad-family profiles explicit as planned future rungs. psionic-environments, psionic-serve, psionic-provider, and psionic-router now carry the current green claim check end to end so public and routeable internal-compute claims cite a named profile instead of drifting into vague Rust/Wasm language. The committed artifacts are fixtures/tassadar/reports/tassadar_internal_compute_profile_ladder_report.json and fixtures/tassadar/reports/tassadar_internal_compute_profile_ladder_summary.json.

Validation run:

• cargo test -p psionic-models internal_compute_profile -- --nocapture
• cargo test -p psionic-environments tassadar_environment_bundle_is_machine_legible -- --nocapture
• cargo test -p psionic-serve capability_publication -- --nocapture
• cargo test -p psionic-serve planner_router_route_capability_descriptor_is_machine_legible -- --nocapture
• cargo test -p psionic-provider tassadar_capability_envelope -- --nocapture
• cargo test -p psionic-provider tassadar_planner_route_capability_envelope -- --nocapture
• cargo test -p psionic-router tassadar_route_negotiation -- --nocapture
• cargo run -p psionic-eval --example tassadar_internal_compute_profile_ladder_report
• cargo test -p psionic-eval internal_compute_profile_ladder -- --nocapture
• cargo run -p psionic-research --example tassadar_internal_compute_profile_ladder_summary
• cargo test -p psionic-research internal_compute_profile_ladder_summary -- --nocapture