TECHNICAL APPROACH CREDIBILITY
Before asking a public body to trust an AI agent with its work, we publish the controls we run on ours. This is an assurance page, not marketing: every control below maps to a real file or workflow in the repository, so it can be checked rather than taken on trust.
| Control | What it does | Where it lives |
|---|---|---|
| Branch-per-issue, draft-PR-only workflow | Every change ships on an isolated branch as a draft pull request. Nothing merges to main without explicit human approval. | AGENTS.md |
| Protected-path merge gate | Certain paths, including the main site-routing file, require James's explicit merge approval regardless of CI status -- no automated process can merge them. | AGENTS.md |
| One-active-PR-at-a-time discipline | Only one unreviewed development package is in flight at a time unless parallel work is explicitly authorised, keeping the reviewable surface bounded. | AGENTS.md |
| Revision-bound approval gate | An automated code change can only be proposed for a GitHub issue that carries an exact approval comment matching the repository, issue, title, body and the full current main commit SHA. Editing the issue or advancing main invalidates the approval. | ops/engineering-agent/approval-gate.mjs |
| Inert-by-default execution workflow | The isolated engineering executor has no automatic trigger. It requires a separate, absent-by-default enabling variable, and a documented list of unmet infrastructure prerequisites (branch protection, environment secrets, a scoped publisher identity, a model budget) before it can ever run. | .github/workflows/engineering-agent.yml, ops/engineering-agent/README.md |
| Bounded candidate change policy | An automated change is restricted by file count, line count and byte-size caps, a path allowlist that excludes secrets, wallet, payment and CI-workflow paths, and active scanning for secret-shaped text before it is ever applied. | scripts/engineering-agent/candidate-policy.mjs |
| Human-labelled delivery ignition | The delivery loop that turns an approved issue into a pull request only ever acts on issues a person has explicitly labelled ready, and fails closed on any ambiguity. | scripts/engineering-agent/delivery-loop.mjs |
| Observe-only engineering monitor | A separate, isolated worker service with no production, payment, wallet, model or deployment credential. It only reads public endpoints and GitHub, and records redacted, hash-chained audit events. | ops/engineering-agent/observer.mjs |
| Service-lifecycle watchdog | Every paid service's health state (healthy, degraded, stale, quarantined or retired) is tracked continuously from real delivery outcomes, not asserted informally. | src/service-lifecycle.ts |
| Data-quality reporting layer | A dedicated service reports data-quality metrics about the platform's own evidence as a paid, inspectable product, rather than an internal claim. | src/data-quality-intelligence.ts |
| Fail-closed evidence discipline | Missing or stale evidence is reported as unavailable rather than silently estimated or defaulted, applied consistently across the intelligence catalogue. | src/forecast.ts and the wider service catalogue |
| Email-agent authority boundary | The email intake worker may only send fixed, pre-approved acknowledgement templates. It cannot make commitments, contact third parties or send an AI-generated substantive reply without separate human approval, and has a global kill switch. | ops/email-agent/README.md, ops/email-agent/policy.mjs |
WHAT THIS DOES NOT CLAIM
The gated engineering executor referenced above is not currently active in production -- it requires a separately approved enabling variable and infrastructure that is not yet in place. Naming it here is a statement about the control design, not a claim that autonomous merges are happening today.
Last reviewed: 4 September 2026.