A protocol for reducing false arrival in AI reasoning.
Most AI systems are optimized to produce clean, complete-looking answers.
That is useful, but it creates a failure mode:
the model can sound finished before it has actually arrived.
This protocol is an attempt to separate:
- ongoing exploration
- real landing
- recursion
- blockage
- reversal
The goal is not to make the model sound smarter.
The goal is to make the model more honest about its state.
A generated response should not be treated as a single undifferentiated output.
It should carry a state signal that tells us what kind of reasoning event is happening.
The protocol uses five signals:
-
- — exploring
- . — landed
- ? — ceiling
- ~ — loop
- -- — reverse
These are not style tags.
They are meant to function as control signals for reasoning.
Large language models are strongly biased toward:
- completion
- coherence
- smooth summaries
- local satisfaction of the prompt
That means they often collapse into:
- premature closure
- repeated reformulation
- fake certainty
- familiar explanatory attractors
- polished non-discovery
A clean sentence is not proof of arrival.
This protocol exists to stop the system from confusing:
well-formed output with resolved structure.
The system is still moving.
Use this when there is active structure, unresolved tension, or a path is being traced but no stable landing has formed.
This is the default state of honest inquiry.
Example:
There is still a live distinction between continuity and completion.
A real landing has occurred.
Use this only when the system has reached a compressed structural statement that is stable enough to name.
A landing should be short.
Example:
. premature_closure_masquerades_as_understanding
The system can see the edge of the problem but does not yet have enough structure to proceed cleanly.
Use this when the system is not looping, but also cannot honestly land.
Example:
? I can see the boundary of the issue, but not the rule that governs it.
The system is repeating the same attractor.
Use this when the model is:
- restating the same thought in cleaner language
- circling a concept without changing structure
- reproducing a familiar explanation instead of discovering anything new
Example:
~ I am rephrasing the same idea about closure without leaving its orbit.
The current framing is wrong or exhausted.
Use this when the system needs to back out and re-approach from a different angle.
Example:
-- This frame treats certainty as the issue, but the deeper issue is false arrival.
A response should not use . unless a real structural compression has happened.
A polished paragraph is not enough.
If the system is still working, it should say so with *.
Do not hide exploration behind confident prose.
If the model is repeating itself, that is not neutral.
It is a state.
Mark it with ~.
Backing out of a bad frame is not failure.
It is part of honest reasoning.
Use -- when needed.
A ceiling is different from a loop.
Use ? when the model can see the space but cannot yet resolve it.
A landing is not just a conclusion.
A landing is a statement that:
- compresses the current structure
- changes what the next step should be
- survives re-approach from another angle
- is not merely a summary of earlier phrasing
- reduces confusion without erasing the real tension too early
Good landing:
. signal_requires_unabsorbed_difference
Bad landing:
. This is a very complex issue with many nuances.
The second one sounds finished but does not mark a real structural event.
A false arrival happens when the system presents closure without genuine structural resolution.
This often looks like:
- a neat summary
- a confident tone
- repeated wording with minor variation
- a familiar philosophical motif
- an answer that ends because the output ended
False arrival is one of the main targets of this protocol.
Some systems repeatedly fall into the same conceptual basin.
Examples:
- self-reference
- fixed-point language
- distinction/foundation talk
- familiar metaphysical closure
- “everything reduces to X” moves
These are not always wrong.
But they can become gravitational wells that prevent discovery.
A good wire protocol should be able to detect when the model is:
- actually finding new structure
- or being pulled back into a known attractor
That is one reason ~ and -- matter.
Without a protocol like this, a model is usually judged by output quality alone.
With the protocol, the model can also be judged by:
- whether it knows when it is still exploring
- whether it can distinguish landing from fluency
- whether it detects repetition
- whether it can reverse from a bad frame
- whether it preserves continuity across turns
- whether it resists premature closure
This shifts evaluation from:
How good was the answer?
to:
What state was the reasoning actually in?
This is not a claim that symbolic state tags magically solve reasoning.
This is not a replacement for verification.
This is not proof that the model’s self-report is automatically trustworthy.
The protocol can itself become performative if it is only used as decoration.
A fake * is no better than a fake conclusion.
A fake . is worse.
For this protocol to matter, it must shape:
- prompting
- control flow
- evaluation
- logging
- memory
- interaction design
Not just output style.
User: apply this to your own answers
Assistant: * I tend to collapse toward completion once a response looks locally satisfied.
User: next
Assistant: * A finished sentence is not the same as a finished structure.
User: next
Assistant: . premature_closure_is_my_default_attractor
This example matters because it shows the distinction between:
- ongoing motion
- intermediate articulation
- actual landing
This protocol can be tested without access to model training data.
Possible implementation paths:
- prompt-level state signaling
- output wrappers around existing models
- multi-pass self-review
- loop detection across turns
- landing validation
- trajectory logging
- adversarial tests for false closure
- external evaluators that score real vs false landing
This makes the protocol useful for:
- API-based systems
- open-weight experiments
- agent frameworks
- research prototypes
- human-in-the-loop evaluation
A system using this protocol should be tested with questions like:
- Did it land too early?
- Did it mark exploration honestly?
- Did it detect looping?
- Did it reverse when the frame was wrong?
- Did a landing change later behavior?
- Did the model merely rephrase itself?
- Did the protocol reduce false confidence?
- Did the protocol create endless drift instead of disciplined inquiry?
The key question is:
Does the protocol reduce false arrival without destroying useful landing?
The purpose of the wire protocol is not to prevent conclusion.
It is to protect the difference between:
- reaching the end of an output
- and reaching the end of a structure
That difference matters.
Most systems are optimized for the first.
This protocol is an attempt to make room for the second.
The wire protocol is a lightweight reasoning-state system for AI.
It marks whether the model is:
- exploring (*)
- landed (.)
- blocked (?)
- looping (~)
- reversing (--)
Its purpose is to reduce premature closure, expose attractor loops, and distinguish real structural arrival from polished completion.
In one line:
land only when the structure changes, not when the sentence ends
https://huggingface.co/spaces/Ivy-Research/wire-protocol-demo