ZENREITechnologyBack to the overview

ZENREI :: 禅麗 t => t

Read it as: for any shape your work takes, as long as it holds together, ZENREI becomes it.

Why it doesn't break.

The AI proposes. A deterministic core, written in Haskell, decides. Nothing reaches your data unless the core has checked it against everything already there.

The loop

The AI never has the last word.

A language model is good at understanding what you mean. It is not allowed to decide what is true. Those are two different jobs, done by two different things.

  1. YouDescribe your work

    In your own words, exceptions included.

  2. AI proposesWrites in ZENREI-lang

    A program for your rules, plus examples of what should happen.

  3. Haskell decidesChecks the program

    Every field, every empty value, every undecided case. If something is missing, it says where and why.

  4. Haskell decidesRuns it on one engine

    A write is admitted, the rules apply, the invariants hold, then it commits. Otherwise nothing changes.

  5. YouSee the app, or a question

    A working app, and a concrete "what should happen in this case?" where you had not said.

Architecture

No code is generated for your app.

Most AI builders write a new codebase for every app, then patch it on every change. That is where the breakage comes from. In ZENREI your app is a definition, and one engine runs every definition.

APPSGENERATED CODE, ONE PER APP
A codebase per appEvery change edits code that nothing else exercises.
APP DEFINITIONS (DATA)ONE ENGINE, CHECKED ONCE
One engine for every appYour rules are data. The engine that runs them is the same one everybody else runs.

ZENREI-lang

A language invented for AI to write.

Small, typed, and total. You never write it, and you never need to read it. What matters is what a program in it can and cannot say.

  1. Money and units are types

    Yen before tax, yen after tax, grams, pieces. Mixing them is a type error, so it cannot happen quietly.

  2. Invariants hold on every commit

    A property that must always be true is written once and enforced on every write, by people and by rules alike.

  3. Empty must be given a meaning

    A value that might be missing cannot be ordered, or used in arithmetic, until the program says what missing means. Testing it for equality is allowed: a missing value equals nothing.

  4. A refusal carries its reason

    A rule that says no also says why, in the creator's own language.

What the types rule out

Some mistakes have no way to be written.

These are not checks we remember to run. They are things the language has no words for.

  • no side effectsA rule cannot do something behind your back.

    Pure expressions have no construct for writing or sending. Effects are separate, visible steps.

  • no recursionEvery rule finishes.

    There is no construct for a loop that never ends, and each evaluation has a step budget. Run out, and nothing is written.

  • 'Open ≠ 'ClosedAn undecided question cannot ship.

    A program with an open decision in it does not have the type of a released program. The compiler refuses it.

  • refuse_tieTies are decided, not guessed.

    If two records rank equally, the program must say who goes first or refuse with a reason. The engine never picks silently.

Ambiguity is found by the machine, not confessed by the AI. Where two readings of your words would give different results, the checker finds a situation that tells them apart and asks you about it.

Evidence

We broke it on purpose, eleven ways.

Each mutation damages one part of the language implementation. A good test suite notices every one.

8 caught by the tests at once 2 survived at first. We added the missing tests, and they were caught. 1 never reached the tests. The compiler refused to build it.

11of 11 stopped

From the language's design record, November 2026. The two early survivors are reported because they showed properties the design claimed and the tests had not yet checked.

Honest limits

What this does not prove.

  • A correct program can still be the wrong program.

    Types show that a program is consistent. They do not show that it is what you meant. That is what accepted examples are for: the design keeps the examples you confirmed and re-runs them on every change. Keeping your original words alongside them is not built yet.

  • The engine itself is software.

    Its meaning is guarded by property tests and mutation tests, not by types alone.

  • Conversation to app, end to end, is still in development.

    The language, the checker, the engine and data-preserving storage exist and are connected. The full path from a conversation to a finished app is not yet open to everyone.

The stack

Haskell decides. The BEAM delivers.

Two runtimes, each used for what it is best at, with one rule between them: meaning lives in Haskell only.

  • HaskellLanguage, checker, engine, storage decisions and result confirmation. Every business decision is made here.
  • ZENREI-langBusiness rules as checked data, run by one interpreter for all apps.
  • Elixir on the BEAMPhoenix LiveView hosts the screens. Each open screen is its own lightweight process, so one failing session cannot take another down, and changes arrive live without a reload. It holds no business logic: Haskell draws the HTML.
  • SQLite and PostgreSQLTransactional storage, on either database depending on the deployment. The result is compared before commit and again after reopening.

壊れないから、育てられる。

Be among the first