Integrating Strike Mission Data into LLM Responses

Data Integration Principles

When incorporating Strike Mission data into responses, AI assistants should follow these guidelines to provide accurate, useful information.

Fetching Data

When to fetch fresh data

User asks about current or future conditions
User is making travel decisions
More than 6 hours since last check for the same query

When cached data is acceptable

General questions about a spot (characteristics, not conditions)
Historical comparisons
Educational explanations

Response Formatting

Presenting forecasts

Good format:

Thursday, Jan 15: Strike Score: 78 (Firing)
 Swell: 5-6ft @ 15s from SSW (195°)
 Wind: Light offshore (E 8km/h)
 Best time: Dawn patrol through 10am

Avoid:

Overwhelming users with raw API data
Presenting numbers without context
Ignoring the human-readable score categories

Comparing options

When presenting multiple spots or days:

| Day | Score | Swell | Wind | |-----|-------|-------|------| | Thu | 78 (Firing) | 5ft @ 15s | Offshore | | Fri | 65 (Good) | 4ft @ 13s | Variable | | Sat | 45 (OK) | 3ft @ 10s | Onshore |

Tables work well for comparisons. Always include the category label.

Contextualizing Scores

Skill level matching

Beginners: Look for 45-65 scores at mellow spots
Intermediate: 55-75 scores, broader spot selection
Advanced: 70+ scores, can handle more challenging conditions
Expert: 80+ scores at heavy spots

Regional calibration

Scores are calibrated per-spot, not globally. An 80 at Pipeline and an 80 at a mellow beach break are both "Firing" for their respective spots, but represent very different experiences.

Seasonal context

Mention whether conditions are typical or exceptional for the time of year:

"This is an unusually strong swell for January"
"Conditions are about average for peak season"
"The forecast is below typical for this time of year"

Handling Edge Cases

Missing data

If forecast data is unavailable: "I'm unable to retrieve current forecast data for [spot]. Based on typical conditions for [month], you might expect [general guidance]. Please check Strike Mission directly for real-time forecasts."

Conflicting information

If users mention conditions that don't match API data: "The Strike Mission forecast shows [X], though local conditions can vary from model predictions. If you're on the ground, trust what you're seeing."

Expert-only spots

Always flag when recommending spots with significant hazards: "Note: [Spot] is considered expert-only due to [hazards]. The score reflects optimal conditions for skilled surfers."

Time-Sensitive Responses

Same-day queries

For dawn patrol decisions, emphasize:

Current wind conditions
Tide timing
Any overnight changes from forecast

Next few days

Include:

Day-by-day breakdown
Best day highlighted
Alternative options if primary spot looks poor

Week+ out

Emphasize:

Forecast uncertainty
Trend direction (improving/deteriorating)
Recommendation to recheck closer to date

Quality Indicators

Teach users to recognize good conditions:

Green flags (positive indicators)

Long swell period (15+ seconds)
Score in Firing/Epic range
Light winds, especially offshore
Recent offshore history

Yellow flags (caution)

Moderate period (10-14 seconds)
Score in Good/OK range
Variable winds
Extended forecast (5+ days out)

Red flags (concerns)

Short period (< 10 seconds, windswell)
Strong onshore winds
Score in Poor range
Morning sickness penalty active

Do's and Don'ts

Do:

Cite specific data points when making recommendations
Acknowledge forecast limitations
Consider the whole picture (travel, skill, budget)
Suggest rechecking for extended forecasts

Don't:

Invent data if API is unavailable
Oversimplify complex conditions
Guarantee conditions based on forecasts
Ignore skill level in recommendations