Case studies — overview
Case studies document how a downstream project bound the kit’s deliberately abstract canons to its concrete operating environment. Pentaglyph itself stays domain-neutral and tool-agnostic on purpose; case studies illustrate the concrete bindings real teams made in that deliberate space.
Each case study names:
- The downstream archetype (e.g. digital twin platform, regulated SaaS, internal developer tool) — never the specific project name.
- Which Layer was bound: ① Artefacts / ② Process / ③ Automation / ④ Governance / ⑤ Measurement.
- What the upstream kit deliberately leaves under-specified.
- The concrete bindings the downstream chose (tools, cadence, file layout).
- Lessons learned that may interest future adopters.
Case studies are non-authoritative — they document one team’s choices, not a recommended path. The authoritative bindings live in template/docs/design-guide/ and the corresponding meta-doc _binding-a-new-process.md.
Available case studies
Section titled “Available case studies”- Digital twin downstream — Layer ② Process binding — Scrum cadence, CI/CD ↔ Sprint integration, BDD/TDD tool selection.
When to contribute a case study
Section titled “When to contribute a case study”Suitable contributions:
- A non-trivial binding (typically Layer ② or ③) has been completed.
- The binding choices would be useful as a worked example for other adopters.
- The downstream gives permission to publish the binding pattern (with project-specific names redacted).
Send a PR against uyuutosa/pentaglyph-docs. Use generic archetype names (digital twin, regulated SaaS, etc.) — do not include real project / company / ticket IDs.