Adoption is counted at call sites, not by teams

What it is

Adoption answers: how many places on the product UI actually use a system component. The denominator is call sites — every tag or instance in templates, markup, design files — not “how many teams installed the package”. A team can add the library at the repo root, wrap it in a private shell, show 100% adopted on a team count, and have every call site outside the shell, so the system controls none of the pixels. Counting teams treats install as adoption; counting call sites treats every on-screen use as adoption.

A team is an organisational unit; a call site is an interface unit. The system governs the interface, so the metric has to land on the interface.

Why it happens

Team counts are cheap: read the dependency list, draw “who is on”. Cheap because they never ask how the dependency is used. Wrappers, re-exports, copying component source into the product repo — all leave the dependency list showing “on” while real tags are no longer the system’s names. Call-site counts are expensive: product code and design files must be parsed to recognise system tags, aliases, and renamed re-exports. The expense buys “how many on-screen places are still in the system”.

One large team can contribute most call sites; ten small teams can contribute only install records. Averaging by team dilutes the large team’s bypasses and counts the small teams’ “installed, unused” as adoption. Decision-makers then see an adoption rate decoupled from the consistency users see. After the decoupling, investment keeps walking toward “get more teams to install” instead of “get more call sites back onto system tags”.

Where it stops holding

Repos with no parseable markup yet (native views concatenated from strings, or boards still drawn without components) will under-count; build the recogniser first, do not treat zero as non-adoption. If generated code expands system tags at build time, count source calls before generation, or the artefact will multiply one site into a hundred. Design files and code are two call-site populations; report them separately, do not sum them into one rate — design 90%, code 40% are two problems. Team counts remain a useful onboarding list of “who has not installed”, and must not be titled adoption.

Applying it

• Define a call site: system tags in product source, official re-export aliases, design-library instances. Tags inside a private shell are listed separately and do not count as adoption.
• Ship only a call-site rate: adopted / (adopted + private shell + native clones). Put the team-install list in an appendix, not under the word adoption.
• Detect renamed re-exports: parse import aliases and the render root of wrapper components; credit those to the private shell, not to the system.
• How to check: pick a team already on the install list, take one core flow, count on-screen controls. System tags over total controls, compared with that team’s “adopted” flag. If the report says 100% and fewer than half the tags on the flow are the system’s, the denominator is wrong. Then expand that team’s private shell and count how many sites inside should have been system calls — those are the gaps the team count hid.

Related

• Same group: R1.18.2 High coverage is not the same as correct use · R1.18.3 Metrics exist to locate gaps, not to score consumers · R1.18.4 The distribution of bypasses shows what the system is missing
• Adjacent: R1.06 Contribution and governance · R1.02 Component library and variants
• Search terms: adoption counted at call sites · call-site adoption · team-count adoption