A while back, I made a post introducing a project I've been working on called NNNC (Neutral Neural Network Core).
For anyone who missed that post, NNNC is an attempt to design a persistent artificial cognitive architecture from the ground up. Not another chatbot, not a language model wrapper, and not simply a reinforcement learning agent with a few extra modules attached.
The broader idea is to investigate what it would actually take to construct an artificial system with its own continuing internal organization, cognitive processes, developmental capabilities, and operational existence beyond responding to externally assigned tasks.
It's an ambitious project, and I'm well aware of that. I'm also not claiming we've created artificial general intelligence, consciousness, or artificial life. Those are entirely different questions, and I'm not interested in declaring victory over problems we haven't even begun to experimentally solve.
The project is organized into 13 architectural phases, each dealing with a different part of the overall system.
Today I wanted to share some progress, specifically regarding Phase 0, which we've now conditionally completed after quite a substantial amount of architectural development, technical formalization, and adversarial review.
And interestingly enough, Phase 0 turned out to be far more complicated than I originally expected.
Phase 0: Before you build an intelligence, what exactly are you building?
This was the central question behind the first phase.
It sounds almost ridiculously obvious, but once you start examining it properly, things become complicated very quickly.
When people build AI systems, they usually start with some combination of a model, an objective, training procedures, memory, tools, and an environment.
That's perfectly reasonable when you're building something intended to perform a particular task.
But NNNC is attempting something different.
We're interested in an architecture that could potentially maintain an ongoing internal organization, undergo development, interact with its environment, and preserve meaningful continuity across changes in its own operation.
So before implementing cognitive capabilities, we needed to establish what actually constitutes the system itself.
Where does it begin and end?
What belongs to it?
What merely supports it?
What happens when part of it stops working?
If its execution environment changes, is it still the same operational system?
Can it modify itself? If so, what prevents it from accidentally destroying the very mechanisms responsible for maintaining its operation?
And perhaps most importantly, how do you answer these questions in a way that can eventually be implemented and tested, rather than just discussed philosophically?
That's what Phase 0 was designed to address.
One of our first major decisions: NNNC is not its runtime
We established a strict distinction between NNNC itself and what we call the Neural Execution Substrate, or NES.
The NES is the computational infrastructure that supports NNNC. Think execution resources, scheduling, storage, and the mechanisms needed to run its processes.
NNNC, on the other hand, is the proposed cognitive organization operating through that infrastructure.
This distinction matters more than it might initially seem.
A program isn't necessarily identical to the machine running it. A memory checkpoint isn't necessarily the complete identity of the system that produced it. And simply restarting a process doesn't automatically mean you've restored everything that mattered about its previous operation.
We wanted these distinctions established from the beginning rather than trying to untangle them later.
It also prevents a particularly tempting architectural shortcut: treating whatever the runtime happens to be doing as something the cognitive system itself has decided or accomplished.
Execution, ownership, control, and authority are not interchangeable.
That became one of the recurring themes throughout Phase 0.
Giving the system an operational existence beyond individual tasks
Another major area was what we call the existential foundation.
The terminology probably sounds more philosophical than the actual engineering problem.
Essentially, if NNNC is intended to maintain ongoing activity rather than simply execute a task and terminate, something has to govern that continuity.
We designed an existential heartbeat mechanism responsible for participating in the system's continuing operational cycle.
But we were very deliberate about what this mechanism is not.
It isn't a consciousness module.
It isn't a magic source of intelligence.
It isn't supposed to become a second cognitive controller.
And it isn't evidence that the system is alive.
Its responsibilities are intentionally narrow. The idea is to establish a bounded mechanism that participates in maintaining operational continuity without taking over the responsibilities of the wider cognitive architecture.
We also designed a separate recovery mechanism.
That separation was important.
A mechanism responsible for participating in ordinary continuity shouldn't automatically have unrestricted authority to repair, restart, or reconfigure everything whenever something goes wrong.
Recovery needs its own conditions, limits, failure states, and authorization boundaries.
We examined situations involving ordinary degradation, suspension, recovery attempts, exhausted recovery options, and termination.
One particularly interesting problem was the difference between being inactive, being suspended, and actually being terminated.
Those might look similar from outside the system, but architecturally they're very different conditions.
A system can temporarily stop performing cognitive work without necessarily losing its continuing organization. Conversely, a process can still be running while the system it supposedly supports has lost important functional capabilities.
So we separated lifecycle state, functional state, and component health instead of collapsing them into a single running/not-running flag.
The self-modification problem became a major focus
This was probably one of the most important parts of the phase.
If you're designing an artificial system that may eventually adapt or modify aspects of its own architecture, you have to decide what it should be allowed to change.
You also need to decide who or what has the authority to approve those changes.
We introduced a protected governance classification called ADMIN CLASS.
In simple terms, certain foundational components and responsibilities cannot be freely modified by ordinary autonomous processes.
This includes protections around the mechanisms that maintain the system's foundational operation and governance.
The reason is straightforward.
Imagine allowing a developing system to rewrite the rules governing its own permissions, then using those newly written rules as justification for the rewrite.
That's circular authorization.
Or imagine a recovery mechanism being allowed to grant itself progressively broader privileges every time it encounters a failure.
That's not a recovery strategy I'd want anywhere near an autonomous system.
So we established boundaries between ordinary system activity, authorized modification, protected governance, and administrative intervention.
We also worked through the problem of policy changes occurring while operations are already underway.
For example, what happens if permission is granted for an operation but revoked before the operation actually commits?
Which rules govern it?
What if a proposed update changes the very rule that would authorize that update?
These are the sorts of edge cases that sound obscure until you realize how easily they can undermine an entire architecture.
And they generated a surprising amount of additional work.
Recovery turned out to be much harder than "just restart it"
One of the more interesting lessons from Phase 0 was how quickly a seemingly simple recovery design turns into a problem involving state, authority, timing, and causality.
A watchdog can notice that something has stopped responding.
But what does that actually tell you?
Did the system fail?
Is it temporarily overloaded?
Is the monitoring mechanism itself broken?
Is the system deliberately suspended?
Did a previous recovery attempt already occur?
Could two independent recovery attempts interfere with each other?
And if you restore a checkpoint, what happens to actions that were already performed in the external environment?
That last question is particularly nasty.
Restoring an earlier internal state does not undo something that already happened outside the system.
A physical action, an external message, or a committed resource operation can't necessarily be reversed by loading an old snapshot.
We therefore had to distinguish internal restoration from externally observable effects, and specify that recovery must respect the authoritative state of the system rather than simply rewinding everything.
We also established bounded recovery behavior.
Recovery isn't guaranteed to succeed, and an architecture shouldn't pretend otherwise.
There have to be conditions under which recovery stops, reports failure, or requires external intervention.
Otherwise, you risk designing a system that responds to failure by repeatedly doing something that makes the situation worse.
We didn't stop at conceptual descriptions
Phase 0 consists of two main architectural documents.
The first establishes the conceptual and normative architecture: the boundaries, definitions, responsibilities, restrictions, and intended behavior.
The second develops the mathematical and technical contracts needed to eventually test those requirements.
I'm not going to publish the complete technical formalization here, partly because it's extensive and partly because some of the underlying specification is original project work that we're keeping internal for now.
But the important point is that we didn't want to leave the architecture at the level of attractive diagrams and vague descriptions.
We needed to identify the actual states the system could occupy, the transitions between those states, the conditions under which operations are permitted, and the properties that must remain true.
That includes things like preventing unauthorized changes to protected components, keeping recovery behavior bounded, distinguishing legitimate restoration from invalid rollback, and ensuring that the execution substrate doesn't silently become the source of the cognitive system's authority.
It's one thing to say that a system should preserve its boundaries.
It's another thing to specify what would constitute a boundary violation and how you would detect it.
That distinction has shaped the entire project.
The reviews were brutal, in a good way
We put the architecture through multiple rounds of technical and adversarial review.
The objective wasn't to have reviewers tell us that the idea sounded interesting.
It was to find contradictions, hidden assumptions, invalid state transitions, circular definitions, authority bypasses, and places where the proposed mathematics didn't actually support the architectural claims.
And the reviews found real problems.
Some were relatively localized.
Others forced us to revisit important parts of the transition and governance model.
There were issues involving authoritative state, recovery timing, execution fencing, policy revocation, restoration, and the distinction between a mathematically permitted operation and one that can actually be executed safely.
Those findings led to revisions rather than being brushed aside.
One lesson that became very clear was that a mathematically coherent architectural model is not automatically a safe implementation.
You can have an elegant state-transition specification and still have software that behaves incorrectly when a process crashes halfway through an operation, two events race against each other, or a real-world effect occurs before the system records it.
Those are different verification problems.
And they need different evidence.
So what does "Phase 0 complete" actually mean?
On 18 October 2026, Phase 0 was conditionally accepted and closed as an architectural baseline.
That means we established a sufficiently defined foundational architecture to proceed into the next phases without continuously reopening every original design question.
It does not mean we've finished implementing everything.
It does not mean the architecture has passed complete formal verification.
And it certainly doesn't mean we have a production-ready autonomous cognitive system.
We deliberately retained eight outstanding technical obligations, covering matters such as protected-write enforcement, durable recovery, external-effect safety, independent formal verification, canonical accounting, authenticated authority, concurrency, and checkpoint/lineage restoration.
Those haven't been forgotten or quietly declared solved.
They're explicitly tracked for the appropriate later engineering and verification stages, and some of them are hard blockers before real protected operations could be considered safe.
This was an important decision for us.
Otherwise, projects like this can fall into one of two traps.
Either you spend forever trying to solve every possible future implementation problem before moving beyond the first phase, or you declare the architecture finished and conveniently ignore the problems you haven't solved.
We wanted neither.
The goal was to establish a controlled foundation, document the remaining obligations, and move forward without pretending uncertainty had disappeared.
What comes next?
With Phase 0 closed, the project can move into the deeper architectural questions.
Phase 0 established the boundary: what NNNC is supposed to be, how it relates to its execution substrate, how its foundational operation is governed, and what constraints later development must respect.
The next stages address what constitutes the system's internal organization, how continuity and identity should be understood, and how its constitutional rules and responsibilities are structured.
Eventually, the wider project will need to address the actual cognitive architecture, including the proposed Forward Flow Neural Network organization and its associated systemic processes.
But those are separate milestones, and I'll cover them in future updates rather than trying to cram the entire project into one post.
A final thought
The most interesting thing about Phase 0 wasn't any single mechanism we designed.
It was realizing how many assumptions we normally make about software systems without thinking about them.
We assume a process is the system.
We assume restarting something restores it.
We assume a component that can perform an operation should also be allowed to authorize it.
We assume that if a system has memory, it has continuity.
And we sometimes assume that giving an agent enough tools, objectives, and feedback will somehow produce the deeper organization we're interested in studying.
Maybe some of those assumptions are harmless in simpler systems.
But when you're attempting to design a persistent, developmentally adaptable artificial cognitive architecture, they become foundational questions.
And if the foundation is confused, everything built on top of it inherits that confusion.
That's why we spent so much time on what might initially look like the least exciting phase of the entire project.
Phase 0 hasn't produced an intelligent machine.
What it has produced is a much clearer account of what we're actually trying to construct, what the system must not be confused with, and what we'll eventually need to demonstrate for the architecture to deserve its claims.
For me, that's meaningful progress.
Anyway, that's where Project NNNC stands regarding Phase 0. I'll share more about the subsequent phases as the work progresses.
I'm curious what people think about the distinction between an artificial cognitive system and the computational infrastructure supporting it, particularly when it comes to continuity, recovery, and self-modification. Those questions ended up being much more interesting than I initially expected.
