// verifiable ai compiler & capability-checked runtime
HowlFrame is a verifiable compiler, intermediate representation (HFIR), and bytecode runtime designed to enforce capability boundaries on AI-assisted software systems. Engineered by William Elias as the execution capability foundation of the Howl Autonomous Software Engineering Ecosystem.
-compile-bc emits standalone .hfbc from the AST. Experimental -compile-hfir-bc is the dogfood lowerer.Modern AI agents generate code through probabilistic prediction. Giving them direct access to production execution environments creates severe security vulnerabilities and architectural drift.
HowlFrame introduces a formal boundary between reasoning and execution. Instead of emitting raw executable code, models author structured, type-checked specifications in Howl. The HowlFrame compiler verifies these specifications against intermediate representations (HFIR), strips unauthorized capabilities, and compiles only validated logic into target environments.
.howl Source Code
│
▼
Parser & AST Construction
│
▼
HFIR Generator & Type Verifier
│
├─────────────────┬─────────────────┬─────────────────┐
▼ ▼ ▼ ▼
HFBC Bytecode Native Go WebAssembly Browser JS
(VM Execution) (Go Backend) (WAT Backend) (web_app DSL)
Production -compile-bc runs the HFIR gate and then compiles the checked AST. Experimental -compile-hfir-bc lowers a bounded subset onto the opcodes that compiler already emits, and it is the dogfood path. Improvement #90 stays Partial. The production flip is deferred: the Assurance tip-lock of 4d74dbcf is Overall PASS and Promote DEFERRED.
Generated Go and JavaScript mediate env, exec, read_file, write_file, mkdir, and fetch on the same grant names as the bytecode VM. An optional (fetch) body stays off OpFetch on both bytecode compilers.
Lowered-HFIR ABI v1 · Production flip criteria · Fetch-body bytecode design · HFIR execution status
.howl syntax, avoiding imperative boilerplate..hfbc with deterministic instruction limits.network, database, filesystem, system).HowlFrame enforces fail-closed execution. OpCodes requiring capabilities are halted unless explicitly granted:
| Capability | OpCodes & DSL Forms | Default Policy | Enforcement Mechanism |
|---|---|---|---|
network |
http_server, fetch, listen |
DENY (Blocked) | Runner flag: -allow-caps network |
database |
store_open, store_put, store_get |
DENY (Blocked) | Runner flag: -allow-caps database |
filesystem |
file_read, file_write |
DENY (Blocked) | Runner flag: -allow-caps filesystem:read=/data,filesystem:write=/out (native VM; filesystem remains unrestricted) |
system |
env_get, process_spawn |
DENY (Blocked) | Runner flag: -allow-caps system |
Autonomous AI coding agents generate non-deterministic code. HowlFrame checks programs before they run and denies undeclared effects by default in its bytecode VM. It is a capability-governed runtime, not an OS sandbox: capability checks run inside the host process, so untrusted code still needs external isolation such as a container or VM.
Standard programming languages assume human authoring and permit arbitrary side effects by default. HowlFrame treats AI code generation as an untrusted intent stream. The Howl AST captures structural intent, while HowlFrame Intermediate Representation (HFIR) enforces explicit type constraints, verified capability requirements, and deterministic state validation prior to compilation.
HowlFrame bytecode (.hfbc) executes in a capability-checked virtual machine where all external interactions (network access, native store persistence, filesystem mutations, system process invocation) are denied by default. Privileged operations require explicit runner capability flags (e.g. -allow-caps network,database), so a prompt-injected or mistaken program cannot use an effect the runner did not grant. These are logic-level checks inside the host process, not OS isolation; see SECURITY.md.
General-purpose runtimes (Node.js, Python, standard Go) allow arbitrary I/O whenever an imported package invokes it. HowlFrame isolates capabilities at the instruction level. AI-generated modules cannot read environment variables, open sockets, or mutate local disk unless the runner explicitly grants that capability for that execution.
HowlFrame serves as the core capability runtime beneath HowlPlane (orchestration and control plane) and HowlChangeOps (governed mutation controller). HowlBoard is the canonical reference application and human-facing operations interface, with HowlNotes alongside it; both dogfood the bytecode VM and native store to verify real-world resilience across state transitions.
# 1. Compile Howl source to Bytecode
howlframe -compile-bc -o output.hfbc input.howl
# 2. Run Bytecode VM with explicit capabilities
howlframe -run-bc -allow-caps network,database output.hfbc
# 3. Transpile Howl to Native Go
howlframe -compile-go -o main.go input.howl
# 4. Transpile Howl to WebAssembly WAT
howlframe -compile-wat -o module.wat input.howlHowlFrame was designed and engineered by William Elias as the foundational capability-checked virtual machine and compiler for the Howl Ecosystem.
It operates in strict coordination with HowlPlane (deterministic control plane and task orchestration), HowlChangeOps (governed git mutation and cryptographic release authority), HowlRelay (persistent multi-session handoffs), HowlWriter (style-preserving writing control), and HowlCreate (exploratory ideation), with full-stack evaluation dogfooded across HowlBoard and HowlNotes.