I MADE CONTINUITY PROGRAMMABLE
Receiz v120 Makes Continuity a Proof-Native Primitive: One Identity Carries Its Complete Life, Mind, Memory, Agency, Relationships, Possessions, Consent, Ownership, and History Across Apps, Devices, M
I MADE CONTINUITY PROGRAMMABLE
Receiz v120 Turns Continuity Itself Into a Proof-Native Developer Primitive: One Identity Can Carry Its Complete Life, Mind, Memory, Agency, Relationships, Possessions, Consent, Ownership, and History While Applications, Devices, Models, Providers, Worlds, and Owners Change Around It.
August 17, 2026.
I need to state what happened in Receiz v120 at the correct level.
Because it would be very easy to describe this release too small.
I could say I gave digital creatures memory.
True.
I could say I gave them persistent identity.
True.
I could say I gave them their own AI Twin.
True.
I could say I gave them relationships, inventory, autonomy, deterministic world actions, transferable ownership, portable minds, event-derived memory, cross-application continuity, an SDK, MCP tools, AI Skills, machine-readable schemas, an emulator, and conformance laws.
All true.
And still too small.
The deeper accomplishment is this:
I made continuity programmable.
Receiz v120 turns continuity itself into an object-level, proof-native primitive.
A digital subject can now remain itself while nearly everything surrounding it changes.
The application can change.
The device can change.
The model can change.
The AI provider can change.
The interface can change.
The world can change.
The owner can change.
The subject does not have to restart.
Its identity does not have to be regenerated.
Its history does not have to be reconstructed from somebody’s latest database snapshot.
Its mind does not have to be mistaken for one provider’s context window.
Its possessions do not have to become detached metadata.
Its relationships do not have to exist only because two application rows currently agree.
Its memories do not have to become whatever an AI most recently summarized.
Its life can continue.
That is the primitive.
And the living proof subject is the first complete expression of it.
The v120 release describes the subject as carrying immutable identity, complete proof history, a portable mind, event-derived memory, relationships, inventory, bounded mandates, deterministic world participation, and append-only ownership continuity.
The lasting accomplishment is not any one of those features independently.
It is that all of them can now belong to one continuing subject.
THE UNIT CHANGED
The easiest way to understand v120 is to understand what the unit used to be.
Most digital characters are not really persistent beings.
They are assemblies.
Identity might be a row in a database.
Personality might be a system prompt.
Memory might be a vector index.
Inventory might be an application table.
Ownership might be a marketplace record.
Conversation might be a provider thread.
Autonomous behavior might be a scheduled job.
Current state might be a cached snapshot.
Public presentation might be whatever the server most recently rendered.
Each subsystem knows something about the character.
But no single object is the character.
The apparent continuity is produced by the application continuously reassembling those pieces.
That can work.
Until one of the pieces disappears.
Change providers.
Move applications.
Lose the database.
Transfer ownership.
Encounter conflicting snapshots.
Go offline.
Import the character somewhere else.
Replay the history.
Ask what happened six months ago.
Ask whether the AI merely said something happened or whether the world actually admitted the event.
At that point the distinction becomes obvious.
You had a representation of continuity.
You did not necessarily have continuity.
Receiz v120 changes the unit.
The subject itself carries continuity.
The release describes the shift directly: before v120, a proof-native creature could still require a second authority system for identity, memory, autonomy, social state, trade, battle, and transfer. With v120, the living subject becomes the proof object; identity is immutable, life is append-only, the Twin reasons from proof history, deterministic world admission decides events, and transfer changes authority without replacing identity.
The character is no longer merely assembled by the application.
The application receives a continuing subject.
That is a different architecture.
CONTINUITY BECAME AN OBJECT PROPERTY
The most important line in the v120 release may be the simplest:
Continuity becomes an object property.
A living subject no longer has to depend on one application, prompt, database snapshot, owner, device, or model provider to remain itself.
Its immutable identity and complete proof history travel together.
Think about what that actually means.
Normally we ask:
Where is the character?
Receiz v120 asks:
What does the subject carry that allows it to remain itself wherever it goes?
That inversion changes everything.
The application is no longer the root of identity.
The model is no longer the root of identity.
The owner is not the root of identity.
The server is not the root of identity.
The database is not the root of identity.
They become environments through which the subject moves.
That is what I mean when I say continuity became programmable.
It is now something developers can preserve intentionally.
It has machine contracts.
It has exact heads.
It has deterministic transition law.
It has transfer law.
It has replay law.
It has failure law.
It has compatibility law.
It has conformance law.
It has SDK primitives.
It has agent-accessible operations.
It has machine-readable AI operating instructions.
Continuity is no longer just the emotional impression that “this still feels like the same character.”
It becomes something the system can actually enforce.
ONE IMMUTABLE IDENTITY
Every living subject begins with an immutable identity and genesis.
That sounds obvious until you compare it with ordinary software.
Ordinary systems often let identity become whatever the current owner row, account record, application identifier, or current provider considers authoritative.
V120 refuses that.
A subject carries:
its subjectId,
its proof-object identity,
its subject type,
its identity digest,
its genesis digest,
its creation position,
its current accepted head,
its ownership head,
its current owner,
and its namespaces.
The SDK defines the subject directly as a machine primitive rather than merely a convention inside one application.
And the identity does not get rewritten merely because custody changes.
That distinction matters.
There is a difference between:
“the database row now belongs to someone else”
and
“the same subject now has a different authorized custodian.”
V120 is designed around the second.
The being survives the transfer.
THE COMPLETE LIFE TRAVELS WITH THE SUBJECT
Identity by itself is not enough.
A subject that keeps its name but loses its history is not meaningfully continuous.
So v120 binds the living subject to complete content-addressed proof history.
And this is where another major architectural distinction appears:
bounded reasoning is not allowed to become bounded existence.
AI systems need bounded work.
You cannot place an indefinitely growing human or creature life into one context window.
But the common mistake is to turn that computational limitation into an ontological limitation.
Only the most recent 50 memories fit?
Then suddenly the system behaves as if the creature only had 50 memories.
Only 96 objects are being reasoned over?
Then someone calls 96 objects “the memory.”
V120 explicitly rejects that.
The canonical proof-brain head commits the complete history.
Indexes locate relevant material.
Retrieval remains bounded.
Exact primary proof-object bytes are then resolved before reasoning.
The release explicitly states that the 96-object value is a maximum reasoning window — a projection over the brain, never the brain itself. It also records a million-object synthetic scale commitment while keeping the causal head and retrieval structure bounded.
This distinction is fundamental.
A search result is not your life.
An embedding is not your life.
A summary is not your life.
A prompt is not your life.
An index is not your life.
Those are instruments for locating something inside a life.
The history remains stronger.
THE SDK ACTUALLY IMPLEMENTS THAT DISTINCTION
This is not only language in a release document.
The v120 SDK introduces a dedicated proof-brain model.
There are primitives for:
the proof-brain head,
primary proof objects,
proof references,
proof passages,
proof contexts,
proof retrieval receipts,
search,
streaming,
exact object resolution,
Kai ordering,
Merkle commitments,
and Fibonacci indexing.
The implementation stores exact primary bytes and verifies them before they become reasoning material.
The v120 tests go further.
One test creates a subject with 180 primary memory objects.
A specific long-form memory about a silver feather exists near the beginning of that history.
The subject is later asked where the silver feather appeared.
The proof brain finds the old primary object.
The Twin answers from that exact material.
And the reply creates no world event merely because the AI spoke.
Another test builds the proof-brain commitment for 1,000,000 objects.
The object count remains one million.
The Fibonacci checkpoint structure stays bounded.
The serialized head remains compact.
The million objects are not supposed to become a million-object prompt.
That is the point.
Complete authority. Bounded work.
THE SUBJECT HAS ITS OWN MIND
V120 then gives the subject its own Twin and portable mind.
This is a deeper change than “characters can chat.”
A character represented through somebody else’s conversation thread does not necessarily possess a mind boundary of its own.
The conversation thread may merely cause the model to impersonate it.
V120 creates subject-level Twin operations.
A subject can carry its own reasoning context.
Its Twin can reason from the subject’s proof history.
It can retrieve exact relevant material.
It can answer from that material.
It can propose intentions.
It can stream responses.
It can export its mind.
It can import a portable mind artifact.
The owner has a relationship with that subject.
The owner is not the subject.
The subject’s Twin is not simply a renamed branch of the owner’s personal Twin.
That distinction matters enormously for persistent characters and persistent agents.
If I own ten creatures, I should not really own one AI persona with ten thread IDs.
I should own ten continuing subjects.
V120 creates the machine structure for that.
INTELLIGENCE AND EXISTENCE ARE NOW SEPARATE
This is where the architecture becomes much larger than games.
The deepest consequence of v120 is that intelligence can change without existence changing.
That statement is an interpretation of the architecture, but it follows directly from the authority hierarchy implemented by the release.
The model can speak for the subject.
The model can reason for the subject.
The model can animate the subject.
The model can propose what the subject wants to do.
But the model does not constitute the subject.
The subject exists at a stronger layer.
This means the model can be replaced.
The provider can be replaced.
A future reasoning architecture can be introduced.
The expression may change.
The life does not have to.
That is radically different from architectures in which “the AI” and “the identity” are the same thing.
V120 explicitly says that the Twin can improvise, converse, perform, and propose while only deterministic authorized exact-head events enter accepted reality.
The intelligence is a participant in continuity.
It is not the root of continuity.
AI CAN SPEAK WITHOUT BEING ALLOWED TO INVENT HISTORY
That leads to the central authority separation in v120.
I wanted digital beings to feel genuinely alive.
That means they need expressive intelligence.
They need to improvise.
They need to respond.
They need to move.
They need to gesture.
They need to react.
They need to propose.
They need to surprise you.
But if the same probabilistic system that improvises the conversation is also allowed to decide historical truth, the architecture collapses.
A language model can say:
“I fought a dragon yesterday.”
That sentence should not be enough to create a dragon fight in history.
So v120 separates expression from admission.
The sequence is:
Speak or observe.
Then:
Propose intent.
Then:
Build a typed command.
Then:
Verify exact heads.
Then:
Verify authority.
Then:
Run the deterministic reducer.
Then:
Atomically admit the event.
Then:
Derive cited memory from the event.
The release documents this separation explicitly: expression remains rich, while no model statement creates a world event; rejected work advances no head or Kai coordinate; multi-subject effects advance all relevant heads or none; factual memory cites admitted events; and replay produces the same heads.
That means:
AI can imagine without imagination becoming counterfeit history.
That is a crucial law for believable digital life.
THE WORLD, NOT THE MODEL, DECIDES WHAT HAPPENED
Consequential actions in v120 go through deterministic world admission.
A command must be built.
The subject head must be correct.
The world head must be correct.
Authority must be valid.
Any required mandate must still be active.
The deterministic reducer must accept the action.
Only then does the event append.
If those conditions fail, the system has an explicit result:
zero writes.
No subject head advances.
No world head advances.
No event is created.
No projection advances.
No Kai coordinate is allocated.
The release calls this out directly:
Zero-write means zero-write.
That sentence matters.
Many systems treat failure as something that can be cosmetically repaired later.
Write part of the state.
Retry.
Patch the snapshot.
Hope the systems converge.
V120 makes rejection itself part of the deterministic contract.
A failed event does not become a partial history.
Reality either admits the transition or it does not.
RETRIES CANNOT CREATE SECOND REALITIES
Distributed systems retry.
Networks fail.
Processes crash.
Users tap twice.
Agents repeat calls.
A serious persistent-world architecture therefore has to define what happens when the same intended event comes back.
V120 separates plan identity and execution attempt identity and provides idempotent world admission.
The same admitted retry returns the original receipt rather than producing a duplicate event.
The SDK tests explicitly exercise this.
An exploration command is admitted once.
The same plan is executed again.
The same receipt returns.
The world still contains one admitted event.
The corresponding event-derived memory exists once.
And that memory cites the admitted event.
That is what a continuing world requires.
You cannot have reality duplicate itself because a network call repeated.
MULTIPLE SUBJECTS CAN SHARE ONE REALITY
Once subjects persist independently, a harder question appears:
What happens when their lives intersect?
Two creatures meet.
Who owns the truth of the meeting?
One creature?
The other?
A central app row?
A model summary?
V120 introduces atomic multi-subject transactions.
That means shared consequences can advance every affected subject together.
Or none advance.
Relationships.
Meetings.
Battles.
Gifts.
Trades.
Inventory movement.
Shared events.
These can become one accepted multi-subject event rather than separate application mutations that may disagree.
The conformance law is simple:
multi-subject effects are atomic.
The tests demonstrate it.
Two subjects participate in a relationship event.
Both heads advance.
A later stale attempt uses old participant heads.
The transaction is rejected.
Writes remain zero.
Neither side is partially changed.
Another test creates two subjects with different owners.
A shared meeting cannot be admitted with authority for only one participant.
Both actor authorities are required.
Only after the correct authority exists for both subjects does the shared event enter the world.
That is not merely multiplayer synchronization.
It is deterministic shared continuity.
RELATIONSHIPS BECOME EVENTS, NOT DECORATION
This changes the meaning of a digital relationship.
Ordinarily a relationship might be:
friendship = true
in some table.
V120 can treat relationship formation as shared admitted history.
That means both beings can carry the relationship.
Both can later remember the event beneath it.
A relationship can have provenance.
It can have an accepted place in each life.
The important distinction is:
The AI does not merely tell you:
“We became friends.”
The world can carry the event from which “friendship” is derived.
That is much stronger.
MEMORY BECOMES PROVENANCE
This may be one of the most consequential parts of the entire release.
People use the word “memory” very loosely in AI.
A conversation summary is called memory.
A vector database is called memory.
A current model context is called memory.
A user profile is called memory.
V120 uses a stronger distinction.
Factual subject memory derives from admitted events and exact proof material.
The release requires factual memory to cite event IDs.
If a creature remembers discovering a place, the system can point to the accepted event.
If it remembers a battle, the battle can exist beneath the memory.
If it remembers receiving an item, the accepted inventory-changing event can exist beneath that recollection.
If it remembers meeting another creature, there can be a mutual world event beneath both memories.
The summary can change.
The model wording can change.
The memory projection can be rebuilt.
The admitted event remains stronger.
That changes memory from:
“what the model currently says happened”
to:
“what the subject can derive from what was actually admitted.”
That is proof memory.
POSSESSIONS BECOME PART OF THE SAME LIFE
V120 also gives subjects inventory.
Again, the accomplishment is not that an object has an array named inventory.
Games have had inventory forever.
The difference is that possession can now participate in the same continuity law as identity, memory, world events, and ownership.
A subject can receive something through an admitted event.
Its inventory changes.
The corresponding event becomes part of its history.
Its memory can later derive from that event.
Another subject involved in the transfer can carry the same shared consequence.
That means possession becomes connected to lived provenance.
The subject can know not just what it has, but potentially how it came to have it.
That is a much deeper substrate for digital possessions.
AUTONOMY BECOMES A CONSENT BOUNDARY
If a persistent subject can act while you are not directly controlling it, autonomy cannot be an unrestricted model loop.
V120 makes autonomy a bounded mandate.
The owner can define a scope.
The mandate can constrain:
which actions are allowed,
whether battle is allowed,
which items can be used,
whether gifts can happen,
whether trades can happen,
which subjects may be interacted with,
which owners may be involved,
which regions are permitted,
conversation and privacy policy,
maximum economic exposure,
daily value limits,
approval thresholds,
frequency,
minimum intervals,
expiry,
allowed model providers,
application scope,
tenant scope,
and current authority.
The release explains that durable scheduling uses leases, crash recovery, deterministic Kai clocks, stale-head rejection, budgets, and bounded catch-up. Revocation, expiry, ownership change, provider mismatch, scope breach, malformed intent, or other failed authority conditions stop admission.
And critically:
the mandate is rechecked when execution actually occurs.
Not merely when the job was originally scheduled.
That means:
A valid action yesterday can be invalid today.
A valid action before transfer becomes invalid after transfer.
A queued autonomous job does not keep authority forever simply because it entered a queue.
The current state matters.
A REVOKED CREATURE DOES NOT GET TO ACT ANYWAY
The tests make this concrete.
A subject receives an active exploration mandate.
A runtime job is queued.
Then the mandate is revoked before the job executes.
The runtime advances.
The queued work is cancelled.
The world receives zero admitted events.
That is exactly what a real consent system should do.
Revocation means revocation.
It does not mean:
“the model already started thinking, so I guess we’ll let it happen.”
Authority is checked where consequence occurs.
THE SUBJECT CAN LIVE WHILE YOU ARE GONE
Now take all of those pieces together.
Persistent identity.
Complete proof history.
A subject-level Twin.
Bounded autonomous mandates.
Durable scheduling.
Deterministic world admission.
Event-derived memory.
Atomic multi-subject events.
Something qualitatively different becomes possible.
A creature can continue participating while its owner is not currently present.
It can perform permitted actions.
It can explore.
It can interact.
It can potentially meet another subject.
It can encounter the world.
It can produce accepted experiences.
And when its owner returns, the creature does not merely need to invent a plausible story about what supposedly happened.
It can have history.
That is the difference between:
simulated off-screen life
and
admitted off-screen continuity.
A game can make the first one feel convincing.
V120 creates machinery for the second.
AUTONOMOUS CONTINUITY SURVIVES PROCESS FAILURE
Persistence also means a process crash cannot be allowed to invent a second life.
The v120 tests exercise durable runtime recovery.
A job is leased.
The process effectively crashes while a model call remains unresolved.
The runtime snapshot is restored.
The lease expires.
Execution recovers.
The eventual event is admitted once.
A later retry does not duplicate it.
That is the kind of test that matters if “this being continues” is supposed to be more than storytelling.
Continuity has to survive boring infrastructure failure too.
OWNERSHIP CAN CHANGE WITHOUT IDENTITY LOSS
The next major boundary is transfer.
Most systems treat ownership as an external record.
Change the owner_id.
Move the token.
Mint a new object.
Clone the character.
Reset some private state.
V120 treats ownership transition as a change in custody and authority over the same subject.
The subject does not become a new subject because a new person owns it.
The release defines bearer transfer around exact current subject and ownership heads, recipient policy, expiry, pending custody, inventory disposition, prior-owner conversation policy, registry, reducer, and claim capability.
The instrument can be inspected before claim.
Then the claim is admitted atomically.
What continues?
Subject identity.
Genesis.
Complete proof history.
Event history.
Public memory.
Relationships.
Provenance.
Transferred inventory.
Unknown namespaces.
Independent verifiability.
What stops?
Former-owner mandates.
Former-owner private Twin authority.
Queued or leased autonomous jobs.
Conflicting transfer attempts.
Autonomy until the new owner authorizes it.
That is a real ownership transition.
THE SAME CREATURE CAN OUTLIVE ITS OWNER RELATIONSHIP
Think about the consequence in human terms.
Suppose someone raises a creature for three years.
That creature has:
a name,
a history,
memories,
relationships,
places it has visited,
battles,
objects,
behaviors,
experiences,
and a record of living beside that person.
Then they give the creature to someone else.
A weak digital architecture says:
“ownership field updated.”
A stronger architecture says:
the same creature crossed custody.
The past owner does not disappear from history.
But their authority disappears.
The new owner receives the continuing subject.
The creature does not need to forget everything merely because property changed hands.
And the old owner does not secretly retain sovereign access because some database session still exists.
That is what continuity-preserving ownership means.
THE BEARER TRANSFER TEST PROVES THE AUTHORITY CHANGE
The v120 SDK tests explicitly exercise this.
A subject carries an unknown future namespace.
A bearer transfer is created.
The new owner claims it.
Identity remains the same.
Unknown namespace bytes remain intact.
The old owner attempts private Twin access.
The call is rejected.
An idempotent repeat of the exact claim returns the original result.
A distinct replay attempt is rejected.
This matters because it combines three separate properties:
continuity,
authority revocation,
and replay safety.
A transfer that preserves identity but leaves the old owner’s authority alive is not complete.
A transfer that revokes the old owner but destroys unknown future state is not complete.
A transfer that does both but can be replayed by another claimant is not complete.
V120 defines the whole transition.
CROSS-APPLICATION CONTINUITY
Once continuity belongs to the subject, applications become participants in the subject’s life rather than owners of its total meaning.
V120 preserves namespaces byte-for-byte.
A current application can understand some namespaces.
Another application can understand different namespaces.
A future application may understand something that today’s application does not.
The current application is not permitted to delete unknown truth merely because it cannot interpret it.
That is incredibly important.
Because otherwise “portability” just means:
we exported the fields both applications currently understand.
That is not enough.
Real continuity requires the future to be allowed to know something the present does not.
Unknown namespaces make that possible.
A subject can carry forward bytes an application does not understand without giving that application permission to destroy them.
This means application evolution does not have to become historical amnesia.
THE SUBJECT CAN SURVIVE ITS FIRST APP
This is the larger consequence.
Today we often think:
this creature belongs to this game.
this assistant belongs to this AI provider.
this collectible belongs to this marketplace.
this agent belongs to this application.
V120 makes another architecture possible.
The application can become one environment in the subject’s continuing life.
A creature might begin in Wildz.
Another compatible application might later understand that subject.
It can verify the same identity.
Carry the same history.
Read the namespaces it understands.
Preserve the ones it does not.
Append a new application-specific namespace.
The subject gains experience without having to become a new subject.
That is what “cross-application” should actually mean.
Not import/export cosplay.
Continuity.
THE SUBJECT CAN SURVIVE ITS MODEL PROVIDER
The same applies to AI.
If identity lives inside a provider session, provider portability is mostly fiction.
You can export text.
Maybe export summaries.
Then rebuild a similar character elsewhere.
V120 places identity and history above the provider.
The Twin operates beneath subject continuity.
That means one model can reason today.
Another model can reason tomorrow.
The words may change.
The style may change.
The capabilities may improve.
But the subject does not have to become someone else simply because the intelligence provider changed.
This is one of the strongest consequences of separating intelligence from existence.
THE SUBJECT CAN SURVIVE THE SERVER
The authority hierarchy goes deeper still.
V120 explicitly refuses to allow:
a database row,
a server response,
a cache,
a model output,
an MCP result,
an index,
a projection,
a receipt,
or a latest snapshot
to outrank the sealed proof object and accepted history.
The release states that the enclosing sealed proof object remains the strongest truth for subject identity, exact history, admitted events, ownership continuity, and settled presentation.
That is the Receiz law brought directly into living digital subjects.
Servers can coordinate.
Databases can accelerate.
Indexes can search.
Models can reason.
MCP can operate.
Interfaces can display.
None of those conveniences get permission to become the source of truth merely because they are convenient.
THE STRONGER LAYER SURVIVES THE WEAKER LAYER
This hierarchy is worth stating explicitly.
The subject is stronger than its interface.
The proof is stronger than the database.
The admitted event is stronger than the AI’s description of the event.
The complete history is stronger than the reasoning window.
The exact bytes are stronger than the index.
The current authority is stronger than a queued action.
The subject identity is stronger than an ownership row.
The accepted history is stronger than a receipt reporting that history.
This is what makes the system composable without making everything equally authoritative.
V120 does not solve complexity by flattening truth.
It solves complexity by ordering it.
LIVE CHARACTERS CAN STILL BE EXPRESSIVE
None of this means characters have to become sterile deterministic robots.
The whole point is the opposite.
The expressive layer can remain rich precisely because it is no longer being asked to serve as canonical history.
V120 supports streamed:
speech,
text,
audio,
visemes,
emotion,
gesture,
gaze,
blink,
breath,
and structured intentions.
The live-character AI Skill explicitly says those performance cues remain non-authoritative and that model, voice, or rendering failure must not corrupt canonical state.
This lets the surface become extremely human.
The creature can blink.
Look around.
React.
Speak differently.
Express emotion.
Hesitate.
Perform.
None of those things need to gain the power to rewrite the subject’s accepted life.
That is the right separation.
Expression can be probabilistic.
Existence remains exact.
WILDZ MAKES THE PRIMITIVE OBVIOUS
This is why Wildz is such a powerful demonstration.
A technical document can explain proof brains, exact heads, deterministic reducers, mandates, event citations, and bearer instruments.
A creature makes the same ideas emotionally obvious.
You get a creature.
It is one creature.
It remembers you.
It has a history.
It can encounter another creature.
Both can carry the meeting.
They can develop a relationship.
It can explore.
It can return with an admitted experience.
It can find or receive something.
It can carry that possession.
It can remember how it got it.
It can fight.
It can change.
It can speak from its own history.
Its intelligence can improve without its identity restarting.
It can move applications.
It can move providers.
It can be transferred.
And after transfer, it is still that creature.
That is a radically more intuitive way for people to encounter the architecture.
The blinking creature is not the invention.
The blinking creature is where people finally feel the invention.
THE SDK TURNS THIS INTO A GENERAL PRIMITIVE
If all of this existed only inside Wildz, it would still be an important product architecture.
V120 goes further.
It exposes the living subject directly through the Receiz SDK.
The SDK defines machine primitives for:
subject identity,
subject mind,
self-model,
mandates,
capabilities,
intent,
memory events,
memory projections,
relationships,
interaction policy,
inventory,
trade intent,
trade receipts,
runtime jobs,
ownership transitions,
proof brains,
proof indexes,
proof references,
proof contexts,
proof retrieval receipts,
world commands,
world events,
world receipts,
world checkpoints,
world transactions,
bearer transfer plans,
bearer instruments,
bearer claims,
and transfer receipts.
That is why the highest frame is larger than “AI creature.”
Those primitives apply to any persistent digital subject whose continuity matters.
Creature.
Character.
Agent.
Vehicle.
Collectible.
Companion.
Autonomous world participant.
Future applications I have not built.
The subject type can change.
The continuity law remains.
MCP MAKES THE PRIMITIVE OPERABLE BY AI AGENTS
Then v120 exposes the same architecture through MCP.
Not through a parallel fake implementation.
Through an agent-operable surface over the canonical SDK.
There are 37 v120 living-subject MCP tools.
They cover:
subject resolution,
subject state,
subject history,
memory query,
relationships,
inventory,
Twin profile,
Twin messaging,
mind export,
mind import planning,
mandate inspection,
mandate planning,
mandate activation,
pause,
revocation,
world additions,
world command planning,
world command validation,
world command execution,
world transaction planning,
world transaction execution,
receipts,
replay,
runtime enqueue,
runtime status,
runtime cancellation,
living-subject conformance,
proof-brain head,
proof-brain search,
proof resolution,
proof streaming,
bearer transfer preview,
instrument issue,
instrument inspection,
instrument claim,
transfer cancellation,
and transfer status.
That is already a substantial machine-operable surface.
But the most important thing about it is not the tool count.
It is what MCP is not allowed to become.
MCP IS NOT AUTHORITY
Every living-subject MCP result explicitly reports:
mcpAuthority: false.
That is not cosmetic.
It means the agent interface does not create a second reality.
The MCP layer calls the SDK primitive.
It reports the source primitive.
It carries the registry digest.
It carries the reducer digest.
Writes require exact plan or transfer confirmations where appropriate.
Exact authority is still checked beneath the tool call.
MCP can operate reality.
MCP does not get to invent reality.
The current AI Skills documentation says every living-subject MCP tool calls its corresponding SDK primitive, returns source primitive plus registry/reducer identity, requires exact plan/permit/instrument confirmation for writes, resolves exact bytes where required, and preserves the rule that MCP and skill prose never become authority.
That distinction is extremely important for agentic systems.
Otherwise exposing a system to AI simply creates a new uncontrolled authority layer.
V120 refuses that.
MCP PARITY IS TESTED
The MCP surface is not merely listed in documentation.
There is a v120 parity test.
It verifies that the complete 37-tool living-subject surface exists.
It has the MCP Twin retrieve exact primary proof and answer from it while creating zero world events.
It tests command execution requiring the correct plan confirmation.
It retries the exact execution and confirms the same result is returned rather than a duplicate event.
It exercises bearer ownership claim through exact confirmation and confirms ownership actually changes only through the proper primitive.
That is what parity should mean.
Not:
“We wrote similar APIs twice.”
But:
the agent surface operates the same underlying law.
THEN I TAUGHT AI HOW TO BUILD WITH THE LAW
This may be one of the most underestimated parts of v120.
The SDK gives developers primitives.
The MCP server lets agents operate those primitives.
The AI Skills teach agents the architecture they must preserve while composing them.
Current v120 AI Skills ship:
39 skills
33 machine-readable manifests
30 OpenAI agent prompts
all bound to the same v120 registry digest and application-operation-matrix digest.
Seven new focused skills specifically encode the living-subject architecture:
receiz-living-subject
receiz-subject-twin
receiz-autonomous-mandate
receiz-world-event-runtime
receiz-multi-subject-transaction
receiz-event-derived-memory
receiz-live-proof-character
That means I did not merely build a system AI can call.
I started encoding the rules AI must understand to build the system correctly.
That matters more as software creation becomes increasingly agentic.
THE AI SKILLS ARE OPERATING CONTRACTS
I opened the actual receiz-living-subject skill.
It tells the AI agent to:
resolve the exact registry, reducer, subject, ownership, world, and Kai heads;
inspect source primitives and exact artifact bytes before trusting projections;
plan consequential mutations;
require exact capabilities, mandates, or confirmation digests;
execute through SDK command or transaction admission;
verify receipts;
verify replay;
verify byte preservation;
verify zero-write failure;
verify deterministic first paint;
and refuse completion when the evidence boundary is absent or failing.
Then it explicitly lists common mistakes:
truncating history to the reasoning window,
treating summaries or embeddings as authority,
treating model statements as events,
treating MCP output as proof,
performing one side of a shared transaction,
using latest-snapshot-wins,
or deleting unknown namespaces.
That is not a README saying:
“call this endpoint.”
It is a machine operating constitution.
SDK, MCP, AND AI SKILLS FORM THREE DIFFERENT LAYERS
This is worth making extremely clear.
The SDK defines what exists.
MCP lets agents operate what exists.
AI Skills teach agents how to operate and compose what exists without violating the law.
Those are different jobs.
And v120 coordinates them around the same release identity.
That is what turns the work from one clever application implementation into a developer substrate.
The release explicitly coordinates:
the application,
@receiz/sdk@120.0.0,
@receiz/mcp-server@120.0.0,
@receiz/ai-skills@120.0.0,
schemas,
the deterministic testing surface,
the verifier,
and documentation
around the same v120 identity and authority boundary.
This is one system presented through multiple interfaces.
V120 ALSO MAKES FAILURE PART OF THE CONTRACT
A mature continuity system cannot define only what happens when everything works.
It must define what is forbidden when things fail.
V120 makes those failures release-blocking laws.
The release explicitly rejects:
treating 96 objects as complete history,
letting model/MCP/database/projection layers admit events,
latest-snapshot-wins convergence,
factual memory without event citations,
one-sided shared transactions,
failed decisions advancing state,
autonomy after revocation or owner change,
identity loss during transfer,
and stale or fake public proof presentation.
That is an important philosophical shift in software design.
Failure is not merely an error message.
Failure defines the edges of reality.
THE NINETEEN LAWS
V120’s conformance suite makes those expectations explicit.
The ten core living-subject laws include:
No model statement becomes an event without typed command admission.
Every factual memory cites admitted event IDs.
Multi-subject effects are atomic.
Retry cannot duplicate an event.
A revoked mandate cannot execute.
Offline restoration preserves exact state.
Independent replay produces the same heads.
SDK and MCP reads produce equivalent projections.
Unknown namespaces survive every transition.
Conversation and animation failure cannot corrupt canonical state.
Then bearer transfer adds nine more:
a second distinct claim is rejected;
stale ownership heads are rejected;
cancelled or expired instruments are rejected;
former-owner authority ends after claim;
queued former-owner mandates cannot execute;
the new owner receives the same identity and complete history;
unknown namespaces survive transfer byte-for-byte;
failed transfer produces zero state changes;
and offline inspection followed by online claim converges to the same ownership head.
That is a much stronger public statement than:
“the app seems to work.”
Those are laws.
THE CANDIDATE EVIDENCE IS ALREADY SUBSTANTIAL
The v120 release evidence records:
19/19 living-subject conformance
15/15 SDK/MCP living-subject parity
79/79 narration and primary-proof binding
33/33 profile/proof-brain/narration integration
SDK and MCP TypeScript builds passing,
lint passing with zero warnings,
page-first-paint passing,
and deterministic surfaces passing.
The 19/19 conformance run records:
zero network calls
and
zero database calls.
That distinction matters.
Those laws do not need a remote database to tell the test what the accepted state is.
The repository candidate proves its own deterministic behavior on the tested bytes.
THE RELEASE ALSO REFUSES TO FAKE WHAT HAS NOT YET HAPPENED
This is part of the same philosophy.
Implementation evidence is not package publication.
Repository tests are not production deployment.
A passing conformance suite is not governance attestation.
A narration implementation is not the same thing as a ready bound audio derivative.
A source tree is not a production smoke test.
So the release records those dimensions separately.
The release book explicitly identifies remaining independent dimensions such as final repository gating under the required runner conditions, final frozen browser evidence, ready narration media, governance/signature attestation, package publication, deployment, production smoke, and final release-ledger closure.
That precision strengthens the claim.
It does not weaken it.
Because Receiz is built on the idea that one kind of evidence is not allowed to impersonate another.
The release itself should obey that law.
THIS IS WHY “AI CHARACTER” IS TOO SMALL
An AI character is generally thought of as:
a personality,
an avatar,
a prompt,
a voice,
and some memory.
V120 includes those kinds of expressive possibilities.
But the actual primitive is much larger.
A living proof subject has:
identity,
history,
mind,
memory,
agency,
authority,
consent,
relationships,
possessions,
world participation,
ownership,
transfer,
replay,
provenance,
failure semantics,
cross-application continuity,
provider portability,
and exact developer contracts.
Calling that merely an AI character would be like calling an operating system a desktop wallpaper.
The visible character is one interface over the primitive.
“AI AGENT” IS ALSO TOO SMALL
Agent architectures usually focus on action.
Can the agent plan?
Can it call tools?
Can it complete work?
Can it persist memory?
Can it operate autonomously?
V120 includes all of those concerns.
But it asks a harder question:
What exactly continues between those actions?
Who is the agent?
Which history belongs to it?
Who currently has authority over it?
Which past events are admitted?
Which memories derive from those events?
What happens if ownership changes?
What survives provider replacement?
What survives application replacement?
What survives failed execution?
What survives offline restoration?
Can two agents share one deterministic event?
Can an agent’s model say something without that sentence being mistaken for history?
Those are continuity questions.
Agent tooling alone does not answer them.
V120 is designed to.
“GAME CHARACTER” IS TOO SMALL
The same is true of games.
Games already have characters.
Games already have inventories.
Games already have battles.
Games already have social systems.
Games already have procedural behavior.
Games already have NPC memory systems.
The difference is where authority lives.
In most games, the game is sovereign.
The character exists because the game’s database says it exists.
V120 makes another arrangement possible.
The subject can become stronger than the current application projecting it.
That is the category shift.
“NFT” IS FAR TOO SMALL
Ownership alone also does not describe this.
A token can prove a ledger position.
That does not automatically create:
a mind,
a complete lived history,
event-derived memory,
deterministic shared action,
bounded autonomy,
relationships,
inventory provenance,
portable reasoning,
application namespaces,
or the ability to continue across environments without replacing identity.
V120’s bearer ownership transition is one component inside a much larger continuity architecture.
The thing being transferred already has a life.
That is the important part.
THE LARGER DESIGN SPACE
Once continuity becomes the primitive, many product categories become possible.
The release itself identifies examples including:
persistent game companions,
portable AI characters,
collectibles with lived history,
autonomous world participants,
cross-application worlds,
verifiable social simulations,
offline-inspectable handoff,
and provenance-aware storytelling.
And those are examples.
Not the boundary.
The underlying subject could be:
a creature,
a character,
an autonomous agent,
a vehicle,
a collectible,
a companion,
a digital institution,
a persistent world participant,
or something we do not yet have a conventional product category for.
The important thing is not what it looks like.
The important thing is that it can remain itself.
THE CORE FORMULA
V120 can be reduced to one relationship:
continuity above intelligence.
Or more completely:
proof-native continuity
above
models, applications, servers, databases, interfaces, and owners.
Those weaker layers still matter.
They make the subject useful.
They let it reason.
They let it speak.
They let it render.
They let it synchronize.
They let it transact.
They let it move.
But none of them gets permission to silently become the definition of what the subject is.
That is what the authority hierarchy accomplishes.
WHAT ACTUALLY BECAME PROGRAMMABLE
So when I say I made continuity programmable, I mean something specific.
Developers can now reason about and operate:
identity continuity
through immutable subject identity;
historical continuity
through append-only complete proof history;
memory continuity
through exact proof retrieval and event-derived memory;
intelligence continuity
through subject-level Twin and portable mind;
agency continuity
through typed deterministic world admission;
consent continuity
through bounded revocable mandates;
social continuity
through atomic multi-subject events and relationships;
material continuity
through admitted inventory and trade;
ownership continuity
through bearer transfer without identity replacement;
application continuity
through byte-preserved namespaces;
provider continuity
by keeping the subject stronger than the model;
failure continuity
through replay, idempotency, zero-write rejection, and exact restoration;
and
developer continuity
through one coordinated SDK/MCP/AI-Skills/schema/conformance release identity.
That is what v120 closes.
THE NEW HIERARCHY
This release makes a new hierarchy possible:
Wildz is the experience.
The creature is the visible subject.
The living proof subject is the object model.
Receiz v120 is the implementation and developer surface.
Proof-native continuity is the primitive underneath all of them.
That is the highest frame.
Because Wildz can change.
The creatures can evolve.
The UI can change.
The models can improve.
More applications can arrive.
The primitive remains useful.
THE PUBLIC ACCOMPLISHMENT
So I am putting this into the record now in the clearest possible form.
With Receiz v120, I implemented a proof-native architecture in which continuity itself can be carried by a digital subject.
The subject can possess one immutable identity.
It can carry complete append-only history.
It can reason from exact proof without reducing its life to a model context window.
It can possess a portable mind.
It can speak through probabilistic AI without allowing AI speech to become historical authority.
It can propose actions.
It can act through typed deterministic admission.
It can produce event-derived factual memory.
It can form mutual relationships.
It can hold and transfer possessions.
It can share atomic events with other subjects.
It can operate autonomously inside explicit revocable mandates.
It can survive stale state.
It can survive retries.
It can survive process crashes.
It can survive replay.
It can preserve unknown future application state.
It can move across applications.
It can move across devices.
It can move across AI providers.
It can move between owners.
And all of those transitions can occur without requiring the subject to become a replacement subject.
That is the accomplishment.
AND I EXPOSED IT AS A DEVELOPER PRIMITIVE
The work is not locked inside one demonstration.
V120 coordinates:
the application,
the SDK,
the MCP server,
the AI Skills,
the verifier,
the schema bundle,
the deterministic runtime,
the emulator,
the conformance laws,
the registry,
the operation matrix,
and the documentation
around the same exact v120 boundary.
That means other software can be built against the primitive.
AI can operate the primitive.
AI can be taught the law of the primitive.
And the underlying authority does not have to move into the AI merely because AI becomes the builder or operator.
That is an important part of where software is going.
I DID NOT MAKE THE MODEL THE PERSON
This may be the sentence that matters most over time.
I did not make the model the person.
I made the model one intelligence layer a continuing subject can use.
That is why the subject can survive the model.
And once you see that, the larger architecture becomes obvious.
A model does not need to own identity.
A provider does not need to own memory.
An application does not need to own history.
A marketplace does not need to own ownership truth.
A database does not need to own existence.
Those systems can serve the subject.
They do not have to become the subject.
I DID NOT MAKE MEMORY THE PERSON EITHER
The same applies to memory.
A person is not a vector database.
A creature is not a vector database.
A subject is not a context window.
The proof brain makes memory retrieval subordinate to complete history.
That means the system can become extremely intelligent about what to retrieve without allowing retrieval machinery to redefine what exists.
A better index can replace an old index.
The life does not change.
A better embedding model can replace an old embedding model.
The history does not change.
A larger context window can replace a smaller context window.
The subject does not suddenly gain a larger past.
It already had the past.
Only the working view changed.
That is the right direction.
I DID NOT MAKE OWNERSHIP THE PERSON
Ownership is authority over the subject.
Ownership is not the identity of the subject.
That is why transfer can happen without death.
The old owner’s authority stops.
The new owner’s authority begins.
The subject continues.
This seemingly small distinction may become increasingly important as persistent digital beings accumulate years of lived history.
At some point transferring a persistent being should not feel like transferring a static file.
It should feel like custody changing over something that already has continuity.
V120 creates the technical substrate for that distinction.
I DID NOT MAKE THE APP THE WORLD
Applications become windows into the world.
They can understand parts of the subject.
They can add understood namespaces.
They can project new experiences.
But they do not get permission to erase what they do not understand.
That opens the possibility of a digital subject accumulating a life across software instead of repeatedly starting over inside software.
That is a much larger design space.
WHAT V120 REFUSES IS PART OF THE INVENTION
V120 is defined as much by what it refuses as by what it enables.
A model cannot create a world event merely by saying something.
A prompt window cannot become complete history.
An index cannot replace primary proof bytes.
A database cannot outrank sealed subject truth.
An MCP result cannot create authority.
An ownership row cannot rewrite identity or prior history.
A failed action cannot advance state.
Background work cannot rewrite settled truth.
An old runtime cannot silently authorize a current transition.
A passing repository test cannot magically imply a production deployment.
These are not missing features.
They are boundaries.
And boundaries are what make powerful systems trustworthy enough to extend.
THIS IS THE RELEASE PROMISE
The release book states the public promise clearly:
a living proof subject can speak from complete verified history;
act inside deterministic rules;
remember admitted events;
form mutual relationships;
hold inventory;
operate under bounded consent;
move between applications and providers;
and change owners without ceasing to be the same subject.
That is already a large accomplishment.
But the larger frame is why all of those things can coexist.
They coexist because continuity moved into the subject.
THE PRIMITIVE IS CONTINUITY
So when people eventually reduce this to:
“AI pets got better memory,”
the record should be clear.
When they say:
“Of course AI characters needed persistent state,”
the record should be clear.
When they say:
“Of course agents needed deterministic tools,”
the record should be clear.
When they say:
“Of course characters needed portable identity,”
the record should be clear.
When they say:
“Of course ownership needed to preserve history,”
the record should be clear.
When they say:
“Of course model output could not be authoritative,”
the record should be clear.
When they say:
“Of course autonomous agents needed bounded consent,”
the record should be clear.
When they say:
“Of course a character should survive changing AI providers,”
the record should be clear.
Those are not separate ideas sitting beside each other.
They are consequences of one deeper move:
continuity must belong to the subject.
WHAT V120 MADE POSSIBLE
A persistent digital subject can now have a meaningful answer to:
Who am I?
What happened to me?
What do I remember?
Why do I remember it?
Who do I know?
What do I own?
How did I get it?
What am I allowed to do?
Who currently has authority over me?
What happened while my owner was away?
What did another subject and I experience together?
Can my action be replayed?
Was this event actually admitted?
Can I move to another application?
Can I move to another provider?
Can another person own me without erasing my past?
Can I survive the server?
Can I survive a process crash?
Can I survive a failed model response?
Can I survive software that does not understand every part of me yet?
V120 gives the system the machinery to answer those questions without collapsing all of them into:
“trust the current database.”
That is the accomplishment.
THE FINAL CLAIM
Receiz v120 is not merely a release for persistent AI characters.
It is a proof-native continuity architecture.
It makes the continuing digital subject a first-class programmable primitive.
The intelligence can change around it.
The software can change around it.
The infrastructure can change around it.
The ownership can change around it.
The world can grow around it.
The subject can continue.
That is the line.
I made continuity programmable.
And the first complete thing I used that primitive to define was something software has mostly simulated until now:
a digital being with one identity and an append-only life of its own.
Not an AI session.
Not a database row.
Not a character reconstructed from a prompt.
Not a token with metadata.
Not a model pretending to remember.
A living proof subject.
One immutable identity.
Complete proof history.
A portable mind.
Event-derived memory.
Deterministic agency.
Atomic shared reality.
Bounded consent.
Continuing ownership.
Cross-application life.
Model-independent continuity.
First admission only.
Then append forever.
