Build a competency matrix that levels distinguish by scope, not by adjectives

Build a competency matrix for Product Design across IC2 through IC5, where each level within each skill dimension is distinguished by a concrete difference in scope or autonomy — not by inflating the same description with stronger adjectives at each level up.

SKILL DIMENSIONS TO INCLUDE
Problem framing, cross-functional influence, design system ownership, mentoring.

CURRENT VAGUE LANGUAGE TO REPLACE, IF ANY
Current IC3 and IC4 both say 'demonstrates strong design craft and collaborates well with engineering' with no other difference.

EXAMPLES OF ACTUAL WORK AT DIFFERENT LEVELS
An IC4 redesigned the checkout flow end-to-end across three squads with no senior oversight; an IC3 owns the empty-states pattern for one product area with weekly design review.

For each skill dimension, write a one- or two-sentence description per level that names a concrete difference: what kind of problem they handle (well-defined vs ambiguous), how much oversight is involved (reviewed before, reviewed after, none), and what scope of impact (their own work, their team's, multiple teams). Two adjacent levels should never be distinguishable only by intensity words like "strong," "excellent," or "advanced" applied to the same sentence — if you can't state a concrete difference in problem type, oversight, or scope between two levels, say so explicitly rather than inventing a fake distinction to fill the cell.

If current vague language was provided, rewrite each instance to show what it was actually failing to distinguish, and give the sharper replacement — treat this as a before/after pair so the reasoning is visible, not just the fix.

If real work examples were given, use them as calibration anchors: check that your level descriptions would actually sort those specific examples correctly, and flag if any example doesn't cleanly fit the level it was supposedly an example of, since that mismatch usually reveals the framework's boundary is drawn in the wrong place.

WHAT NOT TO DO
Do not produce a matrix where every cell reads as a template with only the adjective swapped ({dimension} at a {level} level requires {stronger word} skills) — that pattern indicates you haven't actually reasoned about what changes at each level and should be treated as a failed draft to redo, not a finished answer.

OUTPUT FORMAT
1. The matrix as a table: rows are skill dimensions, columns are levels, cells are the concrete level description.
2. If vague language was provided, a before/after table showing what was ambiguous and the sharper replacement.
3. If work examples were given, a note on whether each sorted cleanly into its expected level or revealed a boundary problem.