Project 5 — Domain-Specific AI Integration Proposal

“An intelligent heart acquires knowledge, and the ear of the wise seeks knowledge.” — Proverbs 18:15 (ESV)

Chapter: Chapter 5 — AI Across the Computer Science Domains Due: end of Week 5 Submit: a proposal-ai-integration.pdf (or Markdown) committed to your research portfolio repo, plus the filled code/method-fit-matrix.csv and code/baseline-card.yaml Allowed tools: any literature/discovery tool (Appendix B); your portfolio repo; an LLM as a thinking aid only AI policy: open-AI for thinking and drafting; you own and verify every claim and citation; disclose AI assistance per Appendix C. Verify every reference against dblp / Semantic Scholar. Weight: ungraded-but-required portfolio building block (no direct % — it is the methodological core that feeds the graded Research Proposal in Week 8, P8, worth 15% + 10%). Treat it as load-bearing: a weak proposal here weakens everything downstream.

The Setup

You have a gap. Four weeks of reading led to a comparison matrix with an empty cell — an unaddressed column, a method nobody applied to your domain, a benchmark nobody ran. This week a question lands on your desk that every applied-AI researcher must answer before they touch a GPU:

Which specific modern AI method advances my domain’s problem — and what, exactly, does it have to beat?

You are not building the system this week. You are writing the decision that justifies building it: the method, the baseline, the metric, the data, the failure modes, the disclosure. Get this document right and the next eleven weeks are execution. Get it wrong — name an impressive method with no baseline, no data, and no failure analysis — and you will discover the problem in Week 10 when there is no time to fix it. The proposal is cheap insurance against an expensive mistake.

Learning Targets

You will demonstrate that you can:

• Diagnose a domain problem’s failure as knowledge / behavior / elicitation and map it to a rung of the method ladder (prompt → RAG → fine-tune → distill).
• Select a specific AI method (LLM / RAG / fine-tune / agent / CV / RL / multimodal) and justify it against alternatives — including why you did not climb higher on the ladder.
• Name an honest, often non-AI baseline and the metric that decides whether you beat it.
• Anchor to a real, verified canonical paper in your domain and state the dataset/benchmark.
• Enumerate the method’s failure modes with concrete mitigations, and state your venue disclosure stance.

Normal Tier

Required features

A 3–5 page proposal (acmart single-column or IEEEtran is fine, or clean Markdown) containing, in order:

1. Problem & domain (1 para): the specific problem in your chosen CS domain and why it matters.
2. Failure diagnosis (1 para): is the current failure knowledge, behavior, or elicitation? Evidence, not assertion.
3. Method selection (1–2 paras): the method you choose, walked up the ladder — one sentence each for the rungs below your choice explaining why they don’t suffice. Use your filled code/method-fit-matrix.csv.
4. Baseline & metric (1 para + the code/baseline-card.yaml): the single sentence “Method X beats baseline Y on metric Z by margin M.” Y must be simple/honest.
5. Data & anchor (1 para): your data shape (labeled / corpus / reward / few-shot) and one verified canonical paper from §5.7 with its real dblp/Semantic Scholar metadata.
6. Failure modes & disclosure (1 para): each failure mode (§5.8) with a one-line mitigation, plus your venue disclosure stance (Appendix C).

Normal-tier rubric (out of 100)

Medium Tier (+up to 25% extra credit)

Raise the rigor:

• Fill the method-fit matrix with three+ candidate methods and include a short comparison paragraph explaining the trade-off you committed to.
• Instrument the right measurement explicitly: for RAG, define retrieval recall/precision separate from answer accuracy; for an agent, define the trajectory-log schema; for RL, the reward and the baseline policy; for fine-tune, the catastrophic-forgetting check.
• Justify your baseline against a published number on a named benchmark (and check that benchmark for contamination risk — prefer LiveCodeBench / LiveBench / MMLU-Pro where relevant).
• Add a one-paragraph compute/feasibility budget showing the method fits a master’s budget (e.g. QLoRA on one GPU, RAG with a hosted model, RL on a small simulator).

Hard Tier (+up to 25% additional extra credit)

Publication-ready judgment a tool can’t supply. Write a one-page “method-selection memo” addressed to your future committee that:

• Argues, with citations to both sides of a live debate where one exists (e.g. RLVR expands reasoning, arXiv:2506.14245, vs. RLVR merely sharpens sampling, the “Limit of RLVR” line), why your method is defensible given current evidence — not just popular.
• States the single experimental result that would falsify your choice (the outcome that would send you back down the ladder), and commits to reporting it honestly if it happens.
• Names the most damaging question a hostile reviewer would ask and answers it in writing.

This memo is the difference between a method you like and a method you can defend. An AI can list methods; it cannot make this judgment for you and stand behind it.

Submission

• Commit proposal-ai-integration.pdf (or Markdown), the filled method-fit-matrix.csv, and baseline-card.yaml to your portfolio repo under proposals/week-05/.
• Include the AI-disclosure paragraph in the proposal itself.
• Tag the commit p05-ai-integration.

Hints

• Start with code/proposal-skeleton.txt; it already has the six sections.
• Run code/verify_citations.py on every reference before you submit — yes, every one.
• If you can’t name a simple baseline, you’re not ready to write the rest. Solve that first.
• Resist the impressive method. The reproducible small result wins the practicum.
• Re-read §5.7 (the decision framework) and your Week 4 comparison matrix together; your gap and your method should obviously connect.

What Mastery Looks Like

A reader who knows nothing about your domain finishes your proposal and can state, in their own words: the problem, why your method fits the specific failure, what it has to beat, how you’ll know if it did, and where it might break. There is no hand-waving, no unverified citation, and no method chosen for being shiny. The baseline is so honest it’s almost embarrassing — and that honesty is exactly what makes the contribution measurable.

Coach’s Note — The single most common way this proposal dies is “no baseline.” The second is “an LLM invented a citation and I didn’t check.” Both are five-minute fixes this week and fatal in Week 14. Spend the five minutes.

When You’re Done

• Failure diagnosed as knowledge / behavior / elicitation, with evidence
• Method chosen and lower ladder rungs addressed in writing
• Baseline card filled; “X beats Y on Z by M” sentence written
• Data shape stated honestly and matched to the method
• Anchor paper verified in dblp / Semantic Scholar
• Every failure mode has a mitigation
• Disclosure stance written for a real venue family
• Committed and tagged in the portfolio repo

A theological footnote. Proverbs 18:15 praises not the heart that already knows but the ear of the wise that seeks — wisdom as an open, listening posture toward the truth. That is precisely what a baseline is: a deliberate invitation for reality to contradict you. We are, in confessional terms, simul iustus et peccator — capable of quietly fitting the evidence to our hope. So we build the honest baseline on purpose, as a guard against our own heart, and we keep our ear turned toward what the data actually says rather than what we wish it said. To search a matter out faithfully is, in the end, to submit our cleverness to what is — which is its own small act of worship.