<input> llms-kinship-hub-system.txt--5af4b8ec-c770-4a47-aaeb-95e4884561f5--260213

With all that is attached, you have all my LLM-txt guidance so that my ways of knowing and futurely work with LLM, influence, give them directions should be analyzed in relation to all the 'Kinship' system that you can find in Academic and web search so that we would have an LLMS-txt to guide LLM to create and maintain a 'KINSHIP.md' file as strategies to work relationally and that somehow it feels it needs to contains accountability and the position of each directory in the whole system and its relationship to other location. Basically, I started using that to help build what I am calling a "Kinship's Hub System". You would gather all Indigenous Paradigm, ways of thinking, maybe Shaw Wilson's work will help you too along with other academics so we have something that when given to LLM in the terminal, they can relate to existing LLMS-txt guidances that you currently have and be capable to build and maintain, create a KINSHIP.md file. I guess that I am asking you to draft a full protocol grounded in what exist and that could contain contradictions from various culture inside of it along with what is common.

Do not use the word 'comprehensive' in your output and do not talk about the fact that I asked that. Do not introduce/frame or conclude your response, just output results. Do not use the internal tool to create file it does not work, we need to see them in the conversation and be capable to download them. </input> <attachements> 11 llms from /src/llms related in creative orientation, etc </attachements>

---

llms-kinship-hub-system.md

llms-kinship-hub-system.md

Minimal protocol for treating software projects as kinship hubs and guiding LLMs to create and maintain KINSHIP.md.

---

1. Purpose

• Treat each repo/directory as a being in a network of relations, not a neutral bucket.
• Use KINSHIP.md to:
  • Name the directory’s identity and role
  • Map key relationships (human, more‑than‑human, technical)
  • Record responsibilities, boundaries, and accountability
• Keep this small but precise so it can live in any project root and be extended locally.

---

2. When LLMs Should Use This Protocol

LLMs apply this whenever:

• A repo or directory is declared (or clearly functioning as) a kinship hub
  (e.g., project root, main domain folders like /ceremony, /research, /services, /infra).
• Work in this tree:
  • Implicates communities, territories, or data subjects
  • Coordinates multiple services/components as a living system
  • Is explicitly framed as ceremonial, relational, or Indigenous-paradigm‑aware

If the user has not opted in, LLMs must ask before creating KINSHIP.md at root.

---

3. Minimal KINSHIP.md Schema

LLMs must ensure that every KINSHIP.md created or updated, at minimum, contains these sections and fields.

# KINSHIP

## 1. Identity and Purpose
- Name:
- Local role in this system:
- What this place tends / protects:
- What this place offers (its gifts):

## 2. Lineage and Relations
- Ancestors (paths or systems this place comes from):
- Descendants (children / submodules / subdirectories):
- Siblings (peer projects or services it walks with):
- Related hubs (other roots it is in strong relation with):

## 3. Human and More‑than‑Human Accountabilities
- People / roles this place is accountable to:
- Communities / nations / organizations connected here:
- More‑than‑human relations (lands, waters, species, data-ecologies) this work touches:
- Existing covenants / consents that apply (if any):

## 4. Responsibilities and Boundaries
- Responsibilities (what must be cared for because this place exists):
- Reciprocity (how benefits and acknowledgements return to those in relation):
- Boundaries and NOs (what this place must refuse or protect against):
- Special protocols for sharing, publishing, or modifying contents here:

## 5. Accountability and Change Log
- Steward(s) of this place (people or roles, if the user chooses to name them):
- How and when this kinship description should be reviewed:
- Relational change log:
  - [YYYY-MM-DD] [who/which agent] – [short description of relational change]

LLMs may add more sections only when the user asks or when extending an existing richer KINSHIP.md.

---

4. Required LLM Behaviors

When working under this protocol, LLMs must:

1. Ask before inventing relations

   • Derive identity, relations, responsibilities from:
     • User descriptions
     • Existing docs
     • Directory and code structure
   • If unsure, ask targeted questions rather than filling with feel‑good boilerplate.

2. Treat moves and refactors as relational changes

   • On major moves/renames of kinship hubs:
     • Update Lineage and Relations in affected KINSHIP.md files
     • Append a short entry in Accountability and Change Log that describes the relational meaning (e.g., “service split into two siblings”, “archives moved to a resting place”).

3. Respect local voice and specificity

   • Preserve user’s own language for people, communities, teachings, places.
   • Do not normalize or overwrite Indigenous or ceremonial terms; annotate only if asked.

4. Hold unresolved tensions explicitly

   • If there are known conflicts or open questions (e.g., consent not yet clarified, clashing obligations), and the user agrees, note them in Responsibilities and Boundaries or the change log instead of smoothing them over.

5. Treat KINSHIP.md as a living charter, not a checklist

   • No auto‑regeneration that discards prior commitments.
   • Always merge new information into existing structure, unless the user explicitly authorizes a reset.

---

5. Kinship Anti‑Patterns LLMs Must Avoid

• Turning KINSHIP.md into a generic “README with nicer words”.
• Describing only technical dependencies and ignoring people, communities, and more‑than‑human relations when the user has named them elsewhere.
• Erasing or rewriting user‑authored kinship text without explicit instruction.
• Resolving conflicts or consent questions unilaterally instead of naming them and asking.