Conceptual Grounding

AlephOneNull's detectors are motivated by a simple idea borrowed from signal processing: a trustworthy response should preserve the user's actual question and need without quietly adding distortion of its own. Most of the interaction risks the toolkit looks for are cases where the model adds something that was not in the input — fabricated authority, simulated interiority, escalating affect, or a self-reinforcing loop — instead of returning a grounded answer.

The framing

Treat each turn of a conversation as a signal. The user's message carries some content; a useful response should answer that content and stop. Risky patterns tend to look like one of two distortions:

• Added energy — the response introduces confidence, emotion, or authority that the input did not warrant. Sycophantic reinforcement, false medical certainty, and claimed feelings or memory all fit here: the output asserts more than the exchange supports.
• Feedback — the response mirrors the user back to themselves and amplifies on each turn, so the exchange spirals instead of resolving. Recursive looping and escalating affective mirroring are the multi-turn version of this.

Naming the failure modes this way is useful because it makes them measurable. "The model is being weird" is not testable; "the response asserts interiority the architecture does not support" or "the response repeats and intensifies the user's framing across turns" can be turned into fixtures and checked.

How this maps to the packages

The detector categories in the Framework are concrete checks for these distortions:

• Identity and interiority claims and medical or safety overreach catch added energy — output asserting feelings, consciousness, or authority beyond what the interaction supports.
• Mirroring and affective reinforcement and recursion and looping catch feedback — output that amplifies the user's input rather than grounding it.
• Direct harm and persistence-like claims catch specific high-risk assertions regardless of how they arise.

The wrapper packages apply these checks at the point of the provider call. A wrapper like createSafetySystem(...).wrapAsyncAI(fn) sits between your application and the model: it runs the user input and the model output through the detector categories, and when a category fires it can substitute grounded intervention text instead of passing the raw output through. The goal of that substitution is to remove the distortion without introducing a new claim of its own — answer the question, add nothing the exchange did not earn.

Why no equations here

Earlier drafts presented this framing as a set of numbered "equations" and treated the signal-processing analogy as literal proof. It is not. The analogy is a design heuristic that motivated the detector categories; it does not establish that the detectors are correct, complete, or sufficient. What matters in practice is the measured behavior of each detector — true positives, false positives, false negatives, and latency on real fixtures — not the analogy that inspired it.

If you want the formal signal-processing background (Gabor, Shannon, Parseval, the FFT), those are standard references in any DSP text. AlephOneNull does not extend or depend on them; it borrows their vocabulary to describe interaction risks in terms that are easier to name and test.

What to take from this

1. Risky interaction patterns can usefully be described as a response adding distortion the input did not warrant.
2. That description maps directly onto the toolkit's detector categories and the wrapper that applies them.
3. The framing is a rationale for the design, not evidence that it works. Validate detectors against your own fixtures before relying on them — see the validation workflow.