How you're judged

CRITERION 1 — INNOVATION & ORIGINALITY (25 marks)

This criterion asks: how original and creative is the idea? "Original" means new to this context — a known technique applied cleverly to a local problem nobody has tackled still counts as highly original. You are rewarding fresh thinking, not how fancy the topic sounds. Score what the team actually did, not the size of the buzzword.

Item 1.1 — Is the problem itself uncommon in the region? (5)

What this tests: whether the team chose a problem that is genuinely under-served here, rather than a problem already solved many times. Picking an overlooked real problem is itself a sign of original thinking.

• Full (5) — the problem is rarely or never addressed in Sri Lanka / the Eastern Province. Example (STRONG): local-language voice reporting of crop pests for Batticaloa paddy farmers — almost nobody has built this for this audience. Why Full, not Half: it isn't just new to the region, it's barely addressed anywhere for this user group.
• Half (2.5) — the problem is solved elsewhere, but is a fresh attempt locally. Example (MIDDLING): a school attendance app — common globally, but a genuine first attempt at this school/region. Why Half, not Full: the problem is well-trodden elsewhere. Why not None: it is still a fresh local application.
• None (0) — a very commonly addressed problem with nothing regional or new about it. Example (WEAK): a cat-vs-dog classifier — a textbook exercise done countless times.

Item 1.2 — Is AI used in a non-obvious, creative way? (5)

What this tests: whether AI is the clever core of the solution, or just a label. The best entries use AI where it genuinely unlocks something; the worst slap "AI" on a project that doesn't really use it.

• Full (5) — creative, non-tutorial use of AI central to the idea. Example (STRONG): using Tamil + Sinhala speech recognition to turn a spoken report into structured map data — AI does the heavy lifting. Why Full, not Half: the AI use is non-obvious and essential, not a standard demo.
• Half (2.5) — a standard AI technique, applied sensibly. Example (MIDDLING): face recognition for attendance — a common technique, but applied reasonably to a real task. Why Half: it's a textbook use, but at least correctly and usefully applied. Why not None: AI genuinely does something here.
• None (0) — AI is a buzzword or barely present. Example (WEAK or worse): an "AI app" that is actually a hard-coded if-else with no model at all.

Item 1.3 — Does it combine ideas or techniques in a new way? (5)

What this tests: originality often comes from combination — joining things that aren't usually joined. This rewards synthesis, not just a single borrowed idea.

• Full (5) — two or more ideas/techniques combined in a genuinely new way. Example (STRONG): voice AI + a live district risk-map + automatic SMS alerts to agriculture officers, woven into one flow. Why Full, not Half: multiple components combine into something none of them is alone.
• Half (2.5) — a minor recombination or small add-on. Example (MIDDLING): an attendance app that also emails a daily summary — a small extra on a known idea. Why Half: there is some combining, but it's modest. Why not None: it's more than a single off-the-shelf feature.
• None (0) — a single off-the-shelf idea with nothing added. Example (WEAK): a plain image classifier and nothing else.

Item 1.4 — Can the team articulate what makes theirs different? (5)

What this tests: whether the team understands their own originality. A team that can crisply say how they differ from what exists has thought it through; one that can't usually hasn't.

• Full (5) — clearly states a specific, credible unique angle. Example (STRONG): "Existing agri-apps need typing in English; ours works by voice in Tamil, so farmers who can't type or read English can use it." Why Full, not Half: the differentiator is specific and meaningful.
• Half (2.5) — vaguely aware of alternatives, weak differentiation. Example (MIDDLING): "There are other attendance apps, but ours is for our school." Why Half: they know alternatives exist but the difference is thin. Why not None: they at least acknowledge the landscape.
• None (0) — cannot say how theirs differs from anything. Example (WEAK): "We just thought it would be cool" — no comparison at all.

Item 1.5 — Would an experienced judge struggle to recall an identical project? (5)

What this tests: the "have I seen this exact thing before?" gut check — the simplest test of novelty. Use your own experience honestly.

• Full (5) — you genuinely have not seen this exact thing before. Example (STRONG): the local-language pest-report map — unfamiliar even to an experienced judge.
• Half (2.5) — you've seen similar, but not identical. Example (MIDDLING): face-attendance apps exist, but not quite this school's version. Why Half: close cousins exist. Why not None: it isn't a carbon copy.
• None (0) — it is a recognizable copy of a known project. Example (WEAK): the cat-vs-dog classifier lifted straight from a tutorial.

▶ Criterion 1 score = sum of items 1.1–1.5 (max 25).

---

CRITERION 2 — PRACTICAL APPLICABILITY (25 marks)

This criterion asks: could this realistically be built and actually used in the real world? A brilliant but un-buildable idea scores high on Innovation and low here. You are testing for grounding — data, users, cost, and honesty about limits. At the Abstract stage you judge the plausibility of the plan; at the Product stage you judge the actual built thing.

Item 2.1 — Can it realistically be built with the skills and tools available? (5)

What this tests: whether the team can actually make this with what they have or can reasonably get — not whether it's theoretically possible for a big company.

• Full (5) — clearly buildable with the team's current skills/tools (or a realistic, named plan to get them). Example (STRONG): "We'll use free open-source speech models we've already tested on sample audio." — concrete and within reach. Why Full, not Half: no major capability gap remains.
• Half (2.5) — buildable, but needs upskilling or outside help they haven't secured. Example (MIDDLING): "We can build the app, but we still need someone to help us train the face model." — achievable, with a real gap. Why Half: the path exists but isn't fully resourced. Why not None: it's clearly doable in principle.
• None (0) — no realistic path to build it. Example (WEAK/over-reach): "We'll design a brand-new AI chip for it." — far beyond any feasible scope.

Item 2.2 — Is the data it needs actually obtainable? (5)

What this tests: AI lives on data. Many ideas collapse because the data they assume can't actually be gathered, accessed, or used legally.

• Full (5) — a specific data source is identified and genuinely accessible. Example (STRONG): "We have consented voice recordings from 3 cooperatives, plus public pest-outbreak records." — real and in hand. Why Full, not Half: access is confirmed, not hoped for.
• Half (2.5) — the data exists but access is unconfirmed or unclear. Example (MIDDLING): "The school has attendance photos; we think we can get permission." — plausible, not secured. Why Half: the data is real but access is assumed. Why not None: a concrete source exists.
• None (0) — no viable or lawful data source. Example (WEAK): "We'll need everyone's private medical/bank records." — unobtainable and improper.

Item 2.3 — Is a real user or beneficiary identified? (5)

What this tests: whether the team built for a real person or an imagined one. Named, consulted users make a solution far more likely to be real and used.

• Full (5) — specific real users named, with some evidence they want it. Example (STRONG): "We interviewed 3 paddy-farming cooperatives in Batticaloa; all said they'd use a voice pest-reporting tool." Why Full, not Half: they went beyond naming a group — they have evidence of demand.
• Half (2.5) — a plausible real user group is named, but nobody was actually consulted. Example (MIDDLING): "This is for teachers in our school." — a real group, but no sign they were asked what they need. Why Half: the group is genuine but demand is assumed. Why not None: a real user is at least identified.
• None (0) — no specific user; only "people could use this." Example (WEAK): "This could be useful for many people." — nobody specific at all.

Item 2.4 — Is deployment and cost realistic? (5)

What this tests: whether the team has thought about how the thing actually reaches users and what it costs to run — the gap where many student projects quietly die.

• Full (5) — a concrete, affordable deployment and running-cost plan. Example (STRONG): "Runs on a basic Android phone; cloud hosting ≈ LKR 5,000/month, covered by the cooperative." — specific and affordable. Why Full, not Half: both how it's delivered and what it costs are addressed.
• Half (2.5) — a rough plan with real gaps. Example (MIDDLING): "It'll be an app teachers download." — a delivery idea, but no cost or maintenance thinking. Why Half: partial thinking. Why not None: deployment is at least considered.
• None (0) — cost/deployment ignored entirely. Example (WEAK): no mention of how anyone would ever obtain or run it.

Item 2.5 — Are the real constraints acknowledged honestly? (5)

What this tests: maturity. Teams that name their limits and plan around them are credible; teams that claim "no challenges" are not.

• Full (5) — names real limits AND how they'll handle them. Example (STRONG): "Rural connectivity is weak, so reports are cached offline and synced when signal returns." Why Full, not Half: limits are named and mitigated.
• Half (2.5) — mentions some limits, but no mitigation. Example (MIDDLING): "Internet might sometimes be a problem." — aware, but no plan. Why Half: honest but incomplete. Why not None: at least it doesn't pretend perfection.
• None (0) — hand-waves or claims no limitations. Example (WEAK): "There are no challenges; it will work perfectly." — a clear maturity red flag.

▶ Criterion 2 score = sum of items 2.1–2.5 (max 25).

---

CRITERION 3 — TECHNICAL QUALITY (20 marks)

This criterion asks: is the AI and engineering sound and well-executed? Judge the appropriateness and soundness of the approach — not its flashiness. Crucially, judge relative to the category (see §B.6): school-level code and undergraduate-level code are held to different "Full" bars.

Item 3.1 — Does the AI approach fit the problem? (5)

What this tests: whether they chose the right tool. The best teams pick a method because it suits the problem and the constraints, not because it sounds impressive.

• Full (5) — an appropriate, well-justified method. Example (STRONG): a lightweight speech model chosen specifically because it must run offline on cheap phones. Why Full, not Half: the choice is correct and the team can explain why.
• Half (2.5) — a reasonable but not ideal choice. Example (MIDDLING): a heavy cloud model used for something that really needed to work offline. Why Half: it works but is mismatched to the constraints. Why not None: the method can still do the task.
• None (0) — a wrong or inappropriate method. Example (WEAK): using image AI for a problem that is purely about text.

Item 3.2 — Is data used sensibly and ethically? (5)

What this tests: responsible data practice — consent, privacy, and documentation. This matters especially for a government-run, youth-facing programme.

• Full (5) — clean, consented, anonymised, documented data. Example (STRONG): "Voice samples collected with signed consent; names removed; sources listed." Why Full, not Half: ethics and documentation are both clearly handled.
• Half (2.5) — mostly sound, with minor gaps. Example (MIDDLING): attendance photos used and documented, but consent isn't clearly addressed. Why Half: largely responsible, one real gap. Why not None: data handling is mostly sound.
• None (0) — poor, absent, or unethical data use. Example (WEAK): personal data scraped with no consent or thought.

Item 3.3 — Is the architecture/code sound and evidenced? (5)

What this tests: whether there's real, working engineering behind the claims — not just slides describing a system that doesn't exist.

• Full (5) — clean design plus working evidence (repo/demo). Example (STRONG): a clear architecture diagram and a GitHub repo that actually runs. Why Full, not Half: the design is sound and demonstrably real.
• Half (2.5) — it works but is messy or only partly shown. Example (MIDDLING): a working demo, but no code shared or a disorganised repo. Why Half: there's real work, but the engineering quality/evidence is incomplete. Why not None: something genuinely runs.
• None (0) — broken, or no real implementation. Example (WEAK): slides claim a system, but nothing actually runs.

Item 3.4 — Does the complexity match the need? (5)

What this tests: judgment. Over-engineering (to look advanced) and under-engineering (too trivial) are both faults; the right answer fits the problem.

• Full (5) — appropriately scoped, neither over- nor under-built. Example (STRONG): a focused tool that does one useful thing well. Why Full, not Half: effort is spent exactly where the problem needs it.
• Half (2.5) — slightly over- or under-engineered. Example (MIDDLING): five unused features bolted on "to look advanced." Why Half: some effort is misplaced. Why not None: the core still fits.
• None (0) — wildly mismatched to the problem. Example (WEAK): a massive ML pipeline to do what a single rule could do.

▶ Criterion 3 score = sum of items 3.1–3.4 (max 20). Judge each item relative to category capability — see §B.6.

---

CRITERION 4 — IMPACT POTENTIAL (20 marks)

This criterion asks: will it meaningfully help people — especially in the Eastern Province? Reward real, specific, region-relevant benefit. Do not reward the ambition of the topic; a tool that genuinely helps 200 local fishermen beats one that vaguely claims to help "everyone."

Item 4.1 — Are the beneficiaries clearly identified? (5)

What this tests: specificity. Real impact starts with knowing exactly who benefits.

• Full (5) — a specific group named. Example (STRONG): "Paddy farmers in Batticaloa district." — concrete and locatable. Why Full, not Half: the group is specific, not just a broad label.
• Half (2.5) — a broad group named. Example (MIDDLING): "Farmers in Sri Lanka." — real, but too broad to target. Why Half: a real category, but unspecific. Why not None: a beneficiary is at least named.
• None (0) — "everyone" / unspecified. Example (WEAK): "It helps society."

Item 4.2 — Is the benefit significant, not trivial? (5)

What this tests: whether the problem solved actually matters to those people.

• Full (5) — solves a real, felt problem. Example (STRONG): early pest detection that prevents real crop loss and lost income. Why Full, not Half: it addresses a problem people genuinely feel.
• Half (2.5) — a minor improvement. Example (MIDDLING): saves a teacher five minutes of roll-call a day. Why Half: a genuine but small benefit. Why not None: it does help.
• None (0) — negligible benefit. Example (WEAK): "It's a fun app to play with."

Item 4.3 — Is the impact quantified or evidenced? (5)

What this tests: whether the benefit is backed by reasoning/numbers or is just a claim.

• Full (5) — numbers or clear reasoning for the benefit. Example (STRONG): "If 10% of outbreaks are caught a week earlier, roughly X hectares of paddy are saved per season." Why Full, not Half: the impact is estimated, not just asserted.
• Half (2.5) — some justification, no real figures. Example (MIDDLING): "Many farmers lose crops to pests each year, so earlier alerts should help." Why Half: a reasoned case but unquantified. Why not None: there's at least supporting logic.
• None (0) — pure assertion. Example (WEAK): "This will help a lot."

Item 4.4 — Does it matter specifically to the Eastern Province? (5)

What this tests: regional relevance — the heart of this programme's purpose.

• Full (5) — directly relevant to the region. Example (STRONG): built around Batticaloa's paddy and fisheries economy. Why Full, not Half: the regional fit is central, not incidental.
• Half (2.5) — generally useful, not region-specific. Example (MIDDLING): a generic study-helper app that happens to be usable here. Why Half: useful, but nothing about it is regional. Why not None: it could still serve people here.
• None (0) — no regional relevance. Example (WEAK): a meme generator.

▶ Criterion 4 score = sum of items 4.1–4.4 (max 20).

---

CRITERION 5 — PRESENTATION QUALITY (10 marks)

This criterion asks: can outsiders understand what was built and why? It is only 10 of 100 marks by design — a slick presentation cannot rescue weak substance, and strong substance shouldn't be buried by a poor one. Score communication, not charisma.

Item 5.1 — Structure & clarity (3)

What this tests: whether the submission is logically ordered and easy to follow.

• Full (3) — clear, logical, easy to follow. Example (STRONG): problem → solution → demo → impact, in a clean order.
• Half (1.5) — followable with effort. Example (MIDDLING): jumps around, but the gist comes through. Why Half: understandable but disorganised.
• None (0) — confusing. Example (WEAK): no structure; the audience can't tell what it does.

Item 5.2 — Demo / documentation shows it working (3)

What this tests: whether there's real evidence the thing functions.

• Full (3) — a demo clearly shows the solution working. Example (STRONG): a video of a farmer speaking and a report appearing on the live map.
• Half (1.5) — partial or unclear demo. Example (MIDDLING): screenshots only, no live working flow. Why Half: some evidence, not convincing.
• None (0) — no working demo shown. Example (WEAK): only a verbal description, nothing demonstrated.

Item 5.3 — Communication is confident & honest (2)

What this tests: whether claims match reality (no overselling).

• Full (2) — clear and honest about what works. Example (STRONG): "Pest reporting works today; payments are future work."
• Half (1) — some overclaiming or vagueness. Example (MIDDLING): "It does everything," when only one feature works. Why Half: partly oversold.
• None (0) — misleading. Example (WEAK): claims a feature that doesn't exist.

Item 5.4 — Materials are complete (2)

What this tests: whether the required submission items are all present and legible.

• Full (2) — all required materials present & legible. Example (STRONG): slides, demo video, repo link, and summary all provided.
• Half (1) — some missing or poor quality. Example (MIDDLING): slides fine, but no demo video. Why Half: incomplete pack.
• None (0) — key materials missing. Example (WEAK): only a title slide submitted.

▶ Criterion 5 score = sum of items 5.1–5.4 (max 10).

---

B.6 — Per-category calibration

The same items and examples apply to every category. Only the bar for "Full" on the Technical items (3.1–3.4) moves with what's realistic for that category:

• School Students: judge Technical at school level — a simple working prototype can earn Full. Be generous on Innovation (1.x) and Impact (4.x); these students aren't expected to produce production-grade code.
• Undergraduate Students: expect real engineering understanding; the "Full" bar on Technical items is meaningfully higher than for schools.
• Open Innovation (startups/researchers): hardest bar on Applicability (2.x) and Impact (4.x) — they should show a credible path to real use or commercialization. Innovation is judged against the wider field, not just the region.
• Government Institution: judge Innovation (1.x) as novelty within public service delivery; weight citizen-impact (4.x) most heavily. Score real administrative/service improvement, not commercial novelty.

The committee may optionally change the weights per category (e.g. raise Impact for Government). If so, record it here before judging so all judges use one scheme.

---

B.7 — How the rubric applies across the four judging stages

The competition judges four times; you assess each item at the depth the stage allows. At early stages you score promise; at later stages you score delivery.

Stage	When	What you can fully assess
1. Abstract	Screening, 1–10 Sep	1.x, 2.x, 4.x as plans/plausibility; 3.x lightly; 5.x on the written abstract
2. Progress	Mid-term, ≈5 Oct	3.x now emerging; 2.x tightening; honesty of progress vs the plan
3. Product	Final assessment, 26–30 Oct	3.x and 2.x at full weight on the built MVP; 4.x now evidenced, not promised
4. Final Presentation	Grand Finale, 11 Nov	all items on the finished work; 5.x fully assessed live

A team that promised a lot at Abstract but delivered little by Product should see its later scores fall — that is the rubric working, not a penalty.

---

B.8 — FULLY WORKED EXAMPLE SCORECARD

The STRONG project (farmer pest-report voice app) at the Product stage. Each tick is the level whose example the submission most resembles:

Item	Tick		Item	Tick
1.1 Uncommon problem	Full 5		3.1 Approach fits	Full 5
1.2 Non-obvious AI	Full 5		3.2 Ethical data	Full 5
1.3 New combination	Full 5		3.3 Sound code	Half 2.5
1.4 Names difference	Full 5		3.4 Right complexity	Full 5
1.5 Not seen before	Half 2.5		4.1 Beneficiaries named	Full 5
2.1 Buildable	Full 5		4.2 Significant benefit	Full 5
2.2 Data obtainable	Full 5		4.3 Quantified	Half 2.5
2.3 Real user	Full 5		4.4 Regional	Full 5
2.4 Deployment realistic	Full 5		5.1 Clarity	Full 3
2.5 Constraints honest	Half 2.5		5.2 Demo works	Full 3
			5.3 Honest comms	Half 1
			5.4 Complete materials	Full 2

Criterion totals: C1 = 22.5 · C2 = 22.5 · C3 = 17.5 · C4 = 17.5 · C5 = 9 → TOTAL = 89 / 100.

Contrast — the WEAK project (cat-vs-dog classifier): almost every item matches the None example, with a couple at Half (e.g. 1.2 standard-use). Indicative total ≈ 21 / 100. In both cases the judge never invented a number — each tick matched a written example.

Calibration anchors: ~89 = excellent; ~21 = generic-but-functional. Most real submissions land between. Tick the matching example honestly and the score is automatic.

---

B.9 — Judge conduct (carried from the rules, Annex C)

• Declare any conflict of interest (your institution, a relative, a team you mentored) and recuse from scoring it.
• Treat every submission as confidential.
• Score independently first; the Judges' Secretariat Officer reconciles any criterion where judges diverge by more than 5 points.
• Decisions are final and binding. Write a one-line reason beside every Half/None tick so any score can be defended if queried.