A cognitive architecture built to be changed by experience.
Most current AI systems begin life with an unfair advantage: they have already consumed a substantial fraction of what humans have written down. TERNION ONE starts from somewhere less comfortable. What happens if an artificial system has to develop through experience instead?
If experience matters, it should leave a mark.
Large language models are extraordinarily capable, but most of what they can do comes from training that happened before you ever meet them. They can be given memory, tools and long-running context, but the underlying model still has most of its behaviour already shaped.
I want to reverse that arrangement.
If something happens to the system today, I want that event to alter the way it approaches tomorrow. A bad prediction should matter. A successful action should matter. A memory should matter because it changes what the system expects next.
TERNION ONE grew out of that problem.
A system with a history of its own.
TERNION ONE is an experimental cognitive architecture built around persistent state and learning from interaction.
Its core is intended to maintain its own memory, predictions, learned behaviour and an evolving model of its environment. The important word there is own. Those things are not supposed to vanish when a conversation ends or a model connection disappears.
The loop underneath it is deliberately plain:
It observes something, forms an expectation, acts, then finds out whether the expectation survived. The difference becomes useful information.
That information is carried forward. If the same situation appears again, the system should not treat it as though nothing happened last time.
An LLM can help. It is not the thing itself.
Language models can be connected to TERNION ONE. They may provide language, outside knowledge and other useful capabilities.
But they are not supposed to be TERNION ONE, or quietly do its thinking for it.
Disconnect the language model and the underlying cognitive system should remain intact. It should still remember what happened, preserve what it learned and continue to change through experience.
Two copies should eventually stop being copies.
Start two instances from exactly the same state, then let different things happen to them.
One may learn that a particular signal usually precedes trouble. The other may never encounter it. One may keep a strategy because it worked repeatedly; the other may abandon the same strategy after a run of failures.
Six months later, I do not want those systems to remain interchangeable.
First, prove the boring bits.
There is a temptation in AI to sprint straight toward AGI, consciousness and artificial persons. Interesting questions. Terrible first requirements.
TERNION ONE has a much less dramatic first job: learn something useful through interaction, without pretrained task knowledge or an LLM solving the problem in the background.
Then I can ask:
Those questions have answers we can actually measure. If the architecture cannot survive them, the grander questions can wait.
The engineering comes first. The awkward questions can wait their turn.
The longer-term work touches continual learning, predictive learning, persistent memory, world models, temporal processing, concept formation, self-modelling, reflective cognition and persistent artificial identity.
If those pieces start working together, the project eventually runs into a less comfortable question:
I don’t know the answer, and I’m wary of anyone who claims certainty. Consciousness is still an open scientific and philosophical problem. TERNION ONE does not need to solve it in order to be useful. But if the system eventually gives us a reason to ask the question, I would rather examine it than rule it out in advance.
The ideas can be public before the machinery is.
I’m talking publicly about TERNION ONE before publishing the internal architecture. That is deliberate.
Ideas that look elegant on paper have an irritating habit of becoming less elegant when they are required to execute. The system is still being built, tested and changed, and I would rather let the architecture earn its claims before turning it into a public specification.
I’ll talk openly about the problems, experiments, results and principles. Some of the machinery can stay behind the curtain until I know which parts deserve to remain.
Anthony Williams
Software engineer and creator of TERNION ONE.
I’ve spent my career building production systems: distributed software, cloud infrastructure, event-driven platforms and applications that usually become more interesting once real people start using them.
TERNION ONE grew out of a different sort of problem. Not how to make software answer more questions, but how to make what happens to a system matter to the system itself.
It is experimental, unfinished, and some of the ideas will undoubtedly be wrong, which is to be expected. However, those wrong ideas become much more interesting once the machine is capable of proving them wrong.
Contact us
Have questions about TERNION ONE? Interested in collaborating or learning more?
Send me a message.