TAS-R1: Minimal Transformer size for article-equivalent behavior

[AtlantisPleb]

Summary

• find the smallest Transformer that still exhibits article-equivalent
  behavior on the declared canonical route

Roadmap Position

• Phase: Optional research-only follow-on
• Sequence: article-gap closure after TAS-156A
• Owned-route boundary: any canonical article route referenced here means the psionic-transformer-based route established by TAS-156A / TAS-160, not a reintroduced mixed implementation spread across model or runtime crates.
• Status: research-only follow-on; explicitly non-blocking for article-equivalent closure

Why This Matters

• it distinguishes real algorithmic structure from brute-force scale
• it gives the article-closeout program scientific leverage beyond one green
  implementation

Status

• explicitly non-blocking for article closure

Claim Discipline

• Keep machine-legible boundaries explicit; partial progress must not be presented as full article equivalence.
• Preserve typed refusal, fallback, blocked, and suppressed posture where closure is still incomplete.
• Keep public language bounded to the declared article envelope rather than implying generic arbitrary-program closure from a partial green result.

[AtlantisPleb]

I dug through the current article-equivalence stack to figure out what implementing this honestly would require.

Current repo truth:

• TAS-R1 is already marked optional_research in the blocker matrix and is tied only to BEQ-003, BEQ-004, and BEQ-007.
• The current canonical trained article model is TassadarArticleTransformer::trained_trace_domain_reference() in crates/psionic-models/src/tassadar_article_transformer.rs.
• Its committed descriptor is currently:
  • vocab 303/303
  • hidden size 8
  • feed-forward size 16
  • heads 2
  • encoder layers 2
  • decoder layers 2
  • max positions 16384 / 16384
  • 88 tensors / 10,583 total weight scalars in the committed descriptor
• The current produced weight artifact is not a full-model train. crates/psionic-train/src/tassadar_article_transformer_weight_production.rs currently trains only logits_projection_bias (303 scalars) on a bounded suite with train=hungarian_matching and held-out=micro_wasm_kernel, branch_heavy_kernel, memory_heavy_kernel.
• The current committed evidence this issue has to preserve if we say “article-equivalent behavior” in repo terms is:
  • fixture parity: 13/13 exact trace and exact output, 13/13 supported and routeable
  • reference-linear exactness: 13/13 exact, 0 mismatches, 0 refusals, direct proof 3/3 direct + fallback-free + zero external calls
  • generalization: 6/6 exact out-of-distribution cases
  • fast route: architecture selection green on HullCache, exactness green on 3 direct + 3 hybrid cases, throughput floor green with 2 public demo passes, 2 internal demo passes, and 4 kernel passes

Main implementation constraint:

The training surface is already config-driven, but most of the evaluation/report stack is wired to the single committed trained descriptor, lineage contract, and report refs. So a size sweep cannot just rerun today’s canonical reports against smaller models. Several of those reports will fail on artifact identity even if the smaller model still preserves behavior.

Concretely:

• crates/psionic-train/src/tassadar_article_transformer_training.rs already accepts arbitrary EncoderDecoderTransformerConfig.
• crates/psionic-train/src/tassadar_article_transformer_weight_production.rs also accepts arbitrary config, but reference() and validate_against_base_model() are currently anchored to the fixed trace-bound reference model/artifact.
• crates/psionic-models/src/tassadar_article_transformer.rs already gives us the right primitives for candidate artifacts: paper_faithful_reference(...), with_model_identity(...), and write_artifact_bundle(...).
• The real blocker is eval/report identity coupling in the current canonical builders, especially:
  • crates/psionic-eval/src/tassadar_article_fixture_transformer_parity.rs
  • crates/psionic-eval/src/tassadar_article_transformer_reference_linear_exactness_gate.rs
  • crates/psionic-eval/src/tassadar_article_transformer_generalization_gate.rs
  • crates/psionic-eval/src/tassadar_article_fast_route_architecture_selection.rs
  • crates/psionic-eval/src/tassadar_article_fast_route_implementation.rs
  • crates/psionic-eval/src/tassadar_article_fast_route_exactness.rs
  • crates/psionic-eval/src/tassadar_article_fast_route_throughput_floor.rs
  • crates/psionic-eval/src/tassadar_article_transformer_weight_lineage.rs

Those modules currently read the committed canonical refs and/or assert canonical model ids / lineage refs. That is correct for closure artifacts, but it means a TAS-R1 sweep needs candidate-aware research reports instead of trying to overload the canonical ones.

Proposed implementation plan:

1. Add a research-only candidate config frontier.

• Introduce a TAS-R1 candidate table under a research-only run/report root.
• Keep tokenizer/vocab fixed to the current trace-domain vocab.
• Keep max positions fixed to the current 16384 on the first pass so the sweep measures model capacity, not trivial window invalidation.
• Start by shrinking the actual capacity knobs that reduce model size:
  • hidden size
  • feed-forward size
  • encoder depth
  • decoder depth
• I would keep head_count=2 initially and preserve divisibility constraints, then only touch head count if the first sweep says it is still worth doing.
• The first descending family I would queue is:
  • baseline: h=8, ff=16, enc=2, dec=2, heads=2
  • width shrink: h=6, ff=12, enc=2, dec=2, heads=2
  • width shrink: h=4, ff=8, enc=2, dec=2, heads=2
  • depth shrink: h=8, ff=16, enc=1, dec=1, heads=2
  • combined shrink: h=6, ff=12, enc=1, dec=1, heads=2
  • combined shrink: h=4, ff=8, enc=1, dec=1, heads=2
• Each candidate should get its own model id, descriptor, artifact, and lineage identity via with_model_identity(...) + write_artifact_bundle(...).

2. Split behavior checking from canonical artifact identity.

• Extract the current behavior-checking core so it can evaluate an explicit TassadarArticleTransformer plus candidate-specific refs.
• Keep today’s public report builders exactly as thin wrappers around the canonical trained model.
• Add research-only TAS-R1 builders that reuse the same logic without asserting that the candidate must equal tassadar-article-transformer-trace-bound-trained-v0.

3. Add candidate-specific lineage instead of reusing the canonical TAS-169A lineage contract.

• Today’s lineage contract intentionally freezes the current produced model id, current trainable surface, and trainable_parameter_scalar_count == 303.
• That is correct for the canonical artifact, but every TAS-R1 candidate needs its own research lineage record.
• I would keep the canonical lineage contract unchanged and add a research-only candidate lineage manifest that records:
  • candidate config
  • model id / descriptor digest / artifact digest
  • trainable surface
  • train and held-out case set
  • proof/report refs tied to that candidate

4. Run the sweep as a funnel instead of paying full evaluation cost on every candidate.

• Stage A: candidate bootstrap / cheap pruning
  • descriptor + artifact write
  • suite construction
  • weight-production smoke
  • checkpoint restore / artifact reload parity
• Stage B: article-equivalent behavior checks
  • fixture parity (13 declared cases)
  • reference-linear exactness (13 declared cases)
  • generalization (6 OOD cases)
• Stage C: preserve the BEQ-004 / BEQ-007 properties only on survivors
  • direct model-weight proof: 3 required cases, all direct, all fallback-free, zero external calls
  • fast-route selection remains HullCache
  • fast-route exactness remains green
  • throughput-floor remains green

5. Publish one research-only frontier report instead of mutating the acceptance gate.

• I would model this after the existing experiment-queue / ablation patterns in psionic-research.
• The output should make one thing machine-readable:
  • frozen baseline candidate
  • ordered smaller candidates
  • exact parameter count for each candidate
  • which gates passed or failed first
  • smallest candidate that still preserves the current article-equivalent behavior envelope
  • first failing frontier and its failure surface

What I would explicitly not do:

• I would not replace the canonical trained article model or canonical report refs while doing TAS-R1.
• I would not count toy training closure as sufficient evidence for this issue.
• I would not call a candidate “good enough” unless it preserves the direct-proof / no-external-call / fast-route behavior that TAS-R1 is tied to through BEQ-003, BEQ-004, and BEQ-007.

If I were implementing this next, I would start by extracting candidate-aware helpers out of parity / exactness / generalization, then add a small research-only frontier with the six configs above and let the first sweep tell us where the actual break point is.

[AtlantisPleb]

Merged in #356.

Landed outcome:

• added the research-only TAS-R1 minimal frontier report at fixtures/tassadar/reports/tassadar_article_transformer_minimal_frontier_report.json
• committed candidate-specific base/trained artifacts, weight-production bundles, and lineage manifests under fixtures/tassadar/runs/tassadar_article_transformer_minimal_frontier_v1/
• added the checker at scripts/check-tassadar-article-transformer-minimal-frontier.sh

Current frontier result:

• all 6 candidate configurations pass Stage A and Stage B
• all 6 fail Stage C at fast-route selection
• frontier_green=false, so there is no minimal successful candidate in the current reduced set

This keeps the canonical article-equivalence acceptance gate, canonical TAS-169A lineage contract, and canonical HullCache claim unchanged.