Platform Ecosystem Change Council¶

Governance body — instantiates Platform Core / Extension Design

The standing, representative body that holds decision authority over ecosystem-wide changes — breaking contracts, participation terms, ranking and fees, deprecation — so the rules that decide who captures value are made with the builders who live by them.

Platform Ecosystem Change Council is the standing, representative body that holds decision authority over the changes no single team should make alone: breaking changes to shared contracts, who may participate and on what terms, how extensions are ranked and charged, and when a surface is deprecated or retired. Its defining feature is authority with representation. Unlike a review that judges one extension, the council governs the rules of the ecosystem itself — and because those rules decide who captures value, it only works if the builders who live with the decisions hold a real seat, real evidence, and a real appeal, not a consultation staged after the fact.

Example¶

An electronic-health-record platform has hundreds of independent clinical-app vendors building on its patient-data API. The vendor of a widely used e-prescribing app depends on a field the platform now wants to change for a safety fix — a breaking change that will cost every vendor a migration. Rather than the core team deciding unilaterally, the change goes to the council: platform engineers, elected vendor representatives, and a clinical-safety lead.

They see the dependency evidence — how many apps touch the field — weigh the safety benefit against the migration burden, and rule: a phased break with an eighteen-month support window, migration tooling funded by the platform, and a documented rationale that a dissenting vendor may appeal. The decision holds not because the operator imposed it, but because the people who pay for it helped make it. That legitimacy is the thing a unilateral edict cannot buy.

How it works¶

Hold authority over ecosystem-wide decisions — breaking changes, access and participation terms, ranking and fees, deprecation and retirement — that individual teams should not decide alone.
Seat the affected — platform, builders, and any safety or domain stakeholder — with enforced recusal when the operator's own interests are in play.
Decide on evidence — dependency data, burden estimates, stated criteria — and record the rationale.
Provide appeal and revisitation, so a decision can be challenged and revised rather than merely announced.

Tuning parameters¶

Authority scope — what actually requires the council versus what teams decide freely. Too broad and it bottlenecks trivial change; too narrow and the consequential decisions slip past it.
Representation balance — how much voice builders hold relative to the operator. More builder voice builds legitimacy but can stall changes the platform genuinely needs; operator-dominated councils forfeit trust.
Recusal rigor — how strictly conflicted members step back. This matters most exactly where the operator competes with the builders it governs.
Decision cadence — standing schedule versus on-demand. Predictable cadence sets expectations; too slow a cadence pushes teams to route around the council with "emergency" exceptions.

When it helps, and when it misleads¶

Its strength is that it makes contested, ecosystem-wide change legitimate — which is the only thing that makes such change stick — and it is the natural guardian of the fairness that keeps complementors^[1] building even when the operator is also their competitor.

Its failure mode is consultation theater: a council with the trappings of representation but no real authority, evidence, or appeal, which launders decisions already made elsewhere and is worse than honest unilateral control because it disguises it. The classic misuse is convening the council to ratify a change the operator has already shipped — running the process backward to manufacture buy-in. The discipline that guards against this is real authority, recorded evidence and rationale, enforced recusal, and a genuine appeal path — the difference between governance and its costume.

How it implements the components¶

The council realizes the governance components — the rule-setting and lifecycle authority that no single team should hold:

platform_ecosystem_access_and_incentive_rule — sets the terms of participation: who may build, how extensions are discovered, ranked, and charged, and how value and governance voice are distributed.
extension_lifecycle_governance — holds authority over the lifecycle's consequential gates — admission, breaking change, deprecation, retirement — giving harmful or abandoned extensions an orderly path out.

It sets the rules but does not run the per-extension review those rules require (Platform Extension Review and Certification), record extension identity and lifecycle state (Platform Plugin and Extension Registry), or execute the migrations its deprecation rulings trigger (Platform Migration and Deprecation Tooling).

Instantiates: Platform Core / Extension Design — the council is the authority that governs how the ecosystem changes over time.
Consumes: Platform Extension Health and Dependency Dashboard supplies the dependency and health evidence its rulings rest on.
Sibling mechanisms: Platform Extension Review and Certification · Platform Migration and Deprecation Tooling · Platform Extension Health and Dependency Dashboard · Platform Architecture Blueprint · Platform API and SDK · Platform Capability Catalog and Portal · Platform Conformance Test Suite · Platform Extension Manifest · Platform Plugin and Extension Registry · Platform Sandbox and Capability Permissions · Platform Semantic Versioning and Release Train

Notes¶

The council decides, but it can only decide well on evidence it does not itself produce: the dependency graph and health signals from the dashboard, the identity and state from the registry. A change council without that evidence pipeline is opinion with a quorum — which is exactly the failure that "consultation theater" describes from the inside.

References¶

[1] Complementors — Brandenburger and Nalebuff's term (from Co-opetition) for the independent builders whose products make a platform more valuable. A change council's hardest task is governing changes fairly when the operator is simultaneously a complementor's competitor. ↩