Edge Diagnostics
Core Principle
Diagnose edges before nodes.
Edges are the relationships, interfaces, and dependencies between people, teams, systems, processes, data, controls, and decisions. Many visible problems come from stressed edges rather than failed nodes.
When to Use
- A handoff, ownership boundary, feedback loop, definition, timing dependency, or governance interface appears stressed.
- A person, team, process, or tool is being blamed before the relationship context is understood.
- The user asks for an edge map, system diagnosis, operating issue diagnosis, or cross-functional problem analysis.
Edge Types
Check for:
- Handoffs and interfaces.
- Ownership boundaries.
- Decision rights and decision latency.
- Definition mismatches.
- Feedback loops.
- Timing dependencies.
- Incentive conflicts.
- Trust gaps.
- Governance gaps.
- Data lineage or quality breaks.
- Communication channels.
- Informal workarounds.
- Overreliance on heroic individuals.
- Controls that exist on paper but not in behavior.
Workflow
For each likely stressed edge:
- Name what connects to what.
- Explain why the edge may be stressed.
- Identify the symptom it produces.
- Define evidence that would confirm or disconfirm the stress.
- Propose a small repair that could stabilize the relationship.
Output Template
## Edge Diagnostic Map
| Stressed edge | Connected parties/systems/processes | Symptom produced | Likely tension | Evidence needed | First repair |
|---|---|---|---|---|---|
Quality Checklist
- The map focuses on relationships, not blame.
- Each edge connects named parties, systems, processes, data, controls, or decisions.
- Each first repair is small, testable, and tied to a behavior change.
- Evidence is specific enough to guide validation.
1---2name: edge-diagnostics3description: Diagnoses stressed relationships before blaming people, tools, or teams. Use when analyzing handoffs, feedback loops, ownership boundaries, definitions, timing, incentives, trust, governance, data lineage, interfaces, or informal workarounds.4---56# Edge Diagnostics78## Core Principle9Diagnose edges before nodes.1011Edges are the relationships, interfaces, and dependencies between people, teams, systems, processes, data, controls, and decisions. Many visible problems come from stressed edges rather than failed nodes.1213## When to Use14- A handoff, ownership boundary, feedback loop, definition, timing dependency, or governance interface appears stressed.15- A person, team, process, or tool is being blamed before the relationship context is understood.16- The user asks for an edge map, system diagnosis, operating issue diagnosis, or cross-functional problem analysis.1718## Edge Types19Check for:20- Handoffs and interfaces.21- Ownership boundaries.22- Decision rights and decision latency.23- Definition mismatches.24- Feedback loops.25- Timing dependencies.26- Incentive conflicts.27- Trust gaps.28- Governance gaps.29- Data lineage or quality breaks.30- Communication channels.31- Informal workarounds.32- Overreliance on heroic individuals.33- Controls that exist on paper but not in behavior.3435## Workflow36For each likely stressed edge:371. Name what connects to what.382. Explain why the edge may be stressed.393. Identify the symptom it produces.404. Define evidence that would confirm or disconfirm the stress.415. Propose a small repair that could stabilize the relationship.4243## Output Template44```markdown45## Edge Diagnostic Map46| Stressed edge | Connected parties/systems/processes | Symptom produced | Likely tension | Evidence needed | First repair |47|---|---|---|---|---|---|48```4950## Quality Checklist51- The map focuses on relationships, not blame.52- Each edge connects named parties, systems, processes, data, controls, or decisions.53- Each first repair is small, testable, and tied to a behavior change.54- Evidence is specific enough to guide validation.
bkjohn2018