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

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

1. 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.
2. 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.
3. 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.
4. 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.

1. 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.
2. 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.
3. 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.

4. 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.

5. 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.

6. 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.

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

8. 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.

9. 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

10. Education
    LOOM can teach:
    effect systems;
    capability security;
    linear resources;
    sandbox design;
    provenance tracking;
    circular-trust risks;
    WebAssembly compilation.

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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

18. 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.

19. 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.

20. 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.

21. 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.

22. 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.

23. 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.

24. 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