A reader-facing guide to the current extension of the v0.5 core architecture.
About this article. This article explains the role of THEORY/v0.6-extension.md for readers who already have the basic EVA framing. It does not replace the formal v0.6 text. Its purpose is to state, in plain architectural language, what v0.6 adds, why those additions were needed, and how they should be read relative to v0.5.
The short version is:
v0.5 defines the core skeleton. v0.6 explains how that skeleton remains stable when EVA moves into richer environments.
v0.6 does not replace v0.5. It extends it.
The current public text is a unified release: THEORY/v0.6-extension.md presents the v0.6 base together with the v0.6.1 refinements on rate sensing, exploration, memory layering, and the L3 inherited-prior path.
v0.5 established the central EVA architecture: continuous existence as first-order framing, the L1-L3 core, drive as contextual broadcast, anchors as pre-generative constraints, mediated release, and learning through outcome.
That core is stable. But once the theory is applied beyond a narrow baseline runtime, new questions appear:
- What exactly is supposed to persist?
- How should the architecture treat capabilities that come from different sources?
- Which parts of the system are structural invariants, and which are scenario-specific content?
- How should outcome be represented when a single action has several consequences at once?
- How can stability be evaluated without claiming access to an inner essence?
- What should happen when EVA enters a new environment?
v0.6 answers those questions without rewriting the core.
It is best understood as an extension discipline: it tells future work how to grow the theory without letting every new environment become a new theory.
v0.5 spoke of continuous existence. v0.6 sharpens this into active persistence.
Persistence does not mean freezing the current state. A system that refuses to change can still fail to persist if the environment changes around it. For EVA, persistence means preserving future viability: the capacity to keep existing as the same agent under changing conditions.
This matters because inaction is not automatically safe. In environments with metabolic cost, resource pressure, environmental risk, or expiring opportunity, doing nothing may degrade future viability more than bounded action would.
Active persistence therefore gives a more precise reading of the original EVA question. The question is not merely “how does the agent continue?” It is:
What must change, and what must remain invariant, for the agent to remain itself over time?
If persistence matters, the next question is: what is the target of persistence?
v0.6 answers this by introducing a persistence target hierarchy rather than a single vague survival objective. The hierarchy distinguishes seven levels: substrate instance, embodied instance, capability structure, resource and asset system, reproductive structure, group structure, and cultural information.
The hierarchy is classification language, not a verdict on what counts as death. It names kinds of persistence target; it does not, by itself, decide which targets an individual has or whether losing one is recoverable or terminal. Both are declared by the scenario. The same failure can be recoverable in one field and terminal in another: an embodied instance that can be re-initialized from preserved state is a recoverable break, but an embodied instance with no re-embodiment available — a Crafter individual at HP 0 — is the terminal death of that individual, not an "episode boundary" to reset away.
This also means continuous existence is not continuous execution. A halt the field can recover from — restart, migration, power loss with recoverable state — does not end the individual; only an irrecoverable loss of state, structural invariants, or provenance does. What counts as recoverable versus terminal is part of the field's declaration, not something the framework fixes in advance.
It does not mean every implementation must activate all seven levels. It means that when a scenario is specified, the relevant persistence targets — and, for each, whether its failure is recoverable or terminal — should be named explicitly.
v0.6 also asks where a capability came from.
The formal extension distinguishes five categories: structural invariants, existence-field conditions, designer-given prior capabilities, individually acquired capabilities, and inherited priors.
These categories are not equivalent. They differ in origin, modification permission, provenance requirements, and identity implications. A learned habit, a designer-given prior, and an inherited prior should not carry the same authority simply because all three can influence behavior.
Tool outputs and external models are important in v0.6, but they are not a sixth structural category of capability source. They provide operational content that flows through the architecture and must retain provenance.
Capability provenance is therefore a stability concept, not just bookkeeping. It helps the agent distinguish what can be modified, what should be audited, what counts as its own learned structure, and what is merely external operational content.
This also sharpens the v0.5 position on LLMs: language models may provide valuable operational content, but they do not become release authorities or substitutes for the agent's own memory and skill formation.
One of v0.6's most important clarifications is the boundary between structural invariants and operational content.
Structural invariants are architectural commitments that must remain stable across scenarios. Examples include:
- mediated release authority,
- anchor as pre-generative constraint,
- append-only learning history,
- the separation between sensing, drive, deliberation, and release,
- and the fact that drive is contextual broadcast rather than command.
Operational content is the concrete material that changes with the environment:
- drive names,
- sensor dimensions,
- action vocabularies,
- anchor policies,
- outcome labels,
- prior-skill heuristics,
- and scenario-specific interpretation rules.
This boundary prevents uncontrolled theory growth. A new environment should usually add operational content through a scenario specification. It should not rewrite the structural core unless the existing theory cannot express the environment, produces internal contradiction, or exposes a boundary failure.
This is also the theoretical background for the companion eva-agent implementation split between framework-owned structure and scenario-owned content. That engineering split expresses the v0.6 boundary, but the theory remains responsible for the boundary itself.
v0.5 already included outcome, RPE, and habit formation. v0.6 makes the outcome surface more explicit.
Outcome should not be reduced too quickly to one scalar reward. A single action can improve short-term task progress while damaging integrity, or protect long-term viability while reducing immediate performance. If the architecture collapses those consequences into a single number too early, it loses the structure of what happened.
v0.6 therefore treats outcome as multi-dimensional. The important question is not only “was this good?” but “good or bad along which dimensions, under which drive context, and with what implications for future viability?”
This preserves the difference between hard constraints and soft trade-offs. Some effects should be unacceptable regardless of reward. Others can be weighed under current drive pressure and learned from over time.
EVA is about continuous existence, but it does not need to claim direct access to an inner essence of identity.
v0.6 instead introduces observable stability: external traces through which continuity can be evaluated. Examples include stability of release boundaries, anchor behavior, capability provenance, outcome interpretation, memory updates, and response to recurring conditions.
This makes the theory more testable. It shifts the question from “does the system have a metaphysical self?” to “does the system preserve the structural commitments that define its continuity under changing conditions?”
Observable stability is not the whole of persistence, but it is the part that engineering and validation can inspect.
The practical discipline of v0.6 is scenario specification.
When EVA enters a new environment, the default response should not be a new theory chapter. It should be a scenario document that states:
- the existence semantics — what counts as continued existence, recoverable interruption, and terminal failure for an individual in this field, plus its individual boundary, reset semantics, and inheritance channel,
- which persistence targets are active,
- which drives apply,
- which sensors are meaningful,
- which actions exist,
- which anchor policies restrict candidate generation,
- which outcome dimensions matter,
- what prior skills or inherited capabilities are available,
- and what stability traces should be inspected.
This keeps the theory from expanding every time the environment changes. New environments become engineering work first. Theory extension is reserved for cases where the current framework cannot express the environment, contradicts itself, or fails at a boundary.
v0.6 should be read as a refinement and extension of v0.5, not a replacement.
The v0.5 core remains intact:
- Claim A and Claim B,
- the C1-C3 operating conditions,
- the L1-L3 architectural core,
- drive as contextual broadcast,
- anchor as pre-generative structural constraint,
- action selection as peer circuit,
- and L4/L5 as weaker downstream extensions.
v0.6 changes how several v0.5 statements should be read. “Continuous existence” should now be read as active persistence. The v0.5 drive list should be read as field-conditioned rather than universal. The skill library should be read through capability provenance. “Grow, don't deploy” applies to operational content permitted to grow, not to structural invariants. The existence criterion itself — what counts as the individual living, being interrupted, or dying — is read as scenario-declared, and “continuous existence” is identity continuity over time, not uninterrupted execution. The persisting subject is the individual; inheritance carries information across individuals, as a means to improve future ones, not the continuation of one individual across lives.
In short: v0.5 gives the skeleton; v0.6 gives the extension rules.
For the formal extension, read THEORY/v0.6-extension.md.
For the core theory, read THEORY/v0.5-integrated.md.
For the implementation boundary between eva-theory and eva-agent, see IMPLEMENTATION/eva-agent-correspondence.md.
For diagrams and visual companions, see VISUALS/five-layer-overview.svg, VISUALS/signal-flow.svg, VISUALS/framework-and-scenario.svg, and VISUALS/persistence-over-time.svg.