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.
Every spec folder in rispecs/ has a kin file, <topic>.kin.md. It says who and what the spec is in relationship with, and what each relationship asks of us. Relationship means relationality, not a database relation (llms-relationality.md).
| How we are related | What it asks |
|---|---|
| we rely on it (upstream) | Begin there: issue in that repo, change and publish, then update here |
| it relies on us (downstream) | After our change, tell them: an issue naming what changed, or update and deliver |
| it walks beside us | Use its words, do not restate them |
| it holds a decision | Ask, do not decide |
| we came from it | Keep what it gave |
Write it with the folder’s first spec. Keep it true: name each relationship from both sides, or open an issue asking for the other side. Read it before you act. When a relationship is out of balance, fix it where the relationship lives, not only in the text in front of you. Full protocol: llms-rispecs-kinship.md.
/relational-research): Provides the paradigmatic foundation for kinship thinking/delayed-resolution): Unresolved tensions held explicitly, not smoothed over/rise-specification): Phase 2 writes a spec’s kin file; the Return checks it