Design Award Match

Design Award Match

Purpose

Identify the most defensible award, program, track, and category for a design project. Treat fit scores as transparent decision aids, never as probabilities of winning.

Scope

• Extract decision-relevant project facts.
• Pre-filter the configured award allowlist with stable eligibility gates.
• Verify all dynamic requirements on current official pages.
• Compare project evidence with published criteria and observable winner trends.
• Score, rank, and explain strategic fit.
• Stop after recommendation; do not audit every submission file or redesign the project.

Use $design-award-search for verified same-category winners. Route file format, size, naming, declarations, and upload completeness to $design-submission-check.

Input Contract

Accept a brief, images, PDF, portfolio page, or structured JSON. Extract or request only facts that can change the recommendation:

• primary function, target user, and use context;
• innovation and supporting evidence;
• project state and completion, launch, or release date;
• applicant type, student status, country or region;
• candidate awards, intended cycle, budget, and geographic constraints.

Use the canonical values in references/category-crosswalk.json. If the primary function is unclear, ask one short question. If an eligibility fact is missing, continue with Eligibility: Unknown; never assume a pass.

Offer this template when the user asks how to use the skill:

Project: {name and one-sentence description}
Primary function: {job performed or problem solved}
Target user / context: {optional}
Innovation and evidence: {optional}
Development status / launch date: {optional}
Applicant: {student, individual, studio, company; country/region}
Candidate awards: {optional; omit to search the supported allowlist}
Submission cycle / constraints: {optional year, region, budget}

Workflow

1. Build the project profile

Read ../design-judge-shared/category-taxonomy.md and references/category-crosswalk.json. Classify by primary function before appearance. Record one canonical category, no more than two adjacent categories, project state, applicant type, evidence, timing, and constraints. Label material inferences.

For command-line pre-filtering, prepare JSON like examples/project-profile.example.json.

2. Validate and load the supported award set

Read references/awards/index.json and references/award-profile-guide.md. Analyze only the programs in the allowlist. Treat Red Dot Product and Red Dot Design Concept as separate programs. If a requested award is absent, return Unsupported rather than researching and silently adding it.

When a shell is available, validate configuration before analysis:

python scripts/validate_award_profiles.py --pretty

Build a focused candidate set, normally three to five routes:

python scripts/build_candidate_set.py examples/project-profile.example.json --limit 5 --pretty

Use --award repeatedly to restrict candidates. Award ids and declared aliases are accepted.

3. Apply stable gates

Use each selected profile's routes, required_project_fields, and stable_constraints. When needed, run:

python scripts/filter_eligible_awards.py examples/project-profile.example.json --include-ineligible --pretty

Assign:

• Eligible: all stable and current official gates pass.
• Ineligible: a confirmed rule excludes the entry.
• Unknown: a project fact is missing or any live gate remains unchecked.

Exclude Ineligible routes from ranking but state the exact reason. Keep Unknown routes conditional.

4. Verify dynamic rules live

Read only the selected award profiles under references/awards/. For every dynamic_gate and relevant dynamic_field, verify current official pages at request time:

• cycle status and absolute deadlines;
• applicant, geography, age, enrollment, and graduation rules;
• completion, publication, distribution, or launch windows;
• exact track and category labels;
• current judging criteria;
• enough material and physical-delivery requirements to assess feasibility;
• fees and mandatory winner obligations when they affect priority.

Record direct URL and checked on: YYYY-MM-DD. Profile category hints are routing aids only; current official labels control. Never rely on stored dates, fees, category numbers, or remembered requirements.

5. Compare criteria and winner evidence

Read references/evidence-policy.md and references/criteria-crosswalk.json. Display each award's official criterion name; use normalized dimensions only for cross-award comparison.

Map every criterion to concrete project evidence using Strong, Partial, Weak, or Unknown. Do not award alignment for generic claims.

Past winners are optional evidence. Use $design-award-search or a small verified official-source sample. State sample size, years, category, and limitations. Describe observable past-winner trends, never hidden jury preferences.