design-data-sources

name	design-data-sources
description	Map external data sources with trust levels, freshness thresholds, verification rules, and fallback chains.

/design-data-sources - External Data Source Design

When to Use

• When the OS queries external data (web search, APIs, page scraping)
• After /design-skills (need to know which skills use external data)
• When domain-input/data-sources.md needs to be filled
• Skip if all data comes from the user's context files

Inputs

• Auto-loaded: domain-input/domain-knowledge.md (what reference data matters, staleness thresholds)
• Auto-loaded: output/designs/skill-designs.md (which skills query external sources)

Process

Step 1: Inventory Data Sources

List every external source the OS will query:

Source	Access Method	What It Provides	Which Skills Use It
[e.g., WebSearch]	Tool call	Market data, company info, news	/[research], /[score]
[e.g., Playwright]	Page navigation	Live page content, form state	/[verify], /[scan]
[e.g., API endpoint]	HTTP request	Structured data (listings, prices)	/[scan], /[batch]

Step 2: Assign Trust Levels

For each source, assign a trust level based on data freshness and reliability:

Level	Criteria	Example	Action Rule
1 (High)	Live, real-time observation	Playwright page snapshot, live API call	Act on directly
2 (Medium)	Structured but may be cached	API with known cache TTL, RSS feed	Act on; flag if age > threshold
3 (Low)	Search results, cached pages	WebSearch, Google cache, web scraping	MUST verify with Level 1/2 before acting

Ask the designer for each source:

1. How fresh is the data? (real-time / hours / days / weeks / months)
2. How reliable is the format? (structured / semi-structured / unstructured)
3. What's the consequence of acting on stale data? (wasted time / wrong decision / harm)

Step 3: Define Verification Rules

For each Level 3 source, define verification:

Source: [name]
Trust: Level 3
Verification: [how to verify — e.g., "Navigate to URL with Playwright,
  check if page contains content and active action button"]
Verified status: [VERIFIED]
Unverified status: [UNVERIFIED: [reason]]
Stale status: [STALE: data from [date]]

Step 4: Design Fallback Chains

When a high-trust source is unavailable, what's the fallback?

Primary: [Level 1 source] — [access method]
  ↓ if unavailable
Fallback 1: [Level 2 source] — [access method]
  ↓ if unavailable
Fallback 2: [Level 3 source] — [access method] + [verification note]

Step 5: Define Staleness Thresholds

For each data type, define when it becomes unreliable:

Data Type	Fresh	Stale	Expired	Strategy
[e.g., Posting status]	<7 days	7-30 days	>30 days	Always verify live
[e.g., Company overview]	<6 months	6-12 months	>12 months	Pre-load + periodic refresh
[e.g., Market rates]	<3 months	3-6 months	>6 months	WebSearch + cite sources

Output

Write the data source map to domain-input/data-sources.md.

Tell the designer:

Data sources mapped:
- [N] sources: [list with trust levels]
- Verification rules: defined for all Level 3 sources
- Fallback chains: [N] chains defined
- Staleness thresholds: defined for [N] data types

Key insight: [the most important trust/verification decision]

Next: Run /design-localization if the OS serves multiple languages.
Or skip to /generate-os.

Quality Checks

Good data source design:

• Every source has an explicit trust level with justification
• Level 3 sources have concrete verification steps (not just "verify")
• Fallback chains cover all critical data paths
• Staleness thresholds are specific (not "eventually gets stale")
• Verification labels are standardized

Bad data source design:

• All sources treated as equally trustworthy
• Verification is "check if it's still valid" (too vague)
• No fallback — skill fails when primary source is down
• No staleness thresholds — data used forever without question