Decisions
Every decision in force, newest first, rendered from docs/decisions/decisions.json.
| Id | Date | Decision |
|---|---|---|
| EE-036 | 2026-10-28 | SAD is removed from Mentura. The knowledge layer is the memory layer: where every record is stored and found (route, schema, provenance), holding the decision log, venture profile, design documents and references. Every other layer defines the records it writes to memory and their conventions; operations (MAD) is the one layer that is a method rather than record conventions. Storage is not fixed: files today, a database possible later. The SAD method documents, systems, references, artifacts, templates and seventeen SAD skills are deleted (git keeps them); the layer keeps two skills, find-reference and industry-awareness. SAD's surviving rules become checks and skills in the layers that need them. SAD continues as its own separate project. |
| EE-034 | 2026-10-27 | The developer docs are a Nextra 4 site (docs theme) on the latest Next.js, in site/ of this repository rather than a separate repo, so docs and code change in one pull request and the site renders routes, nouns, kits and decisions from the repository at build time. It reads method-level records only, never an instance venture. It stays unpublished (noindex, no deploy) until the owner accepts the developer-docs channel in the venture's publication policy, drafted for that decision. zod is pinned to 4.1.12 because later 4.x releases reject the theme's optional props. |
| EE-033 | 2026-10-27 | File formats are chosen by the first of these that holds: a program reads or writes it, so JSON with a schema; an append-only log, so JSONL; another tool expects the name (SKILL.md, AGENTS.md, CLAUDE.md, README.md, vault notes), so .md; prose for people that is published or needs a component or live data, so MDX; prose that stays private, so .md. MDX pages must compile (site/scripts/check-mdx.mjs, run by test.mjs and CI). |
| EE-032 | 2026-10-27 | Routes follow the Next.js App Router's conventions, with layers kept as route segments so a route is its record's folder path. Built: [id] item routes for collections (products, accounts, handoffs, evidence) beside their list routes; the venture as a catch-all segment, an id or a nested venture's folder path (studio/print); layout (the system, layer and kit context, skills, references, template, gate and need-now status an agent gets before acting); not-found (a missing record answers with its template, schema, skills and need-now status), loading (a waiting draft is reported on read) and error (a failed check or write answers with the kit's skills and template); views, Markdown pages for people (the page convention), and system/overview, a page of parallel slots where one failing slot does not stop the others; route groups by phase, (discovery) to (platform), which gather the routes need-now suggests in that phase without changing paths; robots, the routes a team-plan role may read and write, shown at system/robots; route aliases for renames (interface/route-aliases.json); and gates declared in the data model (decision_class on a record type), applied from the venture's decision rights instead of a list in code. |
| EE-031 | 2026-10-27 | Provenance is built in two ways. Explicitly: every write through the router (CLI, MCP server, HTTP API) appends one line to the venture's provenance log, <venture>/provenance.jsonl, after W3C PROV: the entity (file) written, the activity (write, draft, accept, or baseline for a record adopted as it stood), the agent (person or AI agent, with id, model, session and harness where known, and the interface), what the content was derived from (paths, URLs, decision ids) and the decision or decision class it acted under, with a hash of the content. Each line carries the previous line's hash, so schema/check-provenance.mjs fails when a line is edited, removed or reordered, and warns when a logged file has changed outside the router. Implicitly: git history covers everything written outside the router. The log is a system record, on whatever layers a venture uses; record schemas carry no provenance fields. Existing provenance stays where it is: evidence items and references cite sources with checked dates, and notes carry source and ai-model. |
| EE-030 | 2026-10-27 | The system has one route table, generated from schema/data-model.json and the kit manifests by interface/router.mjs, and three interfaces over it: a CLI (interface/cli/mentura.mjs), an MCP server (interface/mcp/server.mjs) and a local HTTP API (interface/api/server.mjs). A route is <layer>[/<kit>]/<record> with the actions read, write, check and template, or a command with run. Every write is validated against the record's schema; an agent's write to a record whose decision class escalates to a person (ownership, board, founder agreement, exit, telos, decision rights, publication policy) is held as a draft for a person to accept, and the MCP server and API always write as an agent. Adoption may be partial: a venture turns on only the layers it wants (init --layers), and a route needs only its own records. An install skill sets it up in Claude Code and Cursor. |
| EE-029 | 2026-10-27 | The operations layer designs the team: operations/team-plan.json says which roles agents fill and which people fill, by phase, with the decision classes each holds and a named human loop for every agent task that the capability register marks can-with-review, cannot, not-allowed or unknown. Open person roles needed in the current phase are recruited now, from a brief; agents draft, search and screen, and a person makes contact and decides. The evidence layer keeps the capability register, dated and sourced, fed by new research and by our own evals; an unknown task keeps a person in the loop and becomes an eval. |
| EE-028 | 2026-10-27 | The framework says what a venture needs now, what comes soon and what to hold back. schema/need-now.json gives each venture record type a prior probability per phase, raised or lowered by facts about the venture (people, founders, agents, funding, legal form, products, go-to-market path, publishing); schema/need-now.mjs lists records to suggest now (0.5 or more), coming soon (the next phase reaches 0.5), held, and held back. Jev re-scores the priors per venture once the scorer runs. |
| EE-026 | 2026-10-27 | Validation is a probability built from cited evidence, not a declared phase. A validation kit in the purpose layer gives each sub-score (problem first; then solution, product-market fit, pricing, go-to-market, team, operations readiness per MAD tier) its own record type, template and references, all sharing one evidence item. schema/check-validation.mjs grades every item and record high, moderate, low or very low by adapting GRADE: the kind of signal sets the start (behavior high, commitment moderate, stated intent and desk research low, opinion very low), and the wrong audience, a small sample, general answers and age lower it; a claim with no evidence is very low. The grade weighs the sub-score's Jev probability in the validation score. A layer may hold more than one kit, under <layer>/kits/<kit>/. |
| EE-025 | 2026-10-27 | Publishing is a governance matter. Each venture keeps a publication policy (governance/publication-policy.json) that lists its channels, the guidelines each follows (brand and editorial from the pillars, plus outside rules such as platform or advertising law), the checks and preview every publication passes, and who drafts and who approves by role or team. Every publication passes this gate: it runs as a handoff under public-commitment and names its channel and content; agents may draft, check and preview, and a person approves. A channel on a third-party platform (Substack, X, Facebook and others) names the platform and cites its rules; social, newsletter and blog channels say whether replies and comments are gated, delegated to named people, or not made. publish.json moves from operations to governance as the method site's channel configuration. Publisher rule R1 now refuses only files outside the repository (an absolute path, a path through .., or a link resolving outside the root); inside it, publish.json decides. |
| EE-021 | 2026-10-27 | The client record becomes the account record: accounts/<id>/account.json (account.schema.json), optional, for ventures that keep records per named party. Each account has a relationship: client, customer, user, member, partner or other. Who a product serves in general stays its market, which gains the same relationship (plus audience). 'client' is retired as a record name and kept as one relationship value. |
| EE-017 | 2026-10-27 | Execution, evidence and governance get machine-checkable records, so a venture can run end to end. A handoff is JSON at <venture>/execution/handoffs/<id>.json (handoff.schema.json) beside its Markdown brief: role, decision classes, done-criteria (conformance, self-proof, review), status, attempts, run cap, PR, evidence, escalations and lesson. Evidence is the append-only result of one run at <venture>/evidence/results/<id>.json (evidence.schema.json); eval suites follow eval-suite.schema.json. Decision rights follow decision-rights.schema.json; a venture's file tightens the template and may loosen a class only by naming a decision. schema/run-handoff.mjs runs a handoff's criteria and writes evidence; schema/check-execution.mjs holds handoffs to their role's classes, EE-006's conformance and self-proof, attempts, and passing evidence before done. Layer locations are relative to the venture folder; venture members may be agents; business models use schema/vocab/business-models.json; a product may list several markets with one primary; the Product Anatomy runner needs a revenue score of 2 for a revenue engine and counts a standalone part of the flagship kit as a wedge. |
| EE-016 | 2026-10-27 | The interface layer holds interfaces only: tools through which a person, with agents, works across at least four of the six other layers in one session. Agent harnesses (Claude Code, Cursor, Codex) are the default kind and the operator console is a custom one. A tool that serves one or two layers is an integration of those layers (Obsidian under knowledge), checked by schema/check-integrations.mjs. Three AI levels, recorded as a product's ai field: AI feature (the product works without the model), AI harness (the product is the software around a model; a chatbot), agent harness (an AI harness where the model directs its own steps and tool use toward a goal). Every agent harness is an AI harness; a chatbot is not an agent harness. |
| EE-015 | 2026-10-27 | Kits have a scope. A product card may name its scope (the whole system, one layer, or one tier of the operations layer) and the kits it is part of (part_of); a part can still be its own product. The Everything Ecosystem's own schema and method skills are one offering, the system kit; some skills, such as the five-step algorithm skill, are also products by themselves. |
| EE-014 | 2026-10-27 | The system is highly opinionated, with references at every layer. Standards first: a noun uses an established term with its standard meaning and is coined only when none exists. docs/ontology.json is canonical for nouns (docs/ontology.md is generated from it); schema/check-nouns.mjs fails when a retired noun reappears. Each layer records the sources behind its defaults, and the alternatives weighed, in <layer>/references/references.json with title, authors, year, summary, a URL when one exists and a stance; the find-reference skill fills and re-checks them. The genus of the whole (operating system or operating model) stays open until the first venture runs end to end; files say "the system". |
| EE-013 | 2026-10-27 | Nouns that meant two things are split. Layer means only the system's seven layers; MAD's four become tiers. A product's place in the portfolio is its portfolio role; a bare role is a person's or agent's job. Wedge keeps its business meaning, a portfolio role (the narrow product used to enter a market), and is not a phase. The proposed for-profit/nonprofit axis is dropped: legal form carries it, with benefit-corp added. |
| EE-012 | 2026-10-27 | Phase replaces stage. A venture's phases are Discovery, Validation, Beachhead, Scale and Platform, each with a gate for leaving it: problem-solution fit, product-market fit (retention holds), repeatability, market leadership with healthy margins, and others building on it. Formalization is form.legal_form; intent is ambition (hobby, survival, lifestyle, managed growth, aggressive growth). The core product is required once a venture leaves Discovery. Starting layers come from the phase; governance switches on when the venture is formalized. |
| EE-011 | 2026-10-27 | The venture is the unit of an instance, replacing the sphere. A venture is anything a builder undertakes, from a hobby to a company, and ventures can hold ventures. Each keeps a venture.json beside its venture profile (the readable companion, replacing the entity profile). Products are cards in products/, holding their own market, job, technology, offering and business model; venture.json keeps only what is true of the whole venture (phase, ambition, form, industry, core product). Clients are records in clients/ inside the venture that serves them, no longer units. The company template is renamed the venture template. |
| EE-010 | 2026-10-27 | The company template (governance/company-template/) stays, as the venture template. Its three pillars (product, brand, business) are scaffolded into every venture at every stage, because even a venture that is not a legal entity has a product, a brand and a business side. Governance (roles and decision rights) still starts only at the company stage. |
| EE-009 | 2026-10-27 | Personal life is out of scope. A sphere is a venture or a client inside a venture; there is no personal root, and household, employer, community and learning kinds are dropped, with values and purpose weights. Top-level spheres are ventures. Personal knowledge management will be a separate system, built on its own, that can later read from or share with an instance through links. |
| EE-007 | 2026-10-26 | Each layer lists its tools in <layer>/tooling/integrations.json. Choosing tools is opt-in: when someone wants help, the agent asks situation questions from the layer's principles and examples, and scores with Jev plus a reasoning model; people who name their tools just have them recorded. |
| EE-006 | 2026-10-26 | A handoff includes a self-proof step (the agent exercises its change for real), allows 3 attempts and a 2-hour run cap before escalating, and ends with a one-line lesson when something failed for a reason that could recur. |
| EE-005 | 2026-10-25 | Docs as code: the method, design docs, schemas, skills and templates live in this repo. An instance keeps its own notes, philosophy and decisions in its own spheres. |
| EE-002 | 2026-10-27 | The Everything Ecosystem is a schema, described as the AI-Native OS for Builders. An instance is one person's workspace, declared by a workspace.json naming the schema version it follows. The schema does not depend on any instance. |
| EE-001 | 2026-10-26 | The methodology has five layers that form a loop (Purpose, Knowledge, Operations, Execution, Evidence) and two that cut across them (Governance, Interface). Knowledge is SAD; Operations is MAD. |
Last updated on