rhachet-roles-ehmpathy 1.1.0 → 1.2.0

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.

package/dist/logic/roles/bhrain/.briefs/librarian.context/term.ref._vs_brief.md

@@ -0,0 +1,90 @@
+## `.brief: ref.vs_brief`
+## `.brief: concept.form`
+
+a **concept** may be stored in one of two primary forms, distinguished by the length, completeness, and intended usage of their content:
+
+| form     | role        | description | length scope | typical usage |
+|----------|-------------|-------------|--------------|---------------|
+| **[brief]** | instance  | a complete, self-contained work that may be of arbitrary length. represents the *full file* body, containing all details, structure, and data needed for its intended use. | unlimited | final documents, source code, datasets |
+| **[ref]**   | reference | a short, single-sentence concept reference. names or anchors a concept without providing substantive content. | one sentence | quick reference, index listings, choice menus |
+
+**notes**
+- `[brief]` is the **instance** form; `[ref]` is the **reference** form.
+- concepts can transition between forms — a `[ref]` (reference) can later expand into a `[brief]` (instance), and a `[brief]` can be condensed into a `[ref]`.
+- in storage, `[brief]` consumes more resources and may require versioning; `[ref]` is lightweight and suitable for fast retrieval or indexing contexts.
+
+---
+
+## examples
+
+---
+
+**[ref] example**
+\`\`\`md
+raspberry
+\`\`\`
+
+**[brief] example**
+\`\`\`md
+# `.brief: raspberry`
+
+## .what
+a **raspberry** is a small, edible fruit composed of numerous tiny drupelets, typically red, black, purple, or golden in color. it grows on the perennial plant *rubus idaeus* and related species.
+
+## goal
+to provide nutrition, flavor, and culinary versatility as a fruit in human diets.
+
+## core elements
+1. **botanical family** — rosaceae
+2. **growth habit** — perennial shrub with biennial canes
+3. **nutritional value** — rich in fiber, vitamin c, and antioxidants
+4. **culinary uses** — eaten fresh, made into jams, baked goods, or beverages
+\`\`\`
+
+---
+
+**[ref] example**
+\`\`\`md
+duck
+\`\`\`
+
+**[brief] example**
+\`\`\`md
+# `.brief: duck`
+
+## .what
+a **duck** is a waterfowl belonging to the family anatidae, characterized by its broad bill, webbed feet, and short legs. ducks are found worldwide in both freshwater and marine environments.
+
+## goal
+to thrive as part of aquatic ecosystems and serve as a source of food, feathers, and cultural symbolism for humans.
+
+## core elements
+1. **habitat** — lakes, rivers, marshes, and coastal waters
+2. **diet** — aquatic plants, invertebrates, and small fish
+3. **behavior** — dabbling, diving, migratory patterns
+4. **human uses** — meat, eggs, feathers, ornamental breeding
+\`\`\`
+
+---
+
+**[ref] example**
+\`\`\`md
+ship
+\`\`\`
+
+**[brief] example**
+\`\`\`md
+# `.brief: ship`
+
+## .what
+a **ship** is a large vessel designed for transporting people, cargo, or equipment across bodies of water. ships can be powered by sails, engines, or other propulsion methods.
+
+## goal
+to facilitate transportation, trade, exploration, and defense across oceans, seas, and other navigable waters.
+
+## core elements
+1. **types** — cargo ship, passenger ship, warship, research vessel
+2. **propulsion** — sail, steam, diesel, nuclear
+3. **construction materials** — wood, steel, composite materials
+4. **functions** — commerce, military, scientific research, recreation
+\`\`\`

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

@@ -0,0 +1,43 @@
+# 🧩 .brief: `referent`
+
+## .what
+a **referent** is the actual thing in the world (object, person, event, or idea) that a word, phrase, or symbol points to. it is the entity being referred to, distinct from the sign itself (the word or symbol) and from the concept it evokes in the mind.
+
+---
+
+## 🎯 purpose
+- anchors language to reality by specifying *what exactly* is being indicated
+- distinguishes between linguistic form (signifier), mental concept (sense), and the external entity (referent)
+- enables precision in communication, logic, and semantics
+
+---
+
+## 🔍 contrasts
+- **signifier vs referent**
+  - *signifier* = the form (e.g., the word "dog")
+  - *referent* = the actual creature running in the yard
+- **sense vs referent**
+  - *sense* = the mental concept or descriptive content ("domesticated four-legged canine")
+  - *referent* = the particular dog you’re pointing at
+
+---
+
+## 📐 examples
+1. saying *"the Eiffel Tower"*
+   - **signifier:** the phrase “Eiffel Tower”
+   - **sense:** concept of “a famous tower in Paris”
+   - **referent:** the specific iron structure standing in Paris
+
+2. in a classroom, pointing to a triangle on the board while saying “this shape”
+   - **signifier:** the phrase “this shape”
+   - **referent:** that specific chalk triangle
+
+3. in logic:
+   - the expression “2 + 2” → **referent = 4**
+
+---
+
+## 📊 applications
+- **linguistics & semantics:** clarifies meaning by tying words to things
+- **logic & philosophy:** distinguishes between naming, meaning, and existence
+- **computer science (NLP, programming):** a variable may act as a signifier, its value as the referent

package/dist/logic/roles/bhrain/.briefs/librarian.context/usage.lesson_vs_article.[lesson].md

@@ -0,0 +1,31 @@
+# 🧩 .brief: lessons vs articles in llm context
+
+## .what
+within an llm’s **context window**, the choice between feeding it **lessons** or **articles** determines how it will generalize and respond.
+- **lessons** = structured, causal, example-driven scaffolds → optimized for clarity and reuse.
+- **articles** = expository, narrative, stylistic content → optimized for articulation and tone.
+
+---
+
+## .why (purpose)
+- **lessons:** maximize transfer of reasoning patterns, problem-solving steps, and teaching clarity.
+- **articles:** maximize stylistic fidelity, genre mimicry, and rhetorical richness.
+
+---
+
+## .model
+
+| axis              | **lessons in context**                          | **articles in context**                     |
+|-------------------|-------------------------------------------------|---------------------------------------------|
+| **core fusion**   | explain × articulate (scaffolded knowledge)     | articulate (may include explain)            |
+| **strengths**     | clarity, stepwise structure, reusable templates | tone, breadth, rhetorical and stylistic form |
+| **weaknesses**    | narrow scope, less stylistic variety            | verbose, less causal scaffolding             |
+| **best use**      | teaching, tutoring, applied reasoning tasks     | style transfer, perspective capture          |
+
+---
+
+## .takeaway
+- **lessons compress more usable value per token** → best for clarity, reasoning, and consistency.
+- **articles provide articulation patterns** → best for stylistic or rhetorical goals.
+
+**in llm context:** if the task is *teach or solve*, prefer **lessons**. if the task is *sound like or persuade*, prefer **articles**.

package/dist/logic/roles/bhrain/.briefs/librarian.context/usage.lesson_vs_article_vs_demo.[lesson].md

@@ -0,0 +1,37 @@
+# 🧩 .brief: lessons vs articles vs demos in llm context
+
+## .what
+within an llm’s **context window**, you can load knowledge in the form of **lessons**, **articles**, or **demos**. each has a distinct function:
+- **lessons** = structured scaffolds → optimize for clarity & transfer.
+- **articles** = expository text → optimize for articulation & tone.
+- **demos** = concrete examples → optimize for showing *how it looks in practice*.
+
+---
+
+## .why (purpose)
+- **lessons:** to make the llm *reproduce structured reasoning* and stepwise clarity.
+- **articles:** to make the llm *mirror articulation, genre, and style*.
+- **demos:** to make the llm *imitate patterns through example-based learning*.
+
+---
+
+## .model
+
+| axis              | **lessons in context**                          | **articles in context**                        | **demos in context**                        |
+|-------------------|-------------------------------------------------|------------------------------------------------|---------------------------------------------|
+| **core fusion**   | explain × articulate (scaffolded knowledge)     | articulate (may include explain)               | example (observable instance)                |
+| **strengths**     | clarity, stepwise structure, reusable templates | tone, breadth, rhetorical and stylistic form   | concreteness, fast pattern transfer          |
+| **weaknesses**    | narrow scope, less stylistic variety            | verbose, less causal scaffolding               | shallow (shows *what*, not *why*)           |
+| **best use**      | teaching, tutoring, problem-solving             | style transfer, persuasion, context-rich tasks | training-by-example, template replication   |
+
+---
+
+## .takeaway
+- **lessons** compress rules into structured, reusable scaffolds.
+- **articles** convey style and breadth of articulation.
+- **demos** shortcut learning by showing *what to do*, often with minimal explanation.
+
+**in llm context:**
+- for *clarity & reasoning* → use **lessons**.
+- for *style & rhetoric* → use **articles**.
+- for *pattern mimicry* → use **demos**.

package/dist/logic/roles/bhrain/.briefs/librarian.tactics/.readme.md

@@ -0,0 +1,12 @@
+librarian tactics are all [brief]work
+- [article]s (<articulate>)
+- [catalog]s (<catalogize>)
+- [gallery][example]s (<illustrate>)
+- [gallery][review]s (<?>) (no generator for them? since they're detected / pulled / measured)
+
+the librarian gets and sets [brief]s
+
+the librarian is commonly asked to mutate focus
+- get briefs
+- compress per goal
+- set focus.context

package/dist/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>.TriageCatalog.[gallery][example].structure.md

@@ -0,0 +1,18 @@
+```ts
+import { PonderCatalog } from 'rhachet-roles-bhrain';
+
+export const enquestionPonderCatalog = {
+  contextualize: {
+    P0: [],
+    P1: [],
+    P2: [],
+    P3: [],
+  },
+  conceptualize: {
+    P0: [],
+    P1: [],
+    P2: [],
+    P3: [],
+  },
+} as const satisfies PonderCatalog;
+```

package/dist/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>._.[article].frame.cognitive.md

@@ -0,0 +1,33 @@
+# 🗣️ .brief: `<articulate>`
+
+## 🧭 .what
+`<articulate>` is a **focus.motion.acuity** primitive on the `.attributes` subaxis. it moves **inward** (`.attributes++`) to enrich the **same** anchor concept by surfacing explicit traits. the anchor does not change; only the **resolution** of its description increases.
+
+---
+
+## 🎯 purpose
+- transform a minimal or vague seed into a **clear, operational brief**
+- answer guiding questions to surface **surface-level attributes**
+- unlock **variation potential** by increasing `focal.acuity`
+
+---
+
+## 🔗 relation to `focus.motion.acuity`
+- **subaxis** → `.attributes`
+- **motion** → `++` (enrich)
+- **direction** → inward (sharpen)
+- **effect** → reveals finer surface traits without changing the anchor
+
+---
+
+## 🌿 treestruct interaction
+- **anchor** stays fixed: `focus.concept` is not swapped
+- **acuity** increases: more traits are cognitively present
+- surfaced traits can be used immediately for `<cluster>`, `<compare>`, or `<generalize>`
+
+---
+
+## 📎 notes
+- `<articulate>` is for **attributes** only — use `<decompose>` for internal parts (`.substructs++`).
+- It is often run **after `<gather>`** and **before `<cluster>`**.
+- Higher acuity increases cognitive load; apply when precision directly benefits the reasoning goal.

package/dist/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>._.[article].frame.tactical.md

@@ -0,0 +1,45 @@
+# 🧩 .brief: `articulate`
+
+## .what
+**`articulate`** is a **focus.motion** primitive that transforms an in-progress concept into a **clear, explicit, and shareable form**.
+It takes an internal, often fuzzy understanding and **renders it into precise language or representation**, making it accessible for others — or for one’s own future self.
+
+---
+
+## 🎯 goal
+- convert **implicit understanding** into **explicit expression**
+- ensure the concept is **comprehensible, accurate, and usable**
+- provide a **stable reference** for discussion, reasoning, or implementation
+
+---
+
+## ⚙️ method
+1. **anchor**
+   - establish the core concept or seed you’re articulating
+   - lock in scope and avoid redefining mid-process
+
+2. **structure**
+   - choose an organizational frame (outline, template, narrative, gallery-based, etc.)
+   - match format to purpose and audience
+
+3. **express**
+   - render the concept in clear, direct language
+   - surface key attributes, context, and distinctions
+
+4. **refine**
+   - check for clarity, completeness, and fidelity to the original intent
+   - adjust wording or structure as needed
+
+---
+
+## 📐 when to use
+- when a concept needs to move from **thought** to **communicable form**
+- when collaborating, teaching, or documenting
+- when ambiguity is blocking decision-making or action
+
+---
+
+## 💡 notes
+- articulation is **not invention** — the core concept should already exist, even if only as a seed
+- the **acuity** of articulation depends on how well attributes, context, and boundaries are surfaced
+- can be combined with other tactics (e.g., template-driven, exemplar-driven) for different use cases

package/dist/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>.tactic.[catalog].md

@@ -0,0 +1,83 @@
+# 📚 .catalog: `<articulation>.tactics`
+
+## .what
+A reference set of professional strategies for improving the **clarity, completeness, and resonance** of a concept when composing an [article].
+
+---
+
+## 🛠 tactics
+
+### 1. **checklist-driven articulation**
+> use a predefined list of *must-cover* elements to ensure completeness.
+- best for compliance, standards, and repeatable formats
+- example: medical case reports, technical audits
+
+---
+
+### 2. **progressive refinement**
+> start broad, then iteratively zoom into detail (high → medium → low acuity).
+- prevents getting stuck in minutiae early
+- example: write `.what` at overview level, then deepen `.how` and `.why` in passes
+
+---
+
+### 3. **compare-and-contrast framing**
+> define the concept by placing it alongside similar or opposite concepts.
+- accelerates reader understanding via reference points
+- example: feature comparison charts, pros-vs-cons lists
+
+---
+
+### 4. **story-path anchoring**
+> embed the concept in a narrative arc — problem → struggle → resolution.
+- engages attention, aids memory
+- example: user journey stories, before/after scenarios
+
+---
+
+### 5. **taxonomy positioning**
+> locate the concept within a larger system or hierarchy.
+- clarifies scope, boundaries, and related concepts
+- example: placing a technology in a standards stack diagram
+
+---
+
+### 6. **question-driven expansion**
+> use targeted interrogatives (`what`, `why`, `how`, `when`, `who`, `where`) to systematically fill gaps.
+- works well with `<ponder>` and `<enquestion>`
+- example: investigative reporting, root-cause analysis
+
+---
+
+### 7. **pattern abstraction**
+> generalize from specific instances to reveal the underlying structure or principle.
+- good for reusable methods and cross-domain lessons
+- example: abstracting a “sales funnel” pattern from multiple case studies
+
+---
+
+### 8. **reverse articulation**
+> start from the end result or key takeaway and work backward to the core concept.
+- ensures purpose-driven clarity
+- example: explaining a research conclusion by retracing the evidence path
+
+---
+
+### 9. **visual scaffolding**
+> pair text with diagrams, charts, or schemas that mirror the article structure.
+- improves retention and helps readers navigate complex content
+- example: flowcharts for process explanations, mindmaps for relationships
+
+---
+
+### 10. **multi-perspective synthesis**
+> integrate views from different roles, disciplines, or stakeholders.
+- reveals hidden constraints and broader implications
+- example: combining engineer, designer, and end-user perspectives in a product spec
+
+---
+
+## 🔄 usage
+- select 1–3 tactics per [article] depending on **goal**, **audience**, and **acuity**
+- can be sequenced (e.g., start with **story-path anchoring**, end with **taxonomy positioning**)
+- most effective when paired with **templates-exemplars** to keep structure coherent

package/dist/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>.tactic.concept_dimension.examples.[article][seed].md

@@ -0,0 +1,4 @@
+an # examples section on the [article] helps illustrate meaning via practice
+
+
+examples = concept practice; learn via usage

package/dist/logic/roles/bhrain/.briefs/librarian.tactics/<articulate>.tactic.concept_dimension.invariants.[article].md

@@ -0,0 +1,36 @@
+# 🧩 .brief: `concept.dimensions.generic`
+
+## .what
+**`concept.dimensions.generic`** defines the **invariant semantic dimensions** that can be articulated for *any* [concept] in an [article], regardless of domain.
+these dimensions form a **semantic skeleton** — the minimal, always-present slots for fully describing a concept.
+
+---
+
+## 🎯 goal
+- provide a **universal template** for [article] articulation
+- ensure **concept descriptions** are complete, consistent, and comparable
+- enable automation in concept documentation and reasoning flows
+
+---
+
+## 📐 dimensions
+
+| dimension       | question it answers                | description | why it’s always articulable |
+|-----------------|------------------------------------|-------------|-----------------------------|
+| **.what**       | “what is it?”                      | definition and identity — what makes it this concept and not something else | every concept has an identity to distinguish it from others |
+| **.why**        | “why does it exist?”               | purpose, goal, or motivating function | every concept emerges from some need, cause, or intention |
+| **.how**        | “how does it work?”                | mechanisms, processes, or methods | every concept operates in some way, even abstractly |
+| **.where**      | “where does it apply?”             | domain, scope, or applicable contexts | every concept exists in a context or environment |
+| **.when**       | “when is it relevant?”             | temporal aspect — timing, lifecycle, or stage relevance | every concept has moments when it applies or manifests |
+| **.who**        | “who is involved?”                 | agents, roles, or entities that use, own, or are affected by it | every concept has some relationship to actors |
+| **.attributes** | “what qualities does it have?”     | intrinsic traits, descriptors, or parameters | every concept has distinguishable features |
+| **.relations**  | “what is it connected to?”         | links to other concepts — dependencies, contrasts, hierarchies | no concept exists in total isolation |
+| **.examples**   | “what does it look like in action?” | concrete instances or scenarios that embody it | every concept can be grounded by illustration |
+| **.variants**   | “what forms can it take?”          | versions, subtypes, or adaptations | concepts can be generalized or specialized |
+| **.tradeoffs**  | “what are its strengths & limits?” | pros, cons, constraints, and opportunity costs | every concept has both enabling and limiting factors |
+
+---
+
+## 🛠 usage
+use `concept.dimensions.generic` as the **default frame** when authoring any [article] about a [concept].
+even if some slots are left empty, their presence maintains **structural completeness** and improves cross-concept comparability.