When I started building verbose, the goal was direct: remove every layer between what an AI expresses and what the processor executes. No LLVM IR. No type-system gymnastics. No framework runtime. Just declared intent, then a binary.

For pure data transformations — filtering records, aggregating fields, emitting native code — that worked. Each .verbose file produced a small, dependency-free ELF binary that did exactly what its source said.

But “real” software talks to the network. And the moment you talk to the network, the layers come back. You import a Rust framework. You configure a service runtime. The source describes the business logic; everything else is library code you trust.

That last sentence kept bothering me.

The standard pattern

Today’s “verified-language” stories usually stop at the boundary of your business logic. Beyond that boundary — accept loops, HTTP parsing, header handling, dispatch tables — lives the framework. The framework is written in another language, by other people, with assumptions you didn’t make.

It’s a perfectly reasonable arrangement. Reusing a battle-tested framework saves you months. The framework’s authors have thought about TCP edge cases you haven’t. For most teams, this trade is correct.

But the source covers less than people sometimes assume. It covers the rules in your handlers. It does not cover the wire. If you want to know what the deployed binary actually does on the network, reading the source is not enough. You read the framework too. Often you only read the source and trust.

What I tried

verbose’s Phase 7 closes this for HTTP/1.0. You declare the service in .verbose:

service router
  listen:
    protocol   : http_1_0
    port       : 18889
    max_request: 2048
  handler: route_request

rule route_request(req: HttpRequest) -> HttpResponse:
  if req.path == "/" then
    HttpResponse { status: 200, body: "Hello from Verbose router!" }
  else if req.path == "/ping" then
    HttpResponse { status: 200, body: "pong" }
  else
    HttpResponse { status: 404, body: "not found" }

The compiler synthesizes HttpRequest and HttpResponse as built-in concepts — they’re part of the language’s vocabulary. The handler is a pure rule, type-checked. The emitter generates the accept loop, the HTTP parser, the dispatch logic, and the response serializer. All native x86-64. No framework underneath. The output is roughly a kilobyte of ELF.

When you run it and curl localhost:18889/, you get exactly what the source says. No middleware silently stripping a path. No default header you didn’t ask for. No dispatch table that diverges from the rules you wrote.

Why this matters to me

The pitch of verbose has always been the same: no layers between intent and machine. For batch transformations, the layers had already been removed. For services, they hadn’t. The framework was sitting there, doing the parts of “what the binary does” that the source didn’t describe.

Phase 7 removes that framework — for HTTP/1.0, anyway. The source becomes the wire format. When you read route_request, you’re reading what bytes will appear on the socket.

This isn’t because frameworks are bad. They’re not. It’s that, for the specific kind of software where someone needs to read the source and understand exactly what’s happening, “go also read the framework” was a hidden dependency. Phase 7 makes the source self-contained.

What this is not

It’s not “every service should be in verbose.” Most services are fine in a Rust or Go framework. The audience for verbose is narrower — software where the source needs to fully describe the behavior.

It’s not “frameworks are wrong.” Frameworks let you ship fast, and that’s a real value. The trade-off is real, and it’s not the same trade-off in every project.

It’s: when reading the source needs to be enough to know what the binary does, the framework underneath has to go away. For HTTP/1.0, it now has.