Part 1 of 7 · 6 min

What a system should say when it does not know

A system that answers every question gives you no way to tell its good answers from its bad ones. Part 1 of a series on refusal as a product behavior: the moments Coherence declines to answer, and why they make the rest worth acting on.

RET-204 is a retention obligation in a bank. The bank must keep consent records for seven years. It must also erase them, provably, when a customer withdraws consent. The two requirements pull against each other, and that tension is why the obligation carries its own number in the control matrix.

RET-204 itself is an invention: a composite of estates we worked in, because the real ones carry names we do not use. Everything it does in this series is something we watched a real obligation do.

It exists in four places. A regulation requires it. The control matrix lists it. A policy describes it. A procedure from 2019 documents it, written by someone who left three reorganizations ago. Somewhere in the core system there may or may not be a job that enforces the erasure half.

Twice a year, someone has to answer for it. The question never changes. Does this control work?

Every system in the building answers

Ask the document search. It returns the regulation, the policy, and the 2019 procedure. Three relevant documents, and no answer. The question was never a search.

Ask the reporting layer. The row for RET-204 is green, because the dashboard reads the control matrix, and the matrix says the control exists. The row was green last year too. Nobody can name the condition that would turn it red.

Ask a copilot with access to the document folder. It produces a warm, structured paragraph. RET-204, it explains, is implemented through the retention procedures and supported by scheduled jobs in the core system. It reads like an answer. It reads exactly the way it would read if it were wrong.

That last sentence is the problem this series is about. Producing statements about a business has become nearly free. Answering for them has not. Every tool in the estate learned the first skill, and the estate has no tool for the second.

One question, two systems

Now put the same question to a system built the other way around.

The first kind of system treats an answer as its job. Whatever it holds, it composes something. When the material is thin, the composition leans on style, and confidence fills the space that evidence left empty. The reader cannot see where that happened.

The second kind treats an answer as a claim it must stand behind. Asked about RET-204, it checks what it actually holds. The obligation is recorded. The retention half traces to a scheduled job it has read. The erasure half traces to nothing. So it declines the whole and reports the parts.

The decline has a shape. It names what it read. It names the half it cannot confirm. It states what would settle the question: the job schedule, or the data lifecycle configuration, read in as evidence. Nothing about it is apologetic. It is a report of a boundary, offered in place of a guess.

We build the second kind. When Coherence cannot support an answer, the words on screen are plain: insufficient evidence, and here is what is missing. The refusal is not a failure state we tolerate. It is behavior we engineered, and this series is about how far down it goes.

One boundary belongs in the same breath. The refusal covers what was read in. Material nobody supplied is a declared gap, not an inference. A system cannot be honest about documents it was never given, and it does not pretend to be.

A refusal is information

A system that always answers flattens its own output. Strong answers and weak ones arrive in the same voice, and the reader carries the whole risk of telling them apart. Most readers cannot. The ones who can are the experts whose time the system was supposed to save.

A refusal draws a line through the estate. On one side sit the claims the system can show you. On the other side sits what it cannot show, named and counted. The yes begins to mean something because the no exists and is visible.

There is a cost, and we would rather state it than have you find it. On the first day, over a freshly read estate, an honest system declines often. The confirmed picture is small. It grows as evidence is read in, and as people settle the questions the system raises. We show the small number anyway. A large number you cannot defend is worth less than a small one you can.

Where this goes

Refusal sounds like one behavior. Inside the platform it is a family. A classifier records that it cannot classify, rather than guessing. A matcher leaves a column unmapped, rather than inventing a target.

A seal declines to form over a reconciliation that does not balance. An administrator can close an approval, and can never manufacture one. Each part that follows takes one member of the family and shows what it protects.

The next part starts with the distinction the whole family rests on. A check that ran and found nothing, and a check that never ran, produce the same empty screen. If a system cannot tell those two apart, every refusal it makes collapses into noise. Part 2 is about a system that can.

Part 2: Abstention is a result. How the platform types its refusals, and why could-not-conclude and never-checked are different verdicts.

part 2 →Abstention is a result

Model your first domain today.

You send five documents, we model them, and the first cut comes back in days.