rhachet-roles-ehmpathy 1.0.0 → 1.2.0

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

@@ -0,0 +1,34 @@
+# 🧩 .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/logic/roles/bhrain/.briefs/knowledge/kno351.docs.recursion.[catalog].md

@@ -0,0 +1,44 @@
+# 🧩 .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/logic/roles/bhrain/.briefs/knowledge/kno401.actors.1.role.author.[article].md

@@ -0,0 +1,36 @@
+# 🧩 .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/logic/roles/bhrain/.briefs/knowledge/kno401.actors.1.role.librarian.[article].md

@@ -0,0 +1,40 @@
+# 🧩 .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/logic/roles/bhrain/.briefs/knowledge/kno401.actors.2.interdependence.[article].md

@@ -0,0 +1,52 @@
+# 🧩 .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/logic/roles/bhrain/.briefs/knowledge/kno501.doc.enbrief.catalog.structure1.[article].md

@@ -0,0 +1,53 @@
+# 🧩 .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/logic/roles/bhrain/.briefs/knowledge/kno501.doc.enbrief.catalog.structure1.[lesson].template.md

@@ -0,0 +1,101 @@
+# 🧩 .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.

package/dist/logic/roles/bhrain/.briefs/librarian.context/article.variant.vision.[article].md

@@ -0,0 +1,60 @@
+# 🧩 .brief: `[vision]`
+
+## .what
+a **vision** is an imaginative depiction or scenario illustrating a potential future state of a concept, entity, or project. it serves as a creative projection aimed at inspiring and guiding transformative thinking or strategic planning by showcasing what is possible.
+
+---
+
+## 🎯 purpose
+- to **inspire innovation** and broad thinking about potential futures
+- to **guide strategic decision-making** by providing a target state to work towards
+- to **engage stakeholders** by vividly portraying the benefits and impact of pursuing the vision
+
+---
+
+## 🛠 components
+
+### 1. **imagination**
+   - creatively constructed possibilities that envision a future state
+   - may involve speculative scenarios or conceptual explorations
+
+### 2. **impact**
+   - describes the anticipated results or changes if the vision is realized
+   - typically highlights positive transformations or advancements
+
+### 3. **feasibility**
+   - considers the practicality and potential challenges in achieving the vision
+   - often includes contingency thoughts to address uncertainties
+
+### 4. **engagement**
+   - a compelling narrative that captures the interest of diverse audiences
+   - calls for alignment and participation from stakeholders
+
+---
+
+## 🔍 features
+- **vivid and illustrative** to make abstract ideas tangible
+- **aspirational tone** to elevate thinking beyond current limitations
+- includes **elements of storytelling** to foster emotional connection
+
+---
+
+## 🏗 creating a vision
+1. **research trends and scenarios**: understand ongoing changes and potential future shifts.
+2. **brainstorm creatively**: think imaginatively about what is possible without current constraints.
+3. **storyboard your vision**: craft a narrative that conveys the exciting, transformative potential.
+4. **seek feedback and iteratively refine**: engage others in reviewing and enhancing the vision for broader resonance.
+
+---
+
+## 📚 examples
+- vision of a sustainable future city: "the city of tomorrow is a zero-emission urban paradise where nature and technology coexist, providing a thriving, inclusive, and adaptive ecosystem for all."
+- vision for an education system: "an educational landscape where personalized learning and novel pedagogies empower every student to realize their full potential, unbounded by their starting point."
+
+---
+
+## 💡 notes
+- a vision can be abstract and speculative, unlike a mission or strategy, which are typically more grounded and specific.
+- ensure a vision remains **flexible** to evolve with new insights and realities.
+
+---

package/dist/logic/roles/bhrain/.briefs/librarian.context/term.expectation.vs_assumption._.md

@@ -0,0 +1,60 @@
+# 🧩 .brief: `assumption vs expectation`
+
+## .what
+**assumption** and **expectation** are two closely related concepts that shape how we perceive and interact with the world. An **assumption** is a belief or supposition taken as true without proof or concrete evidence. It often functions unconsciously to fill gaps in what we think we know. An **expectation**, on the other hand, is a belief about the anticipated outcome or behavior of someone or something; it is often based on past experience, communication, or desire.
+
+---
+
+## 🎯 purpose
+- distinguish between passive beliefs (assumptions) and active forecasts (expectations)
+- clarify how each informs decision-making and mindset
+- prevent misunderstandings and misalignments in communication and planning
+
+---
+
+## 📐 dimensions
+
+### assumption
+- **definition**: a belief taken for granted without substantiation; a starting point for reasoning that lacks direct evidence.
+- **origin**: emerges from prior experiences, cultural norms, or incomplete data.
+- **effect**: shapes perspective subtly, often unacknowledged; can lead to blind spots if unexamined.
+  
+### expectation
+- **definition**: an anticipated outcome or behavior considered likely or desired, inferred from patterns of past interactions or guidance.
+- **origin**: formed from past experience, explicit statements, or personal goals and desires.
+- **effect**: guides behavior and emotional responses; unmet expectations can result in disappointment or frustration.
+
+---
+
+## 🔗 relations
+- **assumptions can influence expectations**: unacknowledged assumptions can set unrealistic or inaccurate expectations.
+- **expectations shape interactions**: clear expectations improve communication and collaboration, reducing surprises and conflict.
+  
+---
+
+## 💡 examples
+
+### assumptions
+- assuming someone knows how to operate a device without instruction.
+- believing a project will take a standard amount of time without considering unique complexities.
+
+### expectations
+- expecting a colleague to reply to emails within 24 hours based on previous patterns.
+- anticipating software to perform a specific function because it was advertised to do so.
+
+---
+
+## 🌀 contrast & synthesis
+
+### distinguish
+- assumptions are often less conscious and lack immediate validation.
+- expectations are typically more explicit and testable against reality.
+
+### integrate
+- actively recognizing and questioning assumptions can refine expectations into more effective tools for predicting and navigating future scenarios.
+
+---
+
+## 📌 application
+- **in planning**: explicitly state and validate assumptions to ensure realistic expectations and successful outcomes.
+- **in communication**: acknowledge and align on expectations to foster understanding and collaboration.

package/dist/logic/roles/bhrain/.briefs/librarian.context/term.frame.vs_perspective.[article].md

@@ -0,0 +1,96 @@
+# 🧩 .brief: `frame vs perspective`
+
+## .what
+**frame** and **perspective** are paired tools for concept articulation:
+- **frame** = a **structural skeleton** — a variant pattern of slots and relations that can be applied to a concept to shape *how* it is organized in articulation. Multiple frames may be applied to the same concept to produce structurally different materializations.
+- **perspective** = the **viewpoint** or **angle of approach** used to fill that skeleton with content, shaping emphasis, tone, and interpretation.
+
+---
+
+## 🎯 goal
+- **frame**: provide an organizing pattern for a concept’s articulation.
+- **perspective**: give a contextual lens for filling the pattern.
+- together: allow re-framing (structural variation) and re-viewing (interpretive variation) of the same concept.
+
+---
+
+## 🔎 core distinctions
+
+| aspect | **frame** | **perspective** |
+|---|---|---|
+| nature | structural pattern (variant skeleton) | interpretive angle (role, motive, context) |
+| function | determines *what slots exist* and *how they relate* | determines *how slots are filled* and *what’s emphasized* |
+| multiplicity | many possible per concept | many possible per concept |
+| change effect | reorganizes the articulation | shifts tone, focus, interpretation |
+| metaphor | skeleton blueprint | lens |
+
+---
+
+## 🧭 minimal definitions
+
+### frame
+- **slots**: named fields/dimensions (e.g., `.what`, `.why`, `.how`)
+- **relations**: how slots link or depend on each other
+- **order/shape**: sequence, grouping, or hierarchy
+- **constraints**: invariants within that frame variant
+- **acuity rules**: expected detail per slot
+
+### perspective
+- **vantage**: whose view or role is filling the frame
+- **tone/style**: language and metaphor choices
+- **priority**: which slots get richer vs minimal detail
+- **filter**: what’s omitted or downplayed
+- **interpretation**: how the facts are cast in meaning
+
+---
+
+## ⚙️ workflow pattern
+
+1. **<select.frame>** — choose the skeleton variant best suited to the goal.
+2. **<choose.perspective>** — pick the lens: role, priorities, style.
+3. **<materialize>** — fill the frame from that perspective.
+4. **<compare.perspectives>** — same frame, varied fills.
+5. **<compare.frames>** — same concept, varied skeletons.
+
+---
+
+## 🧷 interplay rules
+
+- **frame** = structural variation; **perspective** = interpretive variation.
+- multiple **frames** allow reorganizing the same concept into different slot structures.
+- multiple **perspectives** allow different voices or priorities for the same structure.
+- changing **frame** may change the relationships between elements; changing **perspective** does not.
+
+---
+
+## 🧯 blue-collar example
+
+**concept**: “buying a work truck”
+
+- **frame A** (decision frame):
+  1. purpose
+  2. requirements
+  3. options
+  4. decision
+  5. rationale
+
+- **frame B** (risk–benefit frame):
+  1. risks
+  2. mitigations
+  3. benefits
+  4. trade-offs
+  5. selection
+
+- **perspectives** for either frame:
+  - **owner**: ROI, fuel, maintenance cost.
+  - **foreman**: uptime, ruggedness.
+  - **driver**: comfort, safety.
+
+Same **concept**, different **frames** change *structure*, different **perspectives** change *interpretation*.
+
+---
+
+## 📌 summary
+- **frame** = skeleton variant — structural pattern that organizes articulation.
+- **perspective** = lens — interpretive angle that colors the fill.
+you can re-frame for structural changes, re-view for interpretive changes, or combine both for maximum variation.

package/dist/logic/roles/bhrain/.briefs/librarian.context/term.invariant.[article].md

@@ -0,0 +1,29 @@
+# 🧩 .brief: def(`invariant`)
+
+## .what
+an **invariant** is a property, condition, or quantity that remains unchanged while other elements of a system vary — as long as the system’s rules or constraints are respected.
+
+---
+
+## 🎯 goal
+to define and preserve **consistency** across changes, ensuring that certain truths or conditions hold steady regardless of variation in other factors.
+
+---
+
+## 📍 scope
+- **mathematics** — values or relationships that remain constant under specific transformations
+- **programming** — conditions that must always be true during program execution
+- **physics** — measurable properties that do not change across frames of reference or states
+- **logic / reasoning** — truths that persist across all considered cases
+
+---
+
+## 💡 examples
+- **math**: in euclidean geometry, the distance between two points is invariant under rotation.
+- **programming**: in a sorted array, `array[i] <= array[i+1]` is an invariant.
+- **physics**: the speed of light in a vacuum is invariant for all inertial observers.
+
+---
+
+## 🔍 note
+violating an invariant often signals a **break in the system’s rules** or a **logical error** in reasoning or implementation.

package/dist/logic/roles/bhrain/.briefs/librarian.context/term.lesson._vs_article.[article].md

@@ -0,0 +1,36 @@
+# 🧩 .brief: lesson vs article
+
+## .what
+**lesson** and **article** are both structured forms of knowledge delivery, but they differ in **purpose, orientation, and test of success**.
+- a **lesson** is pedagogical — built to **teach** through the fusion of **explain × articulate**.
+- an **article** is expository — built to **inform or persuade**, relying primarily on **articulation**, sometimes with partial explanation.
+
+---
+
+## .why (purpose)
+- **lesson:** to transfer ability → the learner should *do, apply, or restate*.
+- **article:** to convey information or stance → the reader should *understand, believe, or reflect*.
+
+---
+
+## .model
+
+| axis              | **lesson**                                   | **article**                               |
+|-------------------|-----------------------------------------------|-------------------------------------------|
+| **core fusion**   | explain × articulate                          | articulate (may include explain)           |
+| **orientation**   | audience-centered (learner progression)       | content-centered (author’s theme)         |
+| **structure**     | scoped, stepwise, with checks/examples        | expository/narrative, theme-driven         |
+| **tone**          | directive, guiding, scaffolded                | declarative, expressive, author-driven     |
+| **success test**  | learner can apply or restate concept          | reader grasps or resonates with argument   |
+
+---
+
+## .examples
+- **lesson:** “solving quadratic equations” → rule explained, worked example, practice, recap.
+- **article:** “why quadratic equations matter in physics” → narrative of relevance, context, implications.
+
+---
+
+## .tl;dr
+- **lesson = packaged teaching**: explain + articulate, bounded, learner-focused.
+- **article = expository writing**: articulate, theme-focused, author-driven.