Platform Extension Health and Dependency Dashboard¶

Monitor — instantiates Platform Core / Extension Design

The instrument panel that separates growth from health — surfacing failing extensions, concentrated dependencies, stalled migrations, and eroding exit options that rising usage counts conceal.

Platform Extension Health and Dependency Dashboard is the instrument panel that connects core reliability and extension behavior to the signals that predict ecosystem trouble: which extensions are failing, where dependencies concentrate, whose migrations are stalling, and whether burden and value are landing where the platform intends. Its defining discipline is bounded, action-oriented observation. It exists to make a small number of consequential problems visible early enough to act on — not to count everything, and pointedly not to flatter the platform with growth numbers that climb while the ecosystem quietly grows more fragile.

Example¶

A content-management platform hosts thousands of third-party plugins. Total installs keep rising, so leadership assumes health. The dashboard says otherwise. It surfaces that roughly 40% of live sites depend on a single image-optimization plugin whose maintainer went quiet eight months ago — a concentration the install count hides entirely. It flags a cluster of plugins pinned to a core version that reaches end-of-life next quarter, and a climbing rate of timeout errors traced to two specific extensions.

None of that is visible in the vanity number.^[1] Acting on the dashboard, the platform sponsors a maintained fork of the critical plugin, nudges the pinned plugins toward migration, and quarantines the timeout offenders before they cause an outage — three decisions the raw growth curve would never have prompted, because the growth curve was still green.

How it works¶

Track a bounded set of consequential signals — core and extension failure rates, dependency concentration, version and migration status, support burden, participant outcomes — not everything measurable.
Connect extension behavior back to core reliability, so a platform-level symptom can be traced to the extension causing it.
Surface leading indicators — concentration, staleness, stalled migration — early enough to act on, not just post-mortem counts.
Tie each signal to an owner or action, so the board drives decisions rather than decorating a wall.

Tuning parameters¶

Signal selection — which few things are worth watching. Well-chosen signals drive action; a bloated board buries the one number that mattered and drifts toward surveillance.
Concentration sensitivity — how aggressively single-point dependencies are flagged. High sensitivity catches fragility early but cries wolf; low sensitivity misses the plugin everyone secretly depends on.
Aggregation vs. granularity — ecosystem-wide health versus per-extension detail. Aggregates spot systemic drift; granularity localizes the cause; too much of either blinds you to the other.
Alerting threshold — when a signal becomes a page. Tight thresholds surface trouble early; too tight and the alerts get muted, which is how the real one gets missed.

When it helps, and when it misleads¶

Its strength is that it separates growth from health, making visible the fragility, concentration, and extraction that usage counts conceal, and it turns the change council's and platform team's decisions from anecdote into evidence.

Its failure mode is that a dashboard measures what is easy to measure, so the hardest-to-instrument harms — a slow slide toward extraction, a burden quietly shifted onto builders — can stay invisible while every light is green; and it can decay into a vanity or surveillance instrument that tracks activity instead of health. The classic misuse is reading rising usage and revenue as proof the platform is well, during the very period it is becoming more fragile or more extractive. The discipline that guards against this is to keep the board bounded, action-tied, and pointed at fragility and participant outcomes rather than at flattering totals.

How it implements the components¶

The dashboard realizes the observation side of the ecosystem — the signals that reveal health and resilience without themselves changing anything:

platform_observability_and_ecosystem_health_signals — is the health-signal layer: it connects core reliability and extension behavior to dependency, concentration, migration, burden, and participant-outcome signals, and makes them actionable.
platform_portability_exit_and_contingency_path — supplies the dependency-concentration and lock-in signals that reveal whether a credible exit still exists; a contingency path stays credible only if someone is watching the concentration that erodes it.

The dashboard observes; it does not enforce the guardrails it flags (Platform Sandbox and Capability Permissions), govern the changes its signals call for (Platform Ecosystem Change Council), or declare the per-extension dependencies it aggregates (Platform Extension Manifest).

Instantiates: Platform Core / Extension Design — the dashboard is how the platform sees its own ecosystem's health and fragility.
Consumes: Platform Extension Manifest supplies the declared dependencies the dashboard aggregates into a concentration view.
Sibling mechanisms: Platform Ecosystem Change Council · Platform Extension Manifest · Platform Sandbox and Capability Permissions · Platform Migration and Deprecation Tooling · Platform Architecture Blueprint · Platform API and SDK · Platform Capability Catalog and Portal · Platform Conformance Test Suite · Platform Plugin and Extension Registry · Platform Reference Implementation · Platform Semantic Versioning and Release Train

Notes¶

The dashboard's portability signal is a warning light, not an exit. It can tell you that lock-in is forming — one plugin everyone depends on, a substitution getting harder — but it cannot itself make the platform leaveable; that requires actual portability and substitution machinery elsewhere. Confusing the warning light for the fire exit is how a platform congratulates itself on "visibility" while its exit options quietly close.

References¶

[1] Vanity metrics — measures that rise reassuringly (total installs, extension count, revenue) while saying nothing about whether the underlying system is healthy. Eric Ries popularized the term to distinguish them from actionable metrics; a health dashboard earns its place only by tracking the latter. ↩