What should persist when the underlying model, provider, device, or interface changes?
RESEARCH PROGRAM / 02[patent pending]
PERSISTENT IDENTITY · SOVEREIGN MEMORY · RELATIONAL CONTINUITY
AVA
A research program asking what identity, memory, relationship, and user authority should mean when the model underneath them is replaceable.
01 / THESIS
The model can change.
Continuity should remain yours.
AVA treats persistent identity as a user-governed systems problem—not a feature that should disappear whenever a vendor replaces the engine.
02 / RESEARCH MAP
QUESTIONS, NOT BLUEPRINTS
The boundaries worth pulling on.
How can memory and identity remain under the user’s authority rather than an application boundary?
How should prior interaction influence future behavior without turning history into permanent accumulation?
How can a person inspect, limit, correct, and erase persistent state?
How can the system distinguish supported memory from confident invention?
What observable tests would make continuity claims falsifiable?
03 / EVIDENCE POSTURE
SHOW THAT IT EXISTS WITHOUT SHOWING HOW TO REBUILD IT
More receipts. Less mechanism.
Dated runtime, source, test, and research artifacts support the development chronology.
Internal experiments show continuity-related state influencing later interactions.
Protected work is the subject of pending U.S. patent rights.
The website does not publish a reproducible implementation of the protected system.
[public]
What can be examined
The research thesis, observable goals, experiment design, chronology at a safe level, evidence classifications, limitations, and patent-pending status.
[withheld]
What remains protected
Internal state representations, variables, formulas, scoring, weights, thresholds, update behavior, routing logic, subsystem interactions, private prompts, production topology, code, and data.
PUBLIC RECORDBounded architecture and provenanceExamine the repository ↗
PUBLIC EXPERIMENTContinuity test designExamine the method →
CLAIM LEDGEREvidence boundariesReceipts →