Remark. Different recipes under equal tuning effort [ftip-00LW]
✍️source

Under the equal-tuning-budget arm, the two selected model instances may use different recipes. That difference is compatible with equal predeclared tuning effort; forcing the selected recipes to match would answer a different comparison question.

Context

Study design for comparisons across model instances [ftip-00LS]

This subsection specifies how a conditional architecture comparison may be instantiated without changing the architecture-neutral formulation. It is a study design, not a universal ranking of architectures.

Definition. Matched model-instance record [ftip-00LT]

A model-instance record names the architecture, parameterization or checkpoint, training and post-training recipe, optimizer, execution stack, inference budget, task family, evaluation law, and recorded cost vector. Two records are comparable only after the fields held fixed and the fields allowed to vary are declared.

Definition. Pair identity and comparison unit [ftip-00LU]

A comparison unit is a pair of model-instance records evaluated on the same task family and evaluation law, together with a declared cost scalarization. A Transformer reference and a Kimi Delta Attention instance may form such a pair only when the remaining coordinates are documented.

Remark. Paired responses to a common recipe [ftip-00LV]

For a pair of matched model-instance records, the common-recipe arm measures how the permitted architecture packages respond to one recipe. A score advantage in this comparison need not persist after either package is retuned.

Remark. Different recipes under equal tuning effort [ftip-00LW]
✍️source

Remark. How an allowed class changes its envelope [ftip-00LX]

In the restricted-envelope arm, enlarging an allowed intervention class at fixed evaluation law, cost accounting, and budget can raise its envelope and cannot lower it. A finite search over feasible interventions supplies a lower bound from the scores it attains. It certifies the supremum only if it covers every feasible intervention or is accompanied by a matching upper-bound argument.

Remark. Coordinate-change rule [ftip-00LY]

Changing the optimizer, post-training method, hardware or kernel, precision, context policy, or evaluation law changes a comparison coordinate. A score difference after such a change belongs to the new intervention, unless the study explicitly estimates the interaction.

Definition. Architecture-family transfer matrix [ftip-00LZ]

A transfer matrix records which interfaces, intervention arms, and budgets permit a comparison. Each row is a study record: its source, estimand, matched controls, evaluation coordinates, and declared scope boundary are explicit. A blank or incompatible cell is an incomparability finding, not a missing score to be imputed. The vector and evaluation coordinates are reported together under the conditional frontier of Definition [ftip-00JM].

Comparison cell	Source	Estimand	Matched controls	Cost / stability / monitorability	Status and scope boundary
Transformer--KDA/full attention	Remark [ftip-00KF], Definition [ftip-00LU], Example [ftip-00LQ]	Difference in utility, cost, and \(K_{\rm state}\) between KDA and full attention	Same task, model scale, recipe, context, seeds, and evaluation law	Report measured cost vector, training/inference stability, and state/failure observability	Open; a finite KDA--Transformer result does not establish an architecture-wide ceiling
Transformer--Mamba	Mamba, Sections 3.1--3.3; § [ftip-00OQ]	Difference in retrieval utility and \(K_{\rm state}\) at the declared budget	Task, scale, recipe, context, and inference budget	Report cost vector, recurrence stability, and state/failure observability	Open; selective compression does not transfer a retrieval result across tasks
Transformer--linear attention	Linear attention, Sections 3.2--3.3; § [ftip-00OQ]	Difference in retrieval utility and \(K_{\rm state}\) for associative summaries	Task family, feature map, context budget, and evaluation law	Report prefix cost, numerical stability, and summary-state observability	Open; associative summaries do not imply full-attention equivalence
Transformer--CTM or looped model	Continuous Thought Machine, Sections 3.1--3.5; § [ftip-00KG]; § [ftip-00OQ]	Difference in utility and \(K_{\rm adapt}\) per charged tick or loop	Input, base model, stopping rule, recipe, and charged internal compute	Report tick/loop cost, training and inference stability, and stopping-signal monitorability	Open; extra passes are charged and do not imply continuous-time behavior
Transformer--BDH	BDH, Section 3.2; § [ftip-00OQ]	Difference in task utility and \(K_{\rm state}\) under the reduced state interface	Task, state parameterization, credit horizon, systems stack, and cost	Report memory and compute cost, optimization stability, and state observability	Open; a reduced state-space proposal is not a production transfer result
Core architecture--JEPA adjunct	I-JEPA, Section 3; § [ftip-00OQ]	Conditional change in \(K_{\rm repr}\) and \(K_{\rm plast}\) after the objective intervention	Same base artifact, target task, predictor budget, data, and optimizer arm	Report intervention cost, training stability, and representation/probe monitorability	Conditional; an objective intervention is not a replacement architecture
I-JEPA--SplitJEPA	SplitJEPA, Sections 3.1--3.4; § [ftip-00OQ]	Subspace identifiability and conditional change in \(K_{\rm repr}\)	Matched invariant correspondences, variant-rank premise, normalization, and encoder budget	Report probe cost, numerical and optimization stability, and subspace monitorability	Conditional; identifiability does not become a general I-JEPA guarantee
Core architecture--liquid dynamics	Liquid time-constant networks, Sections 1--2; § [ftip-00OQ]	Difference in utility and \(K_{\rm adapt}\) under the solver intervention	Input law, solver, step budget, tolerance, task, and cost vector	Report solver cost, numerical stability, and trajectory/failure monitorability	Open; continuous dynamics and solver choices remain intervention coordinates
Core architecture--Neural Operator	Neural Operators, Section 3; § [ftip-00OQ]	Difference in utility and \(K_{\rm repr}\) across discretizations	Function-space task, discretization family, operator layer, and evaluation law	Report training/inference cost, discretization stability, and field-observation monitorability	Open; discretization invariance under one source formulation is not task transfer

A completed row must report its paired observations through § [ftip-00L4] and the common-recipe, equal-tuning, and restricted-envelope arms of § [ftip-00JU]. Until those records are supplied, its status remains open or incompatible.

Remark. Applying a finite model to an architecture [ftip-00M0]

A toy representation or recurrence result may motivate a hypothesis, but it is not transferred to a model instance until its interface, task, cost accounting, numerical regime, and evaluation protocol are instantiated and checked. If any required assumption is unverified, applicability to the model instance remains unestablished.

Definition. Negative-result and stopping report [ftip-00M1]

A completed comparison reports the tested cost grid, excluded configurations, stopping rule, uncertainty, and negative results. Stopping without a detected difference is evidence about the declared study, not proof that the architectures have equal potential.

Remark. Open comparison questions [ftip-00M2]

The matrix in Definition [ftip-00LZ] is a protocol map, not a result table. The following probes keep the five capability coordinates separate and leave an unknown cell visible until the required records exist. Each probe names its source, estimand, controls, and evaluation coordinates so that a missing record cannot be mistaken for a zero score.

State access. Sources: Mamba, Sections 3.1--3.3 and linear attention, Sections 3.2--3.3. Estimand: the paired difference in retrieval utility and \(K_{\rm state}\). Controls: Transformer, Mamba, and linear-attention systems on a predeclared retrieval and continuation suite at matched parameter, context, recipe, and cost budgets. Evaluation: report cost, recurrence or summary stability, and state observability. Scope boundary: a long-context score does not transfer to another task family without its task and transport record.
Adaptive computation. Source: Continuous Thought Machine, Sections 3.1--3.5 and the looped-model contract in § [ftip-00KG]. Estimand: the paired change in utility and \(K_{\rm adapt}\) per charged internal tick or loop. Controls: common input, base model, recipe, stopping rule, and charged internal compute. Evaluation: report tick/loop cost, training and inference stability, and stopping-signal monitorability. Scope boundary: an observed adaptive gain remains conditional on that stopping law.
Representation and abstraction. Sources: I-JEPA, Section 3 and SplitJEPA, Sections 3.1--3.4. Estimand: subspace identifiability and the conditional change in \(K_{\rm repr}\). Controls: fixed correspondences, full-rank variant differences, normalization, encoder budget, and matched downstream probes. Evaluation: report probe cost, optimization stability, and subspace monitorability. Scope boundary: the conditional subspace result is separate from downstream task transfer; failure of a premise is an incompatible cell, not a zero score.
Plasticity. Source: the objective and optimizer interfaces in Definition [ftip-00JM] and the I-JEPA intervention description in § [ftip-00OQ]. Estimand: the paired change in \(K_{\rm plast}\) after a declared post-training intervention. Controls: common recipe and equal-tuning arms with data, optimizer, trial count, stopping, and feedback fixed or explicitly varied. Evaluation: report intervention cost, training stability, and update-signal monitorability. Scope boundary: an intervention effect is limited to the declared base artifact, task, and objective; it does not transfer across architectures without a new paired record.
Portability. Sources: the Mamba, BDH, and Neural Operator method descriptions in § [ftip-00OQ]: Mamba, BDH, and Neural Operators. Estimand: survival of the declared utility and \(K_{\rm port}\) across one transfer edge. Controls: source model, task family, model scale, deployment regime, evaluation law, and cost vector retained as paired fields. Evaluation: report migration cost, stability after the shift, and failure monitorability. Scope boundary: evidence for one transfer edge does not order unmeasured edges; blank edges remain unmeasured.
Adjunct interactions. Sources: liquid time-constant networks, Sections 1--2, Neural Operators, Section 3, and I-JEPA, Section 3. Estimand: the joint change in the declared capability coordinates after an explicit intervention. Controls: declared core model, objective, temporal law, function-space bias, matched controls, and separate single-intervention arms. Evaluation: report joint and marginal costs, numerical/training stability, and interaction monitorability. Scope boundary: a joint effect is limited to the declared core, task, temporal law, and function-space regime; it does not transfer across regimes without separate intervention records.

These probes do not establish a common ordering of architecture families. They specify what would count as evidence for a declared bottleneck change, while cost, numerical stability, monitorability, and transfer remain separate evaluation coordinates. Paired observations should use § [ftip-00L4], the study arms of § [ftip-00LS], and the capability vector of Definition [ftip-00JM].

Definition. Equal-tuning-budget comparison arm [ftip-00JW]

An equal-tuning-budget arm permits architecture-specific tuning under a predeclared protocol that fixes the tuning data and its volume, trial count, selection rule, stopping rule, and tuning cost for both architectures. The cost uses the same declared accounting rule. The resulting comparison measures practical performance under this equal optimization effort; it does not determine best possible training or a representation-only limit.