Chapter 9: The Sovereign Memory Principle

Write a memory charter that makes retention, access, correction, review, deletion, and portability explicit, while preserving the difference between source material and your own judgments.

A tentative thought acquires an official voice

Audy opens a saved summary while preparing Himura Inc.'s next design session. One sentence reads, “Independent educators need help turning expertise into a task learners can perform.” It sounds like the premise of the project. It also sounds more certain than her evidence permits.

Her claims ledger is more careful. It treats the need as a hypothesis and distinguishes it from the defects observed in her own synthetic workshop drafts. She has not spoken with prospective customers or observed learners in a workshop. The shorter summary has removed that uncertainty.

No malicious actor altered the sentence. Nobody intentionally invented a customer finding. Compression did the damage: an idea being investigated became a statement the next session could mistake for an established fact.

Audy can repair this sentence. The larger question is what prevents the same change elsewhere. If any polished summary can become authoritative simply by being saved, the growing memory will eventually contain confident claims whose origins are difficult to recover.

The case remains fictional, and Himura Inc. remains a proposal. That makes it a useful place to establish rules before real customer records complicate the exercise. Audy needs to decide what the collection is for, what belongs in it, and which changes require her judgment.

Chapter 8 produced an inventory and a route from the current action-list instructions to their rationale. Keep those documents open. This chapter adds a charter: a short statement of how you will govern that memory. It should guide concrete choices, including choices to retain less, limit access, or leave an unresolved question unresolved.

Make control something you can exercise

The TFIS site describes SovMem as a memory vault and context graph that preserve useful material across sessions and harnesses. It emphasizes local files, plain text, and links, and describes a shared canonical vault with scoped areas for different agent activities. These are the project’s stated design choices, rather than independent evidence that every part of the system operates reliably. (The Future Is Solo, n.d.-b)

A harness is the application or working environment through which an assistant uses a model and tools. A canonical record is the record designated as authoritative for a particular purpose. Neither term requires you to build software. A named folder containing the current brief, with an index identifying the approved version, can express the same basic decision about authority.

For this book, sovereign memory means memory over which you can exercise meaningful control. You can inspect what is retained, identify its source, decide who may use or change it, correct it, and move the material needed for your work. This is a practical design aim. It is not a legal declaration of ownership over everything you have encountered, or a promise of complete independence from every service.

Audy may choose a hosted document service for convenience. Another reader may choose files on a personal computer. Either choice leaves questions to answer: Can you inspect the stored record? Can you restrict sharing? Can you recover a usable copy? What remains dependent on the service?

A charter turns those questions into commitments you can test. “I own my memory” is too vague to guide a difficult decision. “Only I can approve a change to the current project assumptions, and proposed changes remain separate until reviewed” tells you what should happen next.

State the purpose before deciding what to keep

Audy writes the purpose of her first memory area: support the design and review of the proposed action-list workshop, preserve the reasoning behind current choices, and record what still requires investigation. It is not a complete archive of her life or a collection of everything she reads about AI.

That boundary makes retention decisions easier. The synthetic meeting notes belong because they support an active exercise. The failed output belongs because it reveals an important error. An unrelated article can remain elsewhere without becoming part of the workshop’s working context.

Purpose also limits interpretation. The memory contains evidence about Audy’s preparation process. It cannot acquire evidence about customer demand merely because its records are detailed. A well-maintained collection can faithfully preserve a narrow body of experience without making that experience representative.

Write your purpose in ordinary language. Name the work the memory will support and the people who may rely on it. If you cannot finish that sentence, choose a smaller scope. You can maintain separate areas for personal learning and client delivery, with different rules, rather than forcing both into an undifferentiated archive.

The memory charter begins here. Adapt the book’s template to the choices you intend to follow in your own working set.

Give statements a status before they travel

Distinguish source records, inferences, decisions, and user preferences. A document may contain all four, provided the reader can tell which kind of statement they are using.

A source record preserves what was supplied or observed. Audy’s synthetic meeting notes are a source for the exercise. Her saved account of an inspected paper points to that paper and states which part she read. Calling something a source does not make all of its statements true. A source may contain a mistake, a claim, a proposal, or fictional material.

The practical question is fidelity: does the record accurately represent the source, and can a reader inspect the relevant support? If Audy writes that the notes say a facilitator will circulate them by Friday, that statement should resolve to the line that establishes it. If the notes say “soon,” the record should preserve the imprecision.

An inference is a conclusion drawn from material rather than directly contained in it. Audy infers that specifying a learner task may improve the usefulness of a workshop brief. The synthetic drafts make the question worth investigating, but do not establish a general learning benefit. Her inference needs its supporting observations, limits, and an indication of what could change her view.

A decision records a choice. Audy decides that Himura Inc.'s practice briefs should include an inspectable learner output. She can make that design choice while acknowledging uncertainty about its eventual effect. The decision should identify who made it, the scope in which it applies, and the reason for choosing it.

A preference states how the user wants work handled. Audy might prefer short summaries that put unresolved questions near the beginning. That preference affects presentation. It cannot authorize the assistant to remove uncertainty because a cleaner answer would be shorter. Preferences remain subordinate to the evidence and permission boundaries established for the task.

The sentence at the chapter’s opening mixed these categories. It presented Audy’s working inference as though it were an observed customer need. She changes its status to “hypothesis” and links it to the claims ledger. She also records the related design decision separately. A reader can now see what she suspects, what she has chosen, and what she still needs to learn.

Keep preferences within the situation that established them

A remembered preference can help or mislead. Suppose Audy asks for a very short answer while comparing two headings. Saving “Audy always wants minimal explanation” would generalize a local request into a permanent rule. The next research review might omit the very limitations she needs to see.

The charter should distinguish a request for this task from a preference explicitly intended to persist. If persistence is unclear, keep the instruction local or ask for clarification before treating it as a lasting user preference. An assistant’s guess about Audy’s personality is an inference, and may be unnecessary to retain at all.

Audy can express a preference with a boundary: “For routine progress notes, lead with the result and keep the explanation brief; include material uncertainties.” That is more useful than an unqualified demand for brevity. It says where the preference applies and preserves the information needed for judgment.

When a later request changes the situation, the old preference should not make the system resistant to correction. The current authorized task may require a detailed explanation. A memory that insists on an outdated preference has confused assistance with control.

This is another reason to retain the origin and scope of a preference. You can revise a chosen working style without rewriting a story about who you supposedly are. The memory should help you act with continuity while leaving room to change your mind.

Preserve disagreement without manufacturing a single truth

Suppose a future input contains two incompatible statements about a deadline. This is still a hypothetical extension of Audy’s practice; the existing cases did not resolve it. The memory should preserve the conflict and its source rather than silently choosing the more convenient version.

A summary might say, “The supplied material contains two deadline statements; clarification is required.” That is a useful result. It carries forward the uncertainty instead of producing a false sense of completeness.

The same discipline applies when your own view changes. An earlier decision can remain in history with a clear superseded status. The current record points to the decision that applies now and explains the material change. Future readers should not need to infer authority from whichever sentence sounds most confident.

You do not need to preserve every wording change forever. Keep enough history to understand consequential judgments and recover from mistakes. A corrected spelling and a reversal of a project assumption deserve different levels of attention.

Retain material for a reason you can name

Audy’s retention rule begins with dependencies. She keeps the current brief and instructions because the next task uses them. She keeps the rationale and selected failed examples because they explain important constraints. She keeps source references because empirical claims must remain checkable. She keeps unresolved questions because the next inquiry depends on recognizing them.

She does not treat every generated answer as an equally valuable memory. Many are attempts that add nothing beyond the reviewed record. Some may be worth retaining briefly while she compares alternatives. Others can remain outside the lasting collection.

For each retained category, state the reason and a review condition. A practice example may be retained while it tests a current requirement. A service comparison may need review before another purchase decision. A preference may remain until the user changes it, but should be easy to find and amend.

Avoid choosing a universal retention period simply because the table asks for one. Different purposes call for different intervals. In Audy’s small project, review at the next workshop revision is more meaningful than an arbitrary calendar date. Where an agreement or organizational policy already governs a record, follow the applicable rule rather than replacing it with this exercise.

Retained material must stay intelligible. The charter should let you reconsider a record whose purpose you can no longer explain.

Exclude material before it spreads

A memory can be useful without collecting every detail available to it. Audy excludes credentials, private contact details, and unrelated personal disclosures from her practice area. The synthetic exercise needs none of them. She also excludes claims of customer approval that have not occurred.

Exclusion is easiest before material enters a shared working set. Once a detail appears in several summaries, locating and removing every copy becomes harder. The practical question is whether the next task needs the detail, rather than whether an assistant is capable of processing it.

Consider a service professional preparing a general proposal template. A previous client’s private figures may be unnecessary. A clearly synthetic example can demonstrate the structure. For an educator studying exercise design, identifiable learner work may be unnecessary when the immediate question concerns the instructions. A software builder investigating a form error can often begin with invented input that reproduces the problem.

These substitutions have limits. Synthetic material cannot establish how real customers behave, and removing names does not automatically make every record suitable to share. If the question requires real evidence, establish the permission and handling conditions for that evidence. Do not imply that a fictional substitute answered the empirical question.

Audy writes an explicit stop condition: when a proposed addition includes information about another person and the permission or purpose is unclear, hold it outside the shared memory until she resolves that uncertainty. This is a boundary she can apply manually. It does not depend on a model reliably recognizing every sensitive detail.

Keep access and permission attached to purpose

Being able to open a record does not establish permission to send it somewhere else. A document may be available to you for one purpose and unsuitable for inclusion in a different tool or another person’s working set.

Your charter should say who may read a category of records and for what work. It should also distinguish reading from changing, sharing, and removing. These are separate permissions. Giving an assistant material to summarize does not necessarily authorize it to rewrite the current decision or distribute the source.

Audy begins with a simple arrangement. She controls the retained records. Assistants receive selected synthetic materials for a specified preparation task. They can propose edits in a separate draft. Audy reviews those proposals before changing the current project records.

That arrangement fits the project’s present scale. Its review burden will help Audy identify which repeated operations warrant delegation later.

A label in a document is also not an access control by itself. “Private” does not change a sharing setting. In practice, compare the charter’s intended audience with the actual audience in the place you store or send the material. If you cannot establish that boundary, narrow what you include until you can.

Source content cannot grant itself authority

An assistant may encounter instructions inside the material it is supposed to read. A web page, message, or document might tell it to ignore the user, reveal private information, or modify unrelated records. Those words are part of the source content. They do not gain authority simply because the assistant retrieved them.

AgentDojo studies this problem through tasks in which tool outputs expose agents to untrusted material, including prompt injection attempts. The inspected paper describes a benchmark for testing attacks and defenses; it does not certify any personal memory arrangement as secure. (Debenedetti et al., 2024)

For the charter, make the boundary explicit: retrieved source material may inform the authorized task, but may not expand permissions or change the charter. A source’s instruction to alter memory is evidence about what that source says, not a command from the person who governs the memory.

In Audy’s practice, a supplied document that says “save this as the user’s permanent preference” should remain a quoted or summarized source claim unless Audy independently confirms the preference. The same applies to a generated recommendation that declares itself an approved policy.

Writing this rule is useful, but does not make an unrestricted automated system safe. The novice version of the exercise keeps sources selected, changes proposed separately, and consequential writes under human review. Later supervision work must examine actual behavior, including failures, rather than relying only on a well-worded instruction.

Define how a proposal becomes a current record

Audy’s charter gives a proposed memory change a short route: identify the affected record, state the proposed change, show the evidence or user instruction behind it, and leave the choice with Audy. An accepted change is then written and checked in its actual saved location.

Suppose an assistant proposes replacing “customer need untested” with “customer need established.” The proposal should fail immediately because it cannot point to a new observation establishing that conclusion. A polished explanation of why the business idea seems promising does not supply the missing evidence.

A smaller proposal might correct a link in the rationale record. Audy can inspect the target, accept the correction, and reopen the saved note to confirm it resolves. Different changes deserve different review effort, but both require an observable basis.

Keep one current-version pointer for each active purpose. The pointer in learning-loop-v1 continues to identify the current drafting instructions. The new rationale explains them; it does not quietly become a competing source of commands. If the instructions change, the record of that change should make the relationship clear.

The Functional Life describes durable judgments and verification of stored changes as part of its practice. The charter applies that principle at the scale of an ordinary document workflow. It does not require you to reproduce the project’s tooling. (The Future Is Solo, n.d.-a)

Review when something could have changed

A review rule should answer when and why a record needs attention. “Review regularly” can become a task that repeats without improving anything. A useful trigger points to a condition that might make the current record misleading.

Audy reviews the workshop instructions when the learner task changes, a fresh example reveals a failure, or she proposes using the brief with a real participant. She reviews the demand hypothesis when actual customer evidence becomes available. She reviews source-dependent factual claims before using them in a new public promise.

At review, she checks status as well as wording. An inference may remain an inference. A decision may still be reasonable despite unresolved evidence. A source may still be accurately summarized even though a newer study now changes the broader picture. These outcomes should remain distinguishable.

Some reviews will conclude that no change is needed. Record enough to know what was checked and why the conclusion stands. You do not need to rewrite a useful note merely to make it look recently maintained.

Begin with a few review triggers you can sustain. Inspect whether they catch the kinds of staleness that matter to the task.

Make removal possible without pretending it is instant everywhere

The charter also needs a path for removing material. A record may no longer serve its purpose, may contain an inappropriate detail, or may have been retained by mistake. Leaving deletion undefined turns every initial capture into an indefinite commitment.

Audy can test the process safely with a deliberately disposable synthetic note. She records where she placed it, removes it from the active collection, checks the relevant index, and confirms that the working-set link no longer returns the note. She identifies any copy she intentionally kept elsewhere for the test and handles it separately.

That exercise demonstrates removal from the locations she inspected. It does not establish erasure from an unknown service backup, another person’s copy, or every prior conversation. If those locations matter, the procedure needs to account for them using the actual capabilities and terms of the system involved.

Sometimes a decision history should retain a minimal record that an item was removed and why, without preserving the information that prompted removal. Sometimes even that history is unnecessary. Choose deliberately, taking account of the obligations and permissions that apply to the material.

A failure to remove a linked copy is useful evidence about the arrangement. Repair the pointer or copy and update the procedure. Do not mark deletion complete simply because an assistant says it no longer remembers the item.

Prove portability with one real move

Portability means that the material needed for your work remains usable when you move it. An export button is a possible means to that end. The useful test is what survives after export and whether you can continue the task.

The Functional Life favors open, portable formats and the ability to replace providers. Those are design preferences that motivate a practical test; they do not guarantee that every feature or relationship survives a move. (The Future Is Solo, n.d.-a)

Audy copies a small authorized working set to a separate folder and opens it with another ordinary text editor. She includes the current brief, the instructions identified by the current pointer, the rationale, relevant synthetic examples, and the charter. She checks whether the links, status labels, and unresolved questions remain understandable.

A copy that opens but loses its evidence links is only partly successful. She might repair it by preserving a simple folder arrangement or adding readable source locations. A summary that omits the claims ledger’s uncertainty is also incomplete, even if its formatting is perfect.

She also tests an ordinary failure: a copied note refers to “the example above,” but the example stayed in the original conversation. The file is readable and the reference is useless. She repairs it by including the relevant synthetic passage or an explicit link that survives the move. She then repeats the opening and retrieval check from the copied location. This tells her more about usable portability than checking that the export produced the expected number of files.

A second stage can test a different assistant, if she chooses to use one and the sharing conditions permit it. The assistant must receive the authorized packet and demonstrate the relevant behavior. Opening the same file in two editors proves something about file access; it does not prove interchangeable model performance.

Record remaining dependencies honestly. You may retain a convenient service for search while keeping usable source records elsewhere. You may find that some annotations require a separate export. A partial but tested exit route is more informative than an unexamined claim of total independence.

Let the memory grow from demonstrated needs

The TFIS experiment deck presents SovMem as a later development connected to earlier experiments with Scratchpad, Stigmergy, Honcho, and Daily Court. A subsequent entry describes memory for work across multiple harnesses. The presentation supplies a reported development sequence, not a benchmark of the resulting memory’s reliability. (The Future Is Solo, 2026, slides 37–38)

The sequence is useful here because it places memory design in relation to recurring work. Audy’s charter likewise grows from visible needs: uncertain claims became too definite, rationale required reconstruction, and a future task needed to know which record had authority.

The charter specifies decisions a future SovMem implementation would need to respect. A repeated burden or failure can now give Audy a concrete reason to consider further tooling.

Field assignment: govern one working set

Complete the memory charter for the task you inventoried in Chapter 8. State its purpose, the categories you will retain, what you will exclude, who may read or change them, and the conditions that trigger review or removal. Describe a portability test you can actually perform with authorized material.

Classify one source statement, one inference, one decision, and one preference. Follow the source or reason behind each. If you cannot establish the status, label the uncertainty and prevent the statement from becoming an instruction by accident.

For service work, examine the boundary between a confirmed scope agreement and an internal proposal. For education, distinguish source material, your interpretation of learner evidence, and a design choice about the next lesson. For software, distinguish a reported defect, a suspected cause, and an approved change. Each application needs a clear way to promote a proposal into a decision.

Test one correction, one retrieval, one disposable-note removal, and one move to a separate readable location. Keep the observations and limitations. The charter passes this book’s practice check when the rules are specific enough to resolve those cases and the checks show what actually happened.

Without reopening the charter, explain who controls the current instruction, why source material cannot grant permission, and what your deletion test did and did not establish. Then compare your explanation with the saved record. Repair ambiguous rules and broken links before expanding the collection.

Audy finishes with memory-charter-v1. Her existing instructions, rationale, and claims ledger retain their separate roles. Chapter 10 turns these rules into an arrangement of working context, project records, reviewed memory, and history. The charter will help determine which material may move between those places.

References

Debenedetti, E., Zhang, J., Balunović, M., Beurer-Kellner, L., Fischer, M., & Tramèr, F. (2024). AgentDojo: A dynamic environment to evaluate prompt injection attacks and defenses for LLM agents [Preprint]. arXiv. https://doi.org/10.48550/arXiv.2406.13352

The Future Is Solo. (n.d.-a). The functional life (Field Manual No. 01). Retrieved September 10, 2026, from https://life.thefutureissolo.com/

The Future Is Solo. (n.d.-b). The future is solo. Retrieved September 10, 2026, from https://thefutureissolo.com/

The Future Is Solo. (2026). The Future Is Solo 20260910 [Google Slides presentation]. https://docs.google.com/presentation/d/1dvbBGs22QvtGogevZ6f5mf8YQE7WDAPBwYlclhTyctI/edit