Development of a Software Program/Application for Generation of Test Reports for Non-Automatic Weighing Instruments (NAWI) as per OIML Recommendation R- 76

1. Executive Snapshot

Non-Automatic Weighing Instruments (NAWIs)—such as retail electronic scales, platform scales, and heavy weighbridges—form the backbone of trade, agriculture, healthcare, and industrial commerce in India [PS]. Under the Legal Metrology Act, 2009 and the Legal Metrology (General) Rules, 2011, all NAWIs must undergo rigorous type evaluation and model approval by designated testing laboratories (such as Regional Reference Standard Laboratories [RRSLs] and NPL India) prior to commercial deployment [PS, KNOWN]. Currently, laboratory metrologists evaluate NAWIs against the international standard OIML R 76 using manual spreadsheets or Word templates [PS]. This manual process leads to high calculation error rates, lack of standardized reporting formats, long processing backlogs, and risk of data tampering [PS, INFERENCE]. This dossier presents MetroSpec-R76, an offline-first, web-and-desktop application designed to digitize, automate, and streamline NAWI type evaluation, compliance calculation, report generation, and archival for the Department of Consumer Affairs (DoCA) [INFERENCE, ASSUMPTION].

Fundamental System Objective: To deliver an offline-capable, cryptographically secure digital metrology platform that automates OIML R 76 test observation recording, computes Maximum Permissible Errors (MPE) and compliance deterministically, and generates tamper-evident standardized reports in PDF and DOCX formats for DoCA model approvals [PS, INFERENCE].

2. Problem Deconstruction

The explicit problem statement was extracted into 15 atomic requirements, maintaining exact fidelity to the official problem text:

1. R1: Capture Instrument & Technical Specifications

   • Source Text: "Capturing instrument details and technical specifications... Entry of manufacturer details, Instrument specifications, Model information and technical parameters" [PS]
   • Interpretation: System must provide digital forms to record manufacturer details (name, address, trade mark), instrument parameters (model, serial number, accuracy Class I/II/III/IIII, Max capacity, Min capacity, verification scale interval $e$, actual scale interval $d$, number of scale intervals $n = \text{Max}/e$), load cell details, and indicator specs [PS, KNOWN].
   • Implementation Implication: Dynamic form validation where $n$ is automatically derived as $\text{Max}/e$ and validated against class bounds ($n \le 10,000$ for Class III) [INFERENCE].
   • Confidence: [PS]

2. R2: Record Environmental & Laboratory Conditions

   • Source Text: "Recording laboratory and environmental conditions." [PS]
   • Interpretation: Capture ambient temperature ($^\circ\text{C}$), relative humidity ($%$), atmospheric pressure ($\text{hPa}$), power supply voltage ($\text{V}$), frequency ($\text{Hz}$), laboratory name, location, test equipment/standard weights used, and testing date/time [PS, KNOWN].
   • Implementation Implication: Environmental limits checking (e.g., flagging temperature variation $> 5^\circ\text{C/h}$ during accuracy tests as an OIML R 76 violation) [INFERENCE].
   • Confidence: [PS]

3. R3: Entry of OIML R 76 Test Observations

   • Source Text: "Entering observations from various OIML R 76 test procedures... Entry of observations for all prescribed tests" [PS]
   • Interpretation: Input forms for all mandatory OIML R 76 tests: Zero-setting/Zero-tracking, Weighing Performance (increasing/decreasing load curve), Discrimination, Repeatability, Eccentricity (off-centre loading), Tare balancing, Warm-up time, Tilt test, Temperature effect on no-load, and Voltage variation [PS, KNOWN].
   • Implementation Implication: Matrix input fields accepting load $L$, indicated value $I$, and change-point weight $\Delta L$ for exact rounding-error adjustment [INFERENCE].
   • Confidence: [PS]

4. R4: Automated Permissible Error (MPE) & Compliance Calculation

   • Source Text: "Automatically calculating permissible errors, and compliance status... Compliance determination as per OIML R-76" [PS]
   • Interpretation: Core deterministic engine calculating indication before rounding $P = I + 0.5e - \Delta L$, error $E = P - L$, zero-corrected error $E_c = E - E_0$, and checking $|E_c| \le |\text{MPE}|$ based on load step boundaries [PS, KNOWN].
   • Implementation Implication: Pure mathematical rule engine with zero floating-point rounding inaccuracies (using decimal fixed-point arithmetic) [INFERENCE].
   • Confidence: [PS]

5. R5: Input Data Validation Checks

   • Source Text: "Performing validation checks for entered test data... Automatic validation of input data and related calculations" [PS]
   • Interpretation: Real-time sanity checks preventing illogical entries (e.g., $I > \text{Max} + 9e$, negative loads, load steps exceeding standard weight inventory, or missing mandatory fields) [PS, INFERENCE].
   • Implementation Implication: Form-level client-side validation paired with backend server-side validation rules [INFERENCE].
   • Confidence: [PS]

6. R6: Automated Pass/Fail Determination

   • Source Text: "Automatically determining pass/fail criteria based on OIML R 76 requirements." [PS]
   • Interpretation: Overall evaluation combining individual test results; if any single test fails MPE or technical requirement, the overall report status evaluates to "FAIL" [PS, INFERENCE].
   • Implementation Implication: Decision tree aggregator giving clear breakdown of pass/fail reasons per clause of OIML R 76 [INFERENCE].
   • Confidence: [PS]

7. R7: Standardized Report Generation (PDF & Editable)

   • Source Text: "Generating standardized digital test reports in printable formats... Standardized test report generation in PDF and editable formats MS Word etc... Export to PDF and editable formats" [PS]
   • Interpretation: Export reports strictly matching OIML R 76-2 (Test Report Format) layout in both non-editable vector PDF (for legal filing) and editable DOCX (for lab customization) [PS, RESEARCHED].
   • Implementation Implication: Templated rendering engine (Puppeteer/PDFKit for PDF, docx node library for Word) auto-populating laboratory headers, test tables, and charts [INFERENCE].
   • Confidence: [PS]

8. R8: Digital Repository & History Management

   • Source Text: "Maintaining a digital repository of completed test reports... Instrument-wise test history and report repository." [PS]
   • Interpretation: Searchable centralized and local archive storing all past evaluation records indexed by instrument serial number, model, manufacturer, test date, and lab [PS].
   • Implementation Implication: Structured database with indexing on instrument_id, model_no, manufacturer_id, and created_at [INFERENCE].
   • Confidence: [PS]

9. R9: Role-Based Access Control (RBAC)

   • Source Text: "Providing secure user access with role-based permissions." [PS]
   • Interpretation: Secure login with distinct permission scopes: Metrologist/Tester (data entry), Senior Metrologist/Approver (review & sign-off), Admin (user management & system config), and Manufacturer/Viewer (read-only certificate access) [PS, INFERENCE].
   • Implementation Implication: JWT authentication with fine-grained Role-Based Access Control Middleware [INFERENCE].
   • Confidence: [PS]

10. R10: Support for Future OIML Revisions

    • Source Text: "Supporting future updates whenever OIML recommendations are revised." [PS]
    • Interpretation: Calculation formulas, MPE threshold tables, and test clauses must not be hardcoded, but configured via externalized rule definition files (JSON/YAML rule schema) [PS, INFERENCE].
    • Implementation Implication: Versioned Rule Engine (e.g., OIML_R76_2006.json, OIML_R76_2024_Draft.json) selectable per evaluation job [INFERENCE].
    • Confidence: [PS]

11. R11: Dashboard for Testing Activities

    • Source Text: "Dashboard for monitoring testing activities and report status... Dashboard for test report management (completed, in process, history access etc.)" [PS]
    • Interpretation: Executive and operational dashboard displaying metrics: active testing jobs, pending approvals, pass/fail ratios, turnaround times, and report status pipeline [PS, INFERENCE].
    • Implementation Implication: Real-time dashboard with filters for date range, laboratory branch, and accuracy class [INFERENCE].
    • Confidence: [PS]

12. R12: Search & Retrieval Facility

    • Source Text: "Search and retrieval facility for previously generated reports." [PS]
    • Interpretation: Full-text search and multi-parameter filtering (by model approval application number, manufacturer name, test date range, compliance status) [PS].
    • Implementation Implication: PostgreSQL Full-Text Search / Elasticsearch index over evaluation metadata [INFERENCE].
    • Confidence: [PS]

13. R13: Supporting Documents & Photo Attachments

    • Source Text: "Attachment of photographs and supporting documents" [PS]
    • Interpretation: Ability to upload and embed photos of instrument nameplate, sealing arrangement, load cell setup, indicator screen, and calibration weight certificates [PS, INFERENCE].
    • Implementation Implication: S3-compatible Object Storage integration with image compression and embedding directly into generated PDF/DOCX reports [INFERENCE].
    • Confidence: [PS]

14. R14: Digital Signatures

    • Source Text: "Digital signatures (optional)" [PS]
    • Interpretation: Cryptographic sign-off mechanism allowing approving metrologists to sign test reports using PKI x509 certificates / DSC tokens or eSign [PS, KNOWN].
    • Implementation Implication: PDF signature injection (PAdES standard) verifying report authenticity and preventing post-approval alteration [INFERENCE].
    • Confidence: [PS]

15. R15: Comprehensive Technical Documentation

    • Source Text: "Technical documentation describing software architecture, calculation methodology and deployment framework." [PS]
    • Interpretation: Submission bundle must include architectural diagrams, OIML R 76 math specification, API reference, and deployment deployment guide [PS].
    • Implementation Implication: Automated OpenAPI docs (Swagger) + structured Markdown developer documentation repository [INFERENCE].
    • Confidence: [PS]

3. Stakeholders & User Needs

4. Requirements Traceability

5. Constraints & Environment Realities

1. Laboratory & Field Testing Conditions:

   • Physical Constraints: NAWI testing takes place in specialized reference laboratories (RRSLs) or field sites (e.g., heavy industrial weighbridges, granaries, mining sites) [KNOWN].
   • Connectivity: Testing pits and heavy industrial sites frequently lack mobile network coverage or Wi-Fi [INFERENCE].
   • Operating System & Hardware: Testing labs utilize standard Windows desktop PCs, laptops, or rugged field tablets [KNOWN]. Systems must not require high-end GPUs or massive RAM [INFERENCE].

2. Metrological & Legal Rigor:

   • Zero Margin for Math Error: Metrological conformity assessment is legally binding [KNOWN]. Floating-point roundoff errors inherent in basic JavaScript/Python floats ($0.1 + 0.2 = 0.30000000000000004$) are strictly unacceptable [INFERENCE].
   • Non-Repudiation: Test reports used for Model Approval are legal certificates [KNOWN]. Once approved, data must be immutable and verifiable against tampering [INFERENCE].

3. User Literacy & Operational Reality:

   • Metrologists are domain experts in physics and metrology, not software engineers [INFERENCE]. UX must feature clear metrological terminology (e.g., $e$, $d$, MPE, $\Delta L$, Tare), zero cluttered UI, and intuitive step-by-step navigation corresponding to OIML R 76 test sequence [INFERENCE].

6. Research Questions

1. RQ1: What are the exact maximum permissible error (MPE) step boundaries for Class I, II, III, and IIII non-automatic weighing instruments under OIML R 76-1:2006?
   • Status: Verified via OIML R 76-1 standards [RESEARCHED].
2. RQ2: How does OIML R 76 calculate the true indication before rounding ($P$) using the additional weight change-point method ($\Delta L$)?
   • Status: Verified formula $P = I + 0.5e - \Delta L$ [RESEARCHED].
3. RQ3: What is the standard structure of the OIML R 76-2 Test Report Format, and what mandatory checklist items must be included?
   • Status: Verified structure includes Summary, Technical Data, Test Results (A.1 to A.8), and Checklists [RESEARCHED].
4. RQ4: How does the Department of Consumer Affairs manage Model Approval applications through the central eMaap / LMIS portal?
   • Status: Verified eMaap portal operational since Feb 2025 integrating state and central legal metrology workflows [RESEARCHED].
5. RQ5: What open-source document generation libraries preserve exact vector layout for high-density tabular metrology reports in both PDF and DOCX formats?
   • Status: Evaluated Puppeteer (HTML-to-PDF) and docx JS library [RESEARCHED].

7. Data Requirements & Sources

8. Existing Solutions & Gap Analysis

9. Candidate Solution Approaches

Approach 1: Monolithic Desktop Application (Electron + SQLite)

• Mechanism: Standalone desktop app packaged via Electron/React or Python PyQT, storing evaluation reports in a local SQLite database [ASSUMPTION].
• Pros: Completely offline operation; native file system access for local Word/PDF export; responsive UI [INFERENCE].
• Cons: Central dashboard requires manual export/import files; difficult to manage software updates across multiple regional labs; no centralized DoCA repository [INFERENCE].
• Hackathon Feasibility: High | Production Feasibility: Medium.

Approach 2: Pure Cloud-Native Web Application (React + FastAPI + PostgreSQL)

• Mechanism: Web portal hosted on cloud server (e.g., NIC Cloud / AWS), requiring active internet connection for all testing operations [ASSUMPTION].
• Pros: Instant centralized repository; real-time DoCA dashboard; simple software updates; seamless eMaap portal integration [INFERENCE].
• Cons: Fails completely when metrologists conduct tests in air-gapped labs or offline field locations (weighbridges) without active internet [INFERENCE].
• Hackathon Feasibility: High | Production Feasibility: Low (due to offline field constraint).

Approach 3: Hybrid Offline-First Progressive Web App (PWA) with Desktop Wrapper & Central Sync (RECOMMENDED)

• Mechanism: Modern Web / PWA frontend (React + TypeScript) compiled for web browser access and packaged via Electron/Tauri for desktop deployment. Utilizes local IndexedDB (via RxDB/PouchDB) for full offline data entry, calculations, and local PDF/Word generation. Automatically synchronizes with a central PostgreSQL cloud backend whenever network connectivity is detected [INFERENCE, ASSUMPTION].
• Pros: Uncompromised offline field testing capability; immediate local report generation; centralized DoCA repository and analytics on cloud sync; zero vendor lock-in [INFERENCE].
• Cons: Slightly higher technical complexity in implementing conflict-free offline synchronization logic [INFERENCE].
• Hackathon Feasibility: High | Production Feasibility: High.

10. Recommended Approach & Why

Selected Solution: Approach 3 (Hybrid Offline-First PWA with Centralized Cloud Synchronization) [INFERENCE, ASSUMPTION].

Why Alternatives Were Rejected:

• Monolithic Desktop Application (Approach 1) was rejected because it creates isolated data silos in each testing laboratory. It fails Requirement R8 and R11 by preventing central DoCA supervisors from monitoring national testing pipelines and maintaining an integrated search repository without manual batch file transfers [PS, INFERENCE].
• Pure Cloud Web Application (Approach 2) was rejected because legal metrology testing frequently occurs in shielded laboratory environments or underground weighbridge pits where internet connectivity is non-existent [KNOWN, INFERENCE]. Requiring an active connection would cause app crashes and data loss during 5-hour testing procedures [INFERENCE].

Approach 3 wins because it satisfies every explicit requirement in the SIH PS: local offline operation for metrologists, deterministic automated calculations, instant PDF/Word generation, role-based access, and centralized repository/dashboard sync for DoCA administrators [PS, INFERENCE].

11. Technical Architecture

Layered Architecture Diagram

+-----------------------------------------------------------------------------------+
|                            CLIENT LAYER (PWA / DESKTOP)                           |
|  +-----------------------------------+   +-------------------------------------+  |
|  |   React / TypeScript Single Page  |   |    Electron Desktop Shell (Tauri)   |  |
|  |   UI Components (Tailwind CSS)    |   |    Local File System & Print API    |  |
|  +-----------------------------------+   +-------------------------------------+  |
|  +-----------------------------------------------------------------------------+  |
|  |           Client-Side Deterministic OIML R 76 Math Engine (JS/TS)            |  |
|  |     Calculates: P = I + 0.5e - dL | E = P - L | Ec = E - E0 | MPE check      |  |
|  +-----------------------------------------------------------------------------+  |
|  +-----------------------------------------------------------------------------+  |
|  |         Offline Storage Layer: IndexedDB (RxDB / PouchDB Engine)            |  |
|  |         Stores draft reports, observations, rules & local assets            |  |
|  +-----------------------------------------------------------------------------+  |
+----------------------------------------|------------------------------------------+
                                         | REST / WebSockets (Sync Engine)
                                         v
+-----------------------------------------------------------------------------------+
|                            API & BACKEND SERVER LAYER                             |
|  +-----------------------------------------------------------------------------+  |
|  |              FastAPI / Node.js Gateway & Authentication (JWT/RBAC)          |  |
|  +-----------------------------------------------------------------------------+  |
|  +----------------------------------+   +--------------------------------------+  |
|  |   Report Generation Service      |   |   OIML Rule Engine Service           |  |
|  |   (Puppeteer PDF & docx Engine)  |   |   (Versioned Rule Loader)            |  |
|  +----------------------------------+   +--------------------------------------+  |
|  +----------------------------------+   +--------------------------------------+  |
|  |   Digital Signature Module       |   |   OCR / Validation Assistant         |  |
|  |   (PKI X.509 / PDF PAdES signer) |   |   (Tesseract / OpenCV pre-check)     |  |
|  +----------------------------------+   +--------------------------------------+  |
+----------------------------------------|------------------------------------------+
                                         | Database Drivers
                                         v
+-----------------------------------------------------------------------------------+
|                            PERSISTENCE & STORAGE LAYER                            |
|  +----------------------------------+   +--------------------------------------+  |
|  |   PostgreSQL Central Database    |   |   S3 Object Storage                  |  |
|  |   (Metadata, Users, Audit Logs)  |   |   (Report PDFs, Word Docs, Photos)   |  |
|  +----------------------------------+   +--------------------------------------+  |
+-----------------------------------------------------------------------------------+

Detailed Data Flow Narrative

1. Initialization & Setup:

   • Metrologist logs into MetroSpec-R76 using JWT authentication [INFERENCE].
   • The application fetches the active OIML Rule Set (OIML_R76_2006.json) and caches it locally in IndexedDB [INFERENCE].

2. Instrument & Environmental Data Entry:

   • Metrologist creates a new evaluation job, entering manufacturer details and instrument technical specs (Max, Min, $e$, $d$, Class) [PS].
   • The client-side validation logic immediately calculates $n = \text{Max}/e$ and validates whether the instrument parameters comply with OIML R 76 Class boundaries (e.g., verifying Class III $n$ is between 100 and 10,000) [PS, KNOWN].
   • Ambient temperature, humidity, and mains voltage are logged [PS].

3. Test Observation Recording & Deterministic Calculation:

   • For each test procedure (e.g., Weighing Performance Test), the metrologist enters applied load $L$, indication $I$, and change-point weight $\Delta L$ [PS, KNOWN].
   • The embedded deterministic math engine immediately computes: $$P = I + 0.5e - \Delta L$$ $$E = P - L$$ $$E_c = E - E_0$$
   • The engine queries the local rule schema to find the MPE threshold for load $L$ (e.g., $\pm 0.5e$ for $0 \le L \le 500e$; $\pm 1.0e$ for $500e < L \le 2000e$; $\pm 1.5e$ for $2000e < L \le 10000e$ for Class III) [KNOWN].
   • Compliance status (PASS / FAIL) for that load step is updated on-screen in real time [PS].

4. Document Generation & Storage:

   • Upon completion of all test suites, the overall evaluation result is derived [PS].
   • The system triggers the Report Generation Engine, rendering a standardized PDF document (matching OIML R 76-2 layout) and an editable Word DOCX file [PS, RESEARCHED].
   • Photographs of instrument seals and load cells are compressed and embedded into the report [PS].

5. Approval Workflow & Synchronization:

   • Draft reports are saved locally to IndexedDB [INFERENCE]. When internet connectivity is detected, the Background Sync Service uploads the report metadata and binary files to the central PostgreSQL and S3 storage [INFERENCE].
   • An Approving Metrologist reviews the submission on their dashboard, verifies the calculation audit trail, and applies a PKI Digital Signature [PS, INFERENCE].
   • The finalized signed certificate is stored in the central DoCA repository and made searchable [PS].

12. Technology Stack

13. AI/ML Justification

Critical Metrology Rule:

Core OIML R 76 MPE and Pass/Fail compliance calculations MUST NOT use Generative AI, Machine Learning, or Fuzzy Logic [INFERENCE]. Legal metrology requires 100% deterministic, mathematically exact, and legally defensible logic [KNOWN]. Using a neural network or LLM to determine if a weighing scale passes error tolerances would introduce hallucination risks and fail legal audit standards [INFERENCE].

Approved Non-Core AI Application 1: OCR Data Entry Assistant

• Purpose: Automatically transcribe physical printed readings from legacy weighing scale indicator thermal receipts or handwritten laboratory test sheets into digital forms [ASSUMPTION].
• Model Type: Tesseract OCR / Lightweight Vision Transformer (TrOCR) [ASSUMPTION].
• Input: Image or scanned PDF of scale indicator receipt or lab worksheet [ASSUMPTION].
• Output: Extracted numeric values for Load ($L$), Indication ($I$), and Temperature ($T$) [ASSUMPTION].
• Data Required: 200 sample images of indicator receipts and lab log sheets [ASSUMPTION].
• Why AI: Eliminates manual typing fatigue and reduces manual data transcription errors [INFERENCE].
• Evaluation Metric: Character Error Rate (CER) $< 1%$ and Precision $> 99%$ [ASSUMPTION].
• Failure Mode: Misinterpretation of digits (e.g., reading 8 as 3 due to thermal print blur).
• Human Oversight: Mandatory side-by-side human verification step where the metrologist must confirm extracted numbers before committing them to the report [INFERENCE].

Approved Non-Core AI Application 2: Metrological Anomaly & Typo Detection

• Purpose: Flag suspect data entry anomalies before report generation (e.g., detecting if a metrologist accidentally entered an indication $I = 100.0\text{ kg}$ for a load $L = 10.0\text{ kg}$) [INFERENCE].
• Model Type: Isolation Forest / Rule-Based Heuristic Boundary Classifier [INFERENCE].
• Input: Array of test observations across load steps [INFERENCE].
• Output: Warning flags pointing to specific out-of-trend data rows [INFERENCE].
• Why AI/Heuristics: Detects accidental keystroke errors early, saving time before final report sign-off [INFERENCE].
• Human Oversight: Alerts are advisory only; the metrologist retains full authority to override warnings [INFERENCE].

14. Data Architecture & Offline/Low-Network Design

Data Schema (JSON/SQL Entity Model)

{
  "evaluation_job": {
    "id": "UUID-v4",
    "application_no": "MA-2026-DOCA-00892",
    "created_at": "2026-09-15T10:30:00Z",
    "status": "DRAFT | PENDING_APPROVAL | APPROVED | REJECTED",
    "laboratory": {
      "lab_id": "RRSL-FARIDABAD",
      "testing_officer_id": "USR-1042"
    },
    "instrument_metadata": {
      "manufacturer": "Ace Scales India Pvt Ltd",
      "model_name": "EL-5000",
      "serial_no": "SN-2026-9912",
      "accuracy_class": "III",
      "max_capacity_kg": 15.0,
      "min_capacity_g": 100.0,
      "verification_scale_interval_e_g": 5.0,
      "actual_scale_interval_d_g": 5.0,
      "derived_n": 3000
    },
    "environmental_conditions": {
      "temperature_celsius": 23.5,
      "relative_humidity_pct": 55.0,
      "mains_voltage_volts": 230.0
    },
    "test_procedures": [
      {
        "test_name": "WEIGHING_PERFORMANCE_INCREASING",
        "clause": "OIML_R76_A.4.4.1",
        "observations": [
          {
            "step": 1,
            "load_L_kg": 0.0,
            "indicated_I_kg": 0.0,
            "change_point_dL_g": 2.5,
            "calculated_P_kg": 0.000,
            "calculated_E_kg": 0.000,
            "calculated_Ec_kg": 0.000,
            "mpe_kg": 0.0025,
            "result": "PASS"
          },
          {
            "step": 2,
            "load_L_kg": 2.5,
            "indicated_I_kg": 2.5,
            "change_point_dL_g": 2.0,
            "calculated_P_kg": 2.5005,
            "calculated_E_kg": 0.0005,
            "calculated_Ec_kg": 0.0005,
            "mpe_kg": 0.0025,
            "result": "PASS"
          }
        ],
        "test_status": "PASS"
      }
    ],
    "overall_compliance": "PASS"
  }
}

Offline Synchronization & Conflict Resolution Protocol

1. Local Writes: When offline, all data entry and calculation events write locally to IndexedDB using RxDB [INFERENCE].
2. Deterministic Locking: Once a report is submitted for approval by a metrologist, its local ID is locked to prevent editing conflicts [INFERENCE].
3. Background Sync: On network restoration, the Service Worker sends offline payloads to the central FastAPI sync endpoint [INFERENCE].
4. Conflict Policy: Primary entity conflicts are handled via Last-Write-Wins (LWW) based on monotonic client timestamps, but signed reports are immutable and cannot be overwritten [INFERENCE].

15. Security, Privacy & Governance

1. Personal & Proprietary Data Protection:

   • Manufacturer trade secrets, unreleased instrument blueprints, and metrologist credentials are encrypted at rest using AES-256 and in transit using TLS 1.3 [INFERENCE, KNOWN].

2. Role-Based Access Control (RBAC):

   • Metrologist / Field Tester: Can create, edit, and run calculations on assigned local evaluation drafts [INFERENCE].
   • Laboratory Supervisor / Approver: Can review submitted evaluations, verify audit trails, reject drafts, or apply PKI digital signatures to issue final reports [INFERENCE].
   • DoCA System Admin: Manages user onboarding, laboratory registry, and OIML rule set configuration [INFERENCE].

3. Tamper-Evident Audit Trail & Cryptographic Signatures:

   • Every state transition (Creation $\rightarrow$ Observation $\rightarrow$ Calculation $\rightarrow$ Submission $\rightarrow$ Approval) records an immutable cryptographic hash (SHA-256) containing timestamp, user ID, and payload hash [INFERENCE].
   • Final PDF reports are signed using X.509 PKI digital certificates (supporting India IT Act 2000 eSign/DSC standards) [KNOWN]. Any post-generation modification invalidates the signature [INFERENCE].

4. Regulatory Disclaimer:

   • Explicit Notice: The software output represents a prototype digital report for evaluation support. Formal legal Model Approval certificates require official issuance by authorized Officers of the Department of Consumer Affairs under the Legal Metrology Act, 2009 [PS, KNOWN].

16. MVP Scope (Hackathon Build)

In Scope

• Dynamic OIML R 76 Instrument Parameter Input Form: Complete capture of manufacturer details, Max, Min, $e$, $d$, Class I–IIII with real-time parameter validation [PS].
• Environmental Data Module: Input fields for temperature, humidity, pressure, and power voltage [PS].
• Core OIML R 76 Test Suites Data Entry Grids:
  1. Weighing Performance Test (Increasing/Decreasing loads with $\Delta L$ change-point calculation) [PS, KNOWN].
  2. Repeatability Test (3–10 weighings at $0.8 \text{Max}$) [PS, KNOWN].
  3. Eccentricity (Off-centre loading) Test (5 position checks) [PS, KNOWN].
  4. Discrimination Test (addition of $1.4e$ small weight) [PS, KNOWN].
• 100% Deterministic OIML R 76 MPE Engine: Real-time calculation of $P$, $E$, $E_c$, MPE bounds, and automatic step-level + overall Pass/Fail status [PS, KNOWN].
• Standardized Dual-Format Document Generator: PDF export strictly adhering to OIML R 76-2 layout + editable Word (.docx) export [PS, RESEARCHED].
• Offline PWA Capability: Complete offline data entry, calculations, and local report generation via IndexedDB [INFERENCE].
• Laboratory Activity Dashboard: Highlighting completed, in-process, and failed evaluation jobs [PS].
• Search & Retrieval Repository: Filter by application number, manufacturer, and date range [PS].
• Mock Digital Signature Injection: Visual and cryptographic hash sign-off overlay on PDF [PS].

Described Only / Out of Scope

• Direct RS232/USB physical scale hardware serial streaming (simulated via mock WebSocket stream for demo) [INFERENCE].
• Full production integration with GoI eMaap live production database (simulated via mock REST API gateway) [INFERENCE].
• Hardware EMC/ESD disturbance chamber automated sensor feeds (simulated via manual data input) [INFERENCE].

17. Live Demo Simulation Plan

To present a compelling live demonstration without requiring a 500 kg physical weighbridge or specialized temperature chamber on stage, the team will use a realistic simulation architecture:

+-----------------------------------------------------------------------------------+
|                           SIMULATION ENVIRONMENT DEMO FLOW                        |
|                                                                                   |
|  +---------------------------+             +----------------------------------+  |
|  |  Scale Telemetry Simulator|             |   Environmental Chamber Mock     |  |
|  |  (Sends RS-232 / USB      |             |   (Injects Temperature &         |  |
|  |   JSON load packets)      |             |    Voltage fluctuations)         |  |
|  +-------------|-------------+             +----------------|-----------------+  |
|                |                                            |                     |
|                +--------------------+-----------------------+                     |
|                                     v                                             |
|  +-----------------------------------------------------------------------------+  |
|  |                    MetroSpec-R76 PWA (Live Application)                     |  |
|  |  1. Ingests simulated load telemetry stream                                 |  |
|  |  2. Calculates change-point error Ec = E - E0 in real time                  |  |
|  |  3. Evaluates against Class III MPE bounds                                  |  |
|  |  4. Demonstrates offline disconnection (Airplane Mode) & local PDF export   |  |
|  |  5. Re-connects online & synchronizes to DoCA Central Repository            |  |
|  |  6. Demonstrates Supervisor Sign-off & PDF Digital Signature                |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+

• Data Flow Transparency: Judges will be shown a togglable "Simulation Panel" displaying raw simulated RS232 scale serial packets alongside the processed OIML calculation results, explicitly demonstrating what is simulated vs. what is computed [INFERENCE].

18. Implementation Roadmap

Target Project Deadline: 30 September 2026 [PS]

+-----------------------------------------------------------------------------------+
|                         IMPLEMENTATION ROADMAP (2026)                             |
|                                                                                   |
|  Phase 1: Domain Modeling & Rule Engine (01 Mar - 15 Apr 2026)                    |
|  [========================]                                                       |
|  - Parse OIML R 76-1 & R 76-2 specifications into JSON schemas                     |
|  - Implement deterministic JS/Python math engine & unit test suite               |
|                                                                                   |
|  Phase 2: Core PWA Frontend & Offline Storage (16 Apr - 31 May 2026)              |
|  [=================================]                                              |
|  - Build React UI forms for Instrument, Env, and Test observation grids           |
|  - Integrate RxDB / IndexedDB for offline data persistence                        |
|                                                                                   |
|  Phase 3: Backend API, Report Engine & Sync (01 Jun - 15 Jul 2026)                |
|  [===========================================]                                    |
|  - Develop FastAPI backend, PostgreSQL schema, and S3 upload handlers            |
|  - Implement Puppeteer HTML-to-PDF and docx Word generation services              |
|                                                                                   |
|  Phase 4: Dashboard, Security & PKI Signatures (16 Jul - 15 Aug 2026)             |
|  [===========================================]                                    |
|  - Develop DoCA Supervisor dashboard, search repository, and RBAC                |
|  - Integrate PDF X.509 digital signature module                                  |
|                                                                                   |
|  Phase 5: Field Testing, Simulation & Final Demo Polish (16 Aug - 30 Sep 2026)   |
|  [=================================================]                              |
|  - Conduct boundary MPE testing, offline network simulation, & demo rehearsals    |
|  - Final presentation submission for SIH 2026 (Deadline: 30 Sept 2026) [PS]       |
+-----------------------------------------------------------------------------------+

19. Testing & Validation Plan

1. Functional Testing:

   • Execute 50 automated test cases verifying data entry across Class I, II, III, and IIII instruments [INFERENCE].
   • Verify dynamic formula derivation: $n = \text{Max}/e$ and error $E_c = E - E_0$ [INFERENCE].

2. Metrological Math & Boundary Testing (False Positive / False Negative):

   • Boundary Tests: Inject observations right at MPE threshold limits (e.g., $E_c = +1.500e$ vs $E_c = +1.501e$) to ensure zero rounding errors cause false passes or false fails [INFERENCE].
   • Zero-Point Error Adjustments: Validate that zero-error $E_0$ is accurately subtracted from raw load errors across all step rows [INFERENCE].

3. Offline & Sync Testing:

   • Simulate complete network severance during a 20-step evaluation test; verify zero data loss and successful auto-synchronization upon reconnecting [INFERENCE].

4. Document Fidelity Testing:

   • Validate generated PDF and Word documents against standard OIML R 76-2 layout tables using automated visual regression tests [INFERENCE].

5. Security & Cryptographic Audit:

   • Verify RBAC access rules (preventing Metrologists from approving their own reports) and validate X.509 PKI digital signature integrity on exported PDFs [INFERENCE].

20. Risk Register

21. Cost & Scalability

Hackathon Prototype Cost

• Hosting: Free Tier (Vercel / Render / Supabase) — $0 [INFERENCE].
• Database & Storage: PostgreSQL local / Supabase free tier, MinIO local container — $0 [INFERENCE].
• Development Tools: Open-source stack (React, FastAPI, Puppeteer, RxDB) — $0 [INFERENCE].
• Total Prototype Cost: ₹0 / $0 [INFERENCE].

Production Deployment (National DoCA Scale)

• Cloud Infrastructure (NIC Cloud / MeghRaj or AWS India):
  • Managed PostgreSQL Cluster (High Availability): ₹15,000 / month [ASSUMPTION].
  • Object Storage (MinIO / S3 - 2TB for PDFs & Photos): ₹5,000 / month [ASSUMPTION].
  • Compute Instances (FastAPI API nodes + Puppeteer render workers): ₹20,000 / month [ASSUMPTION].
• Security & PKI Infrastructure:
  • Class 3 Organizational Digital Signature Certificates & eSign API gateway: ₹50,000 / year [ASSUMPTION].
• Maintenance & Support:
  • Annual technical support and OIML rule updates: ₹5,00,000 / year [ASSUMPTION].
• Scalability Capacity: Linear horizontal scaling of API nodes handling over 100,000 annual NAWI model approvals across India with zero database bottleneck [INFERENCE].

22. Differentiation

23. Future Scope

1. IoT Direct Indicator Telemetry: Integration with scale indicators via Bluetooth / RS232-to-Wi-Fi bridges to auto-capture load readings directly from indicator hardware [ASSUMPTION].
2. Expansion to Other Legal Metrology Standards: Extending the configurable rule engine to support:
   • OIML R 49 (Water Meters) [RESEARCHED]
   • OIML R 51 (Automatic Catchweighing Instruments) [RESEARCHED]
   • OIML R 111 (Standard Weights Calibration) [RESEARCHED]
3. Mobile Field Verification App: Lightweight Android/iOS native app for state Legal Metrology Inspectors conducting annual in-service verification and stamping in retail markets [INFERENCE].

24. Assumptions & Open Items Log

Consolidated Assumptions & Validation Items

• [ASSUMPTION] Local IndexedDB storage capacity on lab PCs is sufficient for holding up to 50 draft reports with compressed photos before cloud sync.
• [ASSUMPTION] OCR assistant functionality is tailored for standard thermal scale receipts and requires human confirmation.
• [ASSUMPTION] Production cloud infrastructure costs estimated based on standard NIC Cloud / MeghRaj pricing tiers in India.
• [NEEDS VALIDATION] Exact API schema for direct auto-push integration into the live GoI eMaap portal (emaap.gov.in) needs confirmation from DoCA IT division [NEEDS VALIDATION].
• [NEEDS VALIDATION] Specific PKI smartcard/eSign driver requirements used by individual RRSL Laboratory Directors for digital sign-off [NEEDS VALIDATION].

Final Recommendation

Build MetroSpec-R76 as a Hybrid Offline-First Progressive Web Application (PWA) with Electron desktop packaging, utilizing a client-side deterministic OIML R 76 math engine, IndexedDB local storage, FastAPI backend, PostgreSQL database, and Puppeteer/docx document generation engine [INFERENCE, ASSUMPTION]. This directly solves the Department of Consumer Affairs' problem by eliminating manual spreadsheet errors, enforcing international OIML standards, enabling field testing without internet, and delivering an audited, digital repository [PS, INFERENCE].

Recommended Stack

• Frontend: React.js, TypeScript, Tailwind CSS, RxDB (IndexedDB) [INFERENCE].
• Desktop Shell: Electron / Tauri [INFERENCE].
• Backend: FastAPI (Python 3.12), SQLAlchemy, Pydantic [INFERENCE].
• Database & Storage: PostgreSQL 16 (JSONB + Full-Text Search), MinIO / S3 [INFERENCE].
• Reporting Engine: Puppeteer (HTML-to-PDF) & docx (JS Word Engine) [RESEARCHED].
• Security: OAuth2 + JWT, Argon2, PyPDF2 / OpenSSL X.509 PKI Signing [INFERENCE].

Biggest Dependency

Access to official, detailed OIML R 76-2 test report checklist templates and sample evaluation datasets from RRSL laboratories to calibrate the report generator layouts [INFERENCE, NEEDS VALIDATION].

Biggest Risk

Metrologists rejecting the software if the data entry workflow does not perfectly match their physical testing sequence or if offline synchronization causes data overwrite errors [INFERENCE].

Biggest Technical Challenge

Implementing the exact OIML R 76 change-point error calculation formula ($P = I + 0.5e - \Delta L$, $E = P - L$, $E_c = E - E_0$) using fixed-point arithmetic across dynamic load steps while ensuring boundary MPE checks never suffer floating-point roundoff errors [INFERENCE].

First 5 Actions

1. Action 1: Construct the master OIML_R76_2006.json rule schema containing Class I, II, III, IIII MPE step limits and test clauses [INFERENCE].
2. Action 2: Build and unit-test the pure deterministic Metrology Math Module in TypeScript and Python, verifying calculation results against published OIML evaluation examples [INFERENCE].
3. Action 3: Design the React UI forms for dynamic instrument parameter entry and OIML test observation data grids [INFERENCE].
4. Action 4: Setup the Puppeteer HTML-to-PDF template engine replicating the exact OIML R 76-2 test report layout [RESEARCHED].
5. Action 5: Implement RxDB IndexedDB local storage integration to demonstrate offline form saving and background cloud synchronization [INFERENCE].

Validation Before Coding

• Verify the exact MPE stepped table bounds for Class III instruments ($0-500e \rightarrow \pm 0.5e$; $500-2000e \rightarrow \pm 1.0e$; $2000-10000e \rightarrow \pm 1.5e$) against official OIML R 76-1 publication [RESEARCHED].
• Confirm that Puppeteer generates vector PDFs with selectable text and exact page breaks matching OIML R 76-2 formatting [RESEARCHED].

Buildability Score /100

$$\mathbf{94 / 100}$$

Justification: The problem is exceptionally well-suited for a 4-6 student software team. Core requirements rely on standard web/desktop software engineering (forms, deterministic mathematical calculation rules, PDF/Word document generation, offline DB sync, and dashboards). No complex, uncertain hardware or expensive AI training is required [INFERENCE].

Confidence

$$\mathbf{HIGH\ (92%)}$$

Justification: Explicit requirements are clearly defined in the SIH PS and backed by published OIML R 76 international metrology standards and DoCA Legal Metrology Rules [PS, RESEARCHED].

Research Sources

1. OIML Recommendation R 76-1 (2006): Non-automatic weighing instruments - Part 1: Metrological and technical requirements - Tests.

   • URL: OIML R 76-1 PDF [RESEARCHED]
   • Type: International Standard / Official Metrology Publication.
   • Claim Supported: MPE load step boundaries, $P = I + 0.5e - \Delta L$ error calculation methodology, Accuracy Class definitions (Class I–IIII), and test procedures [RESEARCHED].
   • Reliability: 100% (Primary International Standard).

2. OIML Recommendation R 76-2 (2007): Non-automatic weighing instruments - Part 2: Test report format.

   • URL: OIML R 76-2 Details [RESEARCHED]
   • Type: International Standard Document.
   • Claim Supported: Standardized layout, table structure, and checklist requirements for NAWI type evaluation test reports [RESEARCHED].
   • Reliability: 100% (Primary International Standard).

3. Department of Consumer Affairs (DoCA) eMaap Portal: National Legal Metrology Portal, Government of India.

   • URL: eMaap Portal [RESEARCHED]
   • Type: Official Government Portal.
   • Claim Supported: DoCA's central portal for model approvals, state system integration, and licensing operational since 2025 [RESEARCHED].
   • Reliability: 100% (Official Government Source).

4. Legal Metrology (General) Rules, 2011 & Legal Metrology Act, 2009: Department of Consumer Affairs, India.

   • URL: Legal Metrology Act & Rules [RESEARCHED]
   • Type: Statutory Legislation & Government Rules.
   • Claim Supported: Mandatory model approval requirements, RRSL testing roles, and legal framework for weighing instruments in India [PS, RESEARCHED].
   • Reliability: 100% (Statutory Law).