Quality Management

Why this is a runtime problem, not a CRUD problem

A quality system is not a forms package. It is a contract between receiving, production, and shipping: every inspection result must trigger the right downstream behavior — accept, quarantine, rework, scrap, or escalate — and every non-conformance must be contained, root-caused, and resolved by someone who did not create the defect. Sampling rules differ per supplier, SPC limits drift per process line, and a class-A defect on a regulated product is a different workflow than a cosmetic blemish.

A data-app builder gives you screens for inspections and NCRs but leaves the cross-step rules to humans. A packaged QMS has the rules but resists per-plant tailoring of AQL plans, SPC chart types, and disposition workflows. AuraBoot is the third path: inspections, SPC samples, and NCRs are configurable models; state transitions are commands with permissions and audit; the NCR workflow is a BPM process whose tasks resolve back to those same commands.

Data model summary

The Quality Management plugin contributes the core inspection and non-conformance models. The four central ones are:

  • qms_inspection_plan — Per-material or per-process sampling plan: AQL level, characteristics, accept/reject criteria; effective-dated revisions.
  • qms_inspection_record — IQC, PQC, or FQC checkpoint result; states pending → pass / fail / conditional_accept; carries quantities inspected, accepted, rejected.
  • qms_spc_sample — Individual SPC measurement bound to a control chart (X-bar/R, X-bar/S, P, NP, C, U); UCL/LCL violations flagged at write time.
  • qms_ncr — Non-conformance report; states open → contained → root_cause_found → resolved / escalated; links to the triggering inspection or defect record.

Adjacent models — defect records, CAPA, rework orders, batch traceability, and quality cost — round out the plugin. Each declares its dependencies in plugin.json; installing the SPC widgets without the inspection plugin is rejected by the resolver.

Key commands

The plugin defines around 40 commands. Five representative ones cover the three command shapes:

CommandShapeRiskIdempotentWhy it matters
qms.inspection.record_resultActionwritefalseCaptures an IQC/PQC/FQC measurement; non-idempotent because each call is a new sample
qms.ncr.openStateTransitionwritetrueOpens an NCR from a failed inspection; emits ncr.opened event
qms.ncr.containStateTransitionwritetrueMoves NCR to contained after material is segregated
qms.ncr.resolveStateTransitionwritetrueCloses the NCR after corrective action is verified; SoD enforced
qms.ncr.escalateStateTransitionirreversibletruePromotes severity to class-A; routes to Quality Director and emits regulatory notice

A button labeled "Record Result" is wired to qms.inspection.record_result — not to a raw PUT /api/qms_inspection_record. The same command is reachable from automation rules ("auto-fail a sample whose SPC value crosses UCL"), from the NCR BPM process, and — because it declares riskLevel: write, idempotent: false, agentHint: "Use only when the operator has confirmed the measurement on the device" — from an AI agent that watches SPC trends.

Permission example

A realistic quality role: "Plant Inspector — Site Shanghai".

  • RBAC (Layer 1): granted qms.inspection.record, qms.ncr.open, qms.ncr.contain; not granted qms.ncr.escalate (held by Quality Director).
  • Org scope (Layer 3): data visibility limited to the Shanghai plant subtree; cannot see Suzhou inspection records (org-and-descendants).
  • ReBAC (Layer 2): can resolve any NCR in their plant except ones they personally opened — the inspector who finds a defect cannot also sign off the resolution (separation of duties).
  • ABAC (Layer 4): can disposition NCRs only when defect_severity ≤ class B; class A defects route to Quality Director regardless of role.
  • Field-level (Layer 5): sees supplier-cost and concession amounts in NCRs; production operators see the same NCR with those fields masked.

All five layers are evaluated in order. A single declarative role configuration covers what would otherwise be hand-coded branching across UI, controllers, and reports.

Process orchestration

The NCR lifecycle is a BPM process. Each task binds to a command:

                       ┌──────────────────┐
                       │ Inspection fails │  ←  qms.inspection.record_result (result=fail)
                       └────────┬─────────┘
                                │
                       ┌────────▼────────┐
                       │ NCR opened      │  ←  qms.ncr.open
                       └────────┬────────┘
                                │
                       ┌────────▼────────┐
                       │ Contain material│  ←  qms.ncr.contain
                       └────────┬────────┘
                                │
                       ┌────────▼────────┐
                       │ Root-cause      │  ←  qms.ncr.record_root_cause
                       └────────┬────────┘
                                │
                  ┌─────────────▼─────────────┐
                  │ Severity gateway          │
                  └──┬─────────────────────┬──┘
                     │ class B / cosmetic  │ class A / regulated
            ┌────────▼─────────┐    ┌──────▼──────────┐
            │ Resolve (SoD)    │    │ Escalate        │  ←  qms.ncr.escalate
            │ qms.ncr.resolve  │    │ → Director + CAPA│
            └──────────────────┘    └─────────────────┘

The BPM engine enforces SoD by checking the resolver's identity against the opener's identity at the resolve gateway. A class-A escalation cannot be downgraded — the command is irreversible and emits a regulatory event consumed by audit and notification plugins.

Agent integration

Three command classes are intentionally exposed to AI agents in this solution:

  1. Read-and-summarize Commands (qms_ncr.weekly_summary, qms_spc_sample.list_out_of_control) — read-only, idempotent, low risk. Agents can call freely.
  2. Drafting Commands (qms.ncr.draft_root_cause_from_history) — write, idempotent, reversible. Agent proposes a root-cause hypothesis from similar past NCRs; a human inspector confirms via the existing record_root_cause StateTransition.
  3. Operational nudges (qms_inspection.flag_for_review) — write, idempotent. Agent notices an SPC run rule violation and opens an inspection review task; cannot disposition it.

What is not exposed: qms.ncr.escalate (irreversible + regulatory), qms.ncr.resolve (SoD + final), qms_inspection.record_result for class-A characteristics (must be a human on the device). These have agentHint: "Human-only" in their definitions; the platform's agent surface excludes them.

How to get it

  • Community: build it yourself. The architecture, plugin manifest format, and command pipeline are all open-source; the Quality Management plugin is not bundled.
  • Standard: white-label the base platform; build your own QMS-shaped plugins on top.
  • Professional: get the Quality Management plugin — models, commands, pages, roles, SPC chart widgets, and the NCR BPM process.
  • Enterprise: same package plus dedicated delivery engineering, regulated-industry compliance review (IPC-1782, ISO 9001, IATF 16949), MES/LIMS integration design, and SLA-backed support.

See Pricing for the full edition comparison.

Enterprise note — Marketplace publication of vertical plugin packs, License/Entitlement enforcement on the Command pipeline, cross-tenant Agent Control Plane for multi-plant orchestration, and Observability Pro per-stage trace spans are commercial-only capabilities. The open-core runtime described above is the same in every edition.

Next steps

  • System overview — how plugins, commands, and the runtime fit together
  • Command pipeline — the execution contract used by every command above
  • Permissions — the five-layer model used by the Plant Inspector role
  • Plugin manifest — how a solution package declares its plugin dependencies
  • Agent readiness — designing agentHint and risk fields for safe execution