Skip to main content

Folder Ownership Map

Who owns a method — the folder that teaches it or the skill that runs it?

Both, through one contract. A playbook folder owns the know-how for a capability; a skill packages one repeatable method that serves it. The chain is the pattern: business function → capability → unit of work → skill → tool → evidence. The machine SSOT for the skill side is the skill namespace manifest; this page is its playbook-side mirror. When the two disagree, fix the manifest through its generator — never fork the truth here.

The machine SSOT for public top-level folder classification is src/data/playbook-navigation/playbook-taxonomy.v1.json. It classifies subject authority separately from placement band, reader route, and prominence. This page explains ownership; it does not duplicate the registry's complete folder list.

The public-to-operational relationship runs in this order:

Human capability → public doctrine → operational agent skill → unit of work
→ business capability and outcome → evidence and learning return

Public pages explain the capability and may name an operational skill's role. They never depend on private repository paths or copy the skill body.

The Map​

  • /playbook/ai — artificial-intelligence technology: models, architectures, inference, tools, memory, and evals. Skill adjacency: agt.
  • /playbook/agents — accountable actors: skills, collaboration methods, operating models, authority, receipts, and agent systems. Skill domain: agt. Agent methods belong here; underlying model and inference mechanics remain under AI.
  • /playbook/applications — application selection: which software a business assembles, which functions it needs, and which choices become build-or-buy decisions. Skill domains: doc, with eng adjacency when a selection becomes implementation demand. Boundary: /playbook/applications chooses the software and function set; /playbook/software teaches how software is built.
  • /playbook/business — AI-native business as one operating system. Skill domain: bus. The durable model is capability domains, cross-domain flows, and instruments: principles holds timeless business laws, strategy holds direction choices, innovation holds unproven bets, commercial owns demand-to-revenue capabilities, delivery owns promise fulfillment, enablement owns finance/people/legal/IT/risk support, flows names end-to-end value movement, and instruments holds reusable artifacts that execute or verify work. Current customer and operations folders are transitional names until the researched migration rules in Naming Standards are executed.
  • /playbook/hardware — physical technology that complements the software stack: local compute, phones, blockchain nodes, IoT sensors, DePIN devices, edge machines, and device-to-data growth loops. Skill domains: kb for placement and smart-linking, with eng adjacency when a hardware need becomes Stackmates implementation demand. Boundary: Hardware teaches what physical stack should exist and how it passes data or proof; /playbook/software teaches how code is built; /playbook/industries/**/platform teaches the platform pillar inside one industry.
  • /playbook/software — engineering practice and software products. Skill domain: eng.
  • /playbook/systems — feedback loops, thinking methods, process systems. Skill domain: ops; historical wf and 5p method language folds into approved ops-* skill names unless a real protocol family is promoted with proof.
  • /playbook/productivity — workspace tooling and personal throughput. Skill domain: gws.
  • /playbook/performance — metrics, proof, validation, ledger logic. Skill domain: val.
  • /playbook/crypto — chains, tokens, on-chain commerce. Skill domain: sui.
  • /playbook (root and remaining hubs) — documentation and knowledge-shaping methods themselves. Skill domain: doc.

How To Use It​

  • Organizing a folder tree — start with Naming Standards to classify the thing, name the placement axis, and choose the migration proof. This page mirrors ownership after the taxonomy is known.
  • Naming a new skill — find the owning folder first, then apply the slug rules in Naming Standards. The folder names the capability; the skill names the method.
  • Placing new know-how — when a method repeats inside a territory, it earns a skill, and the skill's manifest row points back at the owning folder.
  • Classifying a top-level subject — update the taxonomy registry and regenerate its projections; every public folder must appear exactly once and private underscore folders must appear zero times.
  • Adding smart links — use kb-smart-links when a page needs relationship-bearing Context links. Use code-fix-links only for mechanical validity.
  • Evolving situational wisdom — when a folder move makes a decision easier, capture the rule here or in Naming Standards so the next agent inherits the judgment, not just the path.
  • Reading a gap — folders without a skill domain yet (community, games, navigation, agency) own capability know-how whose methods are not packaged. Mixed-domain folders such as applications may name a primary doc ownership plus an adjacency instead of forcing a false single owner. The gap is a signal, not an error.

Checks​

  • Verify the manifest and this page name the same folders and domains; a mismatch is a manifest fix, made through its generator.
  • Verify every new skill row carries an owning folder before the skill ships.

Failure Modes​

  • Forked truth — editing this page to "correct" an ownership row instead of fixing the manifest. The mirror must never lead the source.
  • Facet packing — encoding placement band, reader route, lifecycle, or prominence in a subject folder name instead of the registry and page metadata.
  • Slug packing — forcing lifecycle, provider, or audience into a skill name when the manifest row already carries those dimensions.
  • Orphan skills — a skill with no owning folder serves no named capability and resists discovery and review.

Context​

  • Wiki Control Plane — the epistemic core this map belongs to
  • Naming Standards — the System of Names authority for folder structure, capability naming, skill slugs, and migration-proof references
  • Skills — what a skill is and how it packages judgment
  • Wiki Schema — the routing rules that decide where know-how lands

Questions​

If a competitor copied your folder tree but not your skills, what would they actually have?

  • Which folder owns the method you repeated most this month — and is it packaged yet?
  • When a skill and a folder disagree about ownership, where is the tie broken, and who fixes the source?