PCBA Manufacturing

Why this is a runtime problem, not a CRUD problem

A PCBA production run touches hundreds of components, each with moisture-sensitivity classes, alternative material substitutions, multi-level engineering BOMs, and IPC/JEDEC lot traceability requirements. The flow is quote → order → BOM resolve → MRP → procurement → IQC → production → in-process QC → FQC → pack → ship → invoice — and every transition must be permissioned, audited, and survive engineering changes that arrive mid-flight.

A data-app builder turns each step into a screen but leaves the cross-step contract to humans. A packaged business suite has the modules but resists deep customization of the BOM resolver and the lot-tracking rules that vary per customer. AuraBoot is the third path: the workflow is a BPM process whose tasks resolve back to commands; the commands enforce permissions, validate against engineering revisions, and emit audit and event records that downstream MES, WMS, and finance modules consume.

Data model summary

The PCBA solution ships as 10 cooperating plugins. The core models are:

pcba_rfq — Customer inquiries with engineering attachments; states draft → submitted → quoted → won/lost.
pcba_quotation — Costed quote with explicit BOM resolution snapshot; states draft → approved → sent → accepted/expired.
pcba_sales_order — Booked order anchoring all downstream activity.
pcba_bom + pcba_bom_item — Multi-level engineering BOM with alternative materials, effective-date revisions, and IPC class.
pcba_work_order — Production order driving MES + IQC/PQC/FQC inspections.
pcba_lot — Material lot with MSD floor-life timer for moisture-sensitive devices.
pcba_inspection_record — IQC/PQC/FQC checkpoint result; states pending → pass/fail/rework.
pcba_ncr — Non-conformance report; states open → contained → root-cause-found → resolved/escalated.

Each model belongs to a plugin (pcba-crm, pcba-sales, pcba-manufacturing, pcba-warehouse, pcba-compliance). Plugins declare their dependencies in plugin.json — adding the compliance plugin without manufacturing is rejected by the resolver, because the inspection records depend on work order models.

Key commands

The full solution defines roughly 80 commands. Five representative ones cover the three command shapes:

Command	Shape	Risk	Idempotent	Why it matters
`pcba_rfq.submit`	StateTransition	write	true	Moves an RFQ from `draft` to `submitted`; gates on required engineering files
`pcba_quotation.approve`	StateTransition	write	true	Manager approval after cost check; emits `quotation.approved` event
`pcba_work_order.start`	StateTransition	write	true	Locks BOM revision, decrements stock reservations, opens MSD timers
`pcba_inspection.record_result`	Action	write	false	Captures inspection result; non-idempotent because each call is a new measurement
`pcba_lot.recall`	Action	irreversible	false	Cross-customer recall after FMEA finding; requires SoD second signature

A button labeled "Submit RFQ" is wired to pcba_rfq.submit — not to a raw PUT /api/pcba_rfq. The same command is reachable from automation rules ("auto-submit overdue drafts"), from BPM flow steps, and — because it declares riskLevel: write, idempotent: true, agentHint: "Use when the customer has confirmed all attachments are final" — from an AI agent acting on behalf of a sales rep.

Permission example

A realistic PCBA role: "Plant Quality Lead — Asia".

RBAC: granted pcba.inspection.record, pcba.ncr.open, pcba.ncr.resolve; not granted pcba.lot.recall (held by Compliance Director).
Org scope: data visibility limited to plants in the Asia org subtree (data scope = org-and-descendants).
ReBAC: can resolve NCRs created by anyone in their plants; cannot resolve those they personally opened (separation of duties).
ABAC: can approve "rework" disposition only when defect_severity ≤ class B; class A defects require Quality Director.
Field-level: sees component-cost fields in inspection records (masked for production operators).

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 order-fulfillment process is a BPMN diagram. Each task is bound to a command:

                    ┌─────────────────┐
                    │ RFQ submitted   │  ←  pcba_rfq.submit
                    └────────┬────────┘
                             │
                ┌────────────▼────────────┐
                │ Engineering BOM review  │  ←  pcba_bom.resolve
                └────────────┬────────────┘
                             │
                ┌────────────▼────────────┐
                │ Cost & quote approval   │  ←  pcba_quotation.approve
                └────────────┬────────────┘
                             │
              ┌──────────────▼──────────────┐
              │ Customer accept (gateway)   │
              └──┬───────────────────────┬──┘
                 │ accepted              │ lost
       ┌─────────▼──────────┐    ┌───────▼──────┐
       │ Sales order open   │    │ Archive RFQ  │
       └─────────┬──────────┘    └──────────────┘
                 │
       ┌─────────▼──────────┐
       │ MRP + procurement  │  ←  pcba_work_order.create + pcba_po.release
       └─────────┬──────────┘
                 │
       ┌─────────▼──────────┐
       │ Produce + inspect  │  ←  pcba_work_order.start, pcba_inspection.record_result (loop)
       └─────────┬──────────┘
                 │
       ┌─────────▼──────────┐
       │ Pack + ship + bill │  ←  pcba_shipment.dispatch, pcba_invoice.issue
       └────────────────────┘

Engineering changes mid-flight do not break the flow: the BPM engine carries the work-order revision lock, and pcba_bom.revise issues a new revision that downstream commands validate against.

Agent integration

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

Read-and-summarize Commands (pcba_rfq.list_overdue, pcba_ncr.weekly_summary) — read-only, idempotent, low risk. Agents can call freely.
Drafting Commands (pcba_quotation.draft_from_rfq) — write, idempotent, reversible. Agent drafts a quote; human approves it via the existing approve StateTransition.
Operational nudges (pcba_inspection.flag_for_review) — write, idempotent. Agent notices an SPC trend, opens an inspection review task; cannot disposition it.

What is not exposed: pcba_lot.recall (irreversible + SoD), pcba_work_order.cancel (irreversible), pcba_invoice.void (financial). 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 PCBA-specific plugins are not bundled.
Standard: white-label the base platform; build your own PCBA-shaped plugins on top.
Professional: get the PCBA solution package — the 10 cooperating plugins, pre-wired menus, roles, and dashboards.
Enterprise: same package plus dedicated delivery engineering, compliance review, MES/WMS 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 Quality Lead role
Plugin manifest — how a solution package declares its plugin dependencies
Agent readiness — designing agentHint and risk fields for safe execution