Component Catalog, Usage, and Contributor Credits

[horner]

Component Catalog, Usage, and Contributor Credits

Vision

Build an internal catalog that connects the software people use to the people
who make it possible: an IMDb-like record of components, applications, releases,
and contributors, informed by real usage and feedback.

The catalog spans participating public and private repositories, not only
mieweb/ui. This library is an initial integration and reference implementation,
not a requirement for participation. Teams can register components, utilities,
and applications without moving their code here or adopting React or Storybook.

An application should be able to show movie-like credits for its release. A
contributor should be able to show a portfolio of shipped work, the applications
that use it, and the improvements it enabled. A developer choosing a component
should be able to see its purpose, alternatives, real-world compositions,
maintainers, and evidence of adoption.

The goal is to reward useful, reliable contributions and make reuse visible,
not to turn clicks, commits, or lines of code into an employee ranking.

The invitation to contributors is: make your work discoverable and measurable
so you can see where it helps, receive credit, and hear what would make it better.
Developers, product managers, designers, researchers, testers, technical writers,
and other contributors should all benefit, whether their audience is another
developer adopting a component or an end user completing a task.

This is a proposal. The catalog, instrumentation API, credits system, and metrics
described below are not implemented by this document.

Outcomes

• Discover which components exist, why to choose them, when not to, and how they fit together.
• Identify which products, applications, and screens consume each version.
• Measure exposure, meaningful use, and explicit feedback where applications opt in.
• Credit design, implementation, testing, accessibility, documentation, and maintenance.
• Generate release-specific application credits and contributor portfolios.
• Encourage adoption, improvements, and collaboration through internal follows,
  appreciation, and recognition of shipped work.

Catalog Model

Use stable identifiers and versioned relationships, not names alone. A rename
should not erase usage or credit history.

Entity	Meaning	Example
Product	A business offering that can contain several applications	Employee health service
Application	A deployable browser interface, including embedded or non-React hosts	Employee portal
Screen or workflow	A named user-facing context inside an application	Review a document
Component	A UI building block or composed feature	TableOfContents, document review panel
Utility	A supporting hook, parser, formatter, or service without its own visible UI	useScrollSpy
Release	An immutable application or package version and its resolved dependencies	Portal release pinned to a Git commit
Contributor	A person or team with verified contributions	Designer, implementer, reviewer, maintainer

Separately classify a component's reuse scope: general-purpose,
domain-specific, product-specific, or application-local. Product and application
are deployment contexts; they should not be confused with component size or
reusability. A useful local component does not have to become a shared primitive.

Record relationships such as contains, uses, depends on, composes with,
alternative to, and supersedes. Distinguish direct dependencies from transitive
dependencies. Label build-time references separately from observed runtime use.

Each component entry should include its source repository, package or artifact
identity, version, purpose, selection guidance, limitations, documentation/demo
links, composition examples, maintainers, lifecycle status, and approved usage
references. Namespace artifact identifiers by organization and stable repository
identity so similarly named components remain distinct. A repository may contain
many artifacts; one release may consume artifacts from many repositories.

Keep durable rationale in the owning repository and reference it from the catalog.
Follow that repository's contribution and review policy; the
mieweb/ui contribution guide
is one example, not a requirement imposed on other projects.

Maturity and Lifecycle

Track maturity per artifact version, separately from deployment environment and
rollout status. A beta can be trialed in a production application without becoming
generally available; a stable component can still have an experimental successor.
Do not infer maturity from a package version, npm tag, or deployment alone.

Stage	Intended Use	Promotion or Exit Evidence
Experimental	Explore a hypothesis with explicitly approved participants	Defined problem, alternatives, owner, and evaluation plan
Alpha	Early integration with limited consumers; API may change	Working composition, documented limitations, baseline safety/accessibility checks, and rollback path
Beta	Broader opt-in evaluation with migration support	Representative workflow testing, feedback triage, compatibility and performance evidence
Stable / GA	Supported production use within documented constraints	Maintainer approval, support ownership, required quality gates, and migration documentation
Deprecated	Existing consumers supported under a stated policy; no new adoption	Replacement or retirement rationale, consumer inventory, notices, and migration plan
Retired	No longer supported or available for new deployment	Remaining consumers accounted for, exceptions resolved, and historical records preserved

Owning repositories define measurable gates and approve transitions. Record who
made each decision, when, and the evidence; allow withdrawal or downgrade when
risks emerge. Display the stage, known limitations, support expectations, and
successor links in catalog entries and developer-facing examples.

Experiments and Replacement Rollouts

Launch Small, Learn Early, Expand Deliberately

Encourage frequent launches of small, independently reversible changes rather
than waiting for a large replacement to be complete. Separate deployment from
exposure using host-controlled feature flags. An early launch can be a preview
or a non-authoritative evaluation; it need not immediately replace the supported
workflow. Do not require an A/B experiment for every release.

Use a lightweight rollout record linked to the release: owner, intended benefit,
risk classification and rationale, eligible cohorts, stage history, guardrails,
minimum observation requirements, promotion authority, and recovery procedure.
Reuse the experiment record below when testing a hypothesis statistically;
ordinary canaries need operational acceptance criteria, not a significance test.

Match Controls to Consequence

Classify the change in its actual workflow, considering severity, reach,
detectability, and reversibility. A small visual change that hides a medication
warning is consequential. A small cohort limits exposure but does not make a
dangerous action safe. Escalate uncertain classifications for domain review.

Control	Relatively Low-Risk Changes	Consequential Changes
Examples	Reversible preferences, non-critical navigation, or presentation without altered meaning	Clinical decisions, orders, payments, access control, destructive actions, or data interpretation
Early learning	Internal preview, then a limited production canary after baseline checks	Synthetic/sandbox evaluation or approved non-authoritative shadow mode before live effects
Approval	Named owner and standard review; automated promotion may follow pre-approved gates	Domain/product owner and engineering approval, plus safety/security/compliance review where applicable
Exposure	Small stable cohort, then progressively broader eligible traffic	Explicitly approved users, sites, or tenants with absolute exposure caps and supervised stages where needed
Promotion	Automated or owner-approved after sufficient observations and healthy guardrails	Explicit sign-off at each live expansion based on workflow-specific evidence
Recovery	Tested flag disablement and prior experience with state preserved	Validated safe fallback plus reconciliation or compensating actions for effects already committed

Both paths require functional, accessibility, privacy, and security checks relevant
to the change. Shadow evaluation must not execute duplicate side effects, influence
real decisions, or bypass data-access rules. Do not experiment on consequential
decisions solely to learn whether an unvalidated implementation is safe.

Staged Canary Procedure

1. Prepare: ship behind a flag with a safe default; verify current and new
   paths, compatibility, monitoring, kill-switch access, and recovery. Specify
   thresholds for errors, latency, task failure, opt-backs, and safety signals as
   appropriate. Name the person monitoring the launch and able to stop it.
2. Preview: expose to internal or consenting pilot users. Collect developer
   and end-user feedback before widening access. For consequential changes,
   complete the required non-live evaluation and approvals first.
3. Canary: enable for a small, stable eligible cohort. An illustrative low-risk
   sequence is 1%, 5%, 25%, 50%, then 100%; these are not universal requirements.
   Use tenant/site allocation when shared workflows make per-user switching unsafe.
   Combine percentages with absolute caps so large deployments remain bounded.
4. Observe and decide: at each stage, meet predefined minimum exposure and
   observation windows covering relevant workflow cycles and delayed effects.
   Compare against a suitable baseline and inspect feedback and critical cohorts.
   No traffic, missing telemetry, or no complaints is not evidence of success.
   Promote, hold, or stop according to the risk path; record the evidence and actor.
5. Stop safely: pause expansion when evidence is missing or guardrails fail.
   Trigger automatic rollback only where the fallback is validated as safe;
   otherwise stop affected actions and invoke the recovery procedure. Disabling
   a flag does not undo orders, payments, writes, or other completed side effects.
6. Complete: expand to the approved population, continue monitoring through
   a stabilization window, and then remove temporary flags and old code according
   to the migration policy. Full rollout, stable maturity, and predecessor
   retirement remain separate decisions. Substantive changes during rollout need
   renewed validation and an appropriate restart stage.

Show the rollout timeline in the catalog: cohort and allocation revisions,
exposures, guardrail results, opt-backs, holds, rollbacks, and approvals. Keep
operational safety monitoring available even when optional product analytics is
disabled; if required monitoring is unavailable, do not expand the rollout.

Recognize short feedback loops, useful increments, and responsible stops, not
raw deployment counts or the speed of reaching 100%. A consequential feature can
iterate frequently in preview while its production exposure remains constrained.

Experiment Record

Link each experiment to immutable artifact versions, application releases, and
workflows. Record its owner, hypothesis, eligible population, variants, start/end
dates, allocation revisions, primary outcome, guardrail metrics, minimum useful
effect, evaluation window, and stop/rollback criteria before launch. Track planned,
running, paused, completed, and stopped experiments with a decision log.

Use the host's feature-flag or experimentation platform for assignment and rollout
control; instrumentation observes decisions rather than making them. An OTel
adapter exports evidence but is not an experiment assignment or analysis engine.

Distinguish voluntary previews, staged rollouts, and randomized A/B tests.
Early adopters are self-selected; a rollout percentage is not automatically a
controlled experiment. For A/B tests, choose and record the randomization unit
(session, user, team, or tenant), maintain stable assignments, and account for
shared workflows where participants can affect one another.

Exposure, Choice, and Outcomes

Record eligibility, assignment, actual exposure, meaningful actions, outcomes,
and preference changes as distinct events. Include experiment/variant identifiers,
artifact version, and the workflow's approved context. Preserve original assignment
when someone switches, while recording which experience they actually received.

For a replacement, link the old and proposed artifacts with a scoped replacement
record: what is replaced, why, compatibility gaps, supported consumers, migration
instructions, and retirement conditions. A proposed successor does not immediately
deprecate its predecessor.

Provide an accessible "Try the new experience" and, where safe and permitted,
"Return to the previous experience" control. Preserve work and preferences across
switches. Explain when switching is unavailable because data formats or workflow
state are incompatible; do not promise reversibility without testing it.

Measure the replacement journey with explicit denominators and time windows:

• Offer uptake: distinct eligible units choosing the preview divided by units
  actually shown the offer; keep automatic rollout exposure separate.
• Exposure: distinct assigned units that actually see the new experience,
  reported alongside assignment counts and missing exposure data.
• Opt-back rate: distinct exposed units explicitly returning to the old
  experience divided by exposed units for whom that choice was available. Report
  both counts, the unit (people, sessions, or tenants), and observation window.
• Continued adoption: units still choosing the new experience at a defined
  follow-up opportunity among units with an observed follow-up. Report units with
  no follow-up separately; silence is not satisfaction.
• Switch reasons: optional user-reported reasons, with response counts, plus
  linked feedback. Separate missing capability, usability, accessibility, and
  performance concerns without inferring intent from a click alone.
• Operational fallbacks: errors, compatibility routing, administrator overrides,
  and emergency rollback, recorded separately from voluntary opt-backs.

Show these alongside task success, errors, latency, accessibility findings, and
developer integration feedback. If deduplicated people counts are needed, compute
them within the host's approved identity boundary; export authorized aggregates
rather than global user identifiers. Session-based counts must not be labeled
"people." Do not introduce cross-application tracking to measure adoption.

Evaluation and Launch Decisions

For randomized experiments, retain assignment-based (intention-to-treat) analysis
even when users switch; label exposure-based and self-selected comparisons as
secondary. Check assignment imbalance, telemetry loss, sampling, novelty effects,
and uncertainty. Predefine sample-size/duration needs and a suitable stopping
method rather than repeatedly checking for a favorable result. Low-volume trials
may remain inconclusive and require qualitative evidence.

Keep safety and accessibility as launch gates, not tradeoffs that a higher average
conversion rate can excuse. Provide a host-controlled kill switch and test rollback
with in-progress work. Product owners and maintainers record whether to expand,
revise, stop, or retire, referencing results and unresolved issues. Promotion to
stable and removal of the old experience are separate decisions.

Contributor portfolios can credit experiment design, implementation, analysis,
and improvements, including a well-supported decision not to launch. Do not award
credit only to "winning" variants or penalize teams for exposing opt-back feedback.

Cross-Repository Participation

Define a versioned, repository-independent manifest and ingestion API. Support
public repositories, private libraries, and application-local components using
the same contract. GitHub is an initial connector, not a required source host.

• Register: a repository owner opts in, identifies artifacts and maintainers,
  and chooses which metadata may be shared and with whom.
• Publish inventory: run analysis inside the repository's own CI and submit
  approved manifests using repository-scoped credentials. Do not require central
  source access. Optional source-host connectors need least-privilege access only
  to selected repositories; credentials must never enter the browser client.
• Resolve usage: join dependencies to artifact versions using approved package
  coordinates and commit identities. Allow reviewed mappings for vendored code,
  forks, and wrappers; leave unresolved dependencies explicitly unknown rather
  than attributing them by name alone.
• Collect evidence: accept the shared event schema through an independent
  client or adapter. Repositories can use existing instrumentation without
  importing @mieweb/ui; inventory, credits, and feedback can participate without
  runtime instrumentation at all.
• Respect ownership: route feedback and proposed changes to the owning team
  and repository. Catalog participation does not authorize copying private code
  into this repository or making private issues public.

Default private entries to their approved audience, with separately approved
company-visible summaries where desired. Repository access and catalog metadata
access are distinct: access to a summary must not imply permission to inspect
source, feedback, or attachments. Never broaden visibility merely because a
public component is used by a private application.

Enforce permissions on relationships as well as entries, including search,
portfolio credits, notifications, exports, and aggregate counts. Do not leak the
existence of a restricted consumer through a "used by" count or credit listing.
Support access revocation and re-evaluate cached views and subscriptions when
sharing changes. Cross-repository credits remain release-specific but are always
filtered for the viewer's current authorization.

Three Sources of Evidence

1. Build-Time Inventory: Where It Is Used

An opt-in CI scanner produces a manifest of application/release identifiers,
resolved package versions or submodule commits, imported components and utilities,
and approved screen/workflow mappings. Hosts outside React can participate through
their build manifests or explicit registration.

Use structured source analysis and dependency metadata. Support manual declarations
for wrappers and dynamic integrations the scanner cannot resolve. Preserve the
evidence source and uncertainty; an import does not prove a component is visible,
shipped, or used. Do not upload proprietary source code to populate the registry.

2. Runtime Instrumentation: How It Is Used

Provide a small, optional repository-independent event interface, with a
@mieweb/ui integration as one client. The host enables it once and
supplies allowlisted application, release, and workflow identifiers. Embedded
React roots can share a client; events are not limited to whole React applications.

• Record visible exposure and meaningful actions, not React render counts.
• Define event semantics per component and version the event schema.
• Distinguish user actions from programmatic changes, automated tests, and Storybook demos.
• Deduplicate exposure within a documented boundary; account for remounts and virtualized content.
• Let applications report task success and abandonment only when they can determine them reliably.
• Instrument utility calls selectively; high call volume is not comparable to screen exposure.
• Bound queues, batch, sample, and drop events safely under failure. Telemetry must not break the UI.

Keep export vendor-neutral. Offer an optional OpenTelemetry adapter that reuses
the host's SDK; use counters and histograms for aggregates, structured events for
interactions, and spans only for operations that benefit from tracing.
OTLP/HTTP can carry data to an application-owned endpoint or collector. Product
analytics adapters may provide better feedback and funnel exploration.

Central company reporting receives only explicitly approved events or aggregates.
No mandatory collector, second global SDK, or automatic library phone-home.

3. Feedback: What People Think

Develop a reusable feedback UI that accepts text and optional screenshot, video,
or manually uploaded attachments. Capture starts only after a user action and
browser permission where required. Users preview, remove, and explicitly submit
attachments; offer screenshot redaction and explain its limits for video.

The host supplies a submission callback and approved context. It owns routing,
storage, access control, and retention. Reuse existing modal, field, attachment,
and media components; separate capture from submission. Text-only feedback must
work when capture is unavailable or denied.

Provide two distinct feedback paths:

• Developer-consumer feedback: collect from the catalog, documentation, or
  integration workflow. Ask about discoverability, API fit, setup, documentation,
  composability, and reasons for adopting or rejecting a component. Attach the
  component/version and an authorized consumer reference when available. A
  developer should be able to give feedback before successfully integrating it.
• End-user feedback: collect in the application and ask about the task, not an
  internal component name. Associate it with the application release and workflow;
  component attribution may need human triage. Ask about clarity, task completion,
  usability, and accessibility without requiring knowledge of the implementation.

Keep these audiences distinct in reports: developer satisfaction with an API is
not end-user satisfaction with an interface. Route feedback to a current owning
team for triage, then share authorized themes and updates with credited
contributors who subscribe. Credit does not automatically grant access to raw
feedback or sensitive attachments, nor make every historical contributor a
support contact.

Track whether feedback resulted in an issue, fix, and released improvement. When
the reporter has opted into updates, close the loop with an acknowledgment and
resolution notice. Credit useful feedback, reproduction steps, and validation of
fixes as contributions where verified.

Authorship and Credits

Maintain a contribution ledger with contributor/team ID, artifact, role, PR or
other evidence, release/version range, reviewer, and verification status.

Roles should include original author, product management, problem discovery,
research, design, implementation, testing, accessibility, localization,
documentation, review, and ongoing maintenance.
Represent collective work and multiple roles; distinguish current maintainers
from historical contributors. Credit substantial non-code work with evidence too.

Git and PR metadata can suggest credits, but commit counts, blame, and the person
who pressed merge do not establish authorship. Confirm credits during review and
provide a correction/dispute process. Preserve historical identity and attribution
without making departed contributors responsible for current support.

Application credits are generated from a release manifest and verified ledger:

• Product/application team and release contributors.
• Screen and feature contributors.
• Reused components, utilities, and their contributors.
• Third-party acknowledgments and required license notices, kept distinct from internal recognition.

Offer an accessible, searchable credits list as the default. An optional movie-like
scroll can be a presentation mode, with pause, reduced-motion support, and no
requirement to wait through an animation. Credits must remain tied to the shipped
release, not silently change to the current dependency graph.

Catalog and Portfolio Experience

Component page: guidance, versions, credits, authorized consumers, compositions,
usage trends, feedback themes, fixes, and maintenance status. Distinguish
"referenced by this build" from "observed in use."

Application page: screen/workflow map, release dependencies, operational usage,
feedback, and a "View credits" entry for each release.

Contributor page: verified roles and shipped contributions, linked application
credits, maintained components, adoption reach, and improvements arising from feedback.
Make it possible to discover who solved a similar problem or whom to ask for help.

Internal community: follow components or contributors, bookmark components,
and give appreciation for specific contributions. Explain what follows notify
people about. Social endorsements are distinct from verified adoption and quality.

Apply authorization to these views and aggregates: even the existence of a private
consumer or product relationship can be sensitive. External/public profiles would
require a separate approval process, not an automatic extension of this pilot.

Metrics and Incentives

A Contributor Value Exchange

Make instrumentation a useful contribution experience, not another reporting
obligation. Offer a guided registration flow that connects an artifact and release
to verified contributors, approved event definitions, and feedback destinations.
Product managers and other non-coding roles can register their work, propose
questions, and subscribe to results without editing instrumentation code. A
developer integrates the approved signals; the application owner controls activation.

1. Register and credit the work. Propose roles with supporting evidence and
   confirm them through review. Make the artifact and its contributors discoverable.
2. Choose what to learn. Identify a small number of useful questions, such as
   whether developers can integrate it or users can complete its intended task.
   Reuse standard event definitions rather than creating events merely for volume.
3. Enable approved measurement and feedback. Connect the inventory, optional
   runtime signals, and both feedback paths through the host's controls.
4. Return value to contributors. Provide authorized adoption notifications,
   separate developer and end-user feedback summaries, and links to shipped
   releases that include their work. Offer configurable digests and subscriptions
   rather than notifying every credited person on every event.
5. Improve and recognize. Turn feedback into reviewed changes; add verified
   credits for the people who diagnosed, designed, implemented, documented, and
   validated the improvement. Show the resulting release and evidence in their
   portfolios without claiming that every observed outcome was caused by them.

For example, a product manager can receive credit for identifying a document
navigation need, a designer for its interaction model, and a developer for the
implementation. They can learn that another team adopted the component, hear
that its API was difficult to integrate, and separately learn whether end users
could find the right section. A subsequent fix can credit the reporting developer
and the team that delivered it.

Credit is not conditional on enabling telemetry. Verified work receives
attribution even when runtime collection is inappropriate or prohibited.
Instrumentation adds evidence of reach and a feedback connection; it does not
create authorship, award extra ownership to whoever added tracking, or entitle
contributors to another application's private data.

Interpreting the Signals

Signal	Useful Interpretation	Guardrail
Known consuming applications/releases	Breadth of reuse	Report inventory coverage and last-seen dates
Visible exposures and meaningful actions	Actual runtime reach	Show definitions, time windows, and sampling
Task outcomes and failure rates	Workflow effectiveness	Require application context and valid denominators
Ratings and feedback themes	Reported experience	Show response counts; account for self-selection
Feedback resolved and shipped	Responsiveness and improvement	Link evidence; do not reward closing issues without resolution
Verified credits and maintenance work	Contribution history	Recognize teams, reviewers, documentation, and quiet maintenance
Follows and appreciation	Community interest	Do not present as adoption or quality

Do not collapse these signals into a single contributor score. Do not equate
dependency fan-out with individual impact, or treat missing telemetry as zero use.
Avoid double-counting an application that consumes a utility through several paths.
Compare like contexts, report uncertainty, and do not claim causal improvement
from a before/after chart alone.

Recognize useful releases, adoption by another team, fixes to accessibility or
reliability, helpful guidance, and sustained maintenance. Avoid incentives for
component proliferation, unnecessary fragmentation, instrumentation inflation, or
shipping before a change is ready. Do not use the pilot as an employee performance
ranking or compensation input.

Privacy, Security, and Governance

Default runtime instrumentation to off. Host opt-in does not replace any required
end-user consent. Provide configuration, revocation, retention limits, and auditability.

Allowlist event fields. Exclude patient/record identifiers, field values, DOM text,
arbitrary URLs, and automatic session replay. Review event timing and metadata for
re-identification risk. Avoid persistent cross-application user tracking.

Keep screenshots, recordings, and free text separate from telemetry; they can
contain sensitive information even when metadata is safe. Define restricted
storage, attachment size/type limits, malware handling, retention, deletion, and
who can view or export feedback before enabling capture. Redaction is not a
guarantee that a recording is safe to share.

Authenticate ingestion, restrict application namespaces, rate-limit writes, and
validate schemas. Browser events are untrusted and can be spoofed; they must never
grant verified contribution credit automatically. Suppress small groups where
aggregates could reveal individual behavior.

Phased Delivery

1. Catalog and credits foundation. Agree on identifiers, taxonomy, credit roles,
   and access policy. Pilot with one willing application and a small set of
   components plus a utility, including artifacts from mieweb/ui and a separate
   private repository. Import a release inventory and manually verify credits.
   Exit: trace an application release to its artifacts and contributors, including
   at least one non-code contribution and an attribution correction. Verify private
   registration without uploading source, distinct identities for same-named
   artifacts, and no restricted relationships exposed to an unauthorized viewer.
2. Instrumentation pilot. Define a minimal event contract, a disabled-by-default
   client, and one adapter using the host's existing analytics infrastructure.
   Exit: distinguish inventory from runtime use, document sampling/coverage, test
   remount deduplication, and demonstrate no network activity when disabled.
   Agree on bundle, CPU, and network budgets and measure against them.
3. Feedback pilot. Add text and manual attachments first, then screenshot and
   video capture after privacy review. Exit: permission denial, unsupported browsers,
   preview/removal, submission failures, and retention controls are tested; trace
   developer-consumer and end-user feedback separately through triage to a released
   improvement, with authorized updates reaching subscribed contributors.
4. Credits and portfolios. Generate release-specific credits and contributor
   pages from verified data; add internal follows and appreciation. Exit: credits
   match a known release, respect access boundaries, and are accessible without animation.
   Include a product manager or other non-coding contributor in the pilot and
   verify that they can register evidence, receive credit, and subscribe to feedback
   without changing code. Collect whether participants found the resulting credit
   and feedback useful enough to instrument their next contribution voluntarily.
5. Lifecycle and replacement pilot. Register an old component and a beta
   successor in one workflow. Test a voluntary preview with persisted preferences,
   explicit opt-back reasons, and an operational rollback. Verify offer, assignment,
   exposure, and switch counts against known scenarios, including missing telemetry.
   If the population and risk permit a randomized A/B test, preregister its analysis
   and validate stable assignment and crossover handling. Otherwise label the trial
   observational. Exit: document a promotion, revision, or stop decision, with no
   requirement that the replacement win, and test the controls with keyboard users.
6. Expand based on evidence. Add applications and instrument only useful signals.
   Review catalog usefulness, maintenance cost, data quality, privacy, and incentive
   effects before expanding scope. Do not assume every primitive needs tracking.

Ownership and Decisions

• Participating repository maintainers: artifact metadata, contribution policy,
  event semantics, credit review, and approved sharing for their repositories.
• Application teams: inventory accuracy, workflow context, opt-in, and feedback handling.
• Product owners and experiment leads: hypotheses, rollout eligibility,
  outcome definitions, experiment analysis, and launch/rollback decisions with maintainers.
• Developer experience/platform: shared schema, registry, repository connectors,
  ingestion, adapters, authorization, and release integration.
• Design/research and privacy/security: feedback quality, capture policy, and access review.
• Contributors and reviewers: credit verification and correction.

Before implementation, select the pilot application, event backend, registry
hosting, identity source, credit approvers, retention periods, and initial success
criteria. Decide which adoption details may be visible company-wide and which
remain product-team-only. Choose whether the application credits list lives in
the product, an internal portal, or both.

The first deliverable should be a small, credible example: one shipped application
release with a dependency map, verified credits, and a few useful usage signals.
That establishes the evidence needed for a contributor portfolio before investing
in a company-wide social or analytics platform.