# InfraSence AI — Technical Project Report

Document ID: MF-2026-10-TPR-01  
Status: structured engineering draft; results not yet publication-approved  
Institution: MindforgeAI · Chatake Innoworks Private Limited

## Executive summary

AI-powered infrastructure sensing and structural health monitoring platform. This report records the engineering problem, evidence, implementation decisions, verification work and limitations without converting a prototype into an unsupported production claim.

## 1. Problem definition

Primary engineering question: **How can visual and inspection evidence support earlier structural-health decisions?**

### Required completion evidence

- user and stakeholder definition;
- measurable functional and non-functional requirements;
- explicit scope and exclusions;
- responsible-use and safety boundary.

## 2. Domain research and requirements

Insert reviewed domain sources, competing methods, user workflow, constraints and acceptance criteria. Every source must be cited and retained in the project research register.

## 3. Dataset, preprocessing and features

Record dataset origin, licence, schema, data dictionary, missing-value policy, exploratory analysis, leakage controls, preprocessing pipeline, feature rationale and train/validation/test split. If no dataset is used, document the equivalent sensor, rule, simulation or document corpus.

## 4. System and model architecture

Add a traceable architecture diagram covering inputs, storage, processing, model or rule layer, API, interface, monitoring and human decision points. Record environment versions and reproducible run commands.

Observed technology surface: Python, YOLOv8 model artifact.

## 5. Implementation and verification

Verified at 17 August 2026: YOLO-oriented source and a model artifact were observed.

Known limitation: Current Python cannot reproduce old pins; runtime imports and the canonical model do not align.

Next gate: Declare the supported Python version, complete dependencies and canonical YOLO asset.

Do not add accuracy, latency, scale, safety or deployment claims until the corresponding test artifact is linked in the evidence matrix.

## 6. Deployment and operations

Reserve evidence for environment configuration, secrets handling, infrastructure, health checks, logs, monitoring, rollback, privacy, accessibility and operating cost. A proposed Android application must remain a proposal until a reproducible build exists.

## 7. Results and discussion

Pending reproducible experiment outputs. Required table: metric, baseline, experiment configuration, result, uncertainty, artifact path and reviewer.

## 8. Limitations and future work

Current limitation: Current Python cannot reproduce old pins; runtime imports and the canonical model do not align.

Capstone continuation remains open after repository reconciliation, reproducibility review and programme approval.

## 9. Conclusion

Complete only after the evidence matrix supports the project objective.

## References and appendices

Use a consistent citation style. Append dataset cards, model cards, API specification, test report, screenshots, diagram sources and change log.