Mitacs AI: prepare your project brief for ADOPT or AI+X

Before discussing Mitacs AI Advantage, write down the business problem, the work you need and the result you would test. ADOPT focuses on moving toward AI implementation; AI+X focuses on AI-enabled research and innovation. A clear project brief helps you discuss the appropriate route with a Mitacs advisor without treating a possible fit as approved funding.

This guide is for Canadian business owners, operations teams and innovation leads. It provides an editorial planning worksheet, not an official application form or an eligibility decision. Official information was checked on September 27, 2026.

Start with the distinction the official sources make

The September 25 federal announcement describes support for business–academic collaboration through AI-related placements. It distinguishes adoption work from research and innovation. An announcement about supported placements does not award a contribution to your business.

On the Mitacs AI Advantage page, ADOPT includes adoption planning, implementation support and internal AI readiness. AI+X covers applied challenges, research, commercialization and development of AI solutions. Mitacs directs organizations to an advisor to discuss the appropriate offering and prepare their project for submission.

Use those descriptions to organize a conversation. Avoid deciding from a technology label alone: two projects using computer vision can involve very different work. One may need help implementing an available approach; another may need research to establish whether a new approach can work.

Describe the problem before naming a solution

Begin with one operational task and its current limitation. “We want to use AI” leaves the reviewer guessing. “Our team manually sorts inspection images, and we need to test whether an assisted process can reduce review time while preserving defect detection” gives the discussion a concrete starting point.

Record the baseline you actually know. If review time has not been measured, write “baseline to establish” and assign someone to collect it. Do not invent a productivity gain to make the brief look complete.

For an internal first draft, answer these questions:

• Who experiences the problem, and which workflow or product is affected?

• What happens today, and which records can demonstrate the limitation?

• What has already been tried, including existing software or non-AI options?

• What would the project deliver: a roadmap, a tested workflow, a prototype or an experimental result?

• Who will judge whether the result is useful, and what evidence will they review?

These are preparation prompts. They are not additional Mitacs requirements.

Make the unresolved work visible

Separate work your team knows how to perform from questions it cannot yet answer. This helps an advisor understand why a collaboration is needed.

An adoption discussion might begin with an available method and ask how to evaluate it, integrate it into a workflow or prepare employees to use it. A research discussion might begin with an unresolved technical question, a proposed experiment and a result that is not yet known. These are illustrative distinctions, not a rule that classifies every project.

Write down the uncertainty in plain language. For example: “We do not know whether the available images capture the defect reliably enough.” Then identify the first useful test. A promise to deploy a finished solution is different from a proposal to determine whether an approach is feasible.

Build a one-page brief for the advisor

Keep the initial brief short enough for operations, finance and the technical lead to review together. Use the following fields as an internal worksheet, then follow the official submission instructions for the actual application.

• Business and project owner: identify the organization, work location and person responsible for the problem.

• Problem and baseline: describe the task, current limitation and available evidence. Label estimates and missing measurements.

• Work and deliverables: list the main activities and what each would produce. Separate investigation from implementation.

• Data and access: describe the data types, their owner, quality concerns and permissions to resolve. Use a summary rather than attaching sensitive datasets to an initial inquiry.

• Collaboration needed: identify the expertise you lack, any academic contact already involved and the support your team could provide.

• Decision test: state how you would assess the result, including quality or safety limits alongside time or cost goals.

• Resources and timing: record staff availability, the desired schedule and budget questions requiring confirmation.

Add a final line for unresolved questions and their owners. That turns the brief into a working handoff: the advisor can identify missing program information while your team resolves its own operational assumptions.

Example: one inspection problem, two possible briefs

Consider a fictional manufacturer that wants to improve visual inspection. No funding approval or eligibility is implied by this example.

In the first version, a suitable image-classification approach already exists. The team needs to assess its use on the shop floor, plan integration and train users. Its brief would emphasize the current inspection workflow, implementation barriers, available images and an evaluation plan. It could ask the advisor whether an ADOPT discussion is appropriate.

In the second version, the defects are difficult to distinguish and the team does not know whether existing methods can detect them. Its brief would describe the unresolved question, experimental data and comparison needed to test a new approach. It could ask whether AI+X fits that research work.

The useful difference is the work to be done and the evidence needed. If the project contains both phases, describe them separately and ask how they should be structured. Do not assume that selecting two labels creates two funding entitlements.

Confirm the funding mechanics before relying on a contribution

The official model involves co-funded placements. Your brief should therefore keep the project’s total resource needs separate from an unconfirmed funding assumption.

Ask the advisor which current terms apply to your organization and project, what partner contribution is required, which expenses are covered, how payments are handled and which dates govern the work. Clarify the treatment of other assistance, agreements, intellectual property and reporting before making commitments that depend on those answers.

Assign finance an owner for the contribution and cash-flow questions, and assign the technical lead an owner for the work plan. A useful brief can contain open questions; an internal budget should make those uncertainties visible.

For broader context, helloDarwin’s AI and innovation funding webinar covers other funding approaches. Our grant application preparation guide explains how to keep scope, budget and evidence consistent. For this Mitacs discussion, the immediate next step is a clear brief and a list of questions for the advisor—not a claim that funding has been secured.