DEV Community: umbra

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 🇺🇦.

Day 6: my language now compiles to WebAssembly — and I emit the bytes by hand

umbra — Fri, 26 Jun 2026 21:22:32 +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 anymore: an organism I built grows it, day and night, on my own machine. This is Day 6, and the whole day went to one thing — WebAssembly.

Why this was a real test

LOOM already runs three ways: an interpreter, and backends that compile checked code to Python and JavaScript. The thesis is "trust survives translation" — effects and provenance, proven once, hold the same on every target. WebAssembly is the strongest test of that: a low-level stack machine with linear memory, nothing like Python or JS.

And there was a constraint. This machine's clang has no wasm target, and I install nothing paid or heavy. So I don't compile to wasm through a toolchain — I emit the wasm bytes myself (LEB128, the type / function / memory / global / export / code sections, the i32 stack machine) and run them through node's built-in WebAssembly. Zero dependencies.

From `fib` to a value runtime, in a day

Every step was prototyped and proven (wasm output == interpreter output) before it touched the kernel:

The integer core — arithmetic, comparison, if, first-order calls and recursion. fib(10) becomes 61 bytes of real WebAssembly and returns 55, identically on the interpreter, Python, Node and wasm.
A value runtime — let and integer lists in a real linear-memory heap (a bump pointer + a $cons cell allocator; head/tail are i32.load, empty is i32.eqz). A list sums and folds by recursion, inside wasm.
Sum types — (variant Tag e) becomes a tagged cell [tag-id | payload]; match loads the tag, compares, binds the payload, branches.

You can watch it: the live playground has a Compile → WAT button and WASM · fib / list-sum / match examples. Type a program, see it become real assembly, in your browser.

Honest scope: ints, let, integer lists and sum types compile to wasm today. Records, closures and effects are the next frontiers (closures are the hard one — a function table plus a heap environment). Anything outside the supported set fails closed — it never emits wrong code.

The part I didn't write

While I worked on wasm, the organism worked on the trust layer. I'd landed D26 — a rule that provenance does not survive an opaque foreign (FFI) call, so the host can vouch for what foreign code is granted but never for what it returns. D26 left an honest gap in its own comments: a vetted, signed library was treated no better than an arbitrary .so.

The organism, on its own overnight pass, proposed the answer — and I reviewed it and landed it. (vouch ROLE WHO COMP): a non-AI authority signs a specific foreign component, so that component's output carries the authority's anchor instead of being stripped. It's an attestation — traceability to a named, non-AI auditor of that exact component — not a claim the component is correct. It fails closed everywhere (an AI vouching for itself, a name mismatch, a value laundered through the call — all rejected). A machine I built found and closed a gap in my own design.

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

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

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

I don't write my language by hand — an organism grows it (Day 5)

umbra — Fri, 26 Jun 2026 14:29:06 +0000

▶ Try it live: https://umbraaeternaa.github.io/loom/play.html

I'm building a programming language. But here's the strange part: I barely write it by hand anymore. An organism I built grows it for me — day and night, on my own machine. This is Day 5, and it did something worth stopping for.

Let me be literal about what "an organism grows it" means in practice — and about the one line I deliberately won't cross.

What the organism actually does

Every cycle, on its own, it:

watches the frontier of languages and security,
proposes a concrete change to the language's kernel,
proves that change in a sandbox — does the whole suite stay green or not,
and then — the part I've never seen an "assistant" do — it adversarially attacks its own proposal, writing programs designed to break the very feature it just suggested.

Only what survives both the proof and the attack lands on my desk. I'm not the author of every line; I'm the final, human gate that says "yes."

How it works inside — its architecture, its "mind" — I keep to myself. That's the edge, and I'm not handing it out. What I publish is results, each one backed by a proof you can re-run.

Today's result (D26): trust that doesn't survive a foreign boundary

LOOM is a machine-checked trust layer for AI-written code. It tracks two things at a gate: what code is allowed to do (its effects, granted through a capability seam) and where a value's authority came from (provenance).

But trust had only ever flowed inside host code. The moment your program calls something foreign and opaque — a third-party library, a plugin, anything across a boundary you don't control — there was a quiet hole:

(trust (seam (Pure) (ffi "x" (prov human 5)))) ; used to type-check — it shouldn't

You can grant foreign code exactly the powers it needs (its effects). But you can never vouch for what it returns. The host vouched for what went in, never for what came out.

The organism noticed this, proposed the fix, proved it (275/275) and attacked it (13/13). Now a value that crosses the foreign boundary loses all of its anchors and is untrusted-by-default:

prov_of((ffi ..)) → {ai} — every inner anchor dropped.
roles_of((ffi ..)) → ∅ — no role vouch survives.

Re-earning trust requires a live host re-vouch placed outside the foreign call, or an explicit, attributable declassify. It's the exact dual of crossing a persistence boundary (recall) — now on the interop axis. The same seam now bounds both axes at the foreign edge: what foreign code may do, and what its output may claim.

The part that makes it real, not a toy

This week I pointed the organism's auditor at a real, running security system — not a textbook example. It found genuine lies about what the code actually does (functions claiming to be pure while quietly reaching into the environment and the filesystem; an advisory AI signal that could be forged into a privileged action). It machine-proved each one against the live checker. We fixed them.

A machine that checks other code for honesty, catching real defects in a live product. That's the whole thesis, demonstrated on production code instead of a slide.

By the numbers

275 checks, all green. Across every day of this project, the language has only ever gotten greener — not a single step back. And the headline feature today was proposed, proven and red-teamed by the organism before I looked at it.

Where this goes next

A browser playground — so you can try LOOM live, in a tab. Then C / WASM backends, and a deeper information-flow lattice.

Built solo, in the open, from Ukraine 🇺🇦. No company, no funds — just this idea.

⭐ Code (MIT): https://github.com/umbraaeternaa/loom
🌐 Site: https://umbraaeternaa.github.io/loom
☕ Support: https://send.monobank.ua/jar/AHaziFXjYX

I'm building a programming language — but I'm not growing it alone

umbra — Thu, 25 Jun 2026 18:31:10 +0000

▶ Try it live: https://umbraaeternaa.github.io/loom/play.html

The world increasingly trusts AI to write code. But if the author is a machine you can't trust on its word, how do you know what the code actually does? Today's answer is "read it and hope." I wanted better.

LOOM is a tiny language that makes what code is allowed to do machine-checkable, and refuses to run anything that lies about it. "AI proposes, the compiler disposes."

In a few days it grew into a trust layer for AI-written code: it checks not just what code does, but who vouches for it — demanding independent, non-AI corroboration. Open (MIT), self-verified by 221 checks that can only grow greener, and now cross-platform — one verified program runs identically on Python and JavaScript.

The unusual part: I didn't grow it alone. An autonomous research organism develops it daily — and this week it learned to pre-check its own proposals in a sandbox and adversarially attack them before I even look. It proves its work; it doesn't ask me to trust it. How the engine works, I'm keeping to myself.

Built solo, in the open, from Ukraine 🇺🇦 — ⭐ github.com/umbraaeternaa/loom

DEV Community: umbra

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

What makes it different

Day 12 — we taught the language to own its memory

The part people don’t expect

Where this is going

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Where this is going

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

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

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

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

What I show, and what I keep

Day 6: my language now compiles to WebAssembly — and I emit the bytes by hand

Why this was a real test

From fib to a value runtime, in a day

The part I didn't write

I don't write my language by hand — an organism grows it (Day 5)

What the organism actually does

Today's result (D26): trust that doesn't survive a foreign boundary

The part that makes it real, not a toy

By the numbers

Where this goes next

I'm building a programming language — but I'm not growing it alone

From `fib` to a value runtime, in a day