Ecosystem Value Mapping & Stakeholder Topologies

Beyond the Stakeholder List

I distrust stakeholder lists. They look responsible. They feel thorough. They almost always hide the real structure of the service. A list says who exists. It does not say who can block you, who absorbs uncompensated work, who holds legal authority, or which actor is quietly acting as the systems integrator because nobody else bothered. In practice that missing structure is where the service either holds together or collapses.

ASD separates two jobs that many teams blur together. First I map stakeholder topology: who holds influence, who holds interest, and what kind of decision rights they actually possess. Then I map the ecosystem value network: what each actor gives, what each actor receives, which channel carries the exchange, and which dependencies make the link fragile. The first artifact tells me how the room behaves. The second tells me how the service behaves. I need both before I design any orchestration.

This distinction matters because power and value do not align neatly. A regulator may have very high influence and almost no operational interest. A family caregiver may have almost no formal power while carrying half the coordination burden. A distributor may sit outside the brand book while controlling the economics of the field experience. A partner may happily consume data while refusing reciprocal visibility. When I flatten those differences into a generic actor map, I design fantasies.

The platform helps by forcing concrete outputs. `stakeholder-mapping` produces a `stakeholder-map`. `ecosystem-value-mapping` produces an `ecosystem-map`. Both are gated by the Critic. Both require evidence on their nodes. Both stay draft until the review path says otherwise. That sounds bureaucratic until you have lived through the alternative: a steering committee arguing about whether a partner is "important" because nobody bothered to tie the claim to quotes, telemetry, or documents.

There is also a practical reason to keep the artifacts distinct. Stakeholder positions change faster than structural exchanges. A new COO can reorder influence overnight. A regulator memo can change tolerance without changing the underlying value network. By contrast, the member still carries the referral, the technician still needs the part, the store associate still absorbs the angry conversation. Separating topology from exchange lets me update governance assumptions without redrawing the whole service universe.

ASD's authored templates are useful here because they narrow the blank page. Two of the seven authored templates are the stakeholder map and the ecosystem map. That is a deliberate choice. These are not decorative diagrams for late-stage storytelling. They are load-bearing instruments. The stakeholder map template demands named actors, roles, and evidence references. The ecosystem map template demands value flows, channels, and dependencies. The authored form is the human-readable aid; the runtime contract is what the system checks.

{
  "method": {
    "id": "stakeholder-mapping",
    "phase": "research",
    "outputKind": "stakeholder-map"
  },
  "steps": [
    {
      "role": "researcher",
      "instruction": "Identify stakeholders with explicit evidence of influence, interest, or dependency."
    },
    {
      "role": "mapper",
      "instruction": "Place each stakeholder in a power-interest topology and name the governance strategy."
    },
    {
      "role": "critic",
      "instruction": "Reject any stakeholder placement with unresolved evidence or placeholder fields.",
      "gate": true
    }
  ],
  "acceptance": [
    { "rule": "min-nodes", "min": 3 },
    { "rule": "min-evidence-per-node", "min": 1 },
    { "rule": "field-non-empty", "field": "strategy" }
  ]
}

Notice what is absent. There is no room for "we all kind of know legal matters." The map has to say why legal matters here, which decision it can stop, and what evidence supports that placement. Once I work that way, the conversation gets sharper. Fewer vibes. More consequences.

Ecosystem Value Maps as Artifacts

An ecosystem map in ASD is a typed artifact, not a clever drawing. I care about that because a real ecosystem contains claims that can be tested. Does a GP send structured referral data or a PDF? Does a distributor receive telemetry early enough to act? Does a customer provide labor without compensation? Does a partner get a visible benefit in exchange for data sharing? Those are not illustration problems. They are artifact problems.

The platform template is plain on purpose. It asks for actors, value flows, dependencies, and orchestration implications. Nothing more. Nothing mystical. That modesty is powerful because it blocks the lazy habit of labeling an arrow "data" and moving on. In the artifact I have to say what kind of data, for whose benefit, through which channel, under which constraint. The result is a map that can survive review.

# Ecosystem Map — <service> (mapping view)

## Actors
| Actor | Type | Role in value network | Evidence refs |
|---|---|---|---|

## Value flows
| From → To | Value exchanged | Channel | Evidence refs |
|---|---|---|---|

## Dependencies & constraints
<regulatory, technical, contractual walls — evidence cited>

## Orchestration implications
<channel-role candidates feeding later design work>

The authored template sits upstream of the runtime registry. The runtime itself registers 38 artifact-kind contracts; the practice-facing vocabulary has 39 rows, which includes aliases and pending concepts. I keep that distinction straight because otherwise people start speaking as if every practice term already exists as a live runtime schema. It does not. The ecosystem map does. The stakeholder map does. That lets me work with confidence on these two surfaces.

When I run `ecosystem-value-mapping`, the engine returns a machine contract: source references, role-attributed steps, acceptance rules, and the declared output kind. The model is allowed to draft. The runtime is allowed to check. The Critic is allowed to veto. That separation matters because the hardest ecosystem claims are the most politically tempting ones to overstate. A team loves to write "shared visibility" or "outcome guarantee" long before it can name the measurement window or the accountable actor.

Aurora Vento gave me a clean example. The first pass of the ecosystem map described Aurora's offer to customers as "guaranteed operational performance." That sounded impressive and useless at the same time. The Critic vetoed it under a measurability rule: no formula, no window, no exclusions, no telemetry source. Exactly right. "Guaranteed operational performance" is not a value flow. It is a slogan pretending to be a contract.

{
  "rowKind": "defect",
  "severity": "critical",
  "rule": "measurability",
  "message": "The value Aurora exchanges is stated as guaranteed operational performance: no availability formula, no window, no exclusions, no data source. That is a slogan, not an outcome.",
  "fix": "Name the uptime formula, the measurement window, the exclusions, the telemetry source, and the per-point remedy before this map can anchor the contract."
}

That one veto does more to explain the value of the artifact model than a hundred process diagrams. The platform did not invent a better strategy. It merely refused a false one. Once the team had to name the formula, the window, the exclusions, and the remedy, the conversation moved from aspiration to architecture. That is what I want from an ecosystem artifact. It should force the hard nouns into the room.

I also use the map to make channels legible. A value flow without a channel is a fantasy. If a patient carries a referral letter physically, I record manual hand-carry. If a hotel brief moves through a shift handoff, I record the brief. If a telemetry packet reaches a distributor dashboard every four hours, I record the sync pattern. Channel detail sounds mundane until a redesign depends on a signal that never actually arrives.

Once the map is built this way, it becomes useful far beyond diagnosis. It feeds orchestration work, requirement shaping, governance design, and pilot scoping. It tells me where shared metrics are possible and where they are fiction. It tells me which actor must be able to exit without the whole design collapsing. It tells me where a portal-first idea will fail because the real pain is re-keying, not access.

Exchanges, Dependencies and Risk

The heart of ecosystem work is the exchange itself. Services do not move only money and information. They move trust, legal authority, scheduling power, care responsibility, physical labor, exception handling, and reputational risk. If I model only the easy exchanges, I misread the operating model.

Northgate Health made this visible immediately. The formal story was about digital referrals. The real story was that the member was still carrying context between actors because the seam had no persistent state. The GP printed a referral. The specialist owned the booking. Diagnostics held results in a separate portal. Pharmacy saw prescriptions without care intent. Home care saw discharge tasks without medication changes. Northgate saw claims after the fact. Meridia saw telehealth episodes without the whole pathway. That is not one broken channel. It is a fractured exchange economy.

When OpenCode reconstructed 47,800 referral events and 11,900 multi-actor care chains, the crucial number was not glamorous: only 54% of referral outcomes made it back to the referrer within 30 days. Another brutal finding sat beneath that: 23% of referral coordination still happened by phone chains that Northgate's owned systems could not see at all. The member was still doing unpaid integration work in a supposedly digitized pathway.

Aurora Vento had a different topology and the same lesson. Hardware margin was eroding. Customers wanted availability commitments. Aurora had 41,000 machines in the field, 340 technicians, operations in 46 countries, and an MTTR of 5.2 days. The service economy around those machines depended on distributors, telemetry, parts, procurement, and technicians who each saw only part of the system. Here the hidden exchange was more than data. It was coordinated readiness: the right part, the right skill, the right timing, and a shared accounting of what uptime actually meant.

Dependency risk appears when one actor receives a burden that nobody has acknowledged. In Northgate the burden was administrative and cognitive. Members repeated their history, carried documents, and chased status across portals. In Aurora the burden was operational. Distributors and technicians absorbed the mismatch between contract ambition and messy logistics. In both cases the service looked stable until you asked who was compensating for the seams.

This is why I use dependency risk registers alongside the ecosystem map. The map shows the shape. The register shows where the shape is brittle. I want to know which flows are legally constrained, which depend on manual workarounds, which rely on one individual, and which lack a graceful fallback. Those questions are especially important when AI enters the mix, because a model will happily recommend a flow that assumes universal API adoption or universal willingness to share data.

flow_id,from_actor,to_actor,risk_type,symptom,current_workaround,design_move
NX-04,GP,Specialist,manual-handoff,printed referral carried by member,member hand-carries paper,structured referral plus consent token
NX-09,Specialist,Referrer,missing-loop-closure,outcome returns late or not at all,GP calls clinic,weekly loop-closure audit plus API push
AV-07,Telemetry,Distributor,partial-visibility,machine alerts arrive too late,technician phones depot,shared event feed with SLA
AV-11,Parts chain,Field technician,dispatch-mismatch,wrong part arrives after visit,second truck roll,coupled parts-and-skills dispatcher

Risk work also changes design posture. Teams often want a central platform because it feels tidy. The ecosystem map usually tells me whether that instinct is arrogant. Northgate's evidence did not support a portal-first rollout. Practices wanted fewer handoffs and less re-keying, not another login. That single insight produced the principle Never re-key and pushed the design toward an API-first model with structured fallback. The member benefit stayed central. Northgate did not get to pretend it was the natural center of care.

The same happened at Aurora. A centralized dispatch model sounded elegant from headquarters and threatening in distributor regions whose economics still depended on emergency parts. The stakeholder topology exposed the political risk. The ecosystem map exposed the operational dependency. Together they stopped the team from calling a power struggle an implementation detail.

Case: Northgate Health and Aurora Vento

Northgate Health and Aurora Vento sit in different worlds. One coordinates care across providers, pharmacies, diagnostics, and home-care actors under heavy data sensitivity. The other is trying to turn industrial equipment uptime into a credible service promise across telemetry, distributors, technicians, and parts chains. I pair them because together they show the full range of ecosystem work: one highly relational and consent-bound, one heavily operational and contract-bound.

At Northgate, the redesign started only after the map corrected the framing. The issue was never merely slow referrals. The issue was that the system closed cost loops faster than care loops. Once I phrased it that way, decisions changed. The target stopped being a shiny portal. The target became a care-coordination layer that respected partner autonomy while reducing invisible labor. The future-state direction became the Northgate Gateway: a care-coordination service with four bounded capabilities — a unified member record assembled from consented summaries rather than full takeover, referral orchestration, a provider API hub using open standards, and a loop-closure engine that chased missing outcomes before the patient fell through the seam.

The ecosystem map made the guardrails explicit. Data sharing had to be consensual, reversible, and non-lock-in. GPs remained autonomous. Specialists kept their systems. The design promise was narrower and stronger: orchestrate the seam, do not colonize the ecosystem. That is why the numbers improved in the pilot target logic. Median referral admin cycle was attacked at the seam. Loop closure was attacked at the missing return path. Manual channel share was attacked through structured payloads and status heartbeats, not through institutional grandstanding.

Aurora's case had more obvious commercial drama. The board wanted to sell availability instead of parts. Customers wanted 98% machine availability. Leadership's first instinct was pricing. The ecosystem work showed the real problem was service delivery capability. Remote parts availability was 81%. MTTR was 5.2 days. Dispatch mismatch was a recurring culprit. The map traced value flows across Aurora, legacy ERP, telemetry, the parts chain, distributors, procurement, and customer operations. It showed exactly where the promise would fail if the contract got ahead of the operating system.

The decisive moment was the Critic veto on the vague outcome definition. Once forced to specify the uptime formula, measurement window, exclusions, data source, accounting level, and remedy, the team could no longer hide behind rhetoric. The design then moved toward what the ecosystem could actually support: telemetry rules for earlier detection, a coupled parts-and-skills dispatcher, clearer distributor roles, and contract language built on measurable events rather than marketing fog.

{
  "projectId": "northgate-gateway-7c2d",
  "planId": "plan-ecosystem-to-canvas",
  "from": "mapper",
  "to": "ideator",
  "condition": "Ecosystem and stakeholder maps have passed Critic review; begin orchestration canvas from validated seams.",
  "artifactId": "artifact-ecosystem-map-01",
  "artifactKind": "ecosystem-map"
}

I include a typed handoff like this because ecosystem work is only valuable if it carries forward without distortion. The next phase should inherit validated actors, dependencies, and evidence-backed seams. It should not restart from a workshop summary. In ASD that handoff has to resolve in the same project and the `artifactKind` must match the stored artifact. If it does not, the record fails before it is written. Good. That is the kind of failure I want early.

The two cases also show why reciprocity matters. Northgate succeeded because every actor got something visible out of participation: less re-keying, better loop closure, clearer status, reversible consent, fewer blind phone chases. Aurora succeeded when the offer stopped pretending value flowed one way. Distributors needed a viable role. Technicians needed better readiness, not more dashboard poetry. Customers needed a measurable outcome with an accountable remedy.

By the end of both programmes, the ecosystem map had done its real job. It had reduced the surface area for self-deception. The sponsor could still make trade-offs. The human designer still made framing calls. But nobody got to claim that a portal equaled coordination, or that a guarantee existed because a brochure said it did. The artifacts carried the argument, and the evidence carried the artifacts.

If you remember one thing from this chapter, make it this: ecosystem work is where you discover whether your service is actually designed for the world it must survive. Stakeholder topologies tell you whose resistance matters. Ecosystem maps tell you whose work matters. When both artifacts are evidence-backed and Critic-reviewed, you get something rare in service design — a strategic picture that is finally concrete enough to build against.