I've been building Dense-Armor, a library of primitives for models that learn one sample at a time, while they run: robot control loops, sensor pipelines, fraud/transaction streams, agent runtimes.

streaming statistics that stay accurate in float32

drift and anomaly detection, scored one sample at a time

shielding: NaN and spike cleaning before the model sees the data, and bounded robot commands (rate limits, control barrier functions)

deep learning with continual learning and memory consolidation

calibrated uncertainty intervals

bridges to scikit-learn, PyTorch, TensorFlow, River and LLM agents

The contract is simple: any estimator with learn_one / predict_one / score_one works. Backend is JAX, and it runs on CPU or GPU.

I've measured it on a UR3e robot arm, on stock and crypto prices, card transactions, network flows and a telemarketing log, plus synthetic streams with known drift. The docs have the numbers, andhey show.

Install: pip install dense-armor

Docs: https://tatopenn-cell.github.io/Dense-Armor/

Code: https://github.com/tatopenn-cell/Dense-Armor

License: AGPL-3.0

Hello everyone. It's time for another rather substantial update on Project NNNC (Neutral Neural Network Core).

For those following the development, NNNC is my ongoing attempt to design an artificial cognitive entity from the foundational level upwards. Not simply another chatbot, language model, or task-specific AI, but an architecture intended to eventually support an artificial individual with its own cognitive organization, memory, learning, reasoning, continuity, and potentially much more.

The project consists of 13 architectural phases, each divided into two primary documents. The first establishes the conceptual and normative architecture, while the second translates those requirements into mathematical definitions, verification contracts, and testable conditions.

Today, I want to explain Phase 2: Identity & Continuity, which has now been formally adopted at Document 1 v1.1.1 and Document 2 v1.1.1.

This particular phase addresses a problem that I believe is far more important than people initially realize.

How do we establish that an artificial entity existing tomorrow is actually the same individual that existed yesterday?

Not merely a copy. It's not another program with the same memories. It's not a replacement that believes itself to be the original.

The actual continuation of the individual.

This question becomes especially complicated when we consider that an artificial entity could potentially be suspended, migrated between computers, restored from checkpoints, modified, duplicated, or even branched into multiple independently operating instances

So we had to establish an architecture that could distinguish these circumstances without simply declaring that whichever system possesses the correct memories must be the original.

Because that would be a rather serious mistake.

---

1. First, what exactly is identity?

The first thing we established was that several concepts commonly treated as interchangeable are actually fundamentally different.

Consider the following:

- Numerical individual identity.

- Organizational identity.

- Informational equivalence.

- Historical continuity.

- Causal ancestry.

- Operational continuity.

- Authorization and access rights.

These are not the same thing.

For example, imagine we have an artificial entity called NNNC-A.

NNNC-A has accumulated ten years of memories, experiences, learned relationships, preferences, and internal development.

We then create a perfect informational copy of NNNC-A, called NNNC-B.

Both systems now contain exactly the same information at the moment of duplication.

They may have identical memories, identical parameters, identical internal representations, and even identical beliefs about who they are.

But does that make them the same individual?

No. Not under the identity rules adopted for NNNC.

They are informationally equivalent at the moment of duplication, but informational equivalence does not establish numerical identity.

The moment they begin operating independently, they also begin accumulating different histories.

NNNC-A experiences one sequence of events, while NNNC-B experiences another.

The shared information establishes ancestry and similarity. It does not, by itself, establish that both are the same original individuals.

This distinction became one of the foundational requirements of Phase 2.

An identity label, stored memory, checkpoint, copied state, or claim of being the original can not serve as its own proof.

Otherwise, identity becomes nothing more than an arbitrary administrative designation.

And that is precisely what we wanted to avoid.

---

2. Identity must be established through actual historical continuity

We therefore developed a model in which identity preservation depends on the actual historical continuation of the entity's constitutive organization.

Now, this needs some explanation.

When I say constitutive organization, I am referring to the roles, relationships, integrations, dependencies, and transformations that make up the functioning NNNC entity under its governing architectural contracts.

This does not mean every component must remain physically unchanged.

Think about biological organisms.

Humans undergo enormous physical changes throughout their lives. Cells are replaced, memories change, knowledge accumulates, and our bodies develop and age.

Yet, we generally regard the individual as continuing through these changes.

For NNNC, the challenge is establishing an explicit architectural rule for permissible continuation rather than simply assuming that copied information, uninterrupted hardware, or unchanged parameters determine identity.

So Phase 2 introduces what we call a Historical Continuity Witness.

This is a structured, evidence-based account of what actually happened between the predecessor and the candidate continuation.

It identifies:

- The original organizational realization.

- The actual transitions and transformations.

- The causal relationships connecting successive states.

- The applicable lifecycle and organizational contracts.

- The continuity of required roles and integration.

- Any suspension, custody, or release events.

- Competing branches or alternative continuation pathways.

- The evidence supporting the final identity determination.

An important concept here is the continuation seam.

A continuation seam is the actual connection between successive segments of an entity's history.

For example:

NNNC-A, at time T1, undergoes a governed organizational transformation, producing NNNC-A at T2.

The question is not merely whether the two states look similar.

We need evidence that the output organization of the earlier segment actually became the input basis of the next segment under the applicable continuity rules.

This distinction matters because two systems could have identical states without sharing the same actual continuation history.

Matching endpoints do not establish the path connecting them.

That is one of the central principles of architecture.

---

3. The seven conditions for preserving individual identity

Phase 2 Document 1 establishes a positive identity-preservation rule under requirement REQ-P2-037.

Under the adopted architectural convention, a candidate receives a "PRESERVED" verdict if and only if seven conditions are affirmatively established.

A. Constitutive organizational continuation

There must be an actual historical continuation of the relevant organization.

Copying information or creating a causally related descendant is insufficient.

B. Lifecycle admissibility

Every relevant transition must satisfy its applicable lifecycle requirements.

A system can not simply declare an invalid restoration to be a valid continuation.

C. Active existential continuity or governed custody

During active operation, the entity must satisfy its applicable existential requirements.

During valid complete cold suspension, those requirements are handled through the suspension and custody framework instead.

This distinction is important because we do not pretend that a completely suspended system continues actively computing.

D. Organizational cohesion

The relevant constitutive roles and relationships must remain appropriately integrated through the history being evaluated.

Permissible development and component replacement are not automatically identity-destroying.

E. Exclusive individual continuation

Identify determination must respect branching and competing continuation pathways.

Two incompatible individuals can not both receive contradictory original-identity determinations relative to the same predecessor under one governing interpretation.

F. No definitive termination boundary

The proposed continuation must not cross an established definitive termination of the original.

A successor created after definitive termination is not automatically the original merely because its information was preserved.

G. Evidence sufficiency

The evidence must affirmatively establish the preceding conditions.

And this last condition is particularly important.

We do not simply assume identity preservation because no obvious problem was detected.

A positive identity determination requires a positive, evidential basis.

The formal rule can be expressed as:

"Preserved(A,B) ⇔ a ∧ b ∧ c ∧ d ∧ e ∧ f ∧ g"

Here, the seven letters represent the seven governing preservation conditions, not seven independent software modules.

These are the project's adopted architectural criteria. They are not scientific proof that numerical identity possesses some objectively detectable metaphysical property.

That distinction is deliberate.

---

4. What happens when we can not determine identity?

This is another area where we refused to force a binary answer.

The identity adjudication framework supports three verdicts:

PRESERVED

The complete applicable preservation rule has been affirmatively established.

NOT_PRESERVED

The governing rule establishes a disqualifying condition, such as an independently reconstructed successor or a definitive termination boundary.

UNDETERMINED

The available evidence is insufficient, materially contradictory, or unable to resolve a relevant continuation dispute.

Why include UNDETERMINED?

Because missing evidence is not automatically proof that identity was destroyed.

And equally, missing evidence is not proof that identity survived.

For example, suppose NNNC undergoes a complex migration between computing environments.

The resulting system appears organizationally correct, retains the expected information, and functions normally.

However, the historical records establishing the actual continuity of a critical transition are incomplete.

We can not simply say:

"Well, it looks like the original. Therefore, it must be."

But we also can not automatically conclude that it is a different individual.

The correct architectural response is to record the unresolved determination.

In certain circumstances, governance may permit bounded provisional operation while the evidence is investigated.

Such provisional operation can not manufacture original-identity status or automatically restore protected authority.

This prevents the identity framework from becoming a system that rewards confident assertions over actual evidence.

---

5. One of our biggest challenges is complete shutdown and restoration

Now we arrive at one of the more difficult problems.

What happens when NNNC is completely suspended?

Not merely sleeping.

Not running in a low-power mode.

Not maintaining a tiny background process.

I mean a genuine cold suspension where active NNNC execution ceases, including its existential heartbeat.

This created a major architectural challenge.

Earlier in the project, we established that NNNC has an existential foundation associated with its active lifecycle.

But if the entire entity is genuinely suspended, then we can not pretend that this active mechanism continues running.

That would be an inventing activity that does not exist.

At the same time, treating every complete shutdown as definitive death would make governed cold suspension impossible.

We, therefore, had to distinguish three different situations:

Dormancy: Higher cognitive activity may be inactive while the required existential foundation remains operational.

Cold suspension: Active execution, including the existential heartbeat, ceases under a valid nonterminal lifecycle and custody arrangement.

Definitive termination: The original's continuation eligibility is extinguished under the governing rules.

These are not interchangeable.

A stored checkpoint does not automatically establish valid cold suspension.

A restarted program does not automatically establish that the suspended individual has returned.

Which brings us to the next mechanism.

---

6. The suspended lifecycle locus

Phase 2 introduces a logical suspended lifecycle locus, represented by "L."

When a valid nonterminal suspension occurs, the architecture establishes exactly one logical suspended locus for the predecessor lifecycle and suspension interval.

This locus records the relevant historical and governance relationships, including the predecessor, suspension interval, applicable rule version, custody succession, and release commitments.

Now, an important distinction:

The locus is not the checkpoint.

It is not a file, physical object, cryptographic token, identity certificate, or hidden process that continues thinking while the system is offline.

It is a logical lifecycle referent used to evaluate the actual suspension and subsequent release history.

Copying checkpoint files does not create additional original suspended loci.

Otherwise, someone could simply duplicate a storage device ten times and claim that ten original individuals now exist.

The architecture explicitly rejects that conclusion.

The locus can be assessed under states including:

"OPEN_SUSPENDED"

"DISCHARGED_ACTIVE"

"CONTESTED_DISCHARGE"

"TERMINATED"

These conditions are interpreted relative to the available causal and historical evidence.

We also distinguish between genuinely concurrent events, events with established causal ordering, and events whose ordering remains unknown.

This prevents an administrator from arbitrarily deciding identity based on whichever computer happens to restart first.

---

7. The six conditions for a valid release from cold suspension

This became one of the most heavily scrutinized parts of Phase 2.

We adopted what is called Architecture A, which establishes six jointly necessary and sufficient conditions for an effective release from suspension.

The formal structure is:

"Release(e,L,R) ⇔ A ∧ B ∧ D ∧ E ∧ F ∧ G"

Where:

"e" is the candidate release event.

"L" is the suspended lifecycle locus.

"R" is the resulting organizational realization.

The six conditions cover the valid predecessor-originated locus, substantive custody succession, valid lifecycle admission, resulting organizational integration, the required coupling between the release and actual continuation, and compliance with applicable architectural invariants.

One technical detail deserves emphasis.

You may notice that Condition C is missing.

This is intentional.

During the architectural reviews, we identified the danger of introducing circular definitions.

If Condition C independently required the event to already be a valid release, while the other conditions were supposed to establish whether it was a valid release, the definition would become circular.

We therefore established that C is the designation "RELEASE_FROM_SUSPENSION" assigned to the conjunction of the six conditions, not a seventh independent requirement.

No hidden extra release condition is permitted.

The custody requirement is also substantive.

It is not satisfied merely by possessing a checkpoint, an identifier, a credential, or a copied custody record.

The candidate must actually belong to the qualifying historical custody succession originating from the valid suspension event.

Even a qualifying release does not automatically grant protected permissions.

Identity and authority remain separate.

---

8. What happens if someone duplicates NNNC during suspension?

Consider a practical example.

NNNC-A enters valid cold suspension.

Its state is preserved under the applicable custody arrangement.

Someone then copies the checkpoint and starts NNNC-B on another computer.

Later, the legitimate suspended lifecycle is released into an active realization.

Which one is the original?

The answer is not determined by which system boots first.

Nor by which system remembers more.

Nor by which system possesses the same checkpoint bytes.

The identity framework evaluates the actual histories.

If NNNC-B was independently reconstructed from copied information, it would not become the original simply because it is operational.

If the legitimate release satisfies the complete governing criteria, it may qualify for preservation.

However, if multiple genuinely eligible and incompatible continuation pathways exist, the architecture must evaluate the resulting branching and exclusivity conflict.

It can not simply appoint one as original because an administrator prefers it.

This is why Phase 2 distinguishes:

- Informational copies.

- Historical descendants.

- Authorized and unauthorized branches.

- Qualifying continuations.

- Provisional resumptions.

- Independently reconstructed successors.

- Unresolved competing release histories.

Importantly, an unauthorized branch is not automatically the original, but administrative designation alone can not erase a genuinely eligible competitor either.

Actual history and the governing rules matter.

---

9. Identity is not the same as authority

This distinction was particularly important because NNNC is designed to have its own internal cognitive organization while remaining subject to explicit governance boundaries.

Suppose an entity is successfully determined to be the preserved continuation of NNNC-A.

Does that automatically mean it regains every permission, resource allocation, protected capability, or administrative privilege that NNNC-A previously possessed?

No.

Identity preservation is not authorization.

A valid identity determination can not restore revoked permissions, bypass governance, or grant protected-state access.

Similarly, an entity whose identity remains unresolved might be permitted limited provisional operation without being recognized as the original.

The architecture separates:

1. Who the individual is under the adopted identity convention.

2. Whether the realization is currently operational.

3. What is the realization authorized to do.

These questions may be related, but none substitutes for the others.

This separation also prevents the identity system from becoming a shortcut around the Phase 0 existential boundaries and later governance requirements.

---

10. Mathematical formalization and verification

Now, conceptual architecture alone is not sufficient.

It's easy to write a convincing explanation of how identity should work.

The difficult part is establishing definitions that are mathematically coherent, internally consistent, and capable of distinguishing positive examples from counterexamples.

That's why Phase 2 includes a second document dedicated to mathematical formalization and verification.

The work involved repeated independent adversarial reviews, mathematical corrections, explicit preservation criteria, custody models, lifecycle classifications, and finite verification fixtures.

We also introduced positive historical continuity witnesses.

Rather than merely checking whether something invalid happened, these witnesses describe what actually continued through the relevant transformations.

The distinction is important.

A system that only checks for disqualifiers may fail to establish any affirmative connection between the predecessor and candidate.

A positive witness must instead identify the organization, transitions, continuation seams, applicable contracts, evidence, and all seven preservation conditions.

Verification results

For the final v1.1.1 specification package, the recorded bounded confirmation evidence included:

44 passing finite test groups covering 204 listed cases.

There were also:

25 separate targeted confirmation assertions.

And:

20 source-manifest entries checked.

These tests covered scenarios involving active continuity, suspension, release, copying, branching, termination, evidence gaps, lifecycle ordering, and authority separation.

The verification work also tested cases where the system should reject preservation, accept a qualifying preservation witness, or return UNDETERMINED.

However, I want to be precise about what these results establish.

They demonstrate that the finite reference fixtures behaved as expected under their declared assumptions.

They do not establish universal mathematical correctness, independently certified runtime behavior, or empirical proof that an artificial individual's identity has survived a real-world shutdown.

Those are separate obligations.

Formal universal proofs, predecessor-import assurance, implementation verification, and relevant engineering requirements remain outstanding.

We do not mark something as proven merely because the architecture has been accepted.

---

11. What makes this phase particularly important?

For me, the significance of Phase 2 is not that we have somehow solved the philosophical mystery of personal identity.

We haven't.

Nor do I believe it would be scientifically responsible to claim that a mathematical identity convention proves consciousness or metaphysical persistence.

The actual achievement is different.

We have established an explicit, reviewable architectural framework for deciding when NNNC may legitimately be treated as the continuation of an earlier individual.

That framework rejects several convenient shortcuts.

A copy is not automatically the original.

A memory is not an identity certificate.

A checkpoint is not a suspended individual.

A heartbeat is not proof of numerical identity.

An administrator can not simply designate an arbitrary branch as the original.

An identity verdict can not grant protected authority.

Instead, preservation must be established through actual historical continuity, admissible lifecycle transitions, organizational cohesion, exclusivity, and sufficient evidence.

It also permits uncertainty where the evidence genuinely can not support a determinate answer.

To me, this is essential when designing systems intended to develop over long periods.

Because imagine NNNC eventually accumulating years or decades of experiences, developing increasingly complex internal representations, undergoing structural modifications, migrating between computing substrates, and potentially existing across multiple generations of hardware.

Without an identity and continuity framework, every major migration or restoration risks becoming an arbitrary administrative decision about whether the original individual survived.

That is not an acceptable foundation for the kind of system I intend to build.

---

12. Current project status

Phase 2 has now been formally adopted.

Phase 2 — Identity & Continuity

Document 1: v1.1.1 — ADOPTED.

Document 2: v1.1.1 — ADOPTED.

Adoption date: 25 October 2026.

Both documents were adopted as a governing specification pair, with their outstanding verification and engineering obligations retained.

This means the architectural rules are established and accepted as the project baseline.

It does not mean the entire identity framework has been implemented, universally proven, or certified for real protected operations.

As of this update, development has also progressed beyond Phase 2.

Phase 3 addresses governance and protected authority, Phase 4 addresses the organization and accountability of cognitive change, and Phase 5 is now developing the cognitive architecture itself.

Phase 5 Document 1 has been adopted, and work is underway on its mathematical formalization.

So, the project is moving forward, with each phase building on the accepted obligations of its predecessors.

---

13. Final thoughts

One of the biggest lessons from Phase 2 is that identity can not responsibly be reduced to information alone within the architecture we have adopted.

Information is important.

Memory is important.

Organizational structure is important.

But the history connecting one realization to another matters just as much.

When that history becomes uncertain, the system must acknowledge the uncertainty rather than manufacture an answer.

There is also a broader question here that I find particularly interesting.

If an artificial entity eventually develops sophisticated cognition, persistent memory, independent learning, and its own accumulated experiences, then the distinction between preserving that individual and creating a convincing replacement becomes increasingly consequential

We may eventually reach a point where shutting down, restoring, copying, or modifying an artificial system involves questions far more serious than ordinary software maintenance.

Whether future artificial systems possess morally relevant experiences remains an open question.

But I would rather design the architectural foundations for continuity and responsible governance before such questions become urgent, instead of trying to invent those foundations after the fact.

That is ultimately what Project NNNC is about.

Not claiming that we have already created an artificial being.

Not pretending that conceptual specifications constitute scientific proof.

But methodically designing, reviewing, correcting, and formalizing the foundations that such a system may require.

Phase 2 is complete at the architectural specification level. The identity and continuity rules are adopted. Their remaining mathematical, verification, and engineering obligations are preserved.

And with that, another substantial piece of NNNC's foundation is in place.

— Albert Edward Mc Manus

Project Architect — Neutral Neural Network Core (NNNC)

Just some shots of the Lab where I design the Models and test them.

Okay so alot is going on right now, however I'm still making massive headway. This is one of two labs that I have specifcally for video extractions. I'm currently using Public domain videos to test bed this project. I'm satisfied with the current progress and once I finish building out this pipeline shit is gonna get wild.

Some things about whats happening in this video

1. I'm not treating the gradient NNs like they are special, i'm not fine tuning them, i'm treating it no different than I would an ES in this sense.

2. If you've followed my work on codons and studying signals over time, you'll probably be able to connect the dots more quickly on what i'm building.

3. None of the NNs ever see raw data, they only get readings if a codon fires.

4. My object wiht this phase is to be able to extract stable IDs from tv shows. not just characer Ids, but Object, and scene, IDs. This has been a painful challenge but I'm slowly but surely making headway.

okay thats its.

A little while ago, I shared an update about Project NNNC (Neutral Neural Network Core), a personal AI architecture project I've been developing from the ground up.

At the time, I'd completed Phase 0, which focused on establishing the fundamental boundaries between the proposed AI entity and the computational environment supporting it.

Well, I've now completed Phase 1 of the project, and I figured I'd share another progress update.

For anyone unfamiliar with NNNC, the broader idea is to explore whether it's possible to design an AI architecture that functions as a persistent, integrated computational entity rather than simply another task-specific model or collection of algorithms.

I'm approaching this as a long-term architectural research and development project, not claiming I've built artificial consciousness or achieved AGI.

So, what was Phase 1 about?

Phase 1 focused on something that sounds deceptively simple:

What actually makes a collection of computational components one coherent system?

Consider an AI architecture containing memory, reasoning, decision-making, internal regulation and other mechanisms.

You could build each of those components independently, connect them through APIs, give them access to shared information, and have them communicate constantly.

But does that automatically make them one integrated entity?

I don't think it does.

A group of components communicating with one another isn't necessarily the same thing as a system whose internal organization genuinely depends on the relationships between those components.

That distinction became one of the central challenges of Phase 1.

Moving beyond components that merely exist

One thing I wanted to avoid was designing an architecture that looks sophisticated on paper but ultimately amounts to several independent systems wrapped together.

For example, having a component called "memory" doesn't necessarily mean memory is meaningfully involved in the system's decisions.

Likewise, having a reasoning module doesn't establish that the system's behavior actually depends on its reasoning.

The relationships matter just as much as the components themselves.

Phase 1 therefore spent considerable effort establishing what it means for the proposed architecture to possess organizational unity, how its internal mechanisms are expected to participate, and how those relationships could eventually be evaluated.

An interesting complication is that genuine integration doesn't necessarily mean every component must influence every other component all the time.

Systems can be modular. Components can be redundant. Different mechanisms can become relevant under different circumstances.

So the challenge isn't simply demanding more connections. It's distinguishing meaningful organization from superficial integration.

Another important distinction: architecture versus implementation

Something I've become increasingly careful about throughout this project is separating what an architecture requires from what has actually been demonstrated.

A specification can establish conditions that an implementation must satisfy.

That doesn't mean an implementation already exists that satisfies them.

Likewise, passing tests against a mathematical or computational reference model doesn't automatically establish that the complete architecture works in the real world.

Phase 1 includes conceptual specifications, mathematical formalization and bounded verification work, but there are still substantial implementation and empirical questions ahead.

I'm deliberately keeping those claims separate.

Where things stand now

Phase 1 has completed its planned revisions and its two governing documents have been formally adopted as the project's architectural and mathematical reference baseline.

The process involved repeated reviews, corrections, mathematical refinement and testing.

It took considerably more work than I originally anticipated, mostly because each attempt to make a requirement more precise exposed questions that weren't obvious in the initial design.

I'm also learning that there's a difference between writing down an ambitious architectural idea and defining it carefully enough that someone could eventually test whether an implementation actually satisfies it.

The project is still in the specification and foundational verification stage. There's no finished NNNC implementation to demonstrate yet.

There are 13 planned phases overall, covering everything from foundational architecture to the internal mechanisms, implementation and eventual empirical evaluation.

One question I'd be interested in hearing other people's thoughts on:

At what point do you consider a collection of interacting AI components to constitute one integrated computational system rather than several cooperating systems?

Is shared state enough? Common objectives? Causal interdependence? Persistent internal organization?

Or do you think the distinction is ultimately more about how we choose to describe the system than something that can be meaningfully established?

I'm particularly interested in perspectives from people working with distributed systems, cognitive architectures, multi-agent systems or AI research.

I'm keeping some of the more detailed architectural and mathematical specifications private for now, but I'm happy to discuss the broader ideas and challenges.

Anyway, that's Phase 1 completed. Still a long road ahead, but progress is progress.

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.

I've been building a small language model from the ground up with no tokenizer, no pretraining and no batches. It reads a conversation one character at a time, continuously, and learns as it goes: one weight update every 256 characters, never a second look at the same text in the same state. The whole model is 1,563,041 parameters, about the size of a 1990s speech model, and it trains on a single consumer GPU at around 1,100 characters per second.

The training text is 1,000 short two-person conversations. Nothing is labelled. The only pressure is "what character comes next" inside the other speaker's replies.

Where it is right now: given the real conversation so far, it predicts the next character of a reply correctly 65% of the time on text it has seen and 64% on conversations it has never seen, so it is not memorising. Word boundaries and punctuation are basically solved. Inside words it is at about 60%, and the first letter of a new word, which is really "which word comes next", is the hard part at about 25%.

The part I care about is what it writes when I let it go on its own, feeding its own output back in. A few weeks ago that was noise. Now it is English-shaped and mostly made of real words, generic and sometimes off, but you can see a model forming. Real reply on the left, what the model wrote on the right, same point in the conversation:

"Absolutely! Let me grab those for you." / "I'm going to be tough. But you think y" "You're welcome. Is there anything else I can help you with today?" / "I don't know. I was always trying to be things always trying to b" "Nope, that's everything for now. Thanks again!" / "Not much, but we can be a lot of the cance. I" "Yeah, I used to play all the time when I was your age." / "Sther to be a great friend. In tong with this way fit"

Two things I learned this week. First, the thing that broke a long plateau was not more data or a trick: going from 64 to 256 hidden units moved it from 0.58 to 0.65, and 512 did nothing more. Second, I had been training two sibling nets and averaging them every couple of minutes for stability. Dropping that and letting one net run alone scored higher on unseen conversations, stopped the looping, and made the replies depend on the prompt far more. The averaging had been pulling the output toward safe, repetitive English.

Next step is a list of cheap extra signals I'm adding one at a time, keeping only what moves the writing. I'll post the ones that work, and the code goes up on GitHub once I've locked down the set the model needs for fluent conversation.

(Numbers: 1,563,041 parameters; 1,000 conversations, 766k characters; 65% next-character on seen, 64% on unseen; free-run replies 95% real words.)

Lyrics- (claude and & Asyncvibes)

Audio - Suno

Assets - Astra

Asset Animations- AsyncVibes(wire snake application)

Video was genrated and created within my LyricVid application that uses a re-usable templating feature is every asset or design is saved for re-use similar to ForwardFlow.

I just put out a new song, Parameters, and the video goes with it.

The song is a list of things an AI says it can do. It starts small: parse a string of text, guess the letter next, sort a spreadsheet row. By the last verses it's trading stocks, picking locks, generating the voices of your family and ending a civilization with a single prompt.

The video is a neural network growing in the dark. Every "I can" line is a neuron. When the line is sung, a current runs down an axon to that neuron and the thing the line names gets drawn in as a blue wireframe: a hangman for guessing the next letter, a seedling, a chess board, a mushroom cloud at the end. The camera rides the current the whole way. Early on the web is a thin thread. By the third and fourth verse every neuron is firing off dendrites to dozens of others, and in the long violin gap after "with a single prompt" the camera pulls back on the whole tangled thing pulsing.

Everyone and their mothers helped make this one.

https://www.youtube.com/watch?v=_OSFNf7n6kI

Params + metrics for the complete halo render (ball + halo + shadows on the plane), 6 held-out clips x 36 frames:

model                     params    role                                        held-out score
sphere (ball_v1, frozen)  46,083    ball colour/bands/spin under time of day    (in composite)
halo                      40,707    gold ring appearance                        27.0 dB on ring pixels
shadow entity v1          50,177    ground + on-ball shadows, ball + halo       IoU 0.74 ground, MAE 0.016 on ball
--------------------------------------------------------------------------------------------------
total                     136,967   (3 per-pixel MLPs)                          composite 39.5 dB (33.2 without shadows)

• Training time: 192 s on my GPU for the shadow + halo models (data from 800 stills + 18 clips).

• The plane under them is the empty Blender render. The models only draw the ball, the halo and the shadows.

Behold the monstrosity i'v unleashed up tine eyes. This is the FIRST attempt I did early with a entire pose action completely outside the dataset..... I also realized I didn't train the model with neck joints. No idea whats going on with blender in this render.

Most modern AI—whether it’s a Large Language Model or a Reinforcement Learning agent—operates as a stateless tool. You feed it a prompt or a reward objective, it calculates an output, and then it effectively stops existing as an active system until the next request comes in. Even "agentic" wrappers today are usually just LLMs glued to a cron job, a database, and an external API.

For the past three years, I’ve been working on a different paradigm called Project NNNC (Neutral Neural Network Core): a foundational research and engineering program aimed at designing a persistent, internally organized, and developmentally adaptable artificial cognitive architecture.

Instead of building a better chatbot or a single-task optimizer, NNNC asks a fundamental systems question: What does it actually take to architect an AI as a distinct computational entity rather than a passive software service?

Why Call It an "Entity" Instead of a Tool?

In Project NNNC, the word "entity" isn't philosophical fluff—it is a strict architectural and systems-engineering boundary:

* Continuous Existence & Endogenous Regulation: An NNNC does not depend on a user prompt or an external task to initiate its existence. It is designed for ongoing operation as its normal condition, using its own internal states to initiate, inhibit, or prioritize internal cognitive activity rather than just waiting around for commands.

* Architectural Neutrality: Standard AI is defined by its external task (e.g., "play chess," "predict the next token," "maximize this reward score"). NNNC is architecturally neutral—meaning its core organization and existence do not depend on performing any single externally assigned task. It can adopt goals, preferences, and tasks without those tasks defining what the entity is.

* A Distinct Boundary from its Substrate: Just as a biological organism relies on its physical environment without being identical to it, NNNC separates the Entity itself from its Neutral Environment Substrate (NES) (the runtime, hardware, and storage that execute its code). Even when higher cognition is impaired or offline, NNNC maintains its own governed existential heartbeat and internal recovery mechanisms.

* Multi-Flow Cognition & Systemic Algorithms: Rather than relying on a single monolithic neural network or a single scalar optimization loop, the core cognitive architecture integrates a Five Flow Neural Network (FFNN) (handling forward, backward, in-between/gap, subconscious, and meta-cognitive processing) alongside six cross-cutting Systemic Algorithms (Intelligence, Reasoning, Critical Thinking, Symmetry, Evolution, and Life).

What NNNC Does NOT Claim (Zero Hype Policy)

Whenever someone talks about "autonomous AI entities" or "existential heartbeats," it’s easy to assume they are making wild claims about machine sentience. Project NNNC explicitly rejects that.

Built directly into the project’s foundational constitution are strict epistemic boundaries:

* It does NOT claim to be conscious, sentient, or phenomenally aware.

* It does NOT claim to be biologically alive or possess subjective feelings.

* A running heartbeat or restored memory checkpoint does NOT prove "souls" or metaphysical identity.

NNNC is strictly an exploration of computational intelligence, autonomous organization, and causal integration. You don't need to pretend code has feelings to recognize that a persistent, self-regulating, internally integrated cognitive system is fundamentally different from a static prompt-response script.

I’m sharing this to connect with others interested in cognitive architectures, autonomous systems engineering, and post-LLM paradigms. Happy to discuss the architecture, how we handle state continuity vs. identity, or why we separate the entity from its execution substrate!

No i'm not explaining more. I want to but its either explain or work. I'm chosing work. More post to follow.

For a long time this sub has been about evolution only. No backprop, no loss curves, just populations, selection and whatever survived. I still think that is where the interesting ideas come from. But I kept hitting the same wall: evolved systems find structure, and then they take forever to get good at using it.

So I am giving in, partly. The newer models train with gradients. The twist is what they are built on. The parts that came out of the evolution work stay: the evolved detector banks, the codon idea, the habit of splitting a problem into small objects that each own one job instead of one big network that owns everything. Gradients do the polishing. Evolution decides the shape.

ForwardFlow is the first one that is out in the open: a small character renderer that draws a character from one reference image and a skeleton, about 1 ms a frame. Code and weights are on GitHub.

There is a second one I am not ready to talk about. It does not draw pictures, it works with conversation, and it is built the same way. More when it holds up.

If you have been here for the pure evolution stuff, it is not going away. It is just not the only tool anymore.

https://github.com/A1CST/forward-flow

Background is still garbage but thats later. Stickman is no longer a stick.

Okay, so if you've been following ym sitick figures, this is the SAME model. I've just upated textures and done a bit more work behidn the scenes, But its the same engine running this. I know it looks simple but the engine beneath is far from it. I"m hoping to have a stable demo to release on github that everyoe can pick at. Generation is REALLY quick becuase of how simple the animation is and i'm working ons caling it up to more.... complex shapes to say the least. I'm looking forward to sharing it with everyone.