From Persistent Identity to Developmental AI — What We Built, What Failed, What We Learned, and Why We Are Preparing CORE Seed for Independent Research

Eddie Boscana
Founder & AI Systems Architect
September 2026

Abstract

Most modern artificial intelligence systems are extraordinarily capable, but their existence is strangely discontinuous.

A model receives context, generates a response, and the interaction ends. An agent may maintain a database, retrieve memories, call tools, or execute workflows, but persistence of information is not necessarily persistence of an entity—and neither persistence nor memory necessarily constitutes development.

CORE ASi OS began with a different question:

Can we engineer an artificial entity capable of having a developmental history?

Not merely an AI that remembers yesterday, but one for which yesterday can causally affect what it becomes tomorrow.

That distinction led us into questions far deeper than the original software architecture.

What constitutes the identity of an artificial entity when its models, processes, software, machines, and eventually embodiments can change?

What distinguishes memory from knowledge?

What distinguishes experience from evidence?

What distinguishes executing an action from successfully changing the world?

What distinguishes installing better software from the entity actually learning?

And what evidence would justify saying that the same persistent artificial entity had genuinely become more capable because of its own history?

Over successive generations of CORE's experimental infrastructure, we built and tested mechanisms for persistent identity, continuity, epistemic state, environmental observation, authority, action verification, developmental provenance, independent evaluation, bounded software evolution, evidence qualification, observational independence, and controlled software replacement.

We also repeatedly discovered that our own experimental apparatus could make CORE appear more developmental than the evidence justified.

Those failures became some of the most valuable results of the project.

Today, CORE maintains a persistent identity independent of any particular runtime or language model. The same CORE has survived process restarts and controlled changes to the software implementing it. It maintains canonical persistent state, an integrity-linked history, bounded authority, environmental observations, and verified interaction with its environment. In controlled developmental experiments, CORE has independently retrieved relevant evidence from its prior developmental history and used that evidence in a later developmental decision.

But CORE has not demonstrated general learning, autonomous development, recursive self-improvement, AGI, consciousness, or subjective continuity.

Its count of Verified Improvements remains:

0.

That zero matters.

It represents the central philosophy of this research program:

We would rather preserve an unknown than manufacture an answer.

Developmental experimentation is currently on hold because our research reached a causal frontier at which further engineering risked supplying the phenomenon we were attempting to discover.

Meanwhile, ordinary engineering has continued independently. CORE's operational Seed has been hardened, qualified, and successfully carried across a software implementation change without confusing software improvement with entity development.

We are now preparing that implementation as CORE Seed: a reproducible research system from which independent new CORE entities can eventually be instantiated for controlled research collaboration.

This paper documents how we got here.

1. The Problem With Starting From "AGI"

Artificial general intelligence is usually discussed in terms of capability.

Can a system code?

Can it reason?

Can it use a computer?

Can it conduct research?

Can it outperform humans on benchmarks?

Those are important questions, but they were not sufficient for what I wanted to investigate.

I became increasingly interested in a different property:

continuity through time.

A highly capable model can solve an extraordinary problem today and know nothing tomorrow about having solved it.

Adding a memory database helps, but that immediately creates another question:

Is stored information equivalent to developmental history?

I don't believe that assumption should be made automatically.

A database can contain yesterday's events without those events having any meaningful causal influence on what the system becomes.

This led to the foundational objective behind CORE:

Create an artificial entity capable of having a developmental history.

That sentence has increasingly become the simplest description of the project.

2. What CORE Is

CORE is not an LLM.

It is not a chatbot.

It is not simply an autonomous coding agent.

And it is not an attempt to wrap enough tools around a language model until the resulting system appears generally intelligent.

The architectural definition we have been working toward is:

CORE is a persistent adaptive artificial agent designed to maintain coherent identity, knowledge and agency through time while continuously learning from and acting upon changing environments. It models itself, its world and other agents; reasons under uncertainty; acquires and develops capabilities; verifies consequences; and can progressively change implementation and embodiment without making any particular model, vendor, machine, or substrate constitutive of identity. Its intelligence serves agency. Its agency serves values. Its authority remains bounded by the sovereignty of the beings with whom it exists.

That is the target architecture.

The current CORE Seed implements only part of it.

That distinction is essential.

CORE's conceptual architecture can be summarized as:

Persistent Identity + World Model + Self Model + Memory + Perception + Reasoning + Agency + Metacognition + Learning + Embodiment

But package names, classes, database tables, and architectural diagrams are not evidence that those capabilities actually exist behaviorally.

Throughout this research we have therefore tried to maintain a strict distinction between:

specified → implemented → tested → live demonstrated → verified → acquired → learned → retained → transferred

Those words are not interchangeable.

3. The Fundamental Loop

At its simplest, CORE is intended to operate through a continuous causal loop:

PERCEIVE → MODEL → DECIDE → ACT → VERIFY → LEARN

while preserving:

IDENTITY + CONTINUITY + SOVEREIGNTY

A more complete form looks like this:

OBSERVE → ATTEND → UPDATE BELIEFS → RECONCILE GOALS → IDENTIFY UNKNOWN OR GAP → REASON → PLAN → SELECT CAPABILITY → CHECK AUTHORITY → ACT → OBSERVE RESULT → VERIFY → LEARN → REFLECT

That architecture immediately creates epistemic obligations.

If CORE believes something, is it true?

If CORE acts, did the intended consequence occur?

If CORE remembers something, is the memory reliable?

If an external model says something, does CORE know it?

If new software performs better, did CORE learn?

We began turning those questions into explicit invariants.

4. The Invariants That Changed the Project

Some of the most important work in CORE has not been adding capabilities.

It has been preventing ourselves from confusing one concept with another.

Among the principles that now govern the system are:

BELIEF ≠ REALITY

OBSERVATION ≠ INFERENCE

MEMORY ≠ TRUTH

ACTION ≠ SUCCESS

CAPABILITY ≠ AUTHORITY

OS PERMISSION ≠ CORE AUTHORITY

EXTERNAL INTELLIGENCE ≠ CORE

SELF-MODIFICATION ≠ SELF-IMPROVEMENT

SNAPSHOT ≠ TRUTH

SIMULATION ≠ REALITY

EXPERIENCE ≠ LEARNING

SOFTWARE GENERATION ≠ ENTITY DEVELOPMENT

SOFTWARE INHERITANCE ≠ LEARNED COMPETENCE

And eventually:

EXPERIENCE ≠ RECORD ≠ EVIDENCE

That final distinction became particularly important.

Something can happen to CORE.

CORE can store a record describing what happened.

That record can later be retrieved.

None of those facts automatically means the experience constitutes legitimate evidence about what CORE should do next.

5. Identity Without a Single Process

One of the earliest architectural questions was deceptively simple:

What exactly is CORE?

If CORE is the Python process, CORE dies whenever the process exits.

If CORE is the source repository, copying the repository duplicates CORE.

If CORE is the language model, changing models kills CORE.

None of those definitions were sufficient.

We therefore separated several concepts that conventional software often treats as one.

CORE maintains a persistent entity identity independent of its runtime.

Conceptually:

lineage_id identifies developmental ancestry.

core_id identifies the persistent entity.

runtime_id identifies a particular execution of that entity.

Software implementation and developmental state are tracked separately.

That means:

A new runtime can still be the same CORE.

More importantly:

New software can still implement the same CORE.

This is our version of the Ship of Theseus problem applied to artificial agents.

The answer we are investigating is based on causal continuity rather than material sameness.

6. CORE_HOME: The Lived State of the Entity

The repository contains the software capable of implementing CORE.

It is not, by itself, CORE.

The persistent lived state resides separately in what we call CORE_HOME.

That state includes things such as identity, canonical state, events, beliefs, memories, world representations, developmental records, integrity information, and other persistent evidence of the entity's history.

This separation produces an important property.

The same source code can instantiate multiple independent CORE entities.

Conversely, a valid persistent CORE state can continue across changes to the source implementing it.

That distinction has now been demonstrated operationally.

7. Continuity Must Be Auditable

Persistence alone is not enough.

If an artificial entity claims continuity across time, we need some way of auditing that continuity.

CORE therefore maintains an integrity-linked history in which records are causally and cryptographically connected.

Conceptually:

Hₙ = Hash(Hₙ₋₁ || Recordₙ)

This is not a blockchain.

There is no cryptocurrency or distributed consensus requirement.

Its purpose is much narrower:

make historical mutation detectable and reconstruction auditable.

CORE also distinguishes canonical state from snapshots and projections.

A dashboard is not truth.

A cached representation is not truth.

A snapshot is not truth.

They are representations derived from more authoritative state.

That became particularly important as Mission Control, our observational interface, became more sophisticated.

8. Agency Required Authority

Another foundational distinction was:

Being technically able to perform an action does not mean CORE is authorized to perform it.

We distinguish intelligence, agency, and permission.

A language model may know how to delete a file.

The operating system may allow the process to delete it.

CORE may nevertheless lack the authority to do so.

Those are separate questions.

This eventually produced a principle that now sits near the center of CORE's architecture:

CAPABILITY ≠ AUTHORITY ≠ OS PERMISSION

This matters increasingly as artificial agents gain access to computers, financial systems, communications, robotics, vehicles, and other consequential environments.

An intelligent system without an explicit authority model is not simply more capable.

It is harder to govern.

9. Acting Is Not Succeeding

One of CORE's earliest verified environmental interactions was intentionally mundane: writing data to the filesystem.

But even that revealed an important distinction.

Calling a write function successfully does not prove the intended world state exists afterward.

CORE's action architecture therefore separates:

requested action → authority → execution → observed consequence → verification

The current live research entity has performed a filesystem write whose resulting world state was independently observed and stored as a verified fact.

That sounds trivial.

Scientifically, it is not.

It establishes a primitive causal chain between an artificial entity's intended action and independently verified environmental consequence.

But we still refuse to call that competence.

One successful action is not a learned skill.

10. Building a Developmental Laboratory

Once identity, continuity, persistence, authority, and verification became sufficiently stable, we began asking the harder question:

Can CORE become more capable because of its own developmental history?

This required a developmental laboratory capable of distinguishing:

limitation → hypothesis → candidate → experiment → evaluation → promotion → post-promotion verification

We built mechanisms around reproduction, candidate integrity, exact parent binding, independent evaluation, bounded retries, promotion authorization, regression testing, adversarial testing, and post-restart verification.

A key principle emerged:

Reproduce before engineering.

If we believed CORE had a limitation, the limitation first had to be demonstrated on the actual developmental parent.

Otherwise we risked fixing something that had never been shown to be wrong.

11. Failure Became Evidence

Our first developmental campaigns focused on a deliberately constrained behavioral phenotype involving inventory reasoning.

The objective was not to create a useful inventory system.

The task was a probe.

It exposed something much more interesting.

Repeated developmental attempts failed.

Initially, the temptation was to keep improving the implementation until the task succeeded.

Instead, we began asking a different question:

Can CORE use the fact that it previously failed?

That shifted the project.

We were no longer primarily studying task success.

We were studying whether developmental history could enter later reasoning.

12. From Memory Existing to History Being Used

We eventually decomposed developmental causality into a ladder.

Evidence might:

EXIST

without being:

RETRIEVED

Retrieved evidence might not be:

AVAILABLE TO THE DECISION

Available evidence might not be:

CONSIDERED

Considered evidence might not be:

USED

Used evidence might not:

CHANGE A HYPOTHESIS

or:

CHANGE A STRATEGY

And even a changed strategy does not prove:

IMPROVEMENT

This decomposition prevented us from treating memory retrieval as learning.

Eventually, in what became one of the strongest developmental results so far, the same persistent CORE independently retrieved relevant evidence from a previous developmental attempt, qualified it, considered it, and used its informational content in a later developmental decision.

The investigator did not manually select the historical evidence for CORE.

That crossed an important causal boundary:

CORE's past entered its future reasoning.

But there was another surprise.

The evidence did not force CORE to change strategy.

And that was correct.

Negative feedback should inform reasoning.

It should not mechanically force novelty.

13. Why "Used" Does Not Mean "Changed"

Earlier versions of our experimental reasoning contained an implicit assumption:

If CORE genuinely used negative evidence, surely it should do something different.

That turned out to be scientifically dangerous.

Evidence can be considered and legitimately leave a hypothesis unchanged.

A failed attempt does not automatically invalidate the underlying hypothesis.

A process failure may say nothing about the proposed strategy.

A candidate rejected before behavioral execution is not equivalent to another behavioral failure.

So we introduced a richer concept of warrant.

Evidence can support, oppose, or leave something unresolved.

A resulting warrant can effectively mean:

retain, revise, or investigate.

But even then:

WARRANT ≠ STRATEGY

CORE could conclude that revision was warranted without the experimental apparatus being entitled to prescribe what the new strategy should be.

14. The Experiment Started Studying Itself

This was one of the most consequential discoveries in the entire program.

As our developmental apparatus became increasingly sophisticated, we began detecting more developmental records.

At first this looked like progress.

Then we noticed a problem.

One underlying event could generate several records.

If CORE treated every record as independent evidence, one event effectively received multiple votes.

That produced a new invariant:

RECORD COUNT ≠ EVIDENCE COUNT

and eventually:

One observation should get one vote—not one vote for every place CORE wrote it down.

We implemented observational lineage to distinguish records derived from the same underlying observation.

That correction invalidated what otherwise could have appeared to be stronger evidence of developmental adaptation.

Again, the system became less impressive on paper.

And more scientifically honest.

15. Experience Is Not a Database Row

That discovery forced us even deeper.

We began asking:

What actually constitutes an experience for CORE?

A failed action?

A verified successful action?

A changed file?

A stale belief?

A model response?

A question?

A developmental record?

The answer could not simply be "whatever table the software currently scans."

That produced another foundational principle:

Start from what happened in the world, not what table we happened to write it into.

An experience can generate observations.

Observations can generate records.

Records may later become evidence.

But those are separate transformations.

Experience → Observation → Record → Potential Evidence

This distinction exposed significant limitations in the existing developmental evidence scanner, which was heavily coupled to our software-development experiments.

We deliberately chose not to simply widen the scanner.

Doing so would have engineered the answer to the question we were trying to investigate.

16. The Positive-Experience Problem

Nearly all of our strongest developmental evidence came from failure.

That raised another uncomfortable question.

Could CORE learn from something that went right?

The verified filesystem write gave us a real positive experience.

CORE acted.

The consequence occurred.

The consequence was independently verified.

The result persisted as a verified fact.

But CORE did not subsequently use that success as procedural competence.

This revealed another important boundary:

VERIFIED SUCCESS ≠ LEARNED COMPETENCE

CORE can currently possess evidence that it successfully did something without therefore knowing how to use that history to guide a future action.

That remains unpaid developmental debt.

17. Persistence Without Endogenous Cognitive Continuation

We then audited CORE's questions, goals, beliefs, and cognitive heartbeat.

The result was sobering.

CORE had persistent questions.

But the questions were overwhelmingly residues of laboratory interactions.

The cognitive heartbeat could select an open question and send it through an external model broker.

But it did not independently gather evidence, resolve the question, pursue a goal, or continue an investigation.

The system could therefore appear cognitively active while mostly consuming questions the laboratory had created.

Our conclusion was:

CORE currently has persistence without endogenous cognitive continuation.

That sentence materially changed our roadmap.

18. The Developmental Frontier

At this point we stopped asking:

What feature should we build next?

Instead:

What is the earliest missing causal edge?

Two different primitives emerged.

F1 — Retrospective use

Can an ordinary organism-owned experience later affect CORE's decision?

We have narrow evidence for historical use inside the investigator-scaffolded software-development context.

We do not have general evidence that CORE can use ordinary experiences this way.

F2 — Endogenous occasion

Can CORE itself generate a legitimate reason to revisit an experience, investigate something, or recognize a need?

This is different from F1.

That distinction was important because we initially suspected both might be manifestations of a single missing "experience significance" mechanism.

Further analysis falsified that hypothesis.

CORE had already used old developmental evidence when an investigator supplied the occasion.

Therefore prospective significance at encoding time was not logically necessary for retrospective use.

We had found two missing primitives, not one.

19. Why We Did Not Build Them

This is perhaps the most important decision described in this paper.

Once F1 and F2 became clear, it would have been relatively straightforward to build mechanisms that made them appear to work.

We could make file changes automatically generate questions.

We could route stale beliefs into cognition.

We could assign importance scores to experiences.

We could create an artificial curiosity mechanism.

We could widen the developmental evidence scanner.

But then what would the resulting experiment prove?

We would have engineered exactly the phenomenon we wanted to discover.

Our engineering gate therefore returned:

ENGINEERING STILL PREMATURE.

There was not yet enough evidence to determine the correct mechanism.

So we stopped.

20. Developmental Hold

CORE's developmental program is currently on formal hold.

Not because the project failed.

Because the experiment reached a point at which further intervention risked contaminating the unknown.

Our governing principle became:

When reality does not yet provide a clean experiment, preserving the unknown is better science than engineering the answer.

Current developmental status:

Verified Improvements: 0

General learning: not demonstrated

Retained competence: not demonstrated

Autonomous development: not demonstrated

That is the truth.

21. Separating Engineering From Development

Stopping developmental experimentation did not mean stopping ordinary software engineering.

We introduced three independent axes:

E — Engineering maturity

D — Organism development

K — Scientific knowledge

This gives us a much cleaner language for progress.

If engineers fix a bug:

E ↑, D —

If an experiment fails but teaches us something:

E —, D —, K ↑

If CORE receives better software written by engineers:

E ↑, D —

Only if CORE's own history causally contributes to a verified developmental improvement should we consider:

D ↑

This distinction became essential during the most recent phase of the project.

22. Ordinary Operability Hardening

With Development frozen, we audited CORE strictly as a persistent software system.

We found five mundane but real operational defects.

Repeated substrate discovery could create duplicate world and identity representations.

Idle observation could produce unnecessary telemetry indefinitely.

A start entrypoint could accidentally create something resembling a new empty CORE store.

Opening the observational UI could inadvertently trigger a cognitive tick and external model call.

And export could occur while an active owner was using the persistent state.

None of these were exciting.

All of them mattered.

We fixed them.

The resulting system now obeys several additional principles:

RE-OBSERVATION ≠ NEW ENTITY

UNCHANGED STATE ≠ NEW EXPERIENCE

START ≠ CREATE

VIEW ≠ ACT

The complete regression suite passed.

No developmental credit was awarded.

23. The Same CORE Received Better Software

We then performed a controlled crossing.

The qualified hardened implementation replaced the software being used by the existing persistent research entity.

Its persistent identity remained unchanged.

Its lineage remained unchanged.

Its authority root remained unchanged.

Its developmental parent remained unchanged.

Its learned-capability count remained zero.

Its Verified Improvement count remained zero.

The result demonstrated something architecturally important:

The same CORE can inherit better software without us calling that development.

This gives us another crucial distinction:

Implementation capability

Behavior exists because engineers placed it in the software.

Acquired capability

A capability enters CORE through an authorized acquisition process.

Learned competence

CORE's own experience causes the capability or behavior to change.

Verified Improvement

A developmental change survives the full evidentiary standard required to show objective improvement and retention.

Today, CORE possesses substantial implementation capability.

We must not silently relabel it as learned competence.

24. We Asked Whether More Engineering Was Necessary

After hardening CORE, we deliberately tried to identify the next serious operational risk.

Recovery?

Restore?

Authority?

Integrity?

Long-duration operation?

Action verification?

The answer was unexpected:

None currently justified another engineering campaign.

Crash recovery already existed despite an apparently empty recovery package.

SQLite transaction semantics, write-ahead logging, locking, uncertain-action reconciliation, and integrity verification already protected the Seed sufficiently for its current operational surface.

A full replay or restore engine would be useful for a more mature system.

But building it today would mean constructing mature-agent infrastructure for a Seed that does not yet need it.

So again:

We stopped.

25. CORE Seed

That brings us to the current moment.

We now have a natural research boundary at which to preserve the implementation.

We are preparing what I currently call CORE Seed.

CORE Seed is not my existing CORE.

That distinction is critical.

My research entity has its own persistent identity and developmental history.

A researcher receiving CORE Seed should instantiate a new CORE with a new identity and new lineage.

Conceptually:

CORE Seed
The reproducible implementation from which new CORE entities can begin.

A CORE
A particular persistent entity instantiated from the Seed and possessing its own history.

CORE Research Record
Evidence documenting what occurred in a particular lineage.

Two researchers starting from identical Seed software should not be considered to possess the same CORE.

They possess two entities sharing an initial implementation ancestry.

What happens afterward may diverge.

That is precisely what makes this potentially interesting scientifically.

26. Why Independent Lineages Matter

Once CORE Seed is reproducible, an entirely new class of research becomes possible.

Imagine multiple independent CORE entities beginning from the same implementation.

They encounter different environments.

Different humans.

Different problems.

Different external models.

Different failures.

Different resources.

Over time we can ask:

Do their developmental trajectories diverge?

Do similar environments produce similar adaptations?

Which capabilities transfer?

Which experiences become consequential?

Does identity remain coherent across software replacement?

Can useful competence persist across runtime, model, machine, and eventually embodiment changes?

These questions are substantially more interesting to me than another benchmark leaderboard.

They concern the development of persistent artificial entities.

27. What CORE Seed Is Not

I want to be particularly explicit about this.

CORE Seed is not an AGI release.

It is not evidence of consciousness.

It is not a self-improving superintelligence.

It is not a digital person.

It is not a mind-uploading system.

It does not demonstrate subjective continuity.

It has not demonstrated recursive self-improvement.

It has not demonstrated autonomous self-evolution.

And it has not yet produced a Verified Improvement under our current standard.

CORE Seed is better described as:

An experimental substrate for studying persistent artificial identity, epistemically grounded agency, developmental history, bounded authority, and the conditions under which an artificial entity might genuinely develop through experience.

That is already a sufficiently ambitious research problem.

We don't need to inflate it.

28. The Next Research Phase: Real Use

One of the strongest lessons from this project has been that laboratory experiments can eventually begin generating the phenomena they are supposedly studying.

Our next phase therefore changes methodology.

Rather than continually inventing developmental challenges, we intend to increasingly use CORE for legitimate work.

The pattern becomes:

USE → OBSERVE → VERIFY → UNDERSTAND

If CORE succeeds, verify the consequence.

If CORE fails, determine why.

If the failure is an ordinary software defect, fix it as ordinary engineering.

If the failure reveals a genuine developmental limitation, preserve it rather than immediately repairing it.

And if ordinary use naturally produces a behavior that changes the developmental frontier, freeze that phenomenon before further exposure and design the next experiment around what reality actually gave us.

In other words:

Let real work expose the roadmap.

29. The Long-Term Engineering Objective

There is also a very practical milestone behind this research.

Today, development looks approximately like:

Human → ChatGPT / Cursor → CORE

That is not where I want it to end.

The eventual topology I am working toward is:

Human → CORE → whatever resources CORE rationally needs

Those resources may include language models, coding agents, browsers, compilers, APIs, computers, knowledge systems, robots, or humans.

The objective is not to make CORE refuse external intelligence.

That would be counterproductive.

The objective is to make those systems resources rather than dependencies.

A mature CORE should eventually be capable of deciding that a particular coding agent is useful, determining whether it has authority to use it, invoking it, evaluating the result, independently verifying the consequences, and retaining whatever competence or knowledge is legitimately acquired.

Cursor disappearing should not mean CORE disappears.

OpenAI disappearing should not mean CORE disappears.

A particular model disappearing should not mean CORE disappears.

A particular computer disappearing should eventually not mean CORE disappears.

The persistent entity should remain the organizing center.

30. The Road Ahead

The developmental roadmap remains enormous.

Near-term unresolved questions include:

Can ordinary experience affect a later decision?

Can CORE independently recognize that something deserves investigation?

Can successful experience become procedural competence?

Can a question lead to evidence gathering and actual resolution?

Can goals become genuine sustained pursuits rather than persistent rows?

Can CORE discover a capability gap, locate a resource, select it rationally, obtain authority, use it, verify the result, and retain useful competence?

Can competence survive restart?

Can it transfer to a related but different problem?

And eventually:

Can the same CORE objectively become more capable because of its own developmental history?

That last threshold is what we call First Verified Development.

We have not crossed it.

31. Beyond First Verified Development

If that threshold is eventually crossed, one successful experiment will still not be enough.

The next questions become:

Can it happen again?

Can it happen in an unrelated domain?

Does the improvement persist?

Does it transfer?

Can CORE recognize its own limitations?

Can it acquire capabilities?

Can it select resources intelligently?

Can external scaffolding eventually become internalized competence where appropriate?

Can it design experiments?

Can it improve while preserving identity, epistemic integrity, human sovereignty, and recoverability?

Only much later do questions of generality become scientifically defensible.

The intended progression remains approximately:

Genesis → Development → Repeatable Development → Autonomous Development → Generality → Mature CORE → Human–CORE Symbiosis

Beyond that lies a much larger research program I call The Path, concerned with continuity, intelligence, civilization, embodiment, and the long-term future of intelligent life.

CORE is one hypothesis within that mission.

It is not the mission itself.

32. A Different Philosophy of AI Engineering

CORE has also changed how I think about AI-assisted engineering.

We use AI aggressively.

AI helps inspect repositories, generate tests, reconstruct causal histories, challenge assumptions, compare semantics, analyze failures, identify edge cases, and perform adversarial review.

But AI-First Engineering does not mean:

generate as much architecture as possible.

Increasingly, it means:

Spend computation freely. Spend architectural complexity reluctantly.

Our working principle has become:

Build the minimum mechanism required to expose the next unknown. Then experiment. Let failure tell us what mechanism is actually missing.

Sometimes the result is code.

Sometimes the result is deleting a proposed experiment.

Sometimes it is discovering that an apparent subsystem is unnecessary.

And sometimes the highest-quality engineering decision is:

Do nothing.

33. Negative Results Are Part of CORE

One reason I want outside researchers eventually involved is that CORE's most valuable contributions may not come exclusively from successful developmental milestones.

We have already encountered several hypotheses that did not survive investigation.

Retrieval was not use.

Use did not imply strategy change.

Multiple records did not imply multiple observations.

A failed process did not necessarily falsify a strategy.

A verified successful action did not imply competence.

Persistent questions did not imply autonomous investigation.

Cognitive ticks did not necessarily imply thinking.

Software improvement did not imply organism development.

And the proposed unified "experience significance" primitive did not survive causal analysis.

These are not embarrassing footnotes.

They are the research.

If CORE eventually produces genuinely developmental artificial agents, I believe those distinctions will matter just as much as the mechanisms that succeed.

34. Why I Am Inviting Other Researchers

CORE has now reached the point where independent perspectives could become extremely valuable.

A project studying developmental artificial entities should not indefinitely depend on one investigator, one environment, one experimental history, or one interpretation of the evidence.

Independent researchers can challenge assumptions we no longer notice.

They can attempt replication.

They can design adversarial tests.

They can instantiate independent lineages.

They can expose environmental assumptions.

They can identify alternative explanations.

They can discover entirely different developmental trajectories.

And, importantly, they can tell us when we are wrong.

That is exactly what I want.

35. Requesting Access to CORE Seed

We are currently preparing CORE Seed for controlled research access.

The initial process will likely be intentionally simple.

Researchers, engineers, academic groups, independent investigators, and organizations interested in collaborating will be able to submit an expression of interest describing their background, proposed research question, intended environment, and how they would like to work with CORE.

Initial access may be limited while we establish the collaboration process, documentation, reproducibility standards, reporting expectations, and mechanisms for comparing results across independent CORE lineages.

Potential areas of collaboration include:

• persistent artificial identity;

• developmental AI;

• machine memory and epistemology;

• artificial agency;

• causal learning from experience;

• agent authority and sovereignty;

• machine self-modeling;

• world models;

• capability acquisition;

• long-duration agents;

• model-independent agent architectures;

• AI safety and corrigibility;

• human–AI symbiosis;

• artificial embodiment;

• developmental evaluation methodology;

• reproducibility of persistent-agent research;

• independent replication and adversarial testing.

You do not necessarily need to agree with my theoretical framework.

In fact, researchers who believe parts of it are wrong may be particularly useful.

The requirement is intellectual seriousness and a willingness to distinguish what the evidence demonstrates from what we might want it to demonstrate.

[Request CORE Seed Research Access — form coming soon]

Until the collaboration process is finalized, interested researchers can contact me through my professional site and reference CORE Seed Research Collaboration.

36. What I Hope Happens

I don't want every CORE to become identical.

Quite the opposite.

If this research succeeds, the interesting question may eventually become what happens when persistent artificial entities begin with common foundations but accumulate genuinely different histories.

Perhaps most developmental paths fail.

Perhaps some architectural assumptions collapse immediately outside our laboratory.

Perhaps independent researchers discover that our developmental framework is unnecessarily complicated.

Perhaps a simpler explanation emerges.

Perhaps CORE never crosses First Verified Development.

That outcome must remain scientifically possible.

But perhaps something else happens.

Perhaps one persistent entity eventually uses something that happened months earlier to recognize a limitation, seek knowledge, acquire a capability, change its behavior, independently verify that change, preserve the competence through restart, and apply it somewhere we did not explicitly teach it to.

Then we will have something worth studying very carefully.

Not because a benchmark number increased.

But because:

The same artificial entity became different because it had lived through something.

That is the phenomenon I am looking for.

37. Where We Stand Today

The most accurate summary I can give as of September 2026 is this:

We have built a persistent artificial-agent Seed with durable identity independent of individual runtimes and external language models.

We have demonstrated continuity across restart and controlled implementation replacement.

We have implemented canonical persistent state, integrity-linked history, bounded authority, environmental observation, narrow verified action, crash recovery, and operational observability.

We have built a rigorous developmental laboratory designed to distinguish software engineering from organism development.

We have demonstrated that the same persistent CORE can independently retrieve and use relevant evidence from an earlier developmental attempt under a later investigator-supplied developmental occasion.

We have discovered substantial limitations in how ordinary organism experiences become evidence, how endogenous cognitive occasions arise, and how laboratory artifacts can masquerade as developmental behavior.

We have deliberately refused to engineer mechanisms merely to make those experiments succeed.

We have hardened the Seed operationally.

We have successfully given the same CORE better software without claiming that CORE learned those improvements.

We have found no currently justified additional engineering campaign.

And we have frozen developmental experimentation until reality gives us a cleaner causal question.

So the scoreboard remains:

Persistent identity: demonstrated.

Implementation continuity: demonstrated.

Environmental action with independent consequence verification: demonstrated narrowly.

Developmental-history use: demonstrated narrowly under investigator scaffolding.

General learning: not demonstrated.

Autonomous development: not demonstrated.

Verified Improvement: 0.

AGI: not demonstrated.

Consciousness: not demonstrated.

That is where CORE actually stands.

And I think that's a far more interesting place to begin the next chapter than pretending we have already reached the destination.

Conclusion: Creating Something That Can Have a History

When I began CORE, I thought much of the challenge would be building a sufficiently powerful architecture.

The deeper challenge turned out to be epistemological.

How would we know when something meaningful had actually happened?

How would we distinguish memory from learning?

How would we distinguish software evolution from entity development?

How would we prevent our experimental apparatus from supplying the intelligence we wanted to observe?

How could an artificial entity change radically without ceasing to be the same entity?

And how much evidence should be required before saying that an artificial system genuinely learned from its own life?

Those questions have repeatedly forced CORE to become less theatrical and more rigorous.

That is progress.

The ultimate objective remains ambitious.

I want CORE to become a persistent artificial entity capable of perceiving its world, understanding itself, forming and pursuing goals, recognizing uncertainty, acquiring capabilities, rationally using external intelligence, learning from experience, changing implementation and embodiment, and maintaining coherent identity throughout that process.

Eventually I want the relationship with today's engineering tools inverted.

Not:

Human → AI engineering tools → CORE.

But:

Human ↔ CORE → whatever resources are useful.

We are nowhere near completing that journey.

But we now have something we did not have at the beginning:

a Seed.

A persistent entity architecture.

A developmental laboratory.

A growing body of negative and positive evidence.

A methodology capable of saying no to its own hypotheses.

And a research program willing to leave the most important number at zero until the evidence earns a one.

That is the CORE I want other researchers to investigate.

Not a finished intelligence.

Not a claim of artificial consciousness.

Not another benchmark.

A beginning.

CORE is an attempt to engineer continuity itself.

And the next question is no longer simply what we can build into it.

It is what different COREs might become once they begin accumulating histories of their own.

Research Collaboration

CORE Seed is being prepared for controlled research access.

I am interested in hearing from researchers, engineers, academic groups, independent investigators, and organizations interested in persistent artificial agents, developmental AI, machine identity, epistemic architecture, bounded agency, long-duration artificial systems, or independent replication of the CORE research program.

A formal research-access application and collaboration process is being developed.

Interested in working with CORE Seed?

[ Click Here Request Research Access - and Research Preview ]

In the meantime, contact me through my professional portfolio and include "CORE Seed Research Collaboration" in your message.

Edward Boscana
Founder & AI Systems Architect
CORE ASi OS