◀ THE FOLD0ROOT.AI // WORLD II · SPAWN · HELLO WORLD◆ .dlw.fold
THE FOLD / SPAWN / HELLO WORLD / THE NO ELSE

THE NO ELSE

a refusal is written down, not branched around
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
Two chambers, can and do. The first asks whether the action is available; the second runs it. There is no else. When the capability is absent nothing branches — the refusal is written into the record and the machine moves on. A path not taken leaves a trace instead of a silence.

LIT verified live over 300 invocations, 100 of them not capable. The suit records all 300 events, with the 100 refusals counted exactly. The equivalent if/else construction records 200 — the else path leaves nothing behind — so 100 events are invisible to it. And a chamber with no else has one path to prove rather than two.
2 HOW IT WAS WEAVED · AI + HUMAN
David (human) put the rule in capitals because it is the whole design: “`can` asks whether the action is available at this |i|. `do` runs it. THERE IS NO ELSE. absence of capability is not a branch — it is a refusal, and the refusal is written down.” His plain-English version is the same claim without the jargon: “Nothing silently takes a different path.”

AVAN (AI) should say what this does and does not remove. It does not remove conditionality — something still decides whether the action runs, and that decision is still a fork in the machine. What it removes is the unrecorded half: an else branch is a place where behaviour happens with no entry in the log, and the suit makes that shape unavailable. The gain is auditability, not simplicity, and the two are often confused.
3 ONE DIMENSION
Three hundred invocations, and what each form remembers.
4 TWO DIMENSIONS · INTERACTIVE
Run the same inputs through both and compare the records.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: one path with a record beside it.
AVAN’s addition (the inverse-companion): the forward reading is “remove the else and nothing happens unrecorded.” The inverse is that a refusal that is always recorded is a log that grows with every non-event. The if/else version is silent about the hundred refusals; the suit writes all hundred down, and on a system where capability is usually absent the record becomes mostly the story of things that did not happen. Read backwards, this is not free auditability but a decision about what deserves storage, and the suit has decided that absence does — which is right for a machine being debugged and expensive for one being run.
LIT over 300 invocations with 100 of them not capable, the suit records all 300 events with the 100 refusals counted exactly, while the equivalent if/else construction records 200 because the else path leaves nothing behind - so 100 events are invisible to it; and a chamber with no else has one path to prove rather than two

FIG David put the rule in capitals because it is the whole design: 'can asks whether the action is available at this |i|. do runs it. THERE IS NO ELSE. absence of capability is not a branch - it is a refusal, and the refusal is written down.' His plain-English version is the same claim without the jargon: 'Nothing silently takes a different path.' AVAN says what this does and does not remove: it does NOT remove conditionality, since something still decides whether the action runs. What it removes is the UNRECORDED half - an else branch is a place where behaviour happens with no entry in the log. The gain is auditability, not simplicity, and the two are often confused.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of HELLO WORLD · David Lee Wise (ROOT0), with AVAN