# The Person Changes During the Day
# Book: Language
# Chapter URL: https://programmer.ie/books/language/25-chapter/
# Prose fingerprint (sha256, normalized): 3264b8af79f5337e1e3c451fc1d7f7919616c1aae10d762dcdad78ec2f682746
# 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, not withdrawing her interest in the implementation or authorising the system to guess what she can safely ignore. Five minutes is her stated budget for this encounter, not a measurement of her attention span or a standing preference for brevity.
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 the same account first might exhaust the time she has. But a short answer that omits the condition under which recovery can duplicate a write would be worse: she could leave the meeting with a fluent answer and a false assurance. Brevity is useful only within what the decision requires her to know.
The channel has to change what it presents without turning this moment into a new fact about Iris. It can put failure risks first, retain each decisive qualification alongside its claim, and keep the source-linked derivation easy to expand. If the constraints cannot be explained safely in five minutes, it 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 expose the question this chapter addresses:
How should temporary conditions alter communication without becoming durable properties of the person?
Chapter 24 separated the historical evidence in memory from its current applicability and authority. The same discipline now has to operate on a much shorter timescale. A standing policy, facts about this interaction, and the rendering decisions made from them are different objects. The distinction resembles the established concern of context-aware computing with information that characterises a situation; it does not imply that sensing context reveals a person’s motives or that using it improves outcomes. Here, the extra question is which contextual inputs the channel is 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 an origin, a permitted use, a scope and a reasonable freshness condition. Some are declarations, some are observable circumstances the person has allowed the system to use, and some are hypotheses that must remain labelled as such. A useful 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 interaction stage. These are narrow facts about this encounter, and their different origins should remain visible.
Those origins determine what the system may conclude. A small screen limits the space in which evidence can be shown; it is not a licence to omit a qualification. An open document may identify the source Iris is examining; it does not establish her purpose. Calendar access, device signals and activity histories are not automatically authorised simply because software can observe them. Where an input is missing or withheld, the channel should use the generic task-appropriate representation rather than silently treating absence as a fact.
The channel can offer a tentative task interpretation from authorised, visible work. Two API descriptions open side by side might prompt: Comparing these interfaces? Iris might instead be collecting examples. Until she confirms, the hypothesis must be displayed as a guess, available for correction and used only for a reversible, low-consequence presentation choice. It cannot override her stated objective, trigger an external action or become a standing memory. A stale guess from an earlier tab or task is not 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 establishes an instruction about this answer, not a diagnosis of impatience. Iris can ask for a slower explanation, larger text or a more direct answer without the system inferring a psychological category. If she herself declares a constraint that the application is authorised to use, that declaration can shape the current view without becoming an enduring trait.
This keeps the earlier boundary intact: observing a condition is not knowing an inner state, and observing it does not automatically authorise using it. The channel needs an adequate account of the task and the permissible presentation constraints, not an explanation of Iris’s personality. If the system cannot tell what task it is serving, a visible clarification or a neutral view is preferable to 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 temporal limit and possibly a narrower task scope; the second is a later, specific instruction. Neither establishes an enduring dislike of detail. If the earlier scope is unclear, the system can ask rather than invent a permanent rule.
The Understanding Compiler could propose those acts, scopes and times while distinguishing Iris’s statements from its own inference about applicability. A meaning diff should keep the original statement fixed and identify the newly admitted task or later instruction separately. Reinterpreting the first statement under the later context is a new interpretation event; it does not change what Iris said earlier. A model-only change in reading needs its own provenance too.
The proposal may inform the session overlay. It must not silently become durable memory, identity or authority. Retaining an interpreted preference needs a separate purpose, scope and permission, and correction must reach its dependent uses. Classifying these sentences does not establish that adaptation improves Iris’s decisions or produces long-term benefit.
The overlay decides what changes Context does not itself determine a representation. Five minutes is a constraint; putting risks first is a rendering decision; suppressing an essential caveat would be an invalid one. The session overlay is a bounded record of the decisions made for this encounter, derived from applicable standing policy, authorised current context, an explicit temporary instruction and non-negotiable preservation and accessibility requirements. It 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 says why this view begins with risks, not what Iris generally likes. Each resulting claim remains tied to the source and its qualifications. A reader inspecting the decision can distinguish the inputs Iris supplied, the device constraint the application used and the rendering choices made under them. Nothing in the overlay upgrades a guess about Iris into a declaration.
If she asks to expand one derivation, that new instruction governs the current view. If she changes device, finishes the review or says the five-minute limit no longer applies, the dependent presentation choices must be reconsidered. A cached brief, a partially generated answer or a queued rendering should not retain authority merely because it was valid moments earlier. The overlay is a derived view of current conditions, not a second standing policy.
Temporary instructions have bounded authority Iris’s immediate request can override her ordinary presentation default within this task. It cannot remove necessary evidence, accessibility requirements or source boundaries. Nor does being hurried grant permission to notify colleagues, change a deployment, retain extra behavioural traces or act for her. Rendering permission and action permission remain different even when an urgent instruction mentions both.
Within those boundaries, one candidate ordering for choosing among permitted 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 resolution procedure, not an empirically established priority scale. Explicit instructions can themselves conflict: an earlier show all equations and a later give me the risk summary must be reconciled by scope and the actual request, not by averaging their strength. An observable constraint cannot override a declaration by pretending to be an instruction; an inferred task cannot claim the authority of one. Where an authorised choice is ambiguous and consequential, the channel should ask. The overlay records the decision and its basis, not an independent permission to make one.
Suppose the standing policy calls for relevant equations, but Iris asks for a short risk summary. If a relation between retry conditions and duplicate writes determines the correct answer, the summary must retain its decisive condition in words, an equation or another demonstrably adequate form. Supporting derivations can be folded; the limiting assumption cannot. If the system cannot preserve it at the requested resolution, the correct response is to disclose that limit and offer a safer, expandable account—not to turn a conditional claim into an unconditional assurance.
The important boundary is that 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 a termination condition as well as a source. For this review names a task boundary; until this incident closes names an event whose completion may need confirmation. A timer can be a conservative backstop, but it does not prove the event has ended. A usable record therefore names its session, triggering condition, expiry rule, and what to do if termination cannot be verified. Unknown status should not extend a temporary override 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. A move from review preparation to study is a change of task even if the app remains open. If until I say otherwise is intended to persist beyond a session, the system should ask whether Iris wants an explicit standing rule rather than reinterpreting a temporary request as one. A requested one-off override must have a visible, bounded lifetime.
A new session gets a newly derived view. Closing the old session does not confer authority on its overlay in a 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 covering the resumed work. The same distinction applies across devices: synchronising a standing declaration is not the same as copying a phone-specific time constraint 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 need not be promoted to durable personal memory before it can shape the present view. Equally, not retained as personal memory is not automatically never recorded anywhere: ordinary diagnostics, security logs or cached outputs may leave technical traces. Those stores require their own permissions, retention controls and access boundaries. The claim here is narrower and testable: absent a separate authorisation, temporary context and its derivatives must not acquire standing authority in 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 the session ends, deleting an object labelled overlay is insufficient if its effects can later influence policy. The more subtle path runs through apparently useful observations: the system changes the view, Iris responds to that altered view, and a learner treats the response as evidence of an enduring 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 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 independently invalidates dependent views and plans.
Suppose Iris selects a deep-study mode for one session. The channel expands explanations and leaves derivations open; she spends longer reading. A later learner might interpret that reading time as evidence that she generally wants long answers, 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 a correct record of reading time cannot, by itself, justify a new personal rule.
If behaviour observed under a temporary mode is deliberately and legitimately retained, the retained record must identify the mode, the presentation that elicited the behaviour, its scope and the permission for subsequent use. Such evidence can motivate a proposal, not an automatic policy update. If retention or promotion was not authorised, a downstream learner must not ingest it as a standing-preference signal. The design has to enforce that boundary at the path from events to learning, not rely only on removing the user-interface overlay.
overlay removed ≠ overlay left no durable residue For an interaction that authorises no durable 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 compiled from today’s instruction and the standing policy that still applies. Neither yesterday’s phone constraint nor the learner’s interpretation of yesterday’s reading behaviour may shorten it. A regression test should resume the session, reopen a cached view, and replay the observation-to-learning path; checking only that an overlay row was removed would miss the failure.
That is the chapter’s key failure test. Expiry must be checked along two paths: directly, where the overlay shapes a later view or survives in a cache; and indirectly, where its effects enter retained events, inferred knowledge or a future policy proposal. The constructed scene makes both paths concrete. It is not evidence that the present 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 persist. She can say: For incident reviews, make the risk summary my default. That is a new declared policy, with its own origin, task scope, effective time and correction route. It may supersede a broader presentation default within that scope, but it cannot retroactively turn earlier temporary behaviour into an instruction she had already given.
A channel might propose a scoped rule after repeated requests, but repetition can be assessed only from records that were intentionally retained for an authorised purpose. Counting discarded overlays would defeat the premise. Even authorised observations may reflect a particular interface or situation, so the system should show the actual examples behind a proposal rather than presenting 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 remain 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, dismissible, specific and reversible. Yes creates an explicit, scoped standing declaration; no creates no new presentation rule; don’t ask again prevents further prompts for that proposal within its declared scope. A refusal must not become merely a lower-weight signal while automatic learning continues toward the same outcome. Retaining a suppression preference also requires a bounded, inspectable record: declining a proposed rule should not force Iris to accept unlimited behavioural profiling.
Asking is a candidate mechanism, not evidence of reduced correction burden. Its purpose here is to make the source 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. Freeze a small set of source-grounded architecture questions with independently checked critical qualifications. Give participants repeated encounters: a short mobile review, a longer desk session, a task switch, and a return the following day. Compare (1) a fixed, task-appropriate view, (2) reader-controlled expansion with no automatic overlay, (3) an overlay driven only by explicitly declared constraints, and (4) an overlay that also uses separately authorised observable context. Keep the source, tasks and preservation obligations constant across conditions; counterbalance the encounter order.
Evaluate decision correctness, missed qualifications, time and interaction cost, unwanted format changes, corrections, and failures to return to the standing view. Independently audit the resumed session, cached views, queued rendering jobs and any permitted observation-to-learning path for leakage from an expired overlay. Test conflicts, revoked permissions, unknown expiry, a change of device and a task switch. Record how often the system has to ask rather than guess. A shorter answer or fewer taps alone would not establish benefit, and an elegant demo would not establish that unseen consumers of session state obey 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, 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 retaining the decisive equation and assumptions. Expiry invalidates known dependent plans and records, including transitive dependencies, instead of simply changing a visible label. Behaviour recorded under a temporary condition keeps that condition as provenance, and 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 supplied fixtures, 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; the latter are intentionally excluded. The model is scripted and the condition is supplied. The example does not establish that every cache, event consumer or learning path has been invalidated, that the proposed resolution policy 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, not construct a persuasive story after rendering: 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, applied rule and resulting view. It should also expose which inputs were declared, observed with permission or merely proposed.
That 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 promotes it. If the system cannot recover the provenance behind a presentation decision, it should not assert that it knows why the view was changed. Inspectable uncertainty is preferable to an invented explanation or an inferred personal trait.
The explanation must cease to describe the current view when the overlay ends. A new view needs a new decision record; an old record can still explain historical output without governing new output. Durable policy supplies continuity, authorised current context supplies responsiveness, and the overlay connects them for a bounded interaction. The boundary to be tested is not merely whether Iris sees a different page tomorrow, but 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 Iris explicitly declared. She may have asked to finish one paper before beginning another, while a stream of related results makes switching tempting. That is not another 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.)