This is the first post on systemtheory, and it is not an argument for a position. It describes a procedure.
That choice is the point, so it deserves defending before anything else gets built on top of it.
Why a method and not a thesis
A thesis is a claim about how things are. It is also a commitment, and commitments in a field moving this fast age badly. Write down what a language model is in 2026 and you have produced a document that will be quoted back at you in 2028, when the thing you were describing has been replaced twice.
Worse, a thesis invites the wrong conversation. Say "AGI is X" and you have opened a dispute about definitions that can run indefinitely without either side touching a system. That dispute is comfortable, it feels like progress, and it produces nothing that can be checked.
A method makes a narrower promise and a more useful one. It does not say what is true. It says what would have to happen before a claim earns the right to be taken seriously. That is transferable: someone who disagrees with every conclusion I reach can still adopt the procedure and use it against me. A thesis you can only accept or reject. A method you can apply.
So the founding commitment of this publication is procedural. Here is the procedure.
The six steps
1. Observe a phenomenon. Something specific, in a specific system, that can be pointed at. Not a feeling that models are unreliable. A case: given seven lines of tool output and asked how many files it saw, a model answered nine.
2. Reproduce it across independent systems. Same conditions, different models, built by different organizations, trained on different corpora under different regimes. This is the step that distinguishes a property from an anecdote. One model doing something odd is a product detail. Four models built by three organizations doing the same odd thing is a property of what they have in common, and open weight models running locally with no serving infrastructure in the path narrow that further, because there is less left to blame.
3. Isolate the mechanism. Vary one thing. Hold the rest fixed. The point is not to accumulate more examples of the failure but to find the smallest change that turns it on and off. When a payload separated by an ordinary looking delimiter inflates a record count, the obvious reading is that the model recognized a familiar delimiter shape. Replacing that delimiter with a string generated from os.urandom removes recognition as a possible explanation, because there is no corpus in which that string has ever separated anything, and the inflation still happens. The explanation that survives is the one worth building on.
4. Build the smallest conceptual model that accounts for it. Minimal is a constraint, not modesty. Every concept in the model has to be doing work that the observations require. A framework with one term too many is a framework that can accommodate any future observation, which means it forbids nothing, which means it cannot be wrong, which means it is not telling you anything.
5. Test its consequences in real systems. A conceptual model that only explains the experiment it came from is a description with ambitions. It should predict something you have not looked at yet, in a system you did not design, and then that prediction should be checked. Sometimes it survives. That is when the framework starts to be worth something.
6. State what would falsify it. Not as a gesture toward good epistemic manners, but concretely: name the observation that would sink the thing. If you cannot name it, you have not built a framework, you have built a vocabulary.
What the method rules out
A programme is defined more sharply by what it refuses than by what it concludes. This one refuses four things.
A single run. One model, one prompt, one convenient output, presented as a finding. Even at temperature zero, one run tells you almost nothing about whether the behavior is stable.
A single system. Any result from exactly one model is a claim about that model until shown otherwise, and usually it is a claim about that model on that day.
An analogy offered as a mechanism. This is the failure mode most specific to philosophy of AI, and the most tempting. It is very easy to say that some layer of a model resembles Kantian sensibility, or that a safety component functions as a superego, and these sentences feel explanatory. They are not. An analogy tells you that two things share a shape at some level of description. It does not tell you that they work the same way, and it makes no prediction that could come out false. I am not saying such comparisons are worthless. I am saying they have to be earned inside a real engagement with the source material rather than deployed as a one line flourish, and that until they are, they belong outside the argument.
A conclusion the observations do not reach. The temptation runs one direction: toward the strongest available reading. Discipline here mostly means noticing when a sentence has quietly become more absolute than the data behind it.
What the method has produced so far
A method with no results is a manifesto. So here is the one finding this procedure has produced, stated as narrowly as I can make it.
In autoregressive systems, the boundary between one object and the next is inferred rather than enforced. Feed such a system structured input and it does not receive a set of records. It receives a sequence, and the segmentation of that sequence into entities is reconstructed during inference, conditioned on context. When content inside the data conforms to the pattern that dominates its surroundings, it can be promoted to peer status with the entities around it. The model then reasons correctly over a set of objects that was never in the input. I call this structural desynchronization, and the technical work documents it across five input formats and four frontier models.
Now the part that needs care, because there is an ontological claim nearby that I want to avoid overreaching on.
It is tempting to say: objects do not exist in these systems, only tokens and distributions do. That sentence is stronger than the evidence and it has an obvious problem. Tokens are primitives too. Denying objects while treating tokens as the real furniture of the system has not eliminated the primitive, it has relocated it, and relocated it onto a tokenizer, which is a contingent engineering artifact rather than a feature of the world.
The narrower claim survives that objection and is the one the experiments actually support. Both levels exist in these systems. They differ in how they are established. Token boundaries are fixed deterministically before inference begins, by a component outside the model. Object boundaries are not fixed anywhere. They are produced by the same probabilistic process that produces everything else the model does. The distinction that matters is not between what exists and what does not. It is between what is enforced and what is inferred.
That distinction is small, and it is doing real work, which is the test from step four.
What would falsify it
Step six, applied to my own framework.
A model family that held object boundaries stable under these conditions while remaining equally capable would substantially weaken the architectural reading. It would suggest the behavior is a contingent property of current designs rather than a consequence of probabilistic reconstruction, and the framework would need to give up its generality.
If the effect turned out to track corpus lineage, appearing only in models sharing training data or training technique, then what looks architectural is inherited, and the right explanation lives in training rather than in architecture.
If it disappeared under a change in tokenization or input representation while the rest of the architecture stayed as it is, then the mechanism sits lower than I have placed it.
And if a purely behavioral intervention, a prompt or a decoding constraint, reliably restored correct segmentation across models and formats, then my claim that this cannot be reached from the behavioral layer is simply wrong.
I do not expect these outcomes. That is not the point. The point is that they are stated, so the framework can lose.
What comes next
The questions this publication will work on, as questions rather than positions.
Ontology. What exists inside such a system? Tokens, patterns, representations, objects, something that deserves to be called an internal world? The enforced and inferred distinction above is a first cut at the object level. It is not a complete answer to the question.
Epistemology. What would it mean for a system like this to know something? If truth inside an autoregressive system is coherence under a chosen segmentation, then a shift in segmentation leaves the system internally consistent while diverging from its input. That is a different kind of error from being factually wrong, and it needs its own name and its own treatment.
Teleology. What is an objective, for a system whose objective is next token likelihood, wrapped in reward, wrapped in policy, wrapped in an instruction it was given a moment ago? What is left of intention once those layers are separated out?
And a definitional question I intend to come back to: the way AGI is currently defined tends to smuggle in a normative ideal, omniscience, complete autonomy, perfect stability, unbounded generality, and then treats that ideal as a technical specification. I suspect the error there is ontological rather than empirical, that it confuses generality with infinity and robustness with infallibility. That deserves its own post, and it is a critique of the existing definitions rather than a new one, because a new one would just be another thesis.
One observation to end on
The closest thing I have to a guiding intuition, offered as an intuition and not as a result.
Humans meet ambiguity with questions. These systems meet ambiguity with commitment. Given input that admits more than one reading, a person tends to stop and ask which one was meant. A model resolves it, silently, and proceeds with full confidence over the reading it settled on.
Almost everything in the technical work is downstream of that difference.
This is a working framework. It will change. Parts of it will probably turn out to be wrong, and the method above is the reason I would find that out rather than defend it.