Apiary Atlas

Inspiration

Beekeeping migration decisions are complex. A beekeeper must consider the number of available colonies, potential destinations, vegetation conditions, weather forecasts, bee-health restrictions and practical permissions.

A green satellite image alone does not prove that flowers are blooming, nectar is available, or moving bees is safe.

Apiary Atlas was inspired by real beekeeping challenges and a simple question: What if beekeepers could bring their own apiary information, real environmental evidence and conversational planning into one trustworthy workspace?

Our goal is to help beekeepers make more informed decisions while keeping humans in full control.

What it does

Apiary Atlas is a beekeeping management and migration-planning platform built around three principles:

PLAN — Analyze locations, compare environmental evidence and prepare migration plans.

PROTECT — Preserve colony records, highlight missing health information and avoid treating incomplete evidence as permission to move bees.

COORDINATE — Connect beekeepers, their records and future association and bee-health workflows.

The hackathon demonstration follows a practical scenario:

A beekeeper signs into a local test workspace containing a synthetic apiary with 45 colonies. The user compares two locations near Hőgyész, Hungary, using genuine Sentinel-2 satellite imagery, quality-masked NDVI vegetation indicators and MET Norway weather forecasts.

An Alexa-style text conversation, connected to the application’s actual services and MCP tools, helps the user compare the locations, select a destination, change colony counts, adjust planning dates and understand information that is missing.

The user then previews a migration plan. Nothing is saved automatically.

Only after reviewing the destination and explicitly confirming the action does the application save a persistent metadata-only migration DRAFT.

After restarting the application, the DRAFT can be reopened. All 45 physical colonies remain unchanged: saving a plan does not reserve or move bees.

How we built it

We extended an existing Apiary Atlas application foundation with an integrated competition workflow.The application uses a modular JavaScript and TypeScript interface, shared application services, current-account authorization checks and a persistent local test store.Six Model Context Protocol (MCP) tools connect the planning workflow with apiary information, environmental reports and migration previews.Our deterministic English Alexa-style web simulation uses those real application tools. It is not a native Alexa session, an Echo-device integration or live generative-model inference.For environmental evidence, we integrated:Element 84 Earth Search: real Sentinel-2 imagery, controlled Cloud Optimized GeoTIFF reads and quality-masked NDVI calculations.MET Norway: genuine point weather forecasts with temperature, wind and precipitation data.Validated provenance: acquisition timestamps, retrieval timestamps, forecast validity, cloud information and clear unavailable states.The application also includes an earlier AWS foundation using Amazon Cognito, API Gateway, AWS Lambda, DynamoDB and CloudFormation. That historical deployed foundation is distinct from the current locally demonstrated competition application.During the hackathon development period, we strengthened the shared MCP/conversation workflow, integrated and verified the real environmental providers, repaired map-to-assistant context handling, introduced renewable bounded data retrieval and created reproducible judge-testing instructions.We do not claim that every Apiary Atlas module was created from scratch during this hackathon.

Challenges we ran into

Reliable satellite processing. We needed to retrieve actual satellite pixels without downloading unnecessarily large datasets, validate their geographic coverage and distinguish cloud-affected pixels from usable vegetation observations.

Data freshness. Satellite acquisition time is not the same as download time. Weather forecast validity is not the same as a migration date. We built explicit freshness, caching and unavailable-data handling rather than silently reusing old information as current.

Conversation consistency. The assistant must retain the correct source apiary, candidate order, selected destination, analysis radius, dates and colony count—even when the map changes or a previous response arrives late.

Safe persistence. Previewing a plan must not mutate colony inventory. We implemented a separate human-confirmation step and verified the saved DRAFT after an application restart.

Truthful demonstrations. We carefully distinguish genuine public environmental observations, synthetic beekeeper records, recorded evidence and functionality that has not been deployed or verified.

Accomplishments that we're proud of

The current competition application successfully retrieved and displayed genuine Sentinel-2 RGB imagery, NDVI and MET Norway forecasts for two tested public locations within a 1 km analysis radius.

Its map, MCP tools and conversational interface used consistent environmental information.

The verified end-to-end workflow created and reopened a migration DRAFT while preserving the original 45-colony inventory.

The application completed 4,136 development tests. Separate clean-installation checks, provider-budget tests and actual browser workflows also passed.

We also prepared an independent, reproducible competition repository with documented startup instructions and a demonstration video based on actual application evidence.

What we learned

The most important lesson was that trustworthy environmental software must explain uncertainty—not hide it.

A technically successful satellite request can still return an older acquisition. A weather forecast may not cover the selected planning dates. An incomplete health or legal dataset must not be replaced by a confident guess.

We learned that a conversational interface becomes significantly more useful when it shares the real application’s services and authorization rules instead of operating as a disconnected demonstration.

And we reinforced a principle that matters in beekeeping: the application can support the decision, but the beekeeper must remain in control.

What's next for Apiary Atlas

Our longer-term vision is a global Apiary Atlas platform connecting migration planning, bee-health workflows, local and national beekeeping associations, secure colony records and coordinated environmental information.

Next steps include broader verified satellite coverage, additional trusted regional datasets, more complete mobile experiences, production deployment and future native conversational integrations.

The present competition implementation is a tested local application, not a completed worldwide production deployment.

Demo, source and data attribution

Demo video: https://youtu.be/WbexHysF4LA

Competition source: https://github.com/ridi0627-boop/apiary-atlas-amazon-hackathon-2026

The source repository is private, with access arranged for competition reviewers. Its README contains the installation instructions, supported test locations and limitations.

The edited demonstration uses genuine environmental evidence retrieved on October 22, 2026. The Sentinel-2 acquisition occurred on October 20, 2026. The verified satellite scope is limited to two public points near Hőgyész, Hungary, at 1 km radius. The video clearly identifies recorded evidence rather than claiming a new uninterrupted live session.

Contains modified Copernicus Sentinel data 2026, accessed through Element 84 Earth Search.

https://element84.com/earth-search/

https://sentinels.copernicus.eu/documents/247904/690755/Sentinel_Data_Legal_Notice

Data from MET Norway, under CC BY 4.0.

https://api.met.no/doc/TermsOfService

Neither NDVI nor weather information proves flowering, nectar availability, disease freedom or legal permission for migration.

Apiary Atlas — Better evidence. Safer planning. Beekeeper-controlled decisions.