HOWL // HOWLFRAME SYS_ID: HF-CORE-01
[ VIEW ON GITHUB ]
SPEC_VER // 0.1.0 (HFBC v1) AUTHORITY: CAPABILITY-CHECKED

// verifiable ai compiler & capability-checked runtime

HowlFrame

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.

AXIOM // INTENT IS NOT AUTHORITY. Probabilistic language models may propose plans, but execution is bound to deterministic capability gates.
[ CLONE REPOSITORY ] [ VIEW ARCHITECTURE ] [ CLI REFERENCE ]
PIPELINE // PROBABILISTIC INTENT → DETERMINISTIC EXECUTION STATUS: ACTIVE
01 // REASON
Howl AST
AI-native Lisp DSL for structural synthesis and prompt planning.
[PROBABILISTIC]
02 // VERIFY
HFIR Gate
Strict type-checking, capability validation, and JSON verification.
[DETERMINISTIC]
03 // BOUND
Bytecode Compiler
Emits standalone .hfbc bytecode with capability metadata.
[IMMUTABLE]
04 // EXECUTE
Target Execution
Bytecode VM, Native Go, WebAssembly WAT, or Browser JS.
[SANDBOXED]

SECTION // 01 System Overview

HF-MOD-OVERVIEW

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.

SECTION // 02 Architecture & Backends

HF-MOD-ARCH
[SCHEMATIC // COMPILATION_GRAPH] HFIR_FLOW 
.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)

SECTION // 03 Four-Stage Lifecycle

HF-MOD-LIFECYCLE
  1. REASON: AI models author declarative intent in the .howl syntax, avoiding imperative boilerplate.
  2. VERIFY: The HFIR compiler validates schemas, type signatures, and declared capability sets.
  3. BOUND: The bytecode generator emits binary format .hfbc with deterministic instruction limits.
  4. EXECUTE: The runtime environment invokes the code under strict runner capabilities (network, database, filesystem, system).

SECTION // 04 Capability Boundary Matrix

HF-MOD-CAPS

HowlFrame enforces fail-closed execution. OpCodes requiring capabilities are halted unless explicitly granted:

Capability OpCodes & DSL Forms Default Sandbox 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
system env_get, process_spawn DENY (Blocked) Runner flag: -allow-caps system

SECTION // 04B Verifiable Execution & Architecture Q&A

HF-MOD-FAQ

Autonomous AI coding agents generate non-deterministic code. HowlFrame provides deterministic architectural guarantees, preventing unauthorized capability escape through verifiable compiler gates and isolated bytecode execution.

What is an AI-native programming language and intermediate representation?

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.

How does a capability-bounded runtime prevent unauthorized AI side effects?

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), preventing autonomous agent jailbreaks or prompt-injected side effects from escaping the VM sandbox.

How does HowlFrame differ from standard general-purpose runtimes?

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 an explicit capability grant is cryptographically or administratively attached to that specific execution context.

How does HowlFrame integrate with the Howl Ecosystem?

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.

SECTION // 05 CLI Reference & Quickstart

HF-MOD-CLI
[BASH // CLI_COMMANDS] 
# 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.howl

SECTION // 06 Ecosystem Governance & Authorship

HF-MOD-GOV

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