The Oasis Method · § 00
How We Build
A verification-first, agent-native way of shipping software — the public edition of the playbook we run on ourselves.
§ 01 · The Premise
Agents author. Humans gate.
The volume of the work — analysis, plans, code, tests — is produced by AI agents. The judgment on everything irreversible is produced by people, at explicit gates, in a single pass. That division is not a detail of the method; it is the method.
First principleAnti-fabrication isn't a feature bolted on at the end. It's the shape of every stage.
The failure mode of AI-built software is not incompetence. It is confident fabrication: a plausible claim, asserted without evidence, that no one checked. A model will tell you the allowlist doesn't exist, the migration is wired to the build, the origin is same-site — fluently, and wrong.
So we don't build a pipeline that trusts its agents and hopes. We build machinery whose entire purpose is to falsify claims before anyone relies on them. Every section below is one more mechanism pointed at that single failure mode.
Volume from agents. Judgment from people. Verification in between.
§ 02 · The Chain
One chain, end to end.
Every unit of work — a typo fix or a quarter-long initiative — travels the same surveyed route. Nothing skips a waypoint, and the points where a human ratifies are marked in brass.
- Intentemits — the settled WHAT
- Ideationemits — the verified SO-WHAT (impact analysis)
- Gate · ratifythe analysis is accepted; the arc is authorized
- Arcemits — a supervised, decomposed body of work
- Gate · approvethe arc plan is ratified before build
- Storyemits — one behavior, one session
- Planemits — the implementation recipe
- Testemits — the receipt (per-criterion evidence)
- Gate · acceptthe receipt is accepted; the story lands
- Feedbackemits — real use that mints the next intent
Intent is the settled what — a ratified statement of what we're building and why. Ideation is the verified so-what: an impact analysis of what building it changes across the system that already exists. An Arc is a supervised body of work, framed and decomposed. A Story is one behavior, sized to a single session. A Plan is the recipe, approved before any code. A Test is the receipt. Feedback closes the loop — telemetry and real use that mint the next intent.
§ 03 · Adversarial Verification
Claims are falsified before they're trusted.
An impact analysis is a set of claims about a codebase. Before any of them is relied on, skeptic agents attack it against the real code: each claim is confirmed, corrected, or refuted — and the impacts the analysis missed are dragged into the light. The draft gets no vote in its own defense.
▸ reading 47 cited artifacts + 1,312 files under codeRoot ▸ verdict per claim ────────────────────────────────── #03 "build-planner.mjs ships with no allowlist" REFUTED allowlist at build-planner.mjs:41 #07 "render + app share one origin" CORRECTED separate origin (ofusercontent.com) #09 "digest is unaffected by the JS flag" CONFIRMED render-tier only · DEC-036 #11 "no tenant scope on requirement.list" CONFIRMED where() missing · handler.ts:88 … 9 more confirmed … ▸ gaps the draft never mentioned ───────────────────── + migration 0017 not wired to buildCommand ADDED + OAuth token carries role bitmap — no DB on path ADDED + canvas CSP blocks localStorage in sandbox ADDED … 22 more added …
On a real pass the skeptics returned eleven claims confirmed, two corrected, and twenty-five impacts the original never mentioned — nearly doubling it. The draft was useful. The verified analysis was trustworthy. Those are not the same document, and only one of them is safe to build on.
The principleClaims are falsified before they're trusted — not asserted and hoped over.
§ 04 · Gates
Decisions surface up front, in batches.
Agents don't reach a fork, guess, and hope you agree later. When a decision is irreversible they halt and surface it — options, a recommendation, the rationale — and batch the open questions so you ratify them in one pass. Then the build runs to completion without stopping to ask.
The recommendation is a starting point, not a verdict. The gate exists precisely so a human can overrule it — and the ones that matter most are the ones where they do.
How should artifact HTML be isolated from the app?
AI-authored canvas artifacts execute untrusted HTML/JS. Where should they render?
- ASubdomain of oasisfactory.com, sandboxed iframe. Ships today; cookies stay same-registrable-domain.
- BSeparate cookieless registrable domain recommended Anthropic's *.claudeusercontent.com model. New domain to provision.
- CSame origin, allow-scripts only. Cheapest; leans entirely on the sandbox holding.
Not A. A shares our registrable domain — one sandbox escape reaches session cookies. A separate cookieless origin is the only isolation that survives a bad artifact. Ship B; provision the domain first.— jmcmunn · 2026-06-24 · overrode recommendation A → B
A specimen decision card. The agent recommended the fast option; the human took the safe one. That reversal is the whole reason the gate exists.
§ 05 · Receipts
Every story leaves a receipt.
A story isn't done because an agent says so. It's done because it produced a receipt: each acceptance criterion marked pass or fail against falsifiable evidence — a file and line, a test name, an assertion count — plus the exact commands to reproduce the verification yourself, and a record of what surprised us on the way.
- AC-1 · PASS Emits dist/planner only from the allowlist. build-planner.mjs:41–58 · test emits only allowlisted targets · 6 assertions
- AC-2 · PASS Non-allowlisted paths are refused, not silently dropped. build-planner.test.mjs:70 · throws on unlisted target · 3 assertions
- AC-3 · PASS Clean build, no type errors. pnpm build · 0 errors · tsc --noEmit green
Reproduce
$ pnpm --filter @oasis/planner build $ node scripts/build-planner.mjs --check-allowlist $ pnpm --filter @oasis/planner test build-planner
Surprises
- The allowlist already existed at build-planner.mjs:41 — the draft impact analysis claimed it didn't. The skeptic pass caught it; the story shrank accordingly.
- Migration 0017 is applied by db:migrate:ci but the Vercel buildCommand never invokes it — logged as a follow-up, out of this story's scope.
Evidence, not assertion. Every verdict points at something a reviewer can open. The surprises section is institutional memory.
§ 06 · Parallel by Contract
A contract lets the halves build at once.
The pipeline has a front half and a back half. The front — intent to verified impact — is analyst-drivable and strictly serial. It ends when a contract is ratified: the types, the interfaces, the schema deltas, fixed in writing.
Once the contract is fixed, frontend and backend build against it in parallel. They never see each other's uncommitted code; they meet at contract tests, integrate in isolated environment slots, and land one at a time.
Parallel integration. Serial landing.
§ 07 · Delivery Patterns
One method, fitted to the engagement.
The artifacts don't change from a solo project to a portfolio — only the shell around them does. Engagements run in fitted tiers, and an engagement can climb a tier without retooling, because the core is invariant.
Invariant core, variable shell.
Because the artifacts are identical across tiers, engagements progress instead of restarting — the same receipts, gates, and chain, whether you're one project deep or running a portfolio under a regulated overlay.
§ 08 · The Proof
The system built itself.
Oasis is the first project tracked in Oasis. The methodology on this page isn't a whitepaper — it's the machinery that produced the machinery, and every arc, story, and receipt of its own construction is recorded inside it.
Not a demo built to sell the method. The method, tracked in the thing it built.