Governed Engineering
A governance system for agent-driven software development: explicit lifecycle state, path authority checked against the actual diff, commit-bound evidence, single-use state-bound approvals — it decides whether an agent's work counts.
The demo runs the product's actual governor — kernel, record schemas, and the CLI's command functions — vendored at a pinned commit, against a real per-run governed repository. The demo agent is deterministic: no AI writes code here, and no model is called. You act as the human owner; no account, no email, no signup.
The problem
A coding agent is not done because it says it is done. Agents produce plausible work at speed — including correct-looking changes nobody authorized, passing tests that prove less than they appear to, and confident claims with no evidence behind them. Review-by-vibes does not scale to agent throughput, and a human approval given yesterday says nothing about the repository that exists today.
What the system does
Governed Engineering makes advancement a governed fact rather than a claim. A project's lifecycle phase is explicit state only a validated transition can change. Work happens in bounded runs: the agent receives permitted and prohibited paths, and the governor compares the ACTUAL git diff against that authority — a violation blocks every transition until it is resolved through a governed path. Completion is derived, never asserted: every declared verification must be executed, its output hashed, and the record bound to the run's exact result commit. Human approvals are single-use instruments bound to the governance digest and git tree at issuance — any change after issuance stales them. The kernel that decides all of this is pure, dependency-free, and versioned; the repository's own records are the only source of truth.
Authority is the architecture
The agent is a replaceable executor inside a governed system — the kernel never even knows which one is running. Work can happen; advancement is governed. Not “AI coding with guardrails”: a deterministic authority model where done is derived from evidence, never asserted.
TASK ──────────▶ AUTHORITY permitted paths · prohibited paths
│ verification obligations
AGENT WORKS ──────┤ bounded run · reserved · digest-bound
│
GOVERNOR CHECKS ──┤ the ACTUAL diff vs the authority
│ GE-RUN-002 blocks everything on violation
VERIFICATION ─────┤ executed · hashed · bound to the
│ run's exact result commit
HUMAN APPROVES ───┤ single-use · digest + tree bound
│ stale the moment the world changes
PROJECT ADVANCES ─┘ a real lifecycle transition, recordedWhat exists today
Every claim here is graded from a source-level inspection of the product repository at the demo's pinned commit. The categories do not blur: implemented in the repository is not production-proven in customer use, an automated pilot is not a human-operated one, and the product's own deliberately open milestone stays open on this page too.
Implemented & self-applied
The governance core the demo runs: the eight-phase explicit lifecycle whose transitions consume single-use approvals; bounded runs with ref reservations, atomic activation commits and digest binding; path authority enforced against the actual rename-correct git diff, with violated runs blocking every transition until a verified revert or a run-scoped human approval; evidence executed through a brokered runner, SHA-256-hashed and bound to the run's exact result commit; approvals and overrides bound to the governance digest AND git tree, consumed on use, stale on drift; journaled, crash-recoverable mutations; and a stable result-code catalogue — all decided by a pure, zero-dependency, versioned kernel. Applied to the product's own repository across twenty-two milestones.
Demonstrated
Everything the working demo shows, through vendored product code at the pinned v0.18.3 commit: the lawful lifecycle walk, the bounded run and instruction, the boundary verdict on the real diff, executed commit-bound evidence, the approval ceremony and its consumption by a real implementation → verification transition, the GE-RUN-002 refusal of correct-looking-but-unauthorized work, the verified-revert resolution, and the GE-APPROVAL-006 / GE-APPROVAL-004 staleness and single-use refusals. Also demonstrated upstream, in pilots: governed adoption of a second mature repository, one GitHub-attested human approval issued outside the agent's reach, and per-release adversarial scenario suites (twenty-one scenarios at v0.18.3).
Implemented; not exercised by this demo
The layers above the core, present and tested in the repository but deliberately outside this demo's envelope: live agent execution with execution envelopes, supervision and honest macOS write-containment; the multi-project coordination service with fenced worker leases, journal-first recovery and reconstruct-from-repositories; the provider-neutral execution-adapter contract with structural tool mediation and a single artifact-ingress gate; governed planning with adoption proofs; portfolio intelligence over an evidence warehouse; the Docker-probed worker fleet; and the operator workbench (five distinct authorities, hash-chained audit, browser-tested) over a versioned API.
In development
The product's own honest gap: milestone M27 — the complete governed workflow operated entirely in the browser — is deliberately recorded INCOMPLETE until a human-operated, two-project pilot passes (scheduled as v0.20 in the product's roadmap); the in-flight v0.18.4 work is closing the browser surfaces that pilot needs. Audit checkpoints export outside the database but are not yet key-authenticated.
Not claimed
Production use by external customers (there is none; the repository is private and pre-1.0), hostile-code containment (the local sandbox is write-containment on a trusted host, stated in the product's own trust model), and authenticated multi-party human intent for the repository's local approvals — the product's own pilot report says those prove the workflow, not authenticated intent; the GitHub-attested issuer exists for the real thing.
The journey the demo proves
TASK → AUTHORITY → BOUNDED WORK → ACTUAL DIFF → VERIFICATION → EVIDENCE → APPROVAL → ADVANCE
The primary refusal
The second task delivers exactly what was asked — and also edits a billing file it was never authorized to touch. The feature works. The tests would pass. The governor compares the actual diff against the task's authority and blocks every transition: GE-RUN-002, resolved only by a verified revert or an explicit run-scoped human approval. Correct work can still be unauthorized.
The secondary refusal
A valid approval exists — bound to the exact governance digest and git tree the owner reviewed. Then one more commit lands. The kernel refuses the old approval (GE-APPROVAL-006) and refuses the already-consumed one too (GE-APPROVAL-004). Approvals are statements about an exact state, not standing permission slips — prior approval can become invalid.
It governs itself
Governed Engineering is developed under its own governance: capabilities are built through governed runs with evidence, and CI rejects invalid governance state. At the demo's pinned commit the product's own repository carries 212 governed runs, 427 commit-bound evidence records, 82 approvals, and a lifecycle history that lawfully moved backward three times — including eight runs that genuinely violated their path authority and were resolved through the governed path. The refusals in the demo are not staged behaviors; they fired on the product's own development.
Honest boundary, in the product's own words: local approvals prove the workflow, not authenticated human intent — the GitHub-attested issuer exists for approvals that must live outside the agent's reach.
Current capabilities
- An eight-phase explicit lifecycle (definition through maintenance) whose transitions consume single-use approval records and are evaluated by a pure, zero-dependency kernel with a stable result-code catalogue
- Bounded runs with ref-based reservations and atomic activation commits: the agent gets authority, not "continue building" — and the governor checks the real, rename-correct git diff against it
- Evidence that is executed, hashed, and commit-bound: verification commands run through a brokered executor with timeouts and output caps, and a record that does not bind the run's result commit does not count
- Approvals and overrides bound to the exact governance digest and git tree, consumed on use, stale on drift — with GitHub-attested issuance for teams that need human approval outside the agent's reach
- A multi-project coordination service (queue, fenced worker leases, journal-first recovery), a provider-neutral execution-adapter contract with structural tool mediation, and an operator workbench over a versioned API
- Self-governance as working proof: the product's own repository is developed under its own governance — hundreds of governed runs, commit-bound evidence records, and CI that rejects invalid governance state on every push
Limitations, stated plainly
- Pre-1.0 and private: v0.18.3, no releases published, no external customer production use. The product's own M27 milestone is deliberately recorded INCOMPLETE pending a human-operated browser pilot.
- The demo agent is deterministic — pre-authored patches through the real run machinery. No AI writes code in this demo, and the demo consumes no model budget at all.
- Demo identities are fabricated and run-scoped through the product's issuer abstraction; the demo does not claim authenticated real-world human intent — which is also the product's documented local-issuer limitation.
- The system is tamper-evident, not inherently tamper-resistant: control state lives in the repository the agent can write to; hashes, digests, pins and history make tampering visible.
- Approval tree-binding covers committed state; runs and clean-tree completion cover the uncommitted surface.
- The product's execution containment is macOS write-containment on a trusted host; this Linux-hosted demo does not rely on it — its isolation is the site's own sandbox architecture (fresh per-request workspaces, token scoping, no visitor-controlled commands anywhere).
- The coordination service, workbench, planning, intelligence and worker fleet exist upstream and are not executed by this demo; the demo runs the CLI-layer governor under the solo-local profile (no PR governance, no GitHub).
Technical shape
A TypeScript monorepo whose trust core is a pure kernel with zero npm dependencies — no filesystem, no clock, no network: the CLI builds a repository snapshot and the kernel evaluates it deterministically, so every governance decision is reproducible from records alone. Governance state lives in the governed repository itself (YAML records, hashed artifacts, git trees), never in a side database that could disagree with it. The public demo vendors the kernel, schemas, templates and CLI command functions at a pinned, hash-manifested commit with a CI tamper check; each run is a real governed fixture repository, materialized into an ephemeral workspace per step (with a pinned git distribution, since the serverless runtime ships none), serialized between steps, isolated per run, and purged completely after 24 hours.
This product is in active development — a deep, self-governed system whose own definition of done is deliberately still open. The demonstration is real: it executes the product's actual governor, and the refusals it shows are the product's actual refusals. The service is not yet shipped, and this page does not pretend otherwise.