SIH26228: Trustworthy Computer Vision Integrity Assurance for Data, Models and Inference Outputs in — SIH 2026

SIH26228: Trustworthy Computer Vision Integrity Assurance for Data, Models and Inference Outputs in — SIH 2026

What they'll ask you

12

Generated from the brief's own wording and the competition's published rules — never from a guess about what this ministry prefers.

Specific cryptographic algorithms or hashing standards to use?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
Required performance execution time limits for large datasets?
The brief never answers this, so a panel will. Whatever you decide, say it the same way twice.
Has any part of this been shown at a previous event, hackathon or college project?
The guidelines are explicit: your solution must not have appeared in any previous event or programme, of any sort. A recycled project is what a team under time pressure reaches for.

9 more— the ones a panel gets to if there is time

The brief asks for training-data integrity checker. How would you build that?
Decoded from SIH26228 itself — Identifies suspicious samples, bad labels, and trigger injections while assessing overall contributor risk. The brief asks for it by name.
The brief asks for model integrity assessor. How would you build that?
Decoded from SIH26228 itself — Evaluates models for hidden backdoors or unauthorized substitutions using behavioural checks and parameter statistics. The brief asks for it by name.
The brief asks for inference provenance binder. How would you build that?
Decoded from SIH26228 itself — Creates cryptographic links using hashes and signatures to prevent tampering with input, model, and output records. The brief asks for it by name.
The brief asks for distribution-shift detector. How would you build that?
Decoded from SIH26228 itself — Measures material deviations caused by environmental changes like terrain or lighting, providing a calibrated risk score. The brief asks for it by name.
The brief asks for analyst dashboard and audit trail. How would you build that?
Decoded from SIH26228 itself — Displays human-readable risk reports with recommended dispositions and maintains a tamper-evident audit log. The brief asks for it by name.
Why not use what already exists? Name the closest thing to this that is already running.
A team that has not named the alternative themselves is answering this for the first time in the room.
Which single thing will you demonstrate end to end, start to finish, with nothing skipped?
Ours, not a rule: a narrow thing that fully works survives questioning better than a broad thing that half works. If nobody on the team can name it, that is the finding.
Show me this working: the jury will rigorously test whether the entire system operates completely offline in an air-gapped environment without cloud dependencies.
This is the evaluator read for your problem statement, decoded from the brief's own wording.
Show me this working: they will check if the framework correctly processes COCO or YOLO datasets and ONNX or PyTorch models while providing clear evidence and confidence scores for every warning.
This is the evaluator read for your problem statement, decoded from the brief's own wording.

Take this to an AI

Pick what you are about to do and copy the prompt. It carries the organisers' own wording, the constraints they never spell out, and an instruction not to invent requirements they never set.

Who has this problem, what already exists, and what you would have to find out.

# Context: India's Smart India Hackathon 2026

I am on a student team entering SIH 2026. Problem statement SIH26228, set by Ministry of defence (MoD).
Its official title, word for word: "Trustworthy Computer Vision Integrity Assurance for Data, Models and Inference Outputs in Multi-Contributor Pipelines"
Theme: Blockchain & Cybersecurity. Category: software.

In plain terms: A software framework that lets analysts verify the integrity of computer vision data, models, and inference outputs in an offline, air-gapped environment.

## The organisers' full description, verbatim

2. Description. 
2.1. Background. Operational computer vision pipelines may combine training data from multiple contributors, pretrained or vendor-supplied models, and inference outputs consumed by downstream systems. This creates distinct integrity and assurance risks across the data, model and inference lifecycle. Data may contain deliberately or inadvertently mislabelled samples, duplicated content, out-of-distribution material or trigger-based backdoors. A model may be substituted, modified or contain hidden behaviour that is not apparent during routine validation. Inference records may also be replayed, replaced or altered after generation unless they are cryptographically linked to the exact input, model and processing chain that produced them. Existing controls often address only individual parts of this lifecycle. The challenge is therefore to create a unified, evidence-based assurance layer that can assess these risks without assuming that every contributing source is trusted. of Fos 
2.2. Detailed Description.
Teams are required to build an extensible computer-vision assurance framework that can evaluate a contributed dataset, a trained model and associated inference records, and produce an evidence-based assessment of integrity and risk. The solution should not be hard-coded to a single model architecture or dataset. Five core capabilities are required. 
      2.2.1. Training-Data Integrity. Identify suspicious or anomalous samples associated with trigger injection, label flipping, systematic mislabelling, near-duplicate flooding and out-of-distribution insertion. Where contributor, batch or source metadata is available, the system should aggregate sample-level evidence into a source-level risk assessment rather than flagging samples in isolation.
     2.2.2. Model Integrity. Assess whether a supplied model exhibits anomalous, substituted or backdoor-like behaviour using methods appropriate to the level of access available. Approaches may include behavioural fingerprinting, trigger search or reconstruction, parameter or activation statistics, and comparison against a defined reference battery. The system must state the access assumptions, confidence and limitations of its assessment. 
     2.2.3. Inference Provenance and Output Integrity. Create a verifiable cryptographic binding among the input image, model identifier or weight digest, preprocessing and inference configuration, and resulting output. The design should make post-hoc alteration, substitution or replay of protected inference records detectable through hashes, signatures and appropriate sequence, timestamp or nonce controls. 
      2.2.4. Distribution-Shift and Anomaly Assessment. Detect material deviation from a declared reference distribution, including changes caused by terrain, season, sensor, illumination or acquisition conditions. The system should characterise the observed shift, provide a calibrated risk or confidence score, and distinguish probable operational drift from suspicious manipulation where the available evidence supports such a distinction.
     2.2.5. Analyst-Facing Assurance and Governance. Every flag must include a human-readable reason, supporting evidence, confidence or severity, the affected asset, and a recommended disposition such as accept, review or quarantine. The solution must maintain a tamper-evident audit trail and explicitly declare attack classes or conditions that it does not support.

     2.2.6. Constraints, the complete evaluation workflow must operate offline and in an air-gapped environment with no dependency on cloud services or external APIs. The solution should ingest common computer-vision dataset formats, including COCO and YOLO, and support the organiser-defined reference model formats, including ONNX and PyTorch/TorchScript. Baseline integrity assessment must not require retraining of the contributed model, although optional remediation may use retraining. Methods that require white-box access must fall back gracefully or clearly report that the relevant assessment is unavailable when only black-box access is provided.

2.3 Expected Solution. 
Teams are expected to develop a model-agnostic assurance system for assessing the integrity of training data, trained computer-vision models and inference outputs. The solution shall use publicly available or team-generated datasets and models, with teams developing reproducible methods to introduce representative poisoning, backdoor, substitution and tampering scenarios for testing. The system should identify suspicious data or contributor behaviour, assess model integrity, detect tampering of inference records, provide supporting evidence for each finding, and generate a clear assurance report stating confidence, limitations and recommended action. Each team must submit the source code, architecture and setup notes, the assurance-report schema, a reproducible audit log, and a clear coverage statement identifying supported attack classes, assumptions and known limitations.

## What the brief never says

- specific cryptographic algorithms or hashing standards to use
- required performance execution time limits for large datasets
## Constraints that are not negotiable

- The judged build is a prototype demonstrated in roughly 36 hours by students, not a product.
- A jury evaluates it against this problem statement's own wording, not against general merit.
- We submit on sih.gov.in; the problem statement number and title above must match exactly.
- Your solution must not have appeared in any previous event or programme, of any sort.
- The organisers attached a dataset, so build against theirs rather than inventing one.

## What I want from you

1. Who actually has this problem in India, and what they do about it today.
2. What already exists — government systems, open-source projects, published research — that we should not rebuild.
3. For each item under 'what the brief never says', what the realistic answer is likely to be and how I could verify it.
4. The two or three things about this domain that a student team would get wrong without local knowledge.
## How to answer

- Everything above between quotation marks is the organisers' own wording. Treat it as the requirement.
- Do NOT invent requirements the brief does not state. If something matters and is not stated, say so and ask me, rather than assuming.
- Where you are inferring rather than reading, mark it as your inference.
- Do not guess what this ministry wants from its name. Its wording above is the only evidence.

---
Problem statement facts assembled by Wynit from Ministry of defence (MoD)'s published brief for SIH 2026.
The plain-English summary, the list of parts and the evaluator read are our interpretation of that text; the quoted title and the full description are theirs.

The government's original description (650 words)

2. Description. 2.1. Background. Operational computer vision pipelines may combine training data from multiple contributors, pretrained or vendor-supplied models, and inference outputs consumed by downstream systems. This creates distinct integrity and assurance risks across the data, model and inference lifecycle. Data may contain deliberately or inadvertently mislabelled samples, duplicated content, out-of-distribution material or trigger-based backdoors. A model may be substituted, modified or contain hidden behaviour that is not apparent during routine validation. Inference records may also be replayed, replaced or altered after generation unless they are cryptographically linked to the exact input, model and processing chain that produced them. Existing controls often address only individual parts of this lifecycle. The challenge is therefore to create a unified, evidence-based assurance layer that can assess these risks without assuming that every contributing source is trusted. of Fos 2.2. Detailed Description. Teams are required to build an extensible computer-vision assurance framework that can evaluate a contributed dataset, a trained model and associated inference records, and produce an evidence-based assessment of integrity and risk. The solution should not be hard-coded to a single model architecture or dataset. Five core capabilities are required. 2.2.1. Training-Data Integrity. Identify suspicious or anomalous samples associated with trigger injection, label flipping, systematic mislabelling, near-duplicate flooding and out-of-distribution insertion. Where contributor, batch or source metadata is available, the system should aggregate sample-level evidence into a source-level risk assessment rather than flagging samples in isolation. 2.2.2. Model Integrity. Assess whether a supplied model exhibits anomalous, substituted or backdoor-like behaviour using methods appropriate to the level of access available. Approaches may include behavioural fingerprinting, trigger search or reconstruction, parameter or activation statistics, and comparison against a defined reference battery. The system must state the access assumptions, confidence and limitations of its assessment. 2.2.3. Inference Provenance and Output Integrity. Create a verifiable cryptographic binding among the input image, model identifier or weight digest, preprocessing and inference configuration, and resulting output. The design should make post-hoc alteration, substitution or replay of protected inference records detectable through hashes, signatures and appropriate sequence, timestamp or nonce controls. 2.2.4. Distribution-Shift and Anomaly Assessment. Detect material deviation from a declared reference distribution, including changes caused by terrain, season, sensor, illumination or acquisition conditions. The system should characterise the observed shift, provide a calibrated risk or confidence score, and distinguish probable operational drift from suspicious manipulation where the available evidence supports such a distinction. 2.2.5. Analyst-Facing Assurance and Governance. Every flag must include a human-readable reason, supporting evidence, confidence or severity, the affected asset, and a recommended disposition such as accept, review or quarantine. The solution must maintain a tamper-evident audit trail and explicitly declare attack classes or conditions that it does not support. 2.2.6. Constraints, the complete evaluation workflow must operate offline and in an air-gapped environment with no dependency on cloud services or external APIs. The solution should ingest common computer-vision dataset formats, including COCO and YOLO, and support the organiser-defined reference model formats, including ONNX and PyTorch/TorchScript. Baseline integrity assessment must not require retraining of the contributed model, although optional remediation may use retraining. Methods that require white-box access must fall back gracefully or clearly report that the relevant assessment is unavailable when only black-box access is provided. 2.3 Expected Solution. Teams are expected to develop a model-agnostic assurance system for assessing the integrity of training data, trained computer-vision models and inference outputs. The solution shall use publicly available or team-generated datasets and models, with teams developing reproducible methods to introduce representative poisoning, backdoor, substitution and tampering scenarios for testing. The system should identify suspicious data or contributor behaviour, assess model integrity, detect tampering of inference records, provide supporting evidence for each finding, and generate a clear assurance report stating confidence, limitations and recommended action. Each team must submit the source code, architecture and setup notes, the assurance-report schema, a reproducible audit log, and a clear coverage statement identifying supported attack classes, assumptions and known limitations.