Once you've applied to 'claim' a quest and recieved your welcome email start here.
Use these resources to get access to tools, plan your work, and find help along the way. Your goal is to deliver a useful solution to the agreed-upon problem, explain how it works, and make it possible for the requester to use or build on your work.
The Minnesota Supercomputing Institute (MSI) provides computing resources for running AI models and working with data. When your application to complete a quest is submitted you will be automatically added to a group with access to MSI systems for the duration of your quest.
Once you have been added, follow the account setup instructions you receive and review MSI Getting Started and Access. You can use MSI to download and run models from Hugging Face and through Ollama.
New to supercomputing? Start with the MSI User Documentation, we recommend the browser-based Open OnDemand interface for most new users. Connect through the UMN EDUROAM network on campus or the UMN VPN off campus. Ask the Makerspace to help you choose a model, set up your environment, and run a small first test.
Useful links: AI Resources at MSI and MSI Open OnDemand. For account or connection problems, contact help@msi.umn.edu.
The CSE AI Makerspace welcomes beginners and experienced students. Visit Walter Library, room 125, or email ai-makerspace@umn.edu to arrange an in-person or virtual appointment. The currently listed hours are Monday–Thursday, 10 a.m.–8 p.m.; Friday, 10 a.m.–4 p.m.; and Saturday, noon–4 p.m., Central Time. Check the Makerspace website for current hours and closures. Reach out when you need help choosing an approach, accessing APIs or computing resources, working on MSI, troubleshooting an error, or getting past a development roadblock. You can ask for help at the start of your Quest—you do not need to wait until you are stuck.
When requesting help share what you are trying to accomplish, what you have tried, and the error or unexpected result. Remove passwords, API keys, and private data from screenshots or examples.
Use the AI Hub Tools Directory to explore University AI tools and their access and data-use guidance. A chat subscription and an API connection are different services; access to one does not automatically include the other. Ask the Makerspace about resources for your project you should not build around a non-enterprise paid service. Confirm any costs and who will cover them with the AI Quests team.
For program questions, timeline concerns, or changes to your Quest, email aiquests@umn.edu.
After your Quest is accepted, contact the requester listed in your welcome email to schedule a kickoff conversation. Allow about 30–45 minutes, invite your teammates, and review the Quest description beforehand. The requester is the person who proposed the project and can explain the problem and intended outcome.
Use the meeting to understand the work before deciding how to build it. These questions are a good starting point:
Understand the problem: Who will use this? Can you walk us through how the task happens today? Which part takes the most time or causes the most difficulty?
See real examples: Can you show us a typical input and the result you would want? What would an incorrect or unhelpful result look like?
Define completion: What must the solution do for this Quest to be complete? What is optional? How will we demonstrate and test it, and who will review the work?
Identify resources and limits: What data, files, existing code, or accounts can we use? Who can authorize access? Are there privacy, accessibility, platform, budget, or licensing requirements?
Agree on a plan: What is the target completion date? When should we show an early version? How should we communicate, and who can answer questions?
Plan the handoff: Where should the finished work live? Who will manage it afterward? Does this Quest call for a prototype or something intended for ongoing use?
Afterward, send a short recap covering the agreed deliverables, success criteria, timeline, access needs, and next steps. Ask the requester to confirm or correct it. Discuss changes to the approved scope or timeline with the AI Quests team before committing to extra work.
Start with the smallest working version that addresses the agreed problem. Test it on a few representative examples and show it to the requester early. Feedback on a rough version is often more useful than polishing the wrong solution.
Test with someone who did not build it, ideally an intended user. Can they understand what to do, recover from an error, and recognize an unreliable result? Use clear labels, readable text, keyboard-accessible controls, and helpful error messages.
Write brief instructions as you build. Include how to open or run the solution, required accounts and software, an example input and output, and what the tool cannot do. Record the model, settings, and software versions used so someone else can reproduce your work.
Use AI where it helps. A spreadsheet formula, search tool, rule, or ordinary automation may solve part—or all—of the problem more reliably. Explain why your chosen approach fits the task.
Choose the right model. Start with a smaller or less expensive model and test whether it meets your quality needs. Use a more capable model when testing shows a meaningful benefit.
Monitor usage and costs. Tokens are the pieces of text a model reads and generates. Track input and output tokens, calls, and estimated costs for paid APIs. Limit response length, repeated requests, retries, and automated loops. For MSI workloads, also watch GPU time, memory, and storage.
Test before scaling. Use a small sample before processing an entire collection. Check typical cases, missing information, confusing requests, and cases where the system should say it cannot answer. Record failures as well as successes.
Protect data and credentials. Confirm what data you may use and where it may go. Start with public or synthetic examples while access is being arranged. Keep passwords and API keys out of code, shared documents, and public repositories.
Keep people in control. Make AI-generated outputs clear and provide a way to review or correct them. Ask for confirmation before a tool sends messages, changes records, deletes files, or takes other consequential actions. Treat uploaded documents and retrieved text as content, not instructions for the program.
Understand what you submit. AI can help you write code or troubleshoot, but you should be able to explain the solution, test its behavior, and document its limitations. Check licenses for reused models, code, and datasets.
Before submitting, compare your work with the agreed definition of done. Prepare:
A working solution or deliverable, with access for the reviewers.
Setup and usage instructions, including required accounts or dependencies.
A short demonstration and a summary of testing results.
Known limitations, ongoing costs, and any maintenance needs.
Use Finish your Quest to submit your solution. Have your Quest ID and Student / Team ID ready; for a team, one member should submit on everyone's behalf. The requester and program team will review the work and may ask for revisions before approving completion.