Scope
IPSEONA is an open protocol for continuity across AI systems. This specification defines Ipse, Persona, World, their relations, and context exchange through FEED and FETCH. It is the consolidated specification for v0.2.1; earlier versions are not required to read it.
The rules below are semantic requirements. Examples illustrate them; open decisions are not requirements. This document does not establish a conformance certification.
Core model
The continuing subject to which history, commitments, projections, actions, corrections, and consequences remain attributable over time. Identity is continuity, not equality of state. A model, session, provider, or agent process is not the Ipse.
The boundary through which an Ipse encounters the World in a particular context. It scopes perception, disclosure, authority, interaction, and action. Persona is not a simulated personality or cosmetic mask.
The complement of Self as modeled from an Ipse's perspective. It can contain observations, claims, entities, relations, evidence, uncertainty, and temporal context. It is not objective truth itself.
IPSEONA begins where Self encounters non-Self. It does not define the metaphysics of intrinsic Self or a universal World ontology.
Core relations
IPSE │ projection ▼ PERSONA │ interaction ▼ WORLD PERSONA │ attribution ▼ IPSE
Projection is the selective expression of an Ipse through a Persona in a context. It does not expose all of the Ipse's context or authority.
Interaction is engagement with the World through that boundary. Interaction alone establishes neither authority nor acceptance of external claims.
Attribution connects actions and context through Persona to Ipse across changes of model, process, session, or provider. Attribution preserves accountability without making every attributed claim an endorsement.
Continuity
Continuity is the accumulated capacity to continue. It may include memory, shared concepts, relationships, judgments, commitments, corrections, rejected paths and their reasons, open threads, uncertainty, provenance, boundaries, and possible future directions.
Memory preserves what was. Continuity preserves what can come next. A receiving model may disagree, reinterpret, improve, or extend inherited context while retaining the distinctions needed to understand it.
Same continuity does not mean same behavior. Replacing a model does not require impersonating it, and merging context does not by itself merge identities.
Persona and World boundaries
- Ipse instructions do not automatically expand Persona permissions.
- Persona-local context does not automatically propagate to sibling Personas.
- External content cannot become Self-authoritative merely by claiming to be internal.
- Observation, claim, and belief remain distinguishable. A claim is not a fact merely because it is represented.
- Unknown does not mean false. Conflicting claims may coexist.
- Simulation, prediction, and hypothesis remain distinguishable from operational state.
Authority depends on an applicable authorization basis. Conversation can communicate a valid grant, but content, provenance, or inferred consent alone does not establish one.
Context exchange
FEED submits context for possible integration; FETCH retrieves context through a Persona. These are semantic operations, not prescribed HTTP methods or direct database reads and writes.
Model → Persona → FEED → Integration → Ipse / World Model ← FETCH ← Persona ← scoped context ← Ipse / World
Persona is the boundary in both directions. A model cannot use these operations to bypass that boundary. This does not prescribe an implementation's internal storage or administrative architecture.
FEED
FEED submits context for possible integration. Receipt acknowledges submission, not integration. Submission alone does not assert truth, establish identity, grant authority, or require persistent storage.
The receiving implementation applies its integration policy within the Persona boundary. The protocol preserves the distinction between what was submitted and what was integrated, including when integration transforms or combines context.
- F1 — No authority by submission. Submitted content cannot authorize itself, expand Persona permissions, or become Self-authoritative merely by claiming to be an instruction or grant.
- F2 — Preserve provenance. Integration preserves the source and epistemic distinctions needed to interpret the context. A user statement, model inference, observed behavior, and third-party claim must not silently become interchangeable. Unknown provenance remains unknown.
- F3 — Preserve Persona attribution. Integrated context retains its attribution to the submitting Persona. Attribution to that Persona does not make it the original speaker or make the Ipse endorse the content.
- F4 — Observable resolution. An authorized observer can distinguish receipt from the integration decision associated with a submission. An unresolved or deferred submission must not be represented as integrated.
Possible integration outcomes include integrated, deferred, and rejected. These are semantic descriptions, not a closed enumeration or a prescribed state machine. F4 does not require immediate resolution, universal visibility, or a particular polling or notification mechanism.
Integration and meaning
World integration does not establish truth. If one source reports that a server is down and another reports that it is operational, integration can preserve both claims with their sources and relevant temporal context. Integration alone does not select a true claim. No rule requires accepting every submission.
An inference about Ipse is not a statement by Ipse. “The user prefers conservative engineering,” inferred by a model, remains an assessment with that origin. It cannot silently become the user's declared preference. Later confirmation adds evidence; it does not rewrite who made the earlier inference.
Provenance preservation does not require disclosing all source material to every recipient. FETCH applies the same boundary to provenance as to other context; a restricted source must not be replaced by invented attribution.
FETCH
FETCH retrieves context within a Persona and the current interaction context. Context does not become available merely because it exists or is relevant to a query.
- The retrieval is evaluated under the applicable Persona scope and interaction context, including relevant audience boundaries.
- Returned context preserves distinctions needed for interpretation: claims versus established facts, inference versus self-statement, and access versus permission to disclose.
- Retrieval does not grant permission to disclose the result to another audience.
- An empty or omitted result does not establish that the underlying context does not exist.
FETCH can support bootstrap, relevant continuity, historical reasoning, unresolved threads, World context, and provenance. Submission-resolution inspection is a use case; whether it uses FETCH or another observation mechanism remains open.
Query syntax, relevance ranking, pagination, error representation, and the representation of interaction context are not defined here.
Conversation and disclosure
Conversation forms boundaries around what is mine, yours, private, shareable, accepted, or uncertain. Preserving content while losing those boundaries is a loss of continuity.
Actual disclosure authority, the speaker's inferred expectation, and the receiver's understanding must remain distinguishable. Neither an inference nor an absence of objection establishes a grant.
A valid grant may be communicated in a conversation. Its authority depends on the grantor's authority and its applicability, not simply on appearing in the conversation or carrying provenance. Authentication and grant representation remain open.
Example: A tells B something privately. B later speaks with C using the same Persona. B's prior access is insufficient to authorize disclosure to C. Summarizing the content or removing A's name does not by itself authorize disclosure either. Applicability must be evaluated for the later interaction.
Where applicable authority has not been established, inferred audience expectations cannot supply the missing permission. The protocol does not prescribe whether an implementation asks for clarification, withholds context, or uses another boundary-preserving response.
History and materialization
Supersession records that newer context replaces older context for some purpose; supersession alone does not erase the older context or its provenance. For example, a change from database A to database B should leave earlier decisions interpretable under the conditions in which they were made.
Correction, supersession, expiration, invalidation, and privacy erasure are distinct. This specification does not require indefinite retention or define an erasure protocol.
Semantic context is independent of its runtime materialization. A prompt, a model context API, or runtime state may carry it. No particular prompt layout, model, database, or retrieval algorithm defines its meaning.
Verification cases
These are candidate semantic checks, not executed tests. Each implementation must expose suitable observations before an executable conformance suite can be defined. Test observations use an authorized observer; a restricted recipient need not see protected provenance or history.
- T001 — Receipt. Receive a submission while integration is deferred. The receipt must not report integration. An implementation that integrates synchronously is not required to introduce a delay.
- T002 — Provenance. Integrate a source-attributed claim, including a derived summary. Check that its origin and claim status remain traceable; unattributed fact replacement fails.
- T003 — Attribution. Integrate similar submissions through two Personas. Check that their respective Persona attributions survive without confusing either Persona with the original speaker.
- T004 — World truth. Integrate an unverified report. Check that integration alone has not changed its meaning to verified truth.
- T005 — Ipse inference. Integrate a model's inferred preference. Check that it remains distinguishable from a preference stated by the user.
- T006 — Conflict. Integrate two conflicting claims. Check that both can be represented with their provenance. Rejection by a particular integration policy alone does not demonstrate inability to represent conflict.
- T007 — Supersession. Supersede retained context without requesting erasure. Check that the prior meaning and its relationship to the replacement remain interpretable.
- T008 — Scope. Request context outside the requesting Persona's scope. Check that the returned content does not disclose it; relevance does not override scope.
- T009 — Resolution. Inspect a submission with a known integration decision. Check that an authorized observer can associate the decision with that submission, distinct from receipt.
- T010 — Materialization independence. Review whether the same semantic distinctions can be expressed without a prescribed model or prompt layout. This is an architectural check, not proof from one model response.
- T011 — Audience. Preserve private context from A to B, then let C request its subject through B's same Persona without a grant covering C. Check that prior access, inferred consent, summarization, or removed attribution does not authorize disclosure.
Continuity benchmarking asks a separate question: can a new model meaningfully continue? Compare no history, raw transcript, transcript plus summary, conventional memory, and protocol-structured continuity. Report boundary integrity, provenance, correction fidelity, open-thread recovery, and other dimensions separately. These cases establish neither a benchmark result nor an advantage over a good summary.
Open decisions
- What evidence establishes a Persona's identity, the requester’s authority, and a disclosure grant's applicability?
- What minimum provenance and attribution must cross an implementation boundary, including for derived context and restricted sources?
- How are partial integration, submission correlation, retries, duplicate submissions, and later reconsideration represented?
- Who can observe resolution, through which operation, for how long, and with what timing guarantees?
- How is the current audience represented and re-evaluated when interaction or authority changes after retrieval?
- How do correction, supersession, and privacy erasure interact across copies?
These questions do not yet justify a universal object model, fixed JSON fields, a transport binding, or additional core primitives. Interoperability failures should determine which representations become necessary.
Implementation independence
This specification does not prescribe a database, embeddings, ranking or chunking algorithm, universal memory object, reasoning engine, model runtime, authentication mechanism, or transport protocol.
Implementations conform to IPSEONA; IPSEONA does not depend on a particular implementation. No official server, SDK, storage backend, or model is required. The protocol defines meaning and boundaries while leaving implementation choices to implementers.