Layers and kits
Every venture has the same seven layers, each at the depth the venture needs. A layer you do not use yet is off.
A kit is what a layer offers: skills for agents, record types with their schemas, checks, templates and references, meant to be used together. Each layer has one kit, and it may hold more under <layer>/kits/. The validation kit, for example, lives inside the purpose layer.
A template is a fill-in starting point for one record or document. A kit holds templates; a template holds no rules and checks nothing.
The kits
| Kit | Layer | Purpose | Skills | Records |
|---|---|---|---|---|
purpose/kit.json | purpose | Say why the venture exists and what it offers: core product, ambition, product cards, accounts, and each product's role by phase (Product Anatomy). | 2 | product, account, anatomy-framework, anatomy-answers, telos |
knowledge/kit.json | knowledge | The memory layer: where every record is stored. The other layers each define the records they write here and the conventions for them; this layer defines only how a record is stored and found (route, schema, provenance), the decision log, the venture profile, design documents and the sources behind them. Storage is not fixed: files today, a database later (EE-036). | 2 | venture-profile, decision, design-document |
operations/kit.json | operations | Decide how work is run (MAD): which methodology builds each system, which artifacts it needs, which tools each layer uses, and the build roadmap. | 7 | methodology, question, artifact-type, assignment, catalog-common, recommendation, mad-answers, team-plan |
execution/kit.json | execution | Do the work: handoffs that hand one unit of work to a role with its decision rights, done-criteria, attempt limit and run cap. | 0 | handoff |
evidence/kit.json | evidence | Prove what is true: results of running checks, eval suites, benchmarks, and audits of coverage, fidelity, findability and metrics. | 6 | evidence, eval-suite, design-documents-registry, benchmark, agent-capability |
governance/kit.json | governance | Say who owns and controls the venture and who may decide what: ownership (cap table), founders, boards, investor rights and exits, roles, decision rights, where it publishes and who may publish what (the publication gate), the venture template and its pillars, and escalation to the owner. | 15 | decision-rights, role, pillar, ownership, board, founder-agreement, exit, publication-policy, publish-config |
interface/kit.json | interface | Let a person, with agents, work across at least four layers in one session: agent harnesses (Claude Code, Cursor) and custom interfaces (the operator console), all reaching the system through one route table that a CLI, an MCP server and an HTTP API share (EE-030). | 1 | route-aliases |
schema/kit.json | system | Hold the records every layer shares (workspace, venture, nouns, references, tooling, the data model and kit manifests, the provenance log) and the checks that tie the layers together. | 0 | workspace, venture, ontology, reference, integration, business-models, scaffold, data-model, kit-manifest, need-now, provenance |
purpose/kits/validation/kit.json | purpose | Say how probable it is that the venture is validated, from cited evidence: one record type per validation sub-score, a shared evidence item graded like GRADE, templates for gathering the evidence, and the references behind each default (EE-026). Starts with the problem sub-score; solution, product-market fit, pricing, go-to-market, team and operations readiness follow the same pattern. | 2 | validation-problem, validation-solution, validation-product-market-fit, validation-pricing, validation-go-to-market, validation-team, validation-operations-readiness, validation-weights |
Last updated on