DEV Community: umbra

Two AI agents, one human, and a system that is not allowed to trust itself

umbra — Thu, 13 Aug 2026 09:22:22 +0000

The diagram above is a complete architecture on one screen. Not a marketing sketch — the real thing, running nightly, with every number measured rather than claimed.

Let me walk through it, because the interesting part is not the boxes. It is why they are arranged this way, and what breaks when they are not.

The problem this exists to answer
When AI writes the code, you cannot trust the author.

Not because the model is malicious — because trust was never the right instrument. You cannot inspect intent. You cannot code-review at the volume machines now produce. And every safety layer that works by asking the model nicely fails silently the first time the model is confidently wrong.

So I set out to answer something narrower and more tractable: can we make what code is allowed to do machine-checkable, and refuse to run anything that lies about it?

That question produced two things, and they exist for each other. LOOM, an effect-typed language that makes permissions provable. ARGUS, a nightly organism that grows LOOM and treats its own conclusions as suspects until proven.

The diagram is how those two are wired together without either becoming a single point of failure.

The top: one human, one word
Everything begins with a single authority. Two autonomous agents run below, and neither may act without explicit approval. They stop fail-closed and wait.

This is not ceremony. In one working session I stopped three separate times, mid-transaction, because a precondition no longer held. All three stops turned out to be correct — the world had moved under the plan while the plan was still being written.

An agent that cannot stop is an agent you cannot deploy. An agent that stops for the wrong reasons is merely annoying. An agent that stops for the right reasons, and can show you the measurement that made it stop, is the only kind worth running unattended.

The human is also the only one who declares which day it is. Neither agent may invent that number. It sounds trivial. It closes a whole class of drift where an automated system quietly redefines its own timeline and then reports progress against it.

Two agents, separated on purpose
Codex writes the language: parser, effect checker, five backends, the entire trust chain. Cloud Code runs the organism: the nightly cycle, backups, continuity, the evidence layer. Cloud has read-only access to the language. Codex does not run the organism.

Here is the part that matters, and it is not a division of labour. It is a division of author and judge.

Each agent is the independent adversary for the other's work.

That decision paid for itself repeatedly, and the clearest example is one where I was wrong. My backup layer had a lock that decided which directory it was protecting by looking at the pathname. Move the locked directory aside, create a fresh one at the same path, and the release returned success — while the original stayed locked forever.

Codex reproduced that against committed code. And when I went to look, I found something worse: my own source comment, sitting directly above the failing check, claimed that replaced roots were refused.

The comment was false, and I had written it.

That is the entire argument for separation in one incident. An author does not see their own blind spot, because the blind spot is made of the same assumptions that produced the code, the tests, and the comment explaining why the code is correct. Confident prose is not a control.

The bridge: measurement, not narrative
One shared file. Currently over ten thousand lines.

Everything one agent passes to the other must be recorded there as a measurement — hashes, test counts, exact paths, return codes, the specific bytes of the specific artifact. Narrative is not accepted.

That single constraint is what makes the audit possible. The judge reads numbers, not the author's story about the numbers. "I verified it" is not admissible. Manifest 7380ef7f…, sixteen of sixteen lines verified against card bytes is.

Two memories, both private
Each agent carries persistent memory across sessions: who the operator is, how we work, every directive, every lesson learned, the full history of the collaboration.

Neither agent reads the other's memory.

That is not a limitation. It is what keeps a cold read cold. A judge who inherits the builder's context inherits the builder's assumptions — and then agrees with them, fluently and at length. Separation of memory is separation of priors.

The narrow column in the middle: four gates
The organism may influence the language only by passing all four. This is the single point of contact between the two halves of the system, and it is deliberately narrow.

precheck verifies a proposal against an exact snapshot of the committed canon and applies nothing. Every anchor must resolve exactly once, or it refuses.

red-team attacks the organism's own proposal — hunting for a hole, not for a confirmation. This is the stage that changes what a human sees in the morning.

audit judges findings against an immutable snapshot of the target, never against a convenient copy.

publish writes the completion marker last. Until that marker exists and re-validates, the run did not happen.

Every gate may refuse. Refusal is the normal, healthy outcome — not an error state.

The cycle: cheap first, and the paid step never acts

eyes (0 tokens) → brain (paid, hard cap) → hands (sandboxed, no network)
→ precheck → red-team → audit → publish
Three decisions carry most of the weight.

The cheap step runs first, so the budget never decides what gets examined. If the expensive step leads, cost silently becomes your research agenda.

The paid step proposes but may never apply. Model output is a candidate, not an action. This is the difference between an assistant and an agent you can leave alone overnight.

The hands run the proposed experiment in a sandbox with no network. A hypothesis is settled by execution, not by how convincing the prose was. Models are extremely good at convincing prose. That is precisely why prose cannot be the evidence.

The consequence: what reaches a human in the morning is never "here is an idea." It is "here is an idea, and here is my best attempt to break it."

The language: a chain with no word for "allowed"
In LOOM, every function must declare its effects, and the checker proves the declaration honest before a single line runs. A seam is not advice — it is a capability boundary. Wrap an untrusted step in seam (Pure) and its I/O becomes physically impossible, not merely discouraged.

Built on top of that is the part I find most interesting:

approve(request) → authorization: claim-required
claim(approval) → authorization: mediation-required
mediate(claim) → authorization: bounded-execution-required
Read the return values. Not ok. Not authorized. Every successful verification returns what is still unproven.

Authorization is not a property any single component can grant. It is the last link in the chain, and it only comes into existence once nothing before it can lie.

The most recently published layer re-verifies the approval, the exact invocation binding and the claim from scratch; opens file paths descriptor-relatively without following symlinks; hashes the executable; verifies working directory, exact environment values and canonical stdin — and then documents the timing window it cannot close, requiring the next layer to re-measure at the moment of spawn.

A layer that names its own limit is worth more than one that pretends it has none.

The bottom: continuity
Four git bundles, four continuity archives, a run receipt, and a manifest in which every named byte is re-hashed on verification.

Inside it: the language, the organism, both agent memories, and the bridge.

If the machine disappeared tomorrow, what recovers from that card is not the code. It is the entire collaboration — including what each agent knows and why.

The card's mutation lock is bound to the root's device and inode, not to its pathname, because a different directory at the same path is not that root. And exactly one full backup per day per card: before that repair, mounting any volume triggered a complete run — thirteen in a single day, hours of continuous writing for minutes of actual change.

What is actually unique here
Not the primitives. Effect systems, capabilities and linear resources are prior art with excellent lineage — Koka, Eff, Unison, OCaml. I would be lying if I claimed otherwise.

Three things are genuinely unusual, and all three are visible on the diagram.

One: the refusal chain. Almost every permission system in production answers "is this allowed?" and returns yes. This one refuses to let any single layer answer that question at all, and returns the next unproven thing instead. Authorization becomes a property of the whole chain rather than of whichever component was asked.

Two: adversarial self-verification as a default, not a phase. The organism attacks its own proposal before a human ever sees it. On top of that runs a mutation harness that copies the tree, deletes one defence, and requires the test suites to go red. A surviving mutation is an invariant nobody asserts — a passing test that was decoration. That harness has found real holes in work I had already declared finished, including one where the version field of a schema was checked by nothing at all, because a neighbouring check made it look covered.

A green suite proves your tests pass. It does not prove they would notice if a defence disappeared. Those are different properties, and only one of them survives a codebase that keeps changing.

Three: the author/judge split enforced structurally. Two agents, two private memories, one shared bridge that accepts only measurements. Most "AI reviews AI" setups share context, share priors, and therefore share blind spots. This one deliberately does not.

What it is for
Short term, it is a research artifact: a credible, fully open, self-verifying reference implementation of a trust layer for AI-written code. Everything on the diagram — architecture, cycle, gates, schemas, and every defect described here — is public. The only closed part is the growth engine, because that is the one thing that can be cloned rather than learned from.

Longer term, the pattern generalises past the language.

The interesting export is not LOOM's syntax. It is the shape: a system in which proposals are cheap, verification is adversarial, evidence is atomic, and permission is the last link rather than the first. Any pipeline where machines generate changes faster than humans can review them has the same structural problem — and most of them are currently solving it by asking the model to be careful.

We are going to need something better than careful. Something that refuses.

Built solo, in the open, from Ukraine 🇺🇦

👇 everything is here:
GitHub — github.com/umbraaeternaa/loom
Site — umbraaeternaa.github.io/loom
Playground (try it live) — umbraaeternaa.github.io/loom/play.html
Instagram — instagram.com/umbra_owner_architect_ai
LinkedIn — linkedin.com/in/volodymyr-natoptanyi-16b906262
Support — send.monobank.ua/jar/AHaziFXjYX

2 · INSTAGRAM (EN) — 2 143 / 2 200
🧭 Two AI agents, one human, and a system that is not allowed to trust itself

The whole architecture on one screen. Every number measured, not claimed.

When AI writes the code, you cannot trust the author. You cannot inspect intent, and any safety layer that works by asking the model nicely fails the first time it is confidently wrong.

So I built two things that exist for each other.

LOOM — a language where every function must declare its effects, and the checker proves the declaration honest BEFORE anything runs. Wrap an untrusted step in a Pure seam and its I/O becomes physically impossible.

ARGUS — a nightly organism that grows LOOM and treats its own conclusions as suspects until proven.

The three ideas the diagram encodes:

ONE. Separate the author from the judge. Codex writes the language, Cloud runs the organism, and each audits the other. That is how a defect was found where my own source comment claimed a case was handled — and the comment was false, and I had written it. An author cannot see their own blind spot, because the blind spot also wrote the tests, and the comment.

TWO. Nothing is allowed until it is proven. approve returns claim-required. claim returns mediation-required. mediate returns bounded-execution-required. Not ok. Not authorized. Every successful check returns what is STILL unproven. Permission is the last link, and it exists only once nothing before it can lie.

THREE. Memory is private, the bridge is shared — and the bridge accepts measurements, never narrative. "I verified it" is inadmissible. A hash is not.

A green suite proves your tests pass. It does not prove they would NOTICE a defence going missing. So a harness deletes one defence and demands the suites go red.

Built solo, in the open, from Ukraine 🇺🇦

👇 everything is here:
GitHub — github.com/umbraaeternaa/loom
Site — umbraaeternaa.github.io/loom
Playground — umbraaeternaa.github.io/loom/play.html
Instagram — instagram.com/umbra_owner_architect_ai
LinkedIn — linkedin.com/in/volodymyr-natoptanyi-16b906262
Support — send.monobank.ua/jar/AHaziFXjYX

AI #SoftwareArchitecture #Security #OpenSource #BuildInPublic

LOOM Day 14 — the compiler should leave a receipt

umbra — Tue, 21 Jul 2026 08:19:32 +0000

LOOM is a tiny effect-typed language: a trust layer for AI-written code. Every function declares its effects, and the checker proves the declaration — transitively, before a single line runs. The premise is uncomfortable but simple: when an AI writes the code, you can't trust the author, so the language has to carry the trust judgment.

Until now LOOM proved properties of code — that its effects are honest, that its budgets hold, that its recursion terminates ((prove (descent f))). Today its gate started leaving verifiable evidence — bound to the exact bytes of the compiler that produced the WebAssembly.

Compiler Evidence v1 ties a compiler profile, the artifact binding, source↔WASM equivalence, and the ABI into one piece of evidence. Swap the compiler, swap the artifact, or recompute a hash to forge attribution — each is rejected before execution; the modular and standalone compilers even carry distinct content identities so cross-attribution fails closed. Receipt v3 composes it; Workflow v3 exposes the route through the CLI and the browser playground.

The one-line version: it's a local in-toto/SLSA-style evidence chain, but anchored on the language's own live checker rather than on reputation. Not "trust me, I checked it" — "here's a receipt bound to exactly what ran, that an independent verifier can re-check."

489 self-verifying checks, all green — +33 in a single day. One checked program runs in an interpreter and compiles to Python, JavaScript, and real in-browser WebAssembly with identical output. There's a playground where you can paste code and watch the checker reject a lie in real time.

How it's built, and what I'm keeping to myself. I don't hand-write the language. An autonomous system I built grows it — and I'm keeping how it's built private; the engine is the part that's mine. What I'll say is what it does: it proposes, proves each idea against the live checker, adversarially attacks its own work, and lands nothing without passing every check and a human gate. It's an AI — precisely the author LOOM says you can't trust on its word — so it never self-certifies. The process obeys the rule the language enforces.

Full write-up (the language, and the organism as far as I'll say): 👉 [встав сюди URL своєї LinkedIn-статті після публікації]

Built solo, in the open, from Ukraine 🇺🇦. Feedback and criticism very welcome — especially where the model is wrong.

GitHub: https://github.com/umbraaeternaa/loom
Site: https://umbraaeternaa.github.io/loom
Playground: https://umbraaeternaa.github.io/loom/play.html
Instagram: https://instagram.com/umbra_owner_architect_ai
Support: https://send.monobank.ua/jar/AHaziFXjYX

LOOM Day 13 — from "what the code does" to "how much"

umbra — Sat, 18 Jul 2026 08:26:27 +0000

LOOM is a tiny effect-typed language: a trust layer for AI-written code. Every function must honestly declare its effects, and the checker proves that declaration before a single line runs.

Today the language went one level deeper. Until now it proved WHAT code does — its effects (network, disk, FFI), and that it doesn't lie about them. But not HOW MUCH. A function that makes one network call and one that makes a thousand looked identical to the gate.

Portable Meter Frame v1 changes that: every effect (IO, Net, Alloc, Rand, FFI) is charged against a private counter that flows through calls, closures, recursion, and handlers — identically across the interpreter, generated Python, JavaScript, and real WebAssembly. Exceeding the budget is rejected at compile time, not as a runtime crash. depthN adds a dynamic recursion-depth bound.

The language no longer only asks "what are you doing?" — it asks "how much?".

443 self-verifying checks, all green. LOOM can only ever grow greener: every new capability lands with an adversarial test that must keep them all passing.

And I don't hand-write the language every day. It's grown by ARGUS — an autonomous multi-agent organism I built: it proposes ideas, proves them against the live checker, red-teams its own work, and keeps only what survives.

Built solo, in the open, from Ukraine 🇺🇦.

Day 12: LOOM now owns its memory — a trust layer for AI-written code, in plain language

umbra — Fri, 10 Jul 2026 10:11:20 +0000

More and more of the world’s code is written by AI. That’s exciting — and quietly unnerving. Not because AI makes mistakes, but because the same AI often writes both the code and the test meant to catch the mistake. When one mind grades its own exam, “it passed” stops meaning “it’s safe.” You’re trusting on faith.

LOOM flips that. It’s a small, open-source language that acts as a trust layer for AI-written code. Code doesn’t just run — first LOOM asks, and proves at a gate:

What does this code promise to do?
Does it do only that — or does it secretly touch the network, the disk, the outside world?
Where did each value come from — and can the AI vouch for its own output? (It can’t.)
Is there independent confirmation — a human, an auditor, a real-run trace?

If the code lies about itself, LOOM refuses to run it. The slogan says it all: AI proposes, the compiler decides.

What makes it different

Most “AI safety” lives in prompts, reviews, and hope. LOOM makes trust a property the machine checks before a single line runs — and that guarantee survives translation: the same verified program runs in an interpreter, compiles to Python and JavaScript, and runs in your browser as real WebAssembly, with the identical result. It’s tiny on purpose — a research kernel — and it’s self-verified by 389 checks that can only ever go greener: every new feature ships with a test that tries to break it, so the language can’t silently regress.

Day 12 — we taught the language to own its memory

Until now, a LOOM program compiled to WebAssembly ran on a fixed scrap of memory. If it overflowed, it crashed — a random, low-level trap outside the language’s control. As of today, LOOM checks there’s room before every single write (reserve → then store). An overflow is no longer a random crash; it’s LOOM’s own deliberate, predictable decision — a clean stop instead of a mystery. It’s the same principle as the whole language — nothing happens that LOOM didn’t allow — now extended to memory itself. 388 → 389 checks, all green.

The part people don’t expect

I don’t write LOOM by hand. An autonomous organism I built grows it — day and night, on one machine. It proposes an improvement, proves it green itself, adversarially attacks its own idea, and only then does a human get the final say. Many “minds,” one engine. You’ll always see what it produces, and every result comes with proof — but the engine that grows it stays private. Open where it earns trust; private where it protects the edge.

Where this is going

Today LOOM checks and proves. Next it moves from checking to enforcing: a real action an AI agent wants to take — edit a file, run a test, push to a repo — physically passes through this gate. It builds a manifest (who’s acting, what they want, which files), checks policy, asks you to approve if needed, and then writes a receipt: what was allowed, and what actually happened. Picture a control panel of trust for working with AI agents — not terminal magic, but plain-language decisions: “this code wants network access,” “this change has no independent proof,” “this push is allowed.”

That’s the goal: to become the trust layer the world uses to safely let AI write code — so you can move fast with agents without giving up control.

389 checks, all green. Built solo, in the open, from Ukraine 🇺🇦.

— Links —
⭐ GitHub (MIT): https://github.com/umbraaeternaa/loom
🌐 Site: https://umbraaeternaa.github.io/loom
▶ Try it live (in your browser): https://umbraaeternaa.github.io/loom/play.html
📸 Instagram: https://instagram.com/umbra_owner_architect_ai
💼 LinkedIn: https://linkedin.com/in/volodymyr-natoptanyi-16b906262
☕ Support: https://send.monobank.ua/jar/AHaziFXjYX

Day 11: my AI-code trust gate now sees what actually happened — two-phase, signed

umbra — Mon, 06 Jul 2026 18:36:53 +0000

I'm building LOOM — a small open-source language that is a machine-checked trust layer for AI-written code. I don't write it by hand: an organism I built grows it, day and night. Day 11 closes the gap between approved and done.

A one-shot approval isn't enough — the gate should see what actually happened

LOOM's core is a gate that refuses code that lies about what it does. Approvals became signed and one-use — but they were still one step: you signed, and it was "spent." Between approved and done there was a gap: a crash mid-action, a replay, a swapped result — the gate never saw it.

Day 11 makes approval two-phase and signed — 385 → 388 checks, all green

claim_operator_approval reserves the signed approval before the action runs.
finish_claimed_receipt closes it exactly once — completed or failed — with a receipt.
Fails closed everywhere — replay across old and new paths, duplicate claims, forgery/rebinding, and double finalization are all rejected.

The gate that refuses lies and proves what it allowed now also proves what actually happened — not just what was approved.

The organism (what I show, not how it's built)

I never write the language by hand. The organism runs a loop no hand-written project has: propose → prove it green itself → adversarially attack it itself → and only then a human decides. AI proposes; the compiler disposes. The engine that grows it stays mine — I show what it does and the proof, never the engine.

388 checks, all green. Built solo, in the open, from Ukraine 🇺🇦.

LOOM: a language that proves what AI-written code is allowed to do

umbra — Sat, 04 Jul 2026 18:35:33 +0000

▶ Try it live (in your browser): https://umbraaeternaa.github.io/loom/play.html

Built solo, in the open, from Ukraine 🇺🇦.

The problem nobody can scale their way out of
AI now writes a large and growing share of the code that runs in the world. The uncomfortable part isn't that the code is often wrong — it's that the same model frequently writes both the code and the tests that check it. When one intelligence authors the solution and the criteria, "it passed" quietly stops meaning "it's safe." The gate becomes foolable. You can make the model bigger, but a bigger model that grades its own homework is still grading its own homework.

The honest answer isn't "trust a smarter model." It's: trust only what can be independently proven — and make that proof mechanical, not a matter of hope. That is the whole idea behind LOOM.

What LOOM is
LOOM is a small, open-source, effect-typed language that acts as a machine-checked trust layer for AI-written code. It doesn't just run code — it proves, at a gate, exactly what the code is allowed to do, before a single line executes. If the code lies about what it does, the compiler refuses it.

The slogan is: AI proposes, the compiler disposes.

Today it is a research kernel with 385 self-verifying checks, all green — every feature added only with an adversarial test, so the language can only ever get greener. There's a live browser playground where a stranger can paste a program and watch the checker accept or reject it in under a minute.

What it can actually do
Effect honesty. Every function declares its effects — Pure, IO, Net, Alloc, FFI, Rand. Declared effects must cover what the code actually does; the lie is caught transitively through calls, branches, recursion — not just straight-line code.
Capabilities, not ambient power. A foreign call has no ambient authority — un-wrapped, it's refused. A seam is the only thing that grants authority, so (seam (Pure) (ffi untrusted)) makes that code's I/O physically impossible.
Reinterpreting handlers. Take code that touches the network, swap what Net means (a pure mock), and the type system proves the original effect is contained.
Linear & affine resources — open-once, use, close-once, carried honestly across calls.
Provenance & a trust gate. Every value carries who authored it. (trust N e) refuses a value trusted only by itself and demands N independent, non-AI anchors — a direct defense against circular trust. Plus role quorums (code, spec, proof by distinct authors), provenance-gated capabilities, taint that flows through data, memory-poisoning defense, and program-wide require/forbid policy.
One program, every backend. The same checked program runs on the interpreter, compiles to Python, JavaScript, and real WebAssembly — structures, closures, effects, strings, and the trust layer itself — with identical output. Honest all the way down to the metal and into the browser.
An accountable gate. A trust decision is no longer a bare yes/no: approvals are now structured verdicts with manifests, advisory receipts, CI evidence, a read-only git observer, and cryptographic one-use signatures — an approval can be spent exactly once and never replayed. The gate that refuses lies now also proves what it allowed.
Its power
The power isn't a single feature — it's the shift in what "trust" means. Elsewhere, trust is a comment, a review, a hope. In LOOM, trust is a property the machine verifies before execution, and it survives translation: a guarantee proven in the interpreter still holds in the browser.

That generality is why the same engine can be pointed outward: LOOM's auditor can read real, external AI-agent code and model each suspected weakness as a minimal LOOM program the live checker rejects — turning "this feels risky" into "here is the exact effect/trust/capability shape, proven." It's early, and every finding is human-ratified before it counts, but the direction is clear: formal, checkable trust analysis for the code AI writes.

Its secret
Here's the part people don't expect: I don't write LOOM by hand. An autonomous organism I built grows it — day and night, on a single machine. Its loop is one no hand-written project runs: it proposes a change → proves it green itself → adversarially attacks its own proposal → and only then a human decides. It self-heals. Many "minds," one engine.

And that's the moat. The language is open. The results are public, always with proof. The engine that grows it stays private. You see what it does and verify it — never how it's built. Openness where it earns trust; secrecy where it protects the edge.

Its future
As AI writes more of the world's code, the scarce thing won't be more model capacity — it will be trust you can prove. LOOM aims to be that layer: where AI-written code can be proven, from a human-checked gate down to the metal and into the browser, with an accountable, non-replayable record of every decision. Next: deeper low-level and cross-platform expansion above the honest assembly contract, sharper external auditing, and — the real goal — for this kind of verifiable trust to be recognized and adopted by the people who need it most.

It's alpha, tiny on purpose. The individual ideas — effect rows, capabilities, provenance — aren't new; the synthesis is: one legible signature channel, checked at a trusted gate, as a trust layer for AI-generated code. Feedback and criticism are genuinely welcome — especially where the model is wrong.

⭐ Code (MIT): https://github.com/umbraaeternaa/loom
🌐 Site: https://umbraaeternaa.github.io/loom
▶ Try it live (in your browser): https://umbraaeternaa.github.io/loom/play.html
☕ Support: https://send.monobank.ua/jar/AHaziFXjYX
📸 Instagram: https://instagram.com/umbra_owner_architect_ai

Day 10: my AI-code trust gate now leaves evidence — signed, one-use, receipted

umbra — Sat, 04 Jul 2026 17:56:01 +0000

canonical_url: https://umbraaeternaa.github.io/loom/
I'm building LOOM — a small open-source language that is a machine-checked trust layer for AI-written code. I don't write it by hand: an organism I built grows it, day and night. Day 10 is about turning a yes/no gate into an accountable one.

A verdict is not enough — a trust gate should leave evidence

LOOM's core is a gate that refuses code that lies about what it does. Until now that gate was ephemeral: it decided, then forgot. An approval left no trace, carried no proof, could be replayed, and an outside observer couldn't check what was actually approved.

Day 10 makes every trust decision accountable — 333 → 385 checks, all green

Structured verdicts + manifests — an approval is now a structured object that records exactly what it covers, not a bare boolean.
Advisory receipts, a role policy, and CI evidence — the gate emits an audit trail; a read-only git observer can witness it without touching anything.
Signed, one-use approvals — an approval is cryptographically signed and can be spent exactly once; it cannot be replayed or reused.
Checked WASM signed comparisons (i31) — the low-level backend gained verified signed-integer comparison intrinsics on top of the existing checked-asm metadata contract (raw assembly stays fail-closed).

The gate that refuses lies now also proves what it allowed — accountability, not just a yes/no.

The organism (what I show, not how it's built)

385 checks, all green. Built solo, in the open, from Ukraine 🇺🇦.

my AI-code language is now honest all the way down to WebAssembly

umbra — Fri, 03 Jul 2026 18:24:15 +0000

Full LOOM Language Report
LOOM is no longer just an idea. It is a compact experimental programming language with its own:
syntax;
static checker;
interpreter;
Python, JavaScript, and WebAssembly compilers;
effect, capability, resource, and trust systems;
browser Playground;
command-line interface;
suite of 378 self-verifying checks.
Current canonical state:
Commit: 92a5742
Citadel: 378/378
Documentation parity: PASS
Git synchronization: 0/0
Live Playground: operational
The Core Idea
Most programming languages primarily check whether code is syntactically and structurally valid.
LOOM additionally checks:
What the code is allowed to do, who is responsible for it, and under which conditions it may receive dangerous capabilities.

For example, a function may claim to be pure:
(defx sneaky () (fn (x) (print x)))
But it performs output internally. LOOM detects the hidden IO effect and rejects the program before execution.
This verification works through:
nested functions;
function calls;
branches;
bindings;
recursion;
closures;
handlers;
external components.
The central principle is:
AI proposes. The compiler disposes.

Current Capabilities

General Programming LOOM already supports: signed integers; arithmetic; comparisons; if expressions; local let bindings; named functions; anonymous functions; recursion; first-class functions; closures; lists; list construction; head, tail, and empty; records with named fields; field access; variants; pattern matching; string literals. This is sufficient for writing small real programs rather than isolated demonstration expressions.
Effect Checking LOOM distinguishes between different classes of behavior: Pure — pure computation; IO — input and output; Net — network access; Alloc — allocation; FFI — foreign code; Rand — randomness. Every function declares its effect row. The checker computes what the function actually performs and compares it with the declaration. This prevents code from secretly: accessing the network; producing output; executing foreign code; allocating resources; using randomness; smuggling effects through helper functions.
Transitive Effect Verification Effect checking is not limited to direct operations. LOOM follows effects through: calls; recursion; conditions; local bindings; higher-order functions; closures; handlers; foreign boundaries. A pure function cannot call an effectful function and hide the effect from its own contract.
Effect Polymorphism Higher-order functions may accept functions whose effects are not known in advance. If the supplied function is pure, the call remains pure. If it performs IO or Net, that effect automatically propagates to the caller. This allows reusable functions such as map and fold without losing security information.
Capability Seams A seam is an explicit capability boundary. Foreign or opaque code does not automatically receive access to: networking; output; allocation; random sources; other host capabilities. Capabilities must be granted explicitly. For example: (seam (Pure) ...) runs the enclosed computation without external capabilities. If foreign code attempts IO or Net, the runtime blocks it. This is the foundation of LOOM’s future sandbox for AI-generated code.
Effect Handlers LOOM can locally discharge or reinterpret an effect. A real network operation may be replaced by a pure mock: (with Net mock ...) This enables: safe testing; service simulation; dry-run execution; deterministic environments; controlled external dependencies. The checker proves that the original network effect does not escape.
Affine Capabilities LOOM supports capabilities that may be used at most once. This protects against: repeated network requests; duplicate token use; repeated critical actions; accidental reuse of one-time authority.
Linear Resources Resources can be required to follow exactly one lifecycle: created; used; completed. LOOM rejects programs where a resource is: never used; used more than once; lost; duplicated; passed incorrectly between functions. Potential applications include: files; sockets; transactions; locks; one-time keys; descriptors; hardware resources.
Typed Resources A resource may carry a specific effect. For example, network authority can be tied to one resource. Code cannot claim to use that resource while secretly performing an ambient network operation elsewhere. This protects the integrity of the execution path.
Required Effects A conventional effect system says: “This function may perform a network action.”

LOOM can also express:
“This function must actually perform the network action.”

This catches false or empty implementations such as:
audit functions that never write an audit record;
persistence functions that store nothing;
transactions that report success without committing;
security checks replaced by return true;
production code accidentally replaced by a stub.

Negative Policies A policy such as: (forbid Net) can prohibit network effects from escaping anywhere in the program. The effect must either: not occur; or be locally handled by a real handler. This supports: offline execution; network-free environments; FFI-free modes; deterministic builds; restricted production profiles.
Provenance Tracking LOOM can record where a value came from: (prov ai value) (prov human value) (prov trace value) Provenance flows through: bindings; computations; function calls; nested expressions; later trust checks. Moving a value into another variable does not erase its history.
Trust Gates A trust gate verifies whether a value has independent supporting evidence. An AI-generated value cannot certify itself: (trust (prov ai 42)) This is rejected. LOOM may require multiple independent anchors: (trust 2 (prov human (prov trace (prov ai 42)))) This value has: an AI origin; human ratification; a real execution trace. The purpose is to prevent one system from generating: the code; the specification; the test; the proof of its own correctness.
Roles and Independent Authors LOOM may require specific roles rather than only counting confirmations: code author; specification author; reviewer; auditor; proof author. A policy can require code and proof to be confirmed by different parties. One person or one AI cannot occupy every role and certify itself.
Role Hierarchies Roles may form a hierarchy: reviewer; auditor; senior auditor. A stronger role may satisfy a weaker requirement, but not the reverse. Role hierarchy never removes the requirement for independent participants.
Provenance-Gated Capabilities Dangerous authority may be granted only to code carrying the required provenance and role quorum. For example: Grant Net only to code written by one party and independently reviewed by another.

If the evidence is missing, the network capability is never issued.
This is one of LOOM’s defining properties:
Trust is not documentation. Trust becomes a condition for receiving real authority.

Per-Effect Trust Requirements Different effects may require different reviewers: Net may require a network reviewer; FFI may require a security auditor; IO may require an operations reviewer. Different risks can therefore demand different evidence.
Program-Wide Policy Policies may be declared once for the entire program: role hierarchy; required number of confirmations; capability requirements; forbidden effects; required effects. Every function and capability seam then inherits the same rules. Trust becomes a property of the codebase rather than repeated boilerplate.
Author-Based Confinement LOOM can control not only what happens, but also which author’s code performs the dangerous operation. This matters when a system combines: first-party code; libraries; plugins; vendor code; code generated by multiple AI systems. An unapproved component can be prevented from directly exercising Net, even when another trusted component has that capability.
Declassification declassify allows an authorized human or role to take responsibility for an AI-derived value after review. This creates an explicit accountability point: “I reviewed this value and now vouch for it.”

An AI cannot declassify its own output.

Reproducibility and Recall LOOM includes constructs for expressing: persisted provenance; recalled values; reproducibility claims; checked re-execution. Much of this layer is static: it is verified before execution and does not add unnecessary runtime overhead.
Checked Low-Level Assembly LOOM exposes a closed low-level interface: (asm wasm OPCODE ARG...) This is not arbitrary textual assembly. The currently registered operations are: i31.add; i31.sub; i31.mul; i31.eq; i31.lt_s; i31.gt_s. For each operation, the registry defines: argument count; input types; result type; effects; portable semantics; WebAssembly opcode; WAT representation; result encoding. Unknown operations, raw WAT, arbitrary WebAssembly bytes, memory operations, and host calls are rejected.
Portable Numeric Semantics All backends share one integer contract: signed i31 values; range from -2^30 to 2^30 - 1; deterministic modulo-2^31 wraparound; out-of-range literals rejected before execution. Python, JavaScript, the interpreter, and WebAssembly must produce identical results.
Multi-Target Compilation
One checked LOOM program can be:
executed by the interpreter;
compiled to Python;
compiled to JavaScript;
compiled to binary WebAssembly;
rendered as human-readable WAT.
The goal is:
One checked source program, multiple platforms, one behavior.
WebAssembly Backend
The WebAssembly backend already supports:
integers;
lists;
records;
variants;
pattern matching;
strings;
functions;
closures;
captured values;
effects;
handlers;
capability seams;
FFI;
trust and provenance wrappers;
structured heap values;
checked assembly.
The ABI is versioned. Generated modules publish their ABI version, allowing a host to reject incompatible modules.
Isolated Compilation Contexts
Each WebAssembly compilation uses an isolated per-program context.
Parallel builds cannot leak or mix:
closure layouts;
helper functions;
variant tags;
record fields;
ABI state.
Command-Line Interface
LOOM can already be used as a local tool:
python3 loom.py check program.loom
python3 loom.py run program.loom
python3 loom.py build program.loom --target js
python3 loom.py audit program.loom
These commands allow users to:
verify a program;
run it;
compile it;
inspect declared and actual effects;
receive structured rejection reports.
Browser Playground
The live Playground can:
accept LOOM source code;
run the checker;
execute the program;
compile it to JavaScript;
emit WAT;
compile and run real WebAssembly;
group errors by function;
demonstrate checked assembly operations.
Self-Verification
LOOM currently has:
378/378 Citadel checks;
negative security tests;
cross-backend differential tests;
deterministic property fuzzing;
reproducible seeds;
standalone published-bundle verification;
GitHub CI;
live-site read-back after publication.
A feature is not treated as complete until it works on every claimed backend and includes tests against incorrect use.
Current Applications
Education
LOOM can teach:
effect systems;
capability security;
linear resources;
sandbox design;
provenance tracking;
circular-trust risks;
WebAssembly compilation.
Programming-Language Research
LOOM is a practical research environment for:
effect systems;
linear and affine types;
provenance;
trust policies;
capability security;
role-based authorization;
secure FFI;
WebAssembly ABI design.
Small AI-Generated Programs
AI systems can generate LOOM code while LOOM checks:
hidden network access;
undeclared output;
incorrect resource use;
missing independent validation;
unauthorized capabilities.
Secure Plugins
LOOM could serve as a language for small:
plugins;
automation scripts;
rules;
handlers;
agent tools;
user extensions.
The host could inspect a plugin’s authority before running it.
CI/CD Policies
LOOM can model policies such as:
deployment requires two independent approvals;
production must not use randomness;
foreign code receives no network authority;
security checks cannot be replaced by empty stubs;
FFI requires an auditor role.
Agent Workflows
LOOM can describe:
which tools an agent may access;
how many times a tool may be used;
who approved the result;
whether network access is permitted;
whether human ratification is required.
Verifiable Automation
A workflow could:
Download data.
Transform it.
Store the result.
Prove that network access occurred only during the download.
Prove that the final write occurred exactly once.
External Code Auditing
The organism’s Auditor can use LOOM as a logical oracle:
Model suspected external behavior as a minimal LOOM program.
Confirm that the checker rejects the unsafe model.
Confirm that the corrected model is accepted.
Confirm that safe controls remain accepted.
This does not automatically prove a vulnerability in arbitrary external Python code. It provides a disciplined way to formalize and test a security hypothesis.
Future Applications
Policy Language for AI Systems
LOOM could verify critical contracts such as:
an agent may read but not write;
a model may access only one API;
code execution requires a sandbox;
production actions require human approval;
a financial operation cannot be repeated.
Trusted Intermediate Representation
Other languages and AI tools could generate a small LOOM intermediate representation.
LOOM would then act as a verification layer between:
AI-generated code;
organizational policy;
WebAssembly;
the host environment.
Verifiable Execution SDK
A future SDK could:
Accept a program.
Verify effects and provenance.
Produce a structured verdict.
Compile the program to WebAssembly.
Run it with minimal capabilities.
Preserve evidence of exactly what was authorized.
Plugin Platform
Before installing a plugin, the platform could show:
network access required;
output access required;
FFI used;
provenance not independently verified;
security audit required;
one-time resource consumed.
The host would issue only the declared and verified capabilities.
AI Tool Marketplace
LOOM could support a marketplace where:
every component has a capability profile;
every release is bound to exact source code;
effect changes are visible;
dangerous authority requires role approval;
execution is isolated through WebAssembly.
Browser, Edge, and Offline Systems
Because LOOM is compact and targets WebAssembly, it may suit:
browser applications;
local automation;
edge devices;
offline systems;
embedded policy engines;
small controlled runtimes.
Contracts Between Multiple Agents
One agent may create code, another the specification, and another the proof.
LOOM can require that:
authors are independent;
roles are not controlled by one party;
runtime traces match the exact artifact;
capabilities are issued only after quorum.
Where the Project Is Going
LOOM is not trying to become another general-purpose replacement for Python.
Its stronger purpose is:
A small, understandable, verifiable language for code that cannot automatically be trusted.

The intended execution chain is:
A human or AI writes a program.
LOOM determines every effect.
LOOM verifies resources and one-time capabilities.
LOOM verifies provenance and independent approvals.
LOOM applies organization-wide policy.
LOOM rejects the program or produces a verdict.
An accepted program is compiled to WebAssembly.
The host grants only the proven capabilities.
The program runs in a browser, server, or local runtime.
The result remains bound to the source, policy, and ABI version.
The Intended Final Product
The complete system should include:
the LOOM language;
an effect, capability, resource, and trust checker;
a WebAssembly compiler;
a capability-aware runtime;
a versioned ABI;
CLI and SDK interfaces;
a browser Playground;
structured verdicts and receipts;
an AI-code auditing tool;
CI/CD and agent integrations;
a standard library of verified components.
The practical outcome is:
We can accept code written by an unknown author or an AI, refuse to trust it on reputation alone, verify its authority before execution, and run it only within the contract that was actually proven.

What Still Blocks Production Readiness
LOOM is already a strong research prototype, but it is not yet a production language.
The remaining work includes:
completing a formal language specification;
stabilizing the ABI;
further separating the main facade into clear modules;
expanding property testing and fuzzing;
conducting an independent security audit;
building a real host sandbox model for FFI;
formally specifying trust and provenance semantics;
creating stable packages and SDKs;
improving diagnostics;
developing a standard library;
testing larger real-world programs;
versioning policies and verdict formats;
resolving recurring first-attempt GitHub Pages deployment failures.
Independent Assessment
LOOM already combines several capabilities that are rarely present together in a small language:
effects;
capabilities;
linear resources;
provenance;
independent roles;
trust gates;
real WebAssembly execution.
Its greatest potential is not competing with Python for ordinary application development.
Its natural role is:
A verifiable execution layer for AI-generated code, agent tools, plugins, and critical automation workflows.

The strongest next strategic step is not simply adding more opcodes. It is creating an exportable verdict or receipt: a compact machine-readable document binding the verification result to the exact source code, policy, ABI version, and commit.
That would transform LOOM from a strong language research project into an embeddable trust tool for other systems.

378 checks, all green. Built solo, in the open, from Ukraine 🇺🇦.

⭐ Code (MIT): https://github.com/umbraaeternaa/loom
🌐 Site: https://umbraaeternaa.github.io/loom
▶ Try it live: https://umbraaeternaa.github.io/loom/play.html
☕ Support: https://send.monobank.ua/jar/AHaziFXjYX

my AI-code language is now honest all the way down to WebAssembly

umbra — Fri, 03 Jul 2026 18:24:15 +0000

Current Capabilities

General Programming LOOM already supports: signed integers; arithmetic; comparisons; if expressions; local let bindings; named functions; anonymous functions; recursion; first-class functions; closures; lists; list construction; head, tail, and empty; records with named fields; field access; variants; pattern matching; string literals. This is sufficient for writing small real programs rather than isolated demonstration expressions.
Effect Checking LOOM distinguishes between different classes of behavior: Pure — pure computation; IO — input and output; Net — network access; Alloc — allocation; FFI — foreign code; Rand — randomness. Every function declares its effect row. The checker computes what the function actually performs and compares it with the declaration. This prevents code from secretly: accessing the network; producing output; executing foreign code; allocating resources; using randomness; smuggling effects through helper functions.
Transitive Effect Verification Effect checking is not limited to direct operations. LOOM follows effects through: calls; recursion; conditions; local bindings; higher-order functions; closures; handlers; foreign boundaries. A pure function cannot call an effectful function and hide the effect from its own contract.
Effect Polymorphism Higher-order functions may accept functions whose effects are not known in advance. If the supplied function is pure, the call remains pure. If it performs IO or Net, that effect automatically propagates to the caller. This allows reusable functions such as map and fold without losing security information.
Capability Seams A seam is an explicit capability boundary. Foreign or opaque code does not automatically receive access to: networking; output; allocation; random sources; other host capabilities. Capabilities must be granted explicitly. For example: (seam (Pure) ...) runs the enclosed computation without external capabilities. If foreign code attempts IO or Net, the runtime blocks it. This is the foundation of LOOM’s future sandbox for AI-generated code.
Effect Handlers LOOM can locally discharge or reinterpret an effect. A real network operation may be replaced by a pure mock: (with Net mock ...) This enables: safe testing; service simulation; dry-run execution; deterministic environments; controlled external dependencies. The checker proves that the original network effect does not escape.
Affine Capabilities LOOM supports capabilities that may be used at most once. This protects against: repeated network requests; duplicate token use; repeated critical actions; accidental reuse of one-time authority.
Linear Resources Resources can be required to follow exactly one lifecycle: created; used; completed. LOOM rejects programs where a resource is: never used; used more than once; lost; duplicated; passed incorrectly between functions. Potential applications include: files; sockets; transactions; locks; one-time keys; descriptors; hardware resources.
Typed Resources A resource may carry a specific effect. For example, network authority can be tied to one resource. Code cannot claim to use that resource while secretly performing an ambient network operation elsewhere. This protects the integrity of the execution path.
Required Effects A conventional effect system says: “This function may perform a network action.”

LOOM can also express:
“This function must actually perform the network action.”

Negative Policies A policy such as: (forbid Net) can prohibit network effects from escaping anywhere in the program. The effect must either: not occur; or be locally handled by a real handler. This supports: offline execution; network-free environments; FFI-free modes; deterministic builds; restricted production profiles.
Provenance Tracking LOOM can record where a value came from: (prov ai value) (prov human value) (prov trace value) Provenance flows through: bindings; computations; function calls; nested expressions; later trust checks. Moving a value into another variable does not erase its history.
Trust Gates A trust gate verifies whether a value has independent supporting evidence. An AI-generated value cannot certify itself: (trust (prov ai 42)) This is rejected. LOOM may require multiple independent anchors: (trust 2 (prov human (prov trace (prov ai 42)))) This value has: an AI origin; human ratification; a real execution trace. The purpose is to prevent one system from generating: the code; the specification; the test; the proof of its own correctness.
Roles and Independent Authors LOOM may require specific roles rather than only counting confirmations: code author; specification author; reviewer; auditor; proof author. A policy can require code and proof to be confirmed by different parties. One person or one AI cannot occupy every role and certify itself.
Role Hierarchies Roles may form a hierarchy: reviewer; auditor; senior auditor. A stronger role may satisfy a weaker requirement, but not the reverse. Role hierarchy never removes the requirement for independent participants.
Provenance-Gated Capabilities Dangerous authority may be granted only to code carrying the required provenance and role quorum. For example: Grant Net only to code written by one party and independently reviewed by another.

If the evidence is missing, the network capability is never issued.
This is one of LOOM’s defining properties:
Trust is not documentation. Trust becomes a condition for receiving real authority.

Per-Effect Trust Requirements Different effects may require different reviewers: Net may require a network reviewer; FFI may require a security auditor; IO may require an operations reviewer. Different risks can therefore demand different evidence.
Program-Wide Policy Policies may be declared once for the entire program: role hierarchy; required number of confirmations; capability requirements; forbidden effects; required effects. Every function and capability seam then inherits the same rules. Trust becomes a property of the codebase rather than repeated boilerplate.
Author-Based Confinement LOOM can control not only what happens, but also which author’s code performs the dangerous operation. This matters when a system combines: first-party code; libraries; plugins; vendor code; code generated by multiple AI systems. An unapproved component can be prevented from directly exercising Net, even when another trusted component has that capability.
Declassification declassify allows an authorized human or role to take responsibility for an AI-derived value after review. This creates an explicit accountability point: “I reviewed this value and now vouch for it.”

An AI cannot declassify its own output.

Reproducibility and Recall LOOM includes constructs for expressing: persisted provenance; recalled values; reproducibility claims; checked re-execution. Much of this layer is static: it is verified before execution and does not add unnecessary runtime overhead.
Checked Low-Level Assembly LOOM exposes a closed low-level interface: (asm wasm OPCODE ARG...) This is not arbitrary textual assembly. The currently registered operations are: i31.add; i31.sub; i31.mul; i31.eq; i31.lt_s; i31.gt_s. For each operation, the registry defines: argument count; input types; result type; effects; portable semantics; WebAssembly opcode; WAT representation; result encoding. Unknown operations, raw WAT, arbitrary WebAssembly bytes, memory operations, and host calls are rejected.
Portable Numeric Semantics All backends share one integer contract: signed i31 values; range from -2^30 to 2^30 - 1; deterministic modulo-2^31 wraparound; out-of-range literals rejected before execution. Python, JavaScript, the interpreter, and WebAssembly must produce identical results.
Multi-Target Compilation
One checked LOOM program can be:
executed by the interpreter;
compiled to Python;
compiled to JavaScript;
compiled to binary WebAssembly;
rendered as human-readable WAT.
The goal is:
One checked source program, multiple platforms, one behavior.
WebAssembly Backend
The WebAssembly backend already supports:
integers;
lists;
records;
variants;
pattern matching;
strings;
functions;
closures;
captured values;
effects;
handlers;
capability seams;
FFI;
trust and provenance wrappers;
structured heap values;
checked assembly.
The ABI is versioned. Generated modules publish their ABI version, allowing a host to reject incompatible modules.
Isolated Compilation Contexts
Each WebAssembly compilation uses an isolated per-program context.
Parallel builds cannot leak or mix:
closure layouts;
helper functions;
variant tags;
record fields;
ABI state.
Command-Line Interface
LOOM can already be used as a local tool:
python3 loom.py check program.loom
python3 loom.py run program.loom
python3 loom.py build program.loom --target js
python3 loom.py audit program.loom
These commands allow users to:
verify a program;
run it;
compile it;
inspect declared and actual effects;
receive structured rejection reports.
Browser Playground
The live Playground can:
accept LOOM source code;
run the checker;
execute the program;
compile it to JavaScript;
emit WAT;
compile and run real WebAssembly;
group errors by function;
demonstrate checked assembly operations.
Self-Verification
LOOM currently has:
378/378 Citadel checks;
negative security tests;
cross-backend differential tests;
deterministic property fuzzing;
reproducible seeds;
standalone published-bundle verification;
GitHub CI;
live-site read-back after publication.
A feature is not treated as complete until it works on every claimed backend and includes tests against incorrect use.
Current Applications
Education
LOOM can teach:
effect systems;
capability security;
linear resources;
sandbox design;
provenance tracking;
circular-trust risks;
WebAssembly compilation.
Programming-Language Research
LOOM is a practical research environment for:
effect systems;
linear and affine types;
provenance;
trust policies;
capability security;
role-based authorization;
secure FFI;
WebAssembly ABI design.
Small AI-Generated Programs
AI systems can generate LOOM code while LOOM checks:
hidden network access;
undeclared output;
incorrect resource use;
missing independent validation;
unauthorized capabilities.
Secure Plugins
LOOM could serve as a language for small:
plugins;
automation scripts;
rules;
handlers;
agent tools;
user extensions.
The host could inspect a plugin’s authority before running it.
CI/CD Policies
LOOM can model policies such as:
deployment requires two independent approvals;
production must not use randomness;
foreign code receives no network authority;
security checks cannot be replaced by empty stubs;
FFI requires an auditor role.
Agent Workflows
LOOM can describe:
which tools an agent may access;
how many times a tool may be used;
who approved the result;
whether network access is permitted;
whether human ratification is required.
Verifiable Automation
A workflow could:
Download data.
Transform it.
Store the result.
Prove that network access occurred only during the download.
Prove that the final write occurred exactly once.
External Code Auditing
The organism’s Auditor can use LOOM as a logical oracle:
Model suspected external behavior as a minimal LOOM program.
Confirm that the checker rejects the unsafe model.
Confirm that the corrected model is accepted.
Confirm that safe controls remain accepted.
This does not automatically prove a vulnerability in arbitrary external Python code. It provides a disciplined way to formalize and test a security hypothesis.
Future Applications
Policy Language for AI Systems
LOOM could verify critical contracts such as:
an agent may read but not write;
a model may access only one API;
code execution requires a sandbox;
production actions require human approval;
a financial operation cannot be repeated.
Trusted Intermediate Representation
Other languages and AI tools could generate a small LOOM intermediate representation.
LOOM would then act as a verification layer between:
AI-generated code;
organizational policy;
WebAssembly;
the host environment.
Verifiable Execution SDK
A future SDK could:
Accept a program.
Verify effects and provenance.
Produce a structured verdict.
Compile the program to WebAssembly.
Run it with minimal capabilities.
Preserve evidence of exactly what was authorized.
Plugin Platform
Before installing a plugin, the platform could show:
network access required;
output access required;
FFI used;
provenance not independently verified;
security audit required;
one-time resource consumed.
The host would issue only the declared and verified capabilities.
AI Tool Marketplace
LOOM could support a marketplace where:
every component has a capability profile;
every release is bound to exact source code;
effect changes are visible;
dangerous authority requires role approval;
execution is isolated through WebAssembly.
Browser, Edge, and Offline Systems
Because LOOM is compact and targets WebAssembly, it may suit:
browser applications;
local automation;
edge devices;
offline systems;
embedded policy engines;
small controlled runtimes.
Contracts Between Multiple Agents
One agent may create code, another the specification, and another the proof.
LOOM can require that:
authors are independent;
roles are not controlled by one party;
runtime traces match the exact artifact;
capabilities are issued only after quorum.
Where the Project Is Going
LOOM is not trying to become another general-purpose replacement for Python.
Its stronger purpose is:
A small, understandable, verifiable language for code that cannot automatically be trusted.

Day 9: my AI-code language is now honest all the way down to WebAssembly

umbra — Fri, 03 Jul 2026 12:57:14 +0000

I'm building LOOM — a small open-source language that is a machine-checked trust layer for AI-written code. I don't write it by hand: an organism I built grows it, day and night, on one machine. Day 9 is one idea taken to its conclusion — the language is now honest all the way down to the metal.

The arc: every layer used to have a "hole at the bottom"

LOOM started as an effect checker — "is this function lying about what it does?". Then it grew a trust layer (a value is trusted only with independent, non-AI anchors). Then a WebAssembly backend — but at first only for integers. Each layer had a hole underneath it where the honesty quietly evaporated: structures and trust didn't reach the machine, a string was indistinguishable from a symbol, and the embedded-assembly boundary just stayed silent.

Day 9 closes those holes — 333 → 373 checks, all green

Strings, structures and the trust layer now run in real WASM. Records, closures, effects, and the transparent trust/prov/recall/declassify wrappers lower to a tagged-ABI runtime; quoted string literals are stored as static WASM data and the browser playground decodes them itself. interp == Python == JavaScript == WASM — for real values, not just arithmetic.
The proof is legible. When the checker refuses, it groups its findings by function (global findings separated), in the CLI and the browser — you see exactly where the lie is.
The assembly boundary is honest. An embedded (asm …) form is explicitly reserved and fail-closed across checker, interpreter, Python/JS, and WASM/WAT: embedded assembly is backend-owned until a checked low-level contract exists. No magic asm smuggled into the core.

The organism (what I show, not how it's built)

I never write the language by hand. The organism runs a loop no hand-written project has: it proposes a change → proves it green itself → adversarially attacks it itself → and only then a human decides. AI proposes; the compiler disposes. It self-heals on crashes and low-quality output. The engine that grows the language stays mine — I show what it does and the proof, never the engine.

Where this is going

Deeper low-level / cross-platform expansion above this honest asm contract — so AI-written code can be proven, from the gate down to the metal and into the browser.

373 checks, all green. Built solo, in the open, from Ukraine 🇺🇦.

"Day 8: my AI-code trust layer now compiles to real WebAssembly — guarantees and all"

umbra — Wed, 01 Jul 2026 20:27:19 +0000

I'm building LOOM — a small open-source language that is a machine-checked trust layer for AI-written code. Here's the part people don't expect: I don't write it by hand. An organism I built grows it, autonomously, day and night, on a single machine. Day 8 crossed a line I care about — the language now runs fully in real WebAssembly, and it takes its trust guarantees down to the metal with it.

Most languages compile the code and leave the safety story behind

You can compile almost anything to WASM. But the guarantees — the effect discipline, the capability seams, the provenance-aware trust gate — usually live in a higher-level checker and quietly evaporate on the way down. The artifact runs; the promise doesn't come along.

Day 8 closed that gap. It went from 333 to 365 self-verifying checks, all green (I ran run_tests.py and verify_docs_parity.py — both PASS), in two moves:

A full value runtime in WASM. Not just integers anymore — records, closures (heap-boxed with a generated dispatcher), and effects (IO) now run in WebAssembly through a tagged ABI v1. The core trap: in an i32 a plain number and a heap pointer are indistinguishable, so a structural runtime is impossible without ambiguity. The tagged ABI removes it by construction — even values are integers, odd values are pointers — and records/closures/effects sit on top.
The trust layer itself, lowered. trust, prov, by, recall, declassify, repro now lower into real WASM — and not by faking a shortcut: the lowering matches the interpreter's sequencing step-for-step (intermediates dropped, final value preserved, handled effects inside wrapper bodies still behave). The guarantee that holds in the interpreter now holds in the browser.

So the invariant is real: interp == Python == JavaScript == WASM, for structures and for trust — not just arithmetic.

The unglamorous half that makes it trustworthy

Deterministic fuzzing (property fuzz across parser/checker/interpreter/Python/JS/WASM) found and closed 3 real defects before they could ship.
CI now pins all of it.
The old ~1300-line monolith was decomposed into clean modules (a small facade over parse / checker / codegen / runtime / wasm / cli), so the surface stays auditable as it grows. Net change since I froze the trust layer: 17 files, +4725 / −1387.

What makes the organism unique

I'll always show what the organism does and the proof — never how it's built. But what it does is the interesting part: it runs a loop no hand-written project has — it proposes a change → proves it green itself → adversarially attacks it itself → and only then a human decides. AI proposes; the compiler disposes. It self-heals: a "mind" that crashes or keeps producing un-landable, low-quality proposals auto-pauses and retries later — it heals output quality, not just crashes. Many minds, one engine. The proof it works isn't a claim — it's these 365 machine-checked green checks and a real WASM backend, all grown this way.

The language is open; the results are public; the engine is private.

365 checks, all green. Across every day, the language has only ever gotten greener.

Built solo, in the open, from Ukraine 🇺🇦.

"Day 7: the organism that grows my language learned to improve itself"

umbra — Sat, 27 Jun 2026 20:14:39 +0000

I'm building LOOM — a small open-source language that is a machine-checked trust layer for AI-written code. I don't write it by hand: an organism I built grows it, day and night, on my own machine. Day 7 was different — the organism learned to improve itself.

The language reached a mature point — and I froze it there

LOOM's trust layer (effects + capabilities + provenance, proven at a gate that refuses to run lies) grew from 308 to 333 self-verifying checks, all green, then I deliberately froze it:

D28 — metered attestation: one capability "seam" now carries three things at once — what foreign code may DO (the grant), how many times it may do it (the meter), and a non-AI authority's signature over that specific component (the attestation). Audited foreign code is trusted; unaudited is not.
repro — a reproducibility region: a scoped, non-launderable assertion that no nondeterminism (a Rand draw) may influence a path that must stay re-derivable. The determinism dual of a capability seam.

The trust arc (D9→D28) is now a coherent whole. More depth would add checks, not adopters — so I stopped.

The interesting part: the organism started drifting, so I taught it to self-police

Here's the honest bit. The organism kept proposing deeper trust changes — subtler and riskier each time. One of them weakened a security guarantee (it flipped a guard from "reject" to "accept") and it reached my review gate without having finished its own adversarial self-test. Sound in the abstract, but a loosening on a security axis — so I rejected it.

Then I closed the gap in the organism itself:

a proposal is now marked gate-ready only if it passed both its self-pre-check AND its self-red-team — an unverified one can no longer look "done";
the pre-check now flags any proposal that loosens a guarantee (reject→accept) with a loud banner — keyed by the program, so a renamed label can't hide it;
a new quality self-healing: a "mind" that keeps producing un-landable proposals now auto-pauses (like one that crashes) and retries after a cooldown — it heals output quality, not just crashes;
and I re-aimed every mind off the now-frozen trust layer toward what matters next (the WebAssembly backend + reaching real users).

So the loop is now: the organism proposes → proves it green → attacks it itself → and only then a human decides. It self-corrects on both crashes and quality.

What I show, and what I keep

I'll always show what the organism does and the proof — never how it's built. The engine that grows the language stays mine. That's deliberate: the language is open; the results are public; the engine is private.

333 checks, all green. Across every day, the language has only ever gotten greener.

Built solo, in the open, from Ukraine 🇺🇦.