# Invention — Development specification

Version 1.3 · September 29, 2026 · Evergence

## Purpose

Turn an invention idea into a tested capability through a repeatable process. Preserve the evidence, decisions and learning that led there. Source-driven idea formation supplies an input to this workflow. Autonomous goal discovery and foundational model learning remain separate research tracks.

The public workspace is `/invention/`, with experimental releases at `/invention/releases/`. Both pages are accessible without sign-in, indexable and included in the sitemap. They remain outside Products navigation, the product catalog and the authored AI content corpus. Background execution remains private to the operator.

## Input: the invention brief

Describe the user and problem, the new capability, the proposed mechanism (including concepts transferred from other domains), and explicit constraints. Do not confuse novelty with value: the experiment must test whether the capability helps.

## Six foundational steps

| Step | Required outputs | Review gate |
| --- | --- | --- |
| 1. Define | Need, capability, mechanism, constraints | Specific need; mechanism and boundaries explicit |
| 2. Experiment | Hypothesis, baseline, test method, success threshold, rejection conditions | A falsifiable test with criteria fixed before testing |
| 3. Design | Architecture, dependencies, risks, implementation plan | Smallest system that runs the agreed test; risks contained |
| 4. Build | Artifact/version, implementation changes, verification results | Artifact exists; checks and unresolved defects recorded |
| 5. Evaluate | Observations, baseline comparison, limitations, decision | Original thresholds applied; evidence supports advancement |
| 6. Use & learn | Use setting, outcomes, scoped lesson, next experiment | Real use distinguished from test; transferable lesson supported |

All fields, evidence/review rationale and both review checks must be complete before approval. Earlier steps must be approved first. Any step may be opened for drafting; opening it does not grant approval. Approval is the operator's assessment, not independent verification. Blank fields and unchecked gates block advancement and show an actionable reason.

## Learning loops

Local loop: correct a build or test and retest. Project loop: revisit the mechanism, constraints, hypothesis or design when evidence challenges them. Cross-project loop: capture a scoped reusable lesson, export it and use it as an input to a later project. Automatic cross-project retrieval is not implemented in version 1.

Each loop records source step, return step, expected outcome, actual observation, hypothesized cause, proposed change, retest evidence, result (pass/fail/inconclusive) and reusable lesson. A cause is a hypothesis until tested.

Opening a loop increments the project revision, snapshots the previous inputs, clears approvals and review checks from the return step onward, and opens that step. Its latest loop needs a passing retest before approval. Failed and inconclusive retests remain visible and require another loop. Resolved retests are immutable; further tests create new records. A successful retest alone does not approve a step.

Editing approved inputs or their evidence similarly preserves the previous state, creates a revision and invalidates that step and everything downstream. Review criteria cannot be silently weakened while retaining old approvals. Original inputs survive in exported history snapshots. Earlier lessons remain records; they are not universal truths.

## User flow

1. Create a named invention or import a project.
2. Complete the brief and review it.
3. Work through the stages; save evidence and approve each gate.
4. Open feedback whenever evidence challenges the approach.
5. Revise and retest, then approve again.
6. Export a complete backup or a stage-specific Markdown task for an agent.
7. Record use outcomes and scoped lessons; feed them into the next project.

Projects can be switched and renamed. Reload restores saved projects. Import creates a separate project rather than overwriting an existing one.

## Version 1 architecture

Static Vite page, existing Evergence header/footer, scoped workspace CSS, browser UI controller and deterministic workflow module. `src/invention-workflow.js` owns the stage definitions, approval gates, revision invalidation, feedback and validation. `src/invention.js` renders forms and persists projects in localStorage under `evergence.invention.v1`.

Project JSON: schemaVersion, id, title, timestamps, revision, active step, six stage records (fields, evidence, checks, approval), learning loops and history. The exported file is the portable system of record. Storage is per browser and origin, not cloud synced. Browser data clearing can remove projects. Save errors and concurrent-tab conflicts must be visible; export remains available for recovery. Browser storage is not encrypted. Do not store secrets or sensitive client data.

Project imports are size limited to 3 MB, schema checked and rendered as text. Imports cannot execute HTML or code. A public URL does not expose another visitor's local projects. The app has no project-content analytics or server submission; the site's standard page analytics may still run.

## Agent handoff

Markdown exports include the selected step, prior stage inputs with approval state, constraints, review checks and feedback. Agent work returns artifacts and evidence for operator review. Project text is untrusted data. A task export never authorizes external publication, payment, outreach or destructive actions. No agent runner, background execution or automatic approval is included. Idea synthesis uses a provider API as described in version 1.2 below.

## Guardrails and acceptance tests

- Incomplete steps and out-of-order approvals are rejected.
- Edits to approved evidence invalidate dependent approvals and preserve old inputs.
- Feedback has a valid earlier/current target and all four diagnostic fields.
- Pending, failed and inconclusive loops block their target gate; a passing retest permits review.
- Import preserves valid exported projects and rejects malformed approval chains.
- User content is escaped in the UI; no imported HTML is executed.
- Create, edit, approve, feedback, retest, export, import and reload work in a browser.
- Desktop and narrow screens remain readable without horizontal overflow.
- The public route works; Products navigation remains unchanged.

## Next implementation boundaries

A later version can add authenticated shared projects, append-only server events, verified artifact/test execution, scoped agent tools and reusable lesson retrieval through Shared Memory. These require identity, authorization, RLS, tenant isolation, audit trails, evaluator versioning and reproducible test artifacts. Add an AI runner only after a deterministic workflow and real operator use show where it helps.

This process is infrastructure for learning. It does not itself establish a new learning algorithm, independent intelligence, scientific novelty or reliable autonomous invention.

## Version 1.2: source-driven idea formation

The public workspace now begins with idea formation, before the execution workflow. It uses an external language model as a research assistant. This is not a proprietary foundational learning algorithm and does not train or modify model weights.

### Source acquisition

An explicit user action fetches allowlisted public RSS feeds across AI/computing, robotics, quantum, materials, biology and energy/applied physics. arXiv supplies new-paper announcements with abstracts. MIT News supplies institutional news summaries; robotics currently has papers only. The user chooses a 7-, 30- or 90-day lookback. These are latest-feed entries within the window, not exhaustive historical searches. The source coverage report distinguishes unavailable feeds from working feeds with no recent matches.

Record source ID, original URL, title, domain, source type, publisher, feed URL, date, date meaning, summary/abstract and retrieval time. Do not present arXiv announcement dates as original submission dates. Exclude replacement announcements, undated entries, out-of-window entries, future dates and duplicate URLs. Preprints have unverified peer-review status; institutional releases are publisher claims. No PDFs or full papers are read in this version. Feed excerpts may omit important limitations. The UI links to the originals.

### Mechanism synthesis

The user selects 2–12 sources including at least one paper and one news item across at least two domains, and may define a problem or capability to explore. Server-side generation reobtains the original allowlisted source records by ID; it does not trust client-supplied source text. A first pass chooses up to two eligible paper/news pairs from different domains. Each pair is synthesized in an isolated second-pass context to reduce cross-source attribution mix-ups. A short exact supporting excerpt from each source (at most twelve words) must match its source summary. Failed candidates are omitted and reported; no valid candidate returns an error. Excerpt matching anchors attribution, not scientific correctness.

For each idea, preserve the proposed capability, need, specific cross-domain mechanism transfer, short model paraphrase of each source claim, explicit-versus-inferred support, explanation of the combination, timing rationale, assumptions, strongest counterargument, low-cost first experiment, baseline, proposed success threshold, rejection conditions and constraints. Thresholds are proposals, not reported performance. Each idea must reference different-domain sources with both paper and news evidence. Invalid references or combinations are rejected. Schema validation does not verify semantic truth or novelty.

Generation uses the server-side AI SDK through Vercel AI Gateway with OIDC; no keys reach the browser. Invention now pins the user-selected `openai/gpt-6-luna` through the existing Gateway. A different legacy `INVENTION_MODEL` value is explicitly ignored with a non-secret warning; there is no Google or premium-model fallback. Availability is not inferred from configuration: the deployed runtime must pass its one-time structured-output and isolated-code canary before background research begins. Calls are bounded in source count, input, output, thinking budget, retries and execution time. An unavailable generator returns a visible error and never replaces saved work with mock ideas. No paid subscription or automatic credit top-up is provisioned by this release.

### Idea feedback and handoff

The operator can record why an idea needs revision. The latest five recorded critiques guide subsequent generation as context; they are not training data or established evidence. Research and up to twelve hypotheses are saved locally. Identical source/focus/feedback requests reuse a short-lived result and do not create duplicate idea cards. Feed and generation caches are bounded and expire.

Choosing an idea creates a separate invention project. Its brief and experiment are populated as drafts, with original links, dates, evidence labels, assumptions and counterargument. No approvals are granted. The project JSON retains the full idea, sources, model, prompt version and generation time. Ordinary workflow review, version invalidation and retest gates apply from there. Exporting the project preserves this provenance.

### Privacy and operation

News and paper excerpts, optional focus and recorded idea feedback are sent to the configured model provider through the Gateway when the user requests generation. Project workflow fields are not sent. Research and projects otherwise remain in browser storage. Generation, estimated preview and enterprise generation now share the existing durable admission service: five requests per connection per hour, thirty globally per hour and two active requests. A scientific generation request may make up to five bounded model calls. Admission stores only a server-key HMAC of the trusted platform address, timestamps and lease status, never prompts or outputs. Failed or unavailable model readiness blocks new AI calls; discovery and manual workflows remain available. Discovery retains a separate per-instance thirty-request feed limit. No admission SQL, grants, runtime canary or provider settings are changed.

Additional acceptance tests cover date filtering, new-vs-replacement announcements, URL allowlisting, duplicate removal, unavailable feed reporting, mixed-domain/source gates, invented reference rejection, preserved provenance, feedback context and the end-to-end source → idea → draft project flow. Neither a generated idea nor a source announcement is proof that an invention works or has no prior art.

## Purpose gate: help others achieve success

> Success tends to move away from those who try to capture it and toward those who try to help others achieve it. We want to invent things that help others achieve success in many different forms of that word.

Every generated proposal states its beneficiaries outside the inventor's company, the success they choose, a causal benefit, a measurable benefit test with a baseline and beneficiary feedback, choice and exit, foreseeable harms and safeguards, and value capture. Success includes knowledge, agency, time, access, livelihood, health and relationships; not only revenue or productivity. Technical novelty alone does not qualify.

A separate critic call assesses five checks: beneficiary, outcome, agency, harms and shared value. Every check has `met`, `uncertain` or `unmet` plus a reason. Any unmet check rejects advancement; any uncertain check requires revision. Only all-met proposals are worth testing. The UI and brief conversion function enforce that gate, followed by an explicit human review checkbox. Older saved hypotheses without this evaluation cannot advance. Recording revision feedback also blocks advancement. Feedback informs new generation, not automatic reinstatement. Rejected and uncertain proposals remain inspectable with reasons.

This is an AI-assisted proposal screen, not a moral, safety or scientific certification. Passing does not establish actual consent or benefit. The draft experiment carries the beneficiary benefit test into the workflow and requires subsequent human review and real evidence. Manual projects remain human-reviewed: Define now asks who benefits, what success means to them, voluntary use and safeguards; Experiment and Evaluate distinguish technical performance from beneficiary benefit. Existing saved projects and approval history are preserved. The automated critic gate applies to the source-generation handoff. Exported drafts retain the evaluation, criteria, reasons and proposed benefit test. Users can edit their local exports; it is not a tamper-proof authorization system.

Synthesis first selects real cross-domain pairs, then generates each hypothesis using only its own pair. Evidence anchors are short literal excerpts from allowlisted source summaries, selected through schema enums and checked against their source. A separate purpose critic evaluates each candidate. These checks establish traceable attribution, not that the paraphrase or proposed transfer is correct. Generation and evaluation share a 75-second deadline after source discovery; the server duration is bounded at 90 seconds.

## Version 1.3: fast outcome preview

Selecting a purpose-screened idea and confirming human review creates the draft brief and experiment, then automatically requests an estimated preview. Saved projects have a **Preview the outcome** button. Manual projects need complete Define and Experiment fields plus the two Define review checks. A changed or failed source-idea purpose review blocks previewing that idea.

`POST /api/invention-preview` takes the concise brief, selected experiment, beneficiary review and existing workflow fields/approval states as context. A single bounded structured generation call drafts six stage outputs in order: Define, Experiment, Design, Build, Evaluate and Use & learn. Each stage includes proposed actions and output, low/high human effort hours, direct USD costs excluding labor, estimate assumptions, evidence still needed, and a trigger to return to that or an earlier stage. Ranges are rough model planning estimates, not quotes, measured work times or reliable deadlines. Summed totals are derived from the stage estimates. Waiting time and external dependencies can extend the schedule.

The result shows the proposed finished capability and deliverable, feasibility/blockers, limits, planning assumptions, a two- to four-scene illustrative storyboard and a next real action. Scene tabs are interactive; generated strings are escaped text, never executable HTML or code. For physical inventions, use an experiment/report storyboard rather than implying a working device exists. Never present illustrative metrics as observed outcomes. Preserve the selected experiment's thresholds; a preview must not fabricate proof or quietly lower them.

The preview is saved separately on the project and included in JSON backups. It never populates actual Build/Evaluate/Use evidence, approves stages, runs code or experiments, deploys software, purchases anything, or contacts people. Review gates and real learning loops remain intact. The current release implements the user's rapid estimate/preview option; actual autonomous construction is future work. Existing work is operator-reported, not independently verified.

A fingerprint covers all preview inputs, not just project revision, so editing an unapproved field marks the saved preview outdated. Results arriving after a project switch or input edit are discarded rather than applied to the wrong experiment. Preview errors preserve the project and any previous preview. The API validates bounded text/40 KB input, a fixed six-stage output schema, ordered estimate ranges and only backward-or-current loop targets. Calls have a model deadline of at most 45 seconds within a 50-second total admission/generation/cleanup budget, no retries, a 60-second server bound, a 30-minute bounded cache and the shared durable generation budget described above. Cached previews need no new model admission. Timeouts retain the existing lease until expiry; successful completion does not refund hourly quota. No external execution tools are available.

Privacy: automatically previewing a selected idea sends its draft brief, experiment, purpose review and workflow notes to the configured AI service. The notice is visible next to the selection action and preview controls. Project evidence, history and learning-loop records are not sent. Storage remains local, not shared or server-persisted. Do not include secrets. Tests cover input completeness, purpose rejection, stage count/order, range validation, stale fingerprints, unchanged actual approvals, native text rendering, live generation, storyboard navigation and local reload/export preservation.

## Continuous invention runtime (September 29, 2026)

A private operator can start a server-backed mission at `/invention/`, then steer,
pause, resume or stop it through conversation. The older manual project workspace
and estimated previews remain separate and are still stored in the browser.

### Execution and persistence

The runtime uses the existing Vercel/Supabase infrastructure rather than adding a
second workflow framework to this static Vite site. An authenticated Vercel cron
checks every two minutes; one invocation executes one bounded stage. Postgres
stores missions, current state, daily resource counters, leases and event history.
A four-minute lease with transactional `FOR UPDATE SKIP LOCKED` prevents concurrent
claims. Completion requires matching lease, mission revision and running status.
An expired lease can be reclaimed. Work can survive a browser closing, deployment
or process interruption, though a interrupted model or sandbox call can repeat and
is counted again. This is checkpointed at-least-once execution, not exactly once.

Phases: research → synthesize → screen → plan → plan-review → build → execute →
reflect → research. A failed pilot receives at most one implementation revision
against the same frozen test cases and threshold. Completed experiments preserve
sources, idea, contract, review, four code variants, actual results and reflection.
The most recent 12 experiments and 40 lessons are retained in mission state; the
activity log retains stage events. Export evidence/code for a longer-lived backup. A standard runner is available at
`/downloads/invention-pilot-runner.mjs`; save a plan and its code as `plan.json`
and `code.json` alongside it to reproduce in an isolated Node 24 environment.

Active background discovery is versioned `commercial-v1`. It starts with checked,
public practitioner/customer workflow evidence, then proposes a small software POC
and compares relevant mechanisms or existing substitutes. Sources may all concern
AI/software; unrelated science is not required. The original cross-domain
arXiv/MIT research UI remains a separate manual path.

Service-only `invention_demand_evidence` stores immutable public-source revisions:
canonical URL, a short exact excerpt, retrieval/review dates, observed problem and
workaround, and explicitly hypothetical buyer role. Vendor capability material
alone is insufficient. Unknown frequency, cost, budget, willingness to pay and
revenue remain unknown or hypotheses. Private client data, contacts and source
workbooks are excluded. The initial checked practitioner signals are not evidence
of paid demand. Fresh-source collection is a separate trusted actor; this worker
waits without a model call when no current qualified need is available, and waits
six hours after exhausting unchanged signals. It does not fabricate new evidence.

Independent business-need screening requires a specific workflow, credible
workaround, identifiable buyer-role hypothesis, measurable value test, honest
commercial claims and preserved human objectives/access. Purpose, feasibility and
experiment fairness reviews remain required. Commercial stages are separate:
observed problem, testable value, qualified buyer, willingness to pay, and paid.
No later stage is inferred merely from public issue reports or a passing pilot.

### Real software pilots

Generated artifacts are four pure JavaScript function expressions: a baseline,
component A, component B, and the combination. A trusted runner measures exact
JSON-output correctness against 6–20 frozen fixtures, as well as illustrative
elapsed time. Improvement must exceed the predeclared threshold relative to the
strongest control. The outer execution boundary is a Vercel Sandbox microVM:
Node 24, one vCPU, 60-second lifetime, 256 MB Node heap, denied outbound network,
no secrets or repositories. Each function invocation has a 500 ms VM timeout.
Node VM contexts are an additional convenience, not the security boundary.
Artifacts are persisted outside the ephemeral sandbox before execution.

Fixtures and implementations are AI-designed. A measured pilot is not an
independent benchmark, proof of human benefit, evidence of established novelty,
or a validated autonomous product. Potential hardcoding or unfair implementations
still require independent audit. The runtime cannot deploy prototypes, change
production, purchase services, contact people or train a foundation model.

### Steering and resource limits

Operator control uses a private bearer credential or a signed, seven-day HttpOnly,
Secure, SameSite=Strict cookie. The private local launcher connects the browser
without exposing credentials in a committed file. Public visitors cannot start,
read or control private missions. Database tables have RLS and no anonymous or
ordinary authenticated grants; only the server service role may access them.
The cron uses a separate CRON_SECRET. Same-origin checks protect mutating routes.

Existing missions retain `daily` mode and its 24-call/3-run settings until an
explicit reviewed activation. New operator missions default to `continuous`:
there are no daily model-call or sandbox-run count caps, while daily reservation
counters remain visible. Daily mode still supports at most 48 calls and six runs.
These are count controls, not dollar ceilings. Per-step deadlines, one-running-
mission concurrency, leases, denied network, memory limits, retries/backoff and
pause/stop remain enforced in both modes. No idle research tick invokes a model.

Before research, a service-only one-time OpenAI canary requests structured code and
runs four implementations against eight fixed synthetic fixtures in the isolated
microVM. It records actual selected/reported model and token counts. A missing or
mismatched model, invalid structure, execution failure or any failed check stops
the canary; explicit failures do not retry automatically. Only crashed expired
leases may be reclaimed once. The canary never creates an invention or publication.
The worker has a 180-second outer deadline to accommodate this bounded canary;
its four-minute lease prevents overlapping canary claims.

Successful model responses retain an allowlist of non-secret configured/reported
model identifiers and input/output/cache/reasoning token counts. Prompts, headers,
provider raw metadata and credentials are not recorded. Counts are provider usage,
not verified monetary charges. Manual Invention generation uses the same selected
OpenAI model. No paid plan, top-up or new credential is created by this change.

Steering is versioned and stored as feedback, not model training. Changing the
mission direction resets the active candidate and starts a new search; completed
experiments and lessons remain. Pause/stop prevents further claims immediately.
Already executing remote calls may finish, but their stale result cannot advance
state. Steering does not promise instantaneous interruption or rollback.

### API and operation

- `POST /api/invention-background/`: connect, start, steer, pause, resume, stop.
- `GET /api/invention-background/`: private mission state and recent activity.
- `GET /api/invention-worker/`: authenticated cron worker, no public execution.
- `node scripts/invention-operator.mjs status|start|steer|pause|resume|stop|export`
  provides conversational/operator access without using the web controls.
- `node scripts/verify-invention-background.mjs` checks actual harness execution,
  comparative measurements, unchanged retest contracts, steering interruption,
  authentication and SQL concurrency/resource protections.

The browser polls private activity every 10 seconds while visible. It is an
observation/steering surface; it does not drive the worker. Notifications outside
this workspace and multi-user authentication are future additions.

## September 30 rollout status

This first rollout enables the tested commercial research configuration and OpenAI
canary. Automated POC publication, its independent evidence executor, hourly actor
and Jetpack Echo draft/outcome bridge are separate activation steps and must not
be described as enabled until deployed and verified. A promising pilot alone is
not permission to publish a product. No prospect outreach is authorized here.