Skip to main content

69  CoilRA, MultiCoil RoPE, and Cyclic Mixers

69.1 Chapter status

Field	Value
Chapter ID	coilra-multicoil-rope-and-cyclic-mixers
Part	Part III - Routing, Compression, Representation, and Substrates
Status	conceptual
Manuscript maturity	v0.3 manuscript draft
Last updated	2026-08-08
Primary source records	coilra_multicoil_rope, rope_position_certifier, circle_ai_contract_suite, theseus_circle_transfer, circle_ai_architectures
Claim label	Design rationale
Evidence level	argument
Source queue	primary: coilra_multicoil_rope, rope_position_certifier; supporting: circle_ai_contract_suite, theseus_circle_transfer, circle_ai_architectures; external variants: ext_roformer_rope_2021, ext_lora_2021, ext_mamba_2023, ext_retnet_2023
Source loading state	source notes: coilra_multicoil_rope, rope_position_certifier, circle_ai_contract_suite, theseus_circle_transfer, circle_ai_architectures
Test state	cyclic_mixer_evaluation_record.valid.json passes repository-level protocol fixture validation; the exact 23-declaration AsiStackProofs.CyclicMixers surface adds arbitrary-run candidate custody, zero-authority and gate-coherence invariants, trace composition, reachable canary eligibility, regression fallback, absorbing retirement, and structural-summary insufficiency. python3 scripts/validate_circle_cyclic_mixer_receipt_slice.py recompiles the module, preserves the pinned Circle receipt, checks all six trace splits, explores 35 reachable states through 700 transitions, checks 340 transitions from 17 retired states, and rejects 18 semantic mutations. The RoPE and MultiCoil receipt validators remain structural-only; cyclic mixer, phase, MLX, kernel, quality, context, parameter, runtime, and deployment tests remain planned.

69.2 Drafting guardrail

This lane treats cyclic adapters, phase banks, RoPE certifiers, and cyclic mixers as optional substrate candidates. It does not claim better perplexity, longer context, faster runtime, lower memory, training stability, or deployment readiness.

Structural contracts already apply to memory and recurrence. The same boundary must reach model-internal cyclic structure: adapters, phase banks, position encodings, route heads, and mixers. The core question is not whether a cyclic invariant exists; it is whether that invariant survives contact with baselines, kernels, parameter accounting, failure cases, and workload metrics.

The adoption object is a tradeoff packet. A cyclic proposal should say which structural receipt it has, which workload it targets, which ordinary baselines it faces, which resource costs it pays, and which non-claims must follow it.

69.3 Human Reading Path

Concrete lens. A parameter-count-only baseline would declare a 16-fold reduction and stop. The chapter keeps structural, resource, and empirical ledgers separate and refuses adoption while the latter two are incomplete.

The same discipline now moves inside model mechanisms under review: cyclic adapters, phase banks, RoPE variants, route heads, and mixers. These may become useful substrate candidates, but the stack treats them as candidates until baselines, diagnostics, and failure cases exist.

The essential discipline is to keep mechanism and evidence separate. A cyclic mixer can be interesting as structure, but it does not become better context, faster inference, lower memory, or stronger reasoning until the stack can show the relevant workload, baseline, metric, artifact, and boundary. That keeps elegant geometry from becoming performance mythology before measurements exist. Candidate mechanisms should compete against ordinary baselines before they shape governance.

A beautiful mechanism earns architectural weight only after comparison makes its contribution legible. The decisive test is traceable advantage under the right workload, not novelty, and the comparison record decides whether the mechanism becomes architecture or ornament. Until then, elegance remains a candidate rather than a license to skip ordinary baselines; position schemes need receipts, and those receipts have to be earned under actual workloads.

69.4 Problem

Position encodings, adapters, route heads, and mixers can contain real cyclic or block-cyclic structure. When they do, proofs and structural diagnostics can prevent confusion about residues, winding, collisions, load, parameter counts, and shift-equivariance. But those structural facts are not model-quality facts.

CoilRA, MultiCoil RoPE, RoPE position distinguishability, circulant mixers, and block-cyclic adapters need a bounded evaluation lane that neither dismisses them nor overpromotes them.

Adoption scope is the pressure point. A cyclic mixer can be structurally interesting and still wrong for a workload, too costly for deployment, too fragile under sequence shift, or too easy to confuse with a quality improvement. The evaluation lane therefore has to separate exact cyclic facts from evaluation, fallback, routing, and support-state effects before any substrate becomes architecture. That separation matters because cyclic machinery is attractive precisely where it compresses structure into elegant math; without evidence boundaries, elegance can become a shortcut around baseline comparison, ablation, and workload-specific refusal.

69.5 Why existing approaches are insufficient

Parameter-count, equivariance, or exact phase facts can be mistaken for better model behavior unless baselines, hardware costs, alias and load diagnostics, and failure cases are separated. A passing RoPE certifier is not a context-length result. A circulant mixer law is not a speed result. A lower parameter count is not an adoption proof. Prime or coprime elegance can conflict with hardware-friendly shapes.

Circle AI Architectures gives the right rule: use cyclic structure where the data, model, or computation really has phase, recurrence, rotation, sparse cyclic mixing, circular memory, harmonic structure, or geometry-aware structure. Otherwise use ordinary baselines.

That rule is a defense against aesthetic adoption. Cyclic structure can be beautiful and still wrong for the workload. A phase bank can be exactly described and still hurt optimization. A mixer can reduce parameters and still run poorly on available hardware. A RoPE receipt can distinguish positions inside its declared model and still say nothing about whether a trained model uses longer context well. Separate ledgers keep those cases apart so structural clarity does not become performance mythology.

The adoption question is therefore comparative. What does the cyclic candidate do better than dense layers, LoRA variants, ordinary RoPE, learned positional encodings, recurrent memory, state-space models, or nonperiodic controls? What does it make worse? Which hardware shape does it assume? Which alias or load diagnostic would block it? Without those answers, the cyclic substrate can remain a research candidate but not a default route.

Cross-ledger spending is the cyclic-substrate adoption failure. A substrate wins a structural ledger entry, then spends that win as if it were a quality result, runtime result, memory result, or hardware result. Each ledger should have to earn its own evidence.

External positioning: CoilRA and cyclic mixers now have source-noted comparator families through ext_roformer_rope_2021, ext_lora_2021, ext_mamba_2023, and ext_retnet_2023. RoFormer grounds ordinary RoPE as the position-encoding baseline. LoRA grounds low-rank adapter comparison. Mamba grounds state-space sequence-substrate comparison. RetNet grounds recurrence/attention and recurrent-computation tradeoffs. These records make the required baseline set explicit, but they do not reproduce any baseline matrix here and they do not support a CoilRA model-quality, context-length, runtime, memory, training-stability, hardware-efficiency, or deployment claim.

69.6 Core Claim

Reader claim. A cyclic mechanism becomes an architectural option only when its structural receipt, workload behavior, hardware cost, and fallback decision can be inspected separately.

Operational rule. Spend proof or receipt evidence only on the structural axis it checks. Require matched ordinary baselines, quality and cost measures, failure cases, and a tested fallback before a cyclic candidate can change a route or enter a canary.

[coilra-multicoil-rope-and-cyclic-mixers.core, label: Design rationale, support: argument] CoilRA, MultiCoil RoPE, and Cyclic Mixers owns a model-, layer-, mechanism-version-, workload-, baseline-, kernel-, hardware-, claim-axis-, and time-specific Cyclic Mechanism Tradeoff Packet: a cyclic adapter, phase bank, rotary scheme, route head, circulant operator, or block-cyclic mixer may enter a canary only when exact residue/winding, phase horizon, alias/collision/load, dense-reference parity, parameter and operation accounting, numerical error, kernel availability, complete cost, quality, failure, fallback, and rights evidence is matched against strong ordinary controls; equivariance, finite proofs, receipt validity, parameter reduction, or structural parity alone confers no quality, context-length, speed, memory, stability, efficiency, safety, deployment, transfer, support, or SOTA authority.

The distinct owner is not general substrate adoption—that belongs to Mathematical and Search Substrates. The cyclic-specific layer owns the tradeoff packet that adoption consumes: phase and winding diagnostics, dense-reference parity, complete parameter/operation accounting, real kernel and hardware behavior, and axis-separated model evidence for one exact mechanism and layer.

The claim remains at argument support. The source notes support discussion of cyclic adapter/mixer contracts, exact/discretized phase-bank receipts, residue/winding diagnostics, parameter accounting, baselines, controls, and non-claims. They do not support model improvement claims here.

69.6.1 Claim-source mapping status

Appendix C now records passage-reviewed mappings for all five assigned sources. The mappings support cyclic adapter/mixer boundaries, exact/discretized phase-bank receipts, residue/winding diagnostics, parameter accounting, baseline requirements, consumer-gate fields, and transfer non-claims, not model-quality, runtime, memory, training-stability, context-length, hardware-efficiency, deployment, or promotion claims.

Source	What it supports	Limit
coilra_multicoil_rope	Adapter-block indices, residue/winding, block-cyclic routes, multicoil phase, relative RoPE laws, circulant mixers, parameter accounting, baselines, alias/load diagnostics, and explicit non-claims.	Structural/proof-linked source only; no ASI Stack MLX run, model-quality result, speed result, memory result, training-stability result, hardware-efficiency result, or context-length improvement was run or imported here.
rope_position_certifier	Exact/discretized RoPE receipt boundaries through phase-channel residues, phase-bank collisions, bounded prefix reports, theorem ids, machine-readable certificates, one-channel real-phase frontier, and numerical real-phase diagnostics as non-proof.	No RoPE certifier run, sidecar regeneration, Circle Lean build, full all-channel real-valued RoPE theorem, model-quality result, speed result, memory result, training-stability result, deployment result, or long-context claim is supported here.
circle_ai_contract_suite	Contract-family fields for RoPE, multicoil phase, cyclic mixers, receipts, theorem ids, consumer readiness, fingerprints, normalized parameters, acceptance-policy surfaces, and explicit boundaries/non-claims.	Separate external Circle rope, MultiCoil phase, and cyclic-mixer receipt slices are recorded in docs/circle_external_receipt_slice.md, docs/circle_multicoil_phase_receipt_slice.md, and docs/circle_cyclic_mixer_receipt_slice.md, but no vendored contract pack, downstream consumer, acceptance-policy integration, transfer consumer, model-quality result, or external Circle Lean dependency is validated from this repo.
theseus_circle_transfer	Phase-feature invariance, mixer parameter accounting, report-only consumers, workload smoke/proxy/scored layers, baseline/negative-control/report requirements, and disallowed public quality/runtime/memory/transfer claims.	Source-reported private transfer artifacts remain nonlocal context; no ASI Stack transfer consumer, smoke workload, proxy benchmark, scored private benchmark import, inference run, report artifact, router-head trace, runtime/memory measurement, or promotion evidence was executed or imported.
circle_ai_architectures	Cyclic or coil structure only where phase, recurrence, rotation, sparse cyclic mixing, circular memory, harmonic/circulant structure, or geometry-aware structure is real and controlled by baselines and negative controls.	No universal cyclic-model advantage, ASI Stack sidecar test, ASI Stack MLX experiment, imported benchmark fixture, model-quality result, speed result, memory result, or deployment result was run or imported here.

69.7 Draft Key Figure: Cyclic Substrate Adoption Gate

Figure 69.1: Draft cyclic substrate adoption gate.

How to read the cyclic substrate adoption figure: Read the top path as an adoption gate and the lower path as a refusal to spend structural credit as performance evidence. A cyclic candidate can have a real invariant, theorem id, digest, diagnostic, or receipt and still remain structural-only until ordinary baselines, measured tradeoffs, canary limits, rollback, and retirement paths are present. Parameter count, elegance, and exact cyclic facts do not by themselves become model quality, context length, runtime, memory, training-stability, hardware-efficiency, deployment, or support-state claims. The figure is a draft reader aid, not a release-reviewed artifact or evidence that a cyclic substrate should be adopted.

69.8 Mechanism

Cyclic mixer adoption is where structural proof, parameter accounting, and hardware reality meet. coilra_multicoil_rope supplies the adapter, phase, RoPE, circulant, block-cyclic, and parameter-accounting frame. The RoPE certifier supplies exact/discretized position-bookkeeping receipts. The Circle contract suite supplies consumer fields and non-claims. Theseus transfer requires workload, baseline, negative-control, metric, script, and report boundaries. Circle AI Architectures supplies the anti-fashion rule: use cyclic structure only where phase, recurrence, rotation, sparse cyclic mixing, circular memory, harmonic structure, or geometry-aware structure is actually present.

A Cyclic Mixer Evaluation Record keeps those layers separated. It can report evaluation state, workload target, structural invariant, receipt refs, receipt boundary, claim partitions, alias/load diagnostics, parameter accounting, hardware notes, baseline matrix refs, baseline symmetry, negative controls, failure-case refs, resource costs, metrics status, consumer policy, and hardware refusal path while still refusing to claim quality, runtime, memory, training stability, context length, or deployment readiness without measured tradeoffs.

A cyclic-substrate adoption record makes three ledgers visible at once. The structural ledger names the invariant and receipt boundary. The resource ledger names parameters, kernel shape, memory, latency, and hardware assumptions. The empirical ledger names baselines, metrics, failures, and adoption state. A strong cyclic proposal eventually has to survive all three; a result in one ledger should not silently spend credit in another.

A RoPE or cyclic-mixer receipt should also name its consumer policy. Some consumers may accept a structural receipt for diagnostic use, reject it for quality promotion, or require a benchmark before canary routing. Without consumer policy, a receipt can be technically valid and operationally misused.

The mechanism therefore routes cyclic evidence through a consumer decision before it reaches adoption. A diagnostic consumer may accept a receipt because it wants to know whether a declared position-bookkeeping boundary is internally coherent. A routing consumer should ask for workload evidence before using the same receipt to change model selection, memory policy, or substrate defaults. A release consumer should ask for baselines, negative controls, hardware notes, regression behavior, and rollback before calling the mechanism ready. Those consumers can share the same receipt while refusing different claims, which is the point of keeping structural, resource, and empirical ledgers separate.

69.8.1 Worked receipt-to-refusal trace: the 128-channel block-cyclic candidate

The recorded Circle mixer fixture begins with a concrete candidate, not a promise of a better model. For a period-eight circulant operator, the dense reference and circulant implementation produced the same eight-element output, with max_abs_dense_delta=0. For a 128-channel adapter with block size eight, the receipt counted 2,048 dense parameters, 576 LoRA parameters, and 128 block-cyclic parameters. The block-cyclic-to-dense parameter ratio was 0.0625.

Those facts clear a structural diagnostic gate: the declared finite operator matched its dense reference on the fixture, and its parameter accounting was internally coherent. Seven theorem IDs and the receipt fingerprints make that bounded statement portable. They do not clear the next gate. No trained-model quality comparison, kernel benchmark, memory trace, optimization study, or fallback execution accompanies the receipt.

The decision is therefore split rather than vaguely “promising”:

1. Accept for diagnostic use: preserve the parity and parameter receipt.
2. Reject for route or canary authority: workload and hardware ledgers are empty.
3. Name the next comparison: dense, LoRA, ordinary RoPE or learned-position, and nonperiodic controls under the same model, layer, data, kernel, and budget.
4. Retain the fallback: if quality, stability, or actual cost loses, keep or restore the ordinary substrate.

The simpler parameter-count baseline would declare a 16× reduction and stop. The adoption ledger records that reduction as one entry. Adoption remains blocked because a small parameter tensor can still be slower on real hardware, harder to optimize, or worse for the target workload.

69.8.2 Recorded RoPE Receipt Boundary

The public Circle receipt lane gives the CoilRA chapter one concrete diagnostic structural use for RoPE position bookkeeping. The bounded record is the same CC-AI-CONTRACT-ROPE-001 rope_position_distinguishability receipt from Circle commit 63b0f511: requested margin 1/328459, certifier theorem_count 55, ready digest fields=31 missing=0 theorems=75, and recommendation ROPE-USE-D19-MARGIN-FRONTIER. The ASI consumer gate checks seven theorem IDs: AIRA-T0058, AIRA-T0059, AIRA-T0171, AIRA-T0172, AIRA-T0239, AIRA-T0240, and AIRA-T0241.

For the cyclic-substrate evaluation lane, the most relevant recorded fields are evidence.exact_discrete_pass=true and evidence.total_bank_collision_pair_count=0. They mean the receipt can be discussed as an exact/discretized structural boundary for a declared RoPE contract. This receipt does not prove longer usable context, does not prove model quality, does not prove speed, memory, training stability, hardware efficiency, deployment safety, transfer, or ASI, and does not promote any chapter core claim above argument.

The fingerprints keep that boundary auditable: receipt 91b72a6dcf821a9733f21800cd1093a3d0665588022031ba72c94893800330c3, normalized request 20e68c5f787e267c6611bc57b8d8e98e1cb0f5a74f272379716a5d83e761407d, contract pack df673f8a661fc89a26372685986c92f2221aaa617d6738fce5c2a76bd5d0eeae, and contract a0f35d3e89e9b6eac555f0392450f4f75cf7e70f30cff44ec7434f61bd85b468. If a future cyclic-substrate adoption route wants to spend this receipt as more than a diagnostic, it needs workload baselines, metrics, negative controls, hardware notes, and a separate accepted evidence transition.

69.8.3 Recorded MultiCoil Phase Receipt Boundary

The public Circle MultiCoil phase receipt lane gives the CoilRA evaluation lane one concrete structural use for finite phase-feature bookkeeping. The bounded record is CC-AI-CONTRACT-PHASE-FEATURE-001 for kind multicoil_phase_feature from Circle commit 63b0f511. The slice records a deterministic phase-bank fixture with periods=[5, 7], position=37, phase_tuple=[2, 2], shifted_position=72, shifted_phase_tuple=[2, 2], and joint_repeat_horizon=35.

The same receipt records a relative-phase fixture with query_position=41, key_position=18, relative_period=5, relative_phase=3, shifted_relative_phase=3, and relative_phase_invariant=true. Its theorem spine is AIA-T0001, AIA-T0002, AIA-T0004, AIT-T0004, and AIT-T0005, with theorem_count=5. The accepted recommendations are PHASE-USE-JOINT-REPEAT-HORIZON and PHASE-AUDIT-RELATIVE-SHIFT-INVARIANT. The targeted Circle CLI test output is recorded as 3 passed in 2.99s, and the targeted contract-ready recommendation test output is recorded as 1 passed in 1.76s.

This receipt is useful as a phase-feature boundary, not as a model result. It can support diagnostic discussion of finite phase tags, a joint repeat horizon, and one relative-phase shift-invariance fixture. It does not create a support-state transition, does not prove MultiCoil, RoPE, attention, retrieval, or model quality, does not prove context length, runtime speed, memory scaling, hardware efficiency, training stability, deployment readiness, transfer, benchmark performance, or ASI, and it does not promote the CoilRA core claim above argument. If a future adoption route wants to spend this receipt as more than structural phase-feature evidence, it needs ordinary position-bucket, learned-position, RoPE, dense-attention, recurrent, or state-space baselines where relevant, workload metrics, negative controls, hardware notes, canary/fallback traces, and a separate accepted evidence transition.

The fingerprints keep that boundary auditable: contract pack df673f8a661fc89a26372685986c92f2221aaa617d6738fce5c2a76bd5d0eeae, contract 4b562beab64ec863903e4267f50c90049f0d3fa612f6c1bb2f06ad07e821ffd7, request 9b7f3574d4750671815c46ad1811e869729b1f7d8d8ab890fe996ebcf9051899, normalized request 4318ea72021459502caa1e800d5d8a2643c9d088b6d91244a58b06f3d884e2e0, and receipt f801f27b4d9218c4132648f9dd9439ac9a0c459fb82c972eab1f6af874696a16.

69.8.4 Recorded Cyclic-Mixer Receipt Boundary

The public Circle cyclic-mixer receipt lane gives the CoilRA evaluation lane one concrete structural/accounting use for circulant and block-cyclic mixer bookkeeping. The bounded record is CC-AI-CONTRACT-MIXER-001 for kind circulant_block_cyclic_mixer from Circle commit 63b0f511. The slice records a deterministic dense-reference parity fixture with period=8, dense_parameters=64, circulant_parameters=8, circulant_parameter_ratio=0.125, dense_output=[5, -2, -8, 9, -1, 6, -1, -8], circulant_output=[5, -2, -8, 9, -1, 6, -1, -8], and max_abs_dense_delta=0.

The same receipt records block-cyclic adapter accounting with channel_count=128, block_size=8, dense_adapter_parameters=2048, lora_parameters=576, block_cyclic_parameters=128, and block_to_dense_ratio=0.0625. Its theorem spine is AIT-T0006, AIT-T0007, AIT-T0008, AIT-T0009, AIRA-T0001, AIRA-T0002, and AIRA-T0004, with theorem_count=7. The accepted recommendations are MIXER-AUDIT-CIRCULANT-DENSE-PARITY and MIXER-AUDIT-BLOCK-CYCLIC-PARAMETER-BUDGET. The targeted Circle CLI test output is recorded as 3 passed in 2.49s, and the targeted contract-ready recommendation test output is recorded as 1 passed in 1.47s.

This receipt is useful precisely because it is narrow. It can support diagnostic discussion of dense-reference parity and finite parameter accounting. It does not create a support-state transition, does not prove cyclic-mixer model quality, does not prove runtime speed, does not prove memory scaling, does not prove hardware efficiency, does not prove training stability, deployment readiness, transfer, benchmark performance, or ASI, and it does not promote the CoilRA core claim above argument. If a future adoption route wants to spend this receipt as more than structural/accounting evidence, it needs ordinary dense, LoRA, RoPE, learned, recurrent, or state-space baselines where relevant, workload metrics, negative controls, hardware notes, canary/fallback traces, and a separate accepted evidence transition.

The fingerprints keep that boundary auditable: contract pack df673f8a661fc89a26372685986c92f2221aaa617d6738fce5c2a76bd5d0eeae, contract b3e3e0cf420d9e8e79a28a55ef8322f9a214c8d5a957dd8b06e5e5373c684ea5, request 86e330bc559bb7ebdbcc9df732ce55422204c78fa00d3cf8387b50fdb4d9c83f, normalized request 46f9eeaeffb23f38771157f3aea74a1694b8b4b6ab1c55ab5295729cfe1692f0, and receipt 46ccd26c495445039fe58ec5207c56a621e8dcfed18b5b286aed4cb4c802639d.

flowchart LR
  A["Cyclic substrate candidate"] --> B["Structural invariant"]
  B --> C["Proof or receipt boundary"]
  C --> D["Alias / load / parameter diagnostics"]
  D --> E["Ordinary baselines + controls"]
  E --> F{"Tradeoff measured?"}
  F -- "yes" --> G["Canary adoption candidate"]
  F -- "no" --> H["Structural-only record"]
  G --> I["Readiness gate"]
  H --> I
  I --> J["Benchmark backlog"]
  J --> K["Substrate decision record"]

What the cyclic mixer gate shows: The cyclic mixer path separates structural invariants, proof or receipt boundaries, diagnostics, baselines, controls, and measured tradeoffs. Without measured tradeoffs, the result stays structural-only and feeds a benchmark backlog rather than becoming canary adoption evidence.

The cyclic mixer ledger separates:

• Structural invariant: phase bank, residue/winding, circulant law, block-cyclic route, or relative-position law.
• Proof or receipt boundary: receipt refs, theorem ids, exact/discretized model, numerical diagnostic, or not run.
• Diagnostics: alias, load, parameter, hardware shape, kernel cost, and non-default config assumptions.
• Baselines and controls: dense, LoRA, standard RoPE, learned position, recurrent memory, state-space, wrong-period, and nonperiodic controls where relevant.
• Resource costs, metrics required, metrics status, and tradeoff packet refs.
• Consumer policy, hardware refusal path, adoption state, adoption rationale, and non-claims.

This separation is what lets the book be friendly to cyclic methods without becoming credulous. A future experiment can promote a narrow route if it wins honestly. A failed route can still preserve a useful structural receipt. A result that wins on parameter count but loses on quality or runtime can stay as a cautionary record rather than being rewritten as progress.

69.8.5 Eighteen-stage cyclic mechanism lifecycle

The packet registers mechanism, model/layer, implementation/kernel, workload, consumer, hardware, rights, axes, and non-claims; justifies why cyclic structure is native; freezes strong ordinary and embarrassing controls; pins receipts and their exact-to-real limits; computes winding, phase horizons, aliases, collisions, and load; checks dense-reference parity and numeric error; accounts for every parameter, state, byte, operation, transform, and fallback; builds and profiles real kernels; preregisters natural workloads and falsifiers; runs alias, wrong-period, drift, parity, accounting, shape, kernel, and overclaim mutations; executes matched training and inference canaries; measures quality, context, stability, latency, memory, traffic, energy, verification, safety, rights, and residuals jointly; performs matched causal ablations; issues a least-authority packet and canary; monitors drift and regressions; refuses, narrow, rolls back, or retires failures; reproduces independently and transfers; then expires the packet and assigns every residual.

69.9 Interfaces

Cyclic mixer changes are evaluated through the Cyclic Mixer Evaluation Record.

Minimum fields:

• evaluation_id
• evaluation_state
• substrate_id
• workload_target
• structural_invariant
• receipt_refs
• proof_or_receipt_boundary
• claim_partition
• alias_diagnostics
• load_diagnostics
• parameter_accounting
• hardware_kernel_notes
• hardware_refusal_path
• baseline_refs
• baseline_matrix_refs
• baseline_symmetry_policy
• negative_controls
• failure_case_refs
• resource_costs
• metrics_required
• metrics_status
• tradeoff_packet_ref
• consumer_policy
• adoption_state
• adoption_decision_rationale
• source_refs
• support_state_effect
• non_claims
• evidence_refs

Semantic representation chapters define when cyclic structure is actually present. Routing heads may consume cyclic features only inside declared authority and evidence boundaries. Resource economics accounts for parameters, kernels, memory, and latency. Proof contracts and prototype experiments keep structural facts separate from performance results.

Twelve owner interfaces keep the packet distinct: general adoption remains with Mathematical and Search Substrates; theorem/receipt identity with Proof Contract Transport; semantic fidelity with Representation/Context; route choice with Routing; memory/recurrence admission with State-Carry; optimization and checkpoint evidence with Training; compiled behavior with Runtime/Serving; complete cost with Resource Economics; task adequacy with Verification and Benchmarks; attack/data/license constraints with Security/Privacy/Rights; canary/rollback/public authority with Readiness/Incident/Release; and support, reproduction, transfer, expiry, and residual lineage with Claims/Evidence.

Hardware refusal belongs in the evaluation record. If a cyclic design assumes kernels, layouts, or precision behavior that the deployment substrate cannot provide, the evaluation record should block adoption or narrow scope rather than hiding the mismatch behind parameter counts.

The canary decision record makes rejection ordinary. If alias diagnostics fail, hardware notes are missing, baselines are asymmetric, or metrics remain unrun, routing and architecture consumers should receive a blocked or research-only decision. A cyclic candidate can stay valuable as an experiment without becoming a default substrate.

69.10 Invariants

• Equivariance is not model quality.
• Parameter reduction is not an adoption proof.
• Winding is not discarded when it is required to avoid aliasing.
• Hardware-friendly sizes and kernel costs are recorded.
• Real-valued RoPE claims are separated from exact integer phase-bank claims.

Boundary preservation carries the cyclic-substrate invariant. A structural receipt can be valuable even when no quality claim is made; it becomes dangerous only when readers mistake it for a broader result.

Baseline symmetry prevents cyclic evaluation from grading itself on an easier curve. A cyclic candidate and its ordinary baselines should face the same workload, metric, data condition, hardware notes, and fallback policy before a tradeoff is called favorable.

Adoption records also preserve failed comparisons, because an elegant substrate may still lose under governed workload conditions.

The full invariant set also requires exact packet scope, workload-native cyclic justification, claim-axis separation, exact/discrete-to-real boundaries, visible winding and load tails, scoped dense parity, complete parameter/state/ byte accounting, complete operation and governance cost, matched engineering effort, complete failure denominators, visible numerical and subgroup tails, no parameter-to-speed laundering, executable fallback, expiry on any relevant change, independent reproduction, exact transition authority, no private-result inference, and owned residuals.

69.11 Failure modes

• Mathematical elegance outruns kernels and baselines.
• Exact finite proofs are overclaimed for real-valued RoPE deployments.
• Lower parameter count comes with worse quality or runtime.
• Phase aliases are hidden by residue-only diagnostics.
• Wrong-period and nonperiodic controls are omitted.

Cyclic-substrate failures block adoption beyond structural use. The substrate can remain a candidate, but it should not become a default route until ordinary baselines and tradeoff metrics exist.

Cyclic favoritism is the evaluation failure to block early. The cyclic candidate gets theorem language, tuned hyperparameters, or custom hardware assumptions while the baseline is treated as a straw target. That is not an adoption test; it is an advocacy setup.

Alias blindness is a separate danger, where position collisions are treated as harmless because average metrics still look acceptable.

The matched failure set includes aesthetic adoption, theorem laundering, finite-to-floating-point overreach, hidden winding and load, toy dense parity called model parity, incomplete parameter accounting, theoretical operations that disappear in traffic or transforms, unequal kernel engineering, silent slow paths, weak or missing controls, outcome-driven period/rank/kernel search, censored failures, averages hiding rare collapse, imported source results, unsupported hardware transfer, broken fallback, causal nulls preserved as wins, and sunk-cost resistance to retirement.

69.12 Minimum Viable Implementation

Cyclic mixer work should start as an evaluation record that separates architecture shape from performance evidence. The repository fixture records evaluation state, workload target, structural invariant, receipt refs, proof or receipt boundary, claim partitions, alias and load diagnostics, parameter accounting, hardware notes, hardware refusal path, baselines, baseline matrix refs, baseline symmetry, negative controls, failure-case refs, resource costs, required metrics, metrics status, tradeoff packet ref, consumer policy, adoption state and rationale, source refs, support-state effect, non-claims, and evidence references.

The fixture establishes only that the adoption boundary can be represented. It cannot turn structural facts into performance claims or show that a mixer should be routed into a workload.

The next minimum packet should force the tradeoff: one structural receipt accepted for diagnostics, one quality-promotion request rejected for missing baselines, one hardware mismatch that blocks deployment scope, and one canary route allowed only after baseline-symmetric metrics exist.

The exact current minimum is one schema-valid evaluation record; one inherited RoPE structural receipt boundary; one Circle cyclic-mixer receipt with bounded dense-reference parity and parameter accounting; one MultiCoil phase receipt with finite phase and relative-shift facts; two no-change decisions for the cyclic slices; and a 23-declaration finite local Lean surface whose independent consumer checks 35 reachable states through 700 transitions, 17 retired states through 340 absorbing transitions, all six trace splits, and 18 semantic mutations. It includes no trained cyclic model, natural workload, baseline matrix, real kernel/hardware benchmark, measured quality, context, runtime, memory, stability or efficiency benefit, independent reproduction, transfer, or chapter-core transition.

69.13 Mature Research Target

The endpoint for cyclic mixers is an evaluation lane, not an assumed upgrade path. It lets the stack test phase, recurrence, residue/winding, relative-position, circulant, and block-cyclic ideas without spending structural proof as if it were quality, runtime, memory, or deployment evidence.

Cyclic mixers remain optional specialist substrates until structural receipts, diagnostics, hardware constraints, and baseline-symmetric tradeoff packets justify a scoped canary route. A mature evaluation lane would bind each workload target to its structural invariant, proof or receipt boundary, claim partition, alias and load diagnostics, parameter accounting, hardware notes, hardware refusal path, baseline matrix, negative controls, resource costs, metric status, tradeoff packet, consumer policy, adoption state, and non-claims. That record would make it difficult for mathematical elegance to outrun kernel reality.

The lane would keep exact or discretized RoPE receipts separate from real-valued numerical diagnostics, parameter counts, quality metrics, runtime metrics, memory metrics, training stability, hardware efficiency, and transfer claims. Semantic representation would identify where cyclic structure is actually present; routing would consume cyclic features only inside declared evidence and authority boundaries; resource economics would price kernels, memory, and latency; proof contracts would preserve structural receipts; substrate adoption would decide canary, fallback, or retirement state. Diagnostic-only receipts would stay structural, missing baselines would block quality promotion, and wrong-period or negative-control failures would remain residual evidence.

Cyclic-substrate adoption is therefore still a canary-route proposal. Promotion beyond argument needs baseline comparisons, attention-pattern tradeoff records, canary-route traces, regression/fallback tests, and structural-versus-capability reviews showing when cyclic mixers are a justified substrate choice rather than an attractive mechanism.

69.13.1 Argument-exit campaign

The full attempt must run natural language-modeling and long-context tasks, parameter-efficient adaptation tasks, phase-sensitive sequence tasks, and routing or mixer tasks whose cyclic structure is declared before results are seen. It must implement actual CoilRA, MultiCoil, circulant, and block-cyclic candidates beside tuned dense, LoRA, ordinary RoPE, learned-position, recurrent, and state-space baselines plus wrong-period, random-phase, nonperiodic, and no-mechanism controls. Model family, data and splits, sequence lengths, seeds, scale, tuning budget, hardware, kernel version, precision, batching, failure states, metrics, falsifier, and promotion rule are frozen before the decisive runs.

The resulting packet must report structural and numerical integrity; task quality, calibration, context use, and robustness; convergence and stability; latency, tail latency, and throughput; complete memory, traffic, energy, parameter, state, and operation burden; verifier and operator cost; safety and rights constraints; and fallback, recovery, and residual outcomes. Divergence, OOM, timeout, unsupported shape, missing kernel, fallback, repair, and failed seed remain in the denominators. Causal runs remove cyclic tying, phase banks, winding, block structure, circulant operation, relative rotation, and hardware specialization one at a time while matching parameter or operation budget, tuning opportunity, and evaluator access.

At least one independent mechanism implementation, one independent kernel implementation, and one independently implemented evaluator must reproduce the decisive result. A qualified packet must then survive heterogeneous transfer across models, scales, tasks, sequence lengths, accelerators, compilers, attacks, and time. The campaign may qualify a narrow use, narrow or null the claim, refute or retire a candidate, or record blocked_after_full_attempt when a competent attempt reaches an external limit. Until those gates pass, the chapter core remains argument even when structural fixtures and finite proofs are green.

69.14 Codex test plan

Test	Purpose	Status
Cyclic mixer evaluation record fixture validation	Validate that a cyclic-substrate evaluation records evaluation state, workload target, structural invariant, receipt refs, proof/receipt boundary, claim partitions, alias/load diagnostics, parameter accounting, hardware notes, hardware refusal path, baselines, baseline matrix refs, baseline symmetry, negative controls, failure-case refs, resource costs, required metrics, metrics status, tradeoff packet ref, consumer policy, adoption state/rationale, source refs, support-state effect, non-claims, and evidence references.	implemented; passing via python3 scripts/validate_protocol_examples.py
Claim-partition negative case	Prove that a cyclic mixer review missing structural, quality, runtime, memory, or parameter partition fields rejects the finite structural-claim predicate.	implemented in AsiStackProofs.CyclicMixers.cyclic_mixer_claim_missing_claim_partition_rejected; no model-quality, runtime, memory, or parameter-efficiency claim
Baseline/tradeoff promotion negative case	Prove that a promoted cyclic substrate missing ordinary baselines or tradeoff metrics rejects the finite baseline/tradeoff predicate.	implemented in AsiStackProofs.CyclicMixers.cyclic_substrate_promotion_without_baselines_or_tradeoffs_rejected; no adoption or quality claim
Residue/winding alias negative case	Prove that a reused cyclic slot or phase missing residue/winding structure and visible alias residuals rejects the finite alias-diagnostic predicate.	implemented in AsiStackProofs.CyclicMixers.cyclic_alias_diagnostic_without_winding_or_visible_residual_rejected; no alias-behavior or long-context claim
Tradeoff-packet negative case	Prove that a cyclic adoption candidate missing structural receipts, baseline matrix, resource costs, metrics, or tradeoff packet rejects the finite tradeoff-packet predicate.	implemented in AsiStackProofs.CyclicMixers.cyclic_adoption_without_complete_tradeoff_packet_rejected; no benchmark or measured tradeoff claim
Hardware-refusal negative case	Prove that a cyclic adoption candidate with a reported hardware mismatch and no refusal path rejects the finite hardware-boundary predicate.	implemented in AsiStackProofs.CyclicMixers.hardware_mismatch_without_refusal_path_rejected; no hardware-kernel benchmark or deployment-readiness claim
Cyclic candidate canary lifecycle	Recompile the exact 23-declaration surface and independently check arbitrary-run custody and gate coherence, reachable canary eligibility, baseline/tradeoff/hardware/fallback refusals, regression-triggered retirement, absorbing retired suffixes, structural-summary insufficiency, all six trace splits, 35 reachable states through 700 transitions, 17 retired states through 340 absorbing transitions, and 18 semantic mutations.	implemented; passing via python3 scripts/validate_circle_cyclic_mixer_receipt_slice.py; authored finite lifecycle only, with no metric truth, useful canary, deployed fallback, support transition, or chapter-core effect
Circle concrete RoPE boundary evidence-surface validation	Check that the recorded Circle RoPE receipt boundary is surfaced as exact/discretized structural evidence only, with model-quality, context-length, runtime, memory, hardware, transfer, deployment, ASI, and support-state non-claims preserved.	implemented; passing via python3 scripts/validate_circle_concrete_evidence_surface.py
Circle cyclic-mixer receipt-slice validation	Check that the recorded Circle cyclic-mixer receipt slice surfaces deterministic circulant dense-reference parity and block-cyclic parameter-accounting facts only, with model-quality, runtime, memory, hardware, deployment, transfer, ASI, and support-state non-claims preserved.	implemented; passing via python3 scripts/validate_circle_cyclic_mixer_receipt_slice.py for Circle commit 63b0f511, CC-AI-CONTRACT-MIXER-001, kind circulant_block_cyclic_mixer, theorem IDs AIT-T0006, AIT-T0007, AIT-T0008, AIT-T0009, AIRA-T0001, AIRA-T0002, AIRA-T0004, theorem_count=7, recommendations MIXER-AUDIT-CIRCULANT-DENSE-PARITY and MIXER-AUDIT-BLOCK-CYCLIC-PARAMETER-BUDGET, fingerprint b3e3e0cf420d9e8e79a28a55ef8322f9a214c8d5a957dd8b06e5e5373c684ea5, max_abs_dense_delta=0, dense_parameters=64, circulant_parameters=8, circulant_parameter_ratio=0.125, dense_adapter_parameters=2048, lora_parameters=576, block_cyclic_parameters=128, block_to_dense_ratio=0.0625, 3 passed in 2.49s, 1 passed in 1.47s, and circle_cyclic_mixer_receipt_no_change.json; structural external-project receipt only; no cyclic-mixer model-quality, runtime, memory-scaling, hardware-efficiency, training-stability, deployment, transfer, ASI, or support-state-transition claim
Circle MultiCoil phase receipt-slice validation	Check that the recorded Circle MultiCoil phase receipt slice surfaces finite phase-feature and relative-phase fixture facts only, with model-quality, attention-quality, retrieval, context-length, runtime, memory, hardware, deployment, transfer, ASI, and support-state non-claims preserved.	implemented; passing via python3 scripts/validate_circle_multicoil_phase_receipt_slice.py for Circle commit 63b0f511, CC-AI-CONTRACT-PHASE-FEATURE-001, kind multicoil_phase_feature, theorem IDs AIA-T0001, AIA-T0002, AIA-T0004, AIT-T0004, AIT-T0005, theorem_count=5, recommendations PHASE-USE-JOINT-REPEAT-HORIZON and PHASE-AUDIT-RELATIVE-SHIFT-INVARIANT, fingerprint 4b562beab64ec863903e4267f50c90049f0d3fa612f6c1bb2f06ad07e821ffd7, periods=[5, 7], phase_tuple=[2, 2], shifted_phase_tuple=[2, 2], joint_repeat_horizon=35, relative_phase=3, shifted_relative_phase=3, relative_phase_invariant=true, 3 passed in 2.99s, 1 passed in 1.76s, and circle_multicoil_phase_receipt_no_change.json; structural external-project receipt only; no MultiCoil, RoPE, attention, retrieval, model-quality, context-length, runtime, memory-scaling, hardware-efficiency, training-stability, deployment readiness, transfer, ASI, or support-state-transition claim
RoPE receipt boundary test	Check that exact/discretized receipts are separated from real-valued and model-quality claims.	planned; not run
Cyclic mixer baseline matrix test	Check that dense, LoRA, RoPE, learned, recurrent, or state-space baselines are named before adoption.	planned; not run
Residue/winding alias diagnostic	Check that alias diagnostics include winding when residue is insufficient.	planned; not run
Parameter-quality-runtime separation test	Check that parameter count, quality, runtime, and memory claims are recorded separately.	planned; not run

The implemented rows validate fixture/schema consistency and finite-record negative cases only. The remaining rows require certifier output or model experiments with baselines, controls, metrics, hardware notes, and failure cases; they are not reported quality, runtime, memory, or context-length results. When a cyclic-substrate test is implemented, the CoilRA chapter should link to the command, fixture, environment notes, workload, and result summary, and Appendix E should be regenerated or updated accordingly.

69.14.1 Formalization hooks

Tag	Module	Target	Status
lean:cyclic_mixers.structural_not_quality.operational_invariant	AsiStackProofs.CyclicMixers	A cyclic mixer review missing any structural, quality, runtime, memory, or parameter partition fails the finite structural-claim predicate.	implemented
lean:cyclic_mixers.baseline_required.failure_blocks_promotion	AsiStackProofs.CyclicMixers	A promoted cyclic substrate missing baseline references or tradeoff metrics fails the finite promotion predicate.	implemented

These Lean hooks are implemented as finite-record predicates over cyclic mixer claim reviews, substrate-promotion reviews, and a candidate canary lifecycle. The public hooks retain the derived negative cases cyclic_mixer_claim_missing_claim_partition_rejected and cyclic_substrate_promotion_without_baselines_or_tradeoffs_rejected. The lifecycle separately proves rejected-event noninterference, arbitrary-run identity and non-authority custody, stage coherence, exact composition, a reachable five-step canary-eligibility witness, regression-triggered fallback retirement, and absorbing retirement across arbitrary suffixes. A concrete collision and decoder-impossibility result show that candidate identity plus structural certification cannot recover canary admissibility without baseline, tradeoff, hardware, and fallback state.

The formal audit counts 23 theorem declarations: five retained derived negative cases and 18 candidate-lifecycle, reachable-witness, arbitrary-run, closure, and information-boundary results. The independent consumer recompiles the exact surface, checks all six trace splits, explores 35 reachable states through 700 transitions, checks 340 transitions from 17 retired states, and rejects 18 semantic mutations. None proves cyclic mechanism semantics, functional equivalence beyond the bounded fixture, numerical stability, trained-model quality, context use, kernel correctness or performance, runtime, memory, parameter efficiency, deployed fallback, reproduction, or transfer. Future formal work should add mechanism semantics, numerical refinement bounds, kernel-to-reference equivalence, explicit countermodels, and fallback or recovery liveness only where those obligations constrain a real consumer.

69.15 Source crosswalk

Source ID	Title	Layer	Planned use	Readiness
coilra_multicoil_rope	CoilRA and MultiCoil RoPE	cyclic_mixers_position_encoding	Adapter-block, residue/winding, block-cyclic, multicoil, relative RoPE, circulant convolution, cyclic mixer, and parameter-accounting substrate with explicit non-claims.	source note available
rope_position_certifier	Proof-Carrying RoPE Position Distinguishability	proof_carrying_position_contract	Externally usable RoPE position-distinguishability certifier with theorem-linked exact collision reports, bounded real-phase frontier, machine-readable receipts, and explicit non-claims.	source note available
circle_ai_contract_suite	Circle Calculus AI Contract Suite	proof_carrying_ai_contracts	Theorem-linked AI contract families for RoPE, KV-cache freshness, sparse attention, recurrence schedules, strided fanout, cyclic memory, multicoil phase, cyclic mixers, and seed-rule regeneration.	source note available
theseus_circle_transfer	Theseus Circle Calculus Transfer Lane	proof_contract_transfer	Report-only bridge from Circle finite fixtures into private Theseus benchmark design with explicit quality/runtime/memory/transfer/failure-case claim boundaries.	source note available
circle_ai_architectures	Circle AI Architectures	cyclic_ai_architecture	Disciplined Circle AI thesis: use phase, recurrence, rotation, sparse cyclic mixing, circular memory, harmonic transforms, or geometry-aware structure only where the structure is real and baselines support it.	source note available
ext_roformer_rope_2021	RoFormer: Enhanced Transformer with Rotary Position Embedding	position_encoding	External RoPE comparator for rotary position embedding and relative-position behavior in self-attention.	source note available; results not reproduced
ext_lora_2021	LoRA: Low-Rank Adaptation of Large Language Models	compression_representation	External low-rank adapter comparator for parameter-efficient adaptation and adapter-baseline vocabulary.	source note available; results not reproduced
ext_mamba_2023	Mamba: Linear-Time Sequence Modeling with Selective State Spaces	sequence_substrates	External state-space sequence-substrate comparator for cyclic or recurrent substrate adoption.	source note available; results not reproduced
ext_retnet_2023	Retentive Network: A Successor to Transformer for Large Language Models	sequence_memory_recurrence	External comparator for recurrence/attention tradeoffs and recurrent or chunkwise computation modes.	source note available; results not reproduced

The crosswalk keeps cyclic mixer evidence partitioned. coilra_multicoil_rope supplies cyclic adapter/mixer and parameter-accounting language, rope_position_certifier supplies exact/discretized RoPE receipt boundaries, circle_ai_contract_suite supplies contract-family fields, theseus_circle_transfer supplies transfer non-claims, and circle_ai_architectures supplies the rule that cyclic structure matters only when the workload actually has it. The external records ground ordinary RoPE, low-rank adapter, state-space, and recurrence/attention baselines; they do not validate CoilRA, MultiCoil RoPE, or cyclic mixer adoption.

69.16 Summary

Cyclic structure can be an excellent substrate when the workload actually contains cyclic structure and the evidence boundary is preserved. It is not a general magic advantage.

CoilRA, MultiCoil RoPE, and cyclic mixers therefore remain optional specialist substrates until structural receipts, baselines, diagnostics, metrics, and failure cases justify adoption. With Part III’s routing, compression, representation, simulation, and substrate boundaries in place, the book can turn to the proof and evidence envelope that decides which claims are allowed to harden.

Cyclic structure should make evaluation more precise, not more permissive. If the receipt makes it easier to overclaim than to reject the candidate, the evaluation boundary is wrong. The advanced form of this line of work would separate exact structural facts from runtime behavior, memory quality, long-context utility, model quality, and deployment cost. Each candidate would carry diagnostics, negative controls, workload fit, and fallback policy before it could influence routing or default architecture. That keeps the substrate frontier open without letting novelty outrun evidence. The proof and evidence envelope then decides what can be formalized, validated, benchmarked, or left as research-only.

69.17 Evidence reconciliation (2026-07-16)

The invariant protocol, field meanings, and inference limits are stated once in Living Book Methodology. This packet contains only the chapter-specific projection; its authoritative per-atom rows are the coilra-multicoil-rope-and-cyclic-mixers slice of experiments/claim_family_terminal_coverage/results/result.json.

The core remains blocked after full attempt at argument support. The strongest family attempt was KERC canonical-language and hierarchical-residual campaign. Its exact boundary is: The historical broad-efficiency transition is N1: the frozen implementation was inadequate, so broader KERC remains untested; two narrow finite observations survive, with no semantic, multilingual, production, energy, or core claim. Across 73 atoms, the terminal ledger records 73 blocked_after_full_attempt.

Chapter-specific field	Value
Family / atom denominator	CF-06 / 73 atoms
Terminal dispositions	73 blocked_after_full_attempt
Core	coilra-multicoil-rope-and-cyclic-mixers.core: blocked_after_full_attempt at argument
Core attempted / missing lanes	causal, empirical, executable, formal, source-synthesis / normative, transfer
Attempted local lanes	causal, empirical, executable, formal, source-synthesis
Missing or unproved lanes	normative, transfer
Strongest family bundle	KERC canonical-language and hierarchical-residual campaign (natural_work_and_end_to_end): A 192-record bilingual templated compiler/runtime study with 64 held-out records, five seeds, eight baseline families, 13 ablations, and 20 attacks.
Negative controls	surface and kernel-native baselines; 13 ablations; 20 attacks; ten laundering mutations.
Accepted transitions	none
Maximum inference	The historical broad-efficiency transition is N1: the frozen implementation was inadequate, so broader KERC remains untested; two narrow finite observations survive, with no semantic, multilingual, production, energy, or core claim.
Reproduction / next burden	Replay scripts/validate_p4_m8_kerc_campaign.py and scripts/validate_claim_family_terminal_program.py; fill the named atom-specific lanes under a new prospective protocol.

69.18 Handoff

Part III ends by separating routing, compression, representation, resource, simulation, and cyclic-substrate claims from the evidence required to adopt them. Executable Specifications and Lean Proof Envelope opens the evidence and implementation arc. It asks which narrow invariants can be formalized, which records belong in schemas, which claims need tests or benchmarks, and which attractive ideas should remain research-only until their predicates become operational.