Foundation

title
Foundation
type
toolbox
summary
Contract-first Go/Rust/TypeScript full-stack substrate with enforced performance planes and agent gates
tags
golang, rust, typescript, webassembly, full-stack, ai-agents
language
Go, Rust, TypeScript
license
unknown
created
2026-07-23
updated
2026-07-23

Foundation is nmxmxh's attempt to collapse the translation tower in a typical web stack — SQL rows to Go structs to JSON to HTTP to TypeScript interfaces to React state — into a single contract that every layer reads from. Define a mutation once in Protobuf or Cap'n Proto and the schema generates the Go routes, the TypeScript types, and the zero-copy binary layouts across each boundary. It is at version 0.0.1 and the README says so plainly.

Structure

Seven packages, split by boundary rather than by feature. server-kit is the Go backend: event bus, workers, database, resilience, observability, and Hermes. runtime-transport is the TypeScript client wire — command bus, envelope creation, WebSocket with HTTP fallback. runtime-sdk is a Rust/WASM kernel built around a 4KB control buffer and a shared arena. runtime-native is a Tauri shell for secure storage, GPU handles and device access. frontend-kit, ui-minimal and config-contracts cover IndexedDB storage, shared React primitives and cross-language configuration schemas. Underneath: PostgreSQL for durable truth, Redis for coordination, Protobuf for contracts, Cap'n Proto for zero-copy boundaries.

Hermes is the piece the README is proudest of. It maintains node-local, memory-bounded, indexed read models that project database mutations in real time, so reads never touch Postgres. The quoted benchmark has a predicate filter running as a columnar bitmap merge in about 34 µs with 2 allocations, against about 7.8 ms and 10,000+ allocations on a record-chasing path — a 229x claim, self-reported.

Performance planes

Rather than one execution model, Foundation names seven lanes and attaches a measured cost to each:

1. Direct dispatch        10-30 ns/op     (same-process, zero-alloc)
2. Binary frames          20-80 ns/op     (borrowed views)
3. Generated protobuf     ~370 ns/op      (typed cross-process)
4. gRPC                   20-30 µs/op     (network machinery)
5. JSON                   ~30 µs/op       (compatibility)
6. Native FFI/SHM         (varies)        (trusted compute)
7. Browser + WASM + SAB   (platform)      (where supported)

The stated rule is that the fastest lane must not pay the cost of the compatibility lane, and that regressions against these numbers are caught in CI before they land. The lanes are meant to be capability-selected refinements of one visible contract, not seven programming models a developer picks between — the same call runs over SharedArrayBuffer where the browser supports it and falls back to JSON where it does not. See webassembly for the runtime side of that.

The agent angle

Foundation is explicit that its structure exists partly because agents write a lot of the code. The repo ships AGENTS.md, an agent operating contract, an AI threat model, and .cursorrules / .clauderules in generated projects. More concretely it runs 40+ automated enforcement checks it calls Practice Controls — loop boundaries, tenant isolation, contract drift, concurrency safety, complexity thresholds — on every commit, with the argument that machine-decidable gates replace review comments as the thing keeping an agent honest.

That is the same bet as agent-built-deterministic-tools: spend the effort once on deterministic checks, then constrain agent output to what passes them. It is also a direct answer to constraint-decay-backend-agents, where agent quality drops as production structural constraints pile up — Foundation's response is to make the constraints compile-time and machine-checked rather than conventions in a style guide. The author says he reviews and signs off on all modifications, but that many modules, tests and reference docs are agent-authored.

make generate-contracts      # protos -> Go/TS
make verify                  # full CI suite
make check-practice-controls # practice matrix
make check-doc-references    # link validation

Scaffolding a project runs through a Node entry point, from the parent directory of the checkout:

node foundation/cmd/ovasabi/bin/ovasabi.js init --profile=performance --name=my-app \
  --foundation-dir foundation --skip-license

update merges upstream changes to core modules into an existing project. Generated projects are supposed to consume Foundation through package boundaries — importing foundation/*/ts/src or foundation/*/go directly is called out as wrong.

Reservations

Version 0.0.1, one author, everything self-reported. The README names no license, pointing only at a LICENSE file. Every number here is the project's own benchmark on its own workload, and the interesting one (229x on predicate filters) compares Hermes against a record-chasing baseline the reader can't see. The stack it commits you to is large — Postgres, Redis, Protobuf, Cap'n Proto, Rust/WASM, Tauri, React — and adopting the substrate means adopting all of it, so the exit cost is the whole application. The README's own "Work in Progress" section lists agentic coding patterns as still being proven.

Worth watching rather than using: the contract-first codegen plus enforced performance budgets is a real idea, and language-choice-for-agents argues for exactly this direction, but a 0.0.1 with an unnamed license is not something to build on yet.

Repo: https://github.com/nmxmxh/foundation