Integration Patterns Between LIMS and MES That Avoid Two Versions of Truth

The Boundary Between the Lab and the Floor

Every regulated manufacturing site runs the same loop. Production reaches a point where material must be tested. A sample is taken and identified. The laboratory tests it. A result comes back. Somebody decides whether the result is acceptable. The batch moves forward, or it does not. In a paper plant that loop is a form and a signature. In a digital plant it is two large computerized systems exchanging messages across an interface that few people have read.

The vocabulary problem comes first. Laboratory people say “sample” and mean a physical aliquot with a chain of custody. Manufacturing people say “sample” and mean a step in a recipe that has to be marked complete. Both are right, and neither definition survives contact with the other system without a translation that somebody has to write down. This is the reason to reach for a standard vocabulary rather than invent one on the project.

ISA-95, published internationally as IEC 62264, is the standard that gives the boundary its names. It defines a five-level model running from the physical process at Level 0 up to business planning and logistics at Level 4, with manufacturing operations management at Level 3.⁵ Part 1 of the standard describes the Level 3 domain and the interface content and transactions within Level 3 and between Level 3 and Level 4, and states its own goal plainly: to increase the uniformity and consistency of interface terminology and to reduce the risk, expense and errors of implementing those interfaces.⁶ That is exactly the problem in front of a LIMS and MES project.

The practical value of ISA-95 in this setting is not the pyramid diagram. It is the object models: material lot, material sublot, process segment, operations definition, operations response, and, most usefully here, quality test specification and quality test result as first-class objects with defined attributes. When a project argues about whether a “result” includes its unit, its specification reference, and its approval state, the standard has already answered. B2MML, the XML implementation of the ISA-95 models maintained by MESA International, publishes those object structures as schemas that a project can read rather than re-derive.¹¹ Even organizations that will never transmit a line of B2MML benefit from reading the schemas, because they show which attributes a well-formed quality result is expected to carry.

Where both systems have a legitimate claim

The boundary is contested because both products were built to do part of the same job. Modern LIMS platforms manage sampling plans, scheduling, stability programs, and disposition workflows. Modern MES platforms manage the electronic batch record, in-process checks, material status, and release readiness. Each vendor has an incentive to widen its scope, and each functional group has a reason to prefer its own system. The result is that a site can end up holding two sample registers, two specification tables, and two views of batch status without anyone deciding to build them.

This is not an argument for one system. It is an argument for one owner per element. The functional overlap is real and permanent, so the answer is a written allocation rather than a turf negotiation repeated at every release.

The regulatory frame, stated once

Four documents carry most of the weight here, and it is worth being precise about what each actually says rather than gesturing at compliance.

EU GMP Annex 11 is the most direct. Clause 5, headed Data, states that computerized systems exchanging data electronically with other systems should include appropriate built-in checks for the correct and secure entry and processing of data, in order to minimize the risks. Clause 6, Accuracy Checks, requires an additional check on the accuracy of critical data entered manually, which may be done by a second operator or by validated electronic means, with the criticality and potential consequences of erroneous entry covered by risk management. Clause 4.3 requires an up to date inventory of systems and their GMP functionality, and for critical systems an up to date system description detailing the physical and logical arrangements, data flows and interfaces with other systems or processes. Clause 4.4 requires user requirements specifications to describe the required functions and to be traceable throughout the life cycle. Clause 4.8 requires that where data are transferred to another format or system, validation includes checks that data are not altered in value and/or meaning during the process.¹

Read together, those clauses are close to a specification for the work in this article. An interface between a LIMS and an MES needs built-in checks, a documented data flow, traceable requirements, and evidence that meaning survives the crossing. Note that clause 4.8 says value and meaning. A number that arrives intact but arrives without the state that qualifies it has had its meaning altered, even though every digit matches.

21 CFR Part 11 supplies the record controls on both sides. Section 11.10 requires validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records; the ability to generate accurate and complete copies; protection of records to enable accurate and ready retrieval throughout the retention period; secure computer-generated time-stamped audit trails that record operator entries and actions which create, modify, or delete electronic records; and use of device checks to determine the validity of the source of data input or operational instruction where appropriate.² That last point is easy to skip and directly relevant: when an MES accepts a result over an interface, something has to establish that the message came from the system entitled to send it.

The CGMP regulations set the underlying obligations the interface exists to serve. Laboratory records must include complete data derived from all tests necessary to ensure compliance with established specifications and standards.³ There must be appropriate laboratory determination of satisfactory conformance to final specifications before release and distribution.⁴ The quality control unit holds the responsibility and authority to approve or reject components, in-process materials, and drug products, and to review production records.¹² An interface does not move any of those obligations. It only changes where the evidence lives.

GAMP guidance supplies the method. The ISPE GAMP Records and Data Integrity Good Practice Guide on manufacturing records gives practical guidance on regulated records, data flows, and risk management with particular attention to process control systems, manufacturing execution systems, and the interfaces and relationships between them.⁸ The related guide on data integrity by design makes the point that data are frequently transferred across multiple systems as part of the data flow that constructs the regulated record, and that a data flow diagram of the complete business process is a foundational requirement rather than a documentation nicety.⁸

Mastership: One Owner for Every Data Element

Mastership is a one-sentence rule with a long tail of consequences. For each data element that crosses the boundary, exactly one system creates it, changes it, and answers for it. Every other system holds a copy, displays the copy, and cannot alter it. The owner publishes changes. The copy holder applies them.

Stated that way, it sounds obvious. In practice, three things break it.

Break one: convenience editing

An operator on the floor sees a sample identifier that looks wrong. The MES screen allows the field to be edited, because during configuration somebody left it editable so that a typo could be corrected without calling the lab. Now the MES holds a sample identifier the LIMS has never heard of. Nothing failed. No alert fired. The batch record refers to a sample that does not exist in the system of record for samples, and the discrepancy will be found during batch review, at the worst possible moment, by the person least able to explain it.

The remedy is a configuration rule, not a training message: fields holding copies of another system’s data are read-only, in every screen, for every role, including administrators. If a value needs correcting, the correction is made in the owning system and republished. This is more inconvenient. It is also the entire point.

Regulators treat over-broad edit rights as a control failure rather than a convenience. In a 2025 warning letter, FDA cited a firm under 21 CFR 211.68(b) because its laboratory equipment lacked restricted access and sufficient controls, with analysts holding administrative rights that allowed data to be altered and electronic raw data files deleted.¹⁰ The same reasoning applies to a copied field in a receiving system. If a role can change a value that another system owns, the record has no reliable provenance regardless of whether anyone has changed it yet.

Break two: independent creation

Both systems can create a sample. The LIMS creates one when a stability pull is scheduled. The MES creates one when a recipe reaches a sampling phase. Unless the project decides which creation path is authoritative for which sample type, the site ends up with two registers that overlap partially and reconcile never. The most common outcome is a manual mapping table maintained by one person in a spreadsheet, which is an unvalidated system performing a GMP function.

The remedy is to allocate creation by sample type rather than by system preference. In-process and finished-product samples driven by a recipe are usually requested by the MES and created by the LIMS, which returns the identifier. Stability, environmental monitoring, utility, and raw material samples are created directly in the LIMS and never exist in the MES at all. Once the allocation is written, the MES loses its ability to create sample identities on its own.

Break three: derived values that look like copies

The subtlest failure is the value that is calculated, not copied. An MES receives a raw plate count and applies its own calculation. A LIMS receives a fill weight and averages it. Both systems now hold numbers that agree with their inputs and disagree with each other, and nobody has broken a rule that was ever written down.

Consider a microbiological count. One system stores the raw plate count. The other applies a dilution factor to express the result per gram or per milliliter. Both numbers are real, both are internally consistent, and they differ by orders of magnitude. If the specification is written against the calculated value and the disposition screen shows the raw count, the number in the system is accurate and the meaning is wrong. That is precisely the failure Annex 11 clause 4.8 names when it says data must not be altered in value and/or meaning.¹ A conversion or calculation applied on the receiving side is an alteration of meaning even when no digit is corrupted.

Why co-mastering feels reasonable at the time

Nobody sets out to co-master. It arrives as a series of small accommodations. The lab wants to see batch status without logging into the MES, so batch status is replicated into the LIMS and, because a LIMS user occasionally needs to correct it, made editable. Manufacturing wants to record an in-process check result without waiting for the lab, so the MES gets its own result field for the same test. A validation engineer wants to avoid an interface change, so a value is keyed into both systems in parallel during a temporary period that lasts four years.

Each of those decisions is defensible in isolation. Together they produce a plant where the honest answer to “what is the assay result for batch 2607-011” is “which system are you looking at”. The discipline is to notice the pattern early, because unwinding co-mastership after go-live means data migration, retraining, and a change control that touches two validated systems at once.

The Integration Decision Table, Element by Element

The deliverable that settles all of this is short. It is a table, agreed by quality, laboratory operations, manufacturing, and IT, that names every data element crossing the boundary and assigns one owner. It belongs in the URS, is referenced by the functional specification, and is the source for the reconciliation report described later. The version below is a starting point for a typical small molecule or biologics site. The specific allocations will differ by organization. The requirement that they be written down does not.

Event-Driven or Scheduled: Choosing How Data Moves

Once mastership is settled, the transport question becomes tractable. It is genuinely a design choice with two defensible answers, and the mistake is applying one answer everywhere.

Event-driven transfer

In an event-driven interface, the owning system publishes a message the moment a fact changes. A result is approved; a message goes out; the MES applies it within seconds. The advantage is that the copy is never meaningfully stale, which matters when the receiving system gates a physical action such as unblocking a phase or permitting a transfer.

Event-driven interfaces carry obligations that projects routinely underestimate:

• Guaranteed delivery. A message that is sent is not a message that arrived. The interface needs acknowledgment and retry, and a dead-letter destination that a human being monitors. An unmonitored dead-letter queue is a data integrity incident waiting for an inspection.
• Ordering. If a result is approved and then invalidated within the same minute, the receiving system must not apply those events out of sequence. Either the transport preserves order per sample, or each message carries a monotonic version number the receiver checks.
• Idempotency. Retries mean the same message can arrive twice. Applying it twice must produce the same state as applying it once, which means messages carry a unique identifier and the receiver keeps a record of what it has already applied.
• Replay. After an outage, somebody has to answer “what did we miss”. A replay mechanism scoped by time window and object type turns that into a procedure rather than an investigation.
• Fail-safe behavior. When the interface is down, the receiving system must block the dependent step rather than proceed on stale data. The default behavior of most configurations is to proceed. Change it deliberately and test it.

Scheduled batch transfer

In a scheduled interface, the owning system produces a set of records on a timer and the receiving system consumes them. Hourly, nightly, or on demand before a defined checkpoint. The advantage is simplicity: the transfer is a discrete, testable unit with a defined start, end, and record count, which makes verification straightforward and makes reprocessing after a failure a matter of rerunning a job.

Scheduled transfer is the right choice when latency does not affect a decision. Historical trending, stability data feeding an annual product review, environmental monitoring summaries, and reference data that changes weekly are all better served by a nightly job than by a message stream nobody watches.

The obligations here are different but not smaller:

• Completeness proof. Each transfer declares an expected record count and the receiver confirms it. A transfer that moves 419 of 420 records and reports success is worse than one that fails outright.
• Window integrity. Records created during the run must land in exactly one window. Overlapping windows create duplicates; gapped windows lose records permanently.
• Late arrivals. A record backdated after its window has closed needs a defined path, usually a catch-up query on a last-modified timestamp rather than a creation timestamp.
• Staleness visibility. Any screen displaying scheduled data shows the timestamp of the last successful transfer. A user who does not know a value is fourteen hours old will treat it as current.

The middle path that causes trouble

Many sites end up with a hybrid: results arrive by event, but a nightly job also sweeps the same data as a safety net. This is a reasonable pattern and a common source of the exact problem this article is about, because the two paths can disagree. The nightly sweep sees a state the event stream has not delivered yet, or applies an older snapshot over a newer event.

If a site runs both, the rule is that the sweep is a detector, not a writer. It compares and reports differences. It does not overwrite. The moment a reconciliation job is given write permission, the organization loses its ability to see how often the primary path fails, which is the one number that tells it whether the interface is healthy.

Interfaces between qualified instruments and the lab system

One layer below the boundary, the same reasoning applies to laboratory instruments feeding the LIMS. An ISPE white paper on integrating qualified laboratory devices makes the case that the variety of laboratory equipment and vendors has produced complex integration scenarios, and proposes standardized device descriptions so that qualified devices can be exchanged with minimal reconfiguration, using established interface standards rather than proprietary connections.⁹ The relevance here is that a result reaching the MES has usually crossed two boundaries, not one. If the instrument-to-LIMS path involves an intermediate file that a person handles, the meaning is at risk before the MES interface is ever reached.

The Hard Cases: When a Result Changes Meaning After It Leaves the Lab

An interface that only ever moves final, approved, first-time-right results is easy and rare. The design is judged on what it does when a result’s meaning changes after the MES has already consumed it. There are five of these, and every one of them is a place where a naive interface produces two versions of truth.

Hard case one: retest

A retest is a new test on the same sample or a new sample, performed under a documented rationale. The critical design point is that a retest produces a new result record with its own identity. It does not update the old one. The relationship between them is explicit: the new record references the record it supersedes, and the reason.

The failure pattern is an interface that publishes results keyed on sample identifier and test name. The retest arrives, the MES matches on the key, and the original value is overwritten. The batch record now shows one result where two occurred. Depending on how the MES handles the update, the audit trail may show the change, but the batch record no longer tells the true story without somebody reading the audit trail to reconstruct it. Under Part 11, records must be retained and retrievable accurately and completely throughout the retention period, and the system must be able to discern invalid or altered records.² An overwrite that hides a prior result is directly at odds with both.

Hard case two: reprocessing and recalculation

Reprocessing covers reintegrating a chromatogram, recalculating with a corrected factor, or reapplying a revised calculation to acquired data. The number changes; the underlying acquisition does not. This is the case that most often exposes a bad mastership decision, because if the MES holds a value it computed from raw inputs, a reprocessing event in the lab does not reach it at all. The two systems drift apart with no message ever failing.

The design answer is the one already stated: calculations are mastered in one place, and the calculation identity and version travel with the result. When a recalculation occurs, the new result carries the new calculation version, and the MES can show that the change came from a recalculation rather than a retest. Those are different facts and a batch reviewer needs to tell them apart.

Hard case three: invalidation and the out-of-specification workflow

This is the hardest one, because invalidation changes the status of a number without changing the number. FDA’s expectations for out-of-specification investigations are structured: a laboratory phase that looks for assignable laboratory error, and, where no laboratory error is established, an expansion of the investigation beyond the laboratory. Invalidation of a result requires documented scientific justification for a specific, identified cause. Enforcement in this area is active. In a January 2026 warning letter, FDA recorded that investigators reviewed twenty-three variance and out-of-specification investigation reports covering November 2024 through May 2025, that none of them followed the firm’s own SOP for investigating out-of-specification results, and that nineteen investigations remained open at the time of the inspection.¹³ An open investigation is not an administrative state. It is a result whose meaning has not yet been settled, and any system holding a copy of that result needs to know it.

For the interface, the consequences are concrete. First, the MES has to be able to hold a result whose state is “under investigation” and to treat that state as neither pass nor fail but as an explicit block on disposition. Second, invalidation is an event that must reach the MES, because the MES may already be displaying the original value in an eBR. Third, invalidation must never delete. The invalidated result remains visible, marked, with its reason and its link to the investigation record.

Hard case four: specification version changes mid-batch

A specification is revised and approved while a batch is in progress. Some samples were tested against version 3 and some will be tested against version 4. Which limits apply, and what does the batch record show?

The policy question belongs to quality, and different organizations answer it differently. Two common policies are that the specification effective at the time of testing applies, or that the specification effective at batch start applies for the whole batch. Either is defensible. What is not defensible is having no written policy, because then the answer depends on which system the reviewer opens.

Whatever the policy, the design requirement is the same: the specification identifier and version that produced the pass or fail decision travel with the result. If the MES stores only a pass or fail flag, it cannot answer which limits produced it, and a reviewer six months later cannot reconstruct the decision. If the MES stores the limits themselves as a static copy taken at recipe design time, they will eventually disagree with the LIMS, and the disagreement will surface as a batch that reads as passing in one system and failing in the other.

Hard case five: results that are not simple numbers

Real results include values below a limit of quantitation, ranges, text outcomes such as conforms or complies, multi-component profiles, and results with a defined number of significant figures where the rounding rule is part of the specification. Each of these breaks a naive numeric field.

• Rounding and significant figures. If the LIMS reports 99.45 and the MES rounds to 99.5 for display, and disposition is made against a limit of 99.5, the two systems disagree about a pass. The rounding rule belongs to the specification and is applied once, in the owning system. The receiver displays the reported value exactly as received.
• Unit conversion. A conversion applied at the interface is a transformation of a GMP record. Either the owner sends the unit the receiver needs, or the conversion is a documented, tested, versioned part of the interface with its own qualification evidence.
• Non-numeric results. The receiving field has to accept text without coercing it. Systems that store everything numerically turn “complies” into null, and null in an eBR field is a review finding.
• Partial and cancelled samples. A sample cancelled after the MES has requested it must produce an explicit cancellation event, not an absence. Absence is indistinguishable from a lost message.

A Worked Example: One Out-of-Specification Result, End to End

The following walks a single out-of-specification result through both systems. The batch, sample, and values are illustrative. The sequence is the design pattern.

A biologics drug substance batch, B-2607-011, reaches an in-process assay point. The specification in force, SPEC-ASY-014 version 3, sets acceptance at 98.0 to 102.0 percent.

Now consider the same sequence in a plant where results are published as bare numbers without state. Step 4 delivers 96.2 as a failure. Step 6 delivers nothing, because invalidation is a state change and the interface has no state to change. Step 7 delivers 99.4, which the MES matches on sample and test and applies as an update, overwriting 96.2. The eBR shows a single passing result. The laboratory system shows an invalidated result, an investigation, and a retest. Both systems are internally consistent. Together they describe two different batches.

That divergence is not detected by any error handler, because nothing errored. It is detected by a reconciliation report, by a batch reviewer who happens to check, or by an inspector.

The Reconciliation Report That Proves the Two Systems Agree

Every interface eventually fails in a way that does not raise an error. The reconciliation report is the control that catches that class of failure. It is not a nice-to-have monitoring dashboard. It is the evidence that the built-in checks Annex 11 clause 5 requires are actually working, and it is the only routine artifact that demonstrates data were not altered in value or meaning in transfer.¹

What it compares

A reconciliation report that compares record counts is barely worth running. Counts match while contents differ. The comparison has to be field level, and the fields to compare come straight from the mastership table.

How often it runs

Three cadences, each doing a different job:

• Daily, for open batches and batches closed within a defined window. This is the working cadence. It finds differences while people still remember the day they were created.
• On demand, immediately before disposition. This is the gate. A batch does not proceed to disposition with an open reconciliation difference. Making this a hard prerequisite rather than a checklist item is what turns the report from monitoring into a control.
• Periodically over the full retention window. Monthly or quarterly, across all batches in the retention period, to catch slow drift and late modifications. This run also feeds the periodic evaluation that Annex 11 clause 11 expects, which is meant to confirm systems remain in a valid state and to consider deviation records, incidents, and problems.¹

What happens when it finds a difference

The report needs a defined handling path, or differences accumulate into a backlog that becomes its own finding.

The report is also a design review

One benefit that projects rarely anticipate: the first month of reconciliation output is the most honest assessment of the integration design anyone will ever get. Every row of the mastership table that was settled by compromise rather than logic shows up as a recurring difference. Teams that treat the first month as a defect list, rather than as noise to be filtered, tend to fix the design while change control is still cheap.

What to Specify in the URS So This Is Designed, Not Discovered

Almost everything above can be reduced to requirements written before a vendor is selected. Annex 11 clause 4.4 requires user requirements specifications to describe the required functions and to be traceable throughout the life cycle, and clause 4.3 requires, for critical systems, a current system description detailing the physical and logical arrangements, data flows, and interfaces with other systems.¹ EU GMP Annex 15 sets the expectation that qualification and validation activities are planned and that requirements are verified against defined acceptance criteria.⁷ A URS that names the interface but not its behavior pushes every decision in this article into the configuration phase, where it will be made by whoever is available.

The following requirement areas belong in the URS for either system, and in the interface specification that both vendors sign up to.

Mastership and permissions

• A mastership table listing every data element crossing the boundary, its owner, its copy holders, and its direction. Referenced by identifier from the functional specification.
• A requirement that fields holding another system’s data are not editable by any role, including administrative roles, and that this is verified during qualification rather than asserted in configuration notes.
• A requirement that the receiving system cannot create records of a type it does not master.

The result object

• The minimum attribute set for a result crossing the boundary: result identifier, sample identifier, batch identifier, test and method version, value as reported including significant figures, unit, specification identifier and version, evaluation outcome, result state, superseded-record reference where applicable, investigation reference where applicable, and the timestamp with its source.
• The permitted result states and the permitted transitions between them, as an explicit list rather than a free-text field.
• A requirement that the receiving system cannot use a result in disposition logic unless its state is approved.
• A requirement that superseded and invalidated results remain visible with their reason and are never deleted or overwritten.

Transport behavior

• For each interface, the pattern (event, request-reply, or scheduled) with the justification, and the maximum acceptable latency where the receiver acts on the data.
• Delivery guarantee, acknowledgment, retry policy, and the destination and monitoring of undeliverable messages.
• Ordering and idempotency requirements, stated as behavior the vendor must demonstrate, not as a technology.
• Replay capability scoped by object type and time window.
• Fail-safe behavior on interface unavailability, stated explicitly as blocking the dependent step.
• A named message contract with a version, and a rule that a contract change is a change control on both systems.

Checks, records, and time

• The built-in checks on entry and processing that Annex 11 clause 5 expects, described specifically: field-level validation, referential checks against the owning system, and rejection behavior for unrecognized values.¹
• Audit trail requirements on the receiving side covering what was received, when, from where, and what it replaced, consistent with the Part 11 requirement for secure computer-generated time-stamped audit trails.²
• Authentication of the sending system, addressing the Part 11 expectation for checks determining the validity of the source of a data input.²
• A single time source for both systems and a statement of which system’s timestamp is authoritative for each event type.

Reconciliation as a requirement, not a project add-on

• The reconciliation report as a named deliverable with its comparison scope, its three cadences, its output format, and its retention.
• Acceptance criteria stated as zero unexplained differences, with a defined classification scheme for explained ones.
• A hard prerequisite that batch disposition cannot proceed with an open unresolved difference on that batch.
• An explicit prohibition on automated correction.

Test data and qualification evidence

• A test data requirement covering the hard cases by name: retest, reprocessing, invalidation, out-of-specification workflow, specification version change mid-batch, sample cancellation, non-numeric result, result below a limit of quantitation, and a value at a rounding boundary.
• Negative tests covering message loss, duplication, out-of-order delivery, and an unrecognized value.
• Traceability from each requirement to the test that verifies it, maintained through the life cycle as Annex 11 clause 4.4 requires.¹

Governing the two systems as one boundary

The last piece is organizational rather than technical. A LIMS and an MES are usually owned by different functions, upgraded on different schedules, and supported by different vendors. The interface belongs to neither, which in practice means it belongs to nobody.

Three governance habits close that gap. First, name a single accountable owner for the boundary, with the authority to block a change on either side that alters the message contract. Second, put the mastership table under change control as a controlled document, so that a proposed change to who owns an element is assessed rather than configured. Third, treat vendor upgrades on either system as a change affecting both, with regression testing of the interface as a standing part of the upgrade package. Sites that skip the third habit discover the interface defect after the upgrade window closes, when backing out is no longer an option.

None of this requires new technology. It requires a decision written down before the configuration workshop, and a report that checks the decision held.

Conclusion

Two versions of truth between a LIMS and an MES are not caused by integration technology. They are caused by an unmade decision. Somebody let two systems own the same element, or let a number cross the boundary without the state, specification version, and history that give it meaning, and the gap opened the first time a result was invalidated or a limit was revised mid-batch. The regulatory expectations are unusually direct on this point: built-in checks on data exchanged between systems, documented data flows and interfaces, traceable user requirements, and validation evidence that data were not altered in value or meaning during transfer. Those clauses describe a mastership table, a result object with a state model, and a reconciliation report. Organizations that build those three things rarely have this problem. Organizations that discover them during qualification pay for them twice.

The work is smaller than it looks and it happens early. A day with the right four people produces the mastership table. A page of the URS produces the result object and the transport rules. A reconciliation report that reads and never writes turns the whole design into something that can be proven rather than assumed. Sakara Digital works with pharma and biotech organizations designing this boundary, whether during a LIMS or MES selection, an integration program already underway, or a remediation after batch review started finding differences nobody could explain. If you are working through where mastership should sit and want an independent perspective before the configuration workshop rather than after it, we are happy to have that conversation.

For Further Reading