Understand the system.
Show the evidence.

From one answer to an experiment.

GENESIS turns a programming goal into a population of competing Python programs. It executes them against frozen tests, selects verified survivors, and uses their code and development feedback to generate another generation.

The important output is more than source code: it is the record of what ran, under which constraints, against which inputs, and with what results. Evolution can improve a solution, but improvement is measured rather than assumed.

A clear boundary between creation and judgment.

The browser presents experiments. FastAPI owns orchestration, tests, scoring, and persistence. AI creates candidate source. CreateOS executes that source in isolated microVMs; it does not decide the score.

Expected answers remain in the backend. The sandbox receives candidate source and input only. The engine compares actual stdout with expected JSON and saves the result after each test.

Stripe Projects provisioning and public hosting are deferred. The current application runs locally with PostgreSQL; it does not claim a completed Stripe deployment.

Generate. Execute. Evaluate. Evolve.

1. Freeze the challenge and tests.

   Preset benchmarks use deterministic reference oracles and a stored seed. Custom challenges use a supplied suite or an AI evaluator followed by a blind verifier. Tests are validated and hashed before candidate generation.

2. Create genuinely different programs.

   The creator receives the goal, constraints, a generation strategy, parent code, and development feedback. Duplicate source hashes are retried up to three times. All programs use the Python standard library and JSON stdin/stdout.

3. Execute and select.

   Each candidate runs in its own CreateOS sandbox. The engine records every case, computes development and holdout grades separately, and marks a candidate verified only if both groups pass completely. Source that exceeds the byte limit is rejected before execution, without a score.

4. Build the next generation.

   Elitism copies and retests the best verified parent. Mutation works from one parent. Crossover uses two verified parents when available. If there are no verified parents, the engine creates new candidates.

5. Adapt strategies, then audit.

   Strategy trials rank actual holdout results while reserving the last candidate slot for exploration. Changing constraints resets these trials and preserves their history. A preset winner receives a fresh seeded final audit after selection; audit results never feed back into evolution.

Correctness first. Performance second.

Preset sorting, stable deduplication, and interval merging use six development cases and three holdout cases. Cases include boundary conditions and seeded random inputs. Custom suites allow 4–24 development and 2–12 holdout cases, with no shared inputs between groups.

A pass requires valid finite JSON equal to the expected result, a successful exit, no timeout, and bounded output. A high development score alone does not make a survivor: every holdout case must also pass. Interrupted evaluation and source-limit rejection have no fitness score.

The creator receives development failures, not holdout expected answers. Because strategy adaptation uses holdout results, holdout is not a permanently untouched benchmark. The fresh final audit is the separate post-selection check for presets.

Generated code executes outside the app.

• CreateOS provides a microVM boundary with closed ingress and a host-enforced non-routable outbound allowlist.
• Candidate Python runs with isolated interpreter mode, UID/GID 65534, a clean environment, and read-only uploaded source.
• The runner imposes wall time, CPU, memory, process, file size, open-file, and output limits. API keys and the lab token never enter the candidate environment.
• Tests, expected answers, and grading remain outside the microVM. Candidate stdout is treated as data.
• Each sandbox is destroyed after evaluation. Failed cleanup preserves its ID for retry; auto-pause is not deletion.

Draft prompts and the private lab token are kept in React memory, never in URLs or browser storage. Reloading or opening another tab requires unlocking again. Local setup saves provider credentials in an owner-only, ignored environment file; public hosting requires HTTPS and hosting secrets.

Goals, parent source, and development feedback go to the selected AI provider. Source and inputs go to CreateOS. Avoid putting secrets or personal data in challenges.

Your brief, a real website, and visible progress.

Choose Website on the home page or a new workspace project. Select Developer portfolio to try a complete frontend brief. Unlock the workspace, review Build settings, and choose Build website. The default makes one candidate in each of two passes. Website builds use the saved AI connection and a separate browser worker; they do not need CreateOS or Stripe.

1. Plan.

   The AI publishes a concise design plan and freezes a section checklist for this request. AI progress shows real timestamped actions and results, not private model reasoning.

2. Build and check.

   The AI generates a self-contained HTML/CSS/JavaScript website. Isolated Chromium renders the source at desktop and phone sizes, captures real screenshots, checks overflow at 1280, 390, and 320 pixels, scans automated WCAG A/AA rules, and tests mobile navigation and JavaScript errors.

3. Refine.

   The next pass receives the actual browser findings and selected parent source. Every version remains saved, including failures. The chosen version has the most passing checks; visual quality still needs your review.

4. Make it yours.

   Use the sidebar to request a change from the selected version. Preview supports interactive desktop/phone views and saved screenshots. Code includes a file explorer, package list, startup guide and parent diff. Checks explains observed results. Versions lets you switch iterations. Download saves a ZIP with index.html and a README; Evidence exports the project record.

Preview and browser boundaries

Preview scripts run in an opaque-origin sandboxed frame. Network requests, forms, popups, and workspace access are restricted. The browser worker has no provider keys or host mounts and uses a private Docker network. Its container has resource limits and a read-only root filesystem. Chromium's additional OS sandbox is not enabled; this local configuration is not a hardened public multi-tenant service.

Progress refreshes about every 1.5 seconds. Individual AI calls may take up to 90 seconds. Stop retains saved versions; a restart marks active work interrupted. Screenshots persist in a separate artifact volume. Ten follow-up revision requests are allowed per project.

A working app, with evidence.

Choose Full-stack to build a task board with real login, saved tasks, search, status filtering and role-based access. The AI generates the frontend against a supplied trusted backend. This release supports this task-board blueprint.

1. Build and preview.

   Start with one candidate and one pass. The preview signs in with a short-lived app owner session. Create a task and change its status: records persist in PostgreSQL.

2. Inspect the backend.

   Open Backend to create editor/viewer accounts. Sign out inside the app to test a user. Viewer accounts cannot write, including through direct API calls. Generated code cannot change the permission rules.

3. Check and compare.

   Checks use expiring real test accounts and database records. Compare opens mobile captures for full-stack projects and separates repaired failures, newly verified checks and regressions. Use Expand workspace for a larger view and Escape to return. CreateOS proof opens clearly labelled recorded Python execution evidence. Inspect failed and unchecked results before presenting.

4. Download and run.

   Download exports a runnable project ZIP with the selected frontend, trusted API, setup guide and Dockerfile. Install Python 3.11 or newer, unzip the download, then double-click Start.command (macOS) or Start.bat (Windows). The launcher installs packages, checks them, helps create the first account and opens the app. Existing local users and tasks are retained on later starts. It excludes saved users, data, keys and sessions. Evidence exports the separate verification record.

The generated preview has an opaque origin and no direct network access. A narrow validated bridge uses app-scoped sessions; workspace/provider secrets never reach generated code. Browser isolation currently relies on the container; the extra Chromium OS sandbox is unavailable on this host. Automated tests do not certify complete security.

Workspace access supports administrator-created accounts with private project histories. The first administrator account can access existing owner projects. Reloading clears the in-memory session; sign in again.

Record a user test · Tester guide · Blank feedback form · Presentation outline

Working in GENESIS.

Start the lab with your own credentials.

Requirements: Python 3.11+, uv, Node 22+, npm, and Docker Desktop. Run these commands from the repository root. The backend uses one worker and supports one active experiment.

uv sync --directory backend
npm ci --prefix frontend
python3 scripts/secure_setup.py

Open http://127.0.0.1:8765, enter the provider keys, AI model ID, and HTTPS API base URL. Save the displayed lab token privately and stop the setup server after saving. Never paste keys into chat or commit them.

python3 scripts/start_lab.py

Open http://localhost:3000, choose Workspace, then Unlock workspace. Review the prompt and Run settings, then submit explicitly to begin. Unlocking alone does not start execution. The launcher starts PostgreSQL and both services. Its Ctrl+C stops the app processes while retaining the database volume. For the container stack, after setup and password generation, use docker compose up --build. With Docker, change saved credentials through secure setup and restart the backend.

Custom challenge contract

Programs read one JSON value and print one JSON value. A supplied suite needs 4–24 development and 2–12 holdout cases; each case has input, expected, and an optional label. The optional input_type declares array, object, string, number, boolean, null, or any. Development and holdout inputs must differ.

{
  "input_type": "array",
  "cases": [
    {"input": [], "expected": 0},
    {"input": [1], "expected": 1},
    {"input": [-2], "expected": -2},
    {"input": [2, -1, 3], "expected": 4}
  ],
  "holdout": [
    {"input": [-5, -1], "expected": -1},
    {"input": [3, -4, 5], "expected": 5}
  ]
}

This small suite illustrates maximum-subarray input. Add broader trusted cases before making a correctness claim. When no suite is supplied, evaluator and blind-verifier agreement is required before tests freeze.

Let the evidence tell the story.

Before presenting, confirm credentials, provider quota, sandbox capacity, and submission eligibility. Keep a completed real preset run ready in the archive. Live provider latency can exceed the presentation window.

1. 0:00–0:25
   Define the experiment

   “We generate competing programs, execute them independently, and evolve verified survivors.” Show the goal and constraints; choose population 3 and two generations.

2. 0:25–1:15
   Show the programs and execution

   Show distinct algorithms in the chamber. Open a candidate’s evidence receipt and explain how stdout is checked against an external expected answer.

3. 1:15–1:45
   Introduce a constraint

   During a live run, lower the byte or time limit for the next generation. In a recorded demo, expand constraint history and explicitly explain the saved change.

4. 1:45–2:30
   Follow a parent into its child

   Select a mutation or crossover node, inspect its parent diff, and explain elite retesting. A rejected candidate is evidence that constraints were enforced.

5. 2:30–3:00
   Close with the proof

   Show current-revision comparison, fresh final audit, and destroyed sandboxes. Export the run. State the pending Stripe deployment and any unverified flow clearly.

What is proven, and what is still pending.

Live verification recorded on October 14, 2026:

• A real sorting run completed two generations with six candidates: five executed and verified; the crossover candidate exceeded the revised byte limit and was rejected without scoring.
• 45 candidate tests and nine fresh final-audit tests ran in CreateOS. The final audit passed. All six experiment sandboxes were destroyed.
• A live constraint update changed 1500 ms / 12,000 bytes / 128 MiB to 1000 ms / 650 bytes / 64 MiB. PostgreSQL retained both generation snapshots.
• Sandbox checks verified unprivileged execution, secret-free candidate environments, output and timeout limits, protected source, and non-routable egress.
• Automated backend tests cover contracts, fitness, lineage, revisions, authentication, cleanup, and error handling. Frontend type checks, production build, and dependency audit pass.

Repeatable release check

From the repository root, inspect the recorded real experiment without creating sandboxes:

uv run --directory backend python ../scripts/verify_release.py --experiment e678e548-76e0-4fe7-a2e7-e640be5965e4

The checker validates source and suite hashes, reference answers, recorded stdout and pass status, fitness, lineage, strategy measurements, final audit, and cleanup. It checks internal consistency; exported receipts alone do not independently authenticate the provider.

To repeat verification using six new sandboxes, explicit live mode runs the real maximum-subarray custom challenge and requires a verified crossover:

uv run --directory backend python ../scripts/verify_release.py --run

Live mode consumes actual AI requests and up to six sandbox allocations. It preserves incomplete evidence and attempts to stop on cancellation or deadline failure. Failure never becomes a success claim.

The official event listing says builders start from an empty directory and submit through Stripe Projects. The schedule is October 17, 12:00–19:00 Pacific, or October 18, 00:30–07:30 India time. Registration requires approval. Treat this prebuilt repository as preparation until organizers authorize its use.

The app is a local workspace. Restarted active runs are marked interrupted, not automatically resumed. Workspace accounts have private project histories. Jobs use a persistent lease with one backend worker. Web source can be rechecked through explicit recovery; automatic billed Python replay and automatic worker failover are excluded. Quota/capacity failures preserve evidence and report failure; there is no simulated fallback.

The experiment is the durable record.

All /api endpoints require the lab bearer token. The browser uses a same-origin proxy; default local API access is http://localhost:8000. Health is public and returns no credentials.

Exports include the challenge, seed, frozen suite and hash, generation revisions, candidate source and hash, parent IDs, operations, development/holdout grades, stdout/stderr, exit status, timing, lifecycle receipts, events, strategy trials, and any final audit. Exports contain user-provided goals and inputs; review them before sharing.

Repository map

Verify a change

cd backend && uv run pytest -q
cd ../frontend
npm test
npm run typecheck
npm run build
npm audit --omit=dev

Unit tests use provider doubles; they do not inject demo data into the dashboard. Live receipts and automated tests establish different kinds of evidence.