1. Mission completeness meter
A mission contract is not ready for planning until its required fields are present. The meter below tracks the live intake form in Section 2. Missing fields are listed, not hidden.
Missing fields:
Verdict: not compilable yet. Fill the missing fields or load a sample.
2. Where the Founder Runtime sits
The runtime is layer T5. It translates human intent into governed organism activity. It does not replace AXON, IAR, AEGIS, MOTHER, Qdrant, Notion, GitHub, Supabase, or the Cockpit. Source claim: the eight-layer model is defined in Section 3 of the source document.
3. Mission intake: natural language to mission contract
Type a request the way Jeramie would say it. The compiler classifies intent, resolves the domain and project, extracts constraints, classifies authority, infers deliverables, and states the definition of done. This demo compiles locally in the browser; no request leaves the page.
No mission compiled yet.
Compiled mission contract
Compiler stages (source Section 7.3): raw request, principal resolution, intent classification, entity and project resolution, context requirements, constraint extraction, authority classification, deliverable inference, definition of done, risk classification, mission contract validation.
Compile a mission to see its contract here.
4. Deterministic strategy scorer (source Section 8.3)
The autonomy core scores candidate strategies deterministically after the model proposes structured values and evidence. The formula below is the source document’s suggested normalized model. Weights are configuration-driven and mission-class aware in the real core; this demo uses the source weights exactly. Each component is scored 0 to 10.
Total = 0.24 x Strategic Alignment + 0.20 x Expected Value + 0.16 x Evidence Confidence + 0.14 x Feasibility + 0.10 x Speed + 0.08 x Reversibility + 0.08 x Cost Efficiency - 0.18 x Risk Penalty - 0.12 x Authority Friction - 0.10 x Dependency Fragility
Range: -4.00 (all penalties 10, all benefits 0) to 10.00 (all benefits 10, all penalties 0). All components at 5 gives 3.00 exactly.
Total score: 3.00 viable
Work shown: positives 5.00 minus penalties 2.00 equals 3.00.
5. Scenario pipeline: acceptance test 22.2, run live
Source acceptance test 22.2 supplies five candidate strategies: two are duplicates, one is dominated, one violates policy, one is viable. Expected outcome: the duplicate pair collapses, the dominated candidate is rejected, the policy candidate is blocked, the viable candidate is selected, and traceability is preserved. Run it below.
| ID | Strategy | Score | Policy | Signature | Outcome |
|---|
Pipeline not run yet. Selected scenarios (0 to 4 maximum, source Section 8.6): none.
6. Persistent mission ledger
Missions persist in this browser’s local storage and survive page reload, which is this demo’s stand-in for the source requirement that a mission survive terminal closure, process restart, context loss, machine reboot, and power loss (source Section 5.6). In the real runtime the durable store is Supabase plus local persistence; here it is local only, and the page says so. State changes are append-only events: no silent state changes (source Section 11.3).
| Mission | Objective | State | Progress | Events | Actions |
|---|
Valid next states follow source Section 11.2. Terminal states: COMPLETED, COMPLETED_WITH_EXCEPTIONS, FAILED_FINAL, CANCELLED, SUPERSEDED. A mission in COMPLETED_WITH_EXCEPTIONS must list what did not complete.
Event log (append-only)
No events yet.
7. Governance gates: authority classes A0 to A6
Source Section 14. AEGIS owns policy, authority, risk, and governance boundaries. The runtime may request an authority decision; it may not silently override one. A5 and A6 always require approval; approvals are scope-limited, so “approve deploy” never becomes “approve all future deploys.”
| Class | Meaning | Default posture |
|---|---|---|
| A0 | Read-only local inspection | Allowed |
| A1 | Local reversible analysis | Allowed |
| A2 | Local code or document mutation | Allowed within canonical local workspace |
| A3 | Local execution with contained side effects | Allowed when governed and reversible |
| A4 | Commit or persistent local-state change | Conditional under repository policy |
| A5 | External send, push, spend, deploy, production mutation | Approval required |
| A6 | Destructive or high-risk operation | Approval required plus enhanced review |
Approval gate demo: execution plan with a deployment step
Plan steps: local read (A0), local test (A3), Git push (A5), production deployment (A5). Per acceptance test 22.3, read and test may proceed; push and deployment block until approval exists. There is no bypass path in this demo.
| Step | Authority | Status | Action |
|---|
Approval state: none requested.
8. Conductor and worker routing
The runtime compiles intent; AXON executes approved actions. Conductor routing sends each execution-plan step to the one governed executor that owns that capability. No step is routed to two executors, and no executor receives a step outside its capability.
| Capability | Executor | Notes |
|---|---|---|
| Governed inference | IAR | Sole authorized inference path; no hidden direct model fallback |
| Policy and authority decision | AEGIS | Permit, block, escalate; never silently overridden |
| Approved commands, reads, code ops | AXON | Explicit plan steps only, never vague intent |
| Health, liveness, service state | MOTHER | Health only; not the planner |
| Durable mission state | Supabase | Missions, events, steps, receipts, approvals |
| Source truth | GitHub | Repo, branch, base commit, resulting commit |
| Semantic retrieval | Qdrant | Stable document IDs and provenance; not the mission-state database |
| Human-readable canon | Notion / neuruh-vault | Doctrine, decisions, approval records |
Health targets named in the source (Section 15, source claims, not live probes from this page): Bonsai :8100, IAR / AEGIS :8090, AXON :8788, AXON Gateway :8300, AnythingLLM :3001, Ollama :11434, Qdrant :6333. Qdrant container neuruh-qdrant, approximately 3,049 points at the noted verification point.
9. Receipt chain and restart recovery
Evidence before action: no important assertion is treated as fact without a claim and evidence reference, and no important step is treated as complete without a receipt (source Section 5.3). Receipts are hash-chained: each receipt records the hash of the one before it, so tampering breaks the chain. This demo uses a deterministic FNV-1a hash, not SHA-256; the source specifies SHA-256 provenance receipts for LANDOS, and this page does not claim otherwise.
Receipt chain
Chain empty. Record receipts to build the chain.
No receipts yet.
Restart recovery (acceptance test 22.4)
Complete two steps, write a checkpoint, terminate the runtime, restart it. Expected: the mission is restored, completed steps are not rerun, side effects are reconciled, the next eligible step is identified, no duplicate receipt or commit appears.
Recovery demo idle. Steps completed: 0 of 5.
No checkpoint yet.
Idempotency: re-running a completed step returns the existing receipt by its idempotency key instead of creating a second side effect (source Section 5.7).
Invalid receipt rejection (acceptance test 22.5)
A receipt with the wrong mission ID, a mismatched step ID, or a bad input hash must be rejected, the step must not complete, and the mission must move to a recoverable failure or blocked state with an event recorded.
No invalid receipt submitted yet.
10. Share link
The current intake, compiled contract, and scorer inputs encode into the URL hash as base64 JSON (#d=...). Opening the link restores the same intake on load. Nothing is uploaded anywhere.
11. Try-it walkthrough
- Load sample 1. Click “Load sample 1” in Section 3. The intake fills with the first vertical slice: organism status and safest next plan. Watch the completeness meter reach 100%.
- Compile. Click “Compile mission contract.” Read the contract: objective, domain, urgency, authority, deliverables, verification criteria, context packs, completion rule.
- Score a strategy. In Section 4, move any slider and watch the total recompute from the source formula. Try the presets and check them against the hand-computed values.
- Run the pipeline. In Section 5, click “Run pipeline.” Five candidates become one selected scenario, with the duplicate collapse, the dominated rejection, and the policy block each shown.
- Seed the ledger. In Section 6, click “Seed ledger.” Advance a mission through its states. Reload the page: the ledger is still there.
- Test the gate. In Section 7, try to run the deployment step before approval. It blocks. Request approval, grant it, then run it.
- Break the chain. In Section 9, record three receipts, verify the chain, then tamper with receipt 2 and verify again. The chain must fail.
- Simulate a restart. Still in Section 9, complete two steps, write a checkpoint, simulate a restart. Completed steps are not rerun and no duplicate receipt appears.
- Share it. In Section 10, generate a share link, copy it, and open it in a new tab. The intake restores.
12. How it works, and what this is not
How it works
- Founder intent arrives as natural language through the Cockpit intake.
- The mission compiler resolves the principal, classifies intent, resolves entities and projects, extracts constraints, classifies authority, infers deliverables, and states the definition of done.
- Context packs compile task-specific evidence with provenance, version, and trust class. Precedence is deterministic: current explicit instruction first, then the active mission contract, governance, source-of-truth records, recent approved decisions, constitution, project canon, mission evidence, semantic retrieval, and general model knowledge last.
- The autonomy core generates candidate strategies, scores them deterministically, runs dominance and Pareto analysis, collapses duplicates, and returns zero to four scenarios.
- A decision packet goes to the founder. Approved work becomes a versioned, immutable, authority-labeled execution plan.
- The conductor routes steps to governed executors. Every step returns a receipt. Checkpoints are written before external side effects and after every completed step.
- Completion is verified against evidence, not agent claims. Outcomes reconcile, learning records are written, and the mission closes with a completion report.
What this is not
- Not a new model, not a new chat wrapper, not another dashboard (source Section 0).
- Not a replacement for AXON, IAR, AEGIS, MOTHER, Qdrant, Notion, GitHub, Supabase, or the Cockpit.
- Not autonomous production deployment, autonomous spending, autonomous external outreach, or self-modifying agents (source Section 29, non-goals for v1).
- Not a live runtime. This page is a browser simulation of the architecture. It does not connect to IAR, AEGIS, AXON, MOTHER, Qdrant, Supabase, or GitHub.
- Not proof that the real Founder Runtime is built. The source status is “Architecture approved for implementation,” not “implemented.”
13. Honest gaps
- This page is a simulation, not the runtime. No mission here executes real work, touches a repository, calls a model, or writes to Supabase. The ledger lives in browser local storage only.
- No live health probes. Service ports and point counts are source claims reproduced as text. This page does not probe Bonsai, IAR, AEGIS, AXON, Ollama, Qdrant, or AnythingLLM.
- Hash is FNV-1a, not SHA-256. The source specifies SHA-256 provenance receipts for LANDOS. This demo uses a short deterministic hash so the chain logic is visible and testable in the browser.
- Intent classification is keyword-based. The real compiler uses governed inference through IAR. This demo matches keywords and falls back to explicit form fields.
- Weights are fixed to the source suggestion. The source says weights should be configuration-driven and mission-class aware; this demo does not implement per-class weight profiles.
- Layout was not eyeballed in a real browser. Structure and behavior were verified in jsdom; visual layout is an accepted limit.
- Source claims are labeled as source claims. Port numbers, commit hashes (IAR 8ab0c59, AXON 56b4f54, AEGIS main 835273d), the Qdrant point count of approximately 3,049, and the LandOS migration 038 note come from the source document and were not independently verified for this page.
- Error taxonomy is listed, not fully wired. The source defines 21 error codes (Section 27), from CONTEXT_NOT_FOUND to CANONICAL_PATH_MISMATCH. This demo surfaces the main ones (APPROVAL_REQUIRED, RECEIPT_INVALID, STATE_TRANSITION_INVALID) and lists the rest in the source reference below.
Source reference (what was read)
Source: 60-page PDF, “NEURUH Founder Runtime: Persistent Founder-Specific Mission Orchestration Layer, Canonical Architecture and Build Handoff, v1.0.” Key sections used: executive directive (11 steps), canonical ownership in recipe-engine, T0-T7 layers, responsibility split across IAR / AEGIS / AXON / MOTHER / Cockpit / Supabase / GitHub / Notion / vault / Qdrant, design principles (local-first, evidence before action, deterministic core, fail-closed, resumability, idempotency), founder context model and 10-level precedence, intent-to-mission compiler, autonomy core scoring formula, decision packet, execution-plan contract, 20-state mission state machine, durable runtime and recovery procedure, receipts and evidence contracts, authority classes A0-A6, health integration, data model, file tree, adapter contracts, API surface, Cockpit experience, security requirements, acceptance tests 22.1-22.8, implementation phases 0-8, first and second vertical slices, observability, error taxonomy, definition of done, non-goals, required build outputs.
Sibling reference on the hub: the Lead Recipe OS and recipe system demos listed at neuruh-hub.pages.dev. The canonical owner repo is NeuruhAI/recipe-engine; this demo creates no repository and makes no repo changes.