Skip to content

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.

Agents author Humans gate Claims falsified before trusted

§ 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.

ratifyapproveacceptIntentsettled WHATIdeationverified SO-WHATArcsupervised workStoryone behaviorPlanthe recipeTestthe receiptFeedbackloop closed
  1. Intentemits — the settled WHAT
  2. Ideationemits — the verified SO-WHAT (impact analysis)
  3. Gate · ratifythe analysis is accepted; the arc is authorized
  4. Arcemits — a supervised, decomposed body of work
  5. Gate · approvethe arc plan is ratified before build
  6. Storyemits — one behavior, one session
  7. Planemits — the implementation recipe
  8. Testemits — the receipt (per-criterion evidence)
  9. Gate · acceptthe receipt is accepted; the story lands
  10. Feedbackemits — real use that mints the next intent
waypoint human gate

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.

skeptic-pass · IDB-006 · grounding against apps/planner
▸ 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 …
confirmed 11 corrected 2 added 25 → the skeptics roughly doubled the analysis

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.

D-26-2 · render-origin isolation Ratified

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.
Operator ✎ corrected
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.

T-131 · build-planner allowlist target PASS
story S-131plan P-131 arc AR-026recorded 2026-07-02
  • 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.

SERIAL · ANALYST-DRIVABLEPARALLEL BUILDSERIAL LANDINGIntentVerifiedimpactContractFrontendBackendContracttestsIntegrationslotDeploy· runContract = types + interfaces + 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.

REGULATED OVERLAY · evidence-grade gates + retentionSeedone projectdirect reviewGrowthparallel streamsdelegated reviewPortfoliomany streamsfull env modelINVARIANT CORE — same artifacts: Intent · Arc · Story · Receipt⇄ CARE — steady state re-mints the next intent
TierSeedOne project, direct review. The whole chain, minimal ceremony.
TierGrowthParallel streams with delegated review — the arc model doing the coordinating.
TierPortfolioMany streams, the full isolated-environment model, serial landing at scale.
Overlay ×RegulatedEvidence-grade gates and retention layered onto any tier.
Mode ⇄CareSteady-state operations: telemetry and feedback keep minting the next build cycle.

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.

26Supervised arcs
119Stories
89Receipts

Not a demo built to sell the method. The method, tracked in the thing it built.