Academy

Every action carries its reason

Most systems record what changed. The thing you can never reconstruct later is why — so we make the reason a mandatory part of every change, captured the moment it happens.

The Felesh team 6 min

Open the history of almost any system, and you can see what happened. A status moved from open to closed. A price changed. A record was created, then archived. The trail of facts is usually intact.

What is almost never there is why. Why did the status move? Who decided the price should change, and on what basis? The change is recorded; the reason behind it is gone.

A history that records what, never whyThree history entries from 14 June: ticket #2210 moved from open to closed at 09:17, the price of SKU-31 moved from 480 to 520 at 11:05, and note #77 was archived at 11:20. Each entry has its fact recorded in the what column; the why column beside every one is empty, marked with a question mark.what was recordedwhy14 Jun 09:17ticket #2210: open → closed14 Jun 11:05SKU-31 price: 480 → 52014 Jun 11:20note #77: archived???facts survive in the trail; the reason is nowhere in it
The trail keeps every fact that changed, and nothing in it says why.

We treat that gap as the central problem, not a detail. A system that acts on your behalf should be able to answer not only what it did, but why it did it — and the why has to be captured at the moment of action, not reconstructed afterwards.

The one thing you can’t get back

You can rebuild a lot of things after the fact. If a number is wrong, you can recompute it. If a record is lost, you can often restore it from a backup. State is recoverable, because state is just the latest value, and the latest value can be derived again.

Reasons are different. A reason lives only in the moment a decision is made. Once that moment passes, the most anyone can do is guess: read the surrounding facts, infer a plausible motive, write it down as if it were the truth. But an inferred reason is a reconstruction, and a reconstruction is not evidence. It is a story told after the fact to make the past look intentional.

State comes back, a reason does notTwo lanes the day after a price change. State: the SKU-31 price reads unknown, then is recomputed as 520 or restored from a backup. Reason: the question why was it 520 has no backup behind it, and all anyone can produce is a guess, matched a rival, marked inferred, not evidence. A reconstruction is a story, not evidence.next daybackstopstatelatest valueSKU-31 price = ?SKU-31 price = 520recompute, orrestore backupreasonone moment onlywhy was it 520?guess: a rivalinferred onlyno backupfor a reasona reconstruction is a story, not evidence
Recompute a wrong state and it is fixed; a reason that was not written down can only be guessed at.

This is why we call the reason the irrecoverable property. Everything else in a system has a backstop. The why has none. If you don’t capture it as it happens, it is gone — and no amount of later effort brings back something that was never written down.

One path in, and it asks two questions

The way we protect the reason is structural, not procedural. We don’t ask people and agents to remember to log their reasoning. We make it impossible to change anything without it.

Every change to the system flows through a single authoring path, and that path asks two questions before it lets anything through: who is making this change, and why. An author and a reason. A change that can’t answer both simply doesn’t happen — there is no side door, no raw write that skips the question. The reason isn’t metadata attached afterwards; it is part of the same action that makes the change, recorded together or not at all.

That applies to people and to the AI equally. When one of our agents acts, it authors through the same path and answers the same two questions. There is no privileged channel where automation gets to change things quietly. The seal is the same for everyone who touches the system.

One path in, two questionsThree changes approach one authoring path. Reza, a person, changes the SKU-31 price to 520 because a rival has that price. The support agent closes ticket #2210 because the fix was seen. Both pass the two questions, who and why, and land in the history with author and reason. A raw write to SKU-31 with no author and no reason stops at the gate and nothing is written.changeshistoryReza, personSKU-31 → 520why: rival 520support agent#2210 → closedwhy: fix seenraw writeSKU-31 → 99who? why? noneone path inwho?why?same for peopleand the AIrefusedRezarival pricethe agentfix seennothingwrittena change that cannot answer both does not happen
A person and an agent go through the same path and answer the same two questions; a write with no answer never lands.

What traceability buys you

When the reason travels with every change, the whole system becomes a glass box. You can point at any fact in it — any value, any state, any record — and ask “why is this the way it is?” and get a real answer, not a guess. The answer was written by whoever made the change, at the time they made it, as a condition of making it at all.

That is what accountability actually means in practice. Not a promise that the system is well-behaved, but the ability to check. You don’t have to trust that the right thing happened for the right reason; you can look. And because the same rule binds the AI as binds a person, you can audit the automated decisions exactly the way you’d audit a human one.

It also changes what “fixing a mistake” looks like. When something is wrong, you don’t start from the broken value and work backwards through speculation. You read the reason that produced it, and the reason usually tells you immediately whether the logic was faulty, the input was bad, or the decision was simply wrong. The why is the fastest path to the fix.

From a wrong value to its fixThe SKU-31 price reads 520 and someone asks why. The reason on record answers: author Reza, 14 Jun 09:17; why, a rival is listed at 520; source, the price-feed. That points to one of three causes, logic faulty, input bad or decision wrong, and here it is input bad. The fix is the stale feed, not the price.SKU-31 price= 520why?reason on recordauthorReza, 14 Jun 09:17whyrival listed at 520sourceprice-feedlogic faultyinput baddecision wrongstale feed: fix the feed, not the price
Read the reason behind a wrong value and it tells you whether the logic, the input or the decision failed.

Where this stands

This is how we build, stated plainly. The system it describes is in active design — a direction we’re committed to, not a deployed product with numbers to quote. We’re describing the principle we hold ourselves to while building, because we think the principle is the part worth judging us on.

We’d rather be measured by the rule than by a demo. A demo shows you a good day. The rule — that nothing changes without an author and a reason — is what holds on the bad ones.

Trust in a system that acts for you doesn’t come from being told it is trustworthy. It comes from being able to ask, of anything it has done, why — and getting an answer that was true when it was written. That is the property we build around, and it is the one we refuse to give up.