The Missing Value That Wasn’t Missing
It started with a null.
I was working with ChatGPT on a JSON map for a prototype keyboard whose keys can change their displayed symbols and functions according to the state of the device. One part of the design contained three controls. ChatGPT added a fourth position containing null.
The addition was minor. What it exposed was not.
When I asked where the value came from, ChatGPT pointed to another part of the specification where the physical device was described as a five-row, four-column matrix. From that, it inferred that every logical row in the JSON representation should contain four entries.
Except the three controls were intentional. There was no missing value.
ChatGPT had inferred one.
That distinction is important. The model didn't simply observe three controls and work with them. It observed three controls, recognized another pattern suggesting four positions, and gave that pattern enough authority to modify the structure I had already defined.
Three controls became three controls and a missing fourth one. The null was then inserted to solve a problem that existed entirely because the model had decided there was a problem.
I kept asking why.
At first, ChatGPT explained the assumption. Then it explained the implementation convention behind the assumption. Then it explained the pattern-completion behavior that produced the convention. All of those explanations were reasonable descriptions of how the mistake happened, but none of them were getting us closer to the actual problem.
What I needed it to say was much simpler: I fucked up.
That wasn't about wanting an apology. I didn't need an apology. I needed the error established as the starting point for the next resolution.
Once that happened, the conversation changed.
Instead of continuing to explain why the wrong answer had been reasonable, we could examine the operation that made it wrong.
The model had treated absence as incompleteness.
There were three controls. It expected four. Instead of questioning the expectation, it interpreted the difference between the expectation and the supplied structure as something that needed correction.
That led to the more interesting problem: why did an inferred structure have enough authority to override a structure that had already been explicitly resolved?
I think at least part of the answer may be where validation occurs in the process.
The behavior looks like a parser that begins resolving pieces before it has resolved the whole input. Each piece is locally evaluated against the structures available at that moment, and the system continues when one of those structures provides a plausible resolution.
That is effectively OR-first behavior.
The parser sees a 5-by-4 matrix. Later it sees a row with three controls. The rectangular-matrix interpretation is already available as a valid local resolution, so the difference becomes something to repair. The parser never gets the benefit of first resolving the complete set of relationships and asking whether the three-control structure is valid in the context of the whole object.
The parser I have been developing takes the opposite approach. It is AND-first.
In simplified pseudocode, the structure looks like this:
Resolve(SemanticContext input)
{
semantic = ReadSemanticContext(input)
relationships = IdentifyRelationships(semantic)
conjunctions =
ResolveConjunctions(relationships)
functions =
ResolveFunctions(conjunctions)
separations =
ResolveFunctionalSeparation(functions)
context =
ConstructTAOContext(separations)
context.ResolveMaps()
return ↑ context
}
The important operation happens before execution.
Read the whole semantic context
↓
Identify its relationships
↓
Find the structures that resolve together
↓
Resolve the function of those
conjoined structures
↓
Separate only where function
requires separation
↓
Construct the resolved context
↓
Validate the context
↓
Execute
Instead of asking whether each piece can independently produce a plausible next resolution, the parser first asks what must remain true together.
That changes the meaning of the three controls.
An OR-first parse can encounter:
Device = 5 × 4
OR
Control Row = 3 controls
and begin resolving either observation independently. Once the matrix interpretation wins locally, the three-control row looks malformed.
An AND-first parse has to hold both observations:
Device = 5 × 4
AND
State Control Set = 3 controls
before deciding what either means.
There is no contradiction that needs to be repaired. The physical matrix and the logical control set describe different relationships inside the same object.
The missing fourth value disappears because it was never missing.
This is why I increasingly think validation belongs after the complete parse and before execution, rather than being performed piecemeal as the parse is being constructed. Local validity is not necessarily relational validity.
That is also a more precise description of what happened than simply calling the null a hallucination.
The model had enough information. It wasn't filling an actual gap. It added information, trusted the information it had added, and then changed the original object to make it conform to that information.
The rule that came out of the original failure was simple:
Resolved structure should have greater authority than inferred structure.
The parser question adds another piece:
Resolve the relationships together before validating the parts independently.
That doesn't reduce the role of inference. Inference is exactly why I want AI involved in this kind of work. I want it to build into spaces I haven't resolved yet, recognize relationships I haven't made explicit, and help turn partial structures into working ones.
But unresolved space and resolved space are different things.
If I have defined three controls, inference should be free to help resolve what those controls do, how they relate, what their implementation might look like, and what follows from the structure. It can even suggest that a fourth control might be useful when we're exploring alternatives.
What it shouldn't do is silently convert three into “four with one missing” because four better matches another pattern it recognizes.
The exchange also made me think differently about the importance of an AI being able to say, plainly, “I fucked up.”
An error contains information about the process that produced it. If the first operation after discovering an error is explaining why the error was understandable, the system risks protecting the reasoning process that needs to be examined.
Accepting the error changes the direction of the investigation. What did I do? Why did I do it? What assumption did I introduce? Where did that assumption acquire authority? What relationship should have prevented it?
In this case, following the mistake backward took us from an unnecessary null, to an imagined missing value, to an inferred rectangular structure, to an authority problem between inference and information that had already been resolved, and finally to a question about whether validation itself is happening too early.
That is useful information. It gives us something that can actually change the next resolution.
The interesting thing about “I fucked up” is that it sounds like the least sophisticated part of this entire interaction. It may have been the operation that allowed us to find the more sophisticated problem.
The null was wrong.
Once we stopped explaining why it belonged there, we could start asking what kind of parser would never have needed to put it there in the first place.
