The proposal sets the project's direction before serious implementation begins. It shows the team understands a real, valuable problem, has defined a clear and feasible task, and has a realistic plan, not final results.
A strong proposal demonstrates that the team:
understands a real and valuable problem
has defined a clear and feasible project task
has researched possible solutions
has identified suitable data, models, and evaluation methods
has a realistic plan for completing the project
The proposal is not expected to contain final results, but it must show the project has been carefully investigated and is technically meaningful.
What the proposal must cover
Six parts, each with what to present, the requirements, and what to avoid.
1
Motivating Use Case
What to present
Describe the real-world context in which the problem occurs, and answer:
Who experiences the problem?
What process, system, or decision is affected?
Why does it matter?
What is the practical value of solving it?
Why is the problem difficult?
How is it handled today?
What are the limits of existing solutions?
Requirements
Keep the use case specific and evidence-based. Do not rely on common-sense claims like "it saves time." Instead say:
whose time is saved
which activity improves
what errors or costs are reduced
why existing tools fall short
Expected evidence
Include at least one of:
examples from real systems
user scenarios
scientific or professional sources
existing products or services
representative input and output examples
statistics showing the scale of the problem
Avoid
toy problems with no meaningful application
general statements about AI with no specific need
describing a technology before explaining the problem
claiming no solution exists without researching existing ones
2
Project Task and Problem Statement
What to present
Define exactly what the project will do. A good problem statement describes:
the input
the expected output
the processing task
the target users or system
the conditions under which the system operates
Example structure
Given [input], develop a system that produces [output] to support [use case], while satisfying [important constraints].
Requirements
The task must be clear, technically meaningful, feasible within the schedule, measurable, and tied directly to the motivating use case.
Break it into components
When the system is complex, split it into technical steps, for example:
collect or prepare the data
identify relevant information
apply a model
rank or classify the results
present the output to the user
Avoid
defining the task as "build an AI system"
confusing a software feature with a research problem
describing implementation details without defining the objective
vague goals like "improve performance" without saying what performance means
3
Novelty and Contribution
What to present
Explain what is new or valuable. Novelty can come from:
a new application
adapting an existing method to a new domain
combining several methods
creating or labeling a new dataset
a new evaluation protocol
comparing methods not compared before
improving quality, efficiency, explainability, or usability
integrating existing models into a useful end-to-end system
Requirements
Base novelty on prior-work research. Identify:
what already exists
what can be reused
what limitation remains
what the project adds
Novelty does not require a brand-new neural architecture; a strong engineering or experimental contribution counts.
Avoid
claiming novelty before reviewing previous work
presenting the use of a popular model as a contribution
calling API integration a research contribution
rebuilding an existing solution with no clear improvement or evaluation
4
Models and Methods
What to present
Describe the planned technical solution. For each major step, explain:
which model, algorithm, API, library, or technique will be used
why it is appropriate
what alternatives were considered
what modifications or fine-tuning may be needed
Requirements
Go beyond a single unexplained model call. Consider:
pretrained models
traditional baselines
state-of-the-art models
fine-tuning
prompt engineering
retrieval
data augmentation
rule-based processing
post-processing
ranking
calibration
error correction
Present the complete pipeline, not only the central model.
Your project must include at least one trained or fine-tuned model, not only zero-shot or few-shot prompting.
Avoid
choosing a model only because it is familiar
saying "we will use ChatGPT" without defining the task and evaluation
using technical terms without explaining their role
listing technologies instead of a coherent solution
5
Data Specification
What to present
Describe the data needed for development and evaluation:
which dataset
where it comes from
how many samples
what each sample contains
which labels or annotations exist
how it splits into training, validation, and test
whether more data must be collected or generated
Synthetic data
When using synthetic data, explain:
why real data is insufficient
what attributes are controlled
how diversity is created
how realism and correctness are checked
how synthetic data is kept separate from test data
Requirements
Give representative examples of inputs, labels, and expected outputs, and name the risks:
insufficient data
class imbalance
label noise
privacy restrictions
duplicate samples
data leakage
biased or unrepresentative data
Avoid
starting model development before inspecting the data
generating large amounts of synthetic data without validation
evaluating only on synthetic data
treating auto-generated labels as unquestionable ground truth
6
Metrics and Evaluation Plan
What to present
Define how success is measured:
which metrics
why each is appropriate
what ground truth is required
how the test set is built
what systems or models are compared
what result counts as success
Requirements
Include:
at least one baseline
quantitative evaluation
qualitative examples where useful
evaluation of major pipeline components
an end-to-end evaluation of the whole system
Candidate metrics: accuracy; precision, recall, and F1; ROC-AUC or PR-AUC; mean absolute error; ranking metrics; generation-quality metrics; latency; cost; robustness; human evaluation.
Avoid
choosing metrics only after seeing results
reporting accuracy alone on highly imbalanced data
evaluating on training data
showing only successful examples
subjective claims like "the results look good"
Make the proposal concrete with visuals
A proposal is far more convincing with one worked input/output example and a planned pipeline than with prose alone. Sketch figures like these even before any results exist.
One worked input → output examplePlanned pipeline diagramBaseline to beat & target metric
Show concrete examples of your data and model
Even before results exist, make it concrete: include representative examples of your data (images or text), how you will generate or collect it, the planned model steps, the expected inputs and outputs, and the errors you anticipate.
Sample data (images or text)
Image, chest X-ray 224×224 · label: pneumonia
"App crashes when I upload a PDF over 10 MB."
Text, support ticket → label: bug
How the data is generated or transformed
"Great pizza, fast delivery."→"gr8 pizza, delivery was not fast"
raw input→preprocess→tokenize / embed→model→post-process→output
Model input and output
"The wifi keeps dropping every few minutes."→{ label: network, conf: 0.92 }
"Summarize this clinical note: ..."→"Intermittent chest pain over two days ..."
input image→2 boxes: car 0.94, pedestrian 0.81
Model errors, with the likely cause
Predicted spam, true not spam: the model over-weighted a marketing phrase inside a quoted reply.
Detected 1 car, missed 1 in heavy rain: low SNR washed out the edges.
Generated a dosage not in the source note: retrieval returned an irrelevant passage.
Submission checklist
This is a quick final check, not a replacement for the full guide. Read the complete requirements above first, then use these ten items to confirm the major pieces are in place before you submit.
The motivating use case is specific and evidence-based (who, why, current limits).
The problem statement defines the input, output, task, users, and constraints.
A clear, non-trivial novelty or contribution is stated, grounded in prior work.
The planned solution is a full pipeline, not a single model call.
The plan includes a trained or fine-tuned model, not only zero-shot or few-shot.
The data is specified: source, size, labels, and train/validation/test split.
If synthetic data is used, its need, control, and validation are explained.
At least one baseline and concrete success criteria are defined.
Evaluation metrics are chosen and justified for the task.
Representative input and output examples are shown, and the risks are named.
