The Personal Experience

A few weeks into using the Radar, Priya notices that it behaves differently from the first day. Library updates no longer interrupt her. Papers arrive with the conclusion first and the method behind a click. Comparisons come as tables. Contradictions of her protocol arrive with the evidence attached, never as a bare verdict. None of this surprises her entirely, and most of it she likes. (Priya and the sessions in this part are constructed for illustration, as in the last part. Where research is cited it is attributed, and nothing here reports a measurement of the book’s own.) But when she asks why a particular item was shown the way it was, the answer is not clear. Some of it she told the system. Some of it she did, and the system noticed. And some of it the system concluded for itself, from the way she had behaved, in ways she cannot now reconstruct.

That is the situation Part III begins with. The last part ended with a channel that decides what reaches Priya, how much of it, and when, using what she declares and what it can observe in the moment. It still waits for her to act, and it forgets her between decisions. Once it starts to remember, to keep something about the relationship between them from one interaction to the next, a new question arrives, and it is larger than it first looks:

What may a channel keep about a person across interactions, who decides, and what must stay explicit?

A memory that cannot say where it came from is a hidden decision-maker. The rest of this part is about how to avoid building one.

Three kinds of thing that persist

What the system holds about Priya is not one body of knowledge. It comes in three kinds, which differ in how they got there and how far each can be trusted:

DECLARED   what she told the system
OBSERVED   what happened, and the system noticed
INFERRED   what the system concluded from it

declared  ≠  observed  ≠  inferred

Declared things carry her authority: she said it, in terms she chose. Observed things are evidence: she snoozed three library updates, opened a table twice, asked for detail on a particular paper. Evidence is real, and it is not a statement of what she wants. Inferred things are the system’s own conclusions, such as “Priya prefers concise material”, and they are the weakest of the three, because they stack a guess on top of evidence that was already partial.

The ordering follows. What she declared outranks what happened, and what happened outranks what the system concluded. Inference can propose, but it cannot establish. This ordering is the spine of the part. Each chapter that follows takes one of the three, or one of the ways they interact, and asks what it may be used for.

The simplest case is also the first: what she explicitly says. This chapter is about that, because everything else rests on it.

The recipient as a declared input

Start from a modest idea. The way information is shown can be one of the things a person controls, stated openly and applied to what she sees:

information  +  task  +  her declared presentation policy
        ↓
representation choice
        ↓
a view shaped for her

Nothing is learned in this picture and nothing is inferred. She says how she likes things shown and the system does it, within limits discussed below. The policy is made of independent settings, one for each dimension along which a presentation can vary:

depth           brief  ↔  exhaustive
form            prose / table / diagram / timeline
explanation     examples first  ↔  principles first
order           conclusion first  ↔  derivation first
evidence        summary first  ↔  source first
interaction     passive  ↔  exploratory
technicality    intuitive  ↔  formal
navigation      guided  ↔  self-directed

Each is an instruction for rendering, stored separately, combined for each encounter and scoped to a kind of task. They are deliberately not grouped into personas. There is no slot for “visual learner”, “technical user” or “beginner”, and the omission is structural, not cosmetic: the system has nowhere to store a type of person, only settings per dimension and per task. That matters because the next chapter argues that types of this kind are a poor basis for adaptation, and it is easier to keep a bad idea out of a design when the design has no place to put it.

Preference, benefit and policy

A distinction needs to be made at once, because it is easy to blur. There are three different things in play:

DECLARED PREFERENCE    what presentation do I want?
OBSERVED PERFORMANCE   what presentation helped on this task?
SYSTEM POLICY          what presentation will actually be used?

“I prefer diagrams” is a real input and gets honoured: the system will render diagrams where they are safe. It is not a finding that diagrams make Priya understand better. That is a claim about benefit, and it needs its own evidence. The two are measured separately, and a result in which she prefers a form that leaves her understanding worse is not a contradiction to explain away. It is a successful control paired with a warning about policy: the system did what she asked, and what she asked is not what helped.

The policy that actually renders is a combination of four things: what she prefers, what the material makes cheap to see, what the task needs, and what must be preserved. Where they pull apart, the interesting cases appear.

Inside the limits

Four such cases make the constraints concrete. She asks for a diagram of material that is dense with qualifications. The right response keeps the prose, or shows the diagram with its qualifications beside it, and never the diagram alone. She asks for extreme brevity where the evidence needs its caveats: the preservation obligations set a minimum, and the system says so. She likes source-first for scanning, which is legitimate and costs time, so it is honoured with the cost shown. She wants an intuitive account of an exact numerical comparison: a table with an explanation, because the numbers must survive.

The rule these cases share is one the earlier parts have already prepared:

Personalisation operates inside constraints the person cannot trade away by accident. It does not get to personalise away what the source claims.

Her preference decides among acceptable representations. It does not make an unacceptable one acceptable. And when a preference is overruled, she should be told why, in plain terms, because an unexplained override turns a control surface into decoration.

What if she never touches the settings?

Most people do not configure most things. A design that works only for people who set up every dimension has quietly made configuration the price of working properly. So the first question about any personalised system is what it does when nothing has been set. The answer is a safe default: representation driven by the source and the task, never by a guess about the person. A task-appropriate generic depth. Evidence available and expandable. No personal assumptions. And no learning at all until she has authorised it. That is not the optimum. It is the bounded fallback that stays acceptable when controls go untouched, and it is a first-class mode of the system, not a failure state.

It follows that the default is allowed to win. If configuring a policy, correcting it and maintaining it costs more attention than the better-suited views save, then a generic interface is the right result, and nothing in this part will pretend otherwise. Control that takes real work to exercise is not a free good. The work should be counted.

What she sees

All of this should be something Priya can look at and change, in terms she can read:

My interface
  Depth: concise ---- detailed
  Evidence: show sources by default
  Comparisons: prefer tables
  Processes: prefer diagrams when safe
  Explanation: examples before formalism
  [Reset to generic]   [Use only for this task]
  Why wasn't my preference used?

The last line is the one that does the most work. A control surface that cannot answer it is one more thing the system does to her.

Where this leaves us

A channel that remembers has three kinds of memory, and they must not be confused: what a person declared, what was observed, and what the system inferred. Authority runs in that order. The first thing that can safely persist is a declared presentation policy, made of independent settings, scoped to tasks, with no place to store a type of person. Preference is honoured but never taken for benefit, personalisation works inside constraints that come from the source, and a safe default has to exist for people who never touch the controls and is allowed to win.

That is the easy case, because everything in it was said out loud. The harder case is the one that has already started. Priya’s behaviour is leaving traces, and there is a short step from what she does to a conclusion about what kind of person she is: this person likes diagrams, that one prefers detail. The step is tempting and widely taken. Before the system learns anything about her, the book has to say what it is allowed to conclude. Is a person a stable type that the system can discover and then serve, or is the thing worth learning something else?