{
  "schema": "vedokrok.public-item.v1",
  "release_id": "MHC-RPUB-20260920-75ad787a",
  "url": "/knowledge/count-coordination-edges-before-adding-a-component",
  "id": "MHC-D-RESEARCH-9147",
  "version": "0.1.0",
  "title": "Count coordination edges before adding a component",
  "summary": "Every new node can create more interfaces to understand and maintain.",
  "kind": "checklist",
  "body": "Before adding a component, count required producers, consumers, approvals, observability paths and ownership handoffs. Compare coordination cost with the benefit of separation.",
  "limits": [
    "Modularity trades coordination inside a boundary for coordination across interfaces. Do not split systems simply to make diagrams or org charts look cleaner."
  ],
  "topics": [
    "union-systems-strategy-and-leverage-thinking"
  ],
  "intents": [],
  "source_ids": [
    "RS-6F01EE9805D9E655"
  ],
  "evidence": [
    {
      "claim": "Simon described complex systems as often hierarchical and near-decomposable, motivating analysis of relatively strong within-subsystem interactions and weaker cross-subsystem interactions.",
      "source_id": "RS-6F01EE9805D9E655",
      "role": "contextualizes",
      "note": "Near decomposability is a conceptual property, not evidence that any chosen boundary is correct.",
      "locator": "Near-decomposability discussion"
    }
  ],
  "use_when": [
    "When a proposed component, workflow or team boundary looks locally clean but adds many new interactions."
  ],
  "avoid_when": [
    "Modularity trades coordination inside a boundary for coordination across interfaces. Do not split systems simply to make diagrams or org charts look cleaner."
  ],
  "example": "A new microservice removes 200 lines of code but creates six operational interfaces and an on-call dependency; the trade-off is reconsidered.",
  "check": "The design decision includes coordination edges and lifecycle cost, not only local component size.",
  "checklist": [
    "List new inbound dependencies.",
    "List new outbound dependencies.",
    "List new ownership and support interfaces.",
    "Compare with keeping the capability inside an existing boundary."
  ],
  "sources": [
    {
      "id": "RS-6F01EE9805D9E655",
      "title": "The Architecture of Complexity",
      "url": "https://www.jstor.org/stable/985254"
    }
  ],
  "relations": [
    {
      "from": "MHC-D-RESEARCH-9147",
      "to": "MHC-D-RESEARCH-9148",
      "type": "useful_with",
      "url": "/knowledge/test-whether-modularity-actually-localizes-change"
    }
  ],
  "collections": [
    {
      "id": "RC-28D91C30CEA1CB4A",
      "title": "Systems and strategic leverage: feedback, flow, modularity, robust options, and information value",
      "url": "/collections/systems-and-strategic-leverage-feedback-flow-modularity-robust-options-and-information-value"
    }
  ]
}