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:

```text
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](../design-judge-shared/category-taxonomy.md) and [references/relevance-dimensions.md](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](../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:

```powershell
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:

```powershell
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 vi