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; statespending → 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; statesopen → 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:
| Command | Shape | Risk | Idempotent | Why it matters |
|---|---|---|---|---|
qms.inspection.record_result | Action | write | false | Captures an IQC/PQC/FQC measurement; non-idempotent because each call is a new sample |
qms.ncr.open | StateTransition | write | true | Opens an NCR from a failed inspection; emits ncr.opened event |
qms.ncr.contain | StateTransition | write | true | Moves NCR to contained after material is segregated |
qms.ncr.resolve | StateTransition | write | true | Closes the NCR after corrective action is verified; SoD enforced |
qms.ncr.escalate | StateTransition | irreversible | true | Promotes 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 grantedqms.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:
- Read-and-summarize Commands (
qms_ncr.weekly_summary,qms_spc_sample.list_out_of_control) — read-only, idempotent, low risk. Agents can call freely. - 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 existingrecord_root_causeStateTransition. - 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