# Protection That Travels
# Book: Language
# Chapter URL: https://programmer.ie/books/language/26-chapter/
# Prose fingerprint (sha256, normalized): cfb1e066ce1acec8eab4922492ec5dd01e16c999e9fad63e9cfdab979e21e48b
# 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 has asked her reading tool to remind her before she opens another paper. She has separately authorised a temporary change to its recommendation view while she studies. Those permissions are local to the reading tool. They do not automatically apply to her news or video services, even when all three recognise the same account. When she moves to another service, its usual recommendations return.
She now makes a distinct request: For this evening’s study, keep new consensus-research recommendations out of the recommendation feeds in these two services. Leave search and direct opening available. End the rule when I finish the paper or end study, and no later than eight this evening. She reviews the named destinations, the feeds affected and the exceptions before accepting. A different service, a broader topic filter or a longer lifetime would require a different decision.
That declaration supplies what the earlier rules did not: scoped authority to attempt this particular change at specified destinations. It does not turn the earlier reminder into a global restriction, transfer the authority to invent new interventions, or give either service access to the history of Iris’s study sessions. Nor does authorisation establish that a destination can implement the request faithfully.
The scene is constructed. Its question is architectural:
If a person has declared a communication boundary once, how can it be carried into another service without carrying the history that produced it?
Two principles guide the proposed answer:
A communication policy can travel farther than the history that produced it.
Portability does not permit reinterpretation.
Permission to travel A rule’s existence does not authorise its use everywhere. Iris may want a quiet reading view and an unrestricted news feed at the same time. A mediator that extends the first rule merely because it recognises her in both places has changed the instruction. Even an apparently beneficial extension would be an unauthorised one. Identifying the same user answers whose rule this is; it does not answer where the rule may operate.
The destination is therefore part of the authority decision, not an implementation detail. A portable boundary needs an identifiable recipient, an affected surface, a permitted effect, preserved exceptions, an override, and an end condition. It also needs a version so an old application can be distinguished from an approved revision. A session overlay may activate the accepted rule when its conditions hold. As in Chapter 24, it cannot create permission or enlarge its scope in transit. The mediator must also have separately authorised access to each service’s controls; a user instruction is not itself a service credential.
Here is a small account of what Iris accepted:
Portable boundary — version 1 Authority: Iris explicitly accepted this separate grant Version: 1; later changes require a new version Destinations: The two named services, with their exact account/surface IDs Effect: Hide new consensus-research recommendations from the named recommendation feeds only Preserve: Search, direct links and other content categories Override: Show recommendations now in this service's current view End: First of: paper finished, study ended, or 20:00 on the accepted date in the declared time zone Learning: Do not promote behaviour shaped by this rule into a durable preference without separate authority Proof needed: Confirmation of each supported control and its limits This is an illustrative contract, not an interchange standard or evidence that a real service supports every field. Its purpose is to make the grant readable and testable. “Keep me focused” would not identify the permitted surfaces, exceptions or lifetime. Names such as “the video service” are not sufficient for actual delivery: an implementation would need to bind the permission to the intended service and account, and reject a payload delivered to an unexpected destination.
The rule also has a reason Iris can recover: she asked for this during a particular study session. That reason must remain hers. Receiving services do not acquire a mandate to diagnose distraction or decide what would be better for her.
What travels and what stays The news service needs to know which recommendation surface the rule covers and what control it is permitted to use. It does not need Iris’s reading history, her earlier overrides or a model’s explanation of her motivation. A destination-specific payload should carry only the accepted effect and the information necessary to implement it; it should not carry a general licence to use the mediator’s personal memory. The mediator must also minimise what it receives back: a status receipt is not an invitation to collect the service’s activity log.
The separation is:
retained history ↓ explicitly authorised boundary ↓ minimum information needed at this destination ↓ local application and a bounded receipt Minimum information is not no information. A receiving service needs a shared understanding of which items count as consensus-research recommendations and which surfaces count as feeds. That classification may itself be a sensitive disclosure of Iris’s current interest. Where the terms cannot be mapped faithfully, the mediator should report the mismatch, seek a narrower accepted definition or abstain. Sending the entire conversation to let the service guess would abandon the very separation portability is meant to preserve.
Nor does the receiving service need Iris’s private explanation of why she wants the rule. It may receive an authenticated reference to the accepted grant, its limited scope and the control it is asked to apply; the fuller reason can remain where she gave it. But a reference alone is not proof of authority. The adapter must know that the grant is genuine, current, addressed to this destination and not a replay of an expired version. Model-generated text claiming to be Iris’s instruction is not a substitute for that check.
Expiry needs the same minimisation. A service may need a deadline and an event signalling that the study session has ended; it does not thereby need continuous access to the paper Iris reads. A mediator could translate the local event into the narrow instruction “end boundary version 1 now”. That is a proposed design, not a claim that a service accepts it. If the event cannot reliably reach the destination, the receipt must say so and the offered enforcement cannot be described as having the requested lifetime.
A faithful adapter The rule arrives at services with different controls. An adapter maps Iris’s accepted effect onto what a particular service can actually do. It should be deliberately unambitious: validate the destination and grant; inspect the supported control; compare its effect, exclusions, lifetime and override with the contract; apply only a permitted mapping; and report what was actually observed. Translation is not negotiation on Iris’s behalf. A model may propose a mapping, but it cannot authorise a broader one or certify its own success.
Three things must stay separate:
Constructed service examples, not real integrations. Partial means a subset of the authorised effect; enforcement needs a bounded receipt. Open full-size diagram. A service limitation does not enlarge the user’s instruction.
Suppose the constructed news service has only an account-wide switch that hides all research content, including search results. Applying it would suppress consensus recommendations, but also remove other research and the direct access Iris explicitly preserved. It is not a faithful implementation.
The adapter must report: This service cannot apply the requested feed boundary. Its available control would also hide other research and search results. It leaves the broader switch unapplied. Iris can accept a newly described, service-specific alternative, but that is a fresh authority decision, not a silent repair of the first grant. The unsuccessful attempt should not change her existing settings or be recorded as protection.
Now suppose the video service can filter its home recommendations but not suggestions beside a playing video. Filtering only the home surface may be faithful partial application if the supported control respects the content category, preserves search and direct opening, offers the agreed local override, honours the lifetime and satisfies the learning constraint. The uncovered suggestions must remain visible in the report. If even one mandatory condition cannot be met, the adapter cannot call that surface a faithful partial application merely because the visible feed became quieter.
That distinction matters:
less of the authorised effect ≠ an effect beyond the authorisation The honest outcomes are faithful application within the checked scope, faithful partial application, inability to apply faithfully, and an outcome not yet confirmed. Partial describes a subset of the authorised effect, never a broader effect. Nor should an adapter silently choose the nearest available control: an approximate match that removes direct access, silently extends the end time or trains a durable profile violates the contract even if it suppresses some desired recommendations.
Classification creates another limit. A service’s category called “consensus research” may not mean what Iris meant, and its classifier may change between receipt and delivery. The adapter should record the category mapping and its known coverage, including exclusions and uncertain cases. A successful setting change can be true while the actual classification is wrong. Testing representative included and excluded items is stronger evidence than reading a switch back, though it still cannot establish the behaviour of every future item.
A receipt says what is known Portable ≠ propagated ≠ verified.
A portable boundary is a versioned, interpretable request. It is not proof that the request has reached each destination, that the destination understood it, that its controls support it or that its effects were verified. The distinction is analogous to a limited security grant: the fact that a grant names an audience and a scope does not prove that the recipient acted correctly. OAuth 2.0 Token Exchange, for example, defines audience and scope concepts for exchanged tokens, not semantics for recommendation filtering or evidence of compliant enforcement. Portability must establish its own meaning and checks.
DECLARED ≠ CARRIED ≠ RECEIVED ≠ SUPPORTED ≠ ENFORCED ≠ VERIFIED A service can receive a rule it cannot support. A control can be supported but not yet applied. A successful application call may be acknowledged without any independent readback. Each receipt therefore needs a basis for its claim: request sent, destination acknowledged, control reported applied, or specified readback passed. None should be silently upgraded to the next. These are observations at different trust boundaries, not synonyms for success.
Sending a rule, receiving an acknowledgement and checking an applied control are different events. A mediator that reports “protected” after the first has confused a request with an outcome.
An enforcement receipt should identify the boundary version, exact destination and surface, status, observation time, evidence basis, unmet conditions and any outstanding expiry or removal check. Its issuer matters too: a receipt authored by the mediator from its own intention is not an observation by the service. In the constructed video service, after a readback, it might say:
Receipt — video service, 18:10 Boundary: Version 1; grant scoped to this video service Surface: Home recommendation feed only Status: Partial; setting readback passed at 18:10 Observed: Home-feed filter enabled; search setting unchanged Unsupported: Recommendations beside a playing video Not verified: Per-item classification, future expiry, effective override, suppression of durable learning Basis: Service-reported setting readback; no behavioural probe Next check: At expiry or revocation; earlier if configuration changes This receipt reports a specific observed setting, not “protection verified” in the general sense. Readback may show that a filter is enabled; it does not prove that search works, the next item will be classified correctly, the override is accessible, the expiry will fire, or downstream learning will leave no residue. Those require different checks, some of which a third-party service may not expose. When a requirement is untestable, the receipt must say not verified, rather than treating silence as success.
setting confirmed ≠ protection verified The receipt must also distinguish unsupported, refused, not applied and unknown. An offline service is not known to have rejected a request; a timed-out apply call is not known to have failed, since the service may have made the change before the response was lost. Retrying therefore needs an operation identity and idempotent handling where available. A receipt must not say “not protected” if the state is unknown, or “protected” because a retry was acknowledged; it should say precisely which operation and state were observed.
This accountability mechanism has a bounded implementation with fake services, described below. It establishes no enforcement in a real service. Its value here is the discipline it imposes on the claim: what changed, under whose instruction, where, and how do we know?
Receipts age. Yesterday’s readback cannot establish today’s state after the service changes a control, the category mapping changes or Iris approves version 2. The display should show the latest observed version and time for each enforcement point, the currently authorised version, and any missing or stale verification. A new request does not erase an older receipt; the record should make disagreement between intention and observed state visible. A state that has become unknown should not inherit the colour or claim of its last successful check.
Ending the rule everywhere At seven, Iris finishes the paper. Her boundary’s authority ends even though its outer deadline was eight. Removing the central record would not undo an active filter in the video service. This is the distributed failure that portability creates: a correct decision in one place can leave an unauthorised effect running somewhere else. Ending the rule is therefore a change that must be attempted, tracked and independently checked at each destination.
Expiry belongs to each applied effect. An adapter must establish how a destination can stop the filter at the earliest of the accepted events, not merely at the convenient clock deadline. A service that supports 20:00 expiry but cannot receive the paper-finished event cannot fulfil Iris’s chosen lifetime on its own. The mediator could offer a separate, explicitly accepted arrangement with a bounded local lease and a reliable cancellation path; it must not assume that an offline destination will promptly receive cancellation. If none can meet the essential end conditions, the adapter should refuse application and explain why.
The same issue appears when she revokes or revises a rule:
Revocation must travel through the same enforcement path as creation. Deleting the source rule is not evidence that its distributed effects have ended.
Suppose the rule was applied at three enforcement points. After Iris revokes it, one confirms removal, one is offline and one still reports version 1 from its cache. The central declaration is revoked in all three cases, but only the first destination is confirmed clear. A late acknowledgement of the old apply operation must not turn the revoked version active again. This requires version-aware, replay-resistant processing and a clear distinction between revocation requested, destination acknowledged and removal checked; the example does not demonstrate that a real service provides these guarantees.
A receipt for version 1 remains evidence about an earlier application, not authority to recreate it. The mediator should reconcile the current authorised version with each destination’s last observed version, make outstanding removal attempts visible, and retry or escalate unresolved changes within its permitted capability. Even established token-revocation protocols cannot promise universal instantaneous effect: RFC 7009, for example, notes cases where access tokens remain usable after related revocation. Revoking a portable communication rule has a different mechanism, but the general lesson is the same: a revocation request is not proof that all distributed effects have ceased.
Removal must preserve unrelated service settings. If Iris already had a separate recommendation filter, ending this rule must not restore the entire feed to its factory defaults. The adapter should record which change it made and, where the API permits, remove only that change using a version-checked update. Otherwise a concurrent change by Iris or another legitimate controller may be overwritten by a stale rollback. Where selective rollback is impossible, the mediator needs to report the conflict rather than silently rewriting settings outside its grant.
An override has a narrower meaning. Show recommendations now for this view permits that view; it does not cancel the boundary in the other service, revise its future scope, or announce that Iris no longer wants to finish the paper. Repeated overrides can invite reconsideration under the previous chapter’s conditions. They cannot authorise stronger enforcement across more destinations.
Temporary effects must not become a person The receiving service might observe that Iris opened fewer consensus recommendations while its feed filter was active. That behaviour was produced under the boundary. It cannot be treated as an unqualified declaration that she has lost interest in consensus research.
This is Chapter 24’s indirect-residue problem at another destination:
temporary boundary changes the feed ↓ changed feed changes behaviour ↓ behaviour becomes a lasting preference inference Removing the filter would leave an effect behind if behaviour produced while it was active continued to train future recommendations. A temporary boundary therefore needs an explicit rule against unauthorised promotion of those observations into a durable personal preference. The destination must either support that limit, provide verifiable evidence of compliance at the level claimed, or disclose that compliance cannot be established. A mediator cannot inspect a third party’s hidden training pipeline simply because the service confirmed a feed setting. Permission to change the view is not permission to construct a lasting inference about Iris.
If the no-promotion limit is an essential part of Iris’s grant, a service that cannot support it does not faithfully implement the requested boundary. The mediator should leave that arrangement unapplied and explain the limitation. Iris may separately accept a different arrangement after seeing the consequences, but the original grant does not stretch to cover it. Equally, a service’s promise not to learn is not proof that it complied. This obligation exposes a genuine boundary of the architecture: not every desired protection is technically enforceable or externally verifiable in an arbitrary application.
Running it Running it. npm run example:personal -- ch26 in the reference implementation (ernanhughes/project-language) applies the portable boundary to three fake services. npm run example:personal -- all adds the separate readback check and revocation.
What it shows: the destination receives a reduced policy payload, not the invented history that produced it. The fixture representing an exact control is applied; the broader-control fixture receives REFORMULATE and is left unchanged; the offline fixture remains unconfirmed. The stage trail distinguishes DECLARED, CARRIED, RECEIVED, SUPPORTED, ENFORCED and VERIFIED. The initial exact-service receipt is not verified; the full run then invokes a separate readback criterion through core/verify. Revocation goes through the same transport mechanism as application. The printed evidence concerns supplied fixture states and their stated check; it is not a cryptographic attestation or an independent observation of a real destination.
What it does not show: that a real service honours the grant, classifies recommendations correctly, preserves Iris’s existing settings or stops learning from the temporary intervention. The model is scripted and the services and controls are fixtures. A passed readback supports only its named criterion. There is no tested guarantee of cross-service expiry, delivery during outages, revocation convergence, accessible overrides or elimination of indirect memory. These are proposed capabilities, not measured results.
A proposed cross-service test A useful experiment would compare four approaches on the same frozen sequence of user grants, service capabilities and service events: manual configuration in each service; a mediator that copies a policy without checking translation; a scope-checked mediator with application receipts; and that mediator with independent readback, expiry and revocation checks. The last two are designs to build and test, not improvements established here. A separate later pilot would be needed to see whether real people understand the controls or benefit from them.
The fixtures should contain exact controls, broader-than-authorised controls, partial surface coverage, changed category meanings, existing unrelated filters, services that go offline after applying, delayed or duplicated acknowledgements, stale rule versions and a revocation racing an old apply request. Include both the early paper-finished event and the final clock deadline. Supply independent expected outcomes for each case before running the adapter; do not let the same model both choose an implementation and judge its correctness.
Measure unauthorised changes, required exclusions lost, correctly reported partial coverage, false claims of verification, residual enforcement after expiry, preservation of unrelated settings, disclosure beyond the destination’s minimum need, and the work required to understand or correct the outcome. A feed that becomes quieter is not by itself evidence of successful protection. At every step compare the receipt with the state the test harness can actually observe. The closed-world fixtures would show whether specified invariants hold under those cases; they would not show that uninstrumented third-party services are trustworthy.
Protection remains an accountable claim An accepted user boundary should constrain only the service behaviour that Iris named, including recommendation defaults that would otherwise fill the feed. If a service cannot honour it, the honest result is a reported refusal, unsupported mapping or unconfirmed state—not a badge that implies safety. A receipt saying received is evidence of communication. A receipt saying readback passed is evidence for one check. Neither substitutes for the actual effect Iris requested.
The account remains narrow. It proposes transporting an authorised communication boundary, not a general identity profile or power to speak for Iris. Existing security ideas offer useful analogies: audience- and scope-limited grants in OAuth 2.0 Token Exchange illustrate why the destination matters, while NIST’s guidance on data minimisation explains why a relying party need not receive all the information its intermediary holds. Neither specifies how to translate a semantic recommendation boundary or verify a service’s learning behaviour. Even a minimal payload can reveal a sensitive interest; across several destinations, those disclosures can be combined. A practical design needs a threat model for the mediator and recipients as well as a short payload.
The requirement is demanding enough without a universal standard. The destination must be identified and authorised; the grant must be authentic, current and limited; translation must preserve the effect, exceptions and lifetime; partial application must stay inside those limits; and expiry, correction and revocation must reach the actual controls. Evidence must be recorded separately from intention. A design that meets only the transmission step has moved an instruction, not demonstrated that the requested protection travels.
Iris can inspect the boundary she accepted and what each destination says happened. Yet enforcement still depends on internal representations: what the mediator thinks the rule means, which category it maps to, whether the service reports support, and whether a receipt is genuine and current. A mistaken mapping can hide the wrong material; a forged or stale receipt can create false reassurance. Retrieved content and model output must not be able to rewrite the grant, impersonate Iris or manufacture a verification result. Making the decision trace visible helps inspection but does not itself validate the underlying belief.
The same limitation applies to beliefs about Iris. The system may hold an estimate of her consensus knowledge, a scoped declaration about derivations, or an inference about her current project. Those claims have different origins, evidence and authority, but any of them can change what appears even when the transport of a boundary is faithful. Transparency is necessary for correction, not a guarantee of accuracy or permission to use the claim. The next chapter turns from portable rules to the consequential beliefs inside the system.
The next question concerns these consequential beliefs: if an internal belief can change what the channel shows, suppresses, retains or enforces, what must the person be able to see?
References IETF (2020). OAuth 2.0 Token Exchange. RFC 8693. https://www.rfc-editor.org/rfc/rfc8693 (Used as an analogy for audience- and scope-restricted grants, not as a protocol for semantic-policy portability.) IETF (2013). OAuth 2.0 Token Revocation. RFC 7009. https://www.rfc-editor.org/rfc/rfc7009 (Used for the narrow point that revocation and the continued usability of distributed credentials can be distinct.) NIST (2025). Digital Identity Guidelines: Federation and Assertions, SP 800-63C-4, privacy considerations. https://pages.nist.gov/800-63-4/sp800-63c/privacy/ (Used for data-minimisation principles in cross-service disclosure, not as evidence of the proposed adapter’s effectiveness.)