QA Platform Architecture: Inspection Engine, NCR Workflow, and Real-Time Dashboard Design

Overview

A QA platform for manufacturing must solve problems that most SaaS applications don't face: inspections happen on the shop floor where connectivity is unreliable, forms must be configurable without code changes, and the audit trail must be tamper-proof for ISO and regulatory compliance. This guide covers the architectural decisions behind IdeaSprout's Quality Assurance module.

1. Dynamic Inspection Form Engine

The Problem with Static Forms

Manufacturing QA has dozens of inspection types: incoming material inspection, in-process inspection, final inspection, customer return inspection, supplier audit. Each has different fields, measurement types, and pass/fail criteria. Hard-coding forms means every new product or process change requires a developer.

Form Schema Design

Forms are defined as JSON schemas stored in the database. The rendering engine interprets the schema at runtime:

{
  "formId": "uuid",
  "name": "Incoming Material Inspection - Steel Rods",
  "version": 3,
  "sections": [
    {
      "title": "Visual Inspection",
      "fields": [
        {
          "id": "surface_finish",
          "label": "Surface Finish",
          "type": "pass_fail",
          "required": true,
          "failAction": "raise_ncr"
        },
        {
          "id": "diameter_mm",
          "label": "Diameter (mm)",
          "type": "measurement",
          "unit": "mm",
          "nominalValue": 25.0,
          "tolerance": { "upper": 0.1, "lower": -0.1 },
          "required": true,
          "outOfToleranceAction": "raise_ncr"
        }
      ]
    }
  ]
}

Versioning

Form schemas are versioned and immutable. When a form is updated, a new version is created. Completed inspections always reference the form version that was active at the time of inspection - ensuring historical records remain accurate even after form changes.

2. Offline-First Data Capture

The Shop Floor Reality

Factory floors often have poor WiFi coverage. Inspectors cannot be blocked from capturing data because of connectivity issues.

Architecture: Local-First with Sync

The mobile/tablet app uses a local SQLite database as the primary store. All inspection data is written locally first, then synced to the server when connectivity is available.

Inspector captures data → SQLite (local) → Background sync → PostgreSQL (server)

Conflict Resolution

When the same inspection record is modified on two devices (rare but possible), the system uses last-write-wins with server timestamp as the conflict resolution strategy. For NCR records (which may be updated by both the inspector and the quality manager), a merge strategy is used: field-level last-write-wins rather than record-level.

Sync Protocol

1. 1Device sends all unsynced records with local timestamps
2. 2Server checks for conflicts (same record modified server-side since last sync)
3. 3Server applies conflict resolution and returns the canonical state
4. 4Device updates local store with canonical state
5. 5Server assigns permanent IDs to locally-created records

3. Measurement Validation Engine

Real-Time Out-of-Tolerance Detection

When an inspector enters a measurement, the client-side validation engine immediately checks against the tolerance specification:

function validateMeasurement(value, field) {
  const { nominalValue, tolerance } = field;
  const deviation = value - nominalValue;
  if (deviation > tolerance.upper || deviation < tolerance.lower) {
    return {
      status: 'OUT_OF_TOLERANCE',
      deviation: deviation,
      action: field.outOfToleranceAction  // 'raise_ncr' | 'warn' | 'block'
    };
  }
  return { status: 'PASS' };
}

Statistical Process Control (SPC)

For high-volume production, the platform computes control charts (X-bar and R charts) in real time. When a measurement falls outside control limits (not just tolerance limits), a process drift alert is raised - before defects start occurring.

Control limits are recomputed using a rolling window of the last 25 subgroups (configurable).

4. NCR (Non-Conformance Report) Lifecycle

State Machine

RAISED → UNDER_REVIEW → DISPOSITION_PENDING → DISPOSED → CLOSED
                ↓
           REJECTED (false NCR) → CLOSED

Disposition Options

CAPA Linkage

NCRs with the same root cause are automatically grouped. When 3+ NCRs share the same root cause within 30 days, the system creates a CAPA (Corrective and Preventive Action) record and links the NCRs to it. The CAPA workflow enforces root cause analysis (5-Why or Fishbone), corrective action implementation, and effectiveness verification.

5. Real-Time Quality Dashboard

Metrics Architecture

Quality metrics are computed from two sources:

1. 1Transactional data (individual inspection results) - for drill-down
2. 2Pre-aggregated summaries - for dashboard performance

A materialised view refreshes every 5 minutes with key metrics:

CREATE MATERIALIZED VIEW quality_summary AS
SELECT
  product_id,
  date_trunc('day', inspected_at) AS day,
  COUNT(*) AS total_inspections,
  COUNT(*) FILTER (WHERE result = 'PASS') AS passed,
  COUNT(*) FILTER (WHERE result = 'FAIL') AS failed,
  ROUND(COUNT(*) FILTER (WHERE result = 'PASS')::numeric / COUNT(*) * 100, 2) AS pass_rate,
  COUNT(DISTINCT ncr_id) FILTER (WHERE ncr_id IS NOT NULL) AS ncr_count
FROM inspection_results
GROUP BY product_id, date_trunc('day', inspected_at);

Defect Pareto

The dashboard includes a Pareto chart of defect types (80/20 analysis). This is computed on-demand with a 1-hour cache since it's expensive to compute but doesn't need real-time freshness.

6. Audit Trail for ISO Compliance

Requirements

ISO 9001 requires that inspection records be:

• •Traceable to the inspector, date, and equipment used
• •Immutable after sign-off
• •Retained for a defined period (typically product lifetime + 1 year)

Implementation

Inspection records are locked after the inspector submits and a supervisor signs off. Locked records cannot be edited - corrections require a new inspection record with a reference to the original.

All records include:

• •inspector_id (with name snapshot - in case employee leaves)
• •device_id (tablet/phone used)
• •calibration_id (measuring instrument used, with calibration due date)
• •submitted_at (server timestamp, not client)
• •signature_hash (SHA-256 of record content + inspector ID)

7. Common Architectural Pitfalls

Summary

A production QA platform requires a schema-driven form engine for configurability, offline-first data capture for shop floor reliability, a measurement validation engine with SPC support, a structured NCR lifecycle with CAPA linkage, and an immutable audit trail that satisfies ISO 9001 requirements.