Signal for LLM

Document Position

Signal for LLM is not a theoretical document of TGR, nor is it part of the Signal document series. It is an engineering architecture document.

Its purpose is not to redefine Signal, but to discuss how Signal can genuinely participate in the runtime of modern Large Language Models (LLMs), rather than remaining only at the symbolic layer.

This document does not modify the definitions established in Signal, Signal Runtime, Signal API, or Signal Engine. Instead, it discusses how an LLM can become the host of Signal.

1.Why Signal

Modern LLMs have already achieved remarkable symbolic generation capabilities. Prompting, Memory, Embeddings, Tool Calling, and related mechanisms continuously improve the utilization of information.

However, nearly all of these capabilities are built upon symbolic projections. Models can read symbols, reconstruct symbols, reason from symbols. But they rarely allow new constraints to participate directly in the runtime state.

As a result, most constraints appear only as interpretations after generation, rather than continuous modulation before and during generation.

The goal of Signal for LLM is not to introduce new knowledge. Its goal is to introduce a new runtime mechanism.

2.Signal Is Not Information

Signal may leave symbolic projections. A Prompt may carry Signal. Tokens may describe Signal. Embeddings may approximate Signal. However, none of these are Signal itself.

Signal is first and foremost runtime state modulation. Only constraints that genuinely participate in changing the runtime state are considered Signal.

If information exists only as a Prompt that must be read again by the model, then it belongs to symbolic projection, not Runtime Signal.

3.Decoupling in Current LLMs

In most deployed LLM systems, the Reward Model learns constraints, while the Generator produces text. After deployment, the Reward Model usually leaves the runtime.

As a result, constraints learned during training remain only indirectly encoded in model parameters. During inference, new constraints cannot continuously participate in state transitions. Instead, the model must infer those constraints again through symbols, rather than directly observing their continued existence.

Signal for LLM aims to restore this layer of runtime continuity.

4.Modulator

Signal for LLM introduces a new runtime role: the Modulator. The Modulator is neither the Generator nor the Reward Model. Its sole responsibility is to modulate the runtime state according to current constraints.

The Modulator can be extremely small. Even the minimal implementation may output only + / − / 0. The important part is not the output format — it is that its output must genuinely modify the runtime state.

5.Runtime State

Signal does not directly control text. Signal controls Runtime State — for example: inference budget, context window, attention resource allocation, KV Cache weighting, expert routing, activation gates, dynamic parameter weighting, or any runtime resource exposed by the Engine.

Which resources are available is an implementation decision of the Engine. Signal specifies no particular target. It requires only one condition: the runtime state must genuinely change.

6.Joint Training

Signal for LLM proposes that the Reward Model, Modulator, and Generator should be trained jointly. The purpose is not higher accuracy — it is to establish shared expectations.

The Generator must gradually learn which Runtime States may occur, what those states imply, and which state drifts originate from the Modulator versus from Prompts. Otherwise, Signal will once again degenerate into Prompt Engineering.

7.Signal Mapping

The role of Signal Mapping is redefined here. Its purpose is not to recover Signal — instead, it records runtime state modulations that have already occurred.

Mapping serves three participants: humans, to understand why the system drifted; the Generator, to learn the relationship between Runtime States and generated outputs; and the Modulator, to continually improve future modulation strategies.

Mapping describes the traceable projections left by state drift, not the runtime state itself.

8.Minimal Experiment

The minimal experiment of Signal for LLM does not validate TGR, nor does it attempt to prove the existence of Signal. It verifies only whether runtime state modulation can produce learnable continuous influence.

A theoretical minimal implementation: the Modulator outputs + or −. A fixed algorithm interprets them — + increases the Context Window for this inference step, − decreases it. The Generator never reads "+" or "−"; it observes only the causal drift created by the changed runtime state.

If joint training succeeds, the Generator will gradually develop expectations about Runtime States and actively exploit state drift during generation.

9.Relationship to Existing LLMs

Signal for LLM does not replace the Transformer, RLHF, or Reward Models. Instead, it introduces a Runtime Modulation Layer.

Therefore, Signal for LLM is better understood as a runtime architecture for agent systems rather than a new foundation model.

10.Engineering Evolution

As modulation capabilities improve, the Modulator may gradually receive broader runtime authority — examples include dynamic inference budgeting, attention scheduling, Mixture-of-Experts routing, dynamic parameter activation, external resource allocation, and multi-model coordination.

Whether these capabilities are exposed depends on the Engine implementation. Signal for LLM specifies no implementation. It specifies only one requirement: Signal must genuinely participate in the runtime state.

11.Boundary

Signal for LLM is not a proof of TGR. It is only one possible engineering implementation of TGR within Large Language Models.

Even if Signal for LLM ultimately fails, it would indicate only that the current engineering path has failed. It cannot be used to invalidate TGR's description of relational generation in reality.

Likewise, even if Signal for LLM succeeds, it does not prove TGR. It only demonstrates that a runtime Signal architecture can introduce new engineering capabilities.

Closing