SIH26228Strong pickacceptance 4/5

Trustworthy Computer Vision Integrity Assurance for Data, Models and Inference Outputs in Multi-Contributor Pipelines

Ministry of defence (MoD) · Blockchain & Cybersecurity · Software

Excellently specified ML-security work with no data barrier and a thin field — depth on three capabilities plus a genuinely honest coverage statement beats shallow breadth across all five, and the inference-provenance layer gives you one deterministic, unarguable win.

Data: Public or team-generated datasets/models; teams inject poisoning/backdoor/tampering scenarios

What it actually is

A computer-vision pipeline may combine training data from many contributors, a vendor-supplied model, and inference outputs that downstream systems trust — and any of those can be poisoned, backdoored, substituted or tampered with. The ask is a single assurance layer that inspects a contributed dataset, a trained model and its inference records and produces evidence-based risk assessments, without assuming any source is trusted and without being tied to one architecture.

What to build

A model-agnostic assurance framework with five capabilities: training-data integrity that flags trigger injection, label flipping, near-duplicate flooding and out-of-distribution insertion and aggregates sample evidence into a per-contributor risk score; model integrity that detects substitution or backdoor-like behaviour via behavioural fingerprinting, trigger search, or parameter/activation statistics against a reference battery, degrading gracefully under black-box access; inference provenance that cryptographically binds input, model digest, preprocessing config and output so replay or post-hoc alteration is detectable; distribution-shift assessment that separates benign operational drift from suspicious manipulation with a calibrated score; and an analyst-facing governance layer where every flag carries a human-readable reason, evidence, severity, affected asset and disposition (accept/review/quarantine) with a tamper-evident audit trail — all running air-gapped and ingesting COCO/YOLO data and ONNX/TorchScript models.

Smallest thing that wins the room

Feed the framework a dataset you have poisoned with a backdoor trigger and a cleanly labelled one, and show it flagging the poisoned contributor with sample-level evidence, then feed a substituted model and show the integrity check catching the anomalous behaviour, each with a human-readable assurance report and confidence.

How crowded this one gets

A guess, projected from the 2025 statements — the last year where both the submission counts and the winners were published.

Quiet70–160 teams expectedroughly 1 in 60–139 wins it

Quieter than 78% of the 240 · #54 of 240 by expected field

Few teams are likely to go here. The best odds on the board come from statements like this.

Why: defence, intelligence and space bodies drew small fields.

This is a guess, not a fact

Nobody has published 2026’s numbers yet. This is an analysed estimate from last year’s pattern, so please do not take it as the truth — check the live counter on the SIH portal before you decide anything. The range covers the middle half of likely outcomes, so one statement in two lands outside it. Entry closes at 500 ideas per statement, so no range goes past that — a statement that reaches the cap fills and shuts rather than drawing an unlimited crowd. The model reads only three things a team can see before choosing — software or hardware, the theme, and what kind of body posted it — and those explain about a quarter of the variation in last year’s field sizes (R² 0.25 on held-out statements). Trust the band more than the number, and the ordering more than either. It cannot see how good your idea is, which is the part that actually decides it.

The scores

The number is the shorthand. The line under it is the reason.

Acceptance potential

4/5

A strong pick — the spec is excellent, teams generate their own attack scenarios so there is no data barrier, the field is thin because ML security intimidates most teams, and the required coverage statement rewards honesty about limits, though the breadth across five capabilities plus dual access models is demanding and a shallow build across all five reads worse than depth on three.

Feasibility

3/5

The building blocks exist — backdoor-detection research (spectral signatures, activation clustering, Neural Cleanse), OOD detection, hashing and signing — and teams generate their own poisoning scenarios, but assembling all five capabilities into a model-agnostic framework that works under both white-box and black-box access is a large, genuinely research-adjacent build.

Innovation scope

4/5

Unifying data, model and inference integrity into one evidence-based, contributor-aware assurance layer that does not assume trust is genuinely open — existing controls address these in isolation, and the aggregation of sample evidence into source-level risk plus the graceful white/black-box fallback is real design space.

Clarity

5/5

Exceptionally precise: five numbered capabilities, named attack classes, explicit access-model handling, required formats (COCO/YOLO, ONNX/TorchScript), the no-retraining-for-baseline constraint, the air-gapped requirement, and a required coverage statement of supported attacks and limitations.

Effort

Massive

Data-poisoning detection, model-backdoor detection, cryptographic inference provenance, distribution-shift assessment and a governance/audit layer is five substantial subsystems spanning ML security and cryptography.

Demo-ability

Medium

Catching a poisoned contributor and a substituted model with evidence is a clear, credible story, but the concepts are abstract and need explaining before a general audience grasps why each flag matters — an ML-security judge will follow it instantly.

In its favour

Green flag: Teams generate their own poisoning, backdoor and tampering scenarios, so there is no data-sourcing barrier and the test cases are fully in your control
Green flag: The required coverage statement of supported attacks and known limits rewards honesty, which is exactly the engineering judgement a serious judge wants to see
Green flag: The inference-provenance layer is deterministic cryptography, so that capability works reliably regardless of model accuracy
Green flag: ML security is intimidating enough to guarantee a thin field of serious competitors

Against it

Red flag: Five capabilities spanning ML security and cryptography is a lot, and building all five shallowly reads worse than three done properly with an honest coverage statement
Red flag: Backdoor detection under black-box access is genuinely hard and often unreliable, so overclaiming detection is exposable by an ML-security judge
Red flag: Distribution-shift versus deliberate manipulation is a subtle distinction, and conflating benign drift with an attack undermines the calibrated-risk requirement
Red flag: Everything must run air-gapped and be model-agnostic, so a solution hard-coded to one architecture or leaning on a cloud service fails the constraints

What you will be writing

Backdoor detection (Neural Cleanse, spectral signatures, activation clustering)
Data poisoning / label-flip / OOD detection
Model fingerprinting + parameter/activation statistics
Cryptographic inference binding (hash + signature + nonce)
Distribution-shift / drift detection with calibration
Tamper-evident audit log; ONNX / TorchScript ingestion
ML security
Computer vision assurance
Supply-chain integrity

Prior art to read before you start

data poisoning and backdoor detection · model integrity verification · cryptographic inference provenance

Analysed by Claude Opus. Every score above is a judgment call with its reasoning attached — kindly cross-check this against the official statement on the SIH portal before your team commits to it.