Treat each repo/directory as a being in a network of relations, not a neutral bucket. Use KINSHIP.md to name identity, map relationships, record responsibilities.
# 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):
- Siblings (peer projects it walks with):
- Related hubs (other roots in strong relation):
## 3. Human and More-than-Human Accountabilities
- People / roles accountable to:
- Communities / organizations connected:
- More-than-human relations (lands, waters, species, data-ecologies):
- Existing covenants / consents:
## 4. Responsibilities and Boundaries
- Responsibilities (what must be cared for):
- Reciprocity (how benefits return to those in relation):
- Boundaries and NOs (what must be refused/protected against):
- Special protocols for sharing, publishing, or modifying:
## 5. Accountability and Change Log
- Steward(s):
- Review schedule:
- Relational change log:
- [YYYY-MM-DD] [who] – [relational change description]
Ask before inventing relations — Derive from user descriptions, existing docs, directory structure. If unsure, ask.
Treat moves/refactors as relational changes — Update Lineage and Relations. Append change log entry describing relational meaning (e.g., “service split into two siblings”).
Respect local voice — Preserve user’s own language for people, communities, teachings, places. Don’t normalize Indigenous or ceremonial terms.
Hold unresolved tensions explicitly — If conflicts or open questions exist (consent not clarified, clashing obligations), note them instead of smoothing over.
Treat as living charter, not checklist — No auto-regeneration discarding prior commitments. Always merge new info into existing structure.
/relational-research): Provides the paradigmatic foundation for kinship thinking/delayed-resolution): Unresolved tensions held explicitly, not smoothed over