rhachet-roles-ehmpathy 1.15.13 → 1.15.15

package/dist/roles/bhrain/briefs/knowledge/kno301.doc.enbrief.2.demonstrate.[lesson].md

@@ -1,49 +0,0 @@
-# 🧩 .brief.lesson: `how to demonstrate a demo`
-
-## .what
-a **demo** is a document that gives a **relational treatment** of a concept: it shows *how an instance exemplifies a concept*.
-this lesson explains how to **demonstrate a demo** — i.e., how to instantiate a demo so the connection between instance and concept is maximally clear.
-
----
-
-## 🎓 steps
-
-1. **select the concept**
-   - identify the abstraction you want to materialize (e.g., “resilience”).
-
-2. **choose a focal instance**
-   - pick a concrete, vivid case (e.g., a tree bending in strong wind).
-   - ensure it is representative enough to reveal the concept.
-
-3. **frame the relation**
-   - state directly how the instance demonstrates the concept.
-   - highlight the relational link (instance → concept).
-
-4. **situate in context**
-   - explain why this instance is a strong example.
-   - connect to broader relevance (domain, application, meaning).
-
-5. **compress articulation**
-   - keep it concise: usually 2–3 paragraphs.
-   - remove noise, emphasize clarity of the instance–concept link.
-
----
-
-## 📌 example: demonstrating a demo of “resilience”
-
-- **concept:** resilience
-- **instance:** a tree bending in strong wind
-- **relation:** the bending tree demonstrates resilience by showing flexibility under force without breaking.
-- **context:** this everyday natural instance captures the broader human/social concept of adapting to stress.
-- **compression:** two short paragraphs clearly tying instance → concept.
-
----
-
-## ✨ insight
-to demonstrate a demo:
-- pick a **clear instance**
-- articulate its **relation to the concept**
-- situate it in **context**
-- keep the link **compressed and clear**
-
-a demo succeeds when the audience can see the **abstract concept made visible** through a single, well-chosen instance.

package/dist/roles/bhrain/briefs/knowledge/kno301.doc.enbrief.2.lessonize.[article].md

@@ -1,26 +0,0 @@
-# 🧩 .brief.article: `lessonize`
-
-## .what
-**lessonize** is the mechanism that **instantiates lessons**: it materializes a concept as a structured pedagogical treatment that guides learning.
-
----
-
-## 🔬 definition
-- **mechanism:** the materialization of a concept into lesson form.
-- **function:** provides a scaffolded sequence of steps, examples, and practices so the learner can internalize the concept.
-- **distinction:** articulation describes *what a lesson is*; lessonizing performs the *instantiation* of a lesson.
-
----
-
-## 📌 examples
-- to lessonize “gravity,” one designs a sequence moving from dropping an apple → comparing planetary orbits → explaining Newton’s law → practicing with tidal predictions.
-- to lessonize “empathy,” one builds a progression from observing a friend’s feelings → practicing perspective-taking → responding → reflecting on the effect.
-
----
-
-## ✨ insight
-**lessonize** is the bridge between concept and pedagogy:
-- it is the **mechanism** of turning raw content into structured learning.
-- it ensures that lessons are not improvised but **instantiated systematically**.
-
-in knowledge architecture, lessonize sits alongside other mechanisms (e.g., *articulate, catalogize, demonstrate*) as a specific process for **pedagogical materialization**.

package/dist/roles/bhrain/briefs/knowledge/kno301.doc.enbrief.2.lessonize.[lesson].md

@@ -1,54 +0,0 @@
-# 🧩 .brief.lesson: `how to lessonize a lesson`
-
-## .what
-a **lesson** is a document that gives a **pedagogical treatment** of a concept: it guides *how the concept is learned and practiced* through structured progression.
-this lesson explains how to **lessonize a lesson** — i.e., how to instantiate a lesson so it effectively scaffolds understanding.
-
----
-
-## 🎓 steps
-
-1. **define the learning goal**
-   - specify what the learner should understand or be able to do at the end.
-   - e.g., “learn how photosynthesis works.”
-
-2. **choose core instances**
-   - gather examples or cases that ground the concept.
-   - ensure variety: simple → complex, familiar → abstract.
-
-3. **sequence the progression**
-   - order steps to move from known → new, concrete → abstract.
-   - each step should build on the previous one.
-
-4. **embed practice and reflection**
-   - include questions, exercises, or thought experiments.
-   - encourage learners to test and reinforce understanding.
-
-5. **compress into a clear arc**
-   - keep the lesson a few paragraphs or steps, not sprawling.
-   - highlight transitions between steps so the flow is obvious.
-
----
-
-## 📌 example: lessonizing a lesson on “photosynthesis”
-
-- **goal:** understand how plants convert sunlight into energy.
-- **instances:** observing a leaf, recalling oxygen release, examining energy diagrams.
-- **sequence:**
-  1. start with observation of leaves and sunlight.
-  2. explain chlorophyll capturing light.
-  3. show the chemical reaction (CO₂ + H₂O → glucose + O₂).
-  4. connect to everyday significance (oxygen supply, food chain).
-- **practice:** sketch the process or explain it in simple terms to a peer.
-
----
-
-## ✨ insight
-to lessonize a lesson:
-- set a **clear goal**
-- select **grounding instances**
-- create a **progression** that builds understanding
-- add **practice and reflection**
-- keep the arc **compressed but complete**
-
-a lesson succeeds when it transforms **instances into a structured pathway**, enabling the learner to grasp and retain the concept.

package/dist/roles/bhrain/briefs/knowledge/kno301.doc.kernelize._.[article].md

@@ -1,58 +0,0 @@
-# 🧩 .brief.article: `<kernelize>`
-
-## .what
-**<kernelize>** is the mechanism that extracts 🌱 **doc.kernels** from any 📚 **doc**.
-it reduces unstructured or expansive material into **atomic expressions**, each carrying **one concept**.
-where a 📚 doc may hold many tangled ideas, <kernelize> isolates them into minimal, portable seeds.
-
----
-
-## 🎯 purpose
-- **distill**: strip away noise, phrasing, and redundancy
-- **separate**: untangle multiple ideas into discrete units
-- **stabilize**: preserve the integrity of each concept in its minimal viable form
-- **prepare**: create fertile, portable kernels for use in 🔖 refs, 🪴 briefs, or new 📚 docs
-
----
-
-## ⚙️ properties
-- **one concept only** — every kernel carries exactly one concept
-- **atomic** — irreducible without breaking the idea
-- **fertile** — can grow into larger articulations (briefs, essays, treatises)
-- **portable** — reusable across different contexts and documents
-
----
-
-## 📌 examples
-
-### ⚖️ gravity
-source doc: *“the reason the apple falls is because earth pulls on it with a force — and in fact, any two masses in the universe attract each other.”*
-kernels extracted:
-- 🌱 `earth pulls on the apple`
-- 🌱 `any two masses attract each other`
-
----
-
-### 🎵 music
-source doc: *“music happens when sounds are arranged in rhythm and melody, and harmony is what gives it depth.”*
-kernels extracted:
-- 🌱 `organized sound creates aesthetic experience`
-- 🌱 `rhythm and melody distinguish music from noise`
-- 🌱 `harmony creates depth in music`
-
----
-
-### 🧩 triangle
-source doc: *“a triangle is a polygon with three sides, three angles, and the sum of its angles is 180°.”*
-kernels extracted:
-- 🌱 `a triangle has three sides`
-- 🌱 `a triangle has three angles`
-- 🌱 `the sum of a triangle’s angles is 180°`
-
----
-
-## ✨ insight
-- 📚 docs contain many concepts, often entangled.
-- **<kernelize>** untangles and harvests them into 🌱 kernels.
-- kernels are the **minimal carriers of meaning** — richer than 🔖 refs, smaller than 🪴 briefs.
-- they are the foundation of concept portability, indexing, and recomposition across the document ecosystem.

package/dist/roles/bhrain/briefs/knowledge/kno301.doc.kernelize._.[lesson].md

@@ -1,88 +0,0 @@
-# 🧩 .brief.lesson: `how to <kernelize>`
-
-## 💡 concept
-**<kernelize>** is the practice of extracting 🌱 **doc.kernels** — the atomic, fertile units of concepts — from any 📚 **doc**.
-most docs contain **many concepts**, often mixed together.
-the goal of <kernelize> is to harvest **each concept individually** in its minimal viable form.
-
----
-
-## 🎯 learning goals
-- recognize that a single doc typically contains **multiple concepts**
-- practice isolating and extracting **one kernel per concept**
-- compare kernels to 🔖 refs (pointers) and 🪴 briefs (structured articulations)
-
----
-
-## 🛠️ method
-
-### step 1: scan for concepts
-- read through the 📚 doc (transcript, notes, essay, article).
-- underline every sentence or clause that carries a **distinct idea**.
-
----
-
-### step 2: isolate each idea
-- separate intertwined sentences into discrete conceptual units.
-- treat each idea as a candidate for its own kernel.
-
----
-
-### step 3: reduce to the irreducible
-- rewrite each idea in its **shortest viable form**.
-- test: *if I cut further, does the concept break?*
-- keep only **one concept per kernel**.
-
----
-
-### step 4: declare as kernels
-- format each idea as a 🌱 **doc.kernel**.
-- a single doc may yield a **set of kernels** — one per concept.
-
----
-
-## 📌 practice examples
-
-### ⚖️ gravity (from a lecture transcript)
-> *“so, basically, the reason the apple falls is because earth pulls on it with a force — and actually, any two masses in the universe attract each other, that’s Newton’s big insight.”*
-
-kernels extracted:
-- 🌱 `earth pulls on the apple`
-- 🌱 `any two masses attract each other`
-- 🌱 `Newton identified universal gravitation as a key insight`
-
----
-
-### 🎵 music (from a conversation)
-> *“when you line up sounds in rhythm and melody, suddenly it feels like music instead of just noise. and harmony is what makes it feel rich.”*
-
-kernels extracted:
-- 🌱 `organized sound creates aesthetic experience`
-- 🌱 `rhythm and melody distinguish music from noise`
-- 🌱 `harmony creates richness in music`
-
----
-
-### 🧩 triangle (from a textbook)
-> *“a triangle is defined as a polygon with three sides, three angles, and the sum of its angles equal to 180°.”*
-
-kernels extracted:
-- 🌱 `a triangle has three sides`
-- 🌱 `a triangle has three angles`
-- 🌱 `the sum of a triangle’s angles is 180°`
-
----
-
-## ✨ reflection
-- 📚 docs = soils full of **many concepts** (entangled, verbose, raw).
-- 🔖 refs = labels into concepts (*“gravity”*, *“music”*).
-- 🌱 kernels = harvested seeds, **one per concept**.
-- 🪴 briefs = portable pots, where kernels are transplanted and structured.
-
----
-
-## 🧠 takeaway
-to **<kernelize>** is to **harvest all the concepts from a doc**:
-- extract **each concept separately**
-- reduce it to its **minimal viable form**
-- treat kernels as **fertile seeds** for cataloging, briefing, or hosting in new docs.

package/dist/roles/bhrain/briefs/knowledge/kno351.docs.are_instances.[article].md

@@ -1,34 +0,0 @@
-# 🧩 .brief.article: `documents as instances`
-
-## .what
-all **documents** are themselves **instances of their document type** (article, catalog, demo, lesson).
-because documents are created from instances, they in turn can serve as **instances for new documents**, enabling recursive knowledge-building.
-
----
-
-## 🔬 definition
-- **duality:** a document is both
-  - a **materialization of a concept** (built from instances of reality), and
-  - an **instance itself** (of the document type, usable as input).
-- **mechanism:** documents can reference, incorporate, or organize other documents as if they were instances.
-- **implication:** knowledge systems are cumulative and self-referential, layering documents upon documents.
-
----
-
-## 📌 examples
-- 📖 an *article* on gravity → becomes an instance in a 🗂️ catalog of scientific papers.
-- 🎬 a *demo* of empathy in a nurse–patient interaction → becomes an instance in a 📖 article defining empathy.
-- 🗂️ a *catalog* of philosophical texts → becomes an instance in a 🎓 lesson on the history of philosophy.
-- 🎓 a *lesson* on climate change → becomes an instance in a 🗂️ catalog of teaching curricula.
-
----
-
-## ✨ insight
-- all documents are **instances of type**.
-- documents can serve as **input instances** for new documents.
-- this recursive structure explains how **knowledge accumulates and evolves**:
-  - concepts are materialized as documents,
-  - documents become instances,
-  - new documents materialize from those instances.
-
-in knowledge architecture, this principle underpins the **layered ecology of documents**, where works are both **outputs** and **inputs** in the ongoing materialization of concepts.

package/dist/roles/bhrain/briefs/knowledge/kno351.docs.recursion.[catalog].md

@@ -1,44 +0,0 @@
-# 🧩 .brief.catalog: `recursion in documents`
-
-## .what
-because all documents are **instances of type**, they can serve as **input instances** for new documents.
-this recursive property explains how knowledge systems accumulate: documents continually materialize concepts while drawing on prior documents as their raw material.
-
----
-
-## 📖 articles using documents
-- **citing:** reference prior articles as evidence or context.
-- **synthesizing:** weave multiple documents into a new definitional treatment.
-- **example:** a meta-article on “democracy” cites historical articles, demos, and lessons to define its evolution.
-
----
-
-## 🗂️ catalogs using documents
-- **aggregating:** group documents of the same type into taxonomies or lists.
-- **indexing:** organize articles, demos, or lessons by topic, date, or author.
-- **example:** a catalog of teaching curricula (lessons) across universities.
-
----
-
-## 🎬 demos using documents
-- **showcasing:** use an article, lesson, or catalog as the instance that exemplifies a concept.
-- **contextualizing:** demonstrate how a specific document embodies or reveals a broader principle.
-- **example:** a demo showing how Newton’s *Principia* itself demonstrates the process of scientific articulation.
-
----
-
-## 🎓 lessons using documents
-- **sequencing:** structure lessons around prior articles, demos, or catalogs.
-- **teaching through documents:** use preserved works as practice material.
-- **example:** a philosophy curriculum built from Plato’s dialogues (demos), Aristotle’s categories (catalog), and modern articles.
-
----
-
-## ✨ insight
-- 📖 **articles cite** other documents to refine definitions.
-- 🗂️ **catalogs aggregate** documents into organized systems.
-- 🎬 **demos showcase** documents as exemplars.
-- 🎓 **lessons sequence** documents into pathways of learning.
-
-recursion in documents ensures that knowledge is **layered, cumulative, and evolving**:
-documents are never isolated — they both **draw from** and **become** instances for new documents in the ongoing materialization of concepts.

package/dist/roles/bhrain/briefs/knowledge/kno401.actors.1.role.author.[article].md

@@ -1,36 +0,0 @@
-# 🧩 .brief.article: `author`
-
-## .what
-an **author** is the actor that **creates documents**: they materialize concepts by selecting and arranging instances into communicable forms such as articles, catalogs, demos, or lessons.
-
----
-
-## 📑 scope of operation
-- authors do **not** operate on collections; they originate documents.
-- their role is to **materialize concepts into documents**, shaping raw instances into definitional, organizational, relational, or pedagogical treatments.
-- where librarians weave documents into collections, authors weave instances into documents.
-
----
-
-## 🔬 functions of an author
-1. **concept selection** → choosing which concept to materialize.
-2. **instance gathering** → collecting examples, cases, or data.
-3. **treatment choice** → deciding whether to articulate, catalogize, demonstrate, or lessonize.
-4. **composition** → structuring the document into coherent, transmissible form.
-5. **expression** → shaping language, style, and framing to suit audience and purpose.
-
----
-
-## 📌 examples
-
-- **science:** an author creates a 📖 *document.article* defining “gravity,” a 🗂️ catalog of physical constants, a 🎬 demo of falling apples, or a 🎓 lesson on Newton’s laws.
-- **philosophy:** an author creates a 📖 article (Plato on justice), a 🗂️ catalog (Aristotelian categories), a 🎬 demo (Socratic dialogue), or a 🎓 lesson (ethics curriculum).
-
----
-
-## ✨ insight
-- **authors** materialize concepts into *documents*.
-- **librarians** materialize documents into *collections*.
-- **readers** (to be articulated) materialize collections into *understanding*.
-
-in knowledge architecture, the **author** is the entry point: without authors producing documents, there is nothing for librarians to curate or readers to interpret.

package/dist/roles/bhrain/briefs/knowledge/kno401.actors.1.role.librarian.[article].md

@@ -1,40 +0,0 @@
-# 🧩 .brief.article: `librarian`
-
-## .what
-a **librarian** is the actor that **curates knowledge collections**: rather than authoring new documents, the librarian operates on existing ones, arranging them into coherent systems that make knowledge accessible and durable.
-
----
-
-## 📑 scope of operation
-- librarians do **not** usually instantiate documents themselves.
-- instead, they **operate on documents**: selecting, classifying, preserving, and connecting them within a knowledge system.
-- where authors **materialize concepts into documents**, librarians **materialize documents into collections**.
-
----
-
-## 🔬 functions of a librarian
-1. **selection** → deciding which documents belong in a collection.
-2. **classification** → arranging documents into catalogs, indexes, and metadata systems.
-3. **navigation** → providing guides, references, and pathways for discovery.
-4. **preservation** → maintaining continuity of documents across time and formats.
-5. **contextualization** → situating documents in relation to one another, weaving knowledge networks.
-
----
-
-## 📌 examples
-
-- **climate change:**
-  authors produce an 📖 article (definition), a 🗂️ catalog (models), a 🎬 demo (regional case), and a 🎓 lesson (curriculum).
-  the librarian curates them into a collection, classifies by type/domain, adds cross-references, and ensures long-term preservation.
-
-- **philosophy:**
-  authors produce an 📖 article (Metaphysics), a 🗂️ catalog (scholastic indexes), a 🎬 demo (Socratic dialogue), and a 🎓 lesson (curriculum).
-  the librarian curates them into traditions, preserves across formats, and builds navigation systems (indexes, headings).
-
----
-
-## ✨ insight
-- **authors** materialize concepts into *documents*.
-- **librarians** materialize documents into *collections*.
-- mechanisms like **articulate, catalogize, demonstrate, lessonize** operate **within documents**.
-- the **librarian** operates **between documents**, turning scattered works into a coherent knowledge ecology.

package/dist/roles/bhrain/briefs/knowledge/kno401.actors.2.interdependence.[article].md

@@ -1,52 +0,0 @@
-# 🧩 .brief.catalog: `author ↔ librarian`
-
-## .what
-**authors** and **librarians** are interdependent mechanisms in the knowledge ecology.
-- 📖 **authors** materialize **documents from instances** (observations + documents).
-- 🗂️ **librarians** collect and curate **instances** (observations and documents) into accessible, preserved systems.
-this interdependence forms a loop: authors rely on librarians to supply instances, and librarians rely on authors to generate new documents to collect.
-
----
-
-## 🔬 functions compared
-
-### 📖 author
-- **concept selection** → chooses which idea to materialize.
-- **instance gathering** → draws from reality *and* from preserved collections.
-- **treatment choice** → decides between article, catalog, demo, or lesson.
-- **composition** → structures instances into a coherent document.
-- **expression** → shapes language and style for audience.
-
-### 🗂️ librarian
-- **selection** → curates both observations (specimens, datasets) and documents.
-- **classification** → organizes them into catalogs, indexes, and metadata.
-- **navigation** → provides pathways for authors and readers to find instances.
-- **preservation** → maintains continuity of both raw data and documents.
-- **contextualization** → links instances so they can be meaningfully reused.
-
----
-
-## 📌 examples
-
-- **science:**
-  - librarian preserves **specimens** (observation-instances) and **journals** (document-instances).
-  - author consults both to write an article on a new species.
-  - librarian then collects the new article into the archive, completing the loop.
-
-- **philosophy:**
-  - librarian preserves **ancient manuscripts** (document-instances) and **oral traditions/notes** (observation-instances).
-  - author draws on them to articulate a new article or construct a lesson.
-  - librarian curates the new works into the philosophical canon.
-
----
-
-## ✨ insight
-- **authors** depend on librarians for access to *instances of reality* (observations preserved) and *instances of knowledge* (documents preserved).
-- **librarians** depend on authors to expand the corpus of documents worth curating.
-- together, they sustain a **two-way loop**:
-  1. librarians collect → preserve instances.
-  2. authors use instances → create documents.
-  3. librarians curate documents → collections.
-  4. authors return to collections → draw instances.
-
-this makes authors and librarians **mutually constitutive**: without librarians, authors lack access to accumulated instances; without authors, librarians lack new material to curate.

package/dist/roles/bhrain/briefs/knowledge/kno501.doc.enbrief.catalog.structure1.[article].md

@@ -1,53 +0,0 @@
-# 🧩 .brief.article: `catalog.structure.s1`
-
-## 💡 what
-**structure.s1** is a **common structure for a catalog**: it organizes a `$concept` into a set of `$subconcept` clusters, balancing a compressed overview with detailed expansions. while other structures are possible, this pattern appears frequently because it provides both scan-ability and depth.
-
----
-
-## 🧱 core structure
-
-### 1. **compressed overview (table)**
-- **purpose:** provide a **scannable map** of the `$concept` space
-- **format:** a table whose **first column is always cluster** (naming each `$subconcept`)
-- **columns:** flexible, but commonly include **what** (definition) plus optional dimensions like *how*, *why*, *when*, or *where*
-- **role:** gives readers a **quick grasp** of the full landscape
-
----
-
-### 2. **clusters (expanded sections)**
-- **purpose:** deepen understanding of each `$subconcept`
-- **format:** a section per cluster, consisting of:
-  1. **emoji-marked header** — each cluster begins with a **distinct emoji**, not a number, to serve as a visual marker that makes clusters easy to grok at a glance
-  2. **short description** — 1–3 sentences that summarize the cluster’s essence
-  3. **nested outline** — flexible bullet/subbullet structure that organizes the cluster’s details
-     - may vary in form: attributes, timelines, taxonomies, workflows, etc.
-- **role:** creates **depth and variation**, allowing each cluster to be expressed in the form that best fits its content
-
----
-
-### 3. **insight (synthesis)**
-- **purpose:** extract patterns across clusters
-- **methods:**
-  - reduce clusters into **verbs** (e.g., “articles define,” “catalogs organize”)
-  - highlight **relationships** (complements, contrasts, overlaps)
-  - summarize the **system-level takeaway** (why the catalog matters as a whole)
-- **role:** turns the catalog into more than a list — a **lens for understanding** the `$concept`
-
----
-
-## ✨ key properties
-- **overview + depth** → balances a **table for scanning** with **clusters for exploration**
-- **emoji headers** → clusters are introduced with **visual emoji markers** instead of numbers, supporting instant recognition and variety without implying sequence
-- **flexible substructure** → clusters are not rigid; each can adopt whatever outline best fits the `$concept`
-- **insight-oriented** → not a static inventory but an interpretive map that clarifies relationships and value
-
----
-
-## 🧩 summary
-**structure.s1** is a **common structure for a catalog**:
-1. a **compressed overview** table to map the terrain,
-2. a set of **emoji-marked clusters** with short descriptions + nested outlines,
-3. an **insight section** that synthesizes meaning.
-
-it is widely useful because it supports both **quick reference** and **conceptual exploration**, making `$concept` domains easier to navigate.

package/dist/roles/bhrain/briefs/knowledge/kno501.doc.enbrief.catalog.structure1.[lesson].template.md

@@ -1,101 +0,0 @@
-# 🧩 .brief.lesson: `catalogize` via `template`
-
-## 💡 concept
-to **catalogize** is to organize a set of `$subconcept`s under a `$concept` by arranging them into a structured overview and expanded clusters, so relationships become clear and referenceable.
-
----
-
-## 📚 materials
-> the template you will use to practice catalogizing
-
-\`\`\`md
-# 🧩 .brief.catalog: `$concept`
-
-## 📊 compressed overview
-
-| **cluster** | **what** | **[optional column]** |
-|-------------|----------|------------------------|
-| 🍎 [$subconcept a] | [short definition or identifying phrase] | [optional info] |
-| 🍌 [$subconcept b] | [short definition or identifying phrase] | [optional info] |
-| 🍇 [$subconcept c] | [short definition or identifying phrase] | [optional info] |
-
----
-
-## 🎨 clusters
-
-### 🍎 **[$subconcept a] — [role/essence]**
-[short description of this cluster]
-- point one
-- point two
-  - subpoint a
-  - subpoint b
-- point three
-
----
-
-### 🍌 **[$subconcept b] — [role/essence]**
-[short description of this cluster]
-- attribute one
-- attribute two
-
----
-
-### 🍇 **[$subconcept c] — [role/essence]**
-[short description of this cluster]
-- step one
-  - detail a
-  - detail b
-    - finer detail i
-    - finer detail ii
-- step two
-
----
-
-## ✨ insight
-- [synthesis across clusters]
-\`\`\`
-
----
-
-## 🛠️ practice
-> how to fill out the template
-
-1. **select a `$concept` domain**
-   - choose the overarching concept you want to organize (e.g., “document archetypes,” “fruit types,” “project risks”).
-   - this sets the *scope* of your catalog — too broad and it becomes messy, too narrow and it loses utility.
-
-2. **define your table columns**
-   - the first column must always be **cluster** (naming each `$subconcept`).
-   - add columns that match what you want to compare:
-     - **what** → short definition (default, highly recommended)
-     - **how** → method, process, or mechanism
-     - **why** → purpose, role, or motivation
-     - **when / where** → context or conditions of relevance
-   - remember: the table is a compressed overview, not a data dump.
-
-3. **draft the compressed overview**
-   - list each `$subconcept` cluster with:
-     - a **name/label** (clear and recognizable)
-     - a **one-liner “what”** definition
-     - optional supporting info in extra columns
-   - aim for *scan-ability*: someone should understand the whole landscape at a glance.
-
-4. **expand each cluster**
-   - mark each cluster header with a **unique emoji**, not a number.
-     - emojis act as **visual tags**, making clusters distinct and instantly recognizable.
-     - choose emojis that symbolize or hint at the `$subconcept`.
-   - begin with a **short description** (1–3 sentences) that anchors what the cluster is about.
-   - follow with a **nested outline** that is **flexible and topic-dependent**.
-     - some clusters may take the shape of attributes, others steps, others categories, or even mixed forms.
-     - outlines should not all look the same; in fact, if every cluster matches the example above exactly, it’s a sign the catalog is being filled mechanically rather than thoughtfully.
-
-5. **distill insights**
-   - once all clusters are drafted, look across them:
-     - **verbs** → reduce each cluster to its action (“articles define,” “catalogs organize”)
-     - **relationships** → highlight how clusters contrast, complement, or overlap
-     - **system takeaway** → explain why the `$concept` matters as a whole, beyond the sum of parts
-
----
-
-## 🎯 goal
-after completing this lesson, you should be able to **catalogize any `$concept` into its `$subconcept` clusters** with a flexible combination of overview tables + emoji-marked descriptive outlines. the *shape of each outline should vary with the topic*, ensuring the catalog balances quick reference with deeper exploration.