LEO Satellite Coverage Risk Analysis

• Your agent uses a series of tools to search for data sources, downloads them, and analyzes them.
• Your agent asks for the user's location (coordinates or polygon), runs the analysis, and determines whether that location has enough TCC visibility.
• Your agent asks for the user's location and returns the potential locations in an {X}m buffer around it that have better TCC visibility.

1. What physical conditions cause service interruptions?
2. What does the dish need from its environment to maintain connectivity?
3. What publicly available geospatial datasets would let you model these risks at scale?
4. What can't you model remotely, and why?

Design and build a system that orchestrates the workflow: ingestion, analysis, validation, and reporting.

• Architecture diagram (Mermaid or equivalent) showing agents, their tools, communication flow, and where humans can intervene.
• Clear agent boundaries. Use LLMs for reasoning. If using multiple agents, each agent has a defined scope and tool access.
• Clear tool definitions. The tools and services used by each agent need to be defined clearly, with their schemas and definitions.
• State management. How context and results pass between agents.
• Failure handling. What happens when data is bad or results are anomalous.

Document how you went from the install guide to your methodology:

• How did you translate the guide's physical requirements into your analytical approach?
• Why this approach over alternatives?
• How did you define "at-risk," and how would you explain it to a non-technical state broadband officer?
• What are the known limitations of your remote analysis vs. an on-site assessment?

• What datasets did you source and why? Link each to a specific obstruction factor from the install guide.
• What quality issues did you find in the provided locations data? How did you handle them?
• What can't be modeled with public data?

• Document your core findings (e.g., what percentage of locations are at risk?).
• Provide a simple visualization (static or dynamic) to explain your finding.

If you integrated AI agents in your workflow, design (and optionally implement) an observability layer:

• Per-agent metrics: task success rate, latency, token usage / estimated cost at scale.
• Output quality metrics (e.g., % of locations scored, anomaly detection accuracy).
• How would you detect drift if the pipeline runs on updated data next quarter?
• Tool-call metrics, for example how accurately your agent calls the right tool at the right time.

Locally-hosted interactive map (Folium, Streamlit + PyDeck, Kepler.gl, etc.):

• Locations color-coded by risk level.
• Environmental overlays.
• Click/hover detail and filtering by state, county, or risk tier.
• Report the AI vibe-coding platform you used, if any.

• Every AI tool you used (Claude, Copilot, Cursor, Codex, v0, etc.).
• What you used each tool for.
• 2–3 cases where you diverged from AI-generated output and why.

• Walk through a technical decision and the alternatives you considered.
• Respond to a scenario change ("What if we add a new obstruction factor?").
• Debug a suspicious result from your own output.
• Explain what breaks at 100x scale.

• GitHub repo (public, or invite-shared with @brookefzy, @am2222, and @tgibbons).
• README.md with a decision log (Decision → Alternatives → Reasoning → What you'd revisit).
• AI_TOOLS.md
• /docs — architecture diagram, analysis rationale.
• /src — pipeline code, agent definitions.
• 5-minute Loom walkthrough (optional, encouraged).