Important to Whom?

The talk on the consensus protocol has been broken into units, with the definition at minute 4 and the qualification at minute 53 joined where they belong. Three colleagues now ask the same system about it, each for a different reason. Priya has to decide whether the protocol is safe when network delays are unbounded. Tom is writing the history of consensus algorithms for a literature review. Mina wants to reproduce the demonstration.

The units are the same for all three. The talk is the same, and so is the budget of what can be shown. What each of them needs from it is different, and a system that gave all three the same digest would be serving none of them well. This chapter asks the question that comes next in the chain:

Once the system has candidate information units, what makes one of them matter for the task at hand?

Four reasons something looks important

Before answering, it helps to separate four different reasons a unit might seem important, because they are routinely mistaken for one another.

SALIENCE           it stands out
SOURCE NECESSITY   it is needed for a faithful account of the source
TASK RELEVANCE     it bears on the declared purpose
PERSONAL NOVELTY   it is new or surprising to this person

A failed demonstration is salient and may carry no unit worth keeping. A mumbled qualification is not salient at all and may carry the unit that limits the main result. A unit can be necessary for a fair account of the talk and irrelevant to what Tom is writing. A unit can be directly relevant to Priya and already known to her. The four are different questions with different answers:

salience  ≠  source necessity  ≠  task relevance  ≠  personal novelty

This chapter is mainly about the third, task relevance, with the second acting as a constraint on it. The fourth is left for the next chapter, where the person enters.

Relevance is a relation

The central claim is that relevance is not a property of the unit alone. It is something that holds between a unit and a purpose, in a context:

RELEVANCE(unit, purpose, context)

Purpose does for relevance what the sender’s intent did for preservation: it says what the information is for.

Take one unit, the qualification at minute 53 that the result assumes bounded delays between machines. For Priya, who is asking about unbounded delay, it is crucial: it tells her the answer is probably no. For Tom, who is tracing the history of the field, it is irrelevant to what he is writing. For a student who wants to understand the protocol, it is useful but not urgent. And for anyone producing a faithful summary of the speaker’s argument, it is mandatory. The unit has not changed. What it is for has, and with it the verdict.

Hence a distinction that is easy to state and easy to lose:

important to the source  ≠  important to the current task

A unit can be central to the source and irrelevant to the task: the paper’s main theoretical contribution, when the question is whether to deploy the system next week. A unit can be minor to the source and decisive to the task: a throwaway aside that clients on one operating system need an undocumented workaround, when the question is whether the organisation, which runs that system, can adopt the tool. A system that stores a single importance score for each unit has mistaken a relation for a property, and everything built on that score inherits the error.

A declared purpose, walked through

Relevance becomes much easier to see once the purpose is written down. Suppose Priya types:

Determine whether this protocol remains safe when network delays become unbounded.

Here are five units from the talk, with the verdict and the reason each gets under that purpose:

A  the definition of "fault" (crash failures only)
   relevant. It scopes what "safe" means. The result says nothing
   about other kinds of failure.

B  the performance benchmark (two round trips under failure)
   low. It is the headline, but it concerns speed, not safety under
   unbounded delay.

C  the bounded-delay assumption
   decisive. It states the condition the safety result depends on,
   and unbounded delay violates it.

D  an anecdote about the protocol's history
   not relevant to this purpose.

E  a deployment caveat (the speaker's team kept clocks synchronised)
   relevant. It explains why the assumption held in practice, and
   so what would change if it did not.

The point of the exercise is not to produce scores. It is to show that each judgement can carry its reason, and that the reason cites the purpose. A relevance judgement without a reason is a number nobody can argue with. With a reason, Priya can see why the benchmark was set aside, disagree, and bring it back. Corrections of this kind, promote this, drop that, are useful information about the purpose, which people are rarely able to state perfectly the first time.

Relevance is not keyword overlap

An obvious shortcut is to treat relevance as similarity between the question and the unit. It does not work. A passage can mention every word in Priya’s question and be useless: the benchmark unit may well say the protocol is “safe, fast and resilient” while telling her nothing about unbounded delay. And the unit that decides her question may never use the word “unbounded” at all, since the speaker only says that the result assumes the machines’ delays have a known limit.

lexical overlap  ≠  task relevance

What a system needs in order to judge relevance is a picture of the task, not of the words. It needs to work out what decision is being made, what evidence would change that decision, what constraints apply, and what failure would matter. Priya’s decision is whether to rely on the protocol under a condition the talk may not cover, and the evidence that would change her mind is anything that says what the protocol’s guarantees depend on. Only against that picture does the bounded-delay unit stand out. This is the same lesson as the earlier distinction between similarity and relationship: closeness in wording is not a statement about what one thing does to another.

Declared and inferred purpose

There are two ways a system can come to know a purpose, and they should not be confused.

DECLARED PURPOSE   what the person explicitly says they need
INFERRED PURPOSE   what the system thinks they need

Declared purpose is the safer starting point precisely because it is stated by the person and not guessed. Inference has uses. It can help disambiguate a vague request, or suggest an alternative reading the person might want. Suppose the request is simply “tell me about performance”. That could mean the speed of the protocol, the cost of deploying it, or how it compares with others, and a careful system surfaces the ambiguity and asks, or serves the readings in parallel, instead of silently choosing.

But there is a line:

inferred purpose  ≠  permission to replace declared purpose

If the system quietly substitutes its own idea of what the person ought to want, then selection has stopped serving the reader and started steering her. A system that decides Priya “really” cares about performance and fills her digest with benchmarks has done something much worse than make an error. It has changed her question without telling her. The inferred purpose may inform what the system proposes. It must not overwrite what the person said.

What the task does not get to drop

A last piece of the picture stops the whole enterprise from becoming optimisation for convenience. Some information is irrelevant to the user’s immediate question and still required to avoid misrepresenting the source.

Suppose Tom asks only how fast the protocol is. The qualification about bounded delays does not help answer that. But if the system tells him the protocol commits in two round trips and leaves out that this holds under bounded delays only, the answer is materially false. Task relevance says the qualification can be dropped. The obligation to preserve what the source claimed says it cannot.

task relevance  +  preservation obligation

Both constrain what is selected. The first narrows what is shown to what the purpose needs. The second says what must still travel with it so that the narrowed account does not say something the source did not. In practice this often means that a unit irrelevant to the task is not dropped but attached to the unit it qualifies, or shown in compressed form, or marked as withheld so that the reader can bring it back. What a system must not do is drop the qualification and present the remainder as the whole story. Withholding for relevance has to stay visible, as the opening chapter of this part argued, and it has to stay faithful.

Where this leaves us

Task relevance is a relation between an information unit, a declared purpose and a context, not a property of the unit. It differs from salience, from what the source itself requires, and from keyword overlap, and it is easiest to judge when the purpose is written down and each judgement carries its reason. The system should work from a picture of the decision being made, not from matching words. It should treat the person’s declared purpose as primary, offer inference as a suggestion and not a replacement, and keep the preservation obligation in force, so that what is dropped for relevance does not leave the source misrepresented.

Fix all of that, and a gap remains. Even with the purpose settled, two people may need different things from the same source, because what is already known to one is new to the other. Suppose Priya has spent two years working on exactly this class of protocol. For her, the definition of fault in unit A is a statement she could have recited. The unit is relevant, the task is the same, and the value is different.

same unit
same task
different person
        ↓
different value

That brings the person into the argument for the first time, and the next chapter is about what a system may know of her and how it should use it.