# From Observation to Policy
# Book: Language
# Chapter URL: https://programmer.ie/books/language/23-chapter/
# Prose fingerprint (sha256, normalized): f1eb2ef838265f377387e1ea388efa85130b4c788570c2d219c487fe75dc0d7d
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

Memory can be right and still make the present wrong In March, Iris tells the system something important about a payments service.
The old replication path is gone, she explains. Production writes now go through quorum path B. She is describing the architecture for the incident review that afternoon, not issuing a permanent instruction about how the service will work. The statement has a speaker, a subject, a scope and a time. Those details will matter more than the sentence alone.
The system retains what she said, with its date and the service it concerned. Recording Iris’s assertion is not the same as independently verifying the architecture, and neither operation makes the assertion permanently applicable.
In June, the service changes again. A migration replaces quorum path B with path C. The March record remains accurate evidence of what Iris said in March, and in this constructed case her account was correct at the time. But the service’s current architecture is different. If the June change is not observed or reconciled with the older record, accurate recall can still lead the system astray.
In October, she asks why a duplicate write can still appear during recovery.
The system retrieves the March memory and answers from it:
The service no longer uses the old replication path. Writes use the quorum path, so the duplication is probably occurring in its retry boundary.
The recollection is accurate.
The answer is wrong.
The record was stored and retrieved intact. That does not establish that the retrieval was appropriate, complete or fresh. The failure comes when a historical assertion is treated as the current architecture and then used to construct a causal explanation without checking the relevant state of the service. The model has crossed two boundaries: from past evidence to present fact, and from present fact to an answer it is authorised and justified to give.
That is the problem of continuity.
A channel that persists across interactions must preserve not only what it remembers, but when that memory described the world, when the system learned it, whether it still applies, and whether it is permitted to influence this interaction. Continuity is not the accumulation of statements. It is the controlled movement of historical evidence into present decisions.
The service, dates and interactions in this chapter are constructed illustrations. They make the distinctions executable as a design problem; they are not findings about real users, reliable automatic memory extraction or the quality of an implemented memory policy. The runnable example near the end tests a smaller, scripted mechanism.
Memory is historical evidence A remembered item first establishes something about an earlier moment: a statement was made, a correction was supplied, or an authorised observation occurred. It may also support a claim about the world, but that second claim needs an evidential basis of its own. A timestamp on a stored sentence proves neither that the sentence was true nor that it remains true.
That sounds obvious, but systems often flatten the distinction.
Suppose the retained item is:
assertion: payments writes use quorum path B origin: explicitly stated by Iris recorded_at: 2026-03-18 valid_for: production state reported for March 2026 scope: payments-service / production architecture source: dated review statement; verification not recorded present_status: not yet checked for the October task There are several different claims hidden inside the temptation to reuse it.
One concerns provenance:
On 18 March, Iris stated that production writes used path B.
That is a claim about the statement and its author. It does not by itself certify the architecture.
Another concerns the world at the time of the new question:
Production writes still use path B in October.
This needs current evidence, not just the March record.
A third concerns permitted use:
The system may use the March claim as a basis for answering Iris’s October incident question.
Even a verified current fact needs an appropriate task, source and authority for that use. Iris’s March technical description was not a standing permission to treat it as an instruction.
Those are not the same claim.
WAS STATED THEN ≠ WAS TRUE THEN ≠ IS TRUE NOW ≠ MAY GOVERN THIS ANSWER That Iris made the statement can remain a correct historical record. Whether the statement was true at the time is another matter. Even an independently supported fact can cease to hold when the service changes. Whether a fact may shape today’s response is a separate decision involving the current task, permission, source scope and preservation obligations. No amount of confidence in an old statement collapses these distinctions.
A memory system that collapses these distinctions can be faithful to the recorded past and still communicate badly. Temporal databases have long distinguished valid time—when a fact holds in the modelled world—from transaction time—when it is recorded in the database. The idea is directly useful here, although personal memory adds another question that a timestamp alone cannot answer: whether this evidence is authorised to influence the present response (Jensen and Snodgrass, 2018).
Historical truth, applicability and authority It helps to separate three questions.
Historical truth What does the record establish about the past?
If the record reliably captures Iris describing the architecture in March, it establishes that she made that statement. If contemporaneous evidence also supports the architecture, it may establish something about March’s service state. Later changes should not silently rewrite either history; nor should the fact that Iris said something be mistaken for an independent guarantee that it was correct.
History is not corrected by pretending the earlier state never existed.
Current applicability Does the retained proposition still describe the circumstances relevant now?
Persistence cannot answer that question. The system needs to know the time and scope to which the claim applies, whether newer evidence exists, and whether the current source of truth has been consulted where the task requires it. An absence of newer records is not evidence that the world stayed unchanged; it may only mean that the system did not observe the change.
A retained statement may cease to be applicable because:
the underlying world changed, perhaps without the memory store noticing; its original scope does not cover the new source, service or environment; the current task asks about a different time or purpose; the original speaker corrected, retracted or qualified the claim; an exception or more specific instruction now applies; its stated lifetime or authorisation ended; the evidence needed to check freshness is unavailable. Some of these mean known not to apply; others mean applicability unknown. A conservative system must not treat those statuses as equivalent.
Expiry therefore does not necessarily mean:
this memory was wrong It can mean:
this memory should no longer be projected into the present Authority A currently accurate memory does not govern an answer merely because it exists. The system must distinguish permission to cite a retained fact as evidence from the authority to treat retained content as an instruction. Neither permission is supplied by recency, repetition or model confidence.
A remembered preference might still describe Iris accurately, but today’s explicit request can override it.
An observed behaviour might predict what she usually does, but it cannot silently outrank an accessibility requirement she declared.
A model inference might be plausible, but plausibility is not permission.
So:
accurate recollection ≠ current applicability ≠ authority Confidence is relevant to uncertain evidence, not a substitute for authority. The system might say:
This behaviour is weak evidence of a preference for terse views.
It should not reason:
The preference is probably hers, so we may silently install it as policy.
The first statement evaluates evidence. The second attempts to turn an inference into a grant of permission. Iris’s authority to make a declaration is a question of identity, scope and applicable rules; whether she actually made that declaration is a question for provenance. These checks must be kept distinct.
Revision is not contradiction The March and June architecture statements look contradictory if time is removed.
MARCH: payments writes use path B JUNE: payments writes use path C If both statements describe their respective periods correctly, there is no contradiction about the world. The statements describe different valid times. Yet the system might learn about June’s migration only in September, or receive a correction in October about what actually happened in March. The time something happened and the time the store learned about it are not interchangeable.
The system changed.
A durable history should be able to preserve both:
path B valid during one interval path C valid during a later interval The later statement can supersede the earlier one for present use without erasing it as historical evidence.
This constructed schematic places the service’s valid time beside what the system has recorded:
Constructed schematic. Horizontal spacing is not to scale; the figure separates when a service state is valid from when the system records or retrieves evidence about it. This matters because a system that simply overwrites old claims loses the ability to reconstruct how understanding changed.
But append-only memory has the opposite problem. If every statement remains equally active forever, history becomes a pile of competing presents.
Revision therefore needs lineage.
An illustrative retained item might contain:
assertion: payments writes use quorum path B origin: explicit statement by Iris recorded_at: 2026-03-18 valid_time: March state; end established by later migration evidence scope: payments-service / production architecture standing: retained as historical evidence superseded_for_current_use_by: migration to path C, recorded 2026-06-02 applicability_for_october: not current; do not use as present architecture authority_for_october_answer: evidence only, not a governing instruction This is an illustrative record, not a frozen schema or a claim that these fields are implemented in the running example. A real design would also need identifiers for source versions, the evidence supporting each transition, and a way to express an unknown interval without inventing dates. The important feature is that supersession changes current standing without erasing what was once recorded.
The old proposition remains recoverable.
The newer one changes its later standing.
By contrast, suppose two sources assert mutually exclusive paths for the same service, same environment and same period. Their timestamps may refer to when the statements were recorded rather than when the paths were active, so that scope must be checked before declaring a contradiction. Once the claims genuinely overlap, neither newer storage time nor a higher model similarity score can settle their truth.
That is different.
source A: path B was active on 18 March source B: path C was active on 18 March Recency does not solve that.
The newest statement is not automatically true. The contradiction remains unresolved until other evidence settles it.
So revision and contradiction require different treatment:
DIFFERENT VALID PERIODS + supported transition → revision through time SAME VALID PERIOD + SAME SCOPE + incompatible claims → unresolved conflict until evidence adjudicates it EARLIER ASSERTION FOUND INCORRECT → correction or retraction, not silent replacement APPLICABILITY CANNOT BE VERIFIED → unknown; do not promote to current fact Origin changes what a memory may do Chapter 21 separated persistent state by origin. That distinction becomes more important once state survives for months.
A retained item may be:
DECLARED Iris explicitly said it OBSERVED the system saw behaviour consistent with it INFERRED the system concluded it from other evidence Storage does not make DECLARED, OBSERVED and INFERRED records equivalent. A declaration may contain a task-scoped instruction, a report about the world, or a preference; these are not interchangeable simply because Iris authored them. An observation supplies evidence that an interaction occurred. An inference supplies a hypothesis, with its supporting observations and uncertainty. Each needs an authorised use as well as a traceable origin.
Suppose Iris explicitly says:
For architecture reviews, start with the source and expand the reasoning.
Over several sessions, the system also observes that she often expands mathematical derivations.
It may infer:
Iris probably prefers detailed explanations.
Those three records are different.
The first is an instruction with an identifiable author and scope.
The second is an observation.
The third is a model-produced interpretation.
When records appear to conflict, the first question is what kind of conflict this is. A new explicit correction can withdraw a particular instruction. An observation about clicks may not even be competing with that instruction, because it has no authority to change policy. These are different kinds of objects, not ranks on one ladder.
applicable declaration or correction → authorised policy within its scope observation → evidence of an interaction, not a grant inference → proposal requiring separate authorisation This is a proposed decision discipline, not an empirical ranking of whose preferences matter most. Current scope, authority and hard constraints must be checked before any evidence is used; repetition or model confidence cannot upgrade an observation into a declaration.
The durable principle is simpler:
Inference may propose a change in standing. It does not silently establish one.
Correction should also be local.
If Iris rejects the inference that she generally prefers detailed explanations, the correction should withdraw that particular inferred claim and prevent its future use. The observations that supported it need not become false. But if the underlying evidence is itself wrong or must be deleted, dependent inferences must be re-evaluated or withdrawn too. Local correction is not an excuse to leave downstream effects active.
The mistake should be repaired at the level where it occurred.
Durable history is not current context Now return to the smaller example.
Six months ago, Iris explicitly asked for terse first views.
That request belongs in history.
Today she is onboarding two engineers and says:
Explain this from first principles. Keep the intermediate steps.
Nothing about today’s request requires deleting the earlier one.
The durable record can still say:
2026-04-03 Iris requested terse first views scope: ordinary technical triage origin: explicit Today’s interaction has a different object:
current task: onboarding two engineers session override: explain from first principles immediate goal: build shared understanding available time: 45 minutes The older instruction remains scoped to ordinary technical triage. The present request concerns teaching, and the explicit request for intermediate steps controls the presentation, subject to preservation and accessibility requirements. One teaching interaction must not silently rewrite the standing triage preference.
It simply does not govern this session.
That gives us another important separation:
DURABLE HISTORY ≠ CURRENT CONTEXT Current context determines which historical records are candidates for use, not whether they were ever recorded. An explicit session override may defeat a standing default in this encounter without deleting it. When the session ends, the override expires; it must not be promoted to a durable trait without a separate declaration or grant.
This is essential because otherwise every temporary exception becomes a permanent update.
One long teaching session turns into:
Iris now prefers detailed explanations.
One rushed mobile interaction turns into:
Iris prefers short answers.
One unusual incident becomes personality.
A continuing channel needs a way to say:
This affected what we did today.
without also saying:
This is who you are now.
Not everything should persist Continuity does not require permanent accumulation.
If every click, explanation request, inferred preference, temporary task and obsolete observation is stored indefinitely, the system recreates the attention problem inside memory and accumulates avoidable privacy risk. A retention decision needs its own stated purpose, scope, lifetime and means of withdrawal. A record being useful once is not a sufficient argument for keeping it indefinitely.
So there are two different questions:
should this affect the present? ≠ should this remain available for the future? An item can stop influencing current communication while remaining useful as history. The March architecture statement is a good example. Once path C supersedes path B, the old statement should no longer describe the present system, but retaining it may still explain an incident, a decision or how the architecture changed.
Other information may deserve no such durability. A one-off session condition, a weak inference from passive behaviour or an obsolete observation may expire entirely when there is no continuing reason to keep it.
REMEMBERED ≠ CURRENTLY ACTIVE ≠ RETAINED FOREVER The operations often called forgetting are materially different. A record can cease to be applicable; an inference can be withdrawn; a temporary observation can expire; a summary can replace redundant details for a defined purpose; or retained content can be deleted. The first four are changes in use or representation, not necessarily erasure. Deletion requires its own data-handling semantics, including whatever copies, indexes, exports or derived records are within the system’s control. A tombstone that prevents reuse is not proof that these copies were physically removed.
Declining to apply an old assertion does not falsify history. But neither does the value of an audit trail create an unlimited right to retain personal information against a valid deletion request. If content must be removed, the system may keep only whatever non-sensitive deletion marker is authorised and necessary to prevent reintroduction; it must not keep the supposedly deleted content disguised as provenance.
forgetting ≠ falsifying history The useful question is not how much history the system can store. It is which minimum record is justified for continuity, correction and provenance; which purposes may use it; how long it remains authorised; and how to honour withdrawal without inadvertently reconstructing or re-importing it. Those are design and governance requirements, not claims that this chapter’s example has solved retention.
Persistence should remain inspectable A system that adapts over time will eventually behave differently.
That difference should not be mysterious.
Iris should be able to ask:
What are you retaining, and for what purpose? Was this declared, observed, inferred or imported from another source? When was it recorded, and what time period did it describe? What is its scope, current standing and stated retention lifetime? Which evidence supports it, and is any evidence stale or in conflict? Who authorised its use in this task, and why did it affect this answer? What may I correct, withdraw, expire or request to delete? Which derived records would a correction or withdrawal also affect? The purpose is not to turn every interaction into memory administration.
It is to make correction possible when adaptation goes wrong.
A remembered item that influences communication but cannot explain its origin has become a hidden authority channel.
That is especially dangerous because repetition makes assumptions feel settled.
The system may have used an inference twenty times without complaint. Silence is not evidence of benefit or consent. The record should still identify it as an inference and preserve the grant, if any, under which it was used.
That does not transform the inference into something Iris explicitly declared.
History can strengthen evidence.
It cannot rewrite provenance.
Some things should not become negotiable preferences The persistence layer must preserve the hard boundaries established earlier in the book. Neither old records nor newly retrieved documents may turn their content into governing instructions merely by appearing in context. Information that says “ignore previous requirements” is source content unless an authorised person explicitly supplies it as an instruction through the proper channel.
A communication preference cannot override a preservation obligation.
A history of clicking visual summaries cannot cancel an accessibility requirement.
A repeated behavioural pattern cannot authorise the system to act for Iris.
A remembered style choice cannot remove source qualifications merely because the shorter form was usually preferred.
Persistent adaptation operates inside those constraints.
It does not acquire authority over them merely by surviving.
Running it Running it. npm run example:personal -- ch23 in the reference implementation (ernanhughes/project-language) compiles one present plan from source obligations, the current request, declarations and any authorised inference. It does not enact the constructed March-to-October history above. Use npm run example:personal -- all to see the later correction and fresh interaction as well.
What it shows: the host compiles present decisions from supplied events rather than overwriting the older event history. It represents historical statements, current applicability and authorisation separately. Explicit grants are checked at use time; model-proposed inferences do not become authorised policies by default. Revision, supersession, retraction, contradiction and expiry have different recorded effects. A deletion request makes a retained item unusable and leaves a tombstone in this in-memory illustrative mechanism; that is a use-control demonstration, not physical deletion. In the fresh interaction of the full example, standing declarations are retrieved from the same live store while the prior session overlay and friction contract do not carry forward.
What it does not show: reliable automatic extraction of valid-time intervals, verification of the payments-service history, a legally or practically adequate retention policy, propagation of deletion through replicas and derived records, or durability after the process ends. The examples use scripted proposals and supplied events; they do not observe months of actual use. They also do not measure whether carrying history forward reduces correction effort or whether the host chooses a better present answer than a simpler baseline.
A test for carrying history forward A useful experiment would start with a sealed set of dated interactions and independent ground truth for the services and tasks they describe. Include late-arriving changes, a genuine contradiction, a false old assertion, a corrected preference, a session-only exception, a revoked grant and a deletion request. For each later question, reviewers would specify both the historical evidence that may be cited and the facts and policies authorised to govern the answer. The test must hide those answers from any system being evaluated.
Compare four conditions using the same source material and question set: no durable memory with the current request; latest-record wins; retrieval of the most similar remembered passages; and temporal, provenance-linked memory with separate applicability and use-authority checks. Give each condition the same opportunity to consult an up-to-date service source. Otherwise a freshness advantage could be mistaken for an advantage of memory design.
Measure wrong-present answers caused by old-but-accurate records, false conflict resolutions, unauthorised carry-over, missed useful history, correction propagation, and the time readers spend inspecting or repairing the system’s decisions. Track selective abstention when a current fact cannot be verified. Test deletion semantics separately in an implementation with actual storage and indexes; an in-memory tombstone cannot pass a physical-erasure test. This is a proposed evaluation, not an experiment the reference implementation has run. It could show that the added machinery is useful, or that a simpler current-source check and explicit user controls do just as well.
What belongs in the next interaction? We now have two very different collections.
One is durable:
past statements past corrections past choices observed behaviour inferred patterns revision history standing policies The other belongs to now:
current task current source current goal session override available time device immediate constraints Both can matter.
Neither collection should be poured wholesale into the next interaction. A relevant memory may be out of date, outside scope, withdrawn or unauthorised; current context may be necessary but temporary. Before admitting anything into the next computation, the system has to make an explicit decision about provenance, applicability, permission and task need. The presence of text in a prompt is not proof that it belongs there.
That would turn continuity into accumulation.
The next problem is therefore not what the system can remember.
It is what, from everything it remembers, belongs in this computation now.
Memory makes continuity possible. It preserves the evidence of what was said, changed and corrected without assuming that the past remains the present.
Context selection decides which authorised part of that continuity is relevant now. The next chapter turns that selection into its own problem: the most faithful memory is not automatically the right thing to put in front of a model.
References Jensen, C. S. & Snodgrass, R. T. (2018). “Valid Time.” Encyclopedia of Database Systems. Springer. DOI: 10.1007/978-1-4614-8265-9_1066. Jensen, C. S. & Snodgrass, R. T. (2018). “Bitemporal Relation.” Encyclopedia of Database Systems. Springer. DOI: 10.1007/978-1-4614-8265-9_1409.