Resubmissions, duplicates and lineage

In short. Most duplicate submissions are honest. A form times out, a co-founder does not know their teammate already applied, an applicant fixes a typo by starting again. Treat every duplicate as an integrity case and you will punish the wrong people; ignore them and evaluators will score the same venture twice. The workable middle is a lineage chain: one active version per venture, every earlier version retained and linked, and a written rule about which one is scored.

Why teams resubmit

In a call with 181 submissions from 170 teams, the eleven extra records are worth understanding individually before any rule is applied to them. The reasons cluster.

Recovery. The applicant lost a draft, or believed they had. Server-side drafts have made this rarer, but a team that started on a shared laptop and finished on a phone will often start again rather than trust that the draft is still there.

Correction. The application went in with the wrong deck attached, a mistyped budget, or last year's team list. The applicant cannot edit after submission — or thinks they cannot — so they submit a corrected copy and hope somebody notices.

Uncoordinated co-founders. Two members of the same team each believed they were the one applying. This produces two near-identical records with different contact emails, and it is the case most likely to be misread as gaming.

Category shopping. The same venture submitted to two tracks of the same call, sometimes with the pitch rewritten for each. This is the one case that usually does need a rule, and the rule should be in the call document rather than invented afterwards.

Genuine iteration across calls. A team that applied in the 2025 round and is applying again in 2026 with a materially different proposal. This is not a duplicate at all. It is history, and it is useful history — but only if the earlier record is linked rather than buried.

Duplicate is not one thing

Four distinct situations get filed under one word, and they need four different handlings.

Collapsing these into "flag and reject" is the mistake. So is collapsing them into "keep both", which is how an evaluator ends up scoring #0142 on Tuesday and #0118 on Thursday without noticing they are the same venture.

Detecting duplicates fairly

Detection should be a signal that surfaces cases for a human to read, never a rule that acts on its own. Four signals do most of the work:

• Contact identity. Same applicant email, same phone number, same institutional identifier. High precision, poor recall, because co-founders differ.
• Team and venture name. Normalised for case, punctuation and the usual suffixes. Catches co-founder duplicates that contact identity misses, and produces false positives on common words.
• Content similarity. Overlap across the long free-text answers and the attached deck. This is what catches a rewritten resubmission, and it is also where a threshold has to be chosen carefully.
• Timing. Two records from the same team within a short window are almost always recovery or correction, not strategy.

Fairness comes from four disciplines. Surface the match with its reason attached, so a reviewer sees why two records are paired rather than a bare flag. Set a similarity threshold high enough that boilerplate — the same institute address, the same standard consent text, the same policy paragraph everyone copies from the call document — does not trigger it. Ask the applicant before concluding anything: a one-line message resolves most cases in a day. And log the outcome, because the one case in fifty that becomes a dispute will be decided by whether there is a record.

Never auto-reject on a similarity score. The false positive rate on free text is high enough that a rejection produced this way will eventually be wrong in a way that is visible and embarrassing.

A worked case: #0142 and #0118

Case #0118 arrives on day 9 of a four-week window: a hardware venture, a three-person team, a deck attached, the budget section left at the default values. Case #0142 arrives on day 23: same venture name, a different contact email, a fuller budget, a new deck, and one team member removed.

Content similarity across the long-answer fields is high; contact identity does not match; team name matches after normalisation. The system pairs them and shows both reasons.

The reviewer opens both dossiers side by side and reads the difference: the second record is a corrected and improved version submitted by a different co-founder. There is no track-shopping and no attempt to obtain two reads. A message goes to both contacts asking which record should stand, and the team confirms #0142.

The resolution: #0142 becomes the active submission and inherits the lineage; #0118 is marked superseded with the reason and the reviewer's name, remains readable to programme staff, and disappears from the evaluator queue. The team's application count stays at one. The lineage entry records that #0142 supersedes #0118, who decided, when, and on what evidence.

What the committee sees later is one entry with a small lineage marker, and a two-line audit note if they ask. What the evaluators see is one application.

Keeping a lineage chain

A lineage chain is simply the ordered list of records belonging to one venture, with a single active member. Four properties make it worth having:

1. One active version. Everything else is superseded, not deleted. Deleting destroys the only defence against a later dispute.
2. A reason on every link. Recovery, correction, co-founder duplicate, track rule, cross-call history. Two words is enough; nothing is worse than a link with no explanation.
3. A person and a timestamp. Who decided, and when. Automated pairing is a suggestion; a human resolves it.
4. Cross-call continuity. A team that applied in 2025 and again in 2026 should show as one venture with two applications, because that is genuinely useful context for an evaluator — a team that has responded to last year's feedback is a different proposition from a first-time applicant.

The chain should be visible in the dossier and invisible in the scoring view, which is the next point.

What to tell evaluators

As little as possible about mechanics, and nothing that prejudices a read.

Evaluators should see exactly one version of an application: the active one. They do not need the superseded record, and they should not be asked to weigh whether a resubmission was legitimate — that is programme staff's decision, made before assignment.

There are two exceptions worth stating in the evaluator briefing. Where an application is a repeat from a previous call, evaluators may be told so and given the earlier decision if the programme's rules allow it, because progress since the last attempt is a legitimate consideration. And where a duplicate was resolved after some scores already existed, the affected evaluators should be told plainly that their scores were moved to the active record, rather than discovering it on the leaderboard.

Blind review complicates this. If the round is blind, the lineage marker must not carry the team name or the earlier contact details; "prior application in the 2025 call" is enough.

Rules worth writing down

Put these in the call document, before the window opens:

• Whether editing after submission is permitted, and until when. This alone removes most correction duplicates.
• What happens if a team submits twice to the same track: the later record stands, the earlier is superseded.
• Whether a venture may apply to more than one track, and what happens if it does.
• That applications are checked for duplicates and that applicants will be contacted before any record is set aside.
• That superseded records are retained for the audit trail and not disclosed to evaluators.

In IdeaScore these arrive as flags on the submissions table with the matching reason shown, a side-by-side dossier view, and a supersede action that carries the reason into the audit log. The flag is the easy part. The rule in the call document, written before anybody submits anything, is what makes the decision defensible six months later when a team asks why their first attempt disappeared.