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

The receipts 🧾

Every red flag on this statement, in full. These are the four places it bites.

1. Exhibit A

   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

2. It gets worse

   Backdoor detection under black-box access is genuinely hard and often unreliable, so overclaiming detection is exposable by an ML-security judge

3. Still reading?

   Distribution-shift versus deliberate manipulation is a subtle distinction, and conflating benign drift with an attack undermines the calibrated-risk requirement

4. And the finisher

   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

The damage report 📉

Every score this statement earned, and what each one actually costs you.

• Feasibility

  3/5

  Buildable. Not comfortably. There is a week in here you have not planned for yet.

  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

  There is something genuinely new here. Do not bury it under another dashboard.

  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

  The ask is unambiguous, which quietly removes your favourite excuse.

  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.

• Acceptance potential

  4/5

  Strong footing before you have written a line. Try not to waste it.

  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.

• Effort

  Massive

  A semester of work wearing a hackathon costume. Something is getting cut; decide what now, not in week five.

  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

  Demoable, if you rehearse it. Nobody rehearses it.

  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.

The demo they will have already seen 🪞

Somewhere around 70–160 teams are heading here, and the description is doing the choosing for most of them. They will read the same brief, reach the same architecture, and build a version of the same demo you are planning. Being correct is the floor. If your five minutes could be swapped with the team before you and nobody in the room would notice, you have not picked badly — you have built predictably, which costs exactly the same and hurts more.

What survives 🛡️

The ground worth standing on when the questions start.

• 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
• The required coverage statement of supported attacks and known limits rewards honesty, which is exactly the engineering judgement a serious judge wants to see
• The inference-provenance layer is deterministic cryptography, so that capability works reliably regardless of model accuracy