Arena's connected BOM, DHF, and DMR remain separate records
Arena says its product-centric QMS connects quality and product records including BOMs, design history files, device master records, SOPs, CAPAs, and training. A shared platform can preserve relationships among them, but no single current product record can answer design-history, manufacturing-definition, and executed-build questions at once.
Editorial figure by Quality Systems Index. Source context: Arena QMS.
Three record classes answer three questions
A bill of materials describes an approved product structure for a defined item and revision. A design history file preserves the design-control history and evidence associated with development. A device master record identifies the specifications and procedures needed to manufacture a device under its approved definition. They can refer to the same product and many of the same components, but they have different content, owners, completeness tests, and approval meanings.
The platform should therefore preserve a record-class identifier, product and market scope, revision, lifecycle state, owner, approver, effective boundary, and governing procedure for each object. A current BOM should not be labeled as the design history, and a completed design review should not become the manufacturing definition. Where terminology or required records vary by product type or regulatory context, that applicability should be explicit rather than inferred from the provider's feature list.
Relationships need revision-specific lineage
A useful connection identifies exactly which requirement, design output, risk control, verification result, component revision, drawing, specification, procedure, and training record supports which product-record revision. The relationship itself needs a source, effective time, reason, owner, and change history. A generic related-record link is weak evidence if reviewers cannot tell whether it is current, superseded, optional, market-specific, or still awaiting assessment.
Changes should update relationships through controlled impact review rather than overwrite them. Preserve the prior record versions and links, proposed changes, affected products and markets, reviewer decisions, verification or validation, approvals, and effective boundary. That chronology should let a reviewer reconstruct the exact design and manufacturing definition applicable to an earlier lot or serial range without pretending that today's connected graph existed at the time.
The approved definition is not the as-built record
A BOM or master manufacturing record states what should be built and controlled. The executed record must separately show what was actually issued, substituted, assembled, processed, inspected, reworked, accepted, and released for a specific production order, lot, or serial population. Material genealogy, operator and equipment records, deviations, inspection results, and dispositions cannot be backfilled from the approved definition merely because no exception is visible.
Connections should support comparison without collapsing the two layers. Reviewers need the approved revision and effectivity used, the actual component and process evidence, departures, approvals, and reconciliation result. If an execution system receives an older revision, a supplier uses a superseded drawing, or a substitution is unresolved, the product record should expose the mismatch and accountable disposition rather than presenting a clean current configuration.
Test one product across record classes
A representative evaluation should begin with one approved requirement, follow it through design output, risk analysis, verification, a BOM and device master record, then execute two production lots under different effective revisions. Introduce a late drawing change, an approved alternate component, an obsolete work instruction, a failed inspection, and a supplier response linked to the wrong product revision. Reviewers should reproduce each record's status and relationship without merging their meanings.
Then ask for the design history that justified the current definition and the as-built evidence for each lot. Missing or conflicting links should remain explicit. Arena's public page supports the described product-centric QMS, connected record types, product-record control, and role-based collaboration positioning. It does not establish a customer's record taxonomy, applicability, relationship completeness, configuration, validation, executed product history, conformity, or compliance.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Quality Systems Index will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.