HowlFrame v0.2.0

HowlFrame v0.2.0

What it is

HowlFrame is an experimental AI-native language and capability-governed execution runtime. Its principle is
intent is not authority: programs may compute and propose, while the runner's explicit grants decide which
effects (files, processes, network, environment, stores) can happen. HowlFrame is not an OS sandbox and is not safe
for arbitrary hostile code.

Highlights since v0.1.0

• Applications accepted against frozen requirements. Milestone 1: LedgerLens, HealthWatch and TaskFlow (CLI).
  Milestone 2: TicketDesk (HTTP API with authentication, authorization and restart-safe persistence). Milestone 3:
  EvidenceDesk (local full-stack service and browser UI); HowlBoard's ledger import validates input with EvidenceDesk's
  ledger module. The Milestone 1 and 2 suites run in CI on every change.
• Language and runtime. A numeric contract with exact int64 and float64 (docs/reference/NUMERIC_CONTRACT.md),
  modules with use, records and JSON forms, read_stdin, HTTP request accessors, a native store, and core library
  forms such as %, //, range, sort_by and pad_left.
• Governed effects. Path-scoped filesystem:read= / filesystem:write= grants, process:exec= program
  allow-lists, host-scoped network:fetch= grants with destination checks, process:env= refusals for
  execution-steering variables, Linux exec descendant containment, and VM budgets for instructions, call depth,
  allocation, wall-clock time, exec output, fetch bodies and request bodies. inspect --caps, --profile governed
  and --receipt report what a program needs and what it did.
• Artifacts. HFBC format 2 serializes deterministically. howlframe interop --json describes the toolchain for
  other tools.
• Numeric contract enforced. Float +, - and * that overflow raise floating-point overflow instead of
  producing +Inf, -Inf or NaN; out-of-range literals fail check; confidence refuses non-finite answers; the VM
  refuses artifacts with non-finite constants.

Breaking changes

• Artifact format 2. v0.2.0 writes HFBC format 2, which v0.1.0 rejects (unsupported artifact version: expected 1, got 2). v0.2.0 still loads format 1 artifacts but runs them under current semantics; see Compatibility.
• Capability grants are narrower. A bare process grant no longer authorizes exec (use
  process:exec=<absolute path> [patterns]), the coarse network grant no longer authorizes outbound fetch (use
  network:fetch=<host>), the model-call forms need network, and process:env=NAME refuses code-loading and
  execution-steering names.
• Numeric errors. Float overflow, NaN or infinity from to_float, division by zero and out-of-range literals are
  errors rather than values.
• map_get of a missing key returns nil (it returned "" in v0.1.0); test with is_nil or map_has.

Compatibility

	v0.1.0	v0.2.0
howlframe version	HowlFrame 0.1.0, HFBC format: 1	HowlFrame 0.2.0, HFBC format: 2
Writes	Format 1	Format 2
Reads format 1	Yes	Decodes; behavior can differ (store_open fails closed, spawn_agent runs or fails closed depending on its form, map_get of a missing key, non-finite numerics, narrower grants)
Reads format 2	Rejected	Yes

Unreleased main builds from 2026-10-01 until this release printed HowlFrame 0.1.0 while writing format 2. Details:
docs/reference/artifact_compatibility.md. Recompile .howl sources with v0.2.0 unless an artifact must also run on
v0.1.0.

Installation

Archives are named howlframe_v0.2.0_<os>_<arch>.tar.gz (.zip for Windows) and contain one executable. Verify them
against SHA256SUMS. Full instructions: docs/installation.md.

curl -fLO https://github.com/howlcipher/howlframe/releases/download/v0.2.0/howlframe_v0.2.0_linux_amd64.tar.gz
curl -fLO https://github.com/howlcipher/howlframe/releases/download/v0.2.0/SHA256SUMS
sha256sum --check --ignore-missing SHA256SUMS
tar -xzf howlframe_v0.2.0_linux_amd64.tar.gz
./howlframe version

Platform	Status
Linux x86-64	Built, executed, acceptance suites passed
Linux ARM64	Built, executed under user-mode emulation only
macOS x86-64 and ARM64	Built, not executed
Windows x86-64	Built, not executed

First program

(cli_app
  (print "Hello from HowlFrame"))

howlframe check hello.howl
howlframe build hello.howl
howlframe run hello.hfbc

Known limitations

• Exec containment stops runaway descendants on Linux, but a program that kills its own supervisor can leave a
  detached descendant running (#216). On macOS and BSD session-escaped descendants are not contained, and on Windows
  only the direct child is (#217). Run programs that need process:exec on Linux.
• process:env= is a deny-list (#182); grant only the variables a program needs.
• Generated Go uses Go's numeric semantics for +, - and * (integer overflow wraps, float overflow is +Inf).
  Use the standalone VM for numeric policy decisions.
• Source has no exponent literals: write 1e10 as digits or (to_float "1e10").
• An invalid resource limit exits with status 1 on some paths and 2 on others; either way nothing runs.
• Release binaries and artifacts are not signed. macOS and Windows binaries have not been executed in the release
  evidence.
• Standalone bytecode covers a defined subset of the language; Go remains the broadest backend, and Wasm is narrower.

Security non-claims

HowlFrame is a capability-governed runtime, not a sandbox. Capability checks, instruction limits and grants are
logic-level restrictions inside the host process, not an operating-system isolation boundary. It is not formally
verified and not production security infrastructure. Run untrusted code only inside external isolation such as a
container or VM. See SECURITY.md.

Verification

The release-candidate evidence (numeric correctness, compatibility, test results, security classification and the
independent review) is in docs/release-readiness/v0.2.0/.

HowlFrame v0.1.0

HowlFrame v0.1.0

What it is

HowlFrame is an experimental AI-native language and capability-bounded execution runtime.

Why it exists

The governing principle is simple: intent is not authority.
LLMs are good at producing structure but often lose time on syntax details and large rewrites. HowlFrame keeps the source grammar small and uniform so generation can be constrained and validated before runtime. Adaptive operations may reason and propose, but deterministic machinery continues to own permissions, capability grants, and approval.

Compiler/runtime pipeline

.howl
→ parser/checker
→ HFIR verification
→ bytecode compiler
→ .hfbc
→ VM

Key capabilities

The HowlFrame bytecode runtime explicitly tracks and enforces capabilities: network, filesystem, process, environment, and database.

Intent is not authority

Capabilities are denied by default. The standalone HowlFrame VM independently enforces capability and state-transition policy based on what the runner explicitly grants.

Applications proved

• Status API
• Log Analyzer
• KV CLI
• Todo CLI
• Task API
• Release Authority
• Action Executor
• Repo Analyst

Known limitations

HowlFrame is highly experimental:

• Standalone bytecode supports a defined subset of the language.
• Go remains the broadest backend.
• Wasm support is narrower.
• Not all backends have semantic parity.
• HowlFrame is not an OS/container/hypervisor sandbox.
• It is not formally verified.
• It is not production-ready security infrastructure.
• Native x86/ARM compilation is not claimed.

See the Coverage Matrix for detailed information on what is supported per backend.

Security non-claims

This is not a safe arbitrary code execution environment or a formal sandbox. It relies on internal instruction counting and capability gating, which is a logic-level restriction, not a strict isolation boundary provided by the OS.

Installation

Binaries for Linux, macOS, and Windows are attached to this release. Extract the binary and place it in your PATH.

First program

Create hello.howl:

(cli_app
  (print "Hello from HowlFrame")
)

Compile and run:

howlframe check hello.howl
howlframe build hello.howl
howlframe run hello.hfbc