Log the no, not just the yes

Go look at what your system actually persists, and sort it by outcome. You will find that the approvals are all there. The order was created, so there is a row for it. The account was opened, the payment cleared, the loan was booked — each of those leaves a durable object behind because something downstream needs it to exist. Now look for the denials. The application that was filtered before a human ever saw it. The candidate screened out. The transaction declined. The offer that was never made. In most systems, those are gone, or were never written, because nothing downstream depended on them. And those are precisely the decisions someone will come back and ask you to account for. You are keeping evidence in almost exact inverse proportion to how much it will be needed.

This is not a policy failure or a compliance oversight. It is the natural gradient of how software gets built, and it runs against you by default. A yes produces an artifact because the yes has consequences the system has to track — you cannot ship an order you did not record, so the record writes itself as a side effect of doing the work. A no produces nothing to track. There is no object to open, no downstream process to feed, no row that has to exist for the next step to run, because there is no next step. So the decision that most needs a record is the one the architecture is least inclined to give one. Correct that on purpose, or it will not get corrected.

The yes writes itself, the no vanishes

Start by naming the asymmetry precisely, because it is the whole problem. Positive decisions are self-documenting: they call something into being, and that something is the record. The created entity carries its own provenance because the business could not function otherwise. Negative decisions are self-erasing: they prevent something from coming into being, and a thing that never existed leaves no trace of the decision not to make it. The absence is total. There is no half-created order sitting in a table with a status of "denied" — there is simply nothing, and nothing is indistinguishable from a decision that was never made at all.

Sit with what that means for contestability. The cases you will be asked to defend are, disproportionately, the noes — the person refused credit, the seller delisted, the resume auto-rejected, the claim declined. Nobody files a grievance because they were approved. So the population of decisions most likely to be challenged is the population your system is structurally worst at recording, and the correlation is not weak. It is close to one. Your evidence retention is tuned, by accident, to be richest exactly where it will never be examined and poorest exactly where it will be fought over. Left alone, that is what you are shipping.

The decision you will be hauled back to defend is the one your architecture was quietly built to forget — and it forgot it on purpose, because forgetting was free.

The rejection is a first-class decision

The directive follows directly: treat a denial as a decision that must produce a record of its own, held to at least the same standard as an approval — and usually a higher one, since it is the one that gets contested. Do not model the no as the absence of a yes. Model it as an event with a body. At the point where your code decides to refuse, write down four things: what was denied, the inputs the refusal actually rested on, the rule or threshold that produced it, and — where you can compute it — the counterfactual margin. That last one is the part most systems omit and the part a contested no needs most: not just that the applicant scored below the line, but how far below, and what would have had to differ for the answer to flip. A refusal that can say "you were four points under a cutoff of seventy, and this single factor accounts for the gap" is answerable. A refusal that can only say "denied" is not a decision anyone can examine; it is a verdict with the reasoning burned.

Write this record on the denial path, synchronously, before the refusal is returned — not as a best-effort log that gets dropped under load, because load is exactly when a wave of contested noes gets made. And freeze what the decision saw: the input values as they were at that instant, the version of the rule in force, the operating point applied. Not a pointer to the current threshold, which will have moved by the time anyone reads the record and will reconstruct the case wrong. The no is a first-class decision. Give it a first-class record, complete enough that someone who was not there, and does not trust you, can replay it and see exactly why the answer came out the way it did.

The cases that never became records

Now the hard part, because the honest cases are not the declined transactions that at least passed through your decision code. They are the ones filtered before any decision object was ever created. The candidate screened out by a pre-filter that ran before the pipeline that would have logged anything. The listing suppressed and never shown. The offer that some upstream eligibility gate silently withheld, so that from the system's point of view the option never existed to be denied. These are the decisions that will surprise you in a deposition, because you will go looking for the record and discover there was never a place for one to live. The filter did its work and moved on, leaving nothing.

So instrument the filter, not just the funnel. Wherever your system narrows a population — culls a set, suppresses a candidate, withholds an option before it surfaces — that narrowing is a decision, and the honest move is to create the decision object at the point of the cut rather than assume one already exists downstream. Do not wait for the surviving records to explain the ones that did not survive; the survivors, by definition, cannot. The excuse you will hear, and may be tempted to give, is "we don't have a row for that" — the case never became a record, so there is nothing to produce. Reject that framing. The missing row is not the reason you cannot account for the decision. It is the decision going unaccounted for. That absence is not a gap in the evidence; it is the bug.

You will not record every filter with the same rigor, and you should not try — a system that writes a full decision record for every item it declines to show would drown in its own telemetry. Tier by stakes. The high-consequence cuts, the ones that decide a person's access to credit or employment or a market, get the full first-class record with inputs, rule, and margin. The low-stakes ones get a lighter touch. But make that a choice you made and can defend, not a default that fell out of what happened to be easy to log. The point is not to record more. It is to stop recording in inverse proportion to need — to make sure the decisions you keep are the ones you will be asked about, and that the noes, the ones most likely to be challenged and least likely to have left a trace, are the ones you can put your hands on first.

— Dispatches · Summit Cognitive