Skip to main content

Hackathon preparation activity

Instruction and application
In Progress

Building on the model you selected and refined in Hackathon 2, we will now walk through sample deployment and monitoring approaches for each scenario.

The goal is to show how a validated model can be translated into a live, monitored, and documented ML service — and bring all teams to a common, deployment-ready starting point.

Download the Hackathon Resource Pack​

The pack contains:

  • Descriptions of the two scenarios (continued from Hackathon 2).
  • Reference model artefacts for each scenario (packaged model, requirements, sample inference script).
  • Deployment harness — a docker-compose starter and a hosted-URL deployment template.
  • Monitoring plan template covering drift detection, alerting, and retraining triggers.
  • Stakeholder presentation template you will use to communicate your deployed solution.

You'll use this pack during the preparation activity and continue using it throughout the hackathon sprints.

AIMLF Hackathon 3 Resource Pack.zip

Once downloaded, open the files and keep them accessible for the rest of the hackathon.

Action item: Scenario refresher​

Directions: Share your thoughts in the chat or come off mute

  • What model did your team select in Hackathon 2, and what business decision does it support?
  • Who are the primary and secondary stakeholders that will interact with — or be affected by — the deployed model?
  • What signals in the live data would tell you that the model's environment has changed?

Hackathon 2 to Hackathon 3 walkthrough​

We will now use the kickoff demo notebooks and deployment harness to walk through sample end-to-end deployments for each scenario. The walkthroughs will show how a refined model can be containerised, exposed as an inference endpoint, monitored for drift, and explained to a non-technical audience.

The demos are intended to demonstrate one possible approach, not a single "correct" solution.

As you review the walkthroughs, focus on the following ideas:

  • A simple, reproducible deployment is more valuable than a complex one that no one else can run.
  • Monitoring and drift-detection choices depend on the business problem, not just on the model.
  • Explainability tooling such as SHAP or LIME helps translate model behaviour for stakeholders.
  • Lifecycle planning — including retraining triggers and decommissioning — starts on day one.

Using LLMs and Atlas during the hackathon​

Throughout the hackathon, you are encouraged to use LLM tools to support your thinking and workflow.

You may use LLMs to:

  • Explore deployment architectures and trade-offs.
  • Draft monitoring rules, alert thresholds, and retraining triggers.
  • Support interpretation of drift signals and stakeholder concerns.
  • Help structure presentation content, speaker notes, and technical documentation.
  • Generate summaries, explanations, or handover artefacts.

You may also use Atlas to:

  • Revisit relevant learning content from Modules 11–13.
  • Prompt against concepts such as scalable deployment, monitoring, drift, lifecycle management, and stakeholder communication.

LLMs should support your decision-making and communication, not replace your reasoning or experimentation.

Before you move on​

In workshops 1 and 2, your team will:

  • Deploy your Phase 2 model into a production or test environment.
  • Design and document a monitoring plan with drift detection.
  • Define a lifecycle strategy including retraining and decommissioning.
  • Prepare a 5-minute audience-tailored presentation for the wrap up.

You are not expected to build a bulletproof platform, use enterprise-grade infrastructure, or produce a fully-hardened production system. The goal of this hackathon is to learn through experimentation, evaluation, and iterative improvement of a real deployed service.

In progress