Hack The Weather 2026 is open to young climate innovators aged 18 -35.
Eligible participants include:
-
University and TVET students
-
Recent graduates
-
Developers and technologists
-
Data scientists and AI practitioners
-
Designers and creative professionals
-
Researchers
-
Entrepreneurs and aspiring founders
-
Environmental and climate innovators
-
Young community changemakers
Participants do not need to be students or climate specialists to participate.
Age RequirementParticipants must be 18β35 years old at the time of the hackathon.
2. Team Formation
Participants must compete in teams of 2β5 people.
Team Rules-
Each participant may belong to only one competing team.
-
Every team member must be registered for the hackathon.
-
Each team must designate one Team Lead.
-
Teams may be formed before or during the hackathon.
-
Every team member must make a meaningful contribution to the submitted project.
-
Teams may include participants from different institutions, disciplines, or backgrounds.
Each team must develop a technology-driven solution that addresses a real climate or environmental challenge.
The project must:
-
Address a clearly defined problem.
-
Make meaningful use of data from the Conduit@Empathy platform at Jomo Kenyatta University of Agriculture and Technology (JKUAT).
-
Include a functional prototype, proof of concept, or minimum viable product (MVP).
-
Demonstrate how the solution addresses the identified problem and provides value to a defined user, community, organisation, or other beneficiary.
Teams are free to define their own problem and are not required to select from a predefined problem statement.
4. Conduit Data RequirementUse of Conduit@Empathy data is mandatory.
Each project must demonstrate how Conduit data contributes to the solution.
Simply displaying Conduit data without using it meaningfully in the functionality, analysis, model, decision-making, or output of the solution does not satisfy this requirement.
Teams may combine Conduit data with other relevant datasets, including:
-
Satellite and Earth observation data
-
Historical weather or environmental data
-
Geospatial data
-
Public datasets
-
Government datasets
-
Open APIs
-
Other legally accessible datasets
Teams must identify and appropriately acknowledge all external data sources used.
5. TechnologyTeams are free to choose their technology stack.
Projects may use, but are not limited to:
-
Web and mobile technologies
-
Artificial intelligence (AI) and machine learning (ML)
-
Data science
-
Geographic information systems (GIS) and geospatial technologies
-
Satellite and Earth observation technologies
-
Internet of Things (IoT)
-
Cloud computing
-
Application programming interfaces (APIs)
-
Data visualisation
-
Predictive analytics
There is no requirement to use a specific programming language, framework, platform, or technology.
6. Development During the HackathonHack The Weather is a build challenge. Teams must complete substantial development work during the official hackathon period.
Participants may prepare before the hackathon by:
-
Researching the problem.
-
Exploring the Conduit platform.
-
Learning relevant technologies.
-
Setting up development environments.
-
Preparing development tools.
-
Reviewing publicly available datasets.
-
Creating basic project plans or wireframes.
Participants may also use existing open-source libraries, frameworks, and boilerplate code.
However, teams may not submit a pre-existing project as their hackathon project without substantial new development during the official hackathon period.
Pre-existing projects that have already been substantially developed before the hackathon are not eligible unless the organisers explicitly approve their use.
7. Use of Artificial IntelligenceArtificial intelligence (AI) tools are permitted.
Teams may use:
-
Generative AI
-
AI coding assistants
-
Machine learning models
-
AI APIs
-
Other AI development tools
Teams remain responsible for the final project and must understand and be able to explain the solution they submit.
Teams must disclose significant use of AI in their project submission where requested by the organisers or judges.
AI-generated code, content, data, or assets must comply with applicable licences, terms of service, and intellectual property requirements.
The use of AI does not exempt teams from being able to explain their project's architecture, implementation, data, or functionality.
8. Prototype RequirementEvery team must submit a working prototype, proof of concept, or MVP.
The prototype does not need to be production-ready but must demonstrate the core functionality of the proposed solution.
Static presentations, mock-ups, or concept-only submissions are not sufficient.
The prototype may be demonstrated through:
-
A live web application
-
A mobile application
-
An interactive prototype
-
A data dashboard
-
An AI or ML model
-
An API
-
A GIS application
-
An IoT demonstration
-
Another functional technology prototype
Each team must submit its project through the official Hack The Weather Devpost submission page before the published submission deadline.
Every submission must include:
-
A 3 - 5 minute demonstration video
-
A GitHub repository link
-
A comprehensive README.md file
-
The required project information on Devpost
Each team must submit a 3 - 5 minute video demonstrating its solution.
The video must show the solution in operation and explain how it addresses the identified problem.
The video should cover:
-
Problem - The problem being addressed and who is affected.
-
Solution - What the team built and how it works.
-
Conduit Data - How Conduit@Empathy data is used in the solution.
-
Demonstration - The key features and functionality of the prototype.
-
Technology - The main technologies, models, frameworks, or tools used.
-
Impact - The expected benefit or impact of the solution.
-
Future Development - How the solution could be developed further after the hackathon.
-
The video must be at least 3 minutes and no more than 5 minutes long.
-
The solution must be clearly visible and demonstrated.
-
Audio must be sufficiently clear for judges to understand the presentation.
-
The video must be accessible to the judging panel without requiring a paid account or special access.
-
The video link must be tested before submission.
-
The video must remain accessible throughout the judging period.
-
Screen recording with voice-over is acceptable.
-
Professional video production is not required.
-
All team members must appear in the video.
Teams may use any free screen recording or video-hosting platform.
Recommended options include:
-
Loom
-
OBS Studio
-
Google Meet
-
YouTube using an Unlisted video
-
Google Drive with appropriate sharing permissions
Teams are responsible for ensuring that the submitted video can be accessed by the judges.
Video production quality is not a judging criterion.
10. GitHub RepositoryEach team must provide a GitHub repository containing the project's source code and relevant project files.
The repository must:
-
Be accessible to the judging panel.
-
Contain the project's source code and relevant files.
-
Include a comprehensive README.md file.
-
Clearly identify the technologies and frameworks used.
-
Identify significant third-party libraries, APIs, datasets, and models used.
-
Identify the Conduit data used by the project.
-
Include appropriate attribution and licences where required.
The repository should be publicly accessible at the time of submission.
If a team has a legitimate reason why its repository cannot be public, the team must contact the organisers before the submission deadline for approval.
Repository DeadlineThe GitHub repository submitted through Devpost will be considered the team's official project repository for judging.
Teams must ensure that the repository reflects the final state of their project at the submission deadline.
Significant changes made after the submission deadline may not be considered during judging.
Teams are encouraged to commit their work regularly throughout the hackathon.
11. README RequirementsEvery project repository must contain a comprehensive README.md file.
The README should allow judges to understand the project without having to inspect the source code first.
At a minimum, the README must include:
Project NameThe project name and a brief description.
Problem StatementDescribe:
-
The problem being addressed.
-
Why the problem matters.
-
Who is affected.
Explain:
-
What the team built.
-
How the solution works.
-
How it addresses the identified problem.
Clearly explain:
-
Which Conduit@Empathy data was used.
-
Where the data is used in the solution.
-
How the data is processed, analysed, or visualised.
-
How the data contributes to the project's functionality.
List and briefly describe the main features of the solution.
Technology StackList the main:
-
Programming languages
-
Frameworks
-
Libraries
-
APIs
-
Databases
-
AI/ML models
-
Cloud services
-
Other technologies
Where applicable, include an explanation or diagram showing the major components of the system and how they interact.
Installation and SetupProvide clear instructions for setting up and running the project locally.
Include, where applicable:
-
Prerequisites
-
Installation commands
-
Dependencies
-
Environment variables
-
Database setup
-
API configuration
-
Run commands
Do not commit passwords, API keys, access tokens, or other secrets to the repository.
UsageExplain how a user can run and use the main features of the solution.
Data SourcesList the datasets, APIs, satellite data, environmental data, or other external data sources used.
AI UsageIf AI was used, explain:
-
Which AI tools, models, or APIs were used.
-
How AI was incorporated into the solution.
-
Which parts of the project were developed or assisted using AI.
Where appropriate, include screenshots, diagrams, or a link to the demonstration video.
TeamList all team members and, where appropriate, their roles or contributions.
Future DevelopmentDescribe planned improvements or opportunities for further development.
LicenceInclude the applicable software licence where required.
12. Devpost Submission InformationIn addition to the demonstration video and GitHub repository, teams must provide the following information on their Devpost submission:
-
Project name
-
Team members
-
Problem statement
-
Solution description
-
Conduit data used
-
Technologies used
-
Expected impact
-
Future development plans
-
Demonstration video link
-
GitHub repository link
The following requirements are mandatory:
| Requirement | Mandatory |
|---|---|
| Demonstration video | Yes |
| GitHub repository | Yes |
| Comprehensive README.md | Yes |
| Meaningful use of Conduit data | Yes |
| Working prototype | Yes |
| Devpost project information | Yes |
Failure to provide any mandatory submission requirement may result in the project being ineligible for judging or disqualified, at the discretion of the organisers.
14. Judging CriteriaProjects will be scored out of 100 points.
| Judging Criterion | Weight |
|---|---|
| Problem and Relevance | 20% |
| Innovation and Creativity | 20% |
| Technical Implementation and Use of Data | 25% |
| Climate, Environmental, and Social Impact | 25% |
| Scalability and Future Potential | 10% |
| Total | 100% |
Judges will assess:
-
Clarity of the problem.
-
Relevance and significance of the problem.
-
Understanding of the target users or beneficiaries.
-
Evidence that the problem is worth solving.
Judges will assess:
-
Originality of the solution.
-
Creativity of the approach.
-
Innovative use of technology and data.
-
Differentiation from existing approaches or solutions.
Judges will assess:
-
Functionality of the prototype.
-
Quality of the technical implementation.
-
Meaningful use of Conduit data.
-
Appropriate use of additional data and technologies.
-
The team's understanding of its technical implementation.
Judges will assess:
-
Potential contribution to climate or environmental action.
-
Potential benefits to users, communities, organisations, or ecosystems.
-
Strength and clarity of the proposed impact.
-
Potential to translate data and insights into useful action.
Judges will assess:
-
Potential for further development.
-
Feasibility of deployment.
-
Potential for adoption, research, entrepreneurship, or commercialisation.
-
Potential to expand the solution beyond the initial use case.
Judges will evaluate each project using the Devpost submission, demonstration video, GitHub repository, and project README.
Teams may be required to answer questions from the judging panel during the final judging session.
Judges are not required to troubleshoot, modify, deploy, or repair a team's project in order to evaluate it.
Teams are responsible for ensuring that all submitted materials are complete, accurate, and accessible.
The judging panel's decision will be final.
16. Intellectual PropertyParticipants retain ownership of the intellectual property they create during the hackathon.
Teams are responsible for ensuring that their projects do not infringe third-party intellectual property rights.
Any pre-existing intellectual property, open-source software, datasets, APIs, models, or other third-party resources used in a project remain subject to their respective licences and terms of use.
By participating in Hack The Weather, teams grant JHUB Africa and the hackathon partners permission to showcase, document, and promote their projects, teams, and achievements in connection with Hack The Weather and related innovation activities.
This permission does not transfer ownership of the project to the organisers.
17. Open-Source and Third-Party ResourcesTeams may use open-source software, frameworks, APIs, datasets, models, and other third-party resources.
Teams must:
-
Comply with applicable licences.
-
Provide attribution where required.
-
Comply with API and service terms.
-
Acknowledge significant third-party resources used in their projects.
Unauthorised use of proprietary software, datasets, content, or intellectual property is prohibited.
18. Responsible TechnologyProjects must comply with applicable laws and must not intentionally:
-
Harm individuals or communities.
-
Violate privacy.
-
Misuse personal or sensitive data.
-
Produce deliberately misleading information.
-
Infringe intellectual property rights.
-
Facilitate illegal activities.
-
Create unreasonable risks to users or communities.
Teams using AI or predictive models should clearly communicate relevant limitations and uncertainty where appropriate.
19. Code of ConductAll participants must:
-
Treat participants, mentors, judges, organisers, and volunteers with respect.
-
Maintain professional conduct.
-
Respect different backgrounds, perspectives, and abilities.
-
Refrain from harassment, discrimination, intimidation, or abusive behaviour.
-
Respect the work and intellectual property of other teams.
-
Follow event, venue, and safety requirements.
Serious or repeated violations may result in removal from the hackathon.
20. DisqualificationA team may be disqualified for:
-
Submitting plagiarised or substantially copied work.
-
Submitting a pre-existing project without substantial development during the hackathon.
-
Failing to use the mandatory Conduit data requirement.
-
Providing false or misleading registration or submission information.
-
Unauthorised use of proprietary data or intellectual property.
-
Manipulating or attempting to improperly influence the judging process.
-
Violating the Code of Conduct.
-
Failing to meet mandatory submission requirements.
-
Violating applicable laws or these rules.
A disqualified team will be ineligible for prizes.
The organisers and judging panel reserve the right to make the final determination regarding eligibility, rule violations, and disqualification.
21. Attendance and ParticipationParticipants are expected to actively participate throughout the hackathon.
Teams must attend and participate in sessions designated by the organisers as mandatory, including, where applicable:
-
Opening briefing
-
Technical orientation
-
Mentorship sessions
-
Team check-ins
-
Final demonstrations
-
Judging and presentations
Specific schedules, deadlines, and mandatory sessions will be communicated through the official hackathon communication channels.
22. Rule ChangesThe organisers reserve the right to clarify, amend, or update these rules where necessary.
Any significant changes will be communicated to registered participants through the official hackathon communication channels.
The organisers' interpretation of these rules will be final.