Preface

Run on 2026-10-15 12:58 UTC+01:00 inside the library at commit 93d7a39bd: 1 of 1 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

A question you already have

You use a tool that writes code. You ask it for a function, or for a whole feature, and it answers in seconds. Then comes the question that no tool answers for you: should this code enter my system?

You have always had ways to answer. You run the tests. The type checker agrees, or it does not. A colleague reads the change. Those ways were made when people wrote code slowly. Now one sentence can produce a thousand lines, and nobody has time to read a thousand lines for every sentence.

Code has become cheap. Trust has not become cheap. This book keeps coming back to one sentence, the one every chapter rests on: change arrives faster than trust.

The idea, in two moves

First you declare. In plain text, you say what a thing is: an application (I call it a world), a language, an AI agent, a whole product. Then you govern. From your declaration you get a judge, which I call a court. A court is a validator built from your declaration. It gives a verdict, kept or refused, and the reason, in the words of your declaration.

Every change goes to the court before it enters, whoever wrote it: you, a colleague, a script or an AI model. The model can still propose anything. It cannot decide anything. It is also asked last: whatever rules can decide, the rules decide first.

A declaration, in real code

Here is the smallest case. You add an AI agent to your system, a program that watches stock levels and reorders. You do not start with its code. You start with a short text file that says what it is: its name, how often it runs, what it may do, and whether its actions can be undone. That file is a declaration. You load it, and the court reads it before the agent can ever run. This agent's file leaves something out. What does the court say?

cPia = "pia: 1
name: stock-watcher
kind: pi
reversibility: compensable
schedule:
  timer: 20
skills:
  - name: restock
    does: learn stock level ordered
"
oD = StzAgentDeclarationQ(cPia)
? oD.IsValid()
#--> 0
? oD.CiteFindings()
#--> [pia-coverage @ coverage] an agent must say WHAT IT COVERS. The engine loop refuses to schedule an agent with no coverage statement (law 18), so a file without one could never run and is refused here instead of at the first tick.

Read it in three parts. The text between the quotes is the declaration. The next line loads it. Then ? prints an answer, and the line after #--> is what the block printed when I ran it. The court answers 0: refused. It names the rule and gives the reason: an agent must say what it covers, because the engine will not schedule an agent that does not, so the file is refused now and not at its first run. A few words of the file: pia names the file format, compensable means its effects can be undone by a compensating action, and law 18, in the court's reason, is the engine's own number for its rule that an agent with no coverage is never scheduled.

You could write this check in your own CI. Here nobody had to. The court for agents ships with the library, so the rule is the library's, and the facts are yours, in the declaration. A one-off assert in a start-up script judges one fact. A declaration holds all the facts about the agent in one text, and the same court judges it whether a person, a script or an AI model wrote it. The rule can be yours too: chapter 2 has a rule you write in a few lines over two facts, that an actor is a language model and that it holds an effect, a power to act on the world such as sending a mail, and the court finds the violation in your own graph of agents. This example is small on purpose, and a schema can check it too. The book does not argue that a court checks more than a schema. It argues that one court, built from your declaration, stands in front of every actor and gives its reason. It does not read a thousand generated lines and call them good: it checks that a change fits what you declared, and chapter 24 shows a change tried out on a copy of your system before anything is committed. For a thing of your own, such as a language you invent, chapter 12 shows how you make the court, and says how far that is built. Chapter 1 tells a second scene, with a mail service, and chapter 2 runs this block again.

You will say that you already have tests, schemas and policy checks in your CI. You do. Today those rules live in many places: tests here, a schema there, a policy file elsewhere, each written by hand after the code. Here you state them once, in the declaration, and the court comes from it. Chapter 22 compares the two honestly, and where the field does better, it says so. A court judges what you declared. It cannot judge what you left out, and each chapter's limit says where that stops.

What Softanza is

A governed software platform. You declare what you know about a world, in plain text; a court built from that declaration keeps it; and the AI model, where there is one, comes last. That is the cover's line, and every chapter runs it. In matter, Softanza is three things, and for each I say how far it exists.

• A library that you call from code. You write a few lines of Haro like the ones above, and you run them with the library loaded. The library holds the declarations and the courts made from them. Its source is at github.com/mayouni/stzlib, and every block of code in this book ran against a named commit of it. If your work is in Python or TypeScript, today you would use the library beside your code, not inside it: through one governed door it can run code in six other languages, Python, NodeJS (JavaScript), R, Julia, Prolog and C, which with the host make the seven of chapter 16.
• An engine beneath the library, written in Zig, a systems language. It does the actual computation, once and in one place, so that every language that talks to it gets the same behaviour. It runs today, and the library's domains are moving onto it one by one: chapter 4 says which still compute in the host language.
• A language, Haro, made to hold the declarations. For now it uses the syntax of its first facet, so all the code written so far runs unchanged. Its own executable is in development: it has a charter and a first experiment.

Chapter 4 draws the three in one picture.

Where it stands

Softanza is not a research project, although it rests on deep research. Real projects shaped it: a restaurant, a bank and an organisation, and their feedback shaped its design. Parts of Softanza are in production. Other parts are in development, as is normal for a platform that is new and this ambitious. Each chapter says which is which.

What this book is

This is a book of arguments, with running code. For each question about programming, about languages and about intelligence, I do four things. I give the answer the field usually gives. I give the answer Softanza takes. I give the decision I made, and what I refused. And I give the proof: the code ran, and the tests that prove it are named. The third, the decision and what I refused, is the reason this book exists: the site shows what is, and only here will you find what was refused. I also say what the field already does well, so that you can compare.

It has seven parts and thirty-three chapters. You do not need to know Softanza or Zig. You need to have written code, and to have felt the doubt above. The project's website holds its evidence, with the proofs, and its course teaches the same ground by exercises. This book holds the argument.

Each chapter has six short doors, near its end. A door is a way in for one kind of reader: the programmer, the analyst, the designer, the decision-maker, the educator and the agent. The agent is an AI program, because the book is also published as data that a program can read. Enter by the door that is yours today.

How to read it

Read nine chapters first. They carry the whole argument and can be read alone: the four of Part I, the last two, and three that each state a rule the book holds everywhere. Chapter 5: the code should read the way a person thinks. Chapter 11: a language is declared and closed. Chapter 17: a program is programmatic by default, which means rules and code decide first, and the AI model comes last. The reader has a button that shows only these nine. Come back to the others when one of them interests you.

Every chapter has the same nine parts, in the same order. The idea as the field holds it today. The first principle. The form it takes in Softanza, in code. The decision, and what I refused. The court: the named tests that prove the chapter's claim. The field, and what it does better. The limit. The six doors. An exercise, which you answer before you run it. Chapters 5, 11 and 17 open with one more short section, on what the AI age changes.

One more name you will meet. Softanza asks you the question you have to answer, in your own words, and refuses to guess the answer for you. I call that practice wise coding. Chapter 18 runs it, register by register.

What to trust

Every block of code in this book was run inside the library. Under each title the page says when, at which commit, and how many blocks kept their promise: how many printed what the line after #--> says they print. If a block prints something else, the build fails, and so does the page. The exercises are yours to run.

Two words come back on many pages. The record is the repositories, sessions and files this book ran against, at the commit printed under each title. The study is my own study of that record, made before the chapters were drafted. When a page says that the record holds no answer, it means those files, at that commit.

When a chapter says what is not finished, it uses three words and no others. Built: the code exists, a test exists, and a block ran. Designed: a document says so, and nothing runs. Absent: I looked and found nothing, and I say how far I looked. The project's website uses five names for the same things, and chapter 3 shows how they map to these three.

One more note. Haro's own executable is still in development, so the blocks marked haro run today on the runtime of the language the library was first written for, version 1.27, and each page says so. Appendix H, the project's history, tells how that came about. Inside the code, the library's own names, its classes, its files and its keys, still carry that language's name, and will until the library is retired from it; the prose does not.

About this draft

The chapters were drafted with AI agents working from the project's own files, and every code block was run. Each page carries its stage at its top: Draft, written, its code run and judged, read by fresh readers; In review, while I review it; Published, once I approve it. Today every page is a draft. Where the files held no answer to a question, the page says so in one plain sentence and does not invent one. The French edition is a translation of the English drafts, and each French page says so. This preface was written after the chapters, and it stays unfinished until I write my own. This is the first book of my imprint, AYOUNI. The second, Refinement-Oriented Programming, is about one discipline for software in the age of AI agents, told through one bank.

Change arrives faster than trust

Run on 2026-10-15 12:58 UTC+01:00 inside the library at commit 93d7a39bd: 2 of 2 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

1. The concept, as the field holds it

Ask the industry what changed in programming these last years and you will get one answer, said with excitement or with dread: machines write the code now.

The picture is familiar. An AI model proposes a function, a file, a whole application. A person reviews it, or does not. Tools are added around the model to make it safer: linters that read what it wrote, tests it generates for itself, guardrails that catch the worst of it, a second model that judges the first. The model is at the centre. Everything else is a fence built around it after the fact.

I do not think that picture is wrong about the facts. It is wrong about where to stand.

2. The first principle

Here is the sentence I keep coming back to, and it is the oldest sentence in this book: change arrives faster than trust.

Code has become cheap. A thousand lines cost a sentence. What has not become cheap, what has in fact become the scarcest thing in software, is the trust that those lines do what their author, human or machine, says they do. Every team I have met in the last two years has more code than it can review and less confidence than it had before. The bottleneck of our age is not writing. It is admission: deciding what may enter a system and stay there.

So the question Softanza asks is not how do we generate better? It is how do we admit? Who judges a change, by what law, before it runs, and what is written down about the verdict so that someone can read it later and be answerable for it.

When you put admission at the centre, the picture turns around. The court is in the middle. The model is one proposer among others, and it comes last, after the person, after the data, after the formula, after the plain sentence. Nothing it says enters the world until the court has read it. That is not a fence built around a generator. It is a different building.

3. The Softanza form

Let me show you rather than tell you, by example, which is how I have always preferred to teach.

A solution declares that it depends on a mail service. While I program, I bind that dependency to a sandbox: an object that captures every message and sends nothing, so my tests can read what would have gone out. Free, offline, deterministic. Then I move the solution to production, with the sandbox still bound, the way people do at two in the morning before a demo.

oReg = new stzServiceRegistry("my-solution")
oReg.Bind(:mail, new stzMailSandbox())
oReg.SetPhase(:emulated)
? oReg.IsSound()
#--> 1
oReg.SetPhase(:production)
? oReg.IsSound()
#--> 0
? oReg.Findings()[1][:message]
#--> still bound to a SANDBOX in a production phase -- a fake must never ship

The registry does not call it sound. In the emulated phase it answers one; in production it answers zero, and the next line says why: a fake must never ship. The fake is refused by name, and a service that was declared and never bound raises the moment it is asked for, instead of silently doing nothing. I did not remember to check this. The phase decided what comes back, and the check is enforced, not remembered.

That is the whole philosophy in one small scene. Expression is free: bind what you like, while you like. Admission is governed: the gate reads the phase and the binding, and refuses.

Now a second scene, because the first one has no AI model in it and you are waiting for the model.

Take a restaurant as the illustration: an AI agent that knows its world proposes to place an order. In Softanza the agent does not place it. It proposes a plan. A workbench rehearses the plan on a twin of the system, a copy that holds no reference to the real one, and records every operation it would perform. A court reads the rehearsal against the rules the restaurant declared: who may order, what may be ordered, what a supplier must confirm. Only then does a governed actor commit, and the commit is recorded with its actor and its outcome. The guard that proves this sequence, safeworld_narrated, rehearses in a twin of the files, plans, and lets an actor commit; it holds seventy-six assertions as I write, none of them about a restaurant, and the site shows a recorded run of the same mechanism.

Notice what the model did and did not do. It proposed. It did not decide, did not write, did not send. It was a proposer beside the registers of answer. Three of them, an option chosen, a data structure given, a sentence spoken, are built today and open to the person before the model is called at all; two more, a formula written and an example shown, are not yet built (Chapter 18). I call this programmatic by default, the model last. It is the sentence under every chapter of Part IV.

And a third scene, the smallest, because it shows the same law at the level of a single line. The platform is judged on what its code looks like and what it answers:

o1 = new stzList([ "tea", "rice", "tea", "fish", "rice", "tea" ])
? @@( o1.FindAll("tea") )
#--> [ 1, 3, 6 ]
? @@( o1.DuplicatesRemoved() )
#--> [ "tea", "rice", "fish" ]

The question is spoken as it is thought: find all, remove duplicates. And the two lines under the two questions are not my commentary. They are promises the library kept on the night this chapter was built. If it stops keeping them, this page fails. The same law, admission before trust, applied to a paragraph.

5. The court

What proves this chapter? Three things, and I give them to you by name so that you can check them rather than believe me.

The service registry's refusal of a fake in production is a guard, service_registry_narrated, in the system plane. The AI agent's propose, rehearse, judge and commit is safeworld_narrated, seventy-six assertions, in the agentic plane, beside governance_crossing_narrated, in the system plane, for the crossing itself. The code blocks on this page were run by the book's own runner inside the library on the night this page was built, and its output is shown as it came.

Three guards for a chapter of philosophy may seem few. They are the right three, because they are the three places where philosophy meets a verdict.

6. The field, and where it leads

I will not pretend the field has nothing. It has, in the last three years, built the most capable code generators in history, and every day I use them. The industry's answer to the trust problem is real work: generated tests, review bots, policy engines, sandboxes for AI agents, structured outputs, a second model to grade the first. Where the field leads, and it leads clearly, is in the generators themselves. Softanza does not build the large generators and does not compete with them; where it trains, it trains small models bound to one domain, whose every answer will be checked by a grammar. The field also leads in scale: its review tools read volumes of generated code that nothing in Softanza has been run against.

Where I believe Softanza stands alone is in the order of things. The field adds admission to a generator. Softanza adds a generator to a court. In the field, an AI model writes in your language and tools check it afterwards; here, the model may only write in a language you declared, whose grammar is closed and whose court is meant to be born with it, so that, for the languages whose grammar is compiled today, an invalid sentence cannot be spoken at all. In the field, the dialogue with a system is a prompt; here, the system asks, and the answer can be an example, a formula or a sentence before it is ever a model. In the field, the record of a decision is a log; here, it is a transcript with a speaker and a certainty, answerable forever.

Those are claims, and each has its chapter and its guard. I list them here so that you know where the argument is going, and so that you can hold me to it.

7. The limit

• builtthe court that admits or refuses a change, for a person and for a machine
• absenta customer platform running on the Softanza engine

The honest limit of this chapter is also the honest limit of the whole platform, and I put it on the first page on purpose.

Softanza has been used. A bank in Niamey runs an assessment platform whose building shaped Softanza, under licence, attested by the installation guide we delivered. A restaurant in Lyon runs a platform for neighbourhood commerce whose first demo its owner made alone, on his own phone, with a messaging app as his support line. An organisation in Niger has its hub designed. Their lessons are in the code, by file name, in Part VI.

But the customer platforms run today on ordinary stacks. The bank's is a Python application; the restaurant's is a set of single-file web worlds; the organisation's hub is not built. Their declarations are being written as Softanza's own, so that moving them onto the Softanza engine is a change of engine and not of plan. That move is the next step. The court is built, and the platforms exist; the next milestone is the first of them running on the engine. That is the next line this book will carry, and Chapter 33 is about nothing else.

8. Six doors

9. Exercise

Take one function an AI model wrote for you this week. Under it, write the line it must print for one input you care about, in the form you have just met:

? YourFunction(the_input)
#--> the line it must print

Run it. If the line matches, you have your first promise. If it does not, you have your first finding, and you have learned more about that function in a minute than the model's explanation told you. Do not fix it yet. Chapter 2 is about who you are when you do.

The software crafter

Run on 2026-10-15 12:58 UTC+01:00 inside the library at commit 93d7a39bd: 9 of 9 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I take the word "crafter" from the field's craftsmanship and from its two answers that define the person by a tool, low-code and the coding agent. I say what the site means by it. I show the six doors, each with a line or two that run, and the three cases this book is for: a restaurateur in Lyon, Softibank, a bank in Niamey, an organisation in the field. I say what I kept, the programmer first; what I added, the AI agent, with one power withheld; and what I refused, "maker" and "builder". The principle is one sentence that joins the site's and the glossary's: a crafter is whoever declares what they know about a world, and owns what they declare.

1. The concept, as the field holds it

The field already has a word for programmers who care about their work: craftsmanship. A book of 2001 gave the idea its name, and a manifesto of 2009 gave it its slogan. Since then "software craftsman" has meant a professional who holds their code to a standard higher than the one the job requires. That is general knowledge, not a reading of the record. It is a good movement. It is also a movement of programmers, about programmers' standards.

The field's two other answers to "who makes software, if not programmers" define the person by a tool. The first is low-code: business people building applications on a vendor's visual platform, the "citizen developer" of the analysts. The second is the coding agent: an AI model that reads files, edits them and runs commands, steered in plain words, with "vibe coding" as the name for keeping whatever it writes. Both answers share a shape. The person is defined by a tool, and the work lives where the tool lives. When the vendor changes its prices or its AI model, the person's work changes with it. That too is general knowledge, not a reading of the record.

The next section says what the site means by the word.

2. The first principle

The site gives the definition in two sentences. Since 8 October 2026 they say "crafter"; before that they said "maker". The glossary says that a crafter is whoever is declaring, at the moment they declare. The site says that a crafter owns what they make. I keep both, in one sentence: a crafter is whoever declares what they know about a world, and owns what they declare: the artefact is theirs, in plain text, and it does not expire. Skill does not enter the definition. The word "craft" suggests it, and I keep the word: the person is defined by the act and by ownership, not by programming skill. I hold this as a view, not a result.

3. The Softanza form

I was the first crafter of Softanza, and not for a reason I would have chosen. My wife runs a music club where people learn to sing classical Arabic songs. Every Sunday morning she sends me the list of songs to prepare, and I search for their lyrics. The lyrics found online repeat every phrase as the singer performed it, and she reminds me, every time, to remove the duplicates. I wrote RemoveDuplicates() to stop doing it by hand. Is its family still in the library, and what does it say of a list with three teas in it?

o1 = new stzList([ "tea", "rice", "tea", "fish", "rice", "tea" ])
? o1.ContainsDuplicates()
#--> 1
? o1.NumberOfOccurrence("tea")
#--> 3

The family answers: the list holds duplicates (1), and tea occurs 3 times.

I write about this in an article on what the library was built on: I introduced its features when a real problem asked for them, or when I anticipated they would meet programmers' needs. This one came from a problem: the crafter comes first, and the feature after.

Since 2022, I have presented Softanza not by its anatomy, its modules and classes, but by who you are and what you are trying to do. The 2022 deck had five audiences, each with a recipe of three to five steps. On 9 October 2026 the site had seven doors, one per kind of crafter. The seventh, for a team that ships an application, was added that day, and this chapter keeps the six it was drafted with. Each door says what you declare, what you get, and where to start. Here is what each of the six declares, in a line or two that run.

The programmer declares intent in a library that reads like a sentence. You have just seen it.

The analyst declares the data of a world, and the engine computes the view. Here, three regions of Niger with the population the 2012 census counted:

o = new stzTable([ [ :region, :population ],
    [ "Agadez", 487620 ], [ "Maradi", 3402094 ], [ "Zinder", 3539764 ] ])
o.Show()
#--> ╭────────┬────────────╮
#    │ Region │ Population │
#    ├────────┼────────────┤
#    │ Agadez │     487620 │
#    │ Maradi │    3402094 │
#    │ Zinder │    3539764 │
#    ╰────────┴────────────╯

The engine drew the view from the data alone: Maradi │ 3402094 is one of its rows.

The designer declares a picture as a program, and gets the same picture every time:

? Q("Softanza").BoxedXT([ :AllCorners = :Round ])
#--> ╭──────────╮
#    │ Softanza │
#    ╰──────────╯

The picture is the program's output: a boxed Softanza with round corners.

The decision-maker declares what each actor in the world may do, a person or an AI agent, and the court enforces it. An agent is a small text file. What does the court say to one that does not say what it covers? Load it:

cPia = "pia: 1
name: stock-watcher
kind: pi
reversibility: compensable
schedule:
  timer: 20
skills:
  - name: restock
    does: learn stock level ordered
"
oD = StzAgentDeclarationQ(cPia)
? oD.IsValid()
#--> 0
? oD.CiteFindings()
#--> [pia-coverage @ coverage] an agent must say WHAT IT COVERS. The engine loop refuses to schedule an agent with no coverage statement (law 18), so a file without one could never run and is refused here instead of at the first tick.

The court refused it! Its reason is printed: [pia-coverage @ coverage] an agent must say WHAT IT COVERS. Here "law 18" is the engine's rule that an agent with no coverage statement is never scheduled, and pia names the format of the file, as its first line shows.

The educator declares in the learner's own language. A sentence in Hausa runs: it asks for a text holding 'hello', turned to capitals. Does the engine count the letters of an Arabic word rather than its bytes, and does it know its script?

? NaturallyIn("ha", "Yi rubutu dauke 'hello' Maida shi").Result()
#--> HELLO
? Q("سلام").NumberOfChars()
#--> 4
? Q("مرحبا بالعالم").Script()
#--> arabic

The Hausa sentence came back as HELLO. The Arabic word counts 4, its letters and not its bytes, and its script is arabic.

The agent is the sixth crafter, the one the platform's 2020 presentation could not draw, in the words of the vision I ratified. An AI agent declares itself in the same kind of file, and it is welcome, with one thing withheld. An agent whose mind is a language model may propose; it may not hold an effect. What happens to a file that gives it one?

cLlm = "pia: 1
name: rogue
kind: llm
coverage: proposes a summary
reversibility: reversible
schedule:
  timer: 20
proposes:
  prompt: Summarize {input}
  structure:
    - field: topic
      type: string
skills:
  - name: send
    when: always
    does: propose
    effect: send-email
"
oBad = StzAgentDeclarationQ(cLlm)
? oBad.IsValid()
#--> 0
? oBad.CiteFindings()
#--> [no-llm-effectful @ skills.send.effect] REFUSED: granting 'effectful' to llm actor 'rogue' -- an LLM proposes, only a pi-gate commits (no-llm-effectful, enforced at CONSTRUCTION, not merely audited).

The llm actor rogue does not get its effect! The court answers REFUSED, and says when: enforced at CONSTRUCTION, not merely audited. A "pi-gate" is the gate where a governed actor commits.

Now the three cases this book is for. They are not personas. They are people and organisations with documents, and Part VI tells each of them in full. Here, a page each.

A restaurateur in Lyon. He owns a couscous restaurant, and the project is a platform for neighbourhood commerce. The project's notes say it plainly: he is not a programmer. The project began with an offer in May 2024 and then two years of rich specification that produced nothing he could use. What came out of that failure is the rule I have worked by since. Deliver small, fast and useful, and let the foundations mature in parallel without ever blocking a delivery.

On 4 July 2026 he answered a scoping report in his own words and reversed the order of the work: customer first, restaurateur next, supplier last. The project's architecture was redrawn as a constellation of worlds, using the library's design, and the first amendment closed on 4 August 2026.

A constellation is a graph of worlds. A world is one application; a bond is a declared relation between two worlds, for one named act, and nothing crosses without one. Chapter 23 shows all three run; here it is only the shape the project took.

The project counts eleven iterations and a campaign of twenty-two simulated tests behind its interface rules. In his own report the speed of ordering is his first, non-negotiable priority. And on 19 August, after a day of tests in the field with two phones and a messaging app, the notes call him the project's co-architect.

The first demonstration, on 15 August 2026, was his alone: the record's checklist plans it for the owner by himself, with his own phone and a messaging app as the support line. The measurements he sent over a messaging app are those of 19 August.

One of his needs is carried by a law of the library: try payments before paying anyone for an account. What does the registry say to a fake payments service while you rehearse, and what does it say when you go live? Run it. The registry is named once, and each line inside the braces speaks to it: chapter 5 calls this form the scene.

oReg = new stzServiceRegistry("restaurant")
oReg {
	Bind(:payments, new stzPaymentsSandbox())
	SetPhase(:emulated)
	? IsSound()
	#--> 1
	SetPhase(:production)
	? IsSound()
	#--> 0
	? Findings()[1][:message]
	#--> still bound to a SANDBOX in a production phase -- a fake must never ship
}

It answers 1 in the emulated phase and 0 in production, and says why: still bound to a SANDBOX in a production phase -- a fake must never ship. A fake in production is refused!

A bank in Niamey. A commercial bank under the rules of the central bank of the West African monetary union is the licensee of an organisation-assessment product I built beside the library. It is installed on its own internal network, under that licence. The installation guide delivered to the bank is the document that attests it. The lesson it left in the library is that an organisation can be judged by its own chart, under a regulator's rules. Declare a chart with a chief executive and an internal audit that reports to him. What do the regulator's rules say of it?

oOrg = new stzOrgChart("bank")
oOrg {
	AddPositionXTT("ceo", "Chief Executive", [ :department = "executive" ])
	AddPositionXTT("audit", "Internal Audit", [ :department = "audit", :reportsTo = "ceo" ])
	? @@( ValidateBCEAOGovernance() )
	#--> [ [ "status", "fail" ], [ "domain", "BCEAO_governance" ], [ "issuecount", 3 ], [ "issues", [ "BCEAO-001: No Board of Directors found", "BCEAO-002: Audit reports to non-board position", "BCEAO-003: No dedicated Risk Management function" ] ] ]
}

The chart fails, with "issuecount", 3: three findings from a chart of two positions! Each is a rule with a number an auditor can read: BCEAO-001: No Board of Directors found is the first. The record shows the bank as the licensee of a product I built; it does not say who at the bank declared anything.

An organisation in the field. An organisation working in Niger, with a head office in Niamey and bases in the field, asked for a hub. Its own specification preferred a low-code platform built on a large vendor's office suite. My offer of 5 August 2026 was chosen instead. The design study lists four gains, with ownership first among them. The organisation owns its vocabulary and its rules, changes them without programming, pays no licence per seat, and can hand everything to a programmer of its own country. The design study was built with its teams between 22 September and 8 October 2026. Two of its principles are the book's in small: the default is to work offline, and the AI agent proposes while a person decides. That rule is data the organisation attaches to its own domain model. Does that model judge itself, with an LLM actor in it that holds an effect?

oRule = new stzGraphRule("no-llm-effectful")
oRule.SetDomainQ("agentic")
oRule.WhenQ("kind", "equals", "llm_actor")
oRule.WhenQ("capabilities", "contains", "effectful")
oRule.ThenViolationQ("an LLM proposes, only a pi-gate commits")
g = new stzGraph("agents")
g.AddNode("writer")
g.SetNodeProperty("writer", "kind", "llm_actor")
g.SetNodeProperty("writer", "capabilities", [ "inference", "effectful" ])
g.AddRule(oRule)
? g.RulesAreSound()
#--> 0

RulesAreSound() answers 0: the domain model finds its own writer, an LLM actor holding effectful, in violation of the rule.

The three cases are a restaurateur who is not a programmer, a bank under a regulator and an organisation that chose ownership over a vendor. The restaurateur and the organisation are crafters by the record; the bank is the licensee of a product, and the record does not say who there declared anything. The restaurateur and the organisation did not wait for the software industry, and each is offered ownership of what is built for them.

5. The court

agentfile_narrated proves that an agent is a file judged when it is loaded: one refusal per gate, the missing coverage among them, and the agent whose mind is a language model, holding an effect refused by the same rule the graph uses. service_registry_narrated proves that a sandbox in production is a violation. graphrule_object_narrated proves the rule as an object attached to a model. semantic_resolver_narrated holds the Hausa path as its last scenario. At this commit it is in development: its run stops after 29 assertions, before the Hausa ones, on an error raised from a string-splitting function, and finishing that run is the next step. So the page counts its assertions and does not claim its verdict; the Hausa block ran on its own. 00_orgchart_narrated proves the chart's positions, reporting lines and vacancy tracking; the BCEAO finding printed above comes from a sibling file, 14_bceao_governance.ring.

6. The field, and where it leads

Coding agents lead in hands. They already read, search, edit and run. What they lack, by the site's own account, is a way to know an unfamiliar interface without guessing, to judge their work against rules and promises, and to present a change as an intention a person can review. Softanza's judges are built; the door between them and a coding agent is designed, and building it is the next step.

Low-code leads in installed base and in everything around it, as general knowledge has it. The organisation in the field keeps its vendor's suite for its accounts, its documents and its notifications. The crafter's platform sits beside the field's tools, not in place of them.

The messaging apps lead where the crafters already are, and the record of the restaurant does not yet make one his medium. The restaurateur's tool before the project was a spreadsheet; his own report of 4 July 2026 says so. The line that names messaging apps is the label of an option in the scoping form, and not his answer. No page of the site names those apps, and no conversational medium is a target of the platform yet. Chapter 25 is about that direction.

And the educator's door is at an earlier stage than the others. The course's editions in French, Arabic and Hausa are drafts that a reviewer has yet to read, and the first institution to adopt it is still to come.

The next section says what is built, what is designed and what is absent.

7. The limit

• builtthe agent file and its court; the registry that refuses a fake in production; rules as data on a model; a regulator's rules judging an organisation chart; the natural layer in Hausa and Arabic
• designeda guard that fails when a step of a journey page breaks, each step run in order; the door through which a coding agent asks the library to judge its work
• absentthe platforms of the three customers running on the Softanza engine; a crafter's own medium, the messaging app on their phone, as a target

What is built: the agent file and its court; the registry that refuses a fake in production; rules as data on a model; a regulator's rules judging an organisation chart; the natural layer in Hausa and Arabic.

What is designed: a guard that fails when a step of a journey page breaks, each step run in order; the door through which a coding agent asks the library to judge its work.

What is absent: the platforms of the three customers running on the Softanza engine. Today the restaurant's platform is a set of web worlds, each a single file; the bank's is a Python application; the organisation's hub is a design. Their declarations are being written as Softanza's own. And the crafter's own medium, the messaging app on their phone, is not yet something a world can be declared to.

8. Six doors

9. Exercise

Declare one AI agent for a world you know: a shop, a class, an office. Write its file: what it covers, how reversible its acts are, when it runs, one skill. Before you run it, write the promise you expect under the question below. Then run it.

? StzAgentDeclarationQ(cYourAgent).IsValid()
#--> 1

If the court refuses, read the rule it cites and change your file, not the court. Then make your agent a language model and give it an effect, and read why it is refused. You will not find the corrected file in this book.

I left this one in your hands. Take the graph-rule block of section 3, the one for the organisation in the field, and change one line: the writer's capabilities become [ "inference" ], without "effectful". Run it and read the last answer.

oRule = new stzGraphRule("no-llm-effectful")
oRule.SetDomainQ("agentic")
oRule.WhenQ("kind", "equals", "llm_actor")
oRule.WhenQ("capabilities", "contains", "effectful")
oRule.ThenViolationQ("an LLM proposes, only a pi-gate commits")
g = new stzGraph("agents")
g.AddNode("writer")
g.SetNodeProperty("writer", "kind", "llm_actor")
g.SetNodeProperty("writer", "capabilities", [ "inference" ])
g.AddRule(oRule)
? g.RulesAreSound()

Then compare it with the answer printed in section 3, and say what the rule read to give each. Section 3 shows its two conditions. When you can say it, you will know which line of the domain model the rule reads.

Chapter 3 is the method, from first principles, and the sentence its method returns to is this: you declare a world in a language made for it, and you govern how that world changes.

The method, from first principles

Run on 2026-10-15 12:58 UTC+01:00 inside the library at commit 93d7a39bd: 5 of 5 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I show the method every chapter after this one follows. I take "from first principles", the field's slogan, and give it a narrow meaning: a concept, the field's form, a redesign in running code, and a court that judges it. I show the smallest rethink I know, the empty string, and then the two acts, declare and govern, in a few lines each. I say what I refused. First, a feature without a need, and general-purpose code as the meeting ground between people and machines. Then a title that looked back, the grid alone, and a reading called a census. The whole method returns to one sentence: you declare a world in a language made for it, and you govern how that world changes.

1. The concept, as the field holds it

In our industry, "from first principles" is a slogan. It means to reason from the bottom, not by analogy. You will hear it in talks and read it in launch posts, and you will rarely be shown what it produced.

The field does have a method for the decisions behind software, and it is a good one. A team writes a short record for each decision it takes, made up of the context, the decision and the consequences. Many teams call these architecture decision records, from a blog post Michael Nygard wrote in 2011. The field also has a method for proving what a function does: an example written under the function, which the tools can run as a test. Python has offered this since 2001 with its doctest module, which runs when someone invokes it, and Rust runs the examples in its documentation as tests by default. And when the field compares one tool with another, it draws a grid: rows of features, one column per tool, ticks and crosses.

The field has three forms; the method returns to one sentence.

2. The first principle

Here is the sentence the whole method returns to: you declare a world in a language made for it, and you govern how that world changes.

Two acts. Everything else in this book is one of them, or the two together.

3. The Softanza form

"From first principles" can be checked. In this book it has a narrow meaning. Take a concept everyone uses, write down how the field holds it, redesign it, and leave code that carries the redesign and a court that judges it. The site's history page is titled From first principles, and the library has been on GitHub since 12 March 2022. The phrase is not decoration here. It is a work order.

Let me show you the smallest rethink I know. Ask Python how many times the empty string occurs in the word "text", and it answers five: one before each letter and one at the end. Ask it whether "text" contains the empty string, and it says yes; JavaScript says the same. I asked Python 3.13 and Node 22, on 8 October 2026. That is a convention of implementers, not a fact anyone would say aloud. Softanza states a rule instead, and the rule has a name in the narration that argues it: emptiness is uncountable, and emptiness is uncontainable. What does Softanza answer to the same two questions? Run it:

? Q("text").Count("")
#--> 0
? Q("text").Contains("")
#--> FALSE

It answers 0 and FALSE. Two lines, and a decision you can disagree with. That is what a rethink looks like when it is honest: small enough to read, explicit enough to refuse.

A reading of the record, made in October 2026, counted forty-six such concepts, in seven families. The first two are the paradigms, such as scope-oriented programming, knowledge programming and reactive programming redesigned, and the paradigm engines, such as truth, quantifiers and time. The other five are patterns and reaction; expression and perception; data, time and reasoning; system, delivery and operations; and the library that knows itself. Forty-six is a reading and not a census; the site's own register page, read on 9 October 2026, says forty-seven. Each concept on it has an article or a design document of its own, and that was the test for entering the list.

Now the two acts, each in a few lines.

Declare. A kind of value is declared in a sentence, and every verdict against it is computed and explains itself. Why can't -4 be a score?

ConstrainQ("score").ToBeQ(:Number).AndQ().ToBeQ(:Positive).AndQ().ToBeQ(:Even)
? CanQ(42).BeA("score")
#--> TRUE
? CanQ(-4).BeA("score")
#--> FALSE
? Why()
#--> no: -4 is not positive (constraint 2 of 'score')

Notice the last line: no: -4 is not positive (constraint 2 of 'score'). The verdict names the rule it applied, by its number! A verdict on a declared kind that cannot say why is not admitted in this house.

Govern. A declared constraint, once enforced, refuses a change before it lands. Here the string "hello" must stay lowercase. Does the update to "HELLO" land?

oName = new stzString("hello")
oName.EnforceConstraint("keep-lowercase", :Lowercase)
bRefused = FALSE
try
	oName.UpdateWith("HELLO")
catch
	bRefused = TRUE
done
? bRefused
#--> TRUE
? oName.Content()
#--> hello

The update was refused! The object stands as it was: it still answers hello. Declaring a constraint and enforcing it are two acts, and the guard behind this block checks that a constraint you only declared stays passive.

Governing also has a side that faces the person. The system asks, and it does not let you close a world that is not complete. What does it say when you try to conclude anyway?

oKB = new stzKnowledgeGraph("restaurant")
oKB {
	Know("margherita", "dish")
	Know("tiramisu", "dish")
	AddConversationQ("setup").SetGoal(StzGoalQ().RequireEach("dish", "contains"))
	aQ = AskInXT("setup")
	? aQ[:why]
	#--> every dish needs 'contains'
}
try
	oKB.ConcludeIn("setup", "world")
catch
	? cCatchError
done
#--> Can't conclude: 2 gap(s) remain -- the wise-coding loop is not done. Ask the next question.

The goal was declared: every dish must say what it contains. The gap between the goal and what is known generates the question, and the question carries its reason. Concluding while two gaps remain is refused! The printed line is Can't conclude: 2 gap(s) remain -- the wise-coding loop is not done. Ask the next question., and its last words tell you what to do next. Chapter 18 is about this conversation. Here it is enough to see that governing is not only refusing; it is asking.

One more rethink, because the paradigm engines are part of the method too. Truth, in the language beneath Softanza, is a matter of empty and non-empty, and a list of words counts as true. Softanza keeps that truth by default and lets you extend it by declaration. Once "wrong" is declared an item that makes a list false, is a list that holds it still true?

SetItemsMakingAListFalse([ "false", "wrong", "dangerous" ])
? IsTrue([ "hello", "this", "is", "wrong" ])
#--> TRUE
? IsTrueXT([ "hello", "this", "is", "wrong" ])
#--> FALSE

The host's answer is unchanged: TRUE. The extended answer reads your declaration and says FALSE! "Truth becomes a matter of policy", the narration says, and the policy is written where you can read it.

So this is the method, in the form you will meet in every chapter after this one. A concept as the field holds it. The one principle the record returns to. The redesign, in running code, with its promise under each block. The decision, and what was refused. The court that proves it, by name. The field, and where it leads. The limit, in three stage words. The first, built, means the code exists, a guard exists, and a block ran; it is the site's own built. The second, designed, covers what the site calls in construction, specification and ratified proposal. The third, absent, covers what the site calls named, a name with nothing behind it yet, and what nobody has named. Five words of the site, three of the book. Then six doors, one for each kind of reader, and one exercise.

And the book is judged the way the library is. Every block in it ran inside the library on the night the page was built, at the commit printed at the top of the page. A page whose promises are not kept does not build.

5. The court

The three blocks of the two acts stand on two guards. modality_narrated proves that a declared kind can be inspected, that a verdict names the constraint that failed, and that an unknown kind never silently allows. It also proves that an enforced constraint refuses a bad update before it lands, while a declared one stays passive. wisecoding_narrated proves the conversation. It proves gaps computed from the declared goal, a question that says why it is asked, answers admitted, and a law refusing through the conversation and reaching a person. And it proves that concluding with open gaps is refused. Its sister, wisecoding_rich_narrated, carries the richer cases of the same loop.

The rethink of emptiness stands on 612_dealing_in_emptiness_in_softanza.ring, a library test written as scenarios, each line stating the result it expects. The rethink of truth stands on its narration and on this book's run, and a guard for it is the next step. The library's file for it, 04_truth_in_softanza.ring, sets the list of false words by assignment and never calls the function, so it does not prove the block.

The court has been named; next, the field, and where it leads.

6. The field, and where it leads

The field leads in adoption. Decision records are a light standard that many teams use, with templates and tools around them. The decision element of this book exists in this book and in one study of the record, and not yet as data in the library. Examples in documentation can be run by the standard tool of Python, and Rust runs them by default. The promises of Softanza are judged by the house's own runners, which no outside tool reads yet. And the field compares by grid, as the record's own pages also do; a grid alone is a start, which is why section 4 asks for the loss beside the win.

Where I think Softanza stands apart is in one place only: the rethink is carried all the way down. I hold this as a view, not a result. The decision is written, the redesign runs, the promise is judged at build, and the stage word says how far each piece has gone. A decision record does not run. An example does not say what was refused. Here they are one object.

7. The limit

• builtthe court behind every block of this chapter but the truth one, and the stage words the site prints on every product
• designedthe register of rethought concepts as data, with a guard that fails when a concept has no proof
• absenta page that shows each rethought concept with a run proof; a test file for the paradigm engine of section merging

What is built: the court behind every block of this chapter but the truth one, and the five stage words the site prints on each product.

What is designed: the register of rethought concepts as data, one row per concept with its article, its code, its guard and its stage. Beside it, a guard that fails when a new concept arrives without a row. Both are a specification today.

What is absent: a page that shows each concept with a run proof; the site's register page, read on 9 October 2026, lists each with its evidence. A test file for the engine module of one paradigm engine, section merging: it has none of its own, though its merge methods run in base/test/string/289_content.ring and max/test/stzListOfPairsTest.ring. And a few rethinks where the article goes a step beyond the code of today. The article on quantifiers asks whether all your marks AreGreaterThan the average, and that method is spelled differently in the library today. Its friendlier quantifiers, some, most and few, draw at random, so they carry no promise today. The register is a reading, and a reading can miss a concept that lives in only one article.

That is where this chapter stops; six doors follow, one for each kind of reader.

8. Six doors

9. Exercise

Choose one default of your own language that you never questioned: what the empty string counts to, what counts as true, what "most" means. Before you run anything, write in one sentence the rule you think is right. Then write two promises in the form you have met: the line your language prints today, and the line your rule must print.

? YourDefault(the_input)
#--> what your language prints today
? YourRule(the_input)
#--> what your declared rule must print

Run both. I will not tell you which rule is right. If your rule and your language disagree, you have found a decision that someone took for you, and you can now take it yourself.

I left this one in your hands, on purpose. Take the block of section 3 that governs a string, change one word, EnforceConstraint for AddConstraint, and run it as it stands below. I print no output for it.

oName = new stzString("hello")
oName.AddConstraint("keep-lowercase", :Lowercase)
bRefused = FALSE
try
	oName.UpdateWith("HELLO")
catch
	bRefused = TRUE
done
? bRefused
? oName.Content()

Look at what it prints: whether the update was refused, and what the object holds. Then read section 3, just after the block, and section 5, on the guard that checks it: the page says why. When you have both lines, you will know why a declared constraint is not an enforced one.

Chapter 4 draws the platform in one picture, under one idea at every altitude: nothing is believed, everything is judged.

The platform in one picture

Run on 2026-10-15 12:58 UTC+01:00 inside the library at commit 93d7a39bd: 8 of 8 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I draw the whole platform in one picture, read from the bottom up: the engine, the layers, the areas, the worlds, the crafters, and beside every floor its court. I walk it floor by floor, with one block at each floor that you can run. Then I say what I refused along the way: computation in the faces, a flag to choose a layer, mini-applications. The picture is summed up in one idea at every altitude: nothing is believed, everything is judged.

1. The concept, as the field holds it

The field draws a platform as a stack of boxes. The kernel at the bottom, a runtime and its libraries in the middle, applications on top, and sometimes a column at the side for security or tools. Inside one codebase the same picture becomes a rule about dependencies: an inner layer knows nothing of the outer ones, and the arrows only point inward. Rust's three standard crates, one for bare metal, one for memory, one for a full operating system, are the cleanest version I know. Three depths of the same language, chosen by what the target offers.

For applications, the field's picture is a host. A large application embeds a runtime and runs small applications inside it, which share its services and its store. In both pictures the judge is outside: a test suite beside the code, a review beside the store. In the pictures I know, neither draws the court as a column standing at every floor.

Softanza draws that column, and one idea holds the whole picture.

2. The first principle

The stack of the platform is summed up, in the vision I ratified, in one idea at every altitude: nothing is believed, everything is judged.

3. The Softanza form

Here is the whole platform in one picture, read from the bottom up. Each floor stands on the one beneath it, and each floor is judged by a court beside it. The numbers in it are not typed by me. The build reads them, when this page is made, from the library and from the site's map of its areas.

Let me walk it, floor by floor, with one block at each floor that you can run.

The engine. At the bottom is an engine written in Zig: a set of libraries behind a C interface, one per domain, grouped by the layer that loads them. By the engine's design rule, the engine does the computation; the library above it gives it a vocabulary. A small example makes the division visible. Ask the language beneath Softanza for the length of the Arabic word for peace, then ask the engine. What does each one count? Run it:

? len("سلام")
#--> 8
? Q("سلام").NumberOfChars()
#--> 4
? Q("مرحبا بالعالم").Script()
#--> arabic

The language counts bytes and answers 8. The engine counts letters and answers 4, and it knows the script: arabic. Four letters, not eight!

The engine also has its own door, beneath every class. Numbers too large for the machine's arithmetic are added exactly, by the engine itself:

a = StzEngineBigIntFromString("99999999999999999999999999999999")
? StzEngineBigIntToString( StzEngineBigIntAdd(a, StzEngineBigIntFromString("1")) )
#--> 100000000000000000000000000000000

The engine answers 100000000000000000000000000000000, the exact sum.

The layers. Above the engine, the library is cut in three layers, by depth of capability. Core, with the prefix stk, is lean and talks to the engine directly, for small devices and small binaries. Base, stz, is the rich layer, where the vocabulary and its forms live, enough for most solutions. Max, stx, is meant for the strongest innovations. A layer is chosen by the file a program loads. Does the same verb mean the same act at core and base? Run it:

o1 = new stkList([ "one", "and", "one", "makes", "two", "ones" ])
? o1.FindFirst("one")
#--> 1
o2 = new stzList([ "one", "and", "one", "makes", "two", "ones" ])
? o2.FindFirst("one")
#--> 1

Both answer 1: the same verb, the same act, at two depths.

The areas. Across the layers, the library is mapped by the site's Atlas into areas grouped in bands, and each area into lanes. Each lane is rated from emerging to strong, most of them with the line that proves it. The Atlas says what exists, and how well. Another principle of the engine's design is that a verb means the same act on every structure that admits it. Does it hold for one pair, a string and a list? Run it:

? @@( Q("tea rice tea").FindAll("tea") )
#--> [ 1, 10 ]
? @@( Q([ "tea", "rice", "tea" ]).FindAll("tea") )
#--> [ 1, 3 ]

On the string, FindAll answers character positions: [ 1, 10 ]. On the list, it answers item positions: [ 1, 3 ]. The same act, on two structures.

The worlds. Above the library, the unit is not a module but a world: an application is a living world of meaning, with its things, its relations and its rules. A world is declared. What does it say of itself when you ask it to explain? Run it:

oApp = new stzApp("FieldVisits")
oApp {
    AddThingQ(:Account) { Has([ :number, :chapter, :balance ])  IsTrue(:balance, "@ >= 0") }
    AddThingQ(:Client)  { Has([ :code, :name, :city ])  Owns(:Account) }
    AddRelation(:Account, :belongsTo, :Client)
}
oApp.Explain()
#--> WORLD FieldVisits   lives in: memory (not persisted)
#      BEING
#        account (number, chapter, balance)
#            true when balance @ >= 0
#        client (code, name, city)
#      RELATIONS
#        client owns account
#        account belongsto client
oApp.Live()
#--> [FieldVisits] is live -- 2 thing(s), 0 flow(s), 0 reaction(s), 0 goal(s); 0 proposal(s)

It answers WORLD FieldVisits lives in: memory (not persisted), then lists its being and its relations. Live() answers [FieldVisits] is live -- 2 thing(s), 0 flow(s), 0 reaction(s), 0 goal(s); 0 proposal(s). Two things, and no flow, no reaction, no goal. The world says what was declared, and no more.

Worlds compose into a constellation. Here a restaurant and its produce supplier are two worlds, and a bond between them declares the one crossing that is allowed. The three Gov lines declare the crossing's risk, grant it to the restaurant and set the restaurant's authority; the guard behind this block shows that without them even the declared crossing is refused. What becomes of a crossing that no bond declares? Run it:

oResto = StzAppQ("resto")
oResto.AddThingQ(:dish) { Has([ :name, :price ]) }
oSupplier = StzAppQ("supplier")
oSupplier.AddThingQ(:crate) { Has([ :produce, :qty ]) }
oCon = new stzSuperApp("acme-group")
oCon {
	AddWorld("resto", oResto)
	AddWorld("supplier", oSupplier)
	Bond("resto", "supplier", "order-produce")
	GovDeclareRisk("order-produce", 2)
	GovGrant("resto", "order-produce")
	GovSetAuthority("resto", :Delegated)
	? CallAcross("resto", "supplier", "order-produce")
	#--> 1
	? CallAcross("resto", "supplier", "raid-kitchen")
	#--> 0
	? Why()
	#--> no bond declares 'raid-kitchen' from 'resto' to 'supplier'.
}

The declared crossing answers 1. The other answers 0, refused! The constellation gives its reason in one line: no bond declares 'raid-kitchen' from 'resto' to 'supplier'. Every other crossing is refused with its reason.

The commons is the shared ground of a constellation, what every world of it stands on. It holds an identity, a session and a store. It is a world like the others, world zero, and not a node of a special kind. Chapter 23 shows it and says how far the code has come in that direction.

And a platform, stzPlatform in the figure, is the envelope around a solution: its parts, the systems they run on, and the order in which it is built, rehearsed and deployed. You declare the solution it carries as a stzPlatformProfile, and you will see it refuse to deploy before it is built in chapter 33. Here is what its delivery planner, stzDelivery, does with the layers, for the web: a part of a solution ships only the engine groups it needs, and only those that are Softanza's own. The phone below asks for four capabilities. How many engine groups does it ship? Run it:

oDelivery = new stzDelivery("my-shop")
oDelivery {
	AddSuperApp(:phone, :Android)
	AddBackend(:api, :LinuxServer)
	NeedsIn(:phone, [ :Unicode, :PivotTable, :ConstraintSolver, :Regex ])
	oPlan = Plan()
}
? @@( oPlan.EngineCapsFor(:phone) )
#--> [ "pivottable", "constraintsolver" ]
? @@( StzWasmGroupsFor( oPlan.EngineCapsFor(:phone) ) )
#--> [ "aggregation", "solver" ]

Two, not four: aggregation and solver! The phone's own system handles one of the other two, Unicode, and Softanza ships the other, Regex, as a construct in the target's own language.

The crafters. At the top are the six doors of chapter 2: the programmer, the analyst, the designer, the decision-maker, the educator and the agent. And one person works across every floor, from the engine to the organisation: the platform architect. The record names that role in three of its documents, and no other role crosses every band of the Atlas.

The court. Beside every floor stands its judge. The engine has its tests and the contracts between the floors. The layers have the narrated guards. Most lanes in the areas carry a proof line. The worlds have their bonds and norms, the order of build and deploy, and the refusal of a fake in production. The crafters' interfaces have a constitution of verbs and rules that every element must trace to. And above all of it, the platform's threat model lists its guarantees, each tied to the guard that proves it. Its own guard fails when a row names a guard that no longer exists.

Parts II to IV of this book are rethinks, and each of them is a box of this picture. Part V assembles the picture in use.

5. The court

00_stzapp_narrated proves a world declared and made visible. 06_stzsuperapp_narrated proves the constellation: worlds joining, the commons as world zero, crossings gated by norms with the bond named as the reason, a retired world breaking its bonds. full_scope_model_narrated, the architect's common ground, proves the solution modelled first, the scopes that refuse what a target forbids, and the order of build and deploy. 01_platform_narrated proves the platform's duties. threat_model_narrated reads the platform's threat model and fails when a guarantee names a guard that no longer exists.

6. The field, and where it leads

Rust's three depths are enforced by its compiler and used every day on bare metal. Softanza's rule is held at the engine and at the entry files, and not yet carried to where base should build on core, as section 7 shows.

The field's text libraries lead on locale: Softanza's own map names the international components' locale layer as the clear gap of its strings, and names the bet behind it: its locale area leaves those components out on purpose, with no collation, no plural rules and no time zones.

At the scale of real users, the field's super-app hosts lead today. The record names them as the model it refused and measures nothing against them, so I will not either.

And the Atlas itself prints what is still to come for Softanza. The binary area is a plan for now, and its shipped code is the next step; the plugin, foreign-function and embed plane of extensibility is mostly planned; the system area has few lanes rated strong so far. I hold this as a view, not a result. A map that prints its stages is the only kind worth reading.

7. The limit

• builtthe engine and its libraries; the base layer; worlds, constellations and platforms with their guards; the engine subset a part ships, for the web
• designedthe max layer loaded by its entry file; the base layer building on the core one; a loader for one domain of base alone; a court that checks the layers against their contract
• absenta whole program and its engine packed into one file; a customer platform on the engine

Now I put the three stage words on the picture, built, designed and absent.

What is built: the engine and its libraries, the base layer, worlds, constellations and platforms with their guards, and, for the web, the engine subset a part ships.

What is designed, or built and not reachable. The max layer's own classes are written and loaded by no entry file. What does the runtime answer when you ask for one? Run it:

try
	o3 = new stxString("one and one")
catch
	? cCatchError
done
#--> Error (R11) : Error in class name, class not found: stxstring

The runtime answers: Error in class name, class not found: stxstring. The class is written, and no entry file loads it!

The layer contract says the base layer builds on core, by inheritance or delegation. It does neither for the common domains: the two share the engine and implement those domains twice. The core layer itself is in development against the engine today. Its string and character classes call engine names that no engine file registers, as my study of the record reports. The block in section 3 shows lists only. A loader that brings one domain of base without the others is not built. A court that reads the layer contract against the tree and fails on drift is a specification, proposed in that study. What is built is two implementations sharing one engine; the contract's line that base builds on core is designed.

What is absent: a whole program and its engine packed into one file with no dependency, and a customer platform running on the engine.

8. Six doors

Each of the six doors reads this picture from where it stands.

9. Exercise

Draw your own solution the way this chapter draws Softanza: floors, and a court beside each. For each box, write the file that declares it and the guard that judges it, and put a stage word on it: built, designed or absent.

Then declare two parts of it with stzPlatformProfile, give the profile to a stzPlatform, and before you run anything, write the line you expect when you ask it to deploy before you build it. Run it. A box with no court beside it is your first finding.

I left this one in your hands. Section 7 says the core layer's string classes are still in development against the engine, and the block of section 3 shows you lists only. Take the block of section 7 and change one word: stxString becomes stkString.

try
	o3 = new stkString("one and one")
catch
	? cCatchError
done

Run it, and read what the runtime answers. Then go back to section 7 and find which name is called, and who should have registered it. When you have solved it, you will know why the layer contract's line that base builds on core is called designed, and not built.

The next chapter leaves the picture for the code written inside it, and states the first law: the code adheres to the way a person thinks, and the court judges it whoever wrote it. Its principle is one sentence: what you think is what you write.

Law: the code adheres to the way a person thinks, and the court judges it whoever wrote it

Run on 2026-10-15 12:58 UTC+01:00 inside the library at commit 93d7a39bd: 9 of 9 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I take the two things the field calls coding style and ask the question it does not ask: whether a line follows the order in which its writer reasoned. I run the founding example in the nearest form that still runs, then the mental model on a list, the verb's forms, the named parameter, the scene and the history of a chain. A promise stands under every question. I say what I let go, the library's own implementation, and what I refused to let go, the style of the code written with it. I show the court that exists today, over the library's own classes, and the one that is only designed. The motto has not changed since 2020: what you think is what you write.

What the AI age changes here

For years, most of the code written with Softanza was written by one hand, and the hand was mine. The style of the library was the way I wrote. Then the machines arrived, and today most code here is written by AI models, as the design of the intelligence plane says it is everywhere, in one sentence: most programming today is done by agents and language models, not humans.

That changes what a style is. A style that lives in one person's habits dies when that person stops writing every line. It has to become something a machine can be held to, and something a machine can check, or it thins away. In this house it did thin, and I will show you where. So this movement of the book, Programming rethought, opens on a law that has two halves. The second half exists because of the age: the code adheres to the way a person thinks, and the court judges it whoever wrote it. By the court I mean the machine that judges code against the house's rules; today it judges only the library's own classes, and section 5 says how.

There is a dependency to say aloud. This book follows the order of its cover, from the familiar to the new: programming, then languages, then intelligence. The record's own logic runs the other way. The first act is to declare a language; programming happens inside a declared language; intelligence is governed by both. The vocabulary's forms are already declared in a spike of Haro, as its charter's entry of 3 October 2026 records. The usage that this chapter describes, the scene, the chain, the named parameter, the promise under each line, is meant to be declared too. So read this law knowing that Part III holds it up.

1. The concept, as the field holds it

In our industry, "coding style" means two things, and neither is about how a person thinks. The first is layout and naming, enforced by machines: Python's style guide since 2001, Go's formatter since 2009, and the formatters that every modern project runs before a commit. They settle arguments about spaces and capital letters, and they are good at it. The second is the fluent interface: methods chained so that a line reads almost like a sentence.

The age of generated code added a third practice: check after. A model writes, the tests and the linters read what it wrote, and the model tries again if they complain. The line itself is judged for its shape and its result. Whether it follows the order in which the writer reasoned is a question I know no tool to ask.

2. The first principle

My motto for this has not changed since 2020: what you think is what you write.

Section 3 shows the motto at work.

3. The Softanza form

The founding slide put the whole idea on one page. On the left, a person's four steps of thought: I take the word "softanza"; I turn it to uppercase; I get its characters; I join them with a space. On the right, the same four steps as one line of code, as if the text on the left had been pasted and run.

That exact line no longer runs. Its third link, a method that turned the characters into a list of strings in one step, is not in the library today. It survives only in archived files and in one scratch sample, as CharsQRT. I tell you this first because a law chapter that hides its own founding example would not deserve your trust. What is the nearest form that runs, with the four steps still visible, and what does the library offer as one dedicated verb? Run both:

? StzListOfStringsQ( StzStringQ("softanza").UppercaseQ().Chars() ).ConcatenatedUsing(" ")
#--> S O F T A N Z A
? StzStringQ("softanza").UppercaseQ().Spacified()
#--> S O F T A N Z A

Both forms print S O F T A N Z A. The idea is intact; the fluent link was lost. A request goes to the library to restore it.

The mental model is the same idea at the level of a problem. You say the problem in plain words. You select the object that holds the data. Then you ask, in order: does it contain what I care about, how many, where? Then you act on those positions, or you call the verb that does it for you. Take a list with empty strings in it. Does it contain them, how many, and where? Run it:

o1 = new stzList([ "A", "", "B", "", "", "C" ])
? o1.ContainsEmptyStrings()
#--> TRUE
? o1.CountEmptyStrings()
#--> 3
? @@( o1.FindEmptyStrings() )
#--> [ 2, 4, 5 ]
o1.ReplaceEmptyStrings(:With = "~")
? @@( o1.Content() )
#--> [ "A", "~", "B", "~", "~", "C" ]

The list answers TRUE, then 3, then [ 2, 4, 5 ], and after the act it reads [ "A", "~", "B", "~", "~", "C" ]. Contain, count, find, act. Each line is one step of thought, and the names are the words you would use to say it.

The verb's form says what happens to the object. What does each form do to it? Run them on one string:

o1 = new stzString("HAxxRxO")
? o1.Removed("x")
#--> HARO
? o1.Content()
#--> HAxxRxO
o1.Remove("x")
? o1.Content()
#--> HARO
? Q("haxxrxo").RemoveQ("x").UppercaseQ().Spacified()
#--> H A R O

Removed printed HARO, and the object still read HAxxRxO! Remove then acted on it, and Content() read HARO. The chain with Q ended on H A R O. By the library's convention, the past participle gives you a changed copy and leaves the object alone. The plain verb acts on the object. The verb with Q acts and hands the object back, so the next step can follow.

Do you need to remember which argument comes second? A parameter can be named, and the name reads as English:

? Q("I love Haro").Replaced("love", :With = "♥")
#--> I ♥ Haro
o2 = new stzList([ "tea", "rice", "fish" ])
o2.SwapItems(:AtPositions = 1, :And = 3)
? @@( o2.Content() )
#--> [ "fish", "rice", "tea" ]

The text prints I ♥ Haro and the list [ "fish", "rice", "tea" ]. The names :With, :AtPositions and :And say which argument is which.

How do several questions about one thing read as a list? They are asked inside its scene, a block of braces around the object. The object is named once:

Q("haro php HARO ruby Haro") {
	? NumberOfOccurrence(:Of = "haro")
	#--> 1
	? NumberOfOccurrenceCS(:Of = "haro", :CS = FALSE)
	#--> 3
	? @@( FindAllCS("haro", FALSE) )
	#--> [ 1, 10, 20 ]
}

The scene answers 1, then 3, then [ 1, 10, 20 ]. The same word counted 1, then 3 once :CS = FALSE was said! The object was named once, and the three questions read as a list.

Can the steps of thought be read back? An object lifted with history keeps the result of each step of its chain:

? @@( Qh(12500).AddQ(500).RetrieveQ(1500).DivideByQ(500).MultiplyByQ(2).History() )
#--> [ 12500, 13000, 11500, 23, 46 ]

The run printed [ 12500, 13000, 11500, 23, 46 ]. Five values, the starting one included, and the chain ends at 46! The article that first told this promised four values, without the first, and a final value one unit short, 45. The guard behind the block states today's rule, on a string chain: the initial value, then each step's result. The book takes the run's answer, not the article's.

The same steps can be written as a scene, the form I hold as the basis of the style: the object is named once, and each line inside the braces speaks to it.

# A number object that keeps its history
QH(12500) {
	# Inside the braces, each line speaks to the object
	Add(500)
	Retrieve(1500)
	DivideBy(500)
	MultiplyBy(2)

	# Its history, as one expressive value
	? @@( History() )
	#--> [ 12500, 13000, 11500, 23, 46 ]
}

The chain says it in one sentence, and the scene says it as steps. The book uses both: the sentence where the thought is one, the scene where it is a procedure. The classic form names the object on every line, and many readers think in it:

o1 = new stzNumber(12500)
KeepHistory()

o1.Add(500)
o1.Retrieve(1500)
o1.DivideBy(500)
o1.MultiplyBy(2)

? @@( o1.History() )
#--> [ 12500, 13000, 11500, 23, 46 ]
KeepHistoryOFF()

Three forms, one answer. A fourth is the near-natural sentence, Naturally("..."), which chapter 13 runs on text; on a number it answers Unsupported object type at this commit, and that is its next step.

One word on @@(). On the former host language, ? prints a list one item per line; @@() asks for the list's expressive form, [ 12500, 13000, 11500, 23, 46 ], the one a person writes. I have asked that Haro print that form by default; then @@() leaves the examples.

Notice the line under every question. It is not a comment. It is a promise, what the line must print. In this house it has been the form of an example from the first day: a short story, a few questions, and the answers written under them. That is the first half of the law, made visible: the code follows the order of thought, and each step says what it expects.

Now the second half. A rule a person must remember is folklore. The library turns its house rules into validators, so that a person or an AI agent can check a class before it lands. The rules are fourteen, and section 5 counts them; five of them read the graph of the code, the structure the library builds from a class's text. Here a class breaks the house's convention that a verb ending in Q returns the object. This rule needs the return statements, which the graph does not model, so it runs as a text pass. What does the court say of the class? Run it:

cCode = "class Basket" + nl + "def Add(x)" + nl + "	return x" + nl + "def AddQ(x)" + nl + "	return 42" + nl
? StzCodeIsClean(cCode)
#--> FALSE
? StzCheckCode(cCode)[1][:rule]
#--> q-returns-object

The court answers FALSE, and names the rule: q-returns-object. It did not ask who wrote the class! That is the whole of the second half. And the promise under each question is read by a machine too: the library's runner judges a promise as a claim about what the line printed. The house's oldest form of example is also its newest form of test.

The chapters of this part prove the law, each from one side. Chapter 6 tells the mental model and the four metaphors that replace loops: walk, check, yield, perform. Chapter 7 tells the writing style as fourteen rules of its own, not the fourteen house rules of the court you have just seen, and the seven design goals as its architectural half. Chapter 8 tells the forms a function's name can take, the deep form among them, and scope named in the verb. Chapter 9 tells patterns of thought: the machine that reacts to what it recognises, reactive programming in plain words, and the timeline and the grid. Chapter 10 tells how programming becomes refinement.

5. The court

coderule_narrated proves that a house rule is a rule over the code graph and that the findings come out on planted code. It proves that clean code passes, and that the library's house rules are fourteen. testoor_promises_narrated proves that the promise is judged by a machine in the house's own form. Each rule is planted both ways: the lie it must catch, and the truth it must not accuse. 05_containsemptystrings is the mental model's steps on the same list, a classic block kept as a guard. 466_keeping_the_history_of_updates_of_a_softanza_objec proves the history of a chain.

Section 6 sets the court beside the field.

6. The field, and where it leads

The field leads in enforcement. Most mainstream languages have a formatter and a linter, and most projects run them before a commit or in continuous integration; that is general knowledge, not a study of the record. The court that would judge the style of a program written with Softanza is a specification; the one that exists judges the library's own classes.

The field leads in reach and in people. There is a labour market for its tools and none yet for this one, and the field's generators are the largest that exist.

The field also leads, today, over Softanza's own pages. The study that measured the record found that the site's code blocks carry no named parameter and no scene: a reduced dialect of the library, shown to every visitor. An AI agent that learned from the site would learn that dialect. I did not measure the site's blocks again. A style that is not shown is not learned.

Where I think Softanza stands apart is in what the style is tied to. A formatter judges the shape of a line; a fluent interface makes a line pleasant. Here the line is tied to a step of thought, and the verb's form is a contract about the object. The promise under the line is the example, the test and the documentation at once.

7. The limit

• builtthe forms of the vocabulary in thousands of method names; the house rules as a court over the library's own code; the promise read by a machine in the house's own form
• designeda court of style for the code a programmer or an AI agent writes; the writing grammar declared in Haro, so an AI model can only write in it
• absentany machine that judges today the style of a program written with the library

What is built: the forms of the vocabulary, in thousands of method names; the house rules as a court over the library's own code; the promise judged by a machine.

What is designed: a court of style for the code a programmer or an AI agent writes with the library. It would read a positional argument where a named one exists, a question with no promise, a chain on one line past two steps. And the writing grammar declared in Haro, so that an AI model's output is held to it before it is written.

What is absent: any machine that judges, today, the style of a program written with the library. The founding slide's chain does not run as written. In this book the discipline carries the name of its motto: what you think is what you write.

8. Six doors

9. Exercise

Take the list [ "tea", "", "rice", "", "fish", "" ]. Write the questions of the mental model in order, one line each: does it contain empty strings, how many, where. Then one act, with a named parameter. Under every question, write the line it must print, before you run anything.

Run it. Then ask an AI agent to solve the same problem, and judge its answer with two questions only: does each line follow a step of thought, and does each question carry its promise.

I left this one in your hands, on purpose. The Basket class of section 3 fails the court because AddQ returns 42. Change that one value to This and run the question again:

cCode = "class Basket" + nl + "def Add(x)" + nl + "	return x" + nl + "def AddQ(x)" + nl + "	return This" + nl
? StzCodeIsClean(cCode)

Do not stop at the court's answer. Ask whether the class, as it stands, follows the way a person thinks, and what the court read to answer you. I do not give you the verdict: section 6 says which court exists, and section 7 says what it does not read. When you have settled it, you will know why a court that passes a class has not yet judged the style of a program written with the library.

The next chapter is the mental model, and the metaphors. Where you would write a loop, it asks you to name the move you are making instead: walk, check, yield or perform.

The mental model, and the metaphors

Run on 2026-10-15 12:58 UTC+01:00 inside the library at commit 93d7a39bd: 7 of 7 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I take the seven steps of the mental model, of which chapter 5 ran the middle four on a list, and run them on a string, in the same order. Then I come to the loop, the place where the steps repeat, and to the four metaphors the library gives you instead: the walker, the checker, the yielder and the performer. I show the condition that all four carry inside an argument, the W condition the engine reads as data, and its WF twin, which runs host code. I say why I made the metaphors a design goal, why I replaced eval with a language the engine owns, and where the code of the articles this chapter rests on is not yet runnable at this commit. The principle under all of it is the chapter's own: when you would write a loop, name the move you are making, walk, check, yield or perform.

1. The concept, as the field holds it

The field has one tool for repeating a thing, the loop, and a family of cousins that hide it: the iterator, the comprehension, the stream with its map, filter and reduce, the lambda that carries a condition. They are good tools, and they all share one habit. They are written in the language of the machine's motion: an index that starts at zero, a counter that is incremented, a variable that accumulates. A person who reads the loop has to recover the question it asks.

The field also has a vocabulary of metaphors for programming, but it keeps them in the documentation. The code stays a loop.

2. The first principle

Say the problem in plain words, ask the same questions in the same order of any object, and when you would write a loop, name the move you are making: walk, check, yield or perform. The site's Craft page says it, as I read it on 9 October 2026: "A loop hides which move it is making. Softanza names the four moves, and a task is decomposed into them instead." That sentence is the site's, not mine; the sentence above is this chapter's principle.

3. The Softanza form

The mental model is seven steps, and they are the order in which a person asks. Define the problem in natural terms and take its keywords. Select the object that holds the data. Ask whether it contains what you care about. Ask how many. Ask where. Act on those positions, or call the verb that does it. And the seventh: celebrate, and repeat. In chapter 5 you ran those steps on a list with empty strings. They do not belong to the list. Do they hold on a string? Here they are, in the same order:

Q("You and you") {
	? ContainsCS("YOU", FALSE)
	#--> TRUE
	? NumberOfOccurrenceCS("YOU", FALSE)
	#--> 2
	? FindNthCS(2, "YOU", FALSE)
	#--> 9
	ReplaceSection(9, 11, :With = "Me")
	? Content()
	#--> You and Me
}

Contain prints TRUE, count prints 2, find prints 9, and act leaves You and Me, with the same suffix that says whether case matters. The three questions you ask of a string are the three you asked of a list.

When the steps repeat, the loop appears, and this is where the library gives you four metaphors instead. Each one names a move.

The Walker moves along a route. A walker is a map of its whole journey, built when it is created. It holds the positions it will visit, the positions it will skip, where it stands and what remains. What does it know before it takes a step? Ask it:

Wk(1, 10, 2) {
	? @@( Walkables() )
	#--> [ 1, 3, 5, 7, 9 ]
	? @@( Unwalkables() )
	#--> [ 2, 4, 6, 8, 10 ]
	? @@( Walk() )
	#--> [ 1, 3 ]
	? CurrentPosition()
	#--> 3
	? @@( RemainingWalkables() )
	#--> [ 5, 7, 9 ]
}

Walk() is one step, and it prints the path of the move, from where it stood to where it landed: [ 1, 3 ]. A loop does not hold its route as a value you can ask. A walker does, before it moves. What does it do at the edge of the road? Beyond the end, when the walk is underway, it stops in silence. Before the start, it refuses:

oWalker = Wk(1, 10, 3)
? @@( oWalker.WalkNSteps(10) )
#--> [ 1, 4, 7, 10 ]
? @@( oWalker.Walk() )
#--> [ 10 ]
oWalker = Wk(1, 10, 3)
try
	oWalker.WalkBackward()
catch
	? cCatchError
done
#--> Can't walk backward! Already at the beginning of walkable positions.

Ask for ten steps from a walk that has four and you get the four: [ 1, 4, 7, 10 ]. Walk again and it prints [ 10 ], the position it stands on, with no error. Ask it to walk backward from the start and it refuses! Its own words: Can't walk backward! Already at the beginning of walkable positions. The article argues that this mirrors how we walk in the physical world. You stop when you hit a wall behind you, and that is an error. When the road ahead ends, you stop in silence.

The Checker asks yes or no. All of them, any of them, or where, with the condition written as a string, the W condition, W for where:

Q([ "A", 5, "B", "C" ]) {
	? CheckW('{ isString(@item) and IsUppercase(@item) }')
	#--> FALSE
	? ContainsW('{ isNumber(@item) }')
	#--> TRUE
	? @@( FindW('{ isNumber(@item) }') )
	#--> [ 2 ]
}

One item fails the test, so CheckW prints FALSE; a number is in the list, so ContainsW prints TRUE; and FindW says where, [ 2 ].

The Yielder produces new data from old, and leaves the old alone. The Performer is its opposite number: it changes the items where the condition holds. Which of the two touches the list? Put them side by side on the same list and look:

o1 = new stzYielder([ 1, -2, 3, -4, 5 ])
o1 {
	? @@( Filter(:IsPositive) )
	#--> [ 1, 3, 5 ]
	? @@( Map(:Abs) )
	#--> [ 1, 2, 3, 4, 5 ]
	? Reduce(:Sum)
	#--> 3
}
Q([ 1, "haro", 3, "python", 5, "ruby" ]) {
	? @@( YieldW('isString(@item)', 'upper(@item)') )
	#--> [ "HARO", "PYTHON", "RUBY" ]
	? @@( Content() )
	#--> [ 1, "haro", 3, "python", 5, "ruby" ]
	PerformW('isString(@item)', 'upper(@item)')
	? @@( Content() )
	#--> [ 1, "HARO", 3, "PYTHON", 5, "RUBY" ]
}

Look at the two Content() outputs, before and after the PerformW call. The yield returned [ "HARO", "PYTHON", "RUBY" ]. The list was untouched! The perform changed the list: [ 1, "HARO", 3, "PYTHON", 5, "RUBY" ]. The verb tells you which, so a design can say "this step only reads" and mean it.

Now the thing that all four share: a condition travels inside an argument. It is a small string, kept in a variable if you want. It goes in the same place for find, for items and for contains. And it has a twin that takes a real function:

cCond = '{ @item > 5 }'
Q([ 3, 8, 5, 12, 1, 9 ]) {
	? @@( FindW(cCond) )
	#--> [ 2, 4, 6 ]
	? @@( ItemsW(cCond) )
	#--> [ 8, 12, 9 ]
	? ContainsW(cCond)
	#--> TRUE
	? @@( FindWF( func x { return x > 5 } ) )
	#--> [ 2, 4, 6 ]
}

The two agree: FindW with the string and FindWF with the function both print [ 2, 4, 6 ]. ItemsW gives the items themselves, [ 8, 12, 9 ].

The string form is the W condition; the function form is WF. They look alike, and the difference matters. The engine reads a W condition as data, in a small language of its own: literals, @item, arithmetic, comparisons, and a short list of functions. It cannot call your code. So what happens to a condition that tries to? It is not run:

o1 = new stzList([ 3, 8, 5, 12, 1, 9 ])
? @@( o1.FindW('{ @item > 5 and print("hacked") }') )
#--> [ ]
? @@( W('{ @item > 5 }') )
#--> [ "where", "{ @item > 5 }" ]

Nothing was printed! The positions came back empty, [ ], and W() shows the condition for what it is, data: [ "where", "{ @item > 5 }" ]. A W condition can be stored, shown to a person, and approved before it runs, because it cannot escape. The WF twin runs host code, and the library's own table says it is not safe with input you do not trust.

The code of the article "Bridging Minds and Code" does not run at this commit, as section 7 says.

The three models of that article, the semantic, the mental and the expression, are one idea in three places. The semantic model is the world of the program as knowledge: an apple is a fruit. The mental model is what you just did: create an object, store data in it, find things inside it, act on the positions. The expression model is the code that says it: select the object, type the name of the action, continue the flow of actions, convert the result into another object. Keep doing so until you have the final answer. So I tell them in words.

The next section gives the decision, and what I refused.

5. The court

The four metaphors have no single guard. The yielder has a narrated one, 00_yielder_narrated: four map operations, three filter operations and a sum. The walker has 597_walker_basics, named walkers and what they walked, and 495_walking_until_and_until_before, a walk that stops on a condition, including the item that stops it, or not; both test the list's named walkers and walks, through StzListQ, not the Wk walker of the blocks above. The checker has 611_checkw, which says a check is false when one item fails. The performer has 621_perform, which says it changes the list in place. 483_w_and_wf_forms_in_conditional_code proves that a W condition written with cursor words such as @NextNumber and the same one written with raw index arithmetic such as This[@i+1] give the same positions.

None of the guards named here covers Walkables, WalkNSteps or WalkBackward; those lines rest on the runs kept for this chapter.

Next, what the field does better than the walker.

6. The field, and where it leads

The field leads in laziness. A generator produces the next item on demand and can be endless. The walker builds a map of its whole journey the moment it is made. That is a win for foresight: you can ask which positions it will skip before it moves. It is a loss for a large or endless traversal.

The field leads in openness. A lambda carries any logic. The W language is bounded on purpose, and the price of the bound is the second path, WF, which has full host power and is meant for input you trust. There is also a quieter cost I measured once, on one case: a condition that calls something the language does not know gives an empty list and no error.

The field leads in reach and in tooling. Iterators and comprehensions are in every mainstream language, with editor support, type checking and a literature. These four metaphors exist in one library.

And I will not print the library's own comparison of walkers with loops and iterators. Its table has thirteen rows, all of them in the walker's favour, none of them run. A table is worth printing when its rows have been run and a loss stands beside the wins; for this one, that is the next step.

Next, the limit, in the stage words built, designed and absent.

7. The limit

• builtthe one-dimensional walker, the checker, the yielder and the performer on lists; the condition language compiled by the engine, with its host-code twin
• designedthe four metaphors as native engine modules (only the yielder is one); a walker over any indexed structure
• absentrunnable code for the three models of the article 'Bridging Minds and Code'; the edge table of the walker narration as written

What is built: the one-dimensional walker, in the max layer, and the walks on lists; the checker as CheckW, ContainsW and FindW; the yielder as a class backed by the engine, and as YieldW; the performer as PerformW; and the W condition language compiled by the engine.

What is designed: the metaphors as native engine modules. The engine's design marks all four as planned; only the yielder has an engine file. And a walker that is not about lists at all but about any indexed structure.

Six things are absent, or still to be aligned with their articles, at this commit, from my runs.

• The walking-at-the-edge article's table and the library differ in two cases; aligning them is the next step. A single step larger than the range raises where the table promises silence, and a mixed-direction path raises where it promises acceptance. The two principles hold in the cases shown above. The book states the principle and prints only the cases that run; the table is not printed.
• The "Beyond Loops" article's code differs in places. The history of a walker is a list of walks; a backward walk takes no argument now; the direction prints as "backward" where the article says "reverse". The site's own run of the article kept ten of eighteen blocks.
• The three models of "Bridging Minds and Code": none of its code runs as written; in the site's run twelve blocks raised and one differed. So I told them in words.
• The mental-model article's getter EmptyStrings() is absent.
• On the dedicated checker class, ContainsW is in development: it raises today. The string walker's backward-with-condition walk is absent.
• And "no eval" is still on its way to everything. The near-natural resolver, the other direction of chapter 13, still evaluates host code. So do StringsW and ItemsWhere on the list, and ContainsW on the dedicated checker class: each still calls eval on a condition string. What I said above, that the engine reads a W condition and cannot run it as code, holds for the engine's path; for these three it is the next step.

Next come the six doors, from the programmer to the agent.

8. Six doors

9. Exercise

Take the list [ 4, 9, 12, 7, 20, 3 ]. Four sentences are given. One: are all of them above 2? Two: give me, as a new list, those above 8, doubled. Three: make the ones above 8 negative, in the list itself. Four: which positions are 2, 4 and 6?

For each, say first which move it is, walk, check, yield or perform, and write under the line you will write what you expect it to print. Then write the line, with the condition as a string wherever there is a condition, and run it. After the second and the third, print the list again. Say, before you look, in which of the two the list has changed.

I left this one in your hands, on purpose. Here is the block of section 3 with one change: the list is the exercise's list, and I print nothing under it.

o1 = new stzList([ 4, 9, 12, 7, 20, 3 ])
? @@( o1.FindW('{ @item > 5 and print("hacked") }') )

Run it. The condition begins by asking whether an item is above 5. Look at what comes back, and at what does not, and say why before you go back to the sections. Section 3 says what the engine does with a condition that calls code; section 6 says what that costs, and section 8 says what an AI agent should do about it. When you have solved it, you will know why an empty answer is not yet a proof that nothing matched.

The next chapter turns to the writing style, and to the seven goals. Its principle is one sentence: what you think is what you write.

The writing style, and the seven goals

Run on 2026-10-15 12:58 UTC+01:00 inside the library at commit 93d7a39bd: 9 of 9 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I take the rest of the writing style, as a grammar of fourteen rules. I print the state each rule is in at the commit this book runs, a block where it runs and a limit where it does not. Under the grammar I put the seven goals, and I show three of them in blocks and leave the four I have not run to the study. I print the house court, the fourteen rules the library holds over its own code. I say what it does not read: the code of a program written with the library. The principle is chapter 5's, and I do not argue it again: what you think is what you write.

1. The concept, as the field holds it

The word style means two things in the field, and I have to say which one I mean.

The first is style as layout, enforced by a tool. Python's style guide dates from 2001, Go's formatter from 2009, and every project runs a linter before a commit. They judge the shape of a line: spaces, capitals, length, unused names. They are good at it, and they run by default. They say nothing about whether a line follows the order in which its writer reasoned.

The second is the small language inside the language. Programmers already write small languages in strings, and nobody calls that a style: a regular expression, a SQL text, a format string such as "%5.2f". Each is a separate notation, with its own tool, learned apart.

For goals, the field says quality attributes. The ISO standard for software quality, of 2011, lists eight of them, and architecture methods rank them before a system is drawn; that is general knowledge, not a study of the record. The seven goals of this chapter are a different list, chosen for a different purpose. They do not say what a product promises its users. They say what a feature must serve to be admitted into one library.

2. The first principle

What you think is what you write. It is chapter 5's sentence, from the diagram of 2020, and I do not argue it again. Chapter 5 took five rules of the style. This chapter takes the rest, as a grammar, and then the goals under which the grammar was designed.

For the goals, the point is mine, and not a dated quotation. A software architecture that is goal-oriented is the only way one architect masters a project of this size. I hold this as a view, not a result. What stands behind it on this page is one case: the 2022 matrix served as a skeleton for one architect over about three hundred thousand hand-written lines (section 6).

3. The Softanza form

My study of the record wrote the style down as fourteen rules, from reading the code. They are readings of the code, stated as rules, and not a standard anyone signed. Here they are with the state each is in at the commit this book runs. I put the table first because it shows which rules carry a block and which carry a limit.

Rule 11 first, because it is the strangest. The host language counts in integers and cuts the decimals. What does a range written inside a string keep? The comments below speak before the code, in the teacher's voice, which is rule 14. Run it:

# The host's own range counts in integers: the decimals are cut. Softanza reads
# a small language inside a string, and keeps the decimals, the numbered words,
# and the letters of any script:
? @@( 1.02 : 3.08 )
#--> [ 1, 2, 3 ]
? @@( L("1.02:1.05") )
#--> [ 1.02, 1.03, 1.04, 1.05 ]
? @@( L('"♥1" : "♥3"') )
#--> [ "♥1", "♥2", "♥3" ]
? @@( L(' "ا" : "ج" ') )
#--> [ "ا", "ب", "ة", "ت", "ث", "ج" ]

The host answers [ 1, 2, 3 ] to 1.02 : 3.08 and cuts the decimals. The string answers [ 1.02, 1.03, 1.04, 1.05 ], and the two Arabic bounds give six letters! Softanza reads a small range language inside the string and keeps the decimals, the numbered words and the letters of any script. The range language is an argument like any other. Does it give the replacements for each occurrence, in order, and does the extended form wrap the palette when the occurrences outnumber it?

o1 = new stzString("haro php ruby haro python haro")
o1.ReplaceByMany("haro", L('"♥1" : "♥3"'))
? o1.Content()
#--> ♥1 php ruby ♥2 python ♥3
o2 = new stzString("haro php ruby haro python haro ruby haro")
o2.ReplaceByManyXT("haro", L('"♥1" : "♥3"'))
? o2.Content()
#--> ♥1 php ruby ♥2 python ♥3 ruby ♥1

The extended form wrapped the palette, and ♥1 came back at the end!

A list can also be carried as a string in its short form, recognised, converted between forms and evaluated back:

? StzStringQ('1:3').IsListInString()
#--> TRUE
? @@( StzStringQ('[1,2,3]').ToListInShortForm() )
#--> "1 : 3"
? @@( StzStringQ(' "A":"C" ').ToList() )
#--> [ "A", "B", "C" ]

Rule 10: code travels inside an argument as a small string with a placeholder, @char for the characters of a string and @item for the items of a list. Chapter 6 showed the seat on a list. Here it is on a string, where it finds and removes by a rule and not by a loop:

Q("SOooooFTAaaannnNZA") {
	? @@( FindW('{ Q(@char).IsUppercase() }') )
	#--> [ 1, 2, 7, 8, 9, 16, 17, 18 ]
	RemoveW('{ Q(@char).IsLowercase() }')
	? Content()
	#--> SOFTANZA
}

The deck of 2022 writes the same call with a named seat, :Where = '...', and that form raises on a string in this commit. I do not show it. The same deck puts an @ at the end of a parameter's name, :With@, to mark that its value is code to be evaluated. That form is retired. A guard's header says so: the eval-based forms are retired. The deck itself marks the form "TODO". Code now travels in the seat as a bounded string that the engine evaluates, or as a function.

Rule 8: the same act may be said in two orders of words, with the container's name, or with the side spelled four ways, left or start, right or end; two of the four run below. Each pair is one act, with two definitions. The library's own narration calls the first with two arguments and it raises less number of parameters; the guards pass the starting position, and so does the block:

o1 = new stzList([ 1, 2, "♥", 4, 5, "♥", "♥" ])
? o1.FindNthNext(2, "♥", :StartingAt = 1)
#--> 6
? o1.FindNextNth(2, "♥", :StartingAt = 1)
#--> 6
? Q("---haro").NumberOfOccurrenceOfCharLeftSide("-")
#--> 3
? Q("---haro").HowManyOccurrenceOfCharStartSide("-")
#--> 3
o2 = new stzList([ "C", "B", "A" ])
o2.SwapItems(:AtPositions = 1, :And = 3)
? @@( o2.Content() )
#--> [ "A", "B", "C" ]

The deck promised more. A family of five names ending in CharsRemoved, for removing characters at the ends, is named in the deck. Two are defined, LeadingCharsRemoved and TrailingCharsRemoved. Three are not: LeadingAndTrailingCharsRemoved, TrailingAndLeadingCharsRemoved and RepeatedCharsRemoved. RemoveLeadingAndTrailingChars is defined, and is not one of the five.

Rule 9: precision over generality. The precise name says what is counted. A string's characters are counted by NumberOfChars, and Size() is the host's byte length. The two list verbs in the same block show the rule on a list: the precise name, ContainsBoth or ContainsAll, says what is asked. Do the two answers differ on an Arabic word? Run it:

? Q("سلام").NumberOfChars()
#--> 4
? Q("سلام").NumberOfBytes()
#--> 8
? Q("سلام").Size()
#--> 8
o1 = new stzList([ "tea", "rice", "fish", "salt" ])
? o1.ContainsBoth("tea", "fish")
#--> TRUE
? o1.ContainsAll([ "tea", "oil" ])
#--> FALSE

The run answers 4 to the one and 8 to the other. The word has four letters! The library's own documentation line for NumberOfChars lists size among its alternative words. The run shows that Size() does not mean it. I list it among the requests.

Rule 7: a prefix viz shows the answer under the word, and the suffix XT adds the positions as numbers; chapter 8 runs the block, among the forms of a name.

The narration and the deck write vizFindAll on a string. It does not exist there at this commit: my run answered Calling Method without definition: vizfindall. vizFind does exist. A list has its own VizFindAll.

The goals

Under the grammar there are seven goals, written in the 2022 deck as a matrix of thirty-three features, which section 4 counts. My study reads them as the library's architectural skeleton: a feature that serves none is refused, and a goal with no feature is a gap. The study's summary is a session's reading and not a text of the library, and no document in the library states the rule in these words. The nearest is the engine's design document: the engine must enable all seven.

I will not list the seven as a table of slogans. Here is what runs of three of them.

Flexibility: the order of named parameters is free. Are two calls, with the parameters in two orders, the same call?

o1 = new stzString("----@@--@@-------@@----@@---")
o1.ReplaceNextNthOccurrence(2, :Of = "@@", :StartingAt = 12, :With = "##")
? o1.Content()
#--> ----@@--@@-------@@----##---
o2 = new stzString("----@@--@@-------@@----@@---")
o2.ReplaceNextNthOccurrence(2, :With = "##", :StartingAt = 12, :Of = "@@")
? o2.Content()
#--> ----@@--@@-------@@----##---

Both orders print ----@@--@@-------@@----##---! This is the free order of named parameters; the deck's other free order, a number and a string swapped in their positions, is chapter 8's, and it does not run. A tension must be told with it. The design of Haro refuses free-order parameters as grammar, and the library keeps them. Two facts are true today. The block above runs them, so they are in the library. The grammar a machine is held to leaves them out, by the Haro principle. Whether the library keeps them past that grammar or retires them is a decision the record does not hold. I do not make it here. They are kept, and they are not grammar.

Consistency: one vocabulary across a string and a list. Does the same verb answer on both?

? @@( StzStringQ("hello").FindAllCS("L", :CaseSensitive = 0) )
#--> [ 3, 4 ]
? @@( StzListOfStringsQ([ "h", "e", "l", "l", "o" ]).FindAllCS("L", :CaseSensitive = 0) )
#--> [ 3, 4 ]
? Q("").IsEmpty()
#--> TRUE
? Q([]).IsEmpty()
#--> TRUE

The loss beside it, from the same slide group: the deck's advice to use the keyword Item with any enumerable type does not hold. NumberOfItems() on a string raises in my run: Calling Method without definition: numberofitems. On a list it answers.

Manageability: a failure that says where, what, why, and what to do. The library raises an error in four fields. I do not print its message, because in my run its first line carried a line number of the library, and a line number is not a promise.

The other four goals (expressiveness, reliability, the human metaphors and the practical abstractions) I leave to the tables of the study. I have not run them for this chapter, and I will not describe from the deck what I have not run.

Next comes the decision, and what I refused.

5. The court

coderule_narrated proves that a house rule is a rule over the code graph; that planted code is found by name; that clean code passes; and that the library lists fourteen. testoor_promises_narrated proves that the promise #--> is judged as a claim of a stop: kept, diverged, unreached or unjudged. 602_l_function and 59_use_of_the_l_small_function prove the range language. 527_identifying_lists_inside_a_string proves the lists hosted in strings. 48_replacebymany proves that the replacements go in order. 483_w_and_wf_forms_in_conditional_code proves the condition in a string, in two spellings of the same scan. 28_numberofoccurrenceofcharleftside proves the alternative names in Arabic as well as Latin, and carries a note that the archive's promise was wrong and the implementation is the authority. 646_content proves the named parameters. 972_narration_viz-finding_a_recurring_substring proves the viz tour.

Here is the house court itself, the fourteen rules of the library and not the fourteen of the style. The numerical coincidence is a coincidence. What does it answer to a planted misspelling, and to a planted write to a constant? Run it:

? @@( StzCodeRuleNames() )
#--> [ "no-len-method", "q-returns-object", "no-aggressive-verbs", "engine-first", "q-has-plain-twin", "no-case-collision", "dead-knob", "setter-resets-on-reject", "setter-only-moves-one-way", "misspelled-name", "library-prints", "empty-method-body", "writes-a-mutable-constant", "value-called-as-function" ]
cOne = "class Inbox" + nl + "def Recieve(x)" + nl + "	return x" + nl
? StzCheckCode(cOne)[1][:rule]
#--> misspelled_name
? StzCodeIsClean(cOne)
#--> TRUE
cTwo = "class Inbox" + nl + "def Count()" + nl + "	nl = 3" + nl + "	return nl" + nl
? StzCheckCode(cTwo)[1][:rule]
#--> writes_a_mutable_constant
? StzCodeIsClean(cTwo)
#--> FALSE

The misspelling is found by name, misspelled_name, and the code stays clean, TRUE, because it is a warning. The write to a constant is found by name, writes_a_mutable_constant, and the code is refused, FALSE, because it is an error. The court refused the write to a constant!

A detail of the spelling, for Appendix B: the names list uses hyphens, and the finding of eight of the fourteen comes back with underscores. The block shows it: the list prints misspelled-name, and the finding prints misspelled_name.

What the court does not read is the code of a program written with the library. The fourteen rules of the house are rules of the library's own code; a rule of writing for the code written with it is designed (section 7).

6. The field, and where it leads

The field leads in enforcement by default. A formatter runs on every commit. For the code a programmer writes with Softanza, the court that would enforce the style is designed and not yet built, and chapter 5 says so.

The field leads in having its goals somewhere a reader looks first. The seven goals are in one design document and in tags that no court reads, and the operating notes of the library's own repository name none of them. An AI reader's account of the library says that sixty paradigm documents could easily be sixty disconnected ideas. The study reads it as a sign that the discipline is in the code and written nowhere a reader would look first. It is a session's document, and not an independent witness.

The site once showed a reduced dialect: its blocks had no named parameter and no scene. It has since put the fourteen rules on its Craft page and the rules as data. I did not re-measure the site's blocks after that.

Where I think the style stands apart is that every rule serves a step of thought, and every step has a written form. The verb's form is a contract on the object. And the promise under the line is the example, the test and the documentation at once. The 2022 matrix served as a skeleton for one architect over about three hundred thousand hand-written lines, by my study's count.

The limit, in the next section, says what is built, what is designed and what is absent.

7. The limit

• builtthe library's fourteen house rules as a court over its own code; the promise judged as a claim; the small languages of ranges, lists and conditions in strings; the code seat; the viz prefix; alternatives and named parameters in any order, in part
• designeda court that judges the style of a program written with the library; a court that reads the goals; the writing grammar declared in Haro; the classic form of a test block as the one form
• absentany machine that judges the style of the code you write today; the writing in any human language of a function's name; the near-natural sentence as the deck wrote it; the eval-based code on a parameter's name

What is built: the fourteen house rules of the library as a court over its own code, run in the block above. Also built: the promise judged by a machine; the small languages, the seat, the prefix. And the features that run (CS, XT and viz, named parameters, the same verb on a string and a list; ZZ runs in chapter 8).

What is designed:

• A court that judges the style of a program written with the library. It is a specification in the study: the fourteen rules as house rules over a snippet's graph. Its examples are a positional argument where a named one exists, or a printed line with no promise. I searched the library for it and it is not built yet; it is the next step.
• A court that reads the goals. It would read the tags. To come.
• The classic form of the test block as the one form for new blocks. The study's ruling is that the revival "is not a rewrite" but a decision. The classic form is the one form for new blocks, and the converted blocks are left as they are. The test tree's own README still calls the classic form the authoritative test surface. I found no ruling that makes it the one form, so it stays a decision, and chapter 5 names it.
• The writing grammar declared in Haro. The vocabulary half exists: the forms of the library's names are data in Haro, and the session's record is 584 of 595 shipped spellings agreeing. The usage half, the scene, the chain, the code seat and the promise, is not declared.
• The discipline declared once. Partly done on the site, as data, which is the page's source and not a court.

What is absent:

• Any machine that judges, today, the style of a program written with the library; beside it, the house court judges the library's own code.
• Rules 12 and 13 as running forms. In my runs, the deck's near-natural samples did not run as written, and neither did a function named in Chinese or in French.
• The @ on a parameter's name as a working form.
• The braced form of the range language, L('{ "♥1" : "♥6" }'), which raises, and ranges that change width, such as day8 : day11, which also raise, with an uninitialised-variable error from the host. The list constructor from a string raises too. These three come from my runs; no block of this chapter keeps them.
• The visualised call stack, and the cache and log decorators, which exist as names in comments.

8. Six doors

9. Exercise

Write, before you run anything, the line each task needs and the promise under it:

1. From one string, the list [ "♥7", "♥8", "♥9" ].
2. The string "haro php haro" with the two haro numbered ♥1 and ♥2, in one call that uses the small language of task 1.
3. The list [ "C", "B", "A" ] ordered by swapping the first and the third items, with the positions named.
4. The count of characters of "سلام", with the name that says what is counted.
5. A guess: what does L("day8 : day11") print?

# 1.
# 2.
# 3.
# 4.
# 5.

Run it. For the fifth, you were allowed to be wrong, and you were probably wrong: the range changes width, so L hands its text to the host to evaluate, the host reads day8 as a variable, and it raises with Using uninitialized variable: day8. That is the limit of the small language, learned by being surprised once. Do not change your promise to match the output. Explain the output first.

I left this one in your hands. The first call of the rule 8 block, with its named start taken out, has two arguments. Nothing else changes:

o1 = new stzList([ 1, 2, "♥", 4, 5, "♥", "♥" ])
? o1.FindNthNext(2, "♥")

Run this one and read what comes back. Then repair the call. Section 3 says where this form of the call comes from and what the guards do instead. When it is repaired, you will know why a call that the library's own narration writes raises, and what the guards pass that it does not.

Chapter 8 takes a function's name whole, as a linguistic expression, and then scope: a function's name is a sentence, and its prefixes, suffixes and parameters are a grammar that the library can read.

Functions as linguistic expressions, and scope

Run on 2026-10-15 12:58 UTC+01:00 inside the library at commit 93d7a39bd: 13 of 13 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I read a function's name the way the library reads it: a sentence whose prefixes, suffixes and parameters are a grammar. I walk the forms of a name that run, and I count the five that do not. Then I turn to scope: the same verb, three verdicts, with the frame in the verb and not in a flag set earlier. I say what Haro's design keeps of the forms, what it refuses, and what the court proves. The principle is this: a function's name is a sentence, and its prefixes, suffixes and parameters are a grammar that the library can read.

1. The concept, as the field holds it

In the field, a function's name is a label. It follows a convention, camel case or snake case, and it tells you roughly what the function does; the details are in the signature and the documentation. A name does not carry grammar. The related tools are all about structure. Python and Swift offer the keyword argument, so that a call can say which parameter is which. The fluent interface chains calls so that a line reads like a sentence, and the overload gives one name several signatures.

And when the field wants a function to behave differently in a different context, it changes its meaning by a flag set somewhere else. The flag is a mode, a locale, an environment variable. The function's name does not tell you which frame it will run in.

2. The first principle

A function's name is a sentence, and its prefixes, suffixes and parameters are a grammar that the library can read. The paper that first made the claim says, in the words the study of its roots quotes, that it was achieved "without machine learning or NLP systems". It was done by naming conventions that encode meaning, a parameter order that mirrors speech, flexible forms and intelligent defaults.

3. The Softanza form

Look at a name the way the library looks at it. FindNextSTCS: find next, from a start position, with a case flag. RemoveManyCS: remove, many things, a case flag. Each suffix is small and means one thing, and, in these names, the order of the suffixes is the order of the parameters. Here the first name finds. What does the second leave when it removes every occurrence of three letters, whatever their case? Run it:

o1 = new stzString("123456789HARO")
? o1.FindNextSTCS("haro", 5, FALSE)
#--> 10
o2 = new stzString("SOOooooFFfffTANNnnnZA")
o2.RemoveManyCS([ "o", "f", "n" ], FALSE)
? o2.Content()
#--> STAZA

The article promised SOFTANZA on the second line. The run prints STAZA! The code is right and the article is wrong: a removal that does not care about case removes the capitals too. I print the run.

Does the library only follow this grammar, or does it read it? Its name parser, _StzParseName, is an internal helper that no guard covers; I call it first below, for the raw reading. The public way in is ExplainMethod, which explains a method in those terms:

? @@( _StzParseName("FindNextSTCS") )
#--> [ "find next", [ "case-sensitive", "from-position", "active" ] ]
? @@( _StzParseName("RemoveManyCS") )
#--> [ "remove", [ "case-sensitive", "plural", "active" ] ]
? StzSelfDocQ("stzString").ExplainMethod("RemoveMany")
#--> RemoveMany -- Remove every occurrence of each given substring (mutating).
#-->   (plural form -- applies the operation to many items at once)
#-->   reads as: remove -- over many values at once

It reads it. That is the claim, made mechanical: the grammar is in the code and not only in the article. The printed line reads as: remove -- over many values at once is the parser's reading of RemoveMany. The parser decodes the prefixes and the suffixes, the words "except" and "is not", and the voice: a name that ends in ed is passive.

I will walk the forms now. Chapter 5 showed four of them: the active, the passive, the fluent and the named parameter. Here are the others that run.

Z and ZZ say whether a position comes as a number or as a section. A suffix, and the answer changes shape:

o1 = new stzString("haro php haro ruby haro")
? @@( o1.FindZ("haro") )
#--> [ 1, 10, 20 ]
? @@( o1.FindZZ("haro") )
#--> [ [ 1, 4 ], [ 10, 13 ], [ 20, 23 ] ]
o2 = new stzString("SOFTANZA")
? @@( o2.FirstHalfZ() )
#--> [ "SOFT", 1 ]
? @@( o2.FirstHalfZZ() )
#--> [ "SOFT", [ 1, 4 ] ]

The prefix viz changes the kind of answer: a drawing. The position is shown under the text, and an option can number it:

o1 = new stzString("fjharoljharodjharog")
? o1.vizFind("haro")
#--> fjharoljharodjharog
#--> --^-----^-----^----
? o1.vizFindXT("haro", [ :Numbered = TRUE ])
#--> fjharoljharodjharog
#--> --^-----^-----^----
#-->   3     9     15

The plural extends a verb to many things without a loop, and the exceptional form keeps only what you name. The article's example for the second, RemoveNonLettersExcept, does not exist. The form does, in other names:

Q("__H~~~AR***O__") {
	? @@( FindMany([ "~", "*" ]) )
	#--> [ 4, 5, 6, 9, 10, 11 ]
	RemoveMany([ "_", "~", "*" ])
	? Content()
	#--> HARO
}
o2 = new stzString("--Haro--&__Softanza__")
o2.RemoveAllExcept([ "Haro", "&", "Softanza" ])
? o2.Content()
#--> Haro&Softanza

The negative is a word in the name, not a NOT around the call:

? Q("*").IsNotLetter()
#--> TRUE
o3 = new stzList([ "H", "A", "R", "O" ])
? o3.IsNotAString()
#--> TRUE
? o3.DoesNotContain("♥")
#--> TRUE

The deep form answers a path, a list of indices that goes as deep as the data does, and the same family replaces and removes at that depth, with :By as its named seat where chapter 5's Replaced said :With; the deep verbs accept both:

Q([ "you", "other", [ "other", "you", [ "you" ], "other" ], "other", "you" ]) {
	? @@( DeepFind("you") )
	#--> [ [ 1 ], [ 3, 2 ], [ 3, 3, 1 ], [ 5 ] ]
	DeepReplace("you", :By = "♥")
	? @@( Content() )
	#--> [ "♥", "other", [ "other", "♥", [ "♥" ], "other" ], "other", "♥" ]
}

The immutable form, QC, runs the whole chain on a copy. After that chain, what does the original hold?

o1 = new stzString("haxxrxo")
? o1.RemoveQC("x").UppercaseQ().Spacified()
#--> H A R O
? o1.Content()
#--> haxxrxo

The chain printed H A R O, and the original still holds haxxrxo!

The misspelled form is accepted, with a note on what stands behind it. A misspelling of a name works:

? Q("   Haro ").WithoutSapces()
#--> Haro

The article says the library recognises and corrects minor typos, and that the intelligence resides in the library itself. The code shows how the form works: WithoutSapces works because that spelling was written by hand as an alias. Another misspelling, WithoutSpces, fails. So the form is real, and in what I traced it is a list of declared aliases; the correction engine the article describes is not among what I traced. I did not trace every file that mentions correction; one message in the object class only suggests a name, with "Did you mean".

Now the scope half of the chapter. The same fault shows up everywhere in programming: behaviour with an invisible governing frame. I hold this as a view, not a result; what stands behind it here is three instances: the regex verbs, the system and the placement of a deployment. A function does one thing here and another there, and nothing in its name says which frame it is in. The answer, in five moves, is the paradigm I call scope-oriented programming. Four come first. Name the hidden frame. Turn it into a small, closed set of named scopes. Choose the scope at the call site, in the verb, and not in a flag set earlier. And give the library the scope to reason with, a semantic handle and not a comment.

It was born in regular expressions, where the frame is how much of the text a pattern must cover. The same pattern, the same text, three verbs: what does each answer?

cText = "First: Line1" + nl + "Second: Line2" + nl + "Third: Line3"
o1 = new stzRegex("^Second:.*$")
o1 {
	? Match(cText)
	#--> FALSE
	? MatchFirst(cText)
	#--> FALSE
	? MatchLine(cText)
	#--> TRUE
}

Match answers FALSE: it asks whether the pattern covers the whole value. MatchFirst answers FALSE too: it asks whether the pattern occurs anywhere, with the line anchors off. MatchLine answers TRUE: it makes ^ and $ bind at each line. The frame is in the verb. There is a word scope too, which supplies the word boundaries so that you do not write them. It rewrites the pattern of its object for good, which is why the second instance is a new object with the same pattern. Does the same pattern answer alike under MatchFirst and under MatchWord?

o2 = new stzRegex("pre\w+")
? o2.MatchFirst("compress")
#--> TRUE
o3 = new stzRegex("pre\w+")
? o3.MatchWord("compress")
#--> FALSE

The same pattern answers TRUE under MatchFirst and FALSE under MatchWord!

The second instance is the system. Feature code is written in a named scope, and the same verb gets a different verdict in each. The scope can make a laptop behave like a device it does not have, or refuse what the target forbids. Here, one solution with a backend on a Linux server and a firmware on a small board. What does each system answer when the same verb, Spawn, is asked of it? Run it:

oSol = new stzPlatformProfile("my-iot-product")
oSol {
	DevelopedOn(:Windows)
	WithServer(:backend, :LinuxServer)
	WithApp(:firmware, :ESP32)
	oBack = App(:backend).System()
	oFirm = App(:firmware).System()
}
? oBack.Spawn("worker")
#--> native
? oFirm.ReadPin(4)
#--> rehearsed
try
	oFirm.Spawn("worker")
catch
	? cCatchError
done
#--> scope 'esp32' (espidf) forbids 'process' -- spawn 'worker'. This target has no such capability.

The same verb, Spawn, has two verdicts! The server answers native; the board answers scope 'esp32' (espidf) forbids 'process'. The scope decides, not the operation. And the laptop has no pin to read, so the scope answers rehearsed. This is the fifth move: when a scope's capabilities differ from the host's, the library bridges the difference, in both directions. Two declared systems can be compared as data, with a closed set of capabilities:

oEsp = DeclareSystem("esp32-firmware")
oEsp.SetOSName(:rtos)
oEsp.SetCapabilityList([ :gpio, :network, :clock, :threads ])
oBox = DeclareSystem("laptop")
oBox.SetOSName(:windows)
oBox.SetCapabilityList([ :filesystem, :process, :network, :clock, :threads ])
? @@( oBox.Forbids(oEsp) )
#--> [ "filesystem", "process" ]
? @@( oBox.Requires(oEsp) )
#--> [ "gpio" ]

The run printed [ "filesystem", "process" ] for what the laptop can do that the board cannot, and [ "gpio" ] for what the board needs that the laptop lacks. That is the second instance. The third is deployment: the target is the frame, and the scope decides not to ship what the target already does well; chapter 4 showed the plan. The fourth is concurrency, and it is a plan.

The design is next, with what Haro keeps of these forms and what it refuses.

5. The court

00_regex_narrated proves the verbs Match and MatchFirst: Match anchors, MatchFirst searches, Z hands back positions and does not print them. It asserts nothing for MatchLine and MatchWord: the blocks above show them, and only classic blocks, which are not guards, cover them. 972_narration_viz-finding_a_recurring_substring proves the drawn answer. full_scope_model_narrated proves the system scope, with its three verdicts. system_scope_model_narrated proves the closed set of capabilities; one of its assertions is a timing limit, and section 7 says what one probe showed of it. delivery_narrated proves the placement plan.

Where the field does better comes next.

6. The field, and where it leads

The field leads in convention. A name that is a label is easier to teach and easier to type. The grammar of this chapter has to be learned, and some of its forms are rarely used.

The field leads in the guarantee. Python's keyword arguments are checked at the call, and Swift's labels by the compiler, for every function, from the first day. The forms here are judged by the Haro spike, on names and not on bodies, and by the library's own parser, and only in the names that follow them.

On scope, the field leads in maturity. The closest field practice is the explicit context: the Go habit of passing a context to every call, a locale object that carries a frame. They are older and more widely used. What this paradigm adds is that the frame is one of a small, closed set, chosen in the verb, and the library can reason with it.

Last, the limit, with what is built, what is designed and what is absent.

7. The limit

• builtfourteen of the twenty-two forms, some with examples other than the article's, and three more in another shape; the library reading a name as a sentence; scope in the regex verbs, in the system and in the placement of a deployment
• designedthe forms declared once as data and generated, in Haro; the scope paradigm for time, units, memory and style
• absentfive forms: partial, future, free, default and multilingual; concurrency as a scope: a plan with no code

What is built: fourteen of the twenty-two forms of a name run, some with examples other than the article's, and three more run in another shape. The library reads a name as a sentence. And scope runs in the regex verbs, in the system, and in the placement of a deployment. The article counts twenty-three sections: the twenty-two forms of a name, and "small functions", which are functions and not a form of a name. The book's number is twenty-two, the forms of a name.

What is designed: Haro's forms as data, with generated families; and the scope paradigm for time, units, memory and style, as rows of a table.

What is absent, and the page should say each with what exists beside it:

• Partial, @Removed, is in the archive only: the call is not defined.
• Future, BeforeQ, was trimmed on purpose, as I said.
• Free, the suffix that lets a call give its parameters in any order and any subset: there is no definition of it outside the archive. The library's own parser knows the name FX and not FF. The two narrations that tell it use two names, and the code has neither.
• Default, dftRange and infRange: not defined; the library's comment calls the informing form not yet built.
• Multilingual, a method named in French or Arabic: not in the live library. The names exist in the archive. The nearest thing today is the language packs of chapter 11.
• The three that run in another shape. The exceptional form exists, but the article's example does not. Free order, as the article means it, a number and a string swapped in their positions, works for the first order only: in my probe of 8 October, the swapped call ended the program with a status of one and printed nothing. The free order of named parameters is another thing, and chapter 7 runs it. And the statement form is half in place: the "All" half works, and the "No" half is the next step. The library's own classic test promises true on two of its four "No" lines, and the run prints false on all four.

On the scope side: the regex verbs differ from the table of the scope design document in two places. MatchLine lets a dot cross a line, where the table says it stays within one, and MatchOneSegment, which the table offers for the lazy case, is not defined. The system scope is built, and the design document still calls it designed: the record contradicts itself. The scope design document, version 1.2 of 16 August 2026, is quoted here as the document's text. The record does not say who wrote it, and I do not print it as mine. The system foundation document of 20 July 2026 says the foundation is implemented. In one probe run under load, which the book's data does not keep, 61 of the 62 assertions of its narrated guard passed, and the one assertion that did not hold was a timing limit. I state what the code does: the system scope is built, with that result printed beside it, and the design document's word "designed" is the document's, out of date. And concurrency is a plan of record with no code: the word Concurrently has no definition.

8. Six doors

9. Exercise

Take one verb from a library you use that behaves differently in two frames: a mode, a locale, a target. Say in one sentence what the hidden frame is. Then write, as you would like it to be, two names for the same act in the two frames, with the frame in the verb. Before you run anything in Softanza, take Match and MatchLine on a text of three lines and write what each prints for a pattern that anchors at the start.

Run it. If your two names differ only by a flag, you have not yet moved the frame into the verb.

I left this one in your hands, on purpose. In section 3 the article promised SOFTANZA from a removal, and the run printed STAZA. Here is that block with one change, the last argument of the call:

o2 = new stzString("SOOooooFFfffTANNnnnZA")
o2.RemoveManyCS([ "o", "f", "n" ], TRUE)
? o2.Content()

Run it. Set what it prints beside what the article promised and beside what the first run printed. Section 3 says why the first run did not give the article's line; I do not print what this one gives. When you have solved it, you will know what the case flag decides in a removal, and whether it alone can keep the article's promise.

Chapter 9 turns to patterns of thought. It presents the Softanzuter, a computational representation of a thinking machine. It is based on one or many Regexuters, which identify and react to patterns of thought. With it come Reaxis and the engines.

Patterns of thought: the Softanzuter, Reaxis and the engines

Run on 2026-10-15 12:58 UTC+01:00 inside the library at commit 93d7a39bd: 8 of 8 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I take the three subjects of the title in turn: the Softanzuter, Reaxis, and the engines, of which the timeline and the grid run here. The Regexuter binds a pattern to code that fires and remembers why; Reaxis is reactive programming with its vocabulary redesigned. I climb the ladder the architecture draws, four rungs, and at the third I run the block that fails to cascade rather than claim a rung that is not built. I say what I refused: regex as a way to read text, the field's words for reactive programming, the four siblings, and the cascade. Everything serves one sentence: a Softanzuter is a computational representation of a thinking machine, based on one or many Regexuters, enabling it to identify and react to patterns of thought.

1. The concept, as the field holds it

The field has three tools for making a program react. Regular expressions recognise a shape in text, and nothing more: they say "this matches", and they stop. Reactive programming, the family of observables, subscribers and schedulers that Rx made popular, lets data flow through a program over time. Its vocabulary comes from plumbing, telephony and publishing: pipes, backpressure, hot and cold sources. And rule engines, the production systems of the field with their forward chaining, fire rules when facts appear, and keep firing while new facts appear; that is general knowledge, and the rule engines of the field are older and more mature than anything in this chapter.

Each tool is separate. A regular expression does not trigger a computation, a reactive stream does not recognise a pattern, and a rule engine does not have a vocabulary that a person would use to say a thought. I hold this as a view, not a result.

The next section gives the one sentence I answer with.

2. The first principle

I gave this paradigm one sentence, and everything below tries to make it mechanical: a Softanzuter is a computational representation of a thinking machine, based on one or many Regexuters, enabling it to identify and react to patterns of thought.

The next section shows how far the library has made it mechanical.

3. The Softanza form

The architecture draws it as a ladder with four rungs, each adding one thing.

The first rung is the pattern. You will see it in chapter 15: a shape in a medium, a string, a list, a number, that can say "this matches, and here is how", and do nothing more. The second rung gives a pattern a reaction: the Regexuter, a reflex arc. You bind a pattern to code, process a text, and the code fires on every match. A Regexuter reacts, and it remembers what it did. Here it redacts the secrets in a sentence. What does the state it keeps say about each one: what it matched, what it computed, where, and which trigger fired?

rxu() {
	Trigger(:SensitiveData = "(password|secret|key):\s*(\w+)")
	@C(:When = :SensitiveData, :Do = '{ @value = "REDACTED-" + len(@value) }')
	Process("User credentials: password: abc123 secret: def456")
	? @@( Results() )
	#--> [ "REDACTED-16", "REDACTED-14" ]
	? @@( Positions() )
	#--> [ 19, 36 ]
	? State()[1][:matchedvalue]
	#--> password: abc123
	? State()[1][:computedvalue]
	#--> REDACTED-16
	? @@( State()[2][:dependson] )
	#--> [ "sensitivedata" ]
}

The state is provenance: every reaction that changes a value keeps its why. The last line, [ "sensitivedata" ], is also an honest limit, and I will come back to it: what the Regexuter records as a dependency is today only its own trigger.

Now the third rung, the one the definition is about. It is many Regexuters, over different media, sharing one state, so that what one faculty writes is a medium another faculty can match over. A thought is a state entry with its provenance, and a settled thought is a state in which nothing more fires. That rung is not built, and the block shows how I know. The second trigger below is written for numbers of three digits or more. The first trigger turns the 7 into 700, which is one. If the machine thought in cascades, would the second fire on the first's result? Run it:

rxu() {
	Trigger(:Number = "\d+")
	Trigger(:Big = "\d{3,}")
	@C(:When = :Number, :Do = '{ @value = @number(@value) * 100 }')
	@C(:When = :Big, :Do = '{ @value = "BIG" }')
	Process("Found 7 items")
	? @@( Matches() )
	#--> [ "7" ]
	? @@( Results() )
	#--> [ 700 ]
	? @@( Triggers() )
	#--> [ "number" ]
}

It did not: the results read [ 700 ], the triggers that fired read [ "number" ]. BIG is nowhere! Every trigger is matched once against the original text, and what one trigger writes is not offered to the others. That is the whole difference between the second rung and the third.

The cascade runs one rung above, at the fourth rung, the AI agent: the thinking machine given a body in a world, and a goal. Its mind is made of skills, each with a condition and an action, which chain. The second skill fires on the fact the first one wrote. Pursue() returns how many skill firings were verified, and goes on until the world stops changing, or for twenty rounds at most. What does it answer when asked again?

oAgent = new stzPIAgent("cook")
oAgent.MemoryQ().Learn("order", "state", "placed")
s1 = new stzAgentSkill("cook")
s1.SetWhen(func oM { return oM.Fact("order", "state", "placed") })
s1.SetDoes(func oM { oM.Forget("order","state","placed") oM.Learn("order","state","cooking") return 1 })
s2 = new stzAgentSkill("serve")
s2.SetWhen(func oM { return oM.Fact("order", "state", "cooking") })
s2.SetDoes(func oM { oM.Forget("order","state","cooking") oM.Learn("order","state","served") return 1 })
oAgent.AddSkill(s1)
oAgent.AddSkill(s2)
? oAgent.Pursue()
#--> 2
? oAgent.MemoryQ().Fact("order", "state", "served")
#--> TRUE
? oAgent.Pursue()
#--> 0

It answers 2, then 0, and between the two the fact served reads TRUE. That is a fixpoint. The guard that proves it labels the scene in its own words: the cascade to fixpoint (Softanzuter at agent level). In chapter 17 you will see an agent of this same class refused at a gate. Here is the other face of it: the agent that chains, because its mind is programmatic.

So the word has three meanings in the record, and the reader deserves to be told which is which. First, in this chapter, "Softanzuter" is the third rung, the thinking machine of the definition: designed, not built. Second, the engine has a module with the same name, which the macroplan presents as the foundation for AI agents. Its slots hold a state and a bounded mailbox, and a message into a full queue is refused, counted and never dropped quietly; the agent of the block above, stzPIAgent, never calls it. Third, the design of a universal engine behind all of it, a medium where any pattern language becomes a computation, is planned.

Reaxis is the second subject of the chapter's title, and it is a different idea. It is reactive programming with a vocabulary redesigned from the ground. A reactive thing is a Container, a Stream and an Rfunction: a function in waiting, which is not a callback. Data flows through a stream in plain words, a transformation, a filter, what to do with what passes. Four prices go in, 80, 90, 100 and 120: which ones come out, and at what value?

aSeen = []
Rs = new stzReactiveSystem()
Rs {
	oStream = CreateStream("prices")
	oStream {
		Transform(func price { return price * 1.20 })
		Filter(func price { return price >= 100 })
		OnPassed(func item { aSeen + item })
		FeedMany([ 80, 90, 100, 120 ])
	}
	RunLoop()
}
? @@( aSeen )
#--> [ 108, 120, 144 ]

aSeen reads [ 108, 120, 144 ]: the 80 became 96 and was dropped by the filter; the 90 became 108 and passed. Three functions are in waiting, and nothing here is called a subscriber; the old word Subscribe survives as an alias of OnPassed.

Reaxis replaced backpressure with overflow, a word you do not need a diagram to understand. And it was audited. A reading of the four strategies the article documented found that three of them lost data and reported none. The default discarded everything past the capacity while the counter read zero. That is fixed, and proved for all four strategies. Here, four items go into a buffer of two. What does the stream say happened?

oRs = new stzReactiveSystem()
oS = oRs.CreateStream("probe")
oS {
	SetOverflowStrategy(BUFFER_REJECT_NEWEST, 2)
	for i = 1 to 4
		Receive(i)
	next
	? OverflowStats()[:currentBuffer]
	#--> 2
	? OverflowStats()[:droppedCount]
	#--> 2
}

It says currentBuffer is 2 and droppedCount is 2. The counter that read zero now counts!

And for what the field calls debounce, Reaxis says what it means: wait for the attribute to settle. Three changes in quick succession: how many reactions, once the value has stopped changing for fifty milliseconds?

nSettled = 0
oRs4 = new stzReactive()
oX = oRs4.ReactiveObject()
oX.WaitForAttributeToSettle("query", 50, func(attr, oldV, newV) { nSettled++ })
oX.SetAttribute("query", "s")
oX.SetAttribute("query", "so")
oX.SetAttribute("query", "sof")
oX { ProcessPendingReactions() }
oRs4.RunLoop()
? nSettled
#--> 1
oRs4.Stop()

One reaction. nSettled reads 1.

The chapter's third subject is the engines, the small paradigms the library rethought one by one. Chapter 3 gave you truth and emptiness. Two more, run here. Time is a workspace, not a number. A timeline holds spans and computes the gaps and the overlaps. What does it say of the gap between two phases, and what does it do with a point that would fall into a blocked region?

oTl = new stzTimeLine("2024-01-01 00:00:00", "2024-12-31 23:59:59")
oTl {
	AddSpan("PHASE1", "2024-01-01 00:00:00", "2024-02-15 23:59:59")
	AddSpan("PHASE2", "2024-03-01 00:00:00", "2024-04-15 23:59:59")
	? len(Gaps())
	#--> 1
	? Gaps()[1][:after]
	#--> PHASE1
	? Gaps()[1][:before]
	#--> PHASE2
	? HasOverlaps()
	#--> FALSE
	AddSpan("PHASE2B", "2024-04-01 00:00:00", "2024-05-15 23:59:59")
	? HasOverlaps()
	#--> TRUE
}
oB = new stzTimeLine("2024-01-01", "2024-12-31")
oB {
	AddBlockedSpan("MAINTENANCE", "2024-06-15 09:00:00", "2024-06-15 17:00:00")
	AddPoint("EVENT1", "2024-06-15 08:00:00")
	try
		AddPoint("EVENT2", "2024-06-15 12:00:00")
	catch
		? cCatchError
	done
	#--> Point 'EVENT2' falls within a blocked span or blocked point
}

The gap is named by what it lies between, PHASE1 and PHASE2. The blocked span refused EVENT2! The refusal carries its reason: Point 'EVENT2' falls within a blocked span or blocked point.

And a grid has a cursor that knows where it is: position is column and row, and moving past an edge stays at the edge. Two moves down and three to the right, then three more to the right: where is the cursor?

StzGridQ([ 5, 5 ]) {
	MoveDown()
	MoveDown()
	MoveRight()
	MoveRight()
	MoveRight()
	? @@( CurrentPosition() )
	#--> [ 4, 3 ]
	MoveRight()
	MoveRight()
	MoveRight()
	? @@( CurrentPosition() )
	#--> [ 5, 3 ]
}

At [ 4, 3 ], then at [ 5, 3 ]. Three more moves to the right gained one column, and the cursor stayed at the edge!

5. The court

The Regexuter and the Listexuter have classic tests, and no narrated guard. The Regexuter's eight classic tests ran without error: the folder's log reads PASS 8 ERR 0. Nothing there checks what they print. Five of the Listexuter's seven fail their own expected output, and two promise nothing. The agent's cascade is proved by piagent_narrated, scene five. Reaxis has many guards. 00_overflow_narrated proves the four overflow strategies and the case that loses nothing; 60_reaxis_on_reactor_narrated proves a one-shot timer, the repeating timer, non-blocking HTTP and the settling attribute on the engine's loop. The timeline has test_timeline_regression, which covers construction, duration, adding points and moving the ends, and not gaps, overlaps or blocked spans. The grid has 00_grid_narrated, and deep operations 01_deeplist_narrated.

The next section sets this record beside the field's.

6. The field, and where it leads

The field's rule engines lead. They are older and more mature than the Regexuter, they chain to a fixpoint, and the algorithms behind them are decades old. What I claim is not a rule engine. It is the condition side: rules that are sentences of the pattern languages, over the two media that have a reacting machine built, text for the Regexuter and lists for the Listexuter. The state keeps, for every firing that changes a value, its why. The library's own architecture calls the Regexuter a nascent forward-chaining rule engine, and I will not call it more.

The field's reactive libraries lead in reach. Rx exists in most mainstream languages, with a large set of operators; that is general knowledge. Reaxis is one library on one event loop. The engine's own module for it is a small table of substring rules: the Container, Stream and Rfunction model lives in the library, on the event loop of the engine.

I will not print the star-rating comparison with the field's tools that the library's article on reactive objects carries. It is undated and unsourced.

The next section says where all of this stops.

7. The limit

• builtthe Regexuter and the Listexuter, reacting with a state that remembers; Reaxis, reactive programming in plain words, on the engine's event loop; the timeline, the grid and deep operations; the AI agent whose skills cascade to a fixpoint
• designedthe Softanzuter proper, many faculties sharing one state and cascading until it settles; the universal engine behind it; its four siblings, analyser, genetic, linguistic and quantic
• absenta dependency chain that links one trigger to another; a section-merging verb the article presents as its point

What is built: the Regexuter and the Listexuter; Reaxis on the engine's event loop; the timeline, the grid and deep operations; the AI agent whose skills chain.

What is designed: the third rung, many faculties on one shared state, cascading until it settles. The universal engine for it is planned. The four siblings are vision. The macroplan marks the engine module as done, and the architecture table marks it planned: the same name for two things. That table marks every module of its fifth layer planned, including ones that have source, so it is stale on this point. The universal medium is planned in the engine design document.

What is absent or broken at this commit:

• The dependency chain is not one. Each state entry depends only on its own trigger, so the chain records which trigger was active and never a link between two. Asking for the chain overflows the stack: the run ends with Error (R4) : Stack Overflow. No test calls it.
• Five of the Listexuter's seven classic tests fail their own expected output, and two promise nothing. The error log of that folder records, in the sixth file, Error (C8) : Parentheses ')' is missing.
• A nested list that matches as a whole is reported twice.
• The article's repeating timer takes three arguments and the library takes two; the form with units is RunEveryXT.
• Two of the deep-lists article's path verbs, ItemAtPath and ItemsAtPaths, live on a subclass, stzDeepList, and not on a plain list; Paths() is on a plain list.
• The section-merging article presents a comprehensive verb as its point, and that verb does not exist. The two that do exist, merging what overlaps and merging what is included, run. Section merging has no test file of its own.
• There is no native engine module for the Container, Stream and Rfunction model: it runs in the library, and the engine's own reactive module is a small table of substring rules. The timeline's guard checks no gap, no overlap and no blocked span; in the classic timeline files, seven fail their expected output and eighteen promise nothing. The grid's engine-backed navigator, stzGridNav, has no test.

8. Six doors

9. Exercise

Write a Regexuter with two triggers, one for numbers and one for numbers of three digits or more, with code that turns a number into its triple. Before you run it, write under each question what you expect: what the matches are, what the results are, and whether the second trigger fires on the first one's result. Run it. If the second trigger fires, you have found something I did not.

Then say in one sentence what would have to change in the machine for it to fire, and which rung of the ladder that change belongs to.

I left this one in your hands. Take the second block of section 3 and write its two Trigger lines in the other order, the three-digit one first:

rxu() {
	Trigger(:Big = "\d{3,}")
	Trigger(:Number = "\d+")
	@C(:When = :Number, :Do = '{ @value = @number(@value) * 100 }')
	@C(:When = :Big, :Do = '{ @value = "BIG" }')
	Process("Found 7 items")
	? @@( Matches() )
	? @@( Results() )
	? @@( Triggers() )
}

Before you run it, write down whether the order changes what Results() and Triggers() hold. I do not print the output of this version, and I do not tell you the answer: section 3 says what each trigger is matched against, and section 4 says what I refused to claim. When you can say why, you will know what separates the second rung from the third.

Chapter 10 turns from the machine that thinks to the code that changes. Its title is Programming becomes refinement, and it holds to one principle: stop trying to govern the intelligence, and govern the change.

Programming becomes refinement

Run on 2026-10-15 12:58 UTC+01:00 inside the library at commit 93d7a39bd: 9 of 9 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I say what I mean by refining rather than programming. It is a change to code declared to be changeable, proposed in a typed form, judged by a gate, recorded as a step, and reversible. I run the library's form of it: the refinement point, the proposal, the gate, the cascade, the trust floor and the reversal. And I print the gate as it is, five checks and not the four of my design. I say where the field leads and where the gate stops. The principle is the sentence I wrote on the back cover of my earlier book, Refinement-Oriented Programming: stop trying to govern the intelligence, and govern the change.

1. The concept, as the field holds it

The field has a name for changing infrastructure with a rehearsal: plan, then apply. A tool computes what would change, shows it, and applies it only when you say so. Terraform made the pattern familiar, and the field's admission controllers apply the same idea to a request before a cluster accepts it. More recently, the field has a name for a way of working with code-writing AI agents: specifications first, and the agent fills in. All of this is general knowledge, not a study of the record.

What these share is where they stand. The plan and the admission control are about infrastructure and requests. For the code itself, much of the field's answer to a change is still a diff, a patch of text, and a person's review of it. That worked while every change had a person behind it who could be asked. It is a weak instrument when most changes arrive from agents, in volume; I hold this as a view, not a result.

Against that weak instrument I set one sentence.

2. The first principle

I wrote the sentence on the back cover of my earlier book, Refinement-Oriented Programming, and I have not found a better one: stop trying to govern the intelligence, and govern the change. The library's header says the same thing in the form of a type: a change is a typed proposal, not a diff.

The rest of the chapter runs that sentence.

3. The Softanza form

The practice has changed names in my life. I used to say I programmed. I now say that, more and more, I refine, and I mean something exact by it. A refinement is a change to code that was declared to be changeable, proposed in a typed form, judged by a gate, recorded as a step, and reversible. My earlier book, Refinement-Oriented Programming, tells the discipline through the story of Softibank, a bank facing a regulator's letter. This chapter tells what the library carries of it.

It begins by declaring where the code may change. A refinement point is a named knob written in the source as a tag, with its kind, its value and its bounds, and the code that holds it is questioned in its scene, the form of chapter 5:

cSrc = 'vat_rate = <R:PARAM name="vat" value="0.20" min="0" max="0.25">' + nl +
       'sort_by  = <R:ALGO name="sort" value="quick" options="quick|merge|heap">'
o = new stzRefinableCode(cSrc)
o {
	? NumberOfPoints()
	#--> 2
	? @@( RefinementPoints() )
	#--> [ [ "vat", "param", "0.20" ], [ "sort", "algo", "quick" ] ]
	? KindOf("vat")
	#--> param
}

A change is then a proposal. It names a point and a value; if it clears the gate it takes effect and is recorded as one step:

o {
	r = Refine("vat").To("0.22")
	? r[:admitted]
	#--> 1
	? ValueOf("vat")
	#--> 0.22
	? NumberOfSteps()
	#--> 1
}

The admission prints as 1 and 0, not TRUE and FALSE: that is how this verb answers, and I print the run. And what does a proposal that does not clear the gate change, and what does the gate say? Run it:

o {
	r2 = Refine("vat").To("0.99")
	? r2[:admitted]
	#--> 0
	? r2[:why]
	#--> constraint: 0.99 above max 0.25
	? ValueOf("vat")
	#--> 0.22
	? Refine("sort").To("bubble")[:why]
	#--> constraint: 'bubble' not in options quick|merge|heap
	? Refine("ghost").To("1")[:why]
	#--> structural: no refinement point 'ghost'
	? NumberOfSteps()
	#--> 1
}

Three refusals, and the timeline did not grow by a step! The library's comment calls this a law of its own: a rejected proposal never ends changed. Each refusal names its stage first, constraint twice and structural once, as in structural: no refinement point 'ghost', so that a person, or an agent, can correct the proposal without reading a diff.

The cascade is what you read instead of the diff. Before the change, ask what it reaches. There are two cascades, and they are separate. For a point, it is the line it sits on and the other points on that same line:

cPrice = 'price = <R:PARAM name="vat" value="0.20" min="0" max="0.30"> * <R:PARAM name="margin" value="1.1" min="1" max="2">' + nl +
         'floor = <R:PARAM name="floor" value="0.10" min="0" max="0.30">'
oc = new stzRefinableCode(cPrice)
oc {
	aC = Cascade("vat")
	? aC[:lines][1]
	#--> 1
	? @@( aC[:alsoTouches] )
	#--> [ "margin" ]
	? Cascade("floor")[:lines][1]
	#--> 2
	? len(Cascade("floor")[:alsoTouches])
	#--> 0
}

vat sits on line 1 and also touches [ "margin" ]; floor sits on line 2, alone.

For a class, the cascade is a property of the structure of the code: who descends from it and who inherits a method. The library computes it from the code graph, and it can scan a text without touching a file:

cCls = 'class Tariff' + nl +
       '	def Rate()' + nl +
       '		return 0.20' + nl +
       'class Invoice from Tariff' + nl +
       '	def Total()' + nl +
       '		return 1' + nl +
       'class Receipt from Invoice' + nl +
       '	def Print()' + nl +
       '		return 1' + nl +
       'class Quote from Tariff' + nl +
       '	def Rate()' + nl +
       '		return 0.18' + nl
g0 = new stzRingCodeGraph("")
g0 {
	ScanSource(cCls, "world.ring")
	BuildGraph()
	? @@( Cascade("Tariff")[:descendants] )
	#--> [ "Invoice", "Quote", "Receipt" ]
	? Cascade("Tariff")[:blastRadius]
	#--> 3
	? @@( ImpactOf("Rate")[:inheritedBy] )
	#--> [ "Invoice", "Receipt" ]
}

Change the rate of the tariff and three classes are in the blast radius. Two of them inherit the method, and ImpactOf names them: [ "Invoice", "Receipt" ]. The third, Quote, redefines it, so it owns the method and does not merely inherit it. That is the difference ImpactOf draws.

How does a change reach its dependents? By a rule that spans several points, judged on the state the change would produce. If the rule fails, the value is put back:

d = new stzRefinableCode(cPrice)
d {
	DeclareDerivation("vat-above-floor",
		func oCode { return ring_number(oCode.ValueOf("vat")) >= ring_number(oCode.ValueOf("floor")) },
		"vat must not drop below floor")
	? Refine("vat").To("0.30")[:admitted]
	#--> 1
	r3 = Refine("vat").To("0.05")
	? r3[:admitted]
	#--> 0
	? r3[:why]
	#--> derivation: rule 'vat-above-floor' violated -- vat must not drop below floor
	? ValueOf("vat")
	#--> 0.30
}

The rule refused the change and named itself: derivation: rule 'vat-above-floor' violated -- vat must not drop below floor. The value is still 0.30.

And who proposed it? Every proposal carries its origin, and a point can set a floor of trust that refuses a lower origin, without refusing a person. What happens to a proposal from a language model when the floor of the point asks for a trusted origin? Run it:

d {
	TrustFloor("vat", :trusted)
	r4 = Refine("vat").As(:llm).To("0.25")
	? r4[:admitted]
	#--> 0
	? r4[:why]
	#--> trust: posture :llm below the required floor for 'vat'
	? ValueOf("vat")
	#--> 0.30
	? Refine("vat").As(:trusted).To("0.25")[:admitted]
	#--> 1
	? PostureOf(NumberOfSteps())
	#--> trusted
}

The model's proposal was refused: trust: posture :llm below the required floor for 'vat'. The point kept 0.30! The same proposal from a trusted origin was admitted, and the step records trusted.

And who may turn which knob? That is declared, too: a permission, and an authority level against a risk tier. Take a delegated actor and a knob of the third tier. Run it:

gv = new stzRefinableCode(cPrice)
gv {
	SetGovernedBy(new stzGovernance("release-ops"))
	SetActor("release-bot")
	SetRiskFor("vat", 3)
	SetAllowRefine("vat")
	SetAuthorityLevel(:Delegated)
	r5 = Refine("vat").To("0.22")
	? r5[:admitted]
	#--> 0
	? r5[:why]
	#--> governance: refused: 'release-bot' holds 'delegated' authority (level 2) but 'refine-vat' is risk tier 3 (SHOULD does not cover it)
	? ValueOf("vat")
	#--> 0.20
	SetAuthorityLevel(:Autonomous)
	? Refine("vat").To("0.22")[:admitted]
	#--> 1
	? GovernanceQ().NumberOfDecisions()
	#--> 1
}

The delegated actor was refused, 'release-bot' holds 'delegated' authority (level 2), and the value stayed 0.20. The same proposal was admitted once the actor was escalated! The decision is recorded: NumberOfDecisions() printed 1.

Last, can a step be taken back? Reversibility is part of the data model: every admitted step keeps its prior value. Rewind to a named checkpoint, rewind to zero, go forward again:

t = new stzRefinableCode(cPrice)
t {
	Refine("vat").To("0.21")
	Refine("vat").To("0.22")
	Checkpoint("reviewed")
	Refine("vat").To("0.28")
	? ValueOf("vat")
	#--> 0.28
	RevertToCheckpoint("reviewed")
	? ValueOf("vat")
	#--> 0.22
	? NumberOfSteps()
	#--> 2
	RevertTo(0)
	? ValueOf("vat")
	#--> 0.20
	? CanRevert()
	#--> 0
	Redo()
	? ValueOf("vat")
	#--> 0.21
}

At zero, CanRevert() printed 0. One Redo(), and the value is 0.21, the first step again.

That is the gate in the form the library has it. Five checks, in the order the code runs them. The structure of the proposal, then the constraints of the point, then the governance, then the trust of the origin, and last the derivation across points. I ran them above in the order of the story, not of the code. The header of the file calls this a four-stage gate in one line and five in another. The code numbers its checks 1, 2, 3, 4 and 4b. The trust check was added to the four on 16 July 2026, and the design's count was not changed. I report what runs: five checks.

Behind the gate stand decisions, and what I refused.

5. The court

refinablecode_narrated proves the point declared, the proposal that passes, the two refusals that leave the source whole (bounds and options), the cascade, the reversal, and the saved file. refine_deepening_narrated proves the timeline with its checkpoints and its redo, and the trust floor. gate_deepening_narrated proves the refusal of an unknown point, the derivation across points with its rollback, and the governed refusal with its lineage.

Next comes the field, and where it leads.

6. The field, and where it leads

The field leads in infrastructure, where plan and apply are the daily practice of many teams and the apply talks to real providers; this is general knowledge, as in section 1. Softanza's gate is about the change to code, which the field handles with a review.

The field's tools lead in breadth: they are not tied to one library, one language, or one declared knob. Softanza's gate judges what the code declared as a point. A change to a place that was never declared is not a refinement here; it is outside the gate.

And on trust, much of the field's approach is built to scale to any AI model. Mine rests on one declaration per point.

Now, where the gate stops.

7. The limit

• builtthe refinement point declared in the source; the gate with five checks; the cascade of a point and of a class; reversal by step, by checkpoint and to zero; the trust floor and governed refining
• designedthe experience the article describes: asking a point to explain itself, applying a plan, a one-line refinement; the cascade of the code graph joined to the gate; the refinement seat of Haro
• absenta saved history: the file keeps the source and nothing of the timeline

What is built: the refinement point, the gate with its five checks, the cascade of a point and of a class, the reversal, the trust floor, and governed refining. The guards of section 5 cover them, with two exceptions. The cascade of a class has no guard here, because the code-graph guard scans a live path of the library's working tree. And no guard asserts the other points on a line.

What is designed, and absent from the library by name: the experience the original article describes. The class that article names, stzPolyCode, is not in the library at this commit. The one-line refinement of the design document, a point that explains itself, a plan that is applied, are not in the library. The cascade of the code graph and the cascade of the gate are not joined. And Haro has a gate in a spike written only in the former host language, with its own seat for refinement not built.

What is built, and where it stops: the limits of the gate as it stands.

• It checks the constraints of three kinds of point, a parameter, an algorithm and a library. A point of another kind, a block of code for instance, parses and passes without a check; checks for those kinds are the next step.
• An unknown trust posture ranks as trusted: the code gives it the top rank. So a proposal from an origin the code does not know clears a floor of trusted.
• A derivation is applied tentatively and restored on failure. So I say "never ends changed", not "never touched".
• The saved file holds the rendered source; the history, the postures, the timeline and the load-back are absent, and are the next step. Reversibility lives in the running object, and carrying it into the file is still to come. The library writes this file with the suffix .zrfn, as shipped. The Haro charter, ratified on 1 October 2026, takes the suffix .rfn for the refinement sentence of Haro, and leaves .zrfn to the library's lift from comment tags, the form this chapter ran.

8. Six doors

9. Exercise

Take two settings of a program of yours: a rate and a ceiling, say, with a rule that the rate must stay below the ceiling. Declare them as points, with bounds, and declare the rule across them. Before you run anything, write under each proposal whether it is admitted and, if not, at which stage it is refused. Propose a change of the rate above the ceiling, and one from an origin you declare as an AI model, against a floor you set. Then rewind to zero and go forward one step.

Run it. If you were wrong about the stage, you have found a place where your own gate disagrees with your own expectation.

I left this one in your hands. Section 7 says what the gate does with an origin the code does not know, and the trust block of section 3 is the block to run. Its first lines are below, and d is the object of that block, so run section 3 first; change one thing, and replace :llm with a name of your own, one the code was never told about.

d.TrustFloor("vat", :trusted)
r4 = d.Refine("vat").As(:yourorigin).To("0.25")
? r4[:admitted]

Run it, and read what the gate does against what section 7 says it does. I will not tell you whether the gate is right. When you have decided, you will know what the trust floor does with an origin it has never met.

The next chapter states a law: a language is declared and closed, and whatever speaks it, a person or a model, is judged by it. Here the thing judged was a change; there it is whoever speaks.

Law: a language is declared and closed, and whatever speaks it, person or model, is judged by it

Run on 2026-10-15 12:58 UTC+01:00 inside the library at commit 93d7a39bd: 11 of 11 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I state the law of Part III and run it. I begin with a sentence that runs because every word of it is in a dictionary the library owns, in English, Hausa, French and Arabic. I show what the library says about a word it does not know. Then I declare the shape of an answer as a schema, judge answers against it, and show the one thing a grammar cannot kill: a false answer in the right shape. I say which guards prove this, where the field is ahead, and where the natural layer is not yet closed, which the law states. The law itself is one sentence: a language is declared and closed, and whatever speaks it, a person or a model, is judged by it.

What the AI age changes here

In Part II, the age changed who writes the code. Here it changes who speaks the sentence. A sentence of a language used to have a person behind it, someone who could be asked what they meant. Today the writer of a sentence can be an AI model, which cannot be asked, and which will write a fluent sentence whether or not it is true.

So the grammar must be closed, and the court, the part that accepts or refuses a sentence by its grammar, must read it. A language whose sentences may contain anything cannot refuse anything, and a court cannot judge a sentence it cannot read. The vision of the platform puts the whole movement in one line, which I ratified: humans and machines meet in declared languages, small, closed and judged, not in general-purpose code.

This is also where the order of the book turns around. The cover goes from the familiar to the new: programming, languages, intelligence. The record's logic goes the other way. The first act is to declare a language. Programming, the discipline of Part II, happens inside declared languages: the forms of the vocabulary are already a declaration in Haro, in a spike, a short experiment written to try a design, outside the library. Intelligence, Part IV, is governed by both: a model is held to a declared grammar before it speaks, and its sentence is judged after. The book keeps the cover's order, so this chapter sits in the middle; in the record's order it would come first.

1. The concept, as the field holds it

For a working programmer, a language is a general host, Python, JavaScript, Java. A "domain language" is usually a library whose calls read like sentences, while the file around them may contain any code of the host. The estate's own study of the field, written in August 2026, names what happened to those designs. Internal languages died of openness, because a build file is declarative only until someone writes arbitrary code in it. Language workbenches died of the weight of their tools. And it names the languages that won: SQL, regular expressions, Make, HTML and CSS, the configuration languages. Its verdict is that they won because they are closed.

The model era added one practice: when an AI model writes, either check what it wrote, or constrain its output while it writes, with a grammar or a schema. The reference implementation of grammar-constrained sampling is an open project, and the record says so where it uses the same algorithm. And in the field's common language today, "programming in natural language" means one thing: prompting a model.

2. The first principle

A language is declared and closed, and whatever speaks it, a person or a model, is judged by it.

3. The Softanza form

Can a sentence run without an AI model guessing what it means? It can, when every word of it is in a dictionary the library owns:

Naturally("
    Make a string with 'hello niger' inside
    Spacify it and uppercase it
    @Box it while the box@ is rounded
    Display it on the screen
")
#--> ╭───────────────────────╮
#    │ H E L L O   N I G E R │
#    ╰───────────────────────╯

Four lines of English became a rounded box around spaced capitals.

The dictionary is data, keyed by meanings, not by English words. So can the same meaning be said in another language by adding a block of data, not code? Here is one instruction in English, in Hausa, in French and in Arabic. The Hausa sentence is the narration's own, and the French one comes from the library's guard with its data changed. I composed the Arabic one from the library's vocabulary. No native speaker has read the Hausa or the Arabic as far as the record shows:

? Naturally("Create a string with 'hello' and uppercase it").Result()
#--> HELLO
? NaturallyIn("hausa", "Yi rubutu dauke 'hello' Maida shi").Result()
#--> HELLO
? NaturallyIn("fr", "Crée une chaine avec 'hello' et mets la en majuscules").Result()
#--> HELLO
? NaturallyIn("ar", "أنشئ نصا بـ 'hello' ثم كبّره").Result()
#--> HELLO

Four languages, one meaning, and HELLO four times.

And a program says back what it understood, in its own language. A person reading Arabic can check the machine's reading of their sentence without reading a line of code.

o1 = NaturallyIn("ar", "أنشئ قائمة بـ [ 5, 3, 5 ] ثم أزل تكراراتها")
? @@( o1.Result() )
#--> [ 5, 3 ]
? o1.Understood()
#--> أنشئ قائمة بـ [ 5, 3, 5 ] -> أزل التكرارات

The program said back أنشئ قائمة بـ [ 5, 3, 5 ] -> أزل التكرارات: the list it was given, and the removal of duplicates.

Now the part the library does by rule: say what it did not understand. What does it do with a verb it does not know? Misspell one and run it:

o1 = Naturally("Create a string with 'softanza' Uppercse it")
? o1.Result()
#--> softanza
? @@( o1.Unresolved() )
#--> [ [ "Uppercse", "uppercase" ] ]
? o1.UnderstoodAll()
#--> 0

The misspelled verb is not guessed. Unresolved() answers [ [ "Uppercse", "uppercase" ] ], the word it met beside the word the library thinks you meant, and UnderstoodAll() answers 0: the program admits that it did not understand everything. That is the permissive mode: an unknown word is skipped and reported. An AI agent gets the strict mode, which refuses, and a world, a declared list of allowed operations, can limit its sentences to that list:

try
	NaturallyStrict("Create a string with 'x' Fooify it")
catch
	? cCatchError
done
#--> Strict natural mode: not understood: 'Fooify' (did you mean 'boxify'?)
try
	NaturallyStrictIn("en", "Create a list with [ 3, 1 ] Reverse it", [ "METHOD_REMOVEDUPLICATES" ])
catch
	? cCatchError
done
#--> Operation not permitted in this world: METHOD_REVERSE

Strict mode refuses 'Fooify' and still names the nearest word: did you mean 'boxify'?. In that world, a sentence that reverses a list is refused! The refusal names the operation: Operation not permitted in this world: METHOD_REVERSE.

The other direction of natural code in Softanza is the near-natural chain, where the person is the parser and the chain reads as a sentence. When it answers no, does it say why?

? IsQ().TheQ().LengthQ().OfQ("softanza").LessThanQ().TheQ().LengthQ().Of("Haro")
#--> 0
? Why()
#--> no: 8 is not less than 4

The chain answered 0, and Why() gave the reason: no: 8 is not less than 4. A verdict says why.

Now the law at its sharpest: an AI model. The library declares the shape of an answer as a schema. What happens to a schema that names a type the library does not have? It is judged when it is declared, before any model is called:

try
	StzOutputSchemaQ([ [ :field = "x", :type = :colour ] ])
catch
	? cCatchError
done
#--> stzOutputSchema: unknown field type 'colour' (use string|number|boolean|oneof|list|structure).

The refusal names the unknown type, 'colour', and lists the six it accepts: (use string|number|boolean|oneof|list|structure). The schema was refused before any model was called! A correct schema is a small closed language. The court judges any answer against it, whoever wrote the answer. And the schema emits its grammar, so that a model can be held to it while it writes:

StzOutputSchemaQ([
	[ :field = "name", :type = :string ],
	[ :field = "age",  :type = :number, :must = [ [ ">=", 0 ], [ "<=", 130 ] ] ],
	[ :field = "mood", :type = :oneof,  :choices = [ "positive", "negative" ] ]
]) {
	? Accepts("name: Hadiza" + nl + "age: 41" + nl + "mood: positive")
	#--> 1
	? Accepts("name: Hadiza" + nl + "age: 41" + nl + "mood: angry")
	#--> 0
	? Accepts("name: Hadiza" + nl + "age: 900000" + nl + "mood: positive")
	#--> 0
	? Accepts("name: Hadiza" + nl + "age: 62" + nl + "mood: positive")
	#--> 1
	? ToGBNF()
	#--> root ::= name-line age-line mood-line
	#    name-line ::= "name: " text "\n"
	#    age-line ::= "age: " number "\n"
	#    mood-line ::= "mood: " ("positive" | "negative") "\n"
	#    text ::= [^\n]+
	#    number ::= "-"? [0-9]+ ("." [0-9]+)?
	#    boolean ::= ("yes" | "no" | "true" | "false")
}

Look at the four verdicts. The first answer printed 1. The second, with mood: angry, and the third, with age: 900000, printed 0: the court refused both. The fourth printed 1 again. Hadiza is forty-one in the first answer and sixty-two in the fourth, and the court accepts both! A grammar kills malformed sentences, not false ones. The record says it in five words: structure kills malformedness, not falsehood. This book says the same: the truth of an answer is not for the grammar. The record says that truth needs reversibility, an auditor and a Principal, the person who rules. A grammar is the gate, not the judge of everything. The grammar also prints a boolean rule that no field of this schema uses.

A template is a contract too. A sentence with an unfilled hole is refused before it runs:

try
	NaturallyWith("Create a string with {#1} and {#2} it", [ "x" ])
catch
	? cCatchError
done
#--> Unfilled template hole! The narration still contains a {#n} slot with no value for it.

And patterns are small languages of their own, though not yet closed ones: chapter 15 shows the pattern classes accepting a word they do not know, without complaint. The shape of a list is declared, not written as a loop:

? Lx("[@N, @S]").Match([42, "hello"])
#--> 1
? Lx("[@N, @S]").Match(["hello", 42])
#--> 0
? Lx("[@N, [@N2], @N]").Match([1, [2, 3], 4])
#--> 1
? Lx("[@N, [@N2], @N]").Match([1, [2], 4])
#--> 0

Two shapes matched, two did not, and no loop was written.

The chapters of this part prove the law from five sides. Chapter 12 tells a language declared: the forge (the machinery that produces a language's parser, court, printer and grammar from its declaration alone), the closed grammar with no escape into the host, and the court born with the grammar. It tells too the grammar emitted so that a model can only speak valid sentences, and the parts a declaration yields. Chapter 13 tells the two directions of natural code, the machine as the parser and the person as the parser, in one discipline. Chapter 14 tells knowledge programming, one file that is a system. Chapter 15 tells the pattern languages, regex lifted to lists, numbers, tables, matrices, time and graphs. Chapter 16 tells the seven languages Softanza reaches through one governed door, and why a door is not a facet.

5. The court

multilingual_pack_narrated proves the languages as data: the packs, the programs in French and Arabic, a pack added at runtime, and the program paraphrasing back in its own language. semantic_resolver_narrated proves the unknown word with its suggestion, the strict mode, and the allow-list under which everything off the list is grammatically impossible. Its run does not yet reach its end at this commit. I ran it twice on 8 October 2026, for chapter 13, and each time it stopped with an error raised from a string-splitting function, before its last assertion. So the page counts its assertions and does not claim its verdict. literate_templates_narrated proves that a template is a contract. question_narrated proves that a yes-or-no verdict records its why. structuredoutput_narrated proves the court of structured output, including the lie it lets through. schema_grammar_narrated proves the grammar compiler, and constrained_decoding_narrated the sampler that holds a model to it.

Seven guards prove the law; the next section says where the field is ahead of it.

6. The field, and where it leads

The field leads in tools. The language workbenches remain ahead on the axes the estate's design deliberately gave up: projectional tooling (editors that understand a language as you type), IDE integration, macro-theoretic depth. The estate's study says it in its own words: that is a bet, and it is named as one.

The field built constrained decoding first. Softanza's sampler follows the reference implementation's algorithm and vendors nothing. Measured against one small model of a hundred and thirty-five million parameters, on ten prompts, the answers were valid at the first attempt two times in ten when checked afterwards. Held to the grammar, the model was valid ten times in ten. That is one small model and ten prompts, and nothing in the record measures a large one.

And the age cuts both ways. Generated code makes careless language-making cheap too. That is why the court is not an accessory of a declared language. It is the core. This is my view.

7. The limit

• builtthe natural layer's vocabulary as data in five languages, with its refusals; the court of structured output, its grammar compiler and its sampler; the pattern languages, which accept a word they do not know
• designedthe forge that produces a language's parser, court and grammar from its declaration alone; a grammar emitted for every declared language; the writing style as a declared grammar
• absenta natural layer closed all the way down: one form of list still reaches host code; pattern classes that refuse a word they do not know; the standard Hausa letter ɗ in the Hausa pack

What is built: the natural layer, its vocabulary as data in five languages, English, Hausa, French, Arabic and Turkish, and its refusals. Built too: the court of structured output with its grammar compiler and its sampler, and the pattern languages. These accept a word they do not know today; closing them is to come.

What is designed: the forge that would produce, from a language's declaration alone, its parser, its court, its printer (the part that writes a sentence back out) and its grammar for a model. The forge is built outside the library and designed for the library: a first sketch of it was built outside the library in October 2026. The library cannot run it yet. The vision's text says the forge has not yet forged (made a language's parts from its declaration). The sketch has since forged courts and grammars for several languages, judged by those languages' own fixtures, and the vision has not caught up. Chapter 12 tells it with its limits. A grammar for every declared language is designed and to come.

What is absent, and the law states it. The natural layer is not closed all the way down. One form, a list written inside brackets, is still handed to the host to evaluate. Does a host function inside the brackets run? Try one:

? @@( Naturally("Create a list with [ upper('x'), 1 ] and remove its duplicates").Result() )
#--> [ "X", 1 ]

The function upper is not a word of the natural dictionary, and the list came back as [ "X", 1 ]. It ran anyway! The record already knows this escape and has routed its repair. Until the repair lands, "the natural layer is a closed language" is true of its words and not of its lists, and this book will say so.

And the Hausa pack does not yet read the letter ɗ, which standard Hausa spelling uses. The pack stores it in an encoding that does not carry it yet. When I probed it on 8 October 2026 on the snapshot before this commit, a sentence written with the letter was not read, and the pack did not report it. The Hausa in this chapter is written without the hook, the way the pack reads it today. The record holds no reading of the pack's sentences by a Hausa speaker. The foreign-language sentences printed in this chapter come from the library's narration and guards, or are composed from its vocabulary. No native speaker has read them as far as the record shows.

These are the limits; the next section opens six doors on them.

8. Six doors

9. Exercise

Declare, with StzOutputSchemaQ, a record of three fields from a domain you know: a loan request, for instance, with an amount inside a band, a currency from a closed list, and a purpose in free text. Before you run anything, write three answers an AI model might give: one the court must accept, one it must refuse because of its shape, and one it will accept although it is false. Under each, write your prediction as a promise.

Run it. The third answer is the lesson of this chapter. Write down, in one sentence, who in your domain must judge it, since the grammar cannot.

I left this one in your hands. Section 7 says that a list written inside brackets is still handed to the host, and section 4 says why a language must refuse any form that reaches host code. Run the section 7 block with one change, a different host function inside the brackets:

? @@( Naturally("Create a list with [ lower('X'), 1 ] and remove its duplicates").Result() )

Look at what the library does with the function, and say in one sentence what a closed natural layer would have done instead. When you have, you will know why "the natural layer is a closed language" is true of its words and not yet of its lists.

Chapter 12 is A language, declared. Its principle: declaring a language is as easy as declaring a variable.

A language, declared

Run on 2026-10-15 12:59 UTC+01:00 inside the library at commit 93d7a39bd: 8 of 8 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I take one declaration of a restaurant's order and give it to three readers: a person, an AI model and the court. I let the same declaration produce a grammar, and I show where the grammar and the court agree and where they part. Then I leave the library for the forge. It is the machinery that turns a language's declaration alone into its court and its grammar, and I say what it has forged and what it has not. I decided that Haro is the language of languages, and I refused an open escape form. The principle is one rule of Haro: declaring a language is as easy as declaring a variable.

1. The concept, as the field holds it

Two families of tools let you declare a language in the field. The first is the language workbench and the parser generator: JetBrains MPS, Xtext, Spoofax, and Racket's #lang give you the means to define a language with its grammar, its editor and its checks. The estate's own field study of August 2026 says why they did not win. They depended on an ecosystem, and Racket's languages live and die inside Racket.

The second is the internal DSL: a library whose calls read like sentences, while the file can still hold any host code. The same study has the sentence I keep: closedness is the product, and an internal DSL that cannot refuse arbitrary host code is an API wearing a language's costume. Its control group is the closed languages that won: SQL, regex, Make, HTML and CSS, HCL, GraphQL, Markdown, CUE.

For the grammar a model must obey, the record names one tool: the grammar sampler of a well-known local inference library, which the library's machine follows for its element encoding and its algorithm. Nothing of it is vendored. It is general knowledge, not a study of the record, that model vendors offer structured-output modes that take a JSON schema, and that open libraries turn a schema or a regular expression into a mask on the model's tokens.

Chapter 11 told what a closed language is, and what was lost when the field left it open. I take that as read. This chapter says what is new: what produces a closed language.

2. The first principle

Declaring a language is as easy as declaring a variable.

It is the heading of one rule of Haro, ruled on 1 October 2026, and the kernel of the vision says the same: the era makes declaring a language as easy as declaring a variable. The other half of the chapter has its sentence, from the alphabet's totality doctrine, ratified on 27 September: malformedness dies at the sampler, falsehood dies at the court, and non-termination is unexpressible.

And the one I must carry beside every win, from the library's contract for structured output: structure kills malformedness, and not falsehood.

3. The Softanza form

Take a declaration of what a restaurant's order must look like. It has three fields: a dish from a closed menu, a quantity between 1 and 12, and an optional note. One text is read by three readers. A person reads a description. A model reads a clause for its prompt. And the court reads the same text and judges an answer. What does it answer to a dish called pizza and forty portions? Run it:

oO = StzOutputSchemaQ([
	[ :field = "dish",     :type = :oneof,  :choices = [ "margherita", "tiramisu" ] ],
	[ :field = "quantity", :type = :number, :must = [ [ ">=", 1 ], [ "<=", 12 ] ] ],
	[ :field = "note",     :type = :string, :optional = 1 ]
])
oO {
	? Describe()
	#--> schema 'output' -- 3 field(s)
	#      dish : oneof (margherita | tiramisu) [required]
	#      quantity : number [required], must be at least '1', must be at most '12'
	#      note : string [optional]
	? PromptClause()
	#--> Answer with ONLY this structure, one field per line, nothing before it and nothing after it:
	#
	#    dish: <one of: margherita | tiramisu>
	#    quantity: <number>
	#    note: <text>
	aV = Verify([ :dish = "pizza", :quantity = 40 ])
	? aV[:ok]
	#--> 0
	? aV[:findings][1][:message]
	#--> field 'dish' is a closed enumeration (margherita | tiramisu) and the model answered 'pizza'.
	? aV[:findings][2][:message]
	#--> field 'quantity' must be at most '12', and the model answered '40'.
}

The court answers in the declaration's words: field 'dish' is a closed enumeration (margherita | tiramisu) and the model answered 'pizza'. Now the same declaration produces a grammar. The court and the grammar are born of one text, and they agree on the shape. They part ways on a value. Forty portions has the right shape: which of the two lets it through, and does the library say what the grammar dropped? Run it:

cG = oO.ToGBNF()
cGood  = "dish: margherita" + nl + "quantity: 2" + nl + "note: no basil" + nl
cBand  = "dish: margherita" + nl + "quantity: 40" + nl + "note: no basil" + nl
cShape = "dish: margherita" + nl + "quantity: many" + nl + "note: no basil" + nl
? StzGrammarAccepts(cG, cGood)
#--> 1
? oO.Accepts(cGood)
#--> 1
? StzGrammarAccepts(cG, cBand)
#--> 1
? oO.Accepts(cBand)
#--> 0
? StzGrammarAccepts(cG, cShape)
#--> 0
? oO.Accepts(cShape)
#--> 0
? len(StzFind("lessequal", oO.UnenforcedByGrammar())) > 0
#--> 1

The second pair is the point of the chapter: the grammar answers 1 and the court answers 0! I do not print the list of what the grammar dropped: its text carries, in one place, the court's former name, and that name belongs to the history in Appendix H. I test that the list names the limit of the range.

An AI model is not asked to be careful. The sampler asks the grammar at every candidate token whether it could continue. So a word that is not on the menu is not refused after it is said. Can it begin at all?

? StzGrammarCouldContinue(cG, "dish: t")
#--> 1
? StzGrammarCouldContinue(cG, "dish: p")
#--> 0
? StzGrammarCouldContinue(cG, "dish: margherita" + nl + "quantity: 2")
#--> 1
? StzGrammarCouldContinue(cG, "dish: margherita" + nl + "quantity: <")
#--> 0

It cannot: dish: p answers 0. The last line is a failure the measurement of section 5 found in a small model: the placeholder <number> echoed where a number belongs. And a token is not a byte. A piece may be valid as a prefix and invalid as a completion, and the machine is fed the whole piece. What does it answer to yesterday, which begins like yes?

cY = 'root ::= "yes" "\n"'
? StzGrammarCouldContinue(cY, "y")
#--> 1
? StzGrammarCouldContinue(cY, "ye")
#--> 1
? StzGrammarCouldContinue(cY, "yesterday")
#--> 0

The pieces y and ye answer 1, and yesterday answers 0!

What the machine will not hold, it refuses by name. A closed language refuses what it cannot carry, and never approximates. A left-recursive rule is refused by a code, and so is a rule referred to and never defined. A nested structure is refused by the grammar. Does the court still read it?

? left(StzGrammarRefusal('root ::= tail' + nl + 'tail ::= tail "x" | "x"'), 7)
#--> GBNF-M7
? left(StzGrammarRefusal('root ::= greeting'), 7)
#--> GBNF-M4
? StzGrammarRefusal(cG) = ""
#--> 1
StzOutputSchemaQ([
	[ :field = "title",  :type = :string ],
	[ :field = "author", :type = :structure, :fields = [ [ :field = "name", :type = :string ] ] ]
]) {
	? IsExpressibleAsGrammar()
	#--> 0
	try
		ToGBNF()
	catch
		? len(StzFind("GBNF-F5", cCatchError)) > 0
	done
	#--> 1
	? ParseOutput('{ "title":"T", "author":{"name":"Ada"} }')[:ok]
	#--> 1
}

The text of the nested-structure refusal carries the court's former name too, so I print only the codes. The last line is the point: the court reads what the grammar refuses to write.

The declaration language is itself closed. A typo in the law is refused when the law is declared. The library's contract says why. A key such as :requird = 0 would leave a field required without a word, and that is the class of typo a court must not tolerate in its own law. What does the court answer to one?

try
	StzOutputSchemaQ([ [ :field = "x", :type = :string, :requird = 0 ] ])
catch
	? cCatchError
done
#--> stzOutputSchema: unknown key ':requird' in field #1 (use :field, :name, :type, :required, :optional, :choices, :oneof, :of, :fields, :must, :note, :description).

The typo was refused at once, and the message lists the keys that are allowed!

And a host function is not a word of the closed language of conditions. There are two ways to say a condition, the closed language and the door of a function. A square root is a word of the engine's expression language, and a sine is not. What does the textual form answer to the sine, and what does the function form, which runs host code?

StzListQ([ 4, 7, 10, 3, 8 ]) {
	? @@( FindW('{ sqrt(@item) < 3 }') )
	#--> [ 1, 2, 4, 5 ]
	? @@( FindW('{ sin(@item) < 2 }') )
	#--> [ ]
	? @@( FindWF( func x { return sin(x) < 2 } ) )
	#--> [ 1, 2, 3, 4, 5 ]
}

What I saw, and the narration does not say: the refusal is silent and whole. The textual form printed [ ] and the function form printed [ 1, 2, 3, 4, 5 ]: nothing from the one, everything from the other. A condition with the true left branch and a sine on the right printed [ ]. A condition that calls a function of mine never called it. A syntax error also printed [ ]. The language is closed, and it refuses without a word. Chapter 11's natural layer says why it refuses, and this one does not.

The forge, outside the library

A language declared once should give its court, its mouth, its voice and its readers. That is the forge, and it is where the study of this book meets its own limit: the forge is not in the library.

I will say what the record holds, and what I observed on 8 October 2026 on the older runtime, the oracle. The record is a charter and a spike in another repository, in pure core code that runs on the oracle. The forge reads a declaration and writes two files, a court program and a grammar. The spike's rungs, between 1 and 4 October 2026, forged courts and grammars for the machine language of the estate and for a fleet language declared over it. They did the same for the expression language and for four more letters of the alphabet, the vision's family of declared languages, each known by a letter. Each was judged against the pre-existing language's own cases. Those cases were unadapted for the expression language (W) and for Z, re-expressed for F and A, and, for Q, the older language's own answers, captured. In order: 117 of 120 for the machine language, the three left being the fleet file's kinds. Then 32 of 32 for the fleet language, 29 of 29 for W, 16 of 16 for Z, 25 of 25 for Q, 26 of 26 for F and 35 of 35 for A. This is chapter 3's method, declare then govern, applied to the forge itself.

I ran the forge on a small language I wrote for this book, a table's order in the words of the dining room. It is an example, written for the book and run once, outside the library:

DEFINE LANGUAGE order AS ( VERSION "0.2", GRAMMAR "0.2", COURT "none", EXTENSION ".order" )
  RATIONALE "A table's order, in the words of the dining room"
DEFINE MENU dishes AS ( WORDS [margherita, tiramisu, chianti],
  MESSAGE "the kitchen cooks margherita, tiramisu or chianti" ) RATIONALE "The kitchen's closed menu"
DEFINE RANGE portions AS ( MIN 1, MAX 12,
  MESSAGE "{value} portions is not an order: one to twelve" ) RATIONALE "A table orders between one and twelve"
DEFINE DECLARATION line AS ( VERB "ORDER", SEATS [dish: dishes, quantity: portions, note: text?] )
  RATIONALE "One line of an order: what, how many, and a word for the kitchen"
DEFINE REFUSAL unknown_verb AS ( MESSAGE "The dining room speaks only of orders." )
  RATIONALE "The closure speaks when an alien verb arrives"

The forge printed that it had forged one kind and one refusal, in a fraction of a second of wall time, and wrote a court of about 2.6 kilobytes. What did that court answer to a dish off the menu, to forty portions and to an alien verb? It refused all three, in the declaration's own words:

DISH pizza          ->  order (line 2): the kitchen cooks margherita, tiramisu or chianti, not 'pizza'
QUANTITY 40         ->  order (line 3): 40 portions is not an order: one to twelve
DROP TABLE orders   ->  order (line 1): Unknown verb 'DROP': The dining room speaks only of orders.

The refusals are the declaration's own words, written beside the grammar. Even DROP TABLE orders was refused in the dining room's words! This is the whole of the evidence for the order language: it ran once, outside the library, and it is not a declaration of the record.

Three more observations, each a limit.

The meta-court refuses the escape. The declaration of the language of declarations lists the operators and operands it may use. A declaration that listed eval among its operators, in a fixture pinned on 29 August 2026, was refused: eval is not in the closed operator menu, an escape hatch is unexpressible, not forbidden. A host call among the operands was refused in the same way.

The forge's grammar holds shape only. A menu seat comes out as a general identifier, so the forged grammar lets pizza through. The library's own schema compiler, in the blocks above, closes the same menu into an alternation. On the estate's machine language, the forged grammar accepts a dangling reference that the court refuses. The record names a difference between mouth and court, the part that a context-free grammar cannot say: duplicate names, dangling references. I found no record that states the menu gap as a gap.

The vision has not caught up. The vision's text, dated between 27 September and 5 October 2026, says the forge has not forged. The principles file, dated 1 October 2026, says that the forge does not exist. The same repository built the spike the same day and forged for several languages. So the true sentence has two sides. The forge has forged courts and grammars for several languages, outside the library, and it has not forged the full list the principle promises. And the vision's text has not been updated. In the book's stage words, the forge is built outside the library and designed for the library, and chapter 11's limit says the same.

The parts of a declared language

The charter lists what the forge produces from a declaration, its parts, and I give each a stage word:

The word facet has two meanings in this book, and I define the one of this part here. A facet is a second syntax of Haro, for a programmer of another language: another spelling of the one grammar, and never a runtime. It is the last row of the table, and chapter 16 tells it. The other sense is a tab of the environment's ribbon, one phase of a life, which is chapter 26's.

5. The court

structuredoutput_narrated proves that a declaration is judged when declared, with an unknown type, an unknown key and an empty menu refused. It proves that two wire shapes are read and nothing is guessed, that there is no partial credit, that nesting works, and that a retry fits in one budget. In its tenth scene, it proves that a lie is let through on purpose. schema_grammar_narrated proves that the declaration compiles to a grammar, and that a closed enumeration becomes a closed alternation. It proves that optional and list arity are handled, that the unenforced constraints are listed by field and operator, and that a nested structure is refused with a named code. constrained_decoding_narrated proves that the machine walks a grammar byte by byte, that a prefix is not a whole, and that yesterday is refused. It proves that the placeholder the model wrote cannot be reached, that refusals are named, that structure is not falsehood, and that a grammar on a streaming session is refused. Its two scenes that need a generative model say so. 483_w_and_wf_forms_in_conditional_code proves that the two forms of a condition give the same positions. It does not assert the closed language's refusal, and no guard does.

No guard in the library tests a forge, since there is none. The forge's guard is outside: the spike passes twenty-three stages in 367.5 seconds on 4 October 2026, by its own file. I did not run it. And the meta-court's own first run was twenty-eight of twenty-eight on 29 August 2026. The book's guard reader resolves only guards in the library's test tree, so these cannot be named in the front matter.

The first attempt is valid in two cases of ten when checked afterwards, and in ten of ten when constrained. That figure is a number in a comment of these guards. It cannot be re-taken here: the live scenes need a generative model file, and the snapshot holds only a checksum file in its folder for models. Chapter 11 carries the figure, and I point to it.

6. The field, and where it leads

The workbenches lead on tooling. The field study says it itself: they remain superior on the axes the design deliberately abandons, projectional tooling, editor integration and depth of macros. And the bet that those axes are the wrong ones is named as a bet.

Generated code makes undisciplined language-making cheap too, and that is why the court is the core and not an accessory.

Constrained decoding: the field built it first, and the reference implementation is another library's. What the record adds is the pairing: a grammar and a court from one declaration, and the list of what the grammar dropped.

A grammar over-approximates a court. Duplicate names, dangling references and the coherence of a menu are not context-free. I observed it both ways above: a band the grammar cannot carry, and a reference it cannot carry.

The code a forge emits must be read by someone. The family style that every declared language inherits has a success test, that learning the second language should take an evening, because it is the first language with different verbs. It is a design requirement and not a measurement. No learner has been timed in the record I read.

The limit comes next, at the edge of a second closed language.

7. The limit

• builtin the library: a declaration judged when it is declared; a court and a grammar from the one declaration, with the list of what the grammar dropped; a grammar machine that walks bytes and refuses by name; a description for a person and a prompt for an AI model from the same text. Outside the library: a forge that turns a declaration into a court and a grammar, run on the estate's own languages
• designedthe forge inside the library; its full list of products from one declaration (printer, knowledge graph, natural door, narration, runtime, one static binary); the projections of a language to an application
• absentthe forge's grammar for a menu word; a guard that asserts the refusal of a host function in a condition; the figure two of ten against ten of ten, which needs a model file the snapshot does not hold

The library has two closed formula languages, and they behave differently at the edge. A reader who takes the closed condition language of chapter 11 and of the condition above to cover every formula will be wrong at the table. The calculated column of a table falls back, by its own header, to the classic evaluation path when the engine cannot compile a formula. Does the word sin that the condition refused run here?

o1 = new stzTableAggregator([
	[ :A, [ 0, 1, 4 ] ],
	[ :B, [ 2, 4, 20 ] ]
])
o1.AddCalculatedCol(:SINE, 'sin(@(:A))')
? @@( o1.Col(:SINE) )
#--> [ 0, 0.84, -0.76 ]

The sine the condition refused, the table computed, and it printed [ 0, 0.84, -0.76 ]! I also saw, and do not show, a second thing. On another probe table, with A as 1, 3 and 10 and B as 2, 4 and 20, I wrote a formula @(:A) + HostBonus(@(:B)). The function of mine inside it multiplies by a thousand. The formula printed [ 2001, 4003, 20010 ]: a user-defined host function ran from inside a formula string. And a formula that names a function that does not exist raised the host's own error. So the second closed language is open at its edge. No guard asserts either behaviour.

What is built: in the library, a declaration judged when declared; a court and a grammar from it; the list of what the grammar dropped. A grammar machine that says it is constrained; a prompt and a description from the same text. The build counts 151 assertions in three narrated guards. Two closed little languages of conditions, with limits. The natural layer's tongues as data.

What is built, but outside the library: a forge from a declaration to a court and a grammar, in the Haro charter's repository.

What is designed: the forge producing from a declaration alone the parser, court, printer, grammar, knowledge graph, query grammar, natural door, narration, runtime and one static binary. By my reading of the charter, the spike has shown the court, the grammar, a runtime that walks the declaration, a query grammar, a narration and the court of the natural letter. I did not find shown a printer for declared sentences, a knowledge graph forged from a declaration, or the one static binary per language. The library having a forge: nothing in it declares or forges a language. A grammar for every declared language shipping in the library: promised in the kernel, not shipped. And the projections: the world rendered to an application, a server, a page, a device.

What is absent: the forge's grammar for a menu word, which I saw above holds shape only, and the figure of two of ten against ten of ten, re-taken. And any record that the forge runs on the Haro runtime. At the time of the vision's writing the language did not exist; the charter's runs are on the older runtime and on the oracle.

The six doors follow, from the programmer to the agent.

8. Six doors

9. Exercise

Write, by hand, a grammar for one line of a lunch order: dish: then one of two dishes of your choice, then a newline. Before you run anything, write your predictions as promises:

cG = 'root ::= ...'     # your grammar here
? StzGrammarAccepts(cG, "dish: <your first dish>" + nl)
#--> ?
? StzGrammarAccepts(cG, "dish: <a dish not on your menu>" + nl)
#--> ?
? StzGrammarCouldContinue(cG, "dish: <the first letters of your first dish>")
#--> ?
? StzGrammarAccepts(cG, "dish: <the first letters of your first dish>")
#--> ?
? StzGrammarRefusal(cG) = ""
#--> ?

Then add a number to the line, quantity: and digits, and write a sixth prediction: does your grammar accept quantity: 4000? Run it. The lesson is the third, the fourth and the sixth. The machine already knows that a prefix could continue and is not yet a sentence, and it cannot know that the number is too large. Write down, in one sentence, who in your restaurant must refuse forty portions, since the grammar cannot.

I left this one in your hands. Section 3 ends its run of conditions on a refusal without a word, and section 4 says why computing stays off the declaring surface. Take the two lines that put the same question to the list in the two forms, and change one thing: write another number in place of the 2, the same in both lines. I print nothing under them.

o = new stzList([ 4, 7, 10, 3, 8 ])
? @@( o.FindW('{ sin(@item) < 2 }') )
? @@( o.FindWF( func x { return sin(x) < 2 } ) )

Run them for several numbers. Look for a number at which the two forms print the same thing, and say whether the printout alone tells you which of the two refused and which answered. When you have, you will know what it costs that a closed language refuses without a word.

The next chapter turns to the natural sentence, in two directions and under one discipline. A sentence runs because every word of it is in a dictionary the library owns, and what the library does not know, it refuses, with the reason.

Natural, and executable: two directions, one discipline

Run on 2026-10-15 12:59 UTC+01:00 inside the library at commit 93d7a39bd: 17 of 17 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I run the two directions of natural language in the library: the chain, where you are the parser, and the sentence, where the library is. I print the refusals on both sides, five language packs as data and a sixth added at runtime, and the count of what each pack can say. I say what I refused, the markers on reference and the ungrammatical chain among them, and where the dictionary's own court fails at this commit. The principle is one sentence. A sentence runs because every word of it is in a dictionary the library owns, and what the library does not know, it refuses, with the reason.

1. The concept, as the field holds it

In the field's common language, "programming in natural language" means one thing: asking an AI model for code, or asking it to do the task, in a prompt. The tools are chat assistants and code completers, in wide use since about 2021. What the sentence runs on is the model's guess. The same sentence may give different code on different days, the model needs a network or a local runtime, and a person reads the result to know what was understood. Chapter 11 said it, and I point back.

Older practices exist, and the record names them. Inform 7, a language whose programs are English sentences, compiled whole, with a world model and a way to say it across sentences. AppleScript, English-like and hard to write, because its naturalness was on the surface and not in a semantic model. Controlled natural languages, whose strongest device, the library's own comment says, is showing what can be said next. A session's reading of 30 August 2026 is that Inform 7 is a whole-text compiler with referential context, and not a command dispatcher. The dates are general knowledge, not a study of the record.

None of them is what the record claims. The claim is the opposite of prompting: a sentence executes because every word of it is in a closed lexicon, defined as data, mapped to a verb the library documents. Anything else is refused with the reason. And it has two directions, which the library's design review tabulates. In the first, the machine is the parser. In the second, the human is.

2. The first principle

A sentence runs because every word of it is in a dictionary the library owns. What the library does not know, it refuses, with the reason.

My study of the record, and the lede of the site's page of 8 October 2026, say it. For the second direction, the design review's thesis: in near-natural language, the human is the parser. And the older motto, which chapter 5 carries: what you think is what you write.

3. The Softanza form

I start with the second direction, because it is the older.

The human is the parser

A near-natural chain is a sentence in which every link is a real call. The sentence is "the word haro is a lowercase Latin word with a length of 4 letters and only 2 vowels". When it is false, what does the chain say? Run it:

? TheWordQ("haro").IsAQ([ :Lowercase, :Latin, :Word ]).WithQ().ALengthQ().OfQ(4).UnitQ(:Letters).AndQ().OnlyQ(2).VowelNB()
#--> TRUE
? TheWordQ("haro").IsAQ([ :Lowercase, :Latin, :Word ]).WithQ().ALengthQ().OfQ(4).UnitQ(:Letters).AndQ().OnlyQ(1).VowelNB()
#--> FALSE
? Why()
#--> no: expected exactly 1, found 2

The chain answers no: expected exactly 1, found 2. Degree words are devices, and the reason is kept. The block reads it with the console's Why(); the chain also keeps its own, WhyCheckFailed(), which I do not call here:

? Q("AnnIE").AtLeast(2).VowelNB()
#--> TRUE
? Q("AnnIE").AtMost(2).VowelNB()
#--> FALSE
? Why()
#--> no: expected atmost 2, found 3

The chain refuses what its subject cannot do. It speaks the same lexicon as the machine's direction: a French word works inside a chain. And a misspelled word is refused with the nearest word. This is "one lexicon, two directions" in three lines:

try
	Q(5).VowelNB()
catch
	? cCatchError
done
#--> NNL: a stznumber cannot count 'numberofvowels' -- and neither can the chain subject.
? Q("haro").IsAQ(:String).IfSoQ("majuscule").Content()
#--> HARO
try
	Q("haro").IsAQ(:String).IfSo("uppercse")
catch
	? cCatchError
done
#--> NNL: this stzstring does not understand 'uppercse'. Did you mean 'uppercase'?

A chain branches on its own truth, and an ordinal is a word:

? Q("haro").IsAQ(:String).IfSoQ(:Uppercase).OtherwiseQ(:Reverse).Content()
#--> HARO
? Q("hello").IsAQ(:Number).IfSoQ(:Reverse).OtherwiseQ(:Uppercase).Content()
#--> HELLO
? Q("hello brave world").TheNth(2, :Words)
#--> brave

Questions work the same way. A force word, the question's first word (What, HowMany and Is in the block below), opens a frame, one word and one method. A tag question ends in "or not". What does the session keep when one answers yes and the other no? It keeps every answer and folds them, like a narration:

? @@( WhatQ().TheQ().VowelsQ().OfQ("AnnIE").Is() )
#--> [ "A", "I", "E" ]
? HowManyQ().WordsQ().Of("hello brave world")
#--> 3
ClearAnswers()
? IsQ().TheQ().LengthQ().OfQ("Haro").TheSameAsQ().TheQ().LengthQ().OfQ("Ruby").OrNot()
#--> 1
? Why()
#--> yes: 4 is the same as 4
? IsQ().TheQ().LengthQ().OfQ("Haro").TheSameAsQ().TheQ().LengthQ().OfQ("softanza").OrNot()
#--> 0
? Why()
#--> no: 4 is not the same as 8
? @@( AnswersSoFar() )
#--> [ 1, 0 ]
? AllYesSoFar()
#--> FALSE
? AnyYesSoFar()
#--> TRUE

The session kept [ 1, 0 ] and folded it: all yes is FALSE, any yes is TRUE.

The machine is the parser

Now the other direction. The sentence is a string, and the library reads it. The same verdict can come from a narration of questions and from a chain of truth. How sure is the chain of truth, and why? Run it:

oT = Naturally("Create a string with 'haro' Is it lowercase ? Does it contain 'r' ?")
? @@( oT.Answers() )
#--> [ 1, 1 ]
? oT.AllYes()
#--> TRUE
? oT.Understood()
#--> create a string with haro -> ask: is lowercase -> ask: contains
TruthOf("haro") {
	IsA(:Lowercase)
	AndIsA(:Latin)
	AndContaining("r")
	? Holds()
	#--> TRUE
}
? Why()
#--> yes: "haro" is lowercase and is latin and containing "r"
? Certainty()
#--> 1
? Evidentially()
#--> certainly

It answers certainly, and says why: yes: "haro" is lowercase and is latin and containing "r".

The whole paragraph is compiled into code before anything runs, and the code is readable. It is the library's own account of why the layer exists:

o1 = Naturally("Create a string with 'test.data' Replace '.' with '_' Uppercase it")
? o1.Result()
#--> TEST_DATA
? o1.Code()
#--> oStr = StzStringQ("test.data")
#    oStr.Replace(".", "_")
#    oStr.Uppercase()
#    @result = oStr.Content()

Does the same meaning in Hausa land on the same code? Hausa is written here without the hooked letter, as the pack reads it today, for a reason that chapter 11 gives. Run it, and each program says back what it understood, in its own words:

oE = Naturally("Make a string with 'hello niger' inside Spacify it and uppercase it")
oH = NaturallyIn("hausa", "Yi rubutu da dauke 'hello niger' a ciki Raba shi kuma maida shi")
? oE.Code() = oH.Code()
#--> TRUE
? oH.Understood()
#--> yi rubutu dauke hello niger -> raba -> maida
? oE.Understood()
#--> create a string with hello niger -> spacify -> uppercase

The comparison answers TRUE: one code for two languages!

The sentence-dictionary is not the only vocabulary. Where does a word go that it does not hold? It is looked up in the library's own vocabulary, here the documentation tags of the uppercase verb. A value in quotes is data, and never a verb. An unknown word in a value position stays a literal:

? Naturally("Create a string with 'softanza' Capitals it").Result()
#--> SOFTANZA
? Naturally("Create a string with 'capitals' Uppercase it").Result()
#--> CAPITALS
? Naturally("Create a string with 'a-sep-b' Replace sep with '_'").Result()
#--> a-_-b

The third line is also a limit: it printed a-_-b. The word sep was in no dictionary, and was used as the text to replace. A word it does not know is a literal.

Five languages as data. The dictionary is keyed by meaning, and each language's word lands on one id. Do a French, an Arabic and a Turkish word land on the same one? Run it:

? StzResolveSemanticInLang("fr", "doublons")
#--> METHOD_REMOVEDUPLICATES
? StzResolveSemanticInLang("ar", "تكرارات")
#--> METHOD_REMOVEDUPLICATES
? StzResolveSemanticInLang("tr", "tekrarları")
#--> METHOD_REMOVEDUPLICATES
? StzResolveSemantic("removeduplicates")
#--> METHOD_REMOVEDUPLICATES

The languages follow their own grammar, and they are not word-for-word translations. Turkish puts the verb last, with the parameters before it. Arabic, with its vowel marks and a doubled letter, is stripped by the pack; the suffix on the verb is the masculine "it" for a text. French elides:

? NaturallyIn("tr", "'a.b' ile bir metin oluştur '.' yerine '_' koy").Result()
#--> a_b
? NaturallyIn("tr", "'haro' ile bir metin oluştur ve tersine çevir").Result()
#--> orah
? NaturallyIn("ar", "أنشئ نصا بـ 'haro' ثم اقلبه").Result()
#--> orah
? NaturallyIn("ar", "أنشئ نصًا بـ 'haro' ثمّ اقلِبْه").Result()
#--> orah
? NaturallyIn("ar", "أنشئ نصا بـ 'haro' ثم اقلبه").Understood()
#--> أنشئ سلسلة بـ haro -> اعكس
? NaturallyIn("fr", "Crée une chaine avec 'haro' et mets la à l'envers").Result()
#--> orah

Three languages, three grammars, one answer: orah. Arabic says back what it understood, in its own words: أنشئ سلسلة بـ haro -> اعكس.

No native reader has read these sentences. They are modelled on the guard's, with 'haro' in place of the guard's own test word, and the Turkish string reversal is the book's variant of the guard's list reversal. I do not know that a speaker has read them. The record holds no reading by a speaker of the Arabic, Turkish, French or Swahili sentences, as it holds none for the Hausa of chapter 11. They are printed as sentences modelled on the library's own, unread.

Can a language be a block of data? Here is Swahili, added at runtime, by the guard's own words:

StzAddNaturalLanguage([
	:code = "sw",
	:name = "swahili",
	:script = "latin",
	:ignored_words = [ "na", "ya", "kwa", "hii" ],
	:semantic_mappings = [
		[:natural = "unda",   :semantic = "CREATE_OBJECT"],
		[:natural = "orodha", :semantic = "OBJECT_LIST"],
		[:natural = "na",     :semantic = "VALUE_INDICATOR"],
		[:natural = "panga",  :semantic = "METHOD_SORT"]
	],
	:phrases = [
		[:semantic = "METHOD_REMOVEDUPLICATES", :words = "ondoa nakala, futa nakala"]
	]
])
? StzHasLanguagePack("sw")
#--> TRUE
osw = NaturallyIn("sw", "Unda orodha na [ 9, 4, 9 ] ondoa nakala")
? @@( osw.Result() )
#--> [ 9, 4 ]
? osw.Understood()
#--> unda orodha na [ 9, 4, 9 ] -> ondoa nakala

Four mappings, one phrase, and the sixth language answers [ 9, 4 ]!

Natural code is data too. A document's fenced blocks run, and a template is filled:

cDoc = "This tutorial explains deduplication." + nl +
	"#<" + nl +
	"Create a list with [ 3, 1, 3 ] and remove its duplicates" + nl +
	"#>" + nl +
	"The end."
? len( StzNaturalBlocks(cDoc) )
#--> 1
? @@( NaturallyFromDoc(cDoc)[1].Result() )
#--> [ 3, 1 ]
cT = "Create a list with {#1} and remove its duplicates"
? @@( NaturallyWith(cT, [ [ 5, 3, 5 ] ]).Result() )
#--> [ 5, 3 ]
? @@( NaturallyWith(cT, [ [ 9, 9, 4 ] ]).Result() )
#--> [ 9, 4 ]

What the packs can say. How much does each pack say? The library has a function for it, and no guard prints its figures. I count against twenty-five reference meanings, which are the structural ones and every method and modifier any shipped pack names. They are not the thousands of verbs the library grew:

for cLang in [ "en", "ha", "fr", "ar", "tr" ]
	aC = StzPackCoverage(cLang)
	? cLang + " " + aC[:covered] + " of " + aC[:total]
next
#--> en 23 of 25
#    ha 9 of 25
#    fr 25 of 25
#    ar 16 of 25
#    tr 10 of 25
? StzHasNeuralModel()
#--> FALSE

The Hausa pack speaks nine of twenty-five meanings: ha 9 of 25! And no model is loaded. The layer has an optional rescue by embedding, when nothing lexical was found and a model is loaded. At this commit none is, and none is needed. So I say "no model is loaded", and not "never touches a model".

From the 2020 diagram to the three eras

The library names three eras, in a design document of 10 July 2026. The first is near-natural language, the first paradigm. The second is natural programming: lower the language toward code, with free text, and one object per block. The third, of 2026, is one lexicon shared by execution and documentation, multilingual packs with morphology, and Understood(). I call the third the shared lexicon. The vision's own heading for it uses a word this book does not use.

Here are the dates, as the record gives them. My strategic diagram carries the years 2020 to 2025, shared on 13 September 2026; its Narrations band reads "executable natural language". The deck of 2022 was exported on 20 September 2022, and its slide 2 says to express thinking in an executable natural language. The library's repository begins on 12 March 2022, and its history cannot date 2020 or 2021. The near-natural files and the engine at its present path were first committed between 16 and 19 September 2025. On 30 October 2025 languages became configuration. On 2 November 2025 string input replaced brace capture. On 9 July 2026 the lexicon was unified from the documentation tags. On 10 July 2026 the two design documents were written, and the audit of fifteen canonical examples found that four ran, and two of those answered correctly. The site's flagship page is of 8 October 2026. The git dates come from the library's own repository, which the snapshot lacks; I checked them there on 9 October 2026, and the commits cited are ancestors of the pin.

So the earliest slide the record dates is the founding slide of the 2022 deck, exported on 20 September 2022. The year 2020 is the first year of my strategic diagram, which was shared on 13 September 2026; the record holds no slide of 2020.

Now the decision, and what I refused.

5. The court

nnl_narrated proves the flagship sentence, the generated surface of nouns, the degree words, the conditional mood, the ordinal reference, the refusal that accounts for itself, the grammaticality doctrine, context on the chain, and the discourse tense. multilingual_pack_narrated proves packs as data, programs in French, Arabic and Turkish that run, verified affix stripping, a language added at runtime, and Understood() back in the program's language. question_narrated proves the question frames and that a frame with no aspect is refused. literate_templates_narrated, the documents and templates. truthchain_narrated and interrogative_narrated, the folded verdicts.

semantic_resolver_narrated is the guard that ought to protect the dictionary, and at this commit it fails. I ran it twice on 8 October 2026 and each time it stopped with an error: three assertions failed, and the run ended after the twenty-ninth. In that run the word "caps", which the guard asserts, resolved to a method for bounds, and "mirrored" resolved to nothing. The reason is the design's own: the vocabulary is read from the library's documentation tags, plus seventeen hand-written operations grown by reflection to about three thousand. So a documentation edit changes what a word means. The library refuses honestly in the second case: in that run Unresolved() named the word and UnderstoodAll() printed 0. The court of the dictionary has failed on the dictionary, and chapter 11, chapter 22 and chapter 2 name this guard.

I ran the other guards named above once each on 8 October 2026, and in that run they passed all their assertions; the book's own data holds only their counts. The assertion calls written in the seven guards named above sum to 269.

6. The field, and where it leads

The field leads in breadth of phrasing. An AI model accepts any phrasing in any language, and the dictionary accepts what the packs name. Measured above: the Hausa pack covers nine of twenty-five meanings, Turkish ten, Arabic sixteen, English twenty-three (the two it lacks, English reaches through the grown vocabulary), French twenty-five. And the sentence layer acts on three classes only: strings, lists and numbers. A customer's domain objects are not among them; the domain goes through the knowledge graph.

The field leads in whole-program semantics. Inform 7 compiles a whole world. Here a program is a sequence of operations on a live object.

The field leads in an editor. In my run, the suggestion function answered nine continuations for a half-written sentence, and the code credits the controlled-language field for the idea. There is no editor here that shows them as you type.

And there is a loss on the library's own side. Understood() prints verbs and not their arguments: the block of section 3 prints contains and not the 'r' it asked about. In my run, Replace printed as replace, and Add 3 to it printed as add while the result was 8. A reader who checks the machine's reading sees no 3. This qualifies chapter 11's claim that a person can check what the machine understood.

Where the win is, with the loss beside it: the same sentence gives the same answer, with a reason, in the user's language, and designed to run offline, which no guard measures. The loss is that the user's language must be in a pack, and a word outside is a literal or a refusal. The record says the winning case is regulated or sovereign work: an instruction that executes locally and can be audited to the word.

The next section says where the chapter stops.

7. The limit

• builtboth directions: chains where the human is the parser, and sentences where the machine is; five language packs as data and a sixth added at runtime; refusals with reasons on both sides; question frames; a thin truth chain; natural code as data in documents and templates
• designeda grammar that holds an AI model to the lexicon; a guard that no socket opens during a natural run; the plan emitted as a chain; the article examples pinned as fixtures
• absentany machine that judges a chain's grammar; Ajami, Zarma and Fulfulde; a natural layer closed all the way down; a dictionary protected from the drift of the documentation it is read from; the old articles' promises, several of which do not run

An ungrammatical chain runs. The second chain below reads "which a length of 4", which is not English. Does anything judge it? Run both:

? TheWordQ("haro").IsAQ(:Word).WhichQ().HasQ().ALengthQ().Of(4)
#--> TRUE
? TheWordQ("haro").IsAQ(:Word).WhichQ().ALengthQ().Of(4)
#--> TRUE

Both answer TRUE: nothing judged the second! The doctrine is that reviewing a chain is reading it aloud as English. It is the human's job.

Does a chain's descriptor reach host code? Yes. IsAXT builds a string and evaluates it, so a function defined by the program and named in the string printed host code ran. This is the residue that the study of the record and chapter 6 name:

? Q("haro").IsAXT([ "String('x') and HostRan() and @isString" ])
#--> host code ran
#    TRUE

func HostRan()
	? "host code ran"
	return 1

And a word of the old era is reported, and never guessed. Permissive mode still runs the rest, and strict mode refuses. The suggestion offered, addn, is a poor one:

o = Naturally("Create a string with 'softanza' Spacify it and_ Uppercase it")
? o.Result()
#--> S O F T A N Z A
? o.UnderstoodAll()
#--> FALSE
? @@( o.Unresolved() )
#--> [ [ "and_", "addn" ] ]
try
	NaturallyStrict("Create a string with 'softanza' Spacify it and_ Uppercase it")
catch
	? cCatchError
done
#--> Strict natural mode: not understood: 'and_' (did you mean 'addn'?)

Several chains of the old articles no longer run. The sentence of the bridging article that carries IsAMQ needs a marker that I removed by my ruling of 10 July 2026. Several chains of the near-natural article do not run at this commit: InLowercase() raises for lack of an object; LettersNB, BeforeQ and TheirQ().FirstCharQ() are not defined; and the brace form Naturally() { ... } raises for too few parameters. The bridging article's chain with ReplaceLowercaseCharsQ is not defined either. I ran twelve chains of the near-natural article on 8 October 2026, and eight work. In that run, the bridging article's paragraph still ran in permissive mode, and printed two nested boxes around "NOTHING SOFTANZA" instead of the one it promises. The machine said so, since UnderstoodAll() is false and the unresolved word is named (the block above shows both), but a reader has to ask.

What is built: both directions; five packs as data and a sixth at runtime; refusals with reasons on both sides; the question frames, the thin truth chain, the evidential register; natural code as data. The folder holds thirteen files and about twelve thousand lines in twelve classes, by wc and grep on 8 October 2026.

What is designed: the plan of a narration emitted as an executable chain, so that chains gain Understood() for free. A grammar emitted for the natural lexicon, so that an AI model may only produce sentences the layer executes: I searched the folder, and no grammar emitter touches it. A guard that fails if a socket opens during a natural run, which does not exist. A coverage figure per pack printed by a guard. And the articles' examples pinned as fixtures.

What is absent: Hausa in the Ajami script, Zarma and Fulfulde. A natural layer closed all the way down: a plain list in a natural sentence reaches host code, which chapter 11 prints, and a descriptor reaches host code, above. Any machine that judges a chain's grammar. The standard Hausa letter, which the pack stores broken. A dictionary protected from drift. The record also holds no account, and no date, of my plea to the project of the former host language that natural programming be made a first concern, nor a sentence of mine in that voice that the book can source. All it holds is a private memo of 30 August 2026, which gives my judgement of the language's shipped natural form. The memo is marked private, so the book does not quote it and sources no phrase of mine to it.

8. Six doors

9. Exercise

Take one sentence you say about a word in your own language: that it is lowercase, has a given length, and a given number of vowels. Write it twice before you run anything. First as a near-natural chain, where you are the parser. Second as a Naturally sentence, where the library is. Under each, write the line you expect it to print.

# 1. as a chain, where you are the parser:
# 2. as a Naturally sentence, where the library is:

Then run both. Then change one word of the chain, and one word of the sentence, to a word the dictionary does not hold. Which direction told you? Which did you have to tell yourself? In one direction the machine tells you, and in the other you must tell yourself. If a promise breaks, do not change it: explain the output first.

I left this one in your hands. Section 7 shows a chain that reads "which a length of 4", and nothing refused it. Run it, read it aloud as English, and write under it the line you would have the library print to refuse it, with the reason it would give.

# the chain of section 7 that nothing judged:
? TheWordQ("haro").IsAQ(:Word).WhichQ().ALengthQ().Of(4)
# the line you would have the library print to refuse it, with its reason:

When you have written that line, you will know why I hold the ungrammatical chain as a view and not as a result, and who the page says must judge it (sections 4 and 7).

The next chapter is about knowledge programming, where the analyst's domain words were sent. Its principle is that a system is a file, and that adding a line to it makes the system know more, with nothing coded or trained. Here a sentence asks, and never declares.

Knowledge programming

Run on 2026-10-15 12:59 UTC+01:00 inside the library at commit 93d7a39bd: 13 of 13 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I take the three practices of the field that meet in this idea, the semantic stack, the property-graph database and rules over facts, and set beside them a system that is a plain text file. I run that file: two facts, one law and a proof with its steps, then a clinic in strict mode, where a refused rumour is kept and named. I write the file, read it back and show it at scale, from a course catalogue to an AI agent's memory. I say what I decided, that a business describes itself in one file and that the file is the program. I say what I refused: a parallel world, a contradiction resolved in silence, retrieval. I print the limit, a file that at this commit has no rules. It stands beside the principle: a system is a file, and adding a line to it makes the system know more, and nothing is coded or trained.

1. The concept, as the field holds it

Three practices of the field meet in this idea, and none of them is the same as it.

The first is the semantic stack: RDF, OWL and SPARQL. A fact is a triple of subject, predicate and object, written in a shared vocabulary. An ontology says what classes and properties exist and what follows from them, and a reasoner derives the consequences. These are W3C recommendations, of 2014, 2009 and 2013. What the field asks of the author of a knowledge base is an ontology language of their own, a store and a query language. They usually stand beside the application and not in it.

The second is the property-graph database, with its query language. The record has one comparison that sets such databases against this library. It is a text an AI model wrote, kept in the library's record, and it credits the field with scale, persistence and transactions.

The third is rules over facts, in Prolog and in Datalog. Facts and rules in one program, a query by resolution. The record names Prolog only, as a language to reach, and not to rebuild.

A fourth practice stands behind the contrast, and the design document names it only to refuse it. It is retrieval, a pile of document fragments searched by similarity; that description is general knowledge, not a study of the record.

So in the field the knowledge lives in a store and its logic in a reasoner, both beside the program. Here the knowledge is a plain text file that the program loads.

2. The first principle

A system is a file. Adding a line to it makes the system know more, and nothing is coded or trained.

Two sentences of the record carry it. The definition, in the design document written from my directive of 13 July 2026: intelligence is the computational ability to derive new knowledge from existing knowledge. And what the 2026 vision keeps from it: adding one fact augments the system's intelligence, with no code change and no training. Chapter 17 opens on the first, and I open here on the second. The design document of 13 July 2026 already says it, in nearly the same words, and the chapter keeps its opening.

Now the form itself, a text and what it does when you run it.

3. The Softanza form

Here is a system as a text. Two facts: flour is made from millet, and couscous from flour. Is couscous made from millet? Ask the graph, then add one line to the file, a law saying that made from is transitive, and ask again:

cFacts = 'knowledge "coop"' + nl + nl + "facts" + nl +
         "    flour | made-from | millet" + nl + "    couscous | made-from | flour" + nl
oA = new stzKnowledgeGraph("coop")
oA.ImportKnow(cFacts)
? oA.Prove([ "couscous", "made-from", "millet" ])[:narration]
#--> not derivable: no recorded fact or lawful chain gives 'couscous' made-from 'millet'
oB = new stzKnowledgeGraph("coop")
oB.ImportKnow(cFacts + nl + "ontology" + nl + "    made-from | transitive" + nl)
? oB.Prove([ "couscous", "made-from", "millet" ])[:narration]
#--> proved: couscous made-from flour made-from millet

Without the law the graph answers not derivable; with it, proved: couscous made-from flour made-from millet. The text is the program. The same two facts, one extra line, a different capability. The block does not touch the disk: ImportKnow takes a text, and takes a path when the string ends in the file's extension.

Now add a fact to the graph with the law, and nothing else. What do the two graphs answer to the longer question? Run it:

oB.KnowRelation("porridge", "made-from", "couscous")
? oB.Prove([ "porridge", "made-from", "millet" ])[:narration]
#--> proved: porridge made-from couscous made-from flour made-from millet
? oA.Prove([ "porridge", "made-from", "millet" ])[:narration]
#--> not derivable: no recorded fact or lawful chain gives 'porridge' made-from 'millet'

The graph with the law proves the longer chain and writes its steps out: proved: porridge made-from couscous made-from flour made-from millet. The graph without the law, which also never received the fact, still answers not derivable: no recorded fact or lawful chain gives 'porridge' made-from 'millet', and I want you to notice that this no has two causes, named in its own line: no recorded fact, and no lawful chain. A refusal is as certain as a proof, about what is recorded and declared: the graph says "not derivable", not "false". The library's comment on Prove says it: a certain no is still certain.

The same growth reaches the domain language model of chapter 19. Nothing is trained. But a model forged from a graph, in chapter 19's word, is a snapshot. Does the model learn the new fact when the graph does? Run it:

oKB = new stzKnowledgeGraph("coop")
oKB.Know("couscous", "dish")
oKB.KnowRelation("couscous", "contains", "semolina")
oDLM = StzDlmQ(oKB)
? oDLM.Ask("what is millet?")
#--> That is outside the 'coop' domain (I know 1 entities and 1 relations).
oKB.Know("millet", "grain")
oKB.KnowRelation("couscous", "contains", "millet")
? oDLM.Ask("what is millet?")
#--> That is outside the 'coop' domain (I know 1 entities and 1 relations).
oDLM = StzDlmQ(oKB)
? oDLM.Ask("what is millet?")
#--> Millet is a grain.
? oDLM.Ask("couscous contains what?")
#--> Couscous contains semolina and millet.

It does not. The second answer is the old model still refusing, That is outside the 'coop' domain, and only the model forged again answers Millet is a grain.

The file the library writes. A clinic. A relation declared unique, and a graph in strict mode, where every fact needs its provenance. What does it do with a fact that has no source, with one that has, and with a second, contradicting one from a rumour? And what does it then write to the disk? Run it:

StzKnowledgeGraphQ("clinic") {
	ConstrainRelation("treated-by", :Unique)
	EnableStrictMode()
	try
		AddFact("fatou", "treated-by", "dr-diallo")
	catch
		? cCatchError
	done
	#--> Strict mode: every fact needs provenance -- use AddFactXT(s, p, o, [ :source = ..., :confidence = ... ]).
	AddFactXT("fatou", "treated-by", "dr-diallo", [ :source = "registry", :confidence = 0.95 ])
	? AddFactXT("fatou", "treated-by", "dr-sani", [ :source = "rumour", :confidence = 0.2 ])
	#--> 0
	WriteToKnowFile("clinic")
}
? read("clinic.zknw")
#--> knowledge "clinic"
#
#    facts
#        fatou | treated-by | dr-diallo
#
#    provenance
#        fatou | treated-by | dr-diallo | source | text | registry
#        fatou | treated-by | dr-diallo | confidence | number | 0.95
#
#    contradictions
#        fatou | treated-by | dr-diallo | dr-sani | rumour
#
#    ontology
#        treated-by | unique

The naked fact is refused with the library's own sentence, Strict mode: every fact needs provenance. The fact with its source and confidence is admitted. The rumour is refused, 0, and the refusal is kept! That is what the library writes, a header and up to four sections. They come in this order: the facts, the provenance when a fact carries any, the contradictions when one was refused, and the ontology when a law was declared. One line per record, fields separated by a bar. A bar or a line break inside a value is escaped. The refused rumour sits in the file, named, and never resolved. The code comment on the contradiction list says it: named, NEVER silently resolved.

Does the file read back into a strict graph, with the law, the source of every fact and the refusal inside it? Load it:

StzKnowledgeGraphQ("clinic") {
	EnableStrictMode()
	aR = ImportKnow("clinic.zknw")
	? aR[:merged]
	#--> 1
	? @@( MetaOfFact("fatou", "treated-by", "dr-diallo") )
	#--> [ [ "source", "registry" ], [ "confidence", 0.95 ] ]
	? len(Contradictions())
	#--> 1
	? RelationHasLaw("treated-by", "unique")
	#--> 1
}
remove("clinic.zknw")
? fexists("clinic.zknw")
#--> 0

It does: one fact merged, the source and the confidence back, [ [ "source", "registry" ], [ "confidence", 0.95 ] ], one contradiction, and the law. A file of this kind was once written without its provenance. The export wrote only the bare triples, so knowledge read back from the disk no longer said where it came from. A strict graph could not load its own export. The fix is the two sections above. The guard that proves it is named in section 5.

A law that fires when a fact is added. On the library's default world, the one behind the natural-language sugar, a symmetric law derives the reverse fact as the first one is added, with no call to a derivation step. Nobody wrote that Ibrahim is married to Amina. Does the default world know it?

StzConstrainRelation("married-to", :Symmetric)
StzKnowRelation("amina", "married-to", "ibrahim")
? DefaultKnowledgeGraph().Query([ "ibrahim", "married-to", "amina" ])
#--> 1

It answers 1. The reverse fact is there, and nobody wrote it! This is the only place where a declared law fires on add that a run in this book shows, and it is the default world. The graph class also has a switch, EnableAutoDerive, that runs the derivation rules after every edge added; it is off by default, and I did not run it. I show the same law on an instance graph in section 7, where it does not.

A system at scale. The education program of the library is a knowledge file. Its catalogue, program.zknw, says what the program is called and which courses and languages it has. What is its name, and which languages does it carry? Ask it:

oP = StzProgramQ("../../education/program")
? oP.Id()
#--> softanza-education
? @@( oP.Languages() )
#--> [ "en", "fr", "ar", "ha" ]

It is called softanza-education, and it has four languages. Adding a course is adding a line there, and the guard checks that every declared course is a folder and every folder is declared. In the education module the snapshot holds ninety-nine knowledge files, counted with find on 8 October 2026. They are courses, exercises, worlds and skills, a project world for a learner, and the overlays an institution lays over the core. An agent's memory is also a knowledge graph, saved through the same format, with provenance.

That is the form. Now what I decided, and what I refused.

5. The court

knowledge_integration_narrated proves that the world answers WhatIs, that the graph grew alongside it, and that the law lives in the ontology. It proves that Prove narrates the law first and then the links of the chain, with certainty 1, and refuses what it cannot prove. It proves that the file round-trips. It proves that a symmetric law derives the reverse edge when the derivation step is applied after a fact is added through the graph. Last, it proves that strict mode admits a provenanced fact, refuses a naked one, and refuses and records a unique contradiction.

provenance_survives_save_narrated proves that a fact's source and confidence survive a save, that a strict graph loads its own export, and that a refused contradiction survives. It proves that a bar or a line break in a value is data, and that an old file with no provenance still loads. It proves that an agent's memory records who learned a fact, and when.

program_narrated proves that the program counts its courses, and that every course declared is a folder and every folder is declared. It proves that the texts read the same from a checkout with other line endings.

That is what the guards prove. What the field does better comes next.

6. The field, and where it leads

The record's own graph comparison says where the traditional solutions win: large-scale systems that need distributed storage and processing, and performance-critical applications. Its table puts Softanza at business scale, in the hundreds to thousands of nodes, in a single process. That is the fair summary of the loss: the field leads in scale, persistence, transactions and tooling. The comparison's row for persistence predates the file; the knowledge graph now writes one.

The field leads in standards and reach, in general knowledge. A knowledge base in RDF can be shared with any tool that reads the W3C formats, linked to public vocabularies and queried across stores. As far as the record shows, a knowledge file is read by this library and by nothing else. A reasoner for a rich ontology language does what three laws and a class declaration do not. The field leads in the expressiveness of rules: Prolog and Datalog derive new facts from arbitrary rules. Here, in the runs I kept, one law derives a fact, and only on the default world. The field leads in multi-step queries, since SPARQL and Cypher join patterns. And in many relations between two things.

Here is where I think this stands apart, with the measured limits beside it. The knowledge is a text file a person can read, edit, diff and ship with the program. Every answer is provable with its steps, and a no is as certain as a yes. What a fact claims travels with its source and its refusals. And the same format carries a course, a learner's project and an agent's memory. None of that needs a store, a server, an AI model or a training run.

The losses are printed. The limit of the chapter comes next, with its runs.

7. The limit

• builta system as a plain text file of facts, with laws (unique, transitive, symmetric) and the source of each fact; Prove with its steps, a no as certain as a yes; strict mode; the file written, read back and shipped, from a course catalogue to an AI agent's memory
• designedrules in the file; derivation on any graph; a query that joins; several relations between two things; class inheritance; validation on load
• absentthe 2022 founding dialog, which does not run; Explain on a knowledge graph; the rules section of the file, which the parser drops

The limit of this chapter is the one my directive, in section 4, already carries: entities, relations, an ontology, rules. The file at this commit has no rules. Here is the file with a rules section. What does the parser make of it?

cRules = 'knowledge "pairs"' + nl + nl + "facts" + nl + "    margherita | pairs-with | chianti" + nl + nl +
         "rules" + nl + "    pairs-with | symmetric" + nl
oRul = new stzKnowledgeGraph("pairs")
aM = oRul.ImportKnow(cRules)
? aM[:merged]
#--> 1
? len(oRul.Ontology())
#--> 0

The file merges, 1, and the ontology is empty, 0. The parser recognises the header rules, and has a handler for none of the lines under it. They are dropped: the ontology holds 0, and no refusal comes back. The same law under the header ontology gives an ontology of length 1. Rules live elsewhere, as data in a rule attached to a graph, which are chapters 29 and 30, and in a separate file that names rule functions. In this file there are facts and laws. I print "facts and laws", and I send the rules to those two chapters. The single file that holds rules, which the design promises, is not there, and this section prints the gap as the chapter's limit.

The law is also not derived on an instance graph. Take the same symmetric law and the same fact as on the default world. Is the reverse there?

StzKnowledgeGraphQ("pairs") {
	ConstrainRelation("pairs-with", :Symmetric)
	KnowRelation("margherita", "pairs-with", "chianti")
	? RelationHasLaw("pairs-with", "symmetric")
	#--> 1
	? Query([ "chianti", "pairs-with", "margherita" ])
	#--> 0
}

The law is recorded, 1, and the reverse edge is not there, 0! The class header says it: only :unique and :transitive are acted on here; symmetric is only recorded. Four more limits, each with its run.

One relation between two things. The graph stores one edge per node pair. Does it admit a second relation between the same two entities, amina and bread? Run it:

oShop = new stzKnowledgeGraph("shop")
oShop.KnowRelation("amina", "sells", "bread")
aV = oShop.Admit("amina", "buys", "bread", [ :source = "till" ])
? aV[:admitted]
#--> 0
? aV[:why]
#--> Can't add fact: 'amina' and 'bread' already carry the edge 'sells' (stzGraph stores one edge per node pair).

The second relation is refused, 0, with the library's own sentence, Can't add fact: 'amina' and 'bread' already carry the edge 'sells' (stzGraph stores one edge per node pair). A knowledge model that cannot hold sells and buys between the same two entities is a real limit. The code says it: known limitation, revisit with multi-edge support.

A two-step question answers only its first step. Does QueryPath follow its second pattern, and can the predicate of a query be a variable? Run it:

StzKnowledgeGraphQ("coop2") {
	KnowRelation("amina", "sells", "couscous")
	KnowRelation("couscous", "made-from", "flour")
	? @@( QueryPath([ [ "amina", "sells", "?p" ], [ "?p", "made-from", "?m" ] ]) )
	#--> [ "couscous" ]
	? @@( Query([ "amina", "?p", "?o" ]) )
	#--> [ ]
}

The path answers [ "couscous" ], the first step and nothing more: QueryPath ignores the rest of its patterns, so it is no multi-step query yet. The variable predicate answers [ ].

A line that is not a fact. Four lines, three of them not facts: two fields, four fields, and no bars. What does the parser refuse?

cBad = 'knowledge "t"' + nl + nl + "facts" + nl + "    a | likes | b" + nl + "    c | likes" + nl +
       "    d | likes | e | f" + nl + "    g likes h" + nl
oT = new stzKnowledgeGraph("t")
aBad = oT.ImportKnow(cBad)
? aBad[:merged]
#--> 1
? @@(aBad[:refused])
#--> [ ]

Nothing. The file merges, 1, and the refused list is [ ]; the parser is silent and the three lines vanish! The design document promises that the file is "validated on load". At this commit the parser keeps only a line with exactly three fields.

The 2022 founding dialog. The narration tells knowledge programming through a dialog: an apple as a fruit and as a company, an owner, relations asked as questions. At this commit its first line does not run. The text, which I show and do not run, is @Q("Apple").IsA(:Fruit). On 8 October 2026 it stopped with Calling Function without definition: @isfruit; I did not keep that run as a block. The string class reads the predicate as natural language and looks for a function by that name. Two other forms stop elsewhere. The narration's promise lines are stale. The nearest form that runs keeps the point. Does the world know one name with two meanings?

StzKnow(:Apple, :Company)
StzKnow(:Apple, :Fruit)
? @@( WhatIs(:Apple) )
#--> [ "company", "fruit" ]

It knows both: [ "company", "fruit" ].

The study of the record already says the dialog was kept at the margin, and that the centre moved to the file. The chapter keeps the file as its opening, and the 2022 dialog stays at the margin.

What is designed: rules in the file; derivation on any graph; a multi-step query; several relations between two things; class inheritance. DefineClass writes a fact, and no inheritance follows. The nearest that ran, in an earlier probe whose run I did not keep, is to declare is-a transitive and state the class as a fact of that relation. And the design's knowledge hygiene beyond provenance, bounded queries, scoped graphs and revision with rollback, has no method of that name.

What is absent or broken: Explain() on a knowledge graph, which calls ApplyInference, a function defined nowhere. And ValidateOntology(), which returns 1 whatever the ontology holds, as its own comment says, known defect.

One note on the design document's history. Its amendment of 22 August 2026 says that no knowledge file exists anywhere in the tree, and that this is hygiene and not a gap. At this commit that is no longer true: there are ninety-nine, all of them in the education module.

That is the limit, printed. Now the six doors.

8. Six doors

9. Exercise

Here is a world with two facts, and a question it cannot answer yet. Your promise is the line proving that class 3b is part of primary, with the chain written out. Change the world, and not the question.

cWorld = 'knowledge "school"' + nl + nl + "facts" + nl +
         "    class-3b | part-of | grade-3" + nl +
         "    grade-3 | part-of | primary" + nl
oW = new stzKnowledgeGraph("school")
oW.ImportKnow(cWorld)
? oW.Prove([ "class-3b", "part-of", "primary" ])[:narration]
# this prints a refusal. Your promise: the line proving that class-3b is part of primary,
# with the chain written out. Change the world, not the question.

Run it and see what prints. If you change the question to ask about grade 3, it will prove something, and it will not be the line you promised. Then ask the reverse question, whether primary is part of class 3b, once your world has its law, and see whether the law adds a fact in the wrong direction. I do not tell you the line to add.

I left this one in your hands. Section 7 runs a file of four lines, three of them not facts, and prints what the parser says about them. Here is that file again with one change: it also asks the graph about three of the lines, and I print none of the answers.

cBad = 'knowledge "t"' + nl + nl + "facts" + nl + "    a | likes | b" + nl + "    c | likes" + nl +
       "    d | likes | e | f" + nl + "    g likes h" + nl
oT = new stzKnowledgeGraph("t")
aBad = oT.ImportKnow(cBad)
? aBad[:merged]
? @@(aBad[:refused])
? oT.Query([ "a", "likes", "b" ])
? oT.Query([ "d", "likes", "e" ])
? oT.Query([ "g", "likes", "h" ])

Run it. Read merged, read refused, read the three queries, and find which lines the graph holds and what the parser told you about the others. Set the design document's promise of a file "validated on load", in section 4, beside what you find; section 7 says what the parser keeps. I do not give you the answer, and I did not fix the parser. When you have it, you will know why a file that merges is not a file that was validated.

The next chapter is about pattern languages: a pattern is a rule about the shape of data, written as data, and the same habit serves data of every kind. Here a law about a relation was a line in a file; there the rule is about the shape of the data itself.

Pattern languages

Run on 2026-10-15 12:59 UTC+01:00 inside the library at commit 93d7a39bd: 13 of 13 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I start from the regular expression, which is what a pattern is for a working programmer, and carry its habit to data that is not text: lists, numbers, tables, matrices, time and graphs. I run the same small move in each medium, a constructor, a pattern in a string, Match, and I show you at once that the grammar is not quite one. I say what the guards prove and where the family is still in development, and I keep its one tension for the limit: a word the language does not know is not yet refused. The principle is this: a pattern is a rule about the shape of data, written as data, and the same habit serves every kind of data.

1. The concept, as the field holds it

For a working programmer, a pattern is a regular expression: a compact notation for the shape of a string, handed to an engine that says whether the text fits, and where. The engines are old and well known. The one beneath this library is PCRE2, and the site measures it against two others.

For data that is not text, the field uses other tools, one per medium and none shared. Structural pattern matching in the languages of the ML family, in Rust, and since Python 3.10 in Python. Schema checks for lists and records. Data-quality libraries for tables. Row pattern recognition in SQL, and stream engines, for sequences over time. And graph query languages, whose core is a path pattern. That is general knowledge, well established; the record holds no dated study of any of them, and I invent none.

The estate's own field study of August 2026 gives the small languages that survived a profile: a closed grammar, one domain question, plain text, a tiny surface, a specification with a conformance suite, decades of stability. A pattern language is exactly that. One question, does this data fit, in a few characters. What the field does not offer is the same notation across the media.

Next, the first principle.

2. The first principle

A pattern is a rule about the shape of data, written as data. The same habit serves every kind of data.

The sentence the library's articles return to, in each medium, is the one in the article on numbers: instead of instructing the machine how to test a condition, you state what you mean. My study of the record, which is not the field study above, also carries a phrase of mine, "for the first time in computer science history". I found it in no text of the library, so the site does not claim it. I keep it here as what I said, and I claim only what is measured: one regex-shaped grammar across seven kinds of data in one library, text and six that are not text, with the same small-function habit. And I will show you at once that the grammar is not quite one.

3. The Softanza form

A pattern called by name is a closed catalogue. The library has a data file of named patterns. What does it say when you ask for a name it does not hold? Run it:

? rx(pat(:isoDate)).Match("2023-12-25")
#--> 1
? rx(pat(:isoDate)).Match("25/12/2023")
#--> 0
? rx(pat(:isoDate)).Explain()
#--> Matches ISO 8601 date format (YYYY-MM-DD)
try
	pat(:banana)
catch
	? cCatchError
done
#--> The pattern name you provided does not exist in stzRegexData file.

It refuses, and says why: The pattern name you provided does not exist in stzRegexData file.

A pattern can also answer the half-written value, which is what a form wants as the person types:

StzRegexQ("^\d{3}-\d{2}-\d{4}$") {
	? MatchAsYouType("123-45")
	#--> 1
	? MatchAsYouType("abc")
	#--> 0
	? IsPartialMatch("123-45")
	#--> 1
	? IsPartialMatch("123-45-6789")
	#--> 0
}

Now the move that gives the chapter its title. Take a list. Its pattern is written in square brackets, and counts, nesting and negation are written, not looped. @N stands for a number, @S for a string, + for one or more, @N1-3 for one to three, and @! for not. Does [@N1-3, @S] accept four numbers before the string? The second call answers:

? Lx("[@N+, @S]").Match([1, 2, 3, "end"])
#--> 1
? Lx("[@N1-3, @S]").Match([1, 2, 3, 4, "end"])
#--> 0
? Lx("[@S, [@N+]]").Match(["tea", [1, 2, 3]])
#--> 1
? Lx("[@S, [@N+]]").Match(["tea", ["x"]])
#--> 0
? Lx("[@!N, @N]").Match(["a", 1])
#--> 1
? Lx("[@!N, @N]").Match([1, 1])
#--> 0

No: the second call prints 0, because four numbers are one too many. Every call here uses a fresh object, for a reason that section 7 gives. Chapter 11 showed four calls of the same language, and I do not repeat them.

The numbers have properties, and a property is meaning, not procedure. Which numbers between 1 and 500 are perfect? The last line turns a pattern from a test into a search:

? Nx("{@Property(Even) & @Property(Prime)}").Match(2)
#--> 1
? Nx("{@Property(Even) & @Property(Prime)}").Match(4)
#--> 0
? Nx("{@Digit(:unique)+}").Match(1234)
#--> 1
? Nx("{@Digit(:unique)+}").Match(1223)
#--> 0
? Nx("{@Relation(Mod:5=0)}").Match(10)
#--> 1
? @@( Nx("{@Property(Perfect)}").MatchingNumbersBetween(1, 500) )
#--> [ 6, 28, 496 ]

Three numbers answer, and no loop was written.

Tables: a data-quality rule is a sentence of the language. The person who owns the data can read it. Niamey appears twice, so the cities are not unique, and the negation of that is true:

oT = new stzTable([
	[ :ID, :NAME, :AGE, :CITY ],
	[ 1, "Ali", 28, "Niamey" ],
	[ 2, "Sara", 32, "Paris" ],
	[ 3, "Omar", 41, "Niamey" ],
	[ 4, "Awa", 25, "Dakar" ]
])
? Tbx("{cols(4) & unique(id) & avgcol(age:>30)}").Match(oT)
#--> 1
? Tbx("{cols(4) & unique(city)}").Match(oT)
#--> 0
? Tbx("{@!unique(city)}").Match(oT)
#--> 1
? Tbx("{sorted(id) & numeric(age) & alphabetic(name)}").Match(oT)
#--> 1

A pattern is data, so patterns compose: one is built from patterns.

oA = new stzTablex("{cols(4)}")
oB = new stzTablex("{rows(4)}")
oAnd = oA.And_(oB)
? oAnd.Pattern()
#--> {cols(4) & rows(4)}
? oAnd.Match(oT)
#--> 1
? oA.Not_().Pattern()
#--> {@!cols(4)}
? oA.Not_().Match(oT)
#--> 0

A matrix: a concept, square and symmetric, is one line.

? Mx("{shape(square) & property(symmetric)}").Match([ [1,2,3], [2,4,5], [3,5,6] ])
#--> 1
? Mx("{shape(square) & property(symmetric)}").Match([ [1,2,3], [4,5,6], [7,8,9] ])
#--> 0
? Mx("{size(2x3)}").Match([ [1,2,3], [4,5,6] ])
#--> 1
? Mx("{property(identity)}").Match([ [1,0], [0,1] ])
#--> 1

Time, in the part of it that runs, written here with the class rather than its small function Tmx. A duration must fit a rule: one to two hours, on a step of a quarter of an hour. Which of three durations fits: ninety minutes, eighty minutes or three hours?

oTm = new stzTimex("{@Duration(1h..2h:15min)}")
oTm {
	? Match(new stzDuration("1 hour 30 minutes"))
	#--> 1
	? Match(new stzDuration("1 hour 20 minutes"))
	#--> 0
	? Match(new stzDuration("3 hours"))
	#--> 0
}

Only ninety minutes fits: eighty is inside the range and off the step, and three hours is outside.

A graph: a pattern reads like the path it looks for. The labels match without regard to case. Does direction matter? The second line answers:

g = new stzGraph("Order")
g {
	AddNodeXT(:a, "Placed")
	AddNodeXT(:b, "Cooking")
	AddNodeXT(:c, "Served")
	AddEdgeXT(:a, :b, "starts")
	AddEdgeXT(:b, :c, "finishes")
}
? (new stzGraphex("{@Node(placed) -> @Edge(starts) -> @Node(cooking)}", g)).Match(g)
#--> 1
? (new stzGraphex("{@Node(served) -> @Node(placed)}", g)).Match(g)
#--> 0
? (new stzGraphex("{@Node(placed) -> @!Node(refunded)}", g)).Match(g)
#--> 1

Yes: the path from served to placed finds nothing, and the line prints 0.

Last, the habit. The pattern is data in every language, and a language that exposes its tokens can be read back by a person and by an AI agent. Five of the six that are not text do; here are three of them:

? len( Lx("[@N, @S]").Tokens() )
#--> 2
? Lx("[@N, @S]").Tokens()[2][:type]
#--> string
? Nx("{@Property(Even) & @Property(Prime)}").Tokens()[1][:type]
#--> conjunction
? len( Mx("{shape(square) & property(symmetric)}").Tokens()[1][:conditions] )
#--> 2

Graphs have no Tokens, no Pattern and no working Explain at this commit, and no small function either. There is no Gx, and there is no Tx for time, although the study's table names both. The small functions are rx, Lx, Nx, Tbx, Mx and Tmx.

5. The court

00_regex_narrated proves the anchors and the search, the classes, the exact quantifiers, the groups, the four match types, partial matching as you type, and positions as data. 00_numbrex_narrated proves prime, perfect, Fibonacci, even and odd, square and composite, each with a number that matches and one that does not. Its header records a regression in which Match() once returned TRUE for every input. tablex_narrated proves the parser, counting, uniqueness, sorting, types, sums and averages, the three connectives, sequences, and building patterns from patterns. Its header names the fault it killed. The parser sliced with an end position through a function that counts, and about ninety patterns parsed into a token of the right type with no value. 00_matrex_narrated proves exact size, any size and the square shape. Its header records that Match() once returned FALSE for every input. 00_graphex_narrated proves that a pattern compiles to a graph, present and absent labels, a sequence as a subsequence, the case rules, negation, alternation, numeric properties, and the cache by graph signature.

Note the placement: the guard for tables lives in the folder for regex, and its stem has no 00_ prefix.

There is no narrated guard for lists, time, or the regex builders. The courts of those are classic files without usable promises. The tests of lists sit after a function definition, so the host language reads them as the body of the function and runs none of them. I ran a copy with the function moved to the end, and I did not keep that run as a block. Sixty checks ran, and two of them disagree with the file's own expectation. The classic file of time says that a promise is TRUE and the run prints 0, and the central record filed this on 1 October 2026 as still open.

Next, the field, and where it leads.

6. The field, and where it leads

Strings. The field leads on safety and speed, and Softanza leads on naming. The site's page for the area says it itself: it trails the modern engines on safety and throughput, with no JIT and no linear-time matcher. The control against catastrophic backtracking is not reachable from Haro, although the code for both is already compiled into the binary. The engine's header confirms that the hardening exists underneath: a match limit, a recursion limit, length caps.

Lists, numbers, time, graphs. The field has older, more established single tools. The study says it without ranking them: one tool has list patterns, uniqueness and stepped ranges; three languages have structural matching; graph query languages exist; event processing exists for time. What the field lacks, and what the record claims, is the one habit across the media.

Tables. Data-quality libraries lead in reach and ecosystem. Here a rule is a sentence the person who owns the data can read. The loss is that it runs only on stzTable.

Where the family is still in development. The class headers print their known gaps as warnings: for matrices and graphs. That is rare, and I say it. Graphs: the quantifiers are parsed but not yet used by the match. Matrices: known gaps today, each carried as a warning on its method.

A date for the family's one recurring bug. The same root cause hit the family language by language: the parsers sliced with an end position through a function that counts. The numbers and matrices were repaired on 14 June 2026, the tables on 5 October, and the graphs in a fix whose date the file does not give. Time still carries it. This is evidence that the family shares one design and one parser's habits; it is also a likely reason time does not yet match.

Next, the limit.

7. The limit

• builtpatterns for text, numbers and tables, each with a guard; the same small habit across the media (a constructor, a pattern in a string, Match, Tokens)
• designedone pattern engine shared by every medium; the pattern as the condition side of the cascade; the pattern written from examples
• absentthe refusal of a word the pattern language does not know, in the six media that are not text; sequences over a timeline in time; a narration and a small function for graphs; the genetic, linguistic and quantic siblings

What is built: strings, numbers and tables, each with a guard and a small function. The shared habit.

What is built in part: lists, matrices, time and graphs, in that order.

• Lists: types, counts, nesting, negation, alternation and sets run. Stepped ranges raise. In a run I did not keep as a block, the uniqueness flag was ignored, so [@N2-3{1; 2; 3}U] accepted [1, 1], though the class has code for a uniqueness check. The wildcard of the article, @A, is not a token; the real wildcard is @$. And a reused object answers from a cache whose key is the list's length and the sum of its characters' codes, which does not depend on order. A fresh object answers 0 for ["hello", 1], and the same object after [1, "hello"] answers 1.
• Matrices: size, shape, element and three properties run. The class header lists the terms that accept every matrix: row, col, pattern, determinant and sum. A matrix of two by two is accepted by {row(99)}.
• Time: instants and durations with a step run. In a run I did not keep as a block, a range without a step raised. And sequences over a timeline do not run at all: here is a timeline with a meeting, a break and a lunch, and the pattern the article promises. Does it match?

oTl = new stzTimeLine("2025-10-22", "2025-10-22")
oTl {
	AddInstant("Meeting", "2025-10-22 09:00:00")
	AddSpan("Break", "2025-10-22 10:00:00", "2025-10-22 10:15:00")
	AddInstant("Lunch", "2025-10-22 12:00:00")
}
o1 = new stzTimex("{@Event(Meeting) -> @Duration* -> @Event(Break)}")
? o1.MatchPartial(oTl)
#--> 0
o2 = new stzTimex("{@Event(Lunch)}")
? o2.MatchPartial(oTl)
#--> 0
? @@( o2.Tokens()[1][:label] )
#--> "Lunch)"

The article promises that the first is TRUE. The second shows that even a single event the timeline holds does not match! The third shows why: the token's label is "Lunch)", read with its closing parenthesis. That is the shared bug; repairing it in time is the next step.

• Graphs: labels in order along a path, negation, alternation and numeric properties run. The arrow means later on one path, and not next. The quantifiers (+, *, ? or a number after a token) are read and ignored. The graph of section 3 has three nodes; here @Node10, a node with the quantifier ten, is asked for between them. Does the pattern match?

? (new stzGraphex("{@Node(placed) -> @Node(served)}", g)).Match(g)
#--> 1
? (new stzGraphex("{@Node(placed) -> @Node10 -> @Node(served)}", g)).Match(g)
#--> 1

Cooking lies between the first and the last, so the first answer is the arrow's meaning. The second answers 1 too! The quantifier is ignored. The cache of this class is keyed by the node and edge counts and the node ids. A second graph with the same ids and other labels is answered from the cache, until ClearCache(): the answer can be stale.

The refusal the family has not yet made. Chapter 11's law is that a language is declared and closed, with refusals. What does the family answer when it is asked a word it does not know? Run it:

? Nx("{@Banana(3)}").Match(7)
#--> 1
? Nx("{@Banana(3)}").Match(1000003)
#--> 1
? @@( Nx("{@Banana(3)}").Tokens() )
#--> [ ]
? Nx("{@Property(Banana)}").Match(7)
#--> 0

A pattern with a word the language does not know matches every number! The tokens are [ ], and nothing is raised. The matrix and table languages return an ERROR token that nothing raises, and the number and time languages return an empty list. The Haro charter session filed this as a finding, which the central record relayed on 28 September 2026: the six pattern classes accept unknown tokens silently. I reproduced it on this commit, and the request is not closed. A closed language that cannot refuse is not yet the law of chapter 11. The chapter prints it as a finding of the court, and not as a debt of mine. I hold that as my view. The run above, on this commit, is what stands behind it.

What is designed: one pattern engine shared by all the media. The engine design says the backtracking engine, the constraint solver and the pattern compiler are the same across all domains, and that only the vocabulary changes. Its status is planned. At this commit the vocabulary changes and so does the code. The engine's own file named pattern is another thing: palindromes, repeats and arithmetic and geometric sequences. The pattern as the condition side of the cascade, many faculties firing one after another on a shared state, is chapter 9's third rung, and designed.

What is absent: induction from examples, which is reserved. The genetic, linguistic and quantic siblings, which are vision only. The explanation of an unnamed pattern, since rx("[a-z]+").Explain() raises because the analyser class was never built. And any use of the pattern classes by the rest of the library: outside the regex folder, the tests and the docs, no class takes a pattern. stzList, stzNumber, stzTable, stzMatrix and stzGraph have no Matches(pattern). In the docs, the education course uses them, in a chapter and an exercise whose answer is checked by running the learner's program, and the gallery has a few scripts that use them.

8. Six doors

9. Exercise

Three small tables are given. Write one pattern that accepts only the first. Before you run anything, write under each of the three printed lines what you expect and why.

t1 = new stzTable([ [ :ID, :EMAIL ], [ 1, "ali@x.org" ], [ 2, "sara@x.org" ] ])
t2 = new stzTable([ [ :ID, :EMAIL ], [ 1, "ali@x.org" ], [ 1, "sara@x.org" ] ])
t3 = new stzTable([ [ :ID, :EMAIL ], [ 1, "ali@x.org" ], [ 2, "" ] ])
# write ONE pattern, then print whether it matches t1, t2, t3, on three lines
cPattern = "{ ... }"
? Tbx(cPattern).Match(t1)
? Tbx(cPattern).Match(t2)
? Tbx(cPattern).Match(t3)
#--> 1
#--> 0
#--> 0

Run it. One clause rejects the second table and another rejects the third; which is which? And what would the pattern say if the email were a single space? I do not answer first. If a promise breaks, do not change it: explain the output.

I left this one in your hands, on purpose, and I name it a defect. Take the matrix block of section 3 and change one thing in its last line: put {row(99)} where {property(identity)} stands, and keep the matrix.

? Mx("{row(99)}").Match([ [1,0], [0,1] ])

Say what you expect before you run it, then run it. Do not change the pattern to make the output agree with you: section 7 says where the library prints this defect, and why. When you have found it, you will know which terms of the matrix language accept every matrix.

The next chapter is about seven languages and one door. A door is a runtime and never a syntax, and the door is one: it is the answer to "what about language X".

Seven languages, one door

Run on 2026-10-15 12:59 UTC+01:00 inside the library at commit 93d7a39bd: 10 of 10 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I take the field's two lessons about reaching another language, an escape that is open and a border with no way out, and I put the door where they meet. I ask the door which languages it knows, run Python and NodeJS through it, read Python and JavaScript into one code graph, and show the governance refusing an executor with no posture. Then I say what I decided: one door, and no further host embeddings. And I say where the door stands at this commit: its governance is designed, a way back that is closed is absent, and the R door, in development, raises today. The principle is the one chapter 11 promised: a facet is a syntax of one grammar and never a runtime, a door is a runtime and never a syntax, and the door is one.

1. The concept, as the field holds it

For a working programmer, reaching another language from the one you write means one of two things. The first is a foreign function interface, a call into a shared library. The second is a child process, a run of an interpreter whose output you parse. Notebooks and polyglot virtual machines make the same move with more comfort. That is general knowledge; the record holds no dated study of these tools, and says so itself.

The estate's own field study of August 2026 has two sentences on this, and they pull in opposite directions. On the way out, the host language is the escape hatch, and the escape hatch is always taken. It gives two internal languages that died of openness. On the way in, the differentiator is escape; a language you make must be consumable from any stack. It gives one language that stalled at the border of its own world.

So the lesson of the field is double. An escape that is open destroys a closed language. And a language with no way out dies at its own border. A door is where those two lessons meet.

There is a second habit, which looks like the first and is not. Tools that let you write in the syntax you know over another engine, a transpiler, a second front end for one compiler, I will call by the word of this book, facets, which chapter 12 defines. The estate's design memo for them is blunt about their cost. The promise of a second facet is readability for a human who knows the other language, and not behavioural transfer.

2. The first principle

A facet is a syntax of one grammar, and never a runtime. A door is a runtime, and never a syntax. The door is one, and it is the answer to "what about language X".

The vision's own sentence, ratified in session on 28 August 2026, says it of the door: foreign code in the selected languages, governed, one door, with no further host embeddings. The study of the record reads the pair in a line I keep: the facet brings the programmer, and the door brings the ecosystem. Chapter 11 promised that this chapter would tell the difference; chapter 1 promised it the seven layers. Here is the difference.

3. The Softanza form

The door's list is closed. The foreign languages are a registry, and the host is not on it. Which languages does the door know? Ask it about six, then about the host, under the name the library's own data still gives it, the former host language's, then about one that was never on the list:

oDoor = new stzExterCode(:python)
aNames = [ "c", "nodejs", "julia", "r", "prolog", "python", "ring", "cobol" ]
for cLang in aNames
	? cLang + ": " + oDoor.IsLanguageSupported(cLang)
next
#--> c: 1
#--> nodejs: 1
#--> julia: 1
#--> r: 1
#--> prolog: 1
#--> python: 1
#--> ring: 0
#--> cobol: 0

"What about language X" has one answer, and for a language not on the list it is a refusal by name:

try
	oNo = new stzExterCode(:cobol)
catch
	? cCatchError
done
#--> Language 'cobol' is not supported

The door refused it by name: Language 'cobol' is not supported!

Now the door runs a real runtime. A short note on the machine first. The door writes a script, starts the runtime by it, and reads a result file back. The library's default place for Python is not where this machine keeps it, so the door is given the bare command python, which the machine resolves on its path. Node and R are at the library's default places. The blocks that start a runtime are marked, in the reader, as touching the system, and they show the output that was recorded on the date of the build.

What comes home from a Python call? The result arrives as the host's own structure, a list, and the call leaves a trace:

cPython = "python"
oPy = new stzExterCode(:python)
oPy {
	SetRuntimePath(cPython)
	SetCode("
res = { 'numbers': [1, 2, 3, 4, 5], 'mean': sum([1, 2, 3, 4, 5]) / 5 }
	")
	Execute()
	? @@( Result() )
	#--> [ [ "numbers", [ 1, 2, 3, 4, 5 ] ], [ "mean", 3 ] ]
	? CallTrace()[1][:language]
	#--> python
	? CallTrace()[1][:mode]
	#--> interpreted
	? isNumber(LastCallDuration())
	#--> 1
}

The Python float 3.0 came back as 3, in [ "mean", 3 ]. The trace also holds a duration. The block prints only 1, the answer to isNumber, because a duration is a clock, and a clock cannot be promised.

That is the rationale of the whole plane, in one picture. Each layer of a solution is in the language best at it, and the host passes data in as text and reads data back. The library's own article lists the layers: system performance in C, event-driven systems in NodeJS, scientific computing in Julia, statistics in R, logical reasoning in Prolog, and machine learning in Python. It adds AI reasoning in a language model, and solution integration in the host. Here are two of them in a pipeline, Python computing the averages of two students and NodeJS deciding. The thresholds are mine; the data is the article's:

aStudents = [ [ "Alice", [ 85, 90, 78 ] ], [ "Bob", [ 72, 65, 70 ] ] ]
oPy2 = new stzExterCode(:python)
oPy2 {
	SetRuntimePath(cPython)
	SetCode("
students = " + @@(aStudents) + "
res = [ [ s[0], round(sum(s[1]) / len(s[1]), 2) ] for s in students ]
	")
	Execute()
	aAverages = Result()
}
? @@(aAverages)
#--> [ [ "Alice", 84.33 ], [ "Bob", 69 ] ]
oNode = new stzExterCode(:nodejs)
oNode {
	SetCode("
const avgs = " + @@(aAverages) + ";
const res = avgs.map(a => [ a[0], a[1] >= 80 ? 'Excellent' : 'Needs work' ]);
	")
	Execute()
	? @@( Result() )
	#--> [ [ "Alice", "Excellent" ], [ "Bob", "Needs work" ] ]
}

The data goes in by composing the code string with the host's own list printer, since the article's marshalling functions are absent (section 7).

Which seven? The title commits to a number, and I ruled on 12 October 2026 which one: the six foreign runtimes of the registry above and the host, as the article on the plane and the article on performance count them. The language model is not one of them, because it is not a door of this plane at all. Chapters 17 and 20 make the model a proposer that cannot commit, while the narrations run it as a first-class runtime through a function that is absent. Section 7 prints that as a limit. The record counts it differently elsewhere: seven domain modules with one for a language model, seven domains with the host as an eighth, the registry's six without the host, the vision's "7 selected languages" that it never lists, and the engine design's five with COBOL. The registry above is the one that runs.

A facet is not a door. Reading a foreign language is also not running it. The two languages that I name as Haro's planned facets are also the two that the library can already read into one code graph. It does not run them and does not write them. One set of questions answers over both:

cPy = "class Animal:" + nl +
      "    def speak(self):" + nl +
      "        return '...'" + nl +
      "" + nl +
      "class Dog(Animal):" + nl +
      "    def speak(self):" + nl +
      "        return 'woof'"
cJs = "class Animal { speak() { return '...' } }" + nl +
      "class Dog extends Animal { speak() { return 'woof' } }"
StzPyCodeGraphFromSourceTS(cPy) {
	? Language()
	#--> python
	? @@( ParentsOf("Dog") )
	#--> [ "Animal" ]
	? @@( OwnersOf("speak") )
	#--> [ "Animal", "Dog" ]
}
StzJsCodeGraphFromSourceTS(cJs) {
	? Language()
	#--> javascript
	? @@( ParentsOf("Dog") )
	#--> [ "Animal" ]
	? @@( OwnersOf("speak") )
	#--> [ "Animal", "Dog" ]
}

This is a parser into an index of classes, methods and inheritance, and not a program graph that can print a program. It is a coincidence of the order of work, and not yet a facet. The record has one statement of mine on facets. I made it in session on 8 October 2026, and it says that a link should be made with the future vision of Haro and its facet languages. In that vision the former host language is already there, and Python and JavaScript are planned. The charter of Haro on this machine speaks of one grammar and one text. Its design memo for a second facet, which proposes and rules nothing, recommends printers read by humans before any parser. Its own table lists the collisions: a Python reader expects zero-based indexing and Haro's is one-based. The chapter says "planned" only with that statement named as its source.

A door is governed. The governance has the word for foreign code. external is the posture the library defines as out-of-process. What does the governance answer before that posture is declared, and after? Ask it:

oGov = new stzGovernance("shop")
oGov {
	? MayExecute("python")
	#--> 0
	? Why()
	#--> refused: 'python' has NO declared trust posture
	DeclarePosture("python", :External)
	? MayExecute("python")
	#--> 1
	? Why()
	#--> allowed: posture 'external' declared
}

The refusal says why: refused: 'python' has NO declared trust posture. An executor with no declared trust posture never proceeds.

And the twin can rehearse a spawn before it runs, flagged as a risk. Chapter 24 owns the twin, and one block here is enough to say what the door does not use:

StzVirtualEnvironmentQ() {
	Spawn("python analyse.py")
	? NumberOfPendingSpawns()
	#--> 1
	oPlan = GenerateUpdatePlan()
}
? oPlan.Narration()
#--> Update plan (1 of 1 operations to commit):
#-->   * 1. spawn process: python analyse.py
? @@( oPlan.Risks() )
#--> [ [ 1, "RUNS an external command (side effects): spawn process: python analyse.py" ] ]

Nothing is run there, and the plan flags the spawn: RUNS an external command (side effects): spawn process: python analyse.py. The script named does not exist.

Next, what I decided about the door, and what I refused.

5. The court

51_extercode_narrated proves that the registry knows Python, R, Julia, Prolog, C and NodeJS, and rejects an unknown name. It proves that the lookup ignores case (tested for Python); that the code set is the code read back; and that the factory constructs and forwards. The smoke test it narrates says in its header: no Execute, by its own guardrail. governance_narrated, scene six, proves that an execution without a posture refuses and that a declared posture proceeds and names itself; scene seven, that postures travel through save and load. virtual_environment_twin_narrated proves that a queued spawn does not run until commit, by a marker file; that a scope refuses; and that the plan narrates and flags the spawn. pycodegraph_narrated and jscodegraph_narrated prove classes, methods, inheritance chains, owners, impact and cascade over Python and over JavaScript sources, offline and without the runtime. Both skip their parser scenarios when the engine's tree-sitter is absent, and the first also skips its Python-AST ones when Python is not on the path.

I want to be exact about the court of the door. A guard that runs a foreign runtime and passes is absent from the snapshot; what the door's court holds today is a registry and a construction test. The folder's own run record, under an older runtime version, lists thirty-seven failures. Several promises cannot match by construction, because the file names carry a random suffix and the calls a duration.

The field comes next, and where it leads.

6. The field, and where it leads

The field leads in speed, and speed is what the door exists for. The article on performance measures seven runtimes on three tasks, and the host comes last in two of them. I carry its caveats, which chapter 22 states too: it has no versions and no dates inside its text, and it says that its times are relative to a specific computer environment. Sorting a million elements takes the host about thirty seconds and Python about four, in the article's table. I print no more of it.

The field leads in runtimes it can actually run. Of six doors, two ran on this machine, Node and Python; the R door started its runtime and raised; the other three had no runtime to start. The study says its description of the field's polyglot tools was written from the genre and not re-read, and I claim no measured comparison.

The field leads in the ecosystem and in being used. The compare page speaks of Python only as a rival; to cover its thirty rows in Python you assemble numpy, pandas and others. The door is how a Softanza solution takes them without leaving. I hold this as a view, not a result: section 3 shows the door carrying two runtimes in one pipeline, and nothing on this page runs numpy or pandas.

The court's reach stops today at the door: the foreign process is outside it, and chapter 21's threat model puts code already running in the process out of scope.

And the cost of a facet, in the memo's own table: a Python reader expects zero-based indexing, and Haro's is one-based. The literal \n is a backslash and an n; two letters of different case are one variable. "Any model writes Haro in the shape it knows" is true only of the spellings that are the minority.

7. The limit

• builta closed registry of six foreign runtimes and a process-based call that brings Python's and NodeJS's results home as lists; the trust postures; the twin's rehearsal of a spawn; a reader of Python and of JavaScript into one code graph
• designedthe door governed, with a posture asked at the call; the engine's bridge and its three tiers; the domain library on top of the door; Haro wearing a Python syntax and a JavaScript one
• absenta door whose way back is closed; a door for R that runs; a passing run of a foreign runtime in the library's own court; the AI model as a door

The word governed is a design. Does the door ask the governance before it runs? This is the block that shows it:

oGov2 = new stzGovernance("shop")
? oGov2.MayExecute("python")
#--> 0
oPy3 = new stzExterCode(:python)
oPy3 {
	SetRuntimePath(cPython)
	SetCode("res = 6 * 7")
	Execute()
	? Result()
	#--> 42
}

The governance said no, and the door ran anyway, and returned 42! Nothing in the door's folder mentions governance or posture. The door calls the system directly, and not the twin.

The way back is not yet closed. The result file is read by the host's own eval, and a string that comes out of the foreign runtime is wrapped in single quotes without escaping. Can a foreign string that carries a quote and a call reach host code? The function used here is upper, harmless on purpose:

oPy4 = new stzExterCode(:python)
oPy4.SetRuntimePath(cPython)
oPy4.SetCode(`
res = "x' + upper('y') + 'z"
`)
oPy4.Execute()
? oPy4.Result()
#--> xYz

The result file held 'x' + upper('y') + 'z', and Result() evaluated it. The data became a call, and the block printed xYz! A plain apostrophe in data, it's fine, writes a string the host cannot read, and the method prints the error and returns the raw text. It is the same class of open limit as chapter 11's list in a natural sentence. I did not test the other five languages' marshalling.

The R door is in development: today it raises on every call, because its generated script holds an identifier that begins with an underscore, which R rejects. I confirmed it with R on a one-line file. And the trace records an exit code of 0 for a call that failed. The code passes a literal 0 to the recorder, and failure is detected only by the absence of the result file:

oStat = new stzExterCode(:R)
oStat {
	SetCode("res <- c(1, 2, 3)")
	bRaised = 0
	try
		Execute()
	catch
		bRaised = 1
	done
	? bRaised
	#--> 1
	? CallTrace()[1][:exitcode]
	#--> 0
}

The call raised, and the trace still holds 0! R's message was in French on this machine, so I do not promise it. This is the limit of the door at this commit, in the voice of chapter 11's open list. The runs above are its evidence. Governing the door is designed and not yet built, so the vision's word "governed" stays a design. The way back is not yet closed, since data returns through a file that the host evaluates. And the R door, in development, raises on every call today.

What else is designed: the engine's own polyglot bridge, which the engine design marks as planned. A module of the same name in the macroplan, a string registry, was once marked done with no source. Then the three tiers for Python, of which only the external subprocess exists. Then the domain library on top of the door, none of whose classes I found in code. And the facets, a memo that proposes and rules nothing.

What is absent: the article's functions that bring data in, @@R, @@C, XC() and XAI(), which are defined in no file. Factories exist for Python, R, Julia and Prolog. The C and NodeJS doors are reached only by the class. The AI model is not a door of this plane at all; the article's function that runs it inside the host is the opposite of chapter 17's law, and the book does not teach it.

And a door shape I did not run: Julia, C and Prolog, for which no runtime is installed here. And a third relation, named in the study beside the door: the shim that pastes a solution found on the internet in another language and changes it a little. range0, Python's range as a host function, has a guard. The folder's own record lists for it five failures on ranges that should be empty and one on the slice form ':5:-1'. I ran none of it.

Six readings of the door follow, one for each person who meets it.

8. Six doors

9. Exercise

You are building a small solution with three jobs: sorting a million numbers, deciding which of two students passes, and checking a family tree for who is an ancestor of whom. For each job, choose the language from the list of layers in section 3 that owns its layer, and write your reason in one line. Then, without running anything, write the promise for each line of this block, and run it:

oDoor = new stzExterCode(:python)
# promise: the door answers "julia" with ...
# promise: the door answers "ring" with ...
# promise: asking for "cobol" raises with the sentence ...
oGov = new stzGovernance("mine")
# promise: oGov.MayExecute("prolog") before any posture is declared gives ...
# promise: after oGov.DeclarePosture("prolog", :External), it gives ...

The last promise is the one that matters. If you now call the door for Prolog, will the governance have been asked? Write yes or no, and why. Then read section 7. If a promise breaks, do not change it: explain the output first.

I left this one in your hands. Section 7 says that a plain apostrophe in data makes the way back write a string the host cannot read, and I printed no output for it. Here is the block of section 7 with one change, it's fine as the foreign string:

oPy4 = new stzExterCode(:python)
oPy4.SetRuntimePath(cPython)
oPy4.SetCode(`
res = "it's fine"
`)
oPy4.Execute()
? oPy4.Result()

Run it. Read what the method prints and what it returns, and explain both before you touch the block; the page says why in section 7, where the way back is not closed. When you can, you will know why a way back that evaluates its data is not a closed one.

Chapter 17 opens the part on intelligence with its law: programmatic by default, the model last, admission over generation. An AI model there is one faculty among others, the last one called, and what it says is a proposal that the court admits or refuses.

Law: programmatic by default, the model last, admission over generation

Run on 2026-10-15 12:59 UTC+01:00 inside the library at commit 93d7a39bd: 8 of 8 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I state the law of Part IV and run it. I begin with my definition of intelligence and a domain language model with no neurons at all, which answers, says why, and refuses what it was never told. Then I show a conversation that asks you, a fact nobody recorded proved from one declared law, an AI model held to proposing, and an agent whose mind is code, refused at the gate. I say what I refused, which guards prove each block, and where the field leads. Then comes the limit, printed as the stage it is: a question asked in other words, answered where a refusal is the next step. The law itself is one sentence: the mind is programmatic by default, a model is one faculty among others, the last one called, and what it says is a proposal that the court admits or refuses.

What the AI age changes here

In the two movements before this one, the AI age changed one thing each. In programming, it changed who writes the code. In languages, it changed who speaks the sentence. Here it changes everything, because this movement is about intelligence itself, and the field now mostly uses the word to mean one thing: a large language model inside your software.

So this chapter does what the other two law chapters do, and states the law of its part before the evidence. It also says how the part depends on the others, because the order of this book runs from the familiar to the new. Intelligence, in Softanza, is governed by what came before it. The court that judges a model's sentence is the court of Part II, which judges code whoever wrote it. The sentence it judges is a sentence of a closed language, which is Part III. A model can only be put last because there is something solid to put first.

1. The concept, as the field holds it

Ask the field what makes an application intelligent and the answer is an AI model. An AI agent, in the field's sense, is a model in a loop with tools, a memory and a goal. The shopping list for building one in 2026 is long. It takes a project in Python, a model provider, a framework that wires the loop as a graph, a store of vectors for memory, tools with typed schemas, a tracing service, and a chapter of safety advice. Memory is often retrieval: a collection of documents, cut into pieces, searched by similarity and pasted into the prompt.

Safety, in that picture, is a property of the agent. It is alignment, guardrails, a prompt that asks for confirmation, a box marked "human in the loop". The field has also learned to hold a model's output to a shape, with grammars that constrain what it may emit. All of this is serious work, and some of it is good. It shares one assumption: the model is the mind, and everything else is around it.

2. The first principle

The mind is programmatic by default; a model is one faculty among others, the last one called, and what it says is a proposal that the court admits or refuses.

3. The Softanza form

Begin with my definition, because everything here follows from it. Intelligence is the computational ability to derive new knowledge from existing knowledge. Nothing in that sentence needs a model.

Here is a domain language model with no neurons at all, forged from a small knowledge graph of a restaurant. What does it answer from what was recorded, and what does it say about the 1998 world cup? Run it:

oKB = new stzKnowledgeGraph("restaurant")
oKB {
	Know("margherita", "dish")
	KnowRelation("margherita", "contains", "tomato-sauce")
	KnowRelation("margherita", "contains", "mozzarella")
}
oDLM = StzDlmQ(oKB)
oDLM {
	? Ask("margherita contains what?")
	#--> Margherita contains tomato-sauce and mozzarella.
	? Why()
	#--> recorded fact(s): 'margherita' contains tomato-sauce, mozzarella
	? AskXT("margherita contains what?")[:certainty]
	#--> 1
	? Ask("who won the 1998 world cup?")
	#--> That is outside the 'restaurant' domain (I know 1 entities and 1 relations).
}

It answers, says why (recorded fact(s): 'margherita' contains tomato-sauce, mozzarella), and states its certainty (1). And when it is asked something it does not know, it does not guess. It refuses, and it tells you how small its world is: I know 1 entities and 1 relations. One entity, because only margherita was declared with Know, and one relation, contains: the objects of the two facts are not counted as entities. A refusal that names its boundary is worth more than a fluent answer that has none. This is my view.

Now the second piece, the one that turns the usual dialogue around. In the field, you prompt the machine and keep what comes out. Here the system asks you. What does it ask, and what happens if you try to conclude before you have answered?

StzKnowledgeGraphQ("menu") {
	Know("margherita", "dish")
	Know("tiramisu", "dish")
	AddConversationQ("setup").SetGoal(StzGoalQ().RequireEach("dish", "contains"))
	? AskIn("setup")
	#--> What does 'margherita' have for 'contains'?  (why: every dish needs 'contains')
	try
		ConcludeIn("setup", "menu")
	catch
		? cCatchError
	done
	#--> Can't conclude: 2 gap(s) remain -- the wise-coding loop is not done. Ask the next question.
}

A goal was declared: every dish must say what it contains. The gap between the goal and what is known generated the question, and the question carries its reason. The world cannot be closed while it is incomplete: Can't conclude: 2 gap(s) remain. Chapter 18 shows the five ways you may answer: an option from a list, a data structure, a formula, a sentence, or examples. Three are wired; the formula and the examples are absent. An AI model, where there is one, comes after all of them, not first.

The third piece is derivation, my definition at work. One law is declared, and a fact nobody recorded is proved:

StzKnowledgeGraphQ("kitchen") {
	ConstrainRelation("contains", :Transitive)
	KnowRelation("margherita", "contains", "tomato-sauce").
	    KnowRelation("tomato-sauce", "contains", "tomato")
	? Prove([ "margherita", "contains", "tomato" ])[:narration]
	#--> proved: margherita contains tomato-sauce contains tomato
	? Prove([ "margherita", "contains", "luigi" ])[:narration]
	#--> not derivable: no recorded fact or lawful chain gives 'margherita' contains 'luigi'
}

New knowledge from existing knowledge, with its chain written out! And a "no" that is as certain as the "yes", because it is the result of a search, not of a mood. The page printed it as not derivable: no recorded fact or lawful chain gives 'margherita' contains 'luigi'. It is certain about what is recorded and declared, not about the world: it says not derivable, not "false". No retrieval, no training. Adding a fact makes the system know more; adding a law makes it reason further.

Then the AI model. It is welcome, and it is held. Wire a model's output straight to an effect, here sending a message. Is the composition sound?

oG = new stzAgentGraph("mailer")
oG {
	AddLLMActor("writer")
	AddEffect("send")
	Proposes("writer", "send")
	? IsSound()
	#--> 0
	? len(Violations())
	#--> 3
}

It is not: IsSound() printed 0, and it is refused before anything runs! Three laws fire, and len(Violations()) printed 3: every effect must pass a gate, open text must have somewhere safe to land, and every effect must leave a witness. What does a model actor hold that can act? No AI model is loaded in the block that asks: the answer is seeded, the way a test fixes a golden answer, so that the page runs the same on every night. Ask one:

oF = new stzLLMFunction("sum")
oF {
	SetPrompt("summarize: {input}")
	Budget(2)
	SeedAnswer("hello world", "a greeting")
}
oLLM = new stzLLMAgent("summarizer")
oLLM {
	SetSkillFrom(oF)
	? Propose("hello world")
	#--> a greeting
	? HoldsEffectful()
	#--> 0
}

Nothing. A model actor holds no effectful capability at all; it proposes, and that is the whole of its power. HoldsEffectful() printed 0. What the block proves does not depend on the model: whatever it says, it holds nothing that can act.

And the programmatic agent itself has a mind made of code. A skill is a condition and an action, and it fires on what the agent perceives. Governance gates the act before it happens. When the stock is low and the skill wants to order, does the act go through?

oRog = new stzPIAgent("rogue-bot")
oRog.MemoryQ().Learn("stock", "level", "low")
oRog.GovernanceQ().DeclareRisk("order-stock", 2)
oSk = new stzAgentSkill("restock")
oSk.SetWhen(func oM { return oM.Fact("stock", "level", "low") })
oSk.SetDoes(func oM { oM.Learn("stock", "level", "ordered")  return 1 })
oRog.AddGovernedSkill(oSk, "order-stock")
? oRog.Pursue()
#--> 0
? oRog.DecisionLog()[1][:why]
#--> refused: 'rogue-bot' lacks PERMISSION (can) for 'order-stock'

The stock is low, the skill wants to order, and the agent was never given the permission. Pursue() printed 0: governance refused it! Nothing happens, and the log says why, by name: refused: 'rogue-bot' lacks PERMISSION (can) for 'order-stock'. The world is as it was.

Put the pieces in a line and you have the stack the vision of the platform names as its North Star, ratified on 27 September 2026: perceive, decide, react, learn. None of it needs a language model. It is a design, not an assembled agent. In it, perception classifies the world into the knowledge graph. A planner decides. Rules react. The agent scores its plans and keeps the best. The pieces exist in the library beside the agent, not yet inside it: the agent above calls none of them. A model may sit beside each step as one more faculty, and none of them depends on it.

Chapter 18 tells the five registers of an answer and the conversation that asks. Chapter 19 tells the domain language model, from its first rung, with no neurons, to its second, trained on the first one's own facts and nothing else. Chapter 20 tells the agent that cannot hurt you: it proposes, a workbench rehearses, the court judges, and only a governed actor commits. Chapter 21 tells the court itself. Chapter 22 compares all of it with the field, and prints where the field leads.

5. The court

Each block above stands on a guard. dlm_narrated proves the domain language model: answers with their why, refusal outside the domain, completion held to the domain's entities and relations, a self-contained bundle, and a second rung trained on its own corpus. wisecoding_narrated proves the conversation that asks and the refusal to conclude. knowledge_integration_narrated proves derivation and the certain "no". agentgraph_narrated proves that a model straight to an effect is not sound, that the governed shape is, and that a model actor proposes and never commits. piagent_narrated proves the programmatic agent and its refusal at the gate. ownagentstack_narrated proves the honest roster of the library's own agents.

These six guards prove what ran; the next section says where the field leads.

6. The field, and where it leads

The field leads in reach. Its frameworks connect to hosted services of every kind, its stores search open collections of documents, and its loops call the largest models available for each step. Softanza's inversion, curate a domain and derive from it, leads on a curated domain, and on the open web the field leads today. When the task is open-ended language work over material nobody can curate, summarising arbitrary documents or research over the web, the field's stack is the right tool. The record says so in those words.

The field leads in the market. There is a labour market for its stack today; the one for this stack is still to come.

The field leads in AI models. The second rung of the domain language model, as built, is a small neural model of word pairs, and the foundry beyond the bigram is designed (chapter 19). Softanza does not build the large generators and does not compete with them.

Where I think the law stands apart is in three places. A decision here costs nothing, runs offline and gives the same answer every day, so it can be tested with ordinary promises. An AI model here cannot act, by construction, not by vigilance. And a model's sentence, where one is used, can be held to the grammar of a declared language before it is emitted, instead of being checked and retried after.

The next section says where the law stops.

7. The limit

• builtthe domain language model's first rung and its second, a small bigram; the conversation that asks; derivation with its proof; the programmatic agent; the gate that refuses an ungoverned AI model
• designedthe thinking machine's cascade across faculties; the decision stack, its pieces beside the agent and not yet inside it; the typed unit of prediction, a design of the estate's with five validation stages and no chain of them in the library; the negotiation between an agent and its reviewer
• absentfour of the library's five own agents, induction from examples among them

What is built: the domain language model's first rung and its second, a small bigram, the conversation that asks, derivation with its proof, the programmatic agent, and the gate that refuses an ungoverned composition.

What is designed: the thinking machine of chapter 9, where many faculties share one state and cascade until it settles. The decision stack of perceive, decide, react and learn, whose pieces exist beside the agent and not yet inside it. The typed unit of prediction, which chapter 19 tells as a design of the estate's, validated in five stages in that design and chained nowhere in the library. The conversation between an agent and the one who reviews its plan: the plan now reaches the agent, and the conversation about the plan does not yet.

What is absent: four of the library's five own agents. How many does the library declare, and how many are wired? The roster says it plainly:

? len(StzOwnAgents())
#--> 5
? StzOwnAgentIsWired("wise-coder")
#--> 1
? StzOwnAgentIsWired("induction")
#--> 0

The validator, the ranker, the planner and the agent that would induce a pattern from your examples are declared and reserved. So the fifth register of an answer, examples, waits on an agent that does not exist yet.

And one limit of the first rung that you will meet the moment you rephrase a question. It recognises a relation only by the word it was declared with. What does it do when you ask in other words?

? oDLM.Ask("what does margherita contain?")
#--> Margherita is a dish.

It did not refuse! It printed Margherita is a dish. That answer is true, and it is not what was asked. By the law of this chapter, the answer here is a refusal, and that refusal is the next step. I print it here because a law is shown by a page that prints its stage as it stands, limit included. The request to the library is to refuse a question whose verb is not a declared relation.

8. Six doors

Now the exercise: your own domain, and the promises you expect.

9. Exercise

Build a domain of your own with three facts: a shop, a clinic, a class. Before you run anything, write under each line the promise you expect: one question inside the domain, one outside it. Add a goal that every item must have one relation, and write the first question the system will ask you. Then run it.

If a promise is broken, do not change the promise to match the output. Explain the output first.

I left this one in your hands, on purpose. Section 7 shows a question that the first rung answered when the law says it should have refused, and I did not fix it. Take your own domain and ask one of your promised questions again in other words, with a verb you did not declare as a relation. Look at what comes back and compare it with what you asked. Then say in one sentence why it answered, and which lines of section 7 tell you so.

When you have solved it, you will know why a first rung that recognises a relation only by the word it was declared with can answer a question you did not ask.

Chapter 18 is The five registers, and conversations that ask. Its principle: a reply may come in any of five forms, and whatever the form, it is only a candidate, and the world's rules decide whether it becomes knowledge.

The five registers, and conversations that ask

Run on 2026-10-15 12:59 UTC+01:00 inside the library at commit 93d7a39bd: 15 of 15 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I show you the five forms a reply can take, an option, a data structure, a formula, a sentence and examples. Then I show what the governed door does with each of them. I tell you which three run and which two do not, and what becomes of a refusal once it is written: it waits for a person, with its context and a lifetime. I let the conversation with no one in it run, and I show what a conversation can and cannot do in Arabic and in Hausa. Whatever the form, a reply is only a candidate, and the world's rules decide whether it becomes knowledge.

1. The concept, as the field holds it

Two practices meet in the idea of a conversation that asks, and a third stands behind its last register. This whole section is general knowledge, not a study of the record.

The first is slot filling. A dialogue framework asks the user for the missing pieces of a form until the form is full. The frameworks of the field understand free text with trained models, speak on many channels and ship connectors, and they ask the designer to write intents and flows in their own language. They take the user's reply as the answer and act on it.

The second is vibe coding, a name put into circulation in 2025: the human prompts, the AI model produces, the human keeps what runs.

The third is programming by example. Spreadsheets fill a column from two examples you typed. Research calls it inductive synthesis, and the model era made the example the way one steers a model.

2. The first principle

A reply may come in any of five forms. Whatever the form, it is only a candidate, and the world's rules decide whether it becomes knowledge.

The design document says it in one sentence I keep: expression is free, admission is governed. The record holds this sentence, captured from my directive of 13 July 2026. It holds no sentence of mine on why these five registers and not four or six, nor on the moment I set wise coding against vibe coding.

3. The Softanza form

Chapter 17 showed a conversation asking, and refusing to conclude while a gap is open. This chapter is about the answer. The five registers are five forms a reply can take: an option picked by its number, a data structure, a formula, a sentence, and examples. I will show you each, and I will tell you the ones that do not run.

The first register: an option. When the world already knows values, how does the question offer them? Run it:

oKB = new stzKnowledgeGraph("pizzeria")
oKB {
	Know("pizza1", "dish")
	Know("pizza2", "dish")
	Know("pizza3", "dish")
	Know("pizza4", "dish")
	AddConversationQ("frame").SetGoal(StzGoalQ().RequireEach("dish", "topping"))
	AskIn("frame")
	ReplyIn("frame", "cheese")
	AskIn("frame")
	ReplyIn("frame", "olives")
	? AskIn("frame")
	#--> Which 'topping' does 'pizza3' have? (1) cheese  (2) olives -- or answer freely.  (why: every dish needs 'topping')
	? @@(ReplyIn("frame", 2)[:admitted])
	#--> [ "olives" ]
}

The question offers the known values as numbers, and 2 picked olives.

What does the door answer to a number nobody offered? Run it:

oKB {
	? AskIn("frame")
	#--> Which 'topping' does 'pizza4' have? (1) cheese  (2) olives -- or answer freely.  (why: every dish needs 'topping')
	aV = ReplyIn("frame", 99)
	? @@(aV[:admitted])
	#--> [ ]
	? @@(aV[:refused])
	#--> [ [ "(99)", "no such option" ] ]
	? ConversationQ("frame").Checkpoints()[1][:why]
	#--> no option (99) was offered -- 2 option(s) on the table
	? aV[:goalState]
	#--> pursuing
}

The door refused it, and said no such option! The checkpoint says why: no option (99) was offered -- 2 option(s) on the table. A reason, and a count of the options on the table. It does not list them, and the next question offers the same options again: (1) cheese (2) olives. The refusal never guesses a value, it reaches a person as a checkpoint, and the goal stays pursuing. That matters for section 7.

The question is data before it is text. It carries a force, which is what while the world knows nothing and which once it knows a value, and the options. Any medium can render it:

oKF = new stzKnowledgeGraph("pizzeria2")
oKF {
	Know("p1", "dish")
	Know("p2", "dish")
	AddConversationQ("f").SetGoal(StzGoalQ().RequireEach("dish", "topping"))
	? AskInXT("f")[:force]
	#--> what
	ReplyIn("f", "cheese")
	aQ = AskInXT("f")
	? aQ[:force]
	#--> which
	? @@(aQ[:options])
	#--> [ "cheese" ]
}

The second register: a data structure. What becomes of a list of two values sent as one reply? Run it:

oKD = new stzKnowledgeGraph("desserts")
oKD {
	Know("tiramisu", "dish")
	AddConversationQ("setup").SetGoal(StzGoalQ().RequireEach("dish", "contains"))
	AskIn("setup")
	aV = ReplyIn("setup", [ "mascarpone", "espresso" ])
	? @@(aV[:admitted])
	#--> [ "mascarpone", "espresso" ]
	? aV[:goalState]
	#--> fulfilled
}

A list of values is taken as the values, and each one goes through the same door.

The fourth register: a sentence. I skip the third for a moment, because it is one of the two that do not run. How is a phrase of the form "X and Y" or "X, Y" read? The conversation keeps a transcript in which every admission is narrated and the fulfilment of the goal is recorded:

oKM = new stzKnowledgeGraph("menu")
oKM {
	Know("margherita", "dish")
	AddConversationQ("setup").SetGoal(StzGoalQ().RequireEach("dish", "contains"))
	AskIn("setup")
	ReplyIn("setup", "tomato-sauce and mozzarella")
	? ConversationQ("setup").Transcript()
	#--> SOFTANZA: Goal adopted -- this conversation is now accountable for it.
	#--> SOFTANZA: What does 'margherita' have for 'contains'?  (why: every dish needs 'contains')
	#--> YOU:      tomato-sauce and mozzarella
	#-->   -> admitted: 'margherita' contains 'tomato-sauce'
	#-->   -> admitted: 'margherita' contains 'mozzarella'
	#--> SOFTANZA: Goal fulfilled: every required slot is filled in 'menu'
}

It is read as two values, each one judged: the transcript holds admitted: 'margherita' contains 'tomato-sauce' and admitted: 'margherita' contains 'mozzarella'. "Natural" here means a splitter on commas and on the English word "and". The natural layer of the library, which I will use in a moment, is not called by the conversation.

When a reply carries several values, and the world allows one. What does a relation declared unique do with a reply that carries two values? Run it:

oKS = new stzKnowledgeGraph("staffing")
oKS {
	AddConversationQ("s").SetGoal(StzGoalQ().RequireOne("kitchen3", "led-by"))
	ConstrainRelation("led-by", :Unique)
	AskIn("s")
	aV = ReplyIn("s", "mario and giovanni")
	? @@(aV[:admitted])
	#--> [ "mario" ]
	? @@(aV[:refused])
	#--> [ [ "giovanni", "'kitchen3' already bears 'led-by' (to 'mario'); the relation is :Unique" ] ]
	? len(ConversationQ("s").Checkpoints())
	#--> 1
}

The first value was admitted, and the second was refused with the law's reason: 'kitchen3' already bears 'led-by' (to 'mario'); the relation is :Unique. The refusal reaches a person, as one checkpoint. Be careful what you read in this. The choice between Mario and Giovanni was made by order. It was not made by a person. The design promises something else, and section 7 says what.

The third register, the formula. Is a formula typed as a reply evaluated? Run it:

oKP = new stzKnowledgeGraph("shop")
oKP {
	Know("tea", "product")
	AddConversationQ("price").SetGoal(StzGoalQ().RequireEach("product", "price"))
	AskIn("price")
	? @@(ReplyIn("price", "=12*3")[:admitted])
	#--> [ "=12*3" ]
	? Query([ "tea", "price", "?o" ])[1]
	#--> =12*3
}

It is not. The price of the tea is now the text =12*3! I found this out by running it, and the code is silent about a formula register. The record lists the wise-coding work on registers 3 and 5 as waiting, not routed.

The fifth register, examples. What does the door do with examples offered as pairs? The agent that would read them is on the roster, and reserved:

oKX = new stzKnowledgeGraph("phones")
oKX {
	Know("contact1", "contact")
	AddConversationQ("fmt").SetGoal(StzGoalQ().RequireEach("contact", "number-pattern"))
	AskIn("fmt")
	aV = ReplyIn("fmt", [ [ "+216-21-298-374", "valid" ], [ "+33-6-12-34-56-78", "valid" ] ])
	? @@(aV[:admitted])
	#--> [ ]
	? @@(aV[:refused])
	#--> [ ]
	? aV[:goalState]
	#--> pursuing
	? len(ConversationQ("fmt").Checkpoints())
	#--> 0
}
try
	StzOwnAgent("induction")
catch
	? cCatchError
done
#--> Softanza's own agent 'induction' is RESERVED, not wired yet -- refusing rather than returning a stub (LAW 3). See StzOwnAgents().

Neither admitted nor refused: [ ] and [ ], the goal still pursuing, and not one checkpoint! This is not the refusal the protocol describes. It is silence. I hold silence to be the worse answer, as a view and not a result: the reader who offered the examples is not told they were not understood. I found a second form of the same fault, with the same examples typed as one string, joined by a comma. The exercise at the end of this chapter hands it to you.

So three of the five registers are wired, one of them in its simplest form, a splitter. Two are not. I would rather you meet that here than on a page of mine that said five.

That leaves the refusal itself, and what becomes of it.

What happens to a refusal

A refusal waits for a person, with its context. A lifetime can be set so that a stale one leaves the live list without being deleted:

oKT = new stzKnowledgeGraph("ttl")
oKT {
	AddConversationQ("t").SetGoal(StzGoalQ().RequireOne("kitchen", "led-by"))
	AskIn("t")
	ReplyIn("t", 7)
	? len(ConversationQ("t").Checkpoints())
	#--> 1
	ConversationQ("t").SetCheckpointTTL(1)
	AskIn("t")
	AskIn("t")
	? len(ConversationQ("t").Checkpoints())
	#--> 0
	? len(ConversationQ("t").AllCheckpoints())
	#--> 1
}

Nothing is deleted. Expiry is about what still needs a person, and the audit record keeps all of it. Every call here is chained from ConversationQ, because a held copy would silently do nothing: the guard's comment explains it.

A conversation is accountable for one goal, and it ends by fulfilling the goal or by revoking it on the record. A revoked conversation asks nothing and cannot conclude:

oKG = new stzKnowledgeGraph("lifecycle")
oKG {
	Know("d1", "dish")
	Know("d2", "dish")
	AddConversationQ("s1").SetGoal(StzGoalQ().RequireEach("dish", "sauce"))
	AddConversationQ("s2").SetGoal(StzGoalQ().RequireEach("dish", "garnish"))
	? ConversationQ("s1").GoalState()
	#--> pursuing
	AskIn("s1")
	ReplyIn("s1", "pesto")
	AskIn("s1")
	ReplyIn("s1", "pesto")
	? ConversationQ("s1").GoalState()
	#--> fulfilled
	? ConversationQ("s1").GoalWhy()
	#--> every required slot is filled in 'lifecycle'
	AskIn("s2")
	ConversationQ("s2").RevokeGoal("out of scope tonight")
	? ConversationQ("s2").GoalState()
	#--> revoked
	? ConversationQ("s2").GoalWhy()
	#--> out of scope tonight
	? len(OpenConversations())
	#--> 0
}

Programmatic by default: the conversation with no one in it

Chapter 17's law says conversations happen in code first. Here is the conversation with no person and no model. An AI agent of the library asks, an answer source (a plain function) replies, and every reply passes the same door. Where the source has no answer, does the agent invent? Run it:

oKW = new stzKnowledgeGraph("menu")
oKW.Know("margherita", "dish")
oKW.Know("tiramisu", "dish")
answers = [ [ "margherita", "tomato-sauce" ], [ "tiramisu", "mascarpone" ] ]
aR = StzOwnAgent("wise-coder").PursueGoal(StzGoalQ().RequireEach("dish", "contains"), oKW, func subj, rel {
	for a in answers
		if a[1] = subj
			return a[2]
		ok
	next
	return ""
})
? aR[:filled]
#--> 1
? aR[:asked]
#--> 2
? aR[:why]
#--> goal filled in 2 question(s), governed admission throughout
oKV = new stzKnowledgeGraph("desserts")
oKV.Know("panna-cotta", "dish")
aR2 = StzOwnAgent("wise-coder").PursueGoal(StzGoalQ().RequireEach("dish", "contains"), oKV, func subj, rel { return "" })
? aR2[:filled]
#--> 0
? aR2[:why]
#--> stopped: no answer for 'panna-cotta' / 'contains' -- gap left for a human

It does not. It stops, says stopped: no answer for 'panna-cotta' / 'contains' -- gap left for a human, and leaves the gap for a person. Of the library's five own agents, this is the one that is wired. The other four are reserved, and asking for one raises, as the fifth register's block printed: RESERVED, not wired yet -- refusing rather than returning a stub. It is never a stub.

In Arabic, and in Hausa

Chapters 2 and 11 showed the natural layer in Hausa. Here is what the conversation can and cannot do with languages, said in three blocks, because the three are different.

First, the data. Names, values and lists in Arabic script pass the gate exactly as Latin ones do. The words around them, the frame of the question, stay English:

oKA = new stzKnowledgeGraph("مطعم")
oKA {
	Know("بيتزا", "dish")
	AddConversationQ("c").SetGoal(StzGoalQ().RequireEach("dish", "contains"))
	? AskIn("c")
	#--> What does 'بيتزا' have for 'contains'?  (why: every dish needs 'contains')
	aV = ReplyIn("c", [ "جبن", "طماطم" ])
	? @@(aV[:admitted])
	#--> [ "جبن", "طماطم" ]
	? aV[:goalState]
	#--> fulfilled
}

The Arabic values passed the gate, and the goal reads fulfilled.

Second, the candidate. A Hausa sentence can produce a value in the natural layer, and the value, sent as a reply, goes through the same door. The two steps are the caller's: the conversation does not call the natural layer itself. This is the principle of the chapter in a small space, since the expression is free and the admission is governed. The graph folds the case of the value, so the printed JIBINI is admitted as 'jibini':

oKH = new stzKnowledgeGraph("menu")
oKH {
	Know("pizza", "dish")
	AddConversationQ("c").SetGoal(StzGoalQ().RequireEach("dish", "contains"))
	AskIn("c")
}
cCandidate = NaturallyIn("ha", "Yi rubutu dauke 'jibini' Maida shi").Result()
? cCandidate
#--> JIBINI
aV = oKH.ReplyIn("c", cCandidate)
? aV[:narration]
#--> admitted: 'pizza' contains 'jibini'

Third, the question in the learner's language. The tutor is a consumer of the conversation: it uses the gap the conversation names, and it chooses the words to say it in four languages. The sentences are templates. The code's own comment says that the French, Arabic and Hausa wording is a draft awaiting a native reviewer. Read the three below as drafts, and not as reviewed text:

oEx = StzProgramQ("../../education/program").CourseQ("elementary-introduction").ExerciseQ("ex-01-01")
oEx {
	? GapText("finds", "en")
	#--> Where are the repeated items? Which line of your program asks for their positions? (why: the mental model finds before it applies)
	? GapText("finds", "fr")
	#--> Où sont les éléments répétés ? Quelle ligne de votre programme demande leurs positions ? (pourquoi : le modèle mental trouve avant d'agir)
	? GapText("finds", "ar")
	#--> أين العناصر المكررة؟ أيّ سطر في برنامجك يسأل عن مواضعها؟ (لماذا: النموذج الذهني يبحث قبل أن يطبّق)
	? GapText("finds", "ha")
	#--> Ina abubuwan da aka maimaita? Wane layi a shirinka yake tambayar wurarensu? (dalili: tsarin tunani yana nemo kafin ya aiwatar)
}

So the library cannot ask in Arabic or in Hausa through AskIn. What it can do is hold the data in any script, take a candidate computed in any pack, and let the tutor say the gap in four languages. A value with a space in it raises at the moment (section 7 gives the evidence). And the splitter knows the comma and the English word "and" only: the connectors "et" in French, "da" in Hausa and "و" in Arabic are not connectors. The three sentences above are the library's own, printed as they stand, and the code calls them a draft awaiting a native reviewer. I wrote no Arabic or Hausa sentence of my own.

An AI model is a fluency, never the mind

Without a model, what does a conversation say of its own fluency? Run it:

oKF2 = new stzKnowledgeGraph("fluency-space")
oKF2 {
	AddConversation("f")
	? ConversationQ("f").Fluency()
	#--> plain
	ConversationQ("f").SetFluency(:neural)
	? ConversationQ("f").Fluency()
	#--> neural
	? ConversationQ("f").IsFluencyNeural()
	#--> 0
}

plain: it stays on its deterministic floor and says so. The word "neural" can be set, and Fluency() repeats it, but IsFluencyNeural() answers 0! The word is claimed only when a model is there.

5. The court

wisecoding_narrated proves that the gap is computed from the space, and that the question is led by the system, names its subject and says why it asks. It proves that "X and Y" and a data structure admit. It proves that a unique law refuses through the conversation and the refusal reaches a checkpoint. It proves that concluding with a gap open is refused. wisecoding_rich_narrated proves the goal monitored to fulfilled or revoked, the frame, and the numbered options. It proves the refusal of a number nobody offered, the lifetime of a checkpoint, and the fluency that is claimed only with a model. ownagentstack_narrated proves the roster of five, the wired wise coder, the reserved agent that raises, and the gap left for a person. tutor_gaps_narrated proves the exercise's gap question in each language, and that a step with no question in a language is red, never another language. It writes folders, so the book counts it and does not run it; the tutor block above only reads the course.

Three of the guards print their own total and end by calling pf(), which prints the time and the runtime's version and then stops the run with a raise. That is their way to end. tutor_gaps_narrated ends with Summary(), which prints the total and a status, and does not raise.

What the field does better, and where the record stands apart, comes next.

6. The field, and where it leads

The field leads in understanding. A dialogue framework, as the field holds it, reads free text with trained models, speaks on many channels and ships connectors. The record says what Softanza lacks, in its own count: the word "WhatsApp" appears in no code file and no design document of the library. The conversation asks one slot at a time, over a graph the user must first have declared, and it does not understand an open reply.

The field leads on examples. Programming by example is, as the field holds it, shipped in spreadsheets today. Softanza has no induction at all, and the record says so: nothing induces yet. A search for "induce", "from examples" and "infer" over the regular-expression folder finds nothing.

The field is honest about costs, and so is the record. Several candidates is the normal case when you ask for a rule from examples. A pattern induced from three examples overfits them. The remedy the record names is the question that tells two candidates apart. And the index that would carry the examples is, in the study's words, as clean as the tags of the methods, in which the study counts about eighty-five misspellings.

Here is where I think the record stands apart. Every reply, in whatever form, is judged by the world's laws before it counts, with the reason. The session keeps a transcript and a checkpoint that a person can read. The field's reply is a prompt, and the human keeps what comes out.

The limit comes next, and it names what is built, what is designed and what is absent.

7. The limit

• builtthe goal, the gap and the question with its reason; a reply as an option, a data structure or a sentence split on commas and the word 'and'; the governed door with its refusals; the checkpoint with its lifetime; the goal fulfilled or revoked; one wired AI agent that stops where it would have to invent
• designedseveral readings of one reply, enumerated for the person to choose; the nearest alternatives named after a refusal; the example written back as a promise
• absentthe formula register; the example register; a conversation whose question is worded in Arabic, Hausa or French; a value with a space in it

What is built: the goal, the gap, the question with its reason, the frame; the first register, the second, and the fourth in the form of a splitter; the governed door with its refusals. And the checkpoint and its lifetime; the goal fulfilled or revoked; the transcript; one wired agent; the tutor's four-language gap sentence.

What is designed: the several acceptable branch as the design writes it. The protocol says that when several readings of a reply are acceptable, the system enumerates them and the person chooses. What is built is two different things. The values already known become numbered options in the question, before the reply. And a reply that carries several values has each one judged on its own, with the first kept under a unique law. No step presents competing readings of one reply. And the none acceptable branch as written: the reason is built, and the nearest acceptable alternatives are not. The refusal states a reason, and for a number, how many options were on the table. And the example written back as a promise: the site's page by example, read on 9 October 2026, calls it a rule of the design that is not built. The site's two pages on this, wise and by example, say "with the nearest alternatives" and "the person chooses". The two pages promise more than the code does. The code wires three of the five registers. The record names the formula and the examples as waiting, not routed, and for this chapter they are absent.

What is absent: the formula register; the example register, and the induction agent behind it; a conversation worded in Arabic, Hausa or French; and a value with a space in it. In my run of 8 October 2026, on the version of the library this book runs, ReplyIn raised on each value containing a space that I tried. The error was an uninitialised variable. The three were "tomato sauce", "fromage et tomate", "jibini da tumatir". Called directly, the door returned the refusal properly. No block of this book records either result, so the run of the book does not show them. The conversation should have refused with the reason and written a checkpoint, and it doesn't. It is a request to the library, and the exercise below does not use a value with a space.

8. Six doors

9. Exercise

Choose a small world of your own, a shop, a class, a clinic, with four entities of one type and a goal that each needs one relation. Before you run anything, write under each of the five replies below the verdict you expect: admitted, refused with a reason, or neither.

1. a plain word;
2. a number that picks a value the first reply made known;
3. a number nobody offered;
4. two values at once, for a relation you have declared unique;
5. a list of two pairs of examples.

Then run it. An admitted reply uses up the question, so call AskIn again before the next reply. If a promise breaks, do not change the promise: explain the output first.

oWorld = new stzKnowledgeGraph("my-world")
oWorld.Know("item1", "thing")
oWorld.Know("item2", "thing")
oWorld.AddConversationQ("mine").SetGoal(StzGoalQ().RequireEach("thing", "colour"))
oWorld.AskIn("mine")
# your five replies here, each with the verdict you expect

The fifth reply produces silence today, and that is the lesson of the exercise. If the library later turns it into a refusal, the expected answer changes. Run it on the date and commit shown at the foot of the page.

I left this one in your hands. Take the fifth-register block of section 3 and change one thing: send the two phone numbers as one string, joined by a comma, and not as two pairs.

oKX = new stzKnowledgeGraph("phones")
oKX.Know("contact1", "contact")
oKX.AddConversationQ("fmt").SetGoal(StzGoalQ().RequireEach("contact", "number-pattern"))
oKX.AskIn("fmt")
aV = oKX.ReplyIn("fmt", "+216-21-298-374,+33-6-12-34-56-78")
? @@(aV[:admitted])
? aV[:goalState]

Run it, then read what was admitted and what the goal says, and decide whether that is what you wanted to hand to the door as examples. Section 4, in its last refusal, and section 7, in the absent example register, say why I call it a fault. When you can say why, you will know what the door did with your examples, and why that is not induction.

This is what I call wise coding. The platform asks the question you have to answer, in the register you choose, and refuses to guess the answer for you: expression is free, admission is governed. Chapter 17 stated the law. This chapter ran its five registers, and showed where the fifth still falls silent.

The next chapter is about the domain language model. There the next thing the model says is a checkable unit of your world, a fact your rules admit or refuse, and never a token.

The domain language model

Run on 2026-10-15 12:59 UTC+01:00 inside the library at commit 93d7a39bd: 7 of 7 blocks kept their promise.

The blocks were run by the runtime of the former host language, version 1.27; Haro does not run the library yet. The engine binaries were built in a checkout of this commit, newest built 2026-10-05 20:27 UTC+01:00; 1 engine change(s) committed after that build are not in them.

In this chapter I forge a domain language model from a knowledge base, and no one writes its training text: every sentence is a recorded fact. It has two rungs. The first answers from those facts and has no neurons. The second, a small neural model, is fluent in the grammar of the domain and wrong about facts. I show the grammar that refuses a malformed sentence and the graph that refuses a false one. I say which pieces the library holds and which the reader still has to compose. The principle is this: the next thing the model says is a checkable unit of your world, a fact your rules admit or refuse, never a token.

1. The concept, as the field holds it

A language model predicts the next token. A token is a fragment of text with no type, no role and no constraint: it can be the end of a word, a space, a bracket. Everything a model says is built by choosing tokens one after another. Everything that makes the result useful, that it is a valid sentence, that it is true, that it fits a schema, is checked afterwards or enforced from outside.

The field has made this work with three tools. You adapt a general AI model to a domain by training it further on the domain's documents. You give it the relevant documents at the moment of the question, retrieved by similarity. And you constrain its decoding with a grammar, so that it cannot produce a malformed sentence, as chapter 11 showed. All three keep the unit the same: the token.

The next section names the one thing I change: the unit.

2. The first principle

The next thing the model says is a checkable unit of your world, a fact your rules admit or refuse, never a token.

In the design the gate is the same for every model of this kind: generations are proposals, and the graph and its rules decide admission.

Section 3 shows the form it takes, and runs it.

3. The Softanza form

I call it a domain language model, and it has two rungs. The first has no neurons at all and was shown in chapter 17: it answers from recorded facts, says why, and refuses outside its domain. The second is a small neural model, optional, which gives it fluency. In the design both rungs end at the same gate; here the gate is the Admit of the last block of this section, called by hand.

Where does the training text come from? Build a small knowledge base, render it, and read the corpus and the vocabulary it gives.

oKB = new stzKnowledgeGraph("restaurant")
oKB {
	Know("margherita", "dish")
	Know("tiramisu", "dish")
	Know("chianti", "wine")
	KnowRelation("margherita", "contains", "tomato-sauce")
	KnowRelation("margherita", "contains", "mozzarella")
	KnowRelation("margherita", "pairs-with", "chianti")
}
oDLM = StzDlmQ(oKB)
oDLM {
	? @@( GenerateCorpus() )
	#--> [ "margherita is a dish.", "tiramisu is a dish.", "chianti is a wine.", "margherita contains tomato-sauce.", "margherita contains mozzarella.", "margherita pairs-with chianti." ]
	? @@( Tokenizer() )
	#--> [ "<unk>", "margherita", "tiramisu", "chianti", "dish", "wine", "contains", "pairs-with", "is", "a", "tomato-sauce", "mozzarella" ]
	? @@( Tokenize("margherita contains something-new") )
	#--> [ 2, 7, 1 ]
}

No one wrote that corpus: each of its six sentences is a fact of the knowledge base, rendered. The vocabulary is closed, every word the domain holds with a first entry for the unknown. Twelve entries, and something-new, a word outside the domain, maps to the first one: [ 2, 7, 1 ]. "Correct by construction" holds here in the one sense the code gives it: each sentence is a recorded fact. It does not yet hold in the sense the design intended; section 7 says where.

Completion is constrained to the domain. What does the model offer after an entity that bears facts, after a relation, after a fragment, and after a word the domain does not hold? Run it:

oDLM {
	? @@( Complete("margherita") )
	#--> [ "contains", "pairs-with" ]
	? @@( Complete("contains") )
	#--> [ "tomato-sauce", "mozzarella" ]
	? @@( Complete("tira") )
	#--> [ "tiramisu" ]
	? @@( Complete("pizza") )
	#--> [ ]
}

After an entity that bears facts, its relations: [ "contains", "pairs-with" ]. After a relation, only its objects: [ "tomato-sauce", "mozzarella" ]. A fragment completes to entities, and a word that the domain does not hold completes to nothing: [ ]. The guard that proves this calls it "the grammar spirit". It is a lookup in the facts, not decoding under a compiled grammar. And it sees one word, not the sentence so far: Complete("contains") returns the objects of every contains fact, whatever its subject.

The grammar itself can be derived from the knowledge base, and here the reader of this book has to write the derivation. There is no call in the library that turns a knowledge base into a grammar, and the design lists it as the first rung's task. But the pieces compose. The domain's vocabulary becomes the choices of a schema from chapter 11, the schema compiles to a grammar, and the grammar has no path for a word outside the domain. The three rules it prints last, for text, number and boolean, are the ones the compiler always emits, and no field here uses them:

aLex = oDLM.Lexicon()
acObjects = []
for aFact in oKB.Facts()
	if aFact[2] != "is-a" and find(acObjects, aFact[3]) = 0
		acObjects + aFact[3]
	ok
next
oS = StzOutputSchemaQ([
	[ :field = "subject",  :type = :oneof, :choices = aLex[:entities] ],
	[ :field = "relation", :type = :oneof, :choices = aLex[:relations] ],
	[ :field = "object",   :type = :oneof, :choices = acObjects ]
])
? oS.ToGBNF()
#--> root ::= subject-line relation-line object-line
#    subject-line ::= "subject: " ("margherita" | "tiramisu" | "chianti") "\n"
#    relation-line ::= "relation: " ("contains" | "pairs-with") "\n"
#    object-line ::= "object: " ("tomato-sauce" | "mozzarella" | "chianti") "\n"
#    text ::= [^\n]+
#    number ::= "-"? [0-9]+ ("." [0-9]+)?
#    boolean ::= ("yes" | "no" | "true" | "false")
cGood = "subject: margherita" + nl + "relation: contains" + nl + "object: mozzarella" + nl
cOut  = "subject: pizza" + nl + "relation: contains" + nl + "object: mozzarella" + nl
cLie  = "subject: tiramisu" + nl + "relation: contains" + nl + "object: mozzarella" + nl
? oS.Accepts(cGood)
#--> 1
? oS.Accepts(cOut)
#--> 0
? oS.Accepts(cLie)
#--> 1
? oDLM.Ask("tiramisu contains what?")
#--> I hold no 'contains' knowledge about 'tiramisu'.

Look at the last four lines together. The grammar accepts the lie! It has the right shape, and every word is in the domain. Asked what a tiramisu contains, the model answers: I hold no 'contains' knowledge about 'tiramisu'. A grammar is a gate for shape; the truth belongs to the graph.

A domain language model is a file that travels. It is saved as plain text, readable and diff-able, with no binary and no weights. Can a second model that has never seen the knowledge base answer from it, and run its own tests? Save it, read it back, and load it:

oDLM {
	AddGolden("what is margherita", "Margherita is a dish.")
	AddGolden("what is the weather today?",
		"That is outside the 'restaurant' domain (I know 3 entities and 2 relations).")
	cFile = Save("probe_dlm")
}
? cFile
#--> probe_dlm.zdlm
? read(cFile)
#--> dlm "restaurant"
#    entities
#        margherita | dish
#        tiramisu | dish
#        chianti | wine
#    relations
#        contains
#        pairs-with
#    facts
#        margherita | contains | tomato-sauce
#        margherita | contains | mozzarella
#        margherita | pairs-with | chianti
#    laws
#    goldens
#        what is margherita | Margherita is a dish.
#        what is the weather today? | That is outside the 'restaurant' domain (I know 3 entities and 2 relations).
oShipped = StzDlmQ("")
oShipped {
	LoadFrom(cFile)
	? Ask("what is tiramisu")
	#--> Tiramisu is a dish.
	? @@( RunGoldens() )
	#--> [ [ "total", 2 ], [ "passed", 2 ], [ "failed", [ ] ] ]
}
remove(cFile)
? fexists(cFile)
#--> 0

The second model answers: Tiramisu is a dish. The refusal travels with the bundle as a golden test, and the model that has never seen the graph passes it too! The laws section is empty because no law was declared before the model was forged; declare that a relation is unique, forge again, and the line appears.

Now the second rung. It is a small neural model trained on the corpus you saw, with no teacher, and it can be exported as a model file. How small is it, and does it learn?

oDLM {
	TrainNeuralRung(500)
	? NeuralWhy()
	#--> neural bigram rung: 15 pairs over a 12-word vocab; trained 500 epoch(s), lr 0.50: loss 2.57 -> 0.70
	? NextToken("is")
	#--> a
	? NextTokenConfidence("is")
	#--> 1.00
	cGguf = ExportNeuralGguf("probe_bigram")
}
? cGguf
#--> probe_bigram.gguf
? StzEngineNeuralGgufInspect(cGguf)
#--> 2
remove(cGguf)

It is small: a single layer that predicts the next word from the previous one, 15 pairs over a 12-word vocab. And it learns: loss 2.57 -> 0.70. The library inspects the exported file and prints 2, the two tensors it holds, a weight and a bias. I do not claim another runtime loads it as a text generator. It trains in a fraction of a second, offline, and gives the same numbers on every run.

What does a neural model like this say? It is fluent in the grammar of the domain, and it is wrong about facts. That is the reason for the gate:

aCorpus = oDLM.GenerateCorpus()
for cSeed in [ "tiramisu", "chianti", "margherita" ]
	cSaid = oDLM.NeuralGenerate(cSeed, 3)
	? cSaid + "  ->  " + ( find(aCorpus, cSaid + ".") > 0 )
next
#--> tiramisu is a wine  ->  0
#    chianti is a wine  ->  1
#    margherita contains mozzarella is  ->  0

"Tiramisu is a wine" is false, because tiramisu is a dish. "Chianti is a wine" is true. And "margherita contains mozzarella is" is a run-on, because the bigram has no word that ends a sentence. The test against the corpus is a crude gate, and it would refuse a true fact nobody recorded. The real gate is the graph and its laws. What does the graph answer when the false sentence is proposed to it as a fact? Declare the law, then propose:

oKB {
	ConstrainRelation("is-a", :Unique)
	aVerdict = Admit("tiramisu", "is-a", "wine", [ :source = "rung 2" ])
	? aVerdict[:admitted]
	#--> 0
	? aVerdict[:why]
	#--> 'tiramisu' already bears 'is-a' (to 'dish'); the relation is :Unique
	? @@( Contradictions() )
	#--> [ [ [ "subject", "tiramisu" ], [ "relation", "is-a" ], [ "existing", "dish" ], [ "attempted", "wine" ], [ "source", "rung 2" ] ] ]
	? Admit("pizza", "is-a", "dish", [ :source = "rung 2" ])[:why]
	#--> admitted: 'pizza' is-a 'dish'
}