Design Award Search

Design Award Search

Purpose

Retrieve a small, high-precision set of verified award-winning designs. Keep the functional design category as a mandatory boundary, then search separately across eight relevance dimensions. Search public official sources at request time. Do not connect to, package, or depend on a private award database.

Scope Boundary

• Identify the user's canonical design category.
• Search selected relevance dimensions independently.
• Verify award identity, year, category, relation evidence, and official URL.
• Explain exactly which dimension makes each result relevant.
• Stop after retrieval. Do not score the design, predict winning probability, recommend changes, or select an award to enter.

User Interaction Contract

Accept a project description, image set, PDF, project page, or brief. Accept optional dimensions, award sources, years, and result count.

Require enough information to identify the object or service and its primary function. If the primary function remains ambiguous, ask exactly one short question: What is the design's primary function and who uses it? Otherwise state reasonable assumptions and continue.

When the user does not select dimensions, use balanced mode across every dimension supported by the supplied evidence. Use user images to infer physical-form and visual-language terms. If no image is supplied, do not activate visual-language relevance unless the user supplies explicit visual descriptors.

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

Project: {name or object}
Primary function: {problem solved or job performed}
Target user: {optional}
Use context: {optional}
Relevance dimensions: {all or selected dimensions}
Preferences: {optional award sources, years, and result count}

Retrieval Workflow

1. Build the profile

Read ../design-judge-shared/category-taxonomy.md and references/relevance-dimensions.md. Extract:

• canonical and adjacent categories;
• designed object or service;
• problem and target user;
• primary function;
• sensing technology;
• intervention mechanism;
• physical form and wear mode;
• use context and workflow;
• system components and information flow;
• visible form and CMF descriptors;
• source, year, dimension, and result-count constraints.

Classify by primary function before appearance. Keep physical form and visual language separate.

2. Select dimensions

Use these eight dimension keys:

1. problem-user
2. core-function
3. sensing-technology
4. intervention-mechanism
5. physical-form
6. use-context
7. system-architecture
8. visual-language

Search only user-selected dimensions. Otherwise activate every dimension supported by the input and use balanced mode.

3. Generate official-source queries

Read ../design-judge-shared/source-registry.md. Use scripts/build_search_queries.py when a shell is available. Translate profile terms into concise English first.

Example:

python scripts/build_search_queries.py `
  --category "Medical and Health" `
  --function "detect stress and prevent relapse" `
  --object "wearable health monitor" `
  --problem "alcohol use disorder relapse" `
  --user "people in addiction recovery" `
  --sensing "ECG HRV stress detection" `
  --intervention "haptic paced breathing biofeedback" `
  --form "adhesive chest patch" `
  --context "daily out-of-clinic high-risk moments" `
  --system "wearable sensor app personalized feedback" `
  --visual "discreet soft white blue medical wearable"

Execute dimension queries progressively. Stop searching a dimension after its target quota has enough verified candidates. Use official gallery search when available; otherwise use site-restricted discovery queries.

For visual-language retrieval, first build a visual-review pool of up to five same-category candidates found through every active dimension. Use visual-specific queries only when that pool is too small. Keep visual queries short: combine the designed object, physical form, and two or three unquoted visual descriptors. A domain-restricted image search may discover candidates, but only official project-page images can verify them. Do not use visual similarity outside the canonical or declared adjacent category.

4. Verify candidates

Open every official project page. Use scripts/verify_official_urls.py to reject unsupported domains and paths.

Verify:

• winner or officially recognized status;
• award organization and year;
• project identity and stable URL;
• same or declared adjacent canonical category;
• explicit evidence for the assigned primary relation.

Treat search snippets as discovery evidence only. For visual-language matches, inspect accessible official images directly; never infer visual similarity from text alone.

Before opening a full browser page, probe the visual-review pool with scripts/verify_visual_evidence.py. The script validates the project URL, extracts hero, thumbnail, lazy-load, and srcset image URLs from the official page, restricts assets to allowlisted official hosts, and fetches each image with the project page as Referer. It never prints image payloads. Its default mode keeps pixels in memory; use --review-dir only when the available visual tool requires a local path.

Example:

python scripts/verify_visual_evidence.py `
  --request-timeout 5 `
  --candidate-timeout 12 `
  --total-timeout 60 `
  --max-images 3 `
  --progress text `
  "https://www.red-dot.org/project/example-123" `
  "https://ifdesign.com/en/winner-ranking/project/example/456"

Treat Official image accessible as an acquisition result only. It remains Pending visual inspection until a visual-capable tool directly inspects the official pixels. Never turn accessibility, metadata, alt text, or official prose into Verified visual evidence.

When the visual tool accepts only local paths, create a new session-scoped handoff directory:

python scripts/verify_visual_evidence.py `
  --review-dir "{new non-existent temporary directory}" `
  --request-timeout 5 `
  --candidate-timeout 12 `
  --total-timeout 60 `
  --max-images 3 `
  "https://www.red-dot.org/project/example-123"

Call the local-image inspection tool on every returned visual_handoff.review_path needed for comparison. Inspect the user image pixels and official image pixels in the same task. Then clean the returned handoff directory, including after an inspection error:

python scripts/cleanup_visual_review.py "{review_handoff.directory}"

Do not create the handoff inside a repository-tracked directory. Do not reuse it in another task. If cleanup is refused, report the exact reason and resolve it before creating another handoff.

Verify visual candidates in this order:

1. Run the probe and use its returned official image URL with a visual-capable tool that can inspect remote images directly.
2. If the visual tool accepts only local paths, rerun with --review-dir, inspect the returned visual_handoff.review_path, and clean the directory in the same task.
3. If neither asset path works, open the official project page after DOMContentLoaded and inspect its visible hero or gallery image; do not wait for networkidle.
4. Try at most one official page-hosted thumbnail and one official image link.
5. If image acquisition fails, record Candidate - image inaccessible with the probe reason code. If acquisition succeeds but no visual tool observes the pixels, keep Pending visual inspection - visual_tool_unavailable; never call it image inaccessible.

Emit progress when each visual candidate starts, when an asset attempt begins, and when the candidate completes. Use a five-second request timeout, a twelve-second candidate budget, and a sixty-second visual-stage budget unless the user asks otherwise. Do not let one inaccessible image block the remaining candidates or the other seven dimensions.

Compare only observable silhouette, proportion, color and material, surface treatment, and medical or low-stigma expression. Record at least two paired attributes that state what is visible in the user image and what is visible in the official image. A generic statement such as both look minimal does not qualify. Follow the states and comparison record in references/retrieval-policy.md.