A question sets requirements, not keywords (Foundations, part 2)

Part 2 of Foundations. Part 1 explained why related text is not yet a supported answer. This note looks at the question side of that boundary.

Start with an ordinary question: “Who directed the film that won Best Picture in 2020?”

The answer is a person, but the question requires more than a person's name. It also requires a particular film, a particular award, the year 2020, and the relationship between all of them. A passage about the award and a separate passage about a director are useful only if they refer to the same film.

The whole question matters#

Every material phrase narrows what counts as a valid answer. Changing “directed” to “produced,” “Best Picture” to “Best Director,” or 2020 to 2021 changes the request even though most of the words remain the same. The words barely move; the requirements move entirely.

This is why a list of individually relevant passages is not enough. The application needs to know that the records support the same answer under the same identity, direction, and time requirements.

What a question actually is#

Here is a way to think about it that took me embarrassingly long to find, and that turns out to be old.

Ask someone "what does this question mean?" and they will usually paraphrase it. Formal semantics, the field that assigns sentences precise logical meanings, gives a stranger and more useful answer: the meaning of a question is the set of things that would answer it. Charles Hamblin proposed this in 1973, in "Questions in Montague English." The question "who directed the film that won Best Picture in 2020?" does not denote a person. It denotes the whole space of candidate answers, one per possible director.

Jeroen Groenendijk and Martin Stokhof sharpened it in 1984, in what is usually called the partition theory of questions. On their account a question cuts the space of possibilities into cells, where each cell is one complete answer, and every possibility falls in exactly one cell. Answering means saying which cell you are in.

You do not need the formalism to use the idea. It cashes out as one practical question you can ask about any system, and I would encourage you to ask it: before it answered, did it know what would have counted as an answer?

That sounds like philosophy and is entirely operational. A system that has computed the space of admissible answers can tell you three things a similarity ranking structurally cannot. It can tell you whether it covered that space or only sampled it. It can tell you whether two results it found are rival answers or compatible ones, because rivals sit in different cells and compatible facts sit in the same one. And it can tell you that the space is non-empty but nothing in the records locates you within it, which is the precise shape of a useful "I don't know."

A ranked list has none of this. It has passages, ordered by closeness. Ask it whether it covered the space and the question does not typecheck.

What the response should expose#

So what should a supported response actually show you? Three things:

1. what answer was returned;
2. which requirements of the question had to be satisfied; and
3. which declared records support each required step.

CleverMemory is being built so that this relationship is carried as a machine-checkable mathematical proof. The proof is stronger than a relevance score: it checks whether the answer follows from the available records under the supported rules.

The proof has a boundary. It does not establish that an original source is truthful or that the available record set is complete. Those are separate questions of source quality and governance.

Failure can still be useful#

Suppose the records establish that Parasite won Best Picture in 2020 but do not identify its director. The useful response is not a nearby name. It is a clear gap: the award and film are supported; the director relationship is not.

The same applies to ambiguity. If two films or two people remain possible, the application should receive the unresolved alternatives or a request for more specific scope. A polished guess hides the exact point where review is needed.

The public contract#

The behavior is the public part. An application should be able to test whether every material part of its question is supported, inspect the proof and sources when it is, and see the missing requirement when it is not. One part of CleverMemory stays ours: the code and data that tie everything together. That piece is not public; everything you need to check what it tells you is.

That is the point of treating a question as a set of requirements: the answer earns its place by satisfying the whole request, not by resembling its words.

Which raises the obvious next question: what should happen when the records run out and no requirement can be satisfied? Part 3 is about the math of honestly saying "I don't know," and it is older and more practical than you might expect.