Cover Image
Imagine a team generating several plausible components before review, each subtly different from the system. AI coding tools can increase the drafts entering an intake queue, but the volume and review effort depend on your team. The workflow below is a proposed contribution model, not a measured account of every design-system team.
The core shift: the system team stops being the authors of components and becomes the operators of intake. Product teams and their agents produce. The model decides what gets adopted into the system, what gets adapted back to the source team with fixes, and what gets rejected outright. Most output should exit through adapt or reject. A model where everything gets adopted is a junk drawer with a review process.
The new volume problem: every team ships components now
Codegen changed the supply curve without changing demand. Products still need the same set of patterns: buttons, cards, tables, dialogs, form controls with consistent behavior. But the cost of producing a near miss collapsed to the price of a prompt, so near misses multiply. Each one looks right in isolation and diverges in the details: a spacing value off by four pixels, a focus state the generator invented, a color one step from the token ramp.
Human review cannot scale to this supply. A queue of forty generated components could overwhelm a three-person team, depending on complexity and its other work, and pretending otherwise produces rubber stamp approvals that admit rot. The contribution model must therefore do most of its sorting without humans: machine checks first, peer review second, system team review only for what survives both. Review rigor concentrates where it matters instead of spreading thin over everything.
This pairs with the token story. Our token governance guide covers keeping values consistent; contributions are where components built on those tokens enter the system. Tokens without intake discipline rot from the component side. Intake without token discipline admits components with nowhere consistent to land. Run both.
Three fates: adopt, adapt, reject
Every submitted component gets one of three verdicts, decided fast, with written reasons. Speed matters because a slow queue teaches teams to fork privately instead of contributing. Target days, not sprints.
Adopt means the component enters the system as maintained code. The bar is high on purpose: genuine reuse across at least two teams, full token compliance, complete states, accessibility passes, documentation the source team writes. Adoption is a promise of maintenance, so the question is never "is this good" but "will we maintain this for two years." Most submissions should fail that question. That is healthy.
Adapt means close but not shippable: the right idea with fixable gaps. The verdict ships back with a specific list (token violations by line, missing states, naming fixes) and the source team resubmits after repair. Adapt is intended to be a useful feedback path: each cycle tells the source team what the system expects and can inform its agent configuration. Good adapt feedback converges teams within a few cycles. Vague adapt feedback ("not quite system quality") teaches nothing and burns goodwill.
Reject means wrong layer or wrong scope: a single use component dressed as a pattern, a duplicate of an existing primitive with different spacing, a clever abstraction nobody else will understand. Reject kindly but plainly, with the pointer to what already covers the need. Our pattern library vs design system piece helps teams tell the difference before submitting: reference galleries inspire, systems standardize, and most generated output belongs in the first category.
Tiered review rigor: machine gate, peer review, system review
Three tiers keep human attention for the decisions only humans can make.
Automated checks run first on every submission; people still need to maintain the checks and investigate false positives. Token compliance (every value traceable to a token), schema validity, naming convention match, test presence, accessibility lint, visual regression against nearest system sibling. JSON Schema documentation explains how to define and validate data constraints. In this proposed pipeline, failed schema validation blocks a submission. Return submissions that fail required checks with actionable error lists; do not target an arbitrary rejection percentage. A submission that cannot pass mechanical checks does not deserve human eyes.
Peer review comes second: one designer and one engineer from outside the source team, checking intent and integration rather than mechanics. Does this solve a shared problem or a local one. Does the API fit how other components behave. Would you reach for this next month. Peers catch the duplicates and the over fitted abstractions that machines cannot see. Keep the review lightweight and time boxed; peers are doing the system a favor, and slow reviews kill volunteer energy.
System review is the final gate and the rarest: the core team confirms maintenance commitment, documentation quality, and roadmap fit. Only adopt candidates reach this tier. Because the first two tiers filtered the volume, the core team sees a handful of strong candidates per cycle instead of a flood. Their yes means something because their no earlier would have meant something too.
Config driven consistency tooling shrinks all three tiers. UI-stack style skills that bind codegen agents to your tokens, spacing, and component APIs can supply the intended constraints, but generated submissions still need validation. The contribution model and the agent configuration are two halves of one loop: the model defines expectations, the agent config encodes them, submissions can be checked against the same expectations. Track whether clearer configuration reduces recurring review findings.
Ownership after admission: source team owns, system team curates
The question that kills federated models arrives after adoption: who fixes this component when it breaks. Answer it in writing before the first adoption, because the default (everyone assumes the system team owns everything) collapses under AI scale.
The federated answer, surveyed in Sparkbox's comparison of design system ownership models, splits ownership from curation. The source team owns their contributed component: bug fixes, updates, answering consumer questions. The system team curates: sets standards, runs the gates, removes components that rot, and holds the right to eject. Ownership scales because it distributes. Curation scales because it only touches exceptions.
Make this concrete with three artifacts per adopted component: a named owning team with a contact, a maintenance SLA in plain language (response time for bugs, update cadence for dependencies), and an ejection policy trigger (unowned for two quarters, failing checks unfixed, superseded by a better primitive). Components without owners drift exactly like tokens without owners, and Sparkbox's long-term support guide covers the rituals that keep ownership real: clear feedback channels and intake, ambassador programs, regular demos, and scheduled maintenance reviews.
The RFC in the codegen era: constraints in, components out
The traditional component RFC asked teams to propose before building. In the codegen era, flip the emphasis: the RFC carries constraints into the agent, and the submission carries the component out for sorting.
A modern proposal is short. Problem statement and evidence of reuse (two consuming teams named). Constraint bundle: tokens, APIs, and patterns the agent must use, ideally as a config file the machine reads rather than prose it interprets. Success criteria the machine gate can check. That is enough to start generating, because generation is cheap and the gates do the filtering.
Review the constraint bundle, not just the output. When submissions repeatedly fail the machine gate on the same checks, the fix is upstream in the shared agent configuration, not downstream in feedback comments. Each adapt cycle should improve the config so the next team never makes that mistake. The contribution model compounds: early months feel heavy with feedback, later work may improve as maintained instructions and checks become clearer. Updating configuration does not itself train the underlying model.
Metrics that prove the model works
A contribution model without metrics drifts into theater. Track five numbers and review them quarterly.
Submission volume and fate split: how many submitted, what share adopted, adapted, rejected. Expect adapt to dominate early and shrink as agent configs improve. A rising reject rate means teams misunderstand scope; fix with guidance, not gates.
Time to verdict per tier: machine gate in minutes, peer review in days, system review in one cycle. Slow verdicts push teams to private forks, which is the failure mode the model exists to prevent.
Gate pass rate on first submission: one indicator of configuration and submission quality. Interpret it alongside changes in task difficulty, contributors, and gate coverage.
Adopted component health: open bugs per component, owner responsiveness, usage counts across teams. Eject what rots. A system that never removes components is accumulating debt with ceremony.
Contributor retention: do teams submit twice. One time contributors who never return are telling you the process cost more than the reward. Interview them before you add more process.
Start with the machine gate and the three fates on one page. Add peer review when volume justifies it. Formalize ownership at the first adoption. The model grows with the supply it sorts, and the supply is only growing.
