Cross-Capability Dependency Mapping
Use generic terminology and preserve the status of every material statement: observed fact, proposal, ratified decision, rejected decision, unresolved question, measured result, estimate, or causal claim.
Workflow
- Define the outcome and capability boundary being mapped.
- Inventory capabilities, owners, inputs, outputs, contracts, data authority, platforms, and decision rights.
- Classify dependencies as data, technical, process, policy, people, funding, vendor, or decision dependencies.
- Record direction, criticality, lead time, confidence, failure effect, fallback, and evidence.
- Identify cycles, single points of failure, shared bottlenecks, contested ownership, and unratified contracts.
- Build a critical path and identify which dependencies can proceed in parallel.
- Assign validation, escalation, and change-notification obligations to named owners.
Boundaries
- Do not infer ownership from who last edited or operates a downstream copy.
- Do not publish private topology, identity, or contractual details in a public artifact.
- Do not treat a dependency map as authority to change another owner's system.
Output
Return Capability map, Dependency register, Critical path, Ownership gaps, Failure paths, Parallel work, and Decisions needed.
1---2name: cross-capability-dependency-mapping3description: Map dependencies across products, teams, data, platforms, decisions, and operating capabilities. Use when delivery or outcomes depend on multiple owners and hidden sequencing, authority, or failure paths must be made explicit.4license: MIT5---67# Cross-Capability Dependency Mapping89Use generic terminology and preserve the status of every material statement: observed fact, proposal, ratified decision, rejected decision, unresolved question, measured result, estimate, or causal claim.1011## Workflow12131. Define the outcome and capability boundary being mapped.142. Inventory capabilities, owners, inputs, outputs, contracts, data authority, platforms, and decision rights.153. Classify dependencies as data, technical, process, policy, people, funding, vendor, or decision dependencies.164. Record direction, criticality, lead time, confidence, failure effect, fallback, and evidence.175. Identify cycles, single points of failure, shared bottlenecks, contested ownership, and unratified contracts.186. Build a critical path and identify which dependencies can proceed in parallel.197. Assign validation, escalation, and change-notification obligations to named owners.2021## Boundaries2223- Do not infer ownership from who last edited or operates a downstream copy.24- Do not publish private topology, identity, or contractual details in a public artifact.25- Do not treat a dependency map as authority to change another owner's system.2627## Output2829Return Capability map, Dependency register, Critical path, Ownership gaps, Failure paths, Parallel work, and Decisions needed.
JovaniPink