naive-framework 0.0.0-stage → 0.1.0

package/docs/ontology.md

@@ -0,0 +1,163 @@
+---
+type: reference
+source: hybrid
+created: 2026-10-27T04:18:09Z
+ai-model: claude-opus-5.5
+tags: [everything-ecosystem, ontology, glossary, nouns]
+description: "The system's nouns at every level, the standard each follows, its references, and the retired nouns with what replaced them. Generated from docs/ontology.json (canonical) by node schema/check-nouns.mjs --md (EE-014)."
+---
+
+# Ontology
+
+The system is opinionated: it names one default for each choice, and every default carries references to its sources and the alternatives it weighed (EE-014). Its nouns follow one rule: **standards first**. Use an established term with its standard meaning, and coin a word (marked "ours") only when none exists.
+
+- Canonical: `docs/ontology.json`. This page is generated from it; regenerate with `node schema/check-nouns.mjs --md`.
+- `node schema/check-nouns.mjs` fails when a retired noun reappears in the schema, design docs, Product Anatomy, AGENTS.md or README.md.
+- References are ids in `<layer>/references/references.json`.
+- The genus of the whole is open: files say "the system" until the first venture runs end to end, then it is settled as an operating system or an operating model.
+- Phases and gates: Discovery, Validation, Beachhead, Scale, Platform (EE-012). Three Horizons, VC funding stages and Blank's customer development are lenses onto them, mapped in the ontology research doc (https://claude.ai/artifact/6LcDgsc8SA9ybY5ddTfsMn).
+### System
+
+| Noun | Meaning | Standard | References |
+| --- | --- | --- | --- |
+| Everything Ecosystem | The name of the system | ours |  |
+| the system | How files refer to the whole. Proposed genus (EE-024): a venture development framework; operating system and operating model are set aside | EOS (Wickman) for 'operating system' |  |
+| venture development framework | Proposed genus of the Everything Ecosystem (EE-024): an opinionated framework for developing ventures, in the same genus as web development frameworks. Like them it gives conventions over configuration (one default per choice, with references), a fixed structure the builder fills in (the venture folder, layers and records), generators (init-venture), checks that run like tests, a data model, and packages (packages/<name>/package.json, EE-071). The builder's venture calls on it, and its checks call back on the venture's records | software framework (Johnson and Foote 1988; Rails' convention over configuration) applied to venture development (venture building, venture studios) |  |
+| method | What to do: Product Anatomy, handoffs; MAD, the method for building software, is a separate product (EE-038) | common usage |  |
+| schema | What to record: venture.json, products, decisions, references | JSON Schema |  |
+| tooling | What helps do it: scripts, skills, agent rules | common usage |  |
+| workspace | One builder's instance of the system, declared by workspace.json | common software usage |  |
+| layer | One of the six: purpose, knowledge, operations, evidence, governance, interface (execution folded into operations, EE-038). A layer organizes the framework repository (its manifest is <layer>/layer.json). It is a property of a record type, not a venture folder (EE-071) | ours |  |
+| integration | A tool or service one layer uses, listed in <layer>/tooling/integrations.json (Obsidian for knowledge, Linear for operations, GitHub checks for evidence). An interface reaches integrations; it is not one | systems integration |  |
+| data model | The list of every record type in the ecosystem, the layer that owns it, its schema, where its records live and what it references (schema/data-model.json). It is the master map; no single schema contains everything | data model (ANSI/SPARC; entity-relationship modelling, Chen 1976) |  |
+| record type | One kind of record in the data model, such as venture, product, handoff or evidence, owned by exactly one layer or by the system | record type (database usage) |  |
+| layer manifest | The file (<layer>/layer.json, system layer at schema/layer.json) that lists what one layer of the framework repository holds: its skills, the record types it still owns, those it reads and writes, and its checks. Layer relationships are derived from manifests (EE-018, EE-071) | package manifest (common software usage) |  |
+| vault | The folder of documents (Markdown notes and JSON records) that holds a workspace's venture folders, their records and decisions. Every workspace has one; a venture outside software may need nothing else | Obsidian's name for a folder of notes; generically a knowledge base |  |
+| repository (repo) | A version-controlled store, normally Git, holding code and the documents that ship with it (docs-as-code). A venture that builds software needs at least one; repo is the short form | version control (Git: repository) |  |
+| template | A fill-in starting point for one record or document: the fields, what to write in each and what a strong one looks like. A kit holds templates; a template holds no rules and checks nothing | common usage (document template) |  |
+| provenance | Who or what produced a record, by which activity, from what, and under which decision: explicit in the provenance log for writes through the router, implicit in git history for everything else (EE-031) | W3C PROV (PROV-DM: entity, activity, agent) |  |
+| provenance log | A venture's append-only record of writes, <venture>/provenance.jsonl: one line per write naming the file, the activity (write, draft, accept, baseline), the person or agent and the interface, what it was derived from and the decision; each line carries the previous line's hash (EE-031) | W3C PROV; hash-chained append-only log (common audit usage) |  |
+
+### Venture
+
+| Noun | Meaning | Standard | References |
+| --- | --- | --- | --- |
+| venture | The unit: anything a builder undertakes, from a hobby to a company. Ventures can hold ventures | common business usage |  |
+| phase | How far a venture has come: discovery, validation, beachhead, scale, platform | Blank; Moore | blank-2005-four-steps, moore-1991-crossing-the-chasm, moore-1995-inside-the-tornado |
+| gate | The test for leaving a phase: problem-solution fit, product-market fit (retention), repeatability, market leadership | Andreessen; Zook and Allen | andreessen-2007-only-thing-that-matters, zook-allen-2012-repeatability |
+| ambition | Why the venture exists and how far it means to go: hobby, survival, lifestyle, managed growth, aggressive growth | IRS (hobby); venture-type literature | irs-treas-reg-1-183-2, elgar-what-do-entrepreneurs-create |
+| legal form | none, sole-prop, partnership, llc, s-corp, c-corp, benefit-corp, nonprofit | US entity types |  |
+| funding | bootstrapped, grant, angel, venture capital, debt, mixed | common usage |  |
+| industry | What the venture produces, by its current flagship | NAICS | naics-2022, gics-msci |
+| core product | The promise, who it is made to, what it must not deliver, and the competence behind it | Kotler; Prahalad and Hamel | kotler-core-product, prahalad-hamel-1990-core-competence |
+| account | A named party a venture keeps a record for, at accounts/<id>/account.json, with a relationship: client, customer, user, member, partner or other. Optional; who a product serves in general is its market | CRM usage (Salesforce, HubSpot: account) |  |
+| relationship | How a party or market stands to the venture: customer (buys), client (served under a professional relationship), user (uses, may not pay), member (belongs), audience (reads, watches or listens; markets only), partner | common business usage; client as a customer of professional services |  |
+| link | What crosses from one venture into another, one way, with a border | Clark's work/family border theory |  |
+| venture profile | The readable companion to venture.json: narrative, pillars, changelog | ours |  |
+| function | A business function with one accountable owner. One person may own several. A solo founder owns them all. Decision rights and the team plan point at function owners (EE-071). department is the alias for one release | business function (common usage) |  |
+| pillar | Product, brand and business, in every venture | ours |  |
+| venture template | The scaffold for a venture: pillars, roles, decision rights | ours |  |
+| kit | Mentura's word (EE-071): an enhanced package that adds automations, agent workflows, richer skills and connectors, at platform/kits/<name>/kit.json. A kit names the one package it extends and never replaces it, so the package works without the kit. The framework does not use kit for its own manifests (was the layer bundle at <layer>/kit.json) | product bundling (Adams and Yellen 1976), kept for the platform |  |
+| strategic foundation | The records a founder keeps in front of them every day until they are muscle memory, answering why, what, who, how, when, where and whether, with brand beside them (purpose/strategic-foundation.json). Each foundation statement is an attribute of an existing record; changing one is deliberate (type to confirm) and confirmed statements unlock delegation (EE-051, EE-052) | strategic foundation in strategic planning (mission, vision, values), widened by the Five Ws and How |  |
+
+### Purpose
+
+| Noun | Meaning | Standard | References |
+| --- | --- | --- | --- |
+| product | One thing a venture offers, stored as a card in products/ | common usage |  |
+| market | Who a product serves: customer type, segment, geography, vertical or horizontal | Abell (customer groups) | abell-1980-defining-the-business |
+| job | The need a product meets | Abell (customer functions); jobs to be done | abell-1980-defining-the-business |
+| technology | How a product meets the need | Abell (alternative technologies) | abell-1980-defining-the-business |
+| offering | product, service, platform, content, marketplace | common usage |  |
+| business model | How a product earns, by St. Gallen pattern names | St. Gallen Business Model Navigator | gassmann-2014-business-model-navigator |
+| portfolio role | A product's place in each phase: flagship, substrate, revenue engine, wedge, option, end product | portfolio strategy |  |
+| wedge | A portfolio role: the narrow product or segment used to enter a market | Dixon (2010) | dixon-2010-thin-edge-of-the-wedge |
+| Product Anatomy | The method that judges products against the core product | ours |  |
+| Succession Matrix | Part of Product Anatomy that assigns portfolio roles by phase | ours |  |
+| telos | The end a venture exists to reach (purpose/telos.json): statement, end state, measures, the owners' intended outcome, and exit criteria for each phase. Start with the end: other layers derive from it | Aristotle (final cause); Covey, begin with the end in mind |  |
+| exit criterion | What must be true for a venture to leave a phase, written in its telos and tied to a telos measure; it refines that phase's generic gate. Not an owner's exit (governance) | Stage-Gate exit criteria (Cooper) |  |
+| validation score | The probability that a venture is validated: a weighted average of sub-scores (problem, solution, product-market fit, pricing, go-to-market, team, operations readiness), each a Jev probability times its evidence weight, with floors; replaces a declared phase gate (EE-026) | ours, after Blank's customer validation | blank-2005-four-steps |
+| evidence grade | How much a validation record's cited evidence can be trusted: high, moderate, low or very low, from the kind of signal, the audience, the sample, the specificity and the age; a claim with no evidence is very low | GRADE certainty of evidence | grade-handbook, fitzpatrick-2013-mom-test |
+| need-now score | The probability that a venture needs a record type in its current phase and the next, from priors raised or lowered by facts about the venture; records below 0.5 are held back unless the builder asks, so builders don't overbuild (EE-028) | ours; just-in-time (lean manufacturing) and YAGNI (extreme programming) in spirit |  |
+
+### Knowledge
+
+| Noun | Meaning | Standard | References |
+| --- | --- | --- | --- |
+| decision | A logged choice with an id (EE- or a venture's own prefix) | ADR practice |  |
+| reference | A source behind a default, recorded per layer with a stance | citation practice |  |
+
+### Operations
+
+| Noun | Meaning | Standard | References |
+| --- | --- | --- | --- |
+| tier | One of MAD's four levels: governance, delivery, software engineering, automation; MAD is a separate product, and Mentura records name a tier only where a venture uses MAD (EE-038) | architecture tiers |  |
+| handoff | One unit of delegated work: a JSON record (role, decision classes, done-criteria, status, attempts) at <venture>/operations/handoffs/<id>.json with a Markdown brief beside it | common operations usage |  |
+| done-criterion | One check that says a handoff is finished: conformance (a command, no model, no reviewer), self-proof (the change exercised for real, with output) or review (fit to intent, by a named role) | definition of done (Scrum) |  |
+
+### Evidence
+
+| Noun | Meaning | Standard | References |
+| --- | --- | --- | --- |
+| eval | A test of whether something worked; evals are grouped in eval suites (eval-suite.schema.json) | AI evals |  |
+| evidence | The recorded result of one run of a check or eval: subject and version, each criterion's outcome and its output, at <venture>/evidence/results/<id>.json. Append-only | common audit usage |  |
+| capability register | What agents can, cannot, may not or are not yet known to do, task by task, with sources and dates, fed by research and our own evals (evidence/capabilities/agent-capabilities.json, EE-029) | ours |  |
+
+### Governance
+
+| Noun | Meaning | Standard | References |
+| --- | --- | --- | --- |
+| role | A person's or agent's job; never a product's place in the portfolio | decision rights (RACI, RAPID) |  |
+| team plan | Who the venture needs, agent or person, by phase, with the authority each holds and where a human stays in the loop; recruiting briefs for open person roles (operations/team-plan.json, EE-029) | workforce planning (common HR usage) |  |
+| human loop | The person who decides, reviews or does the part of a task that agents cannot, may not, or are not known to do; named for every such agent task | human-in-the-loop (common AI usage) |  |
+| decision right | Who may decide what, at one of four levels: decide, decide-inform, recommend-approve, escalate. A venture may tighten the template, never loosen it without a named decision | decision rights (RAPID, DACI) |  |
+| cap table | The record of who owns the venture and on what terms: share classes, holders, grants with vesting, the option pool, SAFEs and notes (governance/ownership.json) | capitalization table (common startup and finance usage) |  |
+| share class | A kind of share (or LLC unit) with its own votes, price and rights: common, preferred, super-voting, non-voting | corporate law (classes of stock) |  |
+| vesting | Earning granted shares over time, commonly four years with a one-year cliff, so that someone who leaves early keeps only what they earned | common startup usage |  |
+| founder agreement | What founders agreed with each other: roles, commitment, IP assignment, departure and deadlock terms; required once two or more founders share ownership | common startup usage |  |
+| board | A formal board of directors (or managers, or trustees), which holds legal authority, or an advisory board, which advises and decides nothing (governance/board.json) | corporate law; Feld and Ramsinghani, Startup Boards |  |
+| reserved matter | A decision only the formal board may make, such as issuing shares or selling the company | corporate governance usage |  |
+| investor right | A right an investor gets with a class or instrument: board seat, information, pro-rata, protective provisions, anti-dilution, drag-along, tag-along, right of first refusal and others | NVCA model legal documents |  |
+| exit | How owners realize value or the venture ends: acquisition, IPO, secondary sale, merger, management buyout, wind-down, or hold (governance/exit.json) | venture finance usage |  |
+| preference stack | The order and amounts in which a sale's proceeds reach each owner, preferences first by seniority, then common; computed from the cap table by schema/payouts.mjs, never typed | venture finance usage (pref stack; Feld and Mendelson, Venture Deals) |  |
+| publication policy | Where a venture publishes and who may publish what there: its channels, the guidelines each follows, the checks and preview every publication passes, and who drafts and approves by role or team (governance/publication-policy.json, EE-025) | content governance; communications or disclosure policy (corporate usage) |  |
+| channel | A place the venture publishes to (website, docs site, social account, newsletter, app store, press, investor update, regulatory filing); its destination decides which guidelines apply | marketing channel (Kotler, Marketing Management) |  |
+| publication | One act of making something public on a channel; always a handoff under the public-commitment decision class, previewed, checked and approved by a person | common usage |  |
+| brand guidelines | The rules for using the venture's visual and verbal identity, kept by the brand pillar | brand guidelines or brand book (common marketing usage) |  |
+| editorial guidelines | What content covers and how it is written, separate from brand voice; a style guide is one part | editorial guidelines and style guide (publishing usage) |  |
+
+### Interface
+
+| Noun | Meaning | Standard | References |
+| --- | --- | --- | --- |
+| console | A custom interface built for the system: a viewer over a venture's records | common software usage |  |
+| interface | A tool through which a person, with agents, works across all or most other layers at once in one session (reaches at least four of the six). A tool that serves one or two layers is an integration of those layers, however good its screen is | ours, a narrowed sense of user interface |  |
+| agent harness | An AI harness in which the model directs its own steps and tool use in a loop toward a goal, acting on files, tools and systems between the person's turns, under permissions (Claude Code, Cursor, Codex, Hermes Agent). The default kind of interface. Every agent harness is an AI harness; a chatbot is not an agent harness | agent harness (industry usage) | anthropic-2024-building-effective-agents |
+| AI harness | A product that is the software around a model: the person's work happens in exchanges with it, so without the model nothing is left. A chatbot is one. The model answers; the person acts | harness (industry usage) | anthropic-2024-building-effective-agents |
+| AI feature | A model used inside a product that does its job without it (summaries, search, drafting). Test: remove the model and the product still works. Most apps that implement AI are here, not harnesses | common product usage | anthropic-2024-building-effective-agents |
+| custom interface | An interface built for the system or a venture rather than bought, such as the operator console | common software usage |  |
+| route | The address of one record type or command in a venture, such as purpose/validation/problem: a layer, then a kit when the record sits in a nested kit, then the record. Generated from the data model and kits; the CLI, the MCP server and the HTTP API share one route table (EE-030) | routing in web frameworks (Next.js App Router, Rails routes) |  |
+| draft | A gated record an agent wrote, held in <venture>/_drafts/ until a person accepts it; the decision class of the record says it is a person's to make (EE-030) | common usage (draft for approval) |  |
+| layout | The context that wraps a route: the system, layer and kit purpose, skills and references, the template, the gate and what need-now says, given to an agent before it acts on the route (EE-032) | Next.js App Router (layout) |  |
+| view | A route rendered as a page for a person; the Markdown form of a record or command result. The operator console will render views (EE-032) | Next.js App Router (page); MVC view |  |
+| route group | A named set of routes that shares a layout without changing their paths; one per phase, (discovery) to (platform), holding the routes need-now suggests in that phase (EE-032) | Next.js App Router (route groups) |  |
+| slot | One part of a page that renders on its own beside others, such as @validation in the venture overview; a slot that fails shows its error while the rest render (EE-032) | Next.js App Router (parallel routes, @slot) |  |
+| route alias | An old route kept after a rename, which the router follows to the new one with a deprecation note (EE-032) | common API usage (deprecation, redirects) |  |
+
+### Retired
+
+| Noun | Status |
+| --- | --- |
+| client | retired; use account (relationship: client) |
+| sphere | retired; use venture |
+| stage | retired; use phase, legal form and ambition |
+| kind | retired; use venture, with accounts as records |
+| Wedge (phase) | retired; use validation (wedge stays a portfolio role) |
+| Core Engine | retired; use scale |
+| Horizon (phase) | retired; use platform (Three Horizons stays a lens) |
+| entity profile | retired; use venture profile |
+| company template | retired; use venture template |
+| orientation | retired; use legal form |
+| liquidation waterfall | retired; use preference stack |
+| derived answer | retired; use undefined |
+| guiding statement | retired; use undefined |

package/docs/reference/ROUTES.md

@@ -0,0 +1,125 @@
+---
+type: reference
+source: generated
+created: 2026-10-27T20:52:31Z
+ai-model: claude-opus-5.5
+tags: [everything-ecosystem, mentura, routing, interfaces, reference]
+description: "Every route a venture has: the records and commands the CLI, the MCP server and the HTTP API reach, with their actions and gates (EE-030). The table below is generated from the data model and kits; test.mjs fails when it is stale."
+---
+
+# Routes
+
+One route table serves three interfaces: the CLI (`interface/cli/mentura.mjs`), the MCP server (`interface/mcp/server.mjs`) and the HTTP API (`interface/api/server.mjs`). All three call `interface/router.mjs`, so they cannot disagree. Install them into an agent harness with `interface/skills/install-mentura/SKILL.md`.
+
+Routes follow the Next.js App Router (EE-032). The path is the route: a record in a layer's own kit is `<layer>/<record>`, and a record in a nested kit is `<layer>/<kit>/<record>`, so a route is its record's folder path. The venture comes first: an id, or a nested venture's folder path (`studio/print`), given as `--venture`, a tool argument, or `/ventures/<venture>/` in the API.
+
+| Next.js | Here |
+| --- | --- |
+| `route` (API endpoint) | record actions read, write, check and template; command routes run |
+| `page` | the view action: a Markdown page for a person |
+| `layout` | the layout action: system, layer and kit context, skills, references, gate and need-now status |
+| `not-found`, `loading`, `error` | a missing record answers with its template and need-now status; a waiting draft is reported on read; a failed check or write answers with the kit's skills and template |
+| `[id]` | collection items: `purpose/product/[id]` beside the list route `purpose/product` |
+| `[...slug]` | the venture: `studio/print` |
+| `(group)` | route groups by phase, below |
+| `@slot` | `system/overview`: slots that render side by side, one failing without stopping the rest |
+| `_private` | `_drafts/`, never routed |
+| `proxy` | gates before every write: schema, decision class (from the data model, applied from the venture's decision rights), the role's routes |
+| `robots` | team-plan roles may list the routes they read and write; `system/robots` shows them |
+| redirects | `interface/route-aliases.json`: a renamed route keeps its old one as an alias |
+
+Nothing here is written by hand: add a record type to `schema/data-model.json` and a kit, and its route appears. Regenerate the table with `node interface/router.mjs --md`.
+
+## Routes (generated by `node interface/router.mjs --md`)
+
+Every route works on one venture, named in front of it: its id, or its folder path for a nested venture (`studio/print`). Record routes read, write, check, view, lay out or show the template of one record type; a collection has a list route and an `[id]` item route; command routes run a venture-wide tool and can be viewed. A write is checked against the record's schema first; a record whose decision class escalates is written as a draft when an agent writes it, for a person to accept.
+
+| Route | Kind | Actions | Files or script | Decision class | Groups | What it is |
+| --- | --- | --- | --- | --- | --- | --- |
+| `.release/venture-package` | record | read, view, layout | `.release/venture-package.json`, `.release/layout.json`, `package/venture-package.json` |  | (discovery) (validation) (beachhead) (scale) (platform) | The venture package view (EE-067, EE-069): the open core packages and handoffs, each record confirmed, to review or to write, what moves now and what waits, with its versions; the records themselves stay in place |
+| `customers` | record (list) | read, view, layout | `customers/*.json` |  |  | A customer master record. Activity is an append-only stream. The package is never complete (EE-070). |
+| `customers/[id]` | record (item) | read, view, layout, write | `customers/*.json` |  |  | A customer master record. Activity is an append-only stream. The package is never complete (EE-070). |
+| `decisions` | record (list) | read, view, layout | `decisions/*.decision.json` |  | (discovery) (validation) (beachhead) (scale) (platform) | One live decision, in a decisions/ folder beside the record it decides, with its parent, boundary (fail closed or open) and the phase it is needed in (EE-054, EE-057); node schema/decisions.mjs renders the matrix. The decision log keeps the history |
+| `decisions/[id]` | record (item) | read, view, layout, write | `decisions/*.decision.json` |  | (discovery) (validation) (beachhead) (scale) (platform) | One live decision, in a decisions/ folder beside the record it decides, with its parent, boundary (fail closed or open) and the phase it is needed in (EE-054, EE-057); node schema/decisions.mjs renders the matrix. The decision log keeps the history |
+| `evidence` | record (list) | read, view, layout, check | `evidence/results/*.json` |  | (validation) (beachhead) (scale) (platform) | Append-only results of running checks |
+| `evidence/[id]` | record (item) | read, view, layout, write, check | `evidence/results/*.json` |  | (validation) (beachhead) (scale) (platform) | Append-only results of running checks |
+| `foundation/alignment` | record | read, view, layout, write | `foundation/alignment.json`, `purpose/alignment.json` | strategy-or-constitution | (discovery) (validation) (beachhead) (scale) (platform) | How the venture's products and agents must behave: principles with a source and a check (EE-053); a foundation statement, gated |
+| `foundation/icp` | record | read, view, layout, write | `foundation/icp.json`, `purpose/icp.json` | strategy-or-constitution | (discovery) (validation) (beachhead) (scale) (platform) | Who the venture serves: ideal customer profiles, one primary (EE-051); a foundation statement, gated |
+| `foundation/problem` | record | read, view, layout, write, check, template | `foundation/problem.json`, `purpose/validation/problem.json` | strategy-or-constitution | (discovery) (validation) (beachhead) | The problem sub-score of validation: the claim and its cited evidence, each item graded (EE-026). Shares schema/validation-evidence.schema.json with every sub-score Gated like the telos (EE-050): the problem statement is a founder-critical record, so an agent's write is a draft the founder accepts. |
+| `foundation/telos` | record | read, view, layout, write, check, template | `foundation/telos.json`, `purpose/telos.json` | strategy-or-constitution | (validation) (beachhead) (scale) (platform) | The end the venture exists to reach: statement, end state, measures, owner outcome, exit criteria per phase (EE-023) |
+| `governance/analytics` | command | run, layout | `schema/decision-analytics.mjs` |  |  | Decision analytics (EE-072): how many decisions of each type each function has made, open against decided, in whose words, in which phase, and their outcomes. Data only; a view is the platform's, or a visualization skill's |
+| `governance/board` | record | read, view, layout, write, check | `governance/board.json` | ownership-or-control | (platform) | Formal and advisory boards, their seats and reserved matters |
+| `governance/decision-rights` | record | read, view, layout, write, check | `governance/decision-rights.json` | strategy-or-constitution | (validation) (beachhead) (scale) (platform) |  |
+| `governance/decisions` | command | run, view, layout | `schema/decisions.mjs` |  |  | The decision matrix: every decision the venture owes by layer and phase, with its parent and boundary, and whether it renders now, waits, comes later, is stale or deferred (EE-054, EE-057) |
+| `governance/exit` | record | read, view, layout, write, check | `governance/exit.json` | ownership-or-control | (scale) (platform) | Exit paths kept open and sale values to model; payouts computed by payouts.mjs |
+| `governance/founder-agreement` | record | read, view, layout, write, check | `governance/founder-agreement.json` | ownership-or-control |  | What founders agreed: roles, commitment, IP, departure, deadlock; prose beside it |
+| `governance/ownership` | record | read, view, layout, write, check | `governance/ownership.json` | ownership-or-control | (scale) (platform) | The cap table: share classes and their rights, holders, grants with vesting, option pool, SAFEs and notes (EE-022) |
+| `governance/payouts` | command | run, view, layout | `schema/payouts.mjs` |  |  | Who gets what at a sale value, from the cap table (EE-022); input value, else the scenarios in exit.json |
+| `governance/pillar` | record (list) | read, view, layout | `pillars/*.md` |  | (beachhead) (scale) (platform) | The product, brand and business pillars: teams, roles and deliverables. The template holds the guides; a venture holds one-line stubs that link to them |
+| `governance/pillar/[id]` | record (item) | read, view, layout | `pillars/*.md` |  | (beachhead) (scale) (platform) | The product, brand and business pillars: teams, roles and deliverables. The template holds the guides; a venture holds one-line stubs that link to them |
+| `governance/publication-policy` | record | read, view, layout, write, check | `governance/publication-policy.json` | strategy-or-constitution | (validation) (beachhead) (scale) (platform) | Where the venture publishes and who may publish what there: channels, guidelines, checks, preview and approvers; every publication passes this gate (EE-025) |
+| `ideas/graph` | record | read, view, layout, write | `ideas/graph.json`, `purpose/ideas/graph.json` |  | (discovery) (validation) | The idea map as a Merkle DAG: each idea with the ideas it builds on, a hash over its text and theirs, its signal, and its lane (in order or on its own); laid out left to right by dependency and top down by signal (EE-060) |
+| `ideas/map` | record | read, view, layout | `ideas/map.mdx`, `purpose/ideas/map.mdx` |  | (discovery) (validation) | The idea dump mapped onto Naive's conventions: one <Idea> per idea, its text unchanged, tagged with departments, records and whether it exists (purpose/frameworks/idea-map); drawn as a mind map (EE-059) |
+| `investors` | record (list) | read, view, layout | `investors/*.json` |  |  | An investor master record. Activity is an append-only stream. The package is never complete (EE-070). |
+| `investors/[id]` | record (item) | read, view, layout, write | `investors/*.json` |  |  | An investor master record. Activity is an append-only stream. The package is never complete (EE-070). |
+| `knowledge/catalog` | command | run, view, layout | `knowledge/connectors/catalog.mjs` |  |  | Build or refresh the catalog: every item in every source the venture keeps records in, with its address and version, no content (EE-037) |
+| `knowledge/knowledge-sources` | record | read, view, layout, write, check | `knowledge/sources.json` |  | (scale) (platform) | Which source each record type lives in: the venture's own folder by default, or a connected source such as a GitHub repository (EE-037); its rules are the source-of-truth matrix: a system of record and owner per record type, attribute and context (EE-042) |
+| `knowledge/search` | command | run, view, layout | `knowledge/connectors/catalog.mjs` |  |  | Find items across every source through the catalog; input value is the query (EE-037) |
+| `knowledge/venture-profile` | record | read, view, layout | `profile.md` |  | (discovery) (validation) (beachhead) (scale) (platform) | The venture's story and thesis in prose, beside venture.json |
+| `knowledge/where-used` | record | read, view, layout, write, check | `knowledge/where-used.json` |  | (scale) (platform) | For each fact kept once in its system of record, every place that repeats it; live children must show the parent's value (EE-042) |
+| `marketing/content` | record | read, view, layout | `marketing/content/**/*.mdx`, `operations/marketing/content/**/*.mdx` |  | (beachhead) (scale) (platform) | Public variants of internal records, written by marketing agents as their own MDX: each names the record it is a variant of, its audience, whether it is published and who approved it; checked by the public gate (EE-064) |
+| `marketing/sitemap` | record | read, view, layout, write | `marketing/sitemap.json`, `operations/marketing/sitemap.json` |  | (validation) (beachhead) (scale) (platform) | The planned public site: each page's sections in order, with the MDX component, the need, the audience and why, when it shows, the internal record it draws on and the public variant to write; part of the marketing package handed to engineering (EE-064, EE-065) |
+| `money` | record (list) | read, view, layout | `money/*.json` |  |  | A money master record. Activity is an append-only stream. The package is never complete (EE-070). |
+| `money/[id]` | record (item) | read, view, layout, write | `money/*.json` |  |  | A money master record. Activity is an append-only stream. The package is never complete (EE-070). |
+| `operations/department` | record | read, view, layout, check | `departments/*/department.json`, `departments/*/*/department.json` |  | (validation) (beachhead) (scale) (platform) | The tag in each department folder, in the governance or operations layer; an optional primary/ or support/ grouping folder is for looking at only (EE-047) |
+| `operations/handoff` | record (list) | read, view, layout, check | `operations/handoffs/*.json` |  | (validation) (beachhead) (scale) (platform) | Execution folded into operations (EE-038). |
+| `operations/handoff/[id]` | record (item) | read, view, layout, write, check | `operations/handoffs/*.json` |  | (validation) (beachhead) (scale) (platform) | Execution folded into operations (EE-038). |
+| `operations/marketing/public` | command | run, view, layout | `operations/marketing/check-public.mjs` |  |  | The public gate: every marketing content file is a variant of a named internal record, says its audience and whether it is published, has a person's approval when published, and copies no run of ten words from its internal record (EE-064) |
+| `operations/marketing/site` | command | run, view, layout | `operations/marketing/site/presence.mjs` |  |  | How present the venture's public records are on its marketing site: a score weighed by who the site must speak to now (raising, hiring, contributors, ICPs), and each item missing, not prominent enough or present, with where it belongs (EE-062). Read the site first with interface/harness/site.mjs |
+| `operations/marketing/sitemap` | command | run, view, layout | `operations/marketing/site/plan.mjs` |  |  | Plan the public site from the venture's records: the product decides whom it is offered to, that decides the audiences, and each page gets its sections in order with the MDX component, need, audience, reason, condition, source record and the public variant to write (EE-064) |
+| `operations/site-presence` | record | read, view, layout, write | `operations/marketing/site-presence.json` |  | (validation) (beachhead) (scale) (platform) | How present the venture's public records are on its marketing site, item by item, with a score weighed by who the site must speak to now (EE-062) |
+| `people/team` | record | read, view, layout, write, check, template | `people/team.json`, `purpose/validation/team.json` |  | (validation) (beachhead) (scale) | Validation sub-score: skills needed, held and the gaps; cofounder sought (EE-026) |
+| `people/team-plan` | record | read, view, layout, write, check | `people/team-plan.json`, `operations/team-plan.json` |  | (validation) (beachhead) (scale) (platform) | Who the venture needs, agent or person, when, with what authority, and where a human stays in the loop; recruiting briefs for open person roles (EE-029) |
+| `product` | record (list) | read, view, layout, check | `product/*.json`, `products/*.json` |  | (discovery) (validation) (beachhead) (scale) (platform) |  |
+| `product/[id]` | record (item) | read, view, layout, write, check | `product/*.json`, `products/*.json` |  | (discovery) (validation) (beachhead) (scale) (platform) |  |
+| `product/anatomy` | record (list) | read, view, layout | `product/anatomy/*.json`, `purpose/anatomy/*.json` |  | (beachhead) (scale) (platform) | Product Anatomy input for one product with parts (venture, core, products, flows), such as Naive or Mentura; read by purpose/frameworks/product-anatomy/anatomy.mjs |
+| `product/anatomy-answers` | record | read, view, layout | `product/anatomy/answers*.json`, `product/anatomy.answers*.json`, `purpose/anatomy.answers*.json` |  | (beachhead) (scale) (platform) | Scores per product per question; the matrix is rendered from them |
+| `product/anatomy/[id]` | record (item) | read, view, layout | `product/anatomy/*.json`, `purpose/anatomy/*.json` |  | (beachhead) (scale) (platform) | Product Anatomy input for one product with parts (venture, core, products, flows), such as Naive or Mentura; read by purpose/frameworks/product-anatomy/anatomy.mjs |
+| `purpose/account` | record (list) | read, view, layout, check | `accounts/*/account.json` |  | (beachhead) (scale) (platform) | A named party the venture keeps a record for: client, customer, user, member or partner (EE-021). Optional |
+| `purpose/account/[id]` | record (item) | read, view, layout, write, check | `accounts/*/account.json` |  | (beachhead) (scale) (platform) | A named party the venture keeps a record for: client, customer, user, member or partner (EE-021). Optional |
+| `purpose/data-stream` | record (list) | read, view, layout | `customers/_streams/*/stream.json`, `investors/_streams/*/stream.json`, `money/_streams/*/stream.json` |  |  | Declares one append-only stream and whether it is sensitive (EE-070). |
+| `purpose/data-stream/[id]` | record (item) | read, view, layout, write | `customers/_streams/*/stream.json`, `investors/_streams/*/stream.json`, `money/_streams/*/stream.json` |  |  | Declares one append-only stream and whether it is sensitive (EE-070). |
+| `purpose/foundation` | command | run, view, layout | `schema/foundation.mjs` |  |  | The venture's strategic foundation by the Five Ws and How plus whether, each confirmed, drafted by an agent, waiting as a draft, or missing (EE-051) |
+| `purpose/ideas` | command | run, view, layout | `purpose/frameworks/idea-map/ideamap.mjs` |  |  | The founder's idea dump mapped onto Naive's conventions: each idea verbatim with its departments, records and whether it exists, where the ideas cluster, what the dump never mentions, and what it says about whether a product exists (EE-059) |
+| `purpose/ideas/graph` | command | run, view, layout | `purpose/frameworks/idea-map/graph.mjs` |  |  | The idea graph: which ideas build on which, each idea's signal, the lanes that move in order and the ones that can move on their own, and the ideas to develop next (EE-060) |
+| `purpose/ideas/routes` | command | run, view, layout | `purpose/frameworks/idea-map/route.mjs` |  |  | Where each idea goes in the framework: the records it feeds, each destination's stage (routed, drafted, your decision, waiting, done), whether it moves in order or on its own, and the one step that moves it; plus the decision docket traced to the ideas (EE-061) |
+| `purpose/raw/text` | record (list) | read, view, layout | `raw/sources/*/text.md` |  |  | The text of a raw source. original.* stays out of git (EE-070). |
+| `purpose/raw/text/[id]` | record (item) | read, view, layout | `raw/sources/*/text.md` |  |  | The text of a raw source. original.* stays out of git (EE-070). |
+| `purpose/validation/assess` | command | run, view, layout | `schema/assess-problem.mjs` |  |  | What the problem's evidence is strong enough for: each assumption labelled demonstrated, inferred, assumed, unknown or contradicted, the commitment it supports and the next test (EE-050). Asks first when the record is incomplete; input as_is runs it anyway |
+| `purpose/validation/score` | command | run, view, layout | `schema/check-validation.mjs` |  |  | Held (EE-050): the single validation score from graded evidence (EE-026); purpose/validation/assess replaces it for the problem |
+| `raw/dump` | record | read, view, layout | `raw/dump.md`, `purpose/ideas/dump.md` |  | (discovery) (validation) | The founder's raw idea dump: every idea about the venture, verbatim and unprompted. Never rewritten by an agent (EE-059) |
+| `raw/sources` | record (list) | read, view, layout | `raw/sources/*/source.json` |  |  | Where a founder-supplied source came from. Raw is immutable (EE-070). |
+| `raw/sources/[id]` | record (item) | read, view, layout, write | `raw/sources/*/source.json` |  |  | Where a founder-supplied source came from. Raw is immutable (EE-070). |
+| `system/need-now` | command | run, view, layout | `schema/need-now.mjs` |  |  | What the venture needs now, soon, or should hold back (EE-028) |
+| `system/overview` | command | run, view, layout | router |  |  | The venture at a glance: telos, validation, need-now, time to ready, team and recent provenance, rendered as parallel slots |
+| `system/package` | command | run, view, layout | `schema/packages.mjs` |  |  | The venture package (EE-067, EE-069): the core packages open now and the handoffs, each record confirmed, to review or to write, what moves on its own and what waits, and what completion unlocks; --write renders the view and records a version. Assumes a solo founder or small founding team in Discovery and Validation; agents are a package enhancement |
+| `system/provenance` | record | read, view, layout, check | `provenance.jsonl` |  | (discovery) (validation) (beachhead) (scale) (platform) | Who or what wrote each record, how, from what and under which decision: one append-only line per write, hash-chained, after W3C PROV (EE-031) |
+| `system/robots` | command | run, view, layout | router |  |  | Which roles may read and write which routes, from the team plan |
+| `system/time-to-ready` | command | run, view, layout | `schema/time-to-ready.mjs` |  |  | Time to running, and to ready per layer and MAD tier |
+| `validation/go-to-market` | record | read, view, layout, write, check, template | `validation/go-to-market.json`, `purpose/validation/go-to-market.json` |  | (validation) (beachhead) (scale) | Validation sub-score: path, motion, channels and evidence a channel works; the path sets the weights (EE-026) |
+| `validation/operations-readiness` | record | read, view, layout, write, check, template | `validation/operations-readiness.json`, `purpose/validation/operations-readiness.json` |  | (beachhead) (scale) (platform) | Validation sub-score: per MAD tier evidence; grades as the weakest tier (EE-026) |
+| `validation/pricing` | record | read, view, layout, write, check, template | `validation/pricing.json`, `purpose/validation/pricing.json` |  | (validation) (beachhead) (scale) | Validation sub-score: price model, points, buyer and evidence they pay (EE-026) |
+| `validation/product-market-fit` | record | read, view, layout, write, check, template | `validation/product-market-fit.json`, `purpose/validation/product-market-fit.json` |  | (validation) (beachhead) | Validation sub-score: retention cohorts, Ellis survey and evidence that a segment keeps using it (EE-026) |
+| `validation/solution` | record | read, view, layout, write, check, template | `validation/solution.json`, `purpose/validation/solution.json` |  | (validation) (beachhead) | Validation sub-score: how it solves the problem and the evidence people choose it (EE-026) |
+
+### Route groups (generated)
+
+A group gathers the routes need-now suggests in a phase. It changes the layout an agent is given, not the path.
+
+| Group | The phase asks | Routes |
+| --- | --- | --- |
+| `(discovery)` | Does a real problem exist, and who has it? | `.release/venture-package`, `decisions`, `decisions/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/problem`, `ideas/graph`, `ideas/map`, `knowledge/venture-profile`, `product`, `product/[id]`, `raw/dump`, `system/provenance` |
+| `(validation)` | Will people adopt this solution and keep using it? | `.release/venture-package`, `decisions`, `decisions/[id]`, `evidence`, `evidence/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/problem`, `foundation/telos`, `governance/decision-rights`, `governance/publication-policy`, `ideas/graph`, `ideas/map`, `knowledge/venture-profile`, `marketing/sitemap`, `operations/department`, `operations/handoff`, `operations/handoff/[id]`, `operations/site-presence`, `people/team`, `people/team-plan`, `product`, `product/[id]`, `raw/dump`, `system/provenance`, `validation/go-to-market`, `validation/pricing`, `validation/product-market-fit`, `validation/solution` |
+| `(beachhead)` | Can we win one segment repeatably, at a profitable cost? | `.release/venture-package`, `decisions`, `decisions/[id]`, `evidence`, `evidence/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/problem`, `foundation/telos`, `governance/decision-rights`, `governance/pillar`, `governance/pillar/[id]`, `governance/publication-policy`, `knowledge/venture-profile`, `marketing/content`, `marketing/sitemap`, `operations/department`, `operations/handoff`, `operations/handoff/[id]`, `operations/site-presence`, `people/team`, `people/team-plan`, `product`, `product/[id]`, `product/anatomy`, `product/anatomy-answers`, `product/anatomy/[id]`, `purpose/account`, `purpose/account/[id]`, `system/provenance`, `validation/go-to-market`, `validation/operations-readiness`, `validation/pricing`, `validation/product-market-fit`, `validation/solution` |
+| `(scale)` | How fast can we take the mass market? | `.release/venture-package`, `decisions`, `decisions/[id]`, `evidence`, `evidence/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/telos`, `governance/decision-rights`, `governance/exit`, `governance/ownership`, `governance/pillar`, `governance/pillar/[id]`, `governance/publication-policy`, `knowledge/knowledge-sources`, `knowledge/venture-profile`, `knowledge/where-used`, `marketing/content`, `marketing/sitemap`, `operations/department`, `operations/handoff`, `operations/handoff/[id]`, `operations/site-presence`, `people/team`, `people/team-plan`, `product`, `product/[id]`, `product/anatomy`, `product/anatomy-answers`, `product/anatomy/[id]`, `purpose/account`, `purpose/account/[id]`, `system/provenance`, `validation/go-to-market`, `validation/operations-readiness`, `validation/pricing` |
+| `(platform)` | What will others build on, so the venture can't be displaced? | `.release/venture-package`, `decisions`, `decisions/[id]`, `evidence`, `evidence/[id]`, `foundation/alignment`, `foundation/icp`, `foundation/telos`, `governance/board`, `governance/decision-rights`, `governance/exit`, `governance/ownership`, `governance/pillar`, `governance/pillar/[id]`, `governance/publication-policy`, `knowledge/knowledge-sources`, `knowledge/venture-profile`, `knowledge/where-used`, `marketing/content`, `marketing/sitemap`, `operations/department`, `operations/handoff`, `operations/handoff/[id]`, `operations/site-presence`, `people/team-plan`, `product`, `product/[id]`, `product/anatomy`, `product/anatomy-answers`, `product/anatomy/[id]`, `purpose/account`, `purpose/account/[id]`, `system/provenance`, `validation/operations-readiness` |