# The Person Changes During the Day
# Book: Language
# Chapter URL: https://programmer.ie/books/language/25-chapter/
# Prose fingerprint (sha256, normalized): 80a3c68f1f2a7dd979ea32d49cd03b9b4554dd31784cb5bcfe834601f93540f8
# 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.

Iris opens the system on her phone before an architecture review and says: I have five minutes before the meeting. Just tell me what can break. She is asking for a different first view. She is not withdrawing her interest in the implementation, and she is not authorising the system to guess what she can safely ignore. Five minutes is her stated time budget for this one encounter. It is not a measure of her attention span, and it is not a standing preference for short answers.
Her standing policy asks for implementation detail and equations when they affect the decision. Yesterday, at her desk, that meant a full account of the recovery path. Today, showing that same account first might use up the time she has. But a short answer that leaves out the condition under which recovery can duplicate a write would be worse. She could leave the meeting with a fluent answer and a false sense of safety. Brevity is useful only as far as the decision requires her to know.
The channel, meaning the part of the system that decides what to show and how, has to change what it presents without treating this moment as a new fact about Iris. It can put failure risks first. It can keep each decisive qualification next to the claim it limits. It can keep the source-linked derivation easy to open. If the constraints cannot be explained safely in five minutes, the channel should say so and offer the next useful view. The time budget does not give it permission to invent a simpler answer. Tomorrow, when Iris asks for the full derivation, today’s urgency must not govern that request.
These are constructed scenes, not measured outcomes. They raise the question this chapter addresses:
How should temporary conditions alter communication without becoming durable properties of the person?
Chapter 24 separated the historical evidence held in memory from its current applicability and authority. The same discipline now has to work on a much shorter timescale. A standing policy, facts about this interaction, and the rendering decisions made from them are three different things. The distinction resembles a long-standing concern in context-aware computing, which is information that describes a situation. It does not mean that sensing context reveals a person’s motives, or that using context improves outcomes. The extra question here is narrower: which contextual inputs is the channel authorised to use?
durable history ≠ current context ≠ session overlay Communication policy can persist. A temporary presentation decision should expire with the condition that justified it, unless the person explicitly authorises a longer-lived rule.
Context describes the present Current context is information about this interaction that can legitimately affect how the system communicates. It is not everything a device could detect. Each input needs four things: an origin, a permitted use, a scope, and a reasonable freshness condition. Some inputs are declarations Iris makes. Some are observable circumstances she has allowed the system to use. Some are hypotheses that must stay labelled as hypotheses. An input can be temporary without being a personal fact.
declared current task, objective, available time, temporary mode observed device or interface constraints, when use is authorised inferred possible task or stage, labelled and correctable checked source, scope, freshness and permitted use for each input In this scene, Iris declares the task, the five-minute budget, and the objective of finding failure risks. The phone interface supplies a screen constraint only if the application is authorised to use it. The phone does not establish that she wants less evidence. “Audio only” would be an output requirement if she declared it. “I am scanning before the meeting” would identify the stage of her work. These are narrow facts about this encounter, and their different origins should stay visible.
The origin of an input determines what the system may conclude from it. A small screen limits how much evidence can be shown at once. It does not give the system a reason to leave out a qualification. An open document may show which source Iris is reading. It does not reveal her purpose. Calendar access, device signals and activity histories are not automatically allowed just because software can read them. When an input is missing or withheld, the channel should use the generic representation suited to the task. It should not quietly treat the absence of information as if it were a fact.
The channel can offer a tentative reading of the task, based on authorised and visible work. Two API descriptions open side by side might prompt: Comparing these interfaces? Iris might instead be collecting examples. Until she confirms, the reading must be shown as a guess. It can be corrected, and it can be used only for a low-stakes presentation choice that is easy to reverse. It cannot override her stated objective, trigger an action outside the system, or become a standing memory. A stale guess from an earlier tab or task is not part of today’s context.
inferred task ≠ inferred inner state The chapter excludes a different kind of input:
inferred mood inferred stress inferred fatigue inferred motivation personality-state guesses A pause can have several explanations. It does not establish stress, cognitive overload, or a need for reassurance. A request for brevity is an instruction about this answer. It is not a diagnosis of impatience. Iris can ask for a slower explanation, larger text, or a more direct answer, and the system does not need to infer any psychological category to respond. If she herself declares a constraint that the application is authorised to use, that declaration can shape the current view. It still does not become an enduring trait.
This keeps the earlier boundary intact. Observing a condition is not the same as knowing someone’s inner state, and observing a condition does not automatically permit using it. The channel needs an adequate account of the task and of the presentation constraints it is allowed to apply. It does not need an account of Iris’s personality. If the system cannot tell what task it is serving, a visible clarifying question or a neutral view is better than confident adaptation.
Same words, changed context Consider two further constructed statements from Iris: “I don’t want detailed explanations today.” Later she says, “Explain this implementation in full.” These need not contradict each other. The first states a preference with an explicit time limit and possibly a narrower task scope. The second is a later, specific instruction. Neither one establishes a lasting dislike of detail. If the scope of the earlier statement is unclear, the system can ask rather than invent a permanent rule.
The Understanding Compiler could propose these acts, their scopes and their times. It should keep track of which parts come from Iris’s statements and which come from its own inference about where those statements apply. A meaning diff should keep the original statement fixed. It should identify the newly admitted task or later instruction separately. Reinterpreting the first statement in light of the later context is a new interpretation event. It does not change what Iris said earlier. A change in reading that comes only from the model also needs its own provenance record.
The proposal may inform the session overlay. It must not silently become durable memory, identity, or authority. Keeping an interpreted preference requires a separate purpose, scope and permission. Corrections must reach every use that depends on the preference. Classifying these sentences does not show that adapting to them improves Iris’s decisions or produces long-term benefit.
The overlay decides what changes Context does not decide on a representation by itself. Five minutes is a constraint. Putting risks first is a rendering decision. Dropping an essential caveat would be an invalid decision. The session overlay is a bounded record of the decisions made for this one encounter. It is built from four sources: the standing policy that applies, the authorised current context, any explicit temporary instruction, and the requirements that must always be met for preservation and accessibility. The overlay is neither raw sensor data nor a new policy about Iris.
standing policy + authorised current context + explicit temporary instruction + preservation and access requirements ↓ scoped, inspectable session overlay ↓ validated view for the current encounter For Iris’s review, the distinction can be shown in a small worked example:
Standing policy (declared; applicable to technical reviews) preserve implementation detail show equations when they affect the decision Current context (for this encounter) task: architecture review (declared) available time: five minutes (declared) device: phone (authorised interface observation) objective: identify failure risks (declared) Temporary instruction "Just tell me what can break" (declared, this review) Session overlay (derived, not a new standing rule) first view: failure risks and their governing qualifications supporting derivations: folded, source-linked and expandable if no safe short view exists: say so rather than omit evidence expires: review ends or session closes, whichever is first explanation: risks first because of the stated time and task The overlay explains why this view starts with risks. It does not claim to know what Iris generally likes. Each resulting claim stays tied to its source and to its qualifications. Someone checking the decision can tell apart three things: the inputs Iris gave, the device constraint the application used, and the rendering choices made from those two. Nothing in the overlay turns a guess about Iris into a declaration.
If she asks to expand one derivation, that new request governs the current view. If she changes device, finishes the review, or says the five-minute limit no longer applies, every presentation choice that depended on those facts must be reconsidered. A cached summary, a partly generated answer, or a queued rendering should not keep its authority just because it was valid a moment earlier. The overlay is a derived view of current conditions. It is not a second standing policy.
Temporary instructions have bounded authority Iris’s immediate request can override her usual presentation default for this task. It cannot remove necessary evidence, accessibility requirements, or source boundaries. Being in a hurry does not give the system permission to notify colleagues, change a deployment, keep extra records of her behaviour, or act on her behalf. Permission to change how something is shown is separate from permission to take action, even when an urgent instruction mentions both.
Within those limits, one possible order for choosing among allowed presentations is:
hard gates: permitted inputs, source preservation, accessibility ↓ applicable explicit instruction for this task ↓ applicable explicit mode and standing declarations ↓ permitted current constraints and corrected task hypotheses ↓ neutral task-appropriate fallback if the inputs conflict This is a proposed procedure for resolving conflicts. It is not a priority scale that has been established by evidence. Explicit instructions can conflict with each other. An earlier show all equations and a later give me the risk summary have to be reconciled by their scope and by what the request actually asks for. Averaging their strength does not settle it. An observed constraint cannot override a declaration by presenting itself as an instruction, and an inferred task cannot claim the authority of an instruction. When an authorised choice is both ambiguous and consequential, the channel should ask. The overlay records the decision and its basis. It does not grant an independent permission to make the decision.
Suppose the standing policy calls for relevant equations, but Iris asks for a short risk summary. If a relationship between retry conditions and duplicate writes determines the correct answer, the summary must keep that decisive condition. It can keep it in words, in an equation, or in another form that is clearly adequate. Supporting derivations can be folded away. The limiting assumption cannot. If the system cannot keep the assumption at the requested level of detail, the right response is to say so and offer a safer, expandable account. It should not turn a conditional claim into an unconditional assurance.
The key boundary is this: a current constraint changes how preserved content is made available. It does not decide that the content has stopped mattering.
Lifetime follows the declared scope The overlay needs an end condition as well as a source. “For this review” names a task boundary. “Until this incident closes” names an event whose completion may need to be confirmed. A timer can serve as a conservative backstop, but it does not prove the event has ended. A usable record therefore names its session, the condition that triggered it, the rule for expiry, and what to do if the end cannot be verified. When the status is unknown, a temporary override should not extend itself silently.
Within an active session, the adaptation should end when its stated task or condition ends, when Iris withdraws it, or when a stricter session boundary is reached. Moving from review preparation to study is a change of task, even if the app is still open. If Iris means “until I say otherwise” to last beyond the current session, the system should ask whether she wants an explicit standing rule. It should not reinterpret a temporary request as one. A one-off override must have a visible, bounded lifetime.
A new session gets a newly derived view. Closing the old session does not give its overlay authority in the new one, even if the app restores tabs or reloads a cached page. A still-active incident may supply relevant context again. But a continuing temporary instruction needs a clearly authorised scope that covers the resumed work. The same principle applies across devices. Syncing a standing declaration is not the same as copying a phone-specific time limit onto a desktop session.
The default route for an ordinary session condition is therefore:
current context → used in the current interaction → expires with its scope The overlay does not need to be promoted into durable personal memory before it can shape the present view. At the same time, “not retained as personal memory” does not mean “never recorded anywhere.” Ordinary diagnostics, security logs and cached outputs may leave technical traces. Those stores need their own permissions, retention controls and access limits. The claim here is narrower, and it can be tested. Unless a separate authorisation exists, temporary context and anything derived from it must not gain standing authority over future communication.
Shedding must include the effects The governing rule is:
A temporary communication condition must never silently become a durable property of the person.
When a session ends, deleting an object labelled overlay is not enough if its effects can still shape later policy. The more subtle route runs through observations that look useful. The system changes the view. Iris responds to the altered view. A learner then treats that response as evidence of a lasting preference. A history of choices made under an imposed format is not an independent sample of how Iris would choose to communicate.
The following proposed risk-and-control path is a design sketch. It is not a reported behavioural finding.
flowchart TD accTitle: Temporary overlay feedback and expiry accDescr: A temporary session overlay changes presentation. If behaviour is recorded with permission, its overlay context remains attached. An inference stays a proposal until Iris explicitly accepts a scoped rule. When the overlay expires, dependent views and plans are invalidated before a later session is derived from current inputs. OVERLAY["Temporary session overlay"] --> VIEW["Presentation changes"] VIEW -->|"If recording is authorised"| OBS["Behaviour observed with overlay provenance"] OBS --> INFERENCE["Possible inference proposed"] INFERENCE --> ACCEPT{"Iris explicitly accepts a scoped rule?"} ACCEPT -->|No| NOCHANGE["No standing-policy change"] ACCEPT -->|Yes| RULE["New declared rule with scope and lifetime"] OVERLAY -->|"Session ends or overlay expires"| INVALIDATE["Invalidate dependent views and plans"] INVALIDATE --> NEXT["Fresh session: current inputs and applicable standing policy"] Only Iris’s explicit acceptance creates a standing rule. Expiry separately invalidates dependent views and plans.
Suppose Iris chooses a deep-study mode for one session. The channel expands its explanations and leaves the derivations open, and she spends longer reading. A later learner might read that reading time as evidence that she generally wants long answers. It would be forgetting that the system itself made long answers the default for that session. The observation is confounded by the presentation policy that produced it. Even an accurate record of reading time cannot, by itself, justify a new personal rule.
If behaviour observed under a temporary mode is deliberately and legitimately kept, the stored record must identify the mode, the presentation that prompted the behaviour, the scope, and the permission for later use. Such evidence can support a proposal. It cannot trigger an automatic policy update. If keeping or promoting the data was not authorised, a downstream learner must not use it as a signal of a standing preference. The design has to enforce this boundary on the path from events to learning. Removing the user-interface overlay is not enough.
overlay removed ≠ overlay left no durable residue For an interaction that authorises no lasting personal change, the intended result is precise. After expiry, no temporary input or derivative may be treated as an active standing rule, and no dependent plan remains valid for reuse. This does not promise the physical erasure of every operational log or cache. It does require a fresh authority check before any retained event can influence a later representation.
Return to Iris the next morning. She is at her desk and asks for the full recovery derivation. The view must be built from today’s instruction and from the standing policy that still applies. Neither yesterday’s phone constraint nor the learner’s reading of yesterday’s behaviour may shorten it. A regression test should resume the session, reopen a cached view, and replay the path from observation to learning. Checking only that an overlay record was deleted would miss the failure.
That is the chapter’s key failure test. Expiry has to be checked along two paths. The direct path asks whether the overlay still shapes a later view or survives in a cache. The indirect path asks whether its effects have entered retained events, inferred knowledge, or a future policy proposal. The constructed scene makes both paths concrete. It is not evidence that the current implementation closes every one of them.
Conceptual guide to the chapter; no new empirical result is asserted. Open full-size diagram. A standing rule needs a separate decision Iris may eventually want a temporary instruction to last. She might say: For incident reviews, make the risk summary my default. That is a new declared policy. It has its own origin, task scope, start time and correction route. It can replace a broader presentation default within its scope. It cannot retroactively turn earlier temporary behaviour into an instruction she had already given.
The channel might propose a scoped rule after she has made similar requests several times. But repetition can only be counted in records that were deliberately kept for an authorised purpose. Counting discarded overlays would defeat the whole premise. Even authorised observations may reflect one interface or one situation. So the system should show the actual examples behind a proposal, and should not present frequency as proof of a stable preference. The cost and intrusiveness of asking should count against proposing the rule at all.
If an appropriate record supports the question, the proposal can stay small:
You have asked for risk summaries in these incident reviews. Make that a standing rule for incident reviews? [yes] [no] [don't ask again] The question should be rare, easy to dismiss, specific, and easy to reverse. Yes creates an explicit, scoped standing declaration. No creates no new presentation rule. Don’t ask again stops further prompts for that proposal within its declared scope. A refusal must not turn into a weaker signal while automatic learning continues toward the same result. Keeping a record of a refusal also needs limits. Declining a proposed rule should not require Iris to accept unlimited behavioural profiling.
Asking is a possible mechanism. It does not show that correction becomes less burdensome. Its purpose is to make the origin of a durable rule unmistakable: Iris chose it. The temporary adaptation and the standing-policy update are separate operations.
A proposed test of session-bound adaptation The claim can be tested without first building an unrestricted model of the person. Start with a small set of source-grounded architecture questions, each with critical qualifications that have been checked independently. Give participants repeated encounters: a short mobile review, a longer desk session, a switch of task, and a return the following day. Compare four conditions:
a fixed, task-appropriate view; reader-controlled expansion with no automatic overlay; an overlay driven only by explicitly declared constraints; an overlay that also uses separately authorised observable context. Keep the source, the tasks and the preservation obligations the same across conditions. Counterbalance the order of the encounters.
Evaluate decision correctness, missed qualifications, time and interaction cost, unwanted format changes, corrections, and failures to return to the standing view. Audit the resumed session, cached views, queued rendering jobs, and any permitted path from observation to learning. Look for any leakage from an expired overlay. Test conflicts, revoked permissions, unknown expiry, a change of device, and a switch of task. Record how often the system has to ask rather than guess. A shorter answer or fewer taps would not establish benefit by itself. An elegant demonstration would not establish that every downstream consumer of session state respects the boundary. This is a proposed study, not a reported result.
Running it Running it. Run npm run example:personal -- ch24 in the reference implementation (ernanhughes/project-language), and npm run example:personal -- all for the ending. Its review has a ten-minute overlay. It uses a separate fixture from the five-minute phone scene above.
What it shows: a scripted ten-minute overlay has a recorded source, scope, session and end condition. It changes a presentation plan while keeping the decisive equation and assumptions. Expiry invalidates known dependent plans and records, including indirect dependencies, instead of only changing a visible label. Behaviour recorded under a temporary condition keeps that condition as provenance. Changing standing policy requires a separate human decision. In the full scripted run, the overlay ends without changing the standing declarations. These are behaviours exercised by the supplied fixtures. They are not observations of Iris.
What it does not show: real-world detection of changes in context, or any inference about mood, fatigue, motivation or cognitive state. Those are intentionally excluded. The model is scripted, and the condition is supplied rather than sensed. The example does not establish that every cache, event consumer or learning path has been invalidated. It does not establish that the proposed conflict-resolution procedure is correct, that no technical record survives, or that readers benefit. The five-minute phone scenario and the runnable ten-minute fixture are separate illustrations.
What changed this view? The channel should explain the actual decision. It should not build a persuasive story after the view has already been rendered: You asked for failure risks before the meeting. I put those first for this review, kept the qualification that governs each risk, and folded the supporting derivation. This view will revert when the review or session ends. The explanation should come from the recorded inputs, the rule that was applied, and the resulting view. It should also show which inputs were declared, which were observed with permission, and which were only proposed.
The explanation identifies the source, effect, scope and lifetime of the choice. Iris can correct it: Keep the derivation open for this risk. The change applies to this view unless she explicitly makes it permanent. If the system cannot recover the provenance behind a presentation decision, it should not claim to know why the view changed. Stating what it does not know is better than inventing an explanation or inferring a personal trait.
The explanation must stop describing the current view when the overlay ends. A new view needs a new decision record. An old record can still explain past output, but it does not govern new output. Durable policy supplies continuity. Authorised current context supplies responsiveness. The overlay connects the two for a bounded interaction. The boundary to test is not just whether Iris sees a different page tomorrow. The real question is whether the expired state has lost its authority everywhere it might influence that page.
One question remains. A session overlay can make an answer fit today’s task, yet the easiest next click may still conflict with a longer-lived goal that Iris explicitly declared. She may have asked to finish one paper before starting another, while a stream of related results makes switching tempting. That is not a reason to infer what she really wants. The next chapter asks when the channel may introduce a pause or reminder on the authority of a declared goal, and how Iris can reject it.
References Dey, A. K. (2001). Understanding and Using Context. Personal and Ubiquitous Computing, 5(1), 4–7. DOI: 10.1007/s007790170019. (Background on defining and using context in computing, not evidence that the proposed overlay improves performance or prevents persistence.)