LIMSpec

LIMSpec is the shared, standards-referenced vocabulary for laboratory informatics: 469 functions across 28 categories spanning LIMS, LIS, ELN, and SDMS, applied the same way in every vendor profile so a laboratory can evaluate any vendor on the facts, and a vendor can describe its own product completely and accurately.

469 Functions Defined 28 Functional Categories LIMS · LIS · LES · ELN · SDMS · BI · AI Standards-Referenced

Master Template

LIMSpec Score:No Score

Version 2026R1.52

Introduction

The LIMSpec and How to Use It

A practical walkthrough of what this document is, how a laboratory evaluating software should read and use it, and how a laboratory informatics vendor positions its own product accurately and completely within it.

What Is the LIMSpec?

LIMSpec is a fixed, standards-referenced catalog of 469 individual laboratory informatics functions, organized into 28 categories, covering the full functional territory spanned by LIMS, LIS, LES, ELN, SDMS, business intelligence, AI/automation, security, and compliance capabilities. It exists so that any laboratory informatics vendor's product can be described against the exact same functional checklist, in the exact same language, rather than through each vendor's own marketing terminology.

The matrix itself is vendor-neutral: this master edition names no vendor, scores nothing, and favors no product category. A specific vendor's profile is a separate document produced by applying this same fixed matrix to that vendor's own public documentation, marking each of the 469 functions as either Documented (confirmed in the vendor's own materials) or Not Supported (not confirmed), with a brief note explaining what was found. The result is a single, consistently structured record of what a vendor's own documentation actually says, function by function.

Overview of the LIMSpec document showing the sidebar table of contents and cover page — The LIMSpec document: a fixed 469-function matrix, a live Vendor LIMSpec Score, and a table of contents covering every category.

Who Benefits, and How

Laboratories evaluating software get a single, comparable, evidence-based reference for what each vendor's documentation actually claims — rather than reconciling incompatible feature lists across a dozen sales decks.
Vendors get a structured, comprehensive framework for describing their own product completely and accurately, including a dedicated place (Chapter 29) to highlight functionality that falls outside the standard matrix entirely.
Everyone benefits from a shared vocabulary: "chain-of-custody tracking" or "21 CFR Part 11 electronic signatures" means the same specific thing in every vendor's profile, because it is defined once, centrally, rather than redefined by each vendor's own copywriting.

How a Laboratory Uses This Document (the Buyer)

A laboratory's evaluation team typically works with completed profiles for each vendor under consideration, comparing them side by side on the facts each vendor has documented.

Reading a Completed Vendor Profile

Every function in the matrix is clickable. Each of the 28 categories lists its functions in a simple, ordered list — clicking any one opens its detail view, showing the standard Functional Requirement — a fixed, vendor-neutral explanation of what the function means and why it matters — alongside a Vendor Information tab containing that specific vendor's status and supporting detail for that function.

A Feature Matrix category page showing its clickable list of functions — Every category page lists its functions this way; clicking any one opens its detail view.

Function detail modal showing the Functional Requirement tab — Every function opens to its full explanation before any vendor-specific claim is even considered.

Function detail modal showing the Vendor Information tab with status and vendor-specific detail

The Vendor LIMSpec Score shown in the top banner is a running total of points earned across all 469 functions — Off-the-Shelf and Configurable each contribute 1 point, Extensible contributes 0.5 point, and Not Supported contributes 0 — a quick, directly comparable summary figure across vendors, though it should never substitute for actually reading the specific functions that matter to a given lab's own work. A high overall score built on functions irrelevant to a particular discipline is less useful than a focused review of the categories that discipline actually depends on.

How a Vendor Uses This Document (the Seller)

A vendor producing its own profile from this matrix works through three things: its Vendor Profile, every applicable function in the 28-category matrix, and, if it has functionality the standard matrix does not cover, Chapter 29.

Filling In the Vendor Profile

Chapter 1 captures basic corporate context — legal/product name, headquarters, ownership, deployment options, licensing model, pricing, compliance and security posture, and so on — using the same Edit-button pattern shown above. Filling in the Vendor / Product field also updates the document's own title banner, so the profile is clearly identified as soon as it is opened.

Cover banner showing the document title updated to include the vendor name, alongside the live score — Filling in Vendor / Product renames the document banner; the Vendor LIMSpec Score updates live as functions are answered.

Answering Functions

For each of the 469 functions, a vendor confirms whether its own documentation supports it. Opening a function and switching to the Vendor Information tab reveals an Edit button; clicking it exposes a status selector and a rich-text editor for the supporting detail — what specifically is supported, how, and (where useful) a source reference.

Function edit mode showing the status dropdown and rich text editor for Vendor Information — Marking a function Documented and describing exactly how it is supported, in the vendor’s own words.

This is where accuracy matters most for a vendor's own credibility. A function marked Off-the-Shelf should be genuinely confirmed in the vendor's own public materials as working out of the box — not implied, not assumed by analogy to a competitor, and not aspirational. A function that only works through configuration should be marked Configurable rather than Off-the-Shelf, and a function that requires custom coding or development should be marked Extensible rather than either. Any such distinction, and any partial support, should be explained plainly in the Vendor Information text. The whole value of a LIMSpec profile to a reader depends on this discipline being followed consistently, function by function.

Adding What the Standard Matrix Doesn't Cover

Some products have genuinely distinctive functionality that falls outside all 469 standard functions — a proprietary integration, a unique automation capability, a specialty workflow built for one industry. Chapter 29, Vendor Added Categories, exists for exactly this: a vendor can define its own categories, each numbered 29.1, 29.2, and so on, and add function points to them using the same Function / Functional Requirement / Vendor Information / Status structure as the standard matrix. Every function added here counts toward the overall Vendor LIMSpec Score exactly the same way a standard function does, earning points by status (1 for Off-the-Shelf or Configurable, 0.5 for Extensible, 0 for Not Supported).

Chapter 29 in its empty state, with an Add Vendor Category button

Add Vendor Category dialog with a name field and description field — Adding a category takes a name and a roughly 50-word description of what it covers and why it is unique to the vendor’s platform.

A vendor-added category shown with its description and an Add Function button

Add Function dialog for a vendor-added category, showing name, functional requirement, status, and vendor information fields — Each vendor-added function uses the same evidentiary structure as the standard 469 — a name, a description of what it does, a status, and supporting detail.

This chapter is the right place for genuine differentiation — not a place to restate standard functions in different words to make the profile look larger. A reader comparing profiles across vendors will notice the difference.

Adding a Vendor-Specific Function Within a Standard Category

Sometimes a vendor has a genuine extension of one specific standard category — not distinctive enough to warrant an entirely new Chapter 29 category, but not one of the 469 fixed functions either. Every standard category page has its own + Add Function button below its function list, right where the category's Chapter 29-style extensions belong. A function added this way uses the same Function / Functional Requirement / Vendor Information / Status structure as everything else, counts toward the overall Vendor LIMSpec Score the same way a standard function does, and can be freely edited or deleted afterward, since it is entirely vendor-authored rather than part of the fixed matrix. The 28 standard categories themselves are permanently fixed and can never be removed — only the vendor-added functions beneath them can be.

Hiding a Standard Function

The 469 standard functions cannot be deleted — deleting a function that is part of the fixed matrix would create a real risk that a future Upgrade migration reintroduces it, since the newer template always has all 469 back by default. Instead, any standard function can be hidden: open the function, switch to the Vendor Information tab, and use the "Hide this function" button next to Edit. A hidden function stays completely intact in the underlying data, and any points it earned before being hidden still count toward the LIMSpec Score — hiding only removes it from that category's visible list. Each category shows a small note when it has hidden functions ("N function(s) hidden from view — Show hidden"), with a link to reveal them again (shown dimmed and tagged "Hidden") for review or to Unhide.

Saving and Sharing a Completed Profile

Every edit — a function's status, a Vendor Profile field, a vendor-added category — is held in the browser until it is downloaded. The sidebar offers two download formats: an updated copy of this same interactive HTML document, and a Word (.docx) export covering the Vendor Profile chapter and the full Feature Matrix, generated entirely in the browser with no data leaving the machine.

Sidebar download buttons for an updated HTML copy and a Word copy, with an unsaved-edits indicator — Both downloads reflect whatever has been filled in so far; the file itself is the save point.

Keeping Your LIMSpec Profile Current

The LIMSpec master template is periodically updated — new functions, corrected wording, new capabilities like the ones described throughout this chapter. A vendor profile built from an older version of the template does not automatically pick these up. The Upgrade My LIMSpec button, in the dark navy cover banner next to the LIMSpec Score badge, exists to bring an older, filled-out profile forward to the latest template without losing the work already done.

This button only appears on the blank Master Template — not on a filled-out vendor profile — because only the Master Template is a valid upgrade target. The distinction matters: the file currently open is always the destination; the file selected in the upgrade dialog is always the source.

Cover banner showing the Upgrade My LIMSpec button only appearing on the blank Master Template — The button is only visible on the blank Master Template — filling in Vendor / Product in Chapter 1 hides it, since a vendor profile is never a valid upgrade target.

To upgrade an older profile: open the current, blank Master Template, click Upgrade My LIMSpec, and select the older filled-out file. The file is validated the moment it is selected — a clear error appears immediately if it is not a valid LIMSpec file — before anything is migrated.

Upgrade My LIMSpec modal showing the version comparison and file picker

Clicking Upgrade migrates every function status, every Vendor Profile field, and any Chapter 29 vendor-added categories from the older file into a fresh copy of the current template, matching by function name and field label. The Master Template page itself is never changed — the result is presented as a summary, with an explicit download link for the upgraded file.

If Something Doesn't Match

Matching works by exact function name and field label. If a function was renamed between versions, its old data will not carry over automatically — the summary reports this plainly as an unmatched item, rather than silently dropping it, so nothing is lost without you knowing about it.

One File, No Server

This entire application — the matrix, the editing tools, the scoring, the Word export — lives inside the single HTML file being viewed right now. Nothing is uploaded anywhere; every edit stays on the device until the file itself is downloaded. A completed profile is simply this same file, saved with its data filled in.

Introduction

Open Access License

This document, the Lab Informatics (LI) Feature Matrix it defines, and every vendor profile published in the LiMSwiki Laboratory Informatics Vendor Profile series are made available under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License (CC BY-NC-SA 4.0).

What This License Permits

Under CC BY-NC-SA 4.0, anyone is free to:

Share — copy and redistribute this document, the Feature Matrix, or any vendor profile in the series, in any medium or format.
Adapt — remix, transform, and build upon the material for any non-commercial purpose, including producing a new vendor profile using the same Feature Matrix and scoring rubric.

What This License Requires

These permissions come with three conditions that apply to any use of this material:

Attribution. Appropriate credit must be given to LiMSwiki.org, a link to the license provided, and any changes made to the original material clearly indicated. This must be done in a reasonable manner, but not in any way that suggests LiMSwiki.org endorses the user or their use of the material.
NonCommercial. This material may not be used for commercial purposes. Internal evaluation, academic research, and non-commercial reference use are permitted; incorporating this document or its content into a paid product, a commercial consulting deliverable, or any other revenue-generating use is not, without a separate commercial license from LiMSwiki.org.
ShareAlike. If this material is remixed, transformed, or built upon, the resulting contributions must be distributed under this same CC BY-NC-SA 4.0 license.

Full License Text

This summary is not a substitute for the license itself. The complete, legally binding terms are available at creativecommons.org/licenses/by-nc-sa/4.0.

Preface

About This Document

This is LIMSpec, the master reference document for the LiMSwiki Laboratory Informatics Vendor Profile series (Version 2026R1.52). It defines the "Lab Informatics (LI) Feature Matrix" (referred to throughout this series simply as the "Feature Matrix") — a fixed, standards-referenced set of 469 functions across 28 categories representing the complete functional scope of laboratory informatics as a domain. This document contains no vendor names, scores, or evaluations. It exists so that any vendor profile in the series can be produced by applying the same fixed matrix and scoring rubric to that vendor's own documentation.

What the Feature Matrix Is

The Feature Matrix was constructed to represent laboratory informatics functionality independent of any single vendor's product categories or marketing language. Its construction rests on two foundations:

Governing standards. ASTM E1578 (Standard Guide for Laboratory Informatics, covering LIMS/LES/LIS/ELN/SDMS relationships and terminology), CLSI LIS08-A (clinical LIS functional requirements), CLSI AUTO08/LIS01/LIS02 and POCT1-A/IHE LAW/SiLA2 (instrument and middleware connectivity), NIH and academic ELN governance guidance, ISA-88 and USP <1058> (laboratory execution and batch/instrument qualification systems), 21 CFR Part 11 (FDA electronic records and electronic signatures), ISO/IEC 17025 (general requirements for the competence of testing and calibration laboratories), the OAIS Reference Model/PREMIS/FAIR Data Principles (scientific data management and digital preservation), ISO 15489 (records management), ISO 9001 (document control), and ISO 31000/COSO ERM/the OCEG GRC Capability Model (governance, risk, and compliance). Each standard was used the same way: read for the specific functional requirements, terminology, or constraints it places on a laboratory informatics system, then translated into one or more discrete, vendor-neutral function entries within the appropriate Feature Matrix category, rather than copied wholesale as a checklist. Appendix A lists this narrower set of standards alongside the category structure each most directly shaped. Appendix C documents the fuller sourcing base — over 130 regulations, accreditation requirements, and guidance documents — that LIMSWiki's own LIMSpec methodology draws on and that this matrix was cross-checked against category by category.
Iterative structural review. Categories and individual functions were added over multiple review passes as gaps in the taxonomy were identified, continuing until further review stopped surfacing materially new functionality — indicating the matrix had reached practical completeness for the domain.

How This Matrix Is Used

To produce a vendor profile from this matrix, each of the 469 functions is evaluated against that vendor's own current product documentation, technical materials, and other publicly available sources, and assigned one status from the Scoring Rubric below. The resulting profile documents that vendor alone against the fixed matrix — it is not, and should not be presented as, a comparison against any other vendor. Two vendor profiles produced from this same matrix can be read side by side precisely because both were scored against identical functions using an identical rubric — not because either vendor was evaluated relative to the other.

This Is a Definitional Document, Not an Evaluation

Nothing in this document constitutes an assessment of any company, product, or vendor. It defines the 469 functions that a completed vendor profile would be scored against, and the rubric used to score them. It contains no claims about what any particular vendor does or does not support.

Independence & Authorship

Vendor Neutrality, AI Authorship & Independence

This section states plainly who produced this document, how, and under what constraints — so that the Feature Matrix and every profile built from it can be evaluated on those terms.

The LIMSpec Is a LabLynx Creation

LIMSpec, and the LiMSwiki.org platform on which it is published, were developed by LabLynx, Inc. as a community initiative for the laboratory informatics profession. LabLynx built both the wiki and the underlying Feature Matrix methodology because the industry lacked a shared, vendor-neutral reference for comparing LIMS, LIS, ELN, SDMS, and related systems on functional terms rather than marketing language — every vendor described its own product differently, in its own terminology, making even basic side-by-side comparison difficult for anyone evaluating software from outside a single vendor's own sales process.

LabLynx created LIMSwiki and LIMSpec together as an open, joint community effort rather than a closed or proprietary comparison tool, on the premise that laboratories, researchers, and procurement teams make better software decisions when they have access to open information and full transparency about what a system actually does — documented against a fixed, independently defined standard, not a vendor's own claims alone. The editorial and evidentiary independence described throughout the rest of this section — vendor-neutral construction, evidence-based status assignment, fully disclosed methodology — governs how LIMSpec is applied to every vendor equally, including LabLynx's own profile in this series.

The underlying premise is straightforward: informed, educated buyers have the most success with the software they choose. A shared, open information model that lets every laboratory informatics vendor be evaluated against the same functional matrix serves that goal directly, regardless of which single company originally built the tool that made it possible.

Vendor-Neutral by Design

The Feature Matrix defined in this document was constructed to represent the complete functional scope of laboratory informatics as an industry domain — not the feature set, terminology, or marketing framing of any single company. No vendor commissioned, funded, previewed, or influenced the selection, wording, or organization of the 469 functions or 28 categories in this matrix. The matrix does not favor the architecture, terminology, or product strategy of any particular vendor over another; where a function reflects terminology closely associated with one vendor's marketing (for example, agentic AI orchestration or a specific data-interchange standard), it was included because it represents a genuine, independently identifiable capability class in the broader market — not an endorsement of the vendor that popularized the term.

AI Authorship

This document, the underlying Feature Matrix, and every vendor profile produced from it are researched and written by Claude, an AI system developed by Anthropic. The standards research, category and function definitions, scoring rubric, and — in a completed vendor profile — the evidence gathering and status assignments for that vendor, are Claude's own work product, produced through direct research against publicly available standards documents, vendor materials, and independent sources. No human author drafted, rewrote, or supplemented the substantive content of this document or of any profile produced from it prior to publication.

AI Transparency Notice

As an AI-generated document, this matrix and any profile produced from it reflect Claude's interpretation of publicly available standards and materials as of the time the research was conducted. Readers are encouraged to verify all standards citations and, in a completed vendor profile, all vendor-specific claims directly against primary sources before relying on them for a purchasing, compliance, or research decision.

Objectivity Through Disclosed Method, Not Claimed Authority

This document does not ask to be trusted on the basis of expertise or authority. It asks to be checked. Every function in the Feature Matrix is traceable to a named standard or category of standards (Appendix A). Every status in a completed vendor profile is traceable to a specific source, documented against that function. Claude applies the same rubric, the same category structure, and the same evidentiary standard — evidence specific to the vendor in question, or the function is marked Not Supported — to every vendor profiled. This consistency of method, not any claim of neutrality on Claude's part, is what this document offers as its basis for being read as objective.

Scoring Rubric

When this matrix is applied to a specific vendor, each function is assigned one of the four statuses below, based on that vendor's own documentation and other publicly available materials.

Status	Meaning	Points
✓ Off-the-Shelf	Feature is included and works as described by the vendor in the LIMSpec for that item; no configuration or customization needed — it just works off the shelf.	1
⚙ Configurable	Feature is included but requires configuration through software settings to work as expected; does not require developer coding.	1
½ Extensible	Base feature exists but requires some coding or development to make it work as expected; will not affect the vendor's ability to stay on a COTS version and maintain its upgrade/support path.	0.5
✕ Not Supported	Feature is not part of the system but this does not preclude it being added as a custom feature; the vendor must address whether custom features are possible.	0

A category score is the sum of points earned across the functions in that category (Off-the-Shelf and Configurable each contribute 1 point, Extensible contributes 0.5 point, and Not Supported contributes 0). An overall vendor score is the total of these points summed across all 469 functions. Every function is weighted the same way regardless of category; no category itself is weighted more heavily than another.

Reading Any Score Produced From This Rubric

A score produced using this rubric measures how much of the Feature Matrix a vendor's public documentation confirms — not how good, complete, or suitable that vendor's product is for any particular buyer. Many functions in this matrix are highly specialized (e.g., hospital core-lab features, biobanking-specific tooling, R&D chemistry/biology registration systems, agentic-AI orchestration) and fall outside the stated target market of many vendors entirely. A lower score in a specialized category is not evidence of a weaker product for buyers who do not need that specialization.

Vendor Profile

Corporate background and product line for the vendor this profile is applied to, as stated in the vendor's own materials and independently verified public sources. This master edition ships blank — click Edit on any row below to fill it in.

Vendor/Product LIMSpec Score

The Vendor/Product LIMSpec Score is the sum of points earned for this vendor across every category in this profile — all 28 Feature Matrix categories plus any categories added in Chapter 29 (Vendor Added Categories). Off-the-Shelf and Configurable each contribute 1 point, Extensible contributes 0.5 point, and Not Supported contributes 0. Every function is weighted the same way regardless of category, so the score rises automatically as functions are marked Off-the-Shelf, Configurable, or Extensible and falls if any are changed back to Not Supported. Current score: No Score

Master Template

LIMSpec Score:No Score

Version

Off-the-Shelf

Configurable

Extensible

Not Supported

Attribute	Detail

Why This Chapter Comes First

Vendor Profile precedes the functional matrix chapters in every vendor-specific edition so that a reader has basic corporate context — who the vendor is, how long they've operated, what they call their products — before encountering 469 individual function-by-function status determinations. Like every other claim in a completed profile, the facts in this chapter should be sourced against the vendor's own materials.

Category 1 of 28

Sample & Specimen Management

21 functions defined in this category.

Sample and specimen management governs everything that happens to a physical sample from the moment it enters a laboratory's custody until its final disposition. This category defines the foundational transactions every other laboratory function ultimately depends on: accessioning, labeling, chain-of-custody tracking, aliquoting, batch and worklist organization, status and lifecycle tracking, and retention or disposal scheduling. Because virtually no downstream test, result, or report can exist without a properly identified and tracked sample, gaps here tend to surface as data-integrity and traceability problems everywhere else in the system. In day-to-day operations, this category determines how quickly and accurately samples move from receipt through preparation to testing, how confidently a lab can prove what happened to a given specimen if a result is ever challenged, and how well the system scales as sample volume grows. Its importance is universal across laboratory types, but the specific functions that matter most vary by discipline — chain-of-custody rigor dominates in forensic and regulated testing, while pre-registration and self-service submission matter more to high-volume commercial and clinical reference labs serving external clients.

Sample/specimen accessioning
Barcode/label generation & scanning
Chain-of-custody tracking
Chain-of-custody transfer tracking to external/outside entities for regulated samples (select agent, cannabis, etc.) with certification numbers
RFID-based sample/specimen identification (in addition to barcode)
Automated/triggered sample pre-registration (date, time, web-request, or API-initiated)
Sample receipt variance checking against customer/lab sampling requirements (general-purpose, all industries)
Location/industry-specific safety information display upon sample registration
Automatic sample-number generation for calibration, validation, and maintenance activities
Sample splitting / aliquoting
Batch / worklist management
Sample status/lifecycle tracking
Multi-site sample transfer/routing
Sample re-test/re-sample workflow
Sample scheduling (recurring/routine)
Container/vessel tracking
Sample disposal/retention tracking
Client sample submission (self-service)
Sample lineage/genealogy tracking (parent-child/derivative sample relationships)
Sampling site master list management (site codes, demographics, commodity/substrate association, active/inactive status)
Environmental monitoring program for production/cleanroom facilities (scheduled site testing, offsite/randomized sampling)

Category 2 of 28

Case & Project Management

19 functions defined in this category.

Case and project management organizes laboratory work around a legal case, research study, or client-funded project rather than around individual samples alone, reflecting how forensic, medical examiner, and contract research operations actually function day to day. This category covers case-centric workflows, multi-discipline routing, project-based sample grouping, workload balancing and scheduling, legal hold and evidence-integrity controls, and independent case review. In practice, it determines whether a laboratory can coordinate work across multiple analysts, disciplines, or departments on a single matter without losing track of accountability, and whether it can defend that work if results are later scrutinized in court, an audit, or a client dispute. For forensic and medical examiner laboratories, functions like legal hold, destructive-testing authorization, and examiner testimony tracking are essential compliance infrastructure. For contract research organizations and academic core facilities, project-based grouping and workload management drive operational efficiency and client billing accuracy. General-purpose clinical or industrial labs typically use a narrower slice of this category, since not all of their work is organized around discrete legal or sponsor-funded matters.

Case-centric workflow (forensic/legal)
Multi-discipline case routing
Medical examiner case management
Project-based sample grouping (CRO model)
Cross-team/cross-department data segregation
External lab referral tracking
Analyst workload balancing & case assignment dashboard
Personnel-to-task scheduling and allocation tools (staffing/instrument resource planning)
Personnel workload capping (limit samples/hours per analyst per sample type, e.g., cytology slide caps)
Automated workload-leveling task release (lean laboratory workflow balancing)
Kanban-style task board visualization for workflow/status tracking
Investigation linkage to case/sample
Cross-facility sample sharing / single accession across multiple labs (no duplicate login)
Legal hold / evidence integrity controls
Destructive testing authorization gate for evidence (prevent testing until documented approval)
Periodic independent case review scheduling (administrative/technical review by uninvolved personnel)
Examiner testimony documentation and periodic evaluation tracking
Investigational product (drug/blood product/medical device) chain-of-custody tracking for clinical trials
Assignment of unique entity identifiers (NPI/ORI) to enacting/subcontracted entities, appearing on records/reports

Category 3 of 28

Test, Method, Specification & Limits Management

16 functions defined in this category.

This category defines how a laboratory manages the analytical methods it performs and the specifications a result must meet to pass. It covers method library management, specification and limits versioning, automated pass/fail comparison, out-of-trend detection, multi-tier specification approval, reflex testing rules, method validation linkage, calculation engines, and unit and significant-figure handling. These functions sit at the core of every quantitative and qualitative test a laboratory runs, since a result is only meaningful when it can be automatically and correctly evaluated against the right version of the right specification. Operationally, this category is what allows a lab to apply the same method and criteria consistently across every analyst and every sample, catch developing problems before they become outright failures, and demonstrate during an audit that every specification change went through proper review. Its influence is broadest in regulated and accredited testing environments — pharmaceutical, clinical, and environmental labs in particular — where inspectors specifically look for evidence that testing was performed against the currently approved method and specification version, with a documented history of every prior revision.

Method library management
Specification/limits versioning
Automated pass/fail comparison to spec
Product/method-linked specification sets
Out-of-trend (OOT) detection
Multi-tier specification approval workflow
Reflex/conditional testing rules
Method validation documentation linkage
Calculation engine (result derivation)
Multi-data-type result field support (numeric, text, date, list, file, calculated, Boolean, interval)
Qualifier/operator entry with numeric results (<, >, ±)
Bulk manual result entry via spreadsheet upload (non-instrument-sourced)
Configurable significant-figures/rounding-rule definition for reported numeric results
Units of measure & unit conversion
Limit of Detection (LOD) / Limit of Quantitation (LOQ) tracking per method
In-process manufacturing material sample flagging and quality-attribute tracking (identity, strength, quality, purity)

Category 4 of 28

Laboratory Execution System (LES)

15 functions defined in this category.

A Laboratory Execution System actively directs how a procedure is carried out in real time, rather than simply documenting it afterward. This category covers guided step-by-step execution, electronic batch records, yield and hold-time tracking, in-process e-signoff, deviation capture, equipment and reagent verification at point of use, real-time control-limit monitoring, and ISA-88-aligned recipe and equipment-state modeling. Its defining operational role is converting a paper batch record or SOP into an actively enforced digital procedure that prevents an operator from skipping steps, using unqualified equipment, or missing a required sign-off, catching problems while a process is still underway rather than after it is complete. This matters most in regulated manufacturing and complex multi-step analytical work — pharmaceutical batch production, sample preparation for regulated testing, and any process where sequence and completeness are themselves quality-critical. Laboratories performing straightforward, single-step bench testing without formal batch production generally have limited use for this category, while pharmaceutical, biotech, and other GMP manufacturers depend on it as core infrastructure for demonstrating that every batch was produced exactly as its approved procedure specifies.

Guided step-by-step execution
Electronic batch records
Theoretical vs. actual yield calculation and recording across production phases
Inter-process time tracking (production process timing/hold-time monitoring)
In-process e-signoff at each step
Deviation capture during execution
Equipment/reagent verification at point of use
Real-time in-process control limits
Paperless work-instruction display
Execution audit trail (who/what/when)
ISA-88 recipe hierarchy support (General/Site/Master/Control recipe levels)
ISA-88 equipment/phase state model with mode/state management and interlocks
USP <1058> analytical instrument/software qualification categorization (Group A/B/C)
Recipe versioning with phase-level change control and impact analysis
Weigh & dispense integration with tolerance/limit checking

Category 5 of 28

Electronic Lab Notebook (ELN) Core

26 functions defined in this category.

The Electronic Lab Notebook Core category defines the primary digital record of what a scientist actually did in an experiment and why — the direct replacement for a paper notebook page. It includes rich-text documentation, structured metadata fields, protocol checklists with timestamped execution, file attachments, template libraries, version and revision history, electronic signatures, tagging and full-text search, collaboration and commenting, and specialized capabilities like code blocks, freehand sketching, and cryptographic timestamping for intellectual-property protection. Operationally, this is the single most universally used category in the entire matrix, since virtually every laboratory discipline needs some mechanism for narrative, attributable documentation of experimental work, however much that narrative is supplemented by structured data elsewhere. Its influence on day-to-day work is direct and constant: how easily a scientist can document an experiment, how reliably that record can later be searched, audited, or defended, and how well institutional knowledge survives staff turnover all depend on the depth and quality of ELN functionality. Regulated laboratories additionally depend on this category to meet electronic-record requirements around signatures, version history, and data integrity.

Rich-text experiment documentation
Structured/custom metadata fields
Protocol/step checklists with timestamped execution
Experiment-to-resource linking
File attachment support
Template library (protocol standardization)
Version/revision history on entries
Electronic signature on entries
Tagging & full-text search
Comments/collaboration on entries
RFC 3161 / blockchain timestamping (IP protection)
Multi-experiment hierarchy with genealogy/lineage tracking
LaTeX/equation rendering
Export to PDF / RO-Crate / interoperable format
Desktop application bridge for native file editing
Real-time collaborative multi-user notebook editing
Legacy paper record digitization workflow with mandated metadata capture
Automatic periodic autosave during data entry
Structured data migration tooling from legacy ELN/paper/spreadsheet sources
File-level version history on individual attached files (distinct from body-text revision history)
Syntax-highlighted code block support within ELN entries (Python, R, bash, etc.)
Built-in freehand draw/sketch annotation tool within ELN entries
@Mention-style inline cross-referencing of inventory items, protocols, samples, or team members (live navigable link)
Direct JSON metadata editor for advanced/bulk metadata manipulation
One-click entry/template duplication retaining metadata and steps
Custom interactive widget/JavaScript builder embeddable within ELN entries (calculators, data capture forms, lookup tools)

Category 6 of 28

Scientific Data Management (SDMS)

18 functions defined in this category.

Scientific Data Management covers how a laboratory captures, archives, and governs the raw data and documents its instruments and staff generate, independent of any single experiment record. This category includes raw instrument data capture, long-term archival separate from the operational database, instrument file-format parsing, document version control and SOP change control, metadata tagging, data-integrity checksums, and specialized long-term preservation standards such as OAIS and PREMIS for organizations with multi-decade retention obligations. Its operational role is preserving the primary evidentiary record behind every reported result and every controlled document, so that a calculated result or a current SOP can always be traced back to the original data or approved version that produced it. This matters for every laboratory to some degree, since ALCOA+ data-integrity principles specifically require original data to be preserved, but the depth of SDMS functionality needed scales sharply with data volume, instrument diversity, and retention duration — a lab with a handful of instruments and modest retention needs has far simpler requirements than one managing years of multi-instrument data under decades-long regulatory retention rules.

Raw instrument data capture & archiving
Long-term data retention independent of operational DB
Instrument file format parsing
Centralized document/file repository
Document version control
SOP management with change control
External BI tool integration (Power BI/Tableau)
Modern web-based SDMS interface
Metadata tagging on archived data
Data integrity checksums / tamper-evidence
Image/photo capture & management (specimen/slide imaging)
OAIS-compliant digital preservation architecture (ISO 14721)
PREMIS preservation metadata support (ISO 22927 — technical/provenance metadata for long-term archival)
FAIR data principles compliance framework (explicit Findable/Accessible/Interoperable/Reusable)
ISO 19115 / EPA Metadata Technical Specification compliance for environmental data publishing
Dedicated education/course-management module for teaching laboratory courses (assignments, grading, TA feedback, institutional LMS integration)
Direct integration with public research data repositories (e.g., Zenodo, Figshare, Dataverse, Dryad) for one-click dataset deposit
Automated file watching/ingestion (hot-folder monitoring for automatic data capture)

Category 7 of 28

Stability, Formulation & Batch Management

10 functions defined in this category.

This category supports laboratories that must demonstrate a product remains safe and effective throughout its shelf life, or that manage the formulation and batch-level production record behind a manufactured product. It covers stability protocol design, pulling-schedule automation, accelerated stability modeling, formulation and recipe management, batch-to-recipe linkage, batch release workflow to a Certificate of Analysis, and rework eligibility. Operationally, these functions govern long-running, multi-year testing programs and the formal decision gates that determine whether a batch can be released to a customer or must be reworked or rejected. This is essential, purpose-built functionality for pharmaceutical, biotech, food, and other regulated manufacturers running formal stability programs and batch production, where a missed pull date or an undocumented formulation change carries direct regulatory consequences. Laboratories that perform only analytical testing without manufacturing a formulated product, or that have no time-based shelf-life claims to support, will find this category largely inapplicable, making it one of the more industry-specific rather than universally relevant sections of the matrix.

Stability protocol design
Pulling schedule automation
Accelerated stability condition simulation
Interval/cycle-based study lifecycle workflow
Formulation & recipe management
Batch-to-recipe linkage
Batch release workflow to COA
Batch reprocessing/rework eligibility flagging and workflow
Legacy stability system data migration support
Freeze/thaw cycle tracking (biobanking/bioanalytical samples)

Category 8 of 28

Molecular Biology / Life Sciences Tools

27 functions defined in this category.

This category covers specialized bioinformatics and molecular biology capabilities that go well beyond general-purpose sample or experiment tracking: PCR and NGS workflow support, plasmid and sequence editing, plate management, compound and biological sequence registration, in silico cloning and PCR modeling, CRISPR guide design, structure prediction tools like AlphaFold integration, flow cytometry and mass spectrometry analysis, and in vivo animal study management. Its operational relevance is concentrated almost entirely in life-science research, biotech, and pharmaceutical discovery organizations, where these functions directly support the scientific work of designing genetic constructs, screening compounds, and analyzing complex biological data — work that a general-purpose LIMS or ELN data model cannot adequately represent on its own. For laboratories in these disciplines, the depth of molecular biology tooling can be a decisive platform differentiator, since it determines whether scientists can work entirely within one system or must constantly move data between the platform and separate specialized bioinformatics software. General clinical, environmental, industrial, and forensic laboratories typically have no use for this category, as it addresses a scientific domain distinct from their core testing work.

PCR/NGS workflow support
Plasmid/sequence map editor
Plate management (96/384-well)
Reagent lot traceability (molecular)
High-complexity testing documentation
Genomics/proteomics data handling at scale
Chemical/molecular structure capture within ELN
Chemical structure drawing, rendering & structure-based search
Compound/chemical registration system (unique ID assignment, structure-based)
Biological sequence/construct registration system
High-throughput screening (HTS) assay data management
CRISPR guide design & genome browsing tools
Multiple sequence alignment (DNA/RNA/amino acid) with consensus generation
In silico restriction enzyme digest modeling (cut site/fragment prediction)
In silico multi-fragment cloning strategy modeling (Gibson Assembly, Golden Gate)
In silico PCR amplification modeling (primer binding verification, product prediction)
Codon optimization for target organism expression
NCBI BLAST integration for sequence homology searching
AlphaFold / protein 3D structure prediction integration
Flow cytometry data analysis tools (FCS file capture, gating, visualization)
Mass spectrometry / proteomics analysis tools (peptide/protein identification, quantification, PTM analysis)
In vivo animal study design and management module (multi-arm treatment groups, timepoints, endpoint tracking)
Multi-parameter animal randomization algorithms for eliminating group-assignment bias
In vivo study real-time analytics (body weight change, nadir calculations, survival analysis)
Bioprocess / process development study tools (recipe execution, assay runs, biomanufacturing workflows)
Antibody / peptide bioinformatics (BCR/TCR/VHH/scFv sequence analysis)
HGVS (Human Genome Variation Society) nomenclature support for sequence variant reporting

Category 9 of 28

Instrument & Equipment Integration

25 functions defined in this category.

This category defines how a laboratory's instruments connect electronically to its information systems, covering bidirectional result transmission, autoverification, HL7/ASTM and modern connectivity standards like SiLA 2, worklist automation, calibration and maintenance scheduling, qualification records linkage, and centralized connectivity gateways for multi-vendor instrument fleets. Its operational impact is direct and substantial: reliable instrument integration eliminates manual transcription, one of the most well-documented sources of laboratory error, while enabling automation like rules-based result release that would be impossible if data required manual entry. Every laboratory generating instrument data benefits from this category to some degree, but its practical importance scales sharply with instrument count, sample volume, and fleet diversity — a lab with one or two instruments has comparatively modest integration needs, while a high-volume clinical or industrial laboratory operating dozens of different instrument models depends on broad driver support and centralized connectivity architecture to avoid a costly, ongoing custom-integration burden. Regulated laboratories also rely on this category to keep out-of-calibration instruments from being selected for use, a specific and frequently audited compliance control.

Bidirectional instrument result transmission
Autoverification of instrument results (rules-based release without manual review)
HL7/ASTM analyzer interface support
Worklist download automation to instruments
Middleware/driver library breadth
Chromatography Data System (CDS) integration
Equipment calibration & maintenance scheduling
Manual instrument data transfer elimination (auto-capture)
Point-of-care (POC) device integration
Instrument qualification records linkage
Real-time instrument status monitoring
Instrument/equipment reservation and usage scheduling (booking system)
Scheduled/automatic instrument online/offline state management
Automatic prevention of instrument selection when out-of-calibration, overdue maintenance, or under investigation
Calibration activity linkage to certified reference material/measurement standards
Parent-child instrument dependency management (auto-offline cascade for components)
Usage-count-based instrument event triggers (in addition to calendar-based scheduling)
Closed-loop screening workflow (ELN/LIMS request automatically triggers an instrument run, with results parsed and returned without manual data transfer)
PubMed literature search/import integration for linking references to notebook entries
Cleanroom/pharma manufacturing instrument integration
SiLA 2 / modern open instrument connectivity standard support (plug-and-play discovery, streaming telemetry)
AnIML (Analytical Information Markup Language) data format support
Allotrope Data Format (ADF) support for vendor-neutral scientific data exchange
IHE LAW profile support (standardized plug-and-play multi-vendor instrument connectivity)
Centralized instrument connectivity broker/gateway (multi-protocol translation hub)

Category 10 of 28

Robotics, Automation & IoT

10 functions defined in this category.

This category covers physical automation and connected-sensor technology within the laboratory: liquid-handling robotics orchestration, robotic sample handling, automated data-workflow triggers, IoT-based environmental monitoring, predictive maintenance, automated reorder triggers, and installable automation modules. Its operational value centers on removing manual labor and manual error from high-volume, repetitive physical tasks and continuously monitoring conditions — like freezer temperature — that would otherwise depend on periodic manual checks. Laboratories with significant investment in liquid-handling automation, high-throughput screening, or large sample volumes benefit substantially, since these functions directly reduce both labor cost and the physical error risk associated with manual sample handling at scale. Environmental monitoring of temperature-sensitive storage in particular is close to a baseline expectation across nearly every laboratory type, since an unnoticed freezer failure can destroy irreplaceable samples within hours. By contrast, laboratories performing exclusively manual bench work without robotic equipment or IoT sensor infrastructure will find most of this category's more advanced functions, such as digital twin modeling or liquid-handler orchestration, of limited immediate relevance to their operations.

Liquid handler / robotics orchestration
Digital twin technology integration (predictive maintenance, real-time environmental modeling)
Automated data workflow triggers
IoT/environmental monitoring integration
Robotic sample handling integration
Automated reorder / procurement triggers
App package / installable automation modules
Predictive maintenance alerts (equipment)
Facility environmental/security monitoring integration (alarms, locks, doors) with notification and logging
Environmental monitoring of sample-storage equipment (incubators, freezers) with automated alerting

Category 11 of 28

Enterprise System Integration (ERP / MES / CDS / API)

14 functions defined in this category.

This category governs how a laboratory platform connects to the broader enterprise software ecosystem it operates within: REST APIs, ERP integration with systems like SAP, Manufacturing Execution System connectivity, Electronic Document Management System integration, webhook-based notifications, and pre-built third-party connector marketplaces. Its operational role is ensuring laboratory data doesn't exist as an isolated island, but instead flows into the financial, supply-chain, production, and document-control systems the rest of the organization already depends on. This matters most for larger organizations where the laboratory is one operational unit within a much larger enterprise, or for manufacturers whose lab testing directly gates a live production process and needs to communicate with plant-floor systems in near real time. A robust, well-documented API is foundational infrastructure here, since nearly every other integration in this category ultimately depends on the platform exposing a capable API other systems can build against. Smaller, independent laboratories without an equivalent enterprise-level ERP or MES ecosystem to integrate with will find comparatively less need for the deeper end of this category's capabilities.

REST API for external integration
ERP integration (e.g., SAP)
MES/PIMS integration
EDMS integration
Multi-server simultaneous API connections
Open API specification support
Webhook-based event notification
Pre-built third-party connector marketplace
LIMS-to-LIMS data transfer / multi-lab federation
VETXML veterinary data interchange format support
FDA ORA DX (Office of Regulatory Affairs Data Exchange) file format support
Selective data archiving by date/type criteria (choose which electronic data and metadata to archive)
Configurable/extensible data schema (modify underlying data structures without vendor intervention)
BioTrack THC seed-to-sale integration (alongside/alternative to METRC)

Category 12 of 28

AI, Machine Learning & Predictive Analytics

24 functions defined in this category.

This category captures how artificial intelligence and machine learning are applied within a laboratory platform, spanning embedded predictive analytics, conversational and agentic AI, anomaly and outlier detection, natural-language data querying, AI-assisted documentation and configuration, machine-learning-based QC rule tuning, and specialized applications like image-integrity verification and supply forecasting. Operationally, these functions aim to shift laboratory management from reactive to proactive, surfacing developing problems before they become failures and reducing the manual effort behind routine tasks like documentation drafting or QC review. Its practical value depends heavily on data volume and history, since most of these capabilities are genuinely predictive rather than merely automated, and models need sufficient historical data to learn meaningful patterns. This is a rapidly evolving area across the industry, and laboratories evaluating a platform on this category should weigh not just which AI functions exist, but how mature, transparent, and auditable the underlying implementation actually is — a consideration with particular weight in regulated laboratories, where relying on an unexplainable AI-driven decision can itself become an audit finding independent of whether the output was accurate.

Embedded predictive analytics
Conversational AI / digital assistant for lab operations
Agentic AI workflow orchestration (autonomous multi-step task execution)
AI-assisted no-code/low-code configuration (natural language to workflow/code generation)
Anomaly/outlier detection (AI-driven)
Natural language data query/interaction
AI-assisted documentation/notebook authoring
AI-driven scheduling/resource optimization
Machine-learning-based QC rule tuning
AI-powered audit trail analysis
Automation of manual instrument data transfer (AI/partnership-driven)
Vendor-published AI roadmap/positioning
AI model transparency / explainability documentation
Ontology-based machine learning for laboratory dataset analysis
AI-driven autonomous customization of data aggregation/transformation/reporting based on learned patterns (no explicit instruction)
AI-driven operational parameter monitoring (capacity utilization, data integrity risk) with proactive notification and logging
AI-powered conversion of PDF SOPs or text prompts into structured, importable protocol templates
Direct export/integration with dedicated statistical graphing software (e.g., GraphPad Prism)
Structure-activity relationship (SAR) / cheminformatics data visualization (compound properties vs. biological activity plotting)
Natively integrated full-featured statistical analysis / publication-quality graphing software (no data export required)
AI-powered scientific image integrity verification (detecting manipulated or duplicated images) for research-integrity screening
AI-powered supply/consumable forecasting predicting stockouts from historical usage patterns
AI-generated experimental write-up/summary from raw data
Autonomous/agentic AI review-by-exception for QC results

Category 13 of 28

Mobile, Remote Access & Multi-Site Operation

9 functions defined in this category.

This category addresses how laboratory staff access the platform away from a fixed desktop workstation and how the platform supports operations spanning multiple physical locations: mobile-responsive web access, native mobile applications, camera and GPS-based field data capture, offline data collection, multi-site configuration, and time-zone handling. Its operational relevance depends heavily on how a laboratory's actual work is distributed. Field-based programs — environmental monitoring, agricultural sampling, point-of-care testing — depend on offline capability and mobile data capture to function at all in locations with unreliable connectivity. Organizations spanning more than one physical facility need multi-site configuration and cross-time-zone handling simply to operate coherently as a single entity rather than a collection of disconnected instances. Laboratories operating from a single fixed location with all work performed by staff at desktop or bench workstations will find much of this category's field-oriented and multi-site functionality unnecessary, while any laboratory whose staff occasionally need to check status or review results away from their desk benefits at least from basic mobile-responsive access.

Mobile-responsive web access
Native mobile application
Camera/barcode scanning + GPS field data capture (mobile)
Remote/offline data collection
Multi-site/multi-lab configuration
Multi-tenant enterprise scalability
Cross-site data roll-up reporting
Time-zone/multi-region support
Voice command / hands-free lab interaction

Category 14 of 28

Inventory, Reagent & Asset Management

17 functions defined in this category.

This category manages the reagents, consumables, and equipment a laboratory consumes and relies on to operate: inventory tracking, multi-location storage, automated reorder triggers, receiving inspection, lot and expiration tracking, standard re-standardization, hazardous-material flagging, vendor approval validation, and quarantine workflows pending QC release. Its operational importance is close to universal, since virtually no laboratory operates without consuming reagents as part of routine testing, and poor inventory visibility reliably produces avoidable problems — unexpected stockouts that halt testing, expired reagents used unknowingly, and wasted material from overstocking. Lot and expiration tracking in particular underpins result validity across every discipline, since a result generated with an expired or unqualified reagent lot is a documented data-integrity concern regardless of testing type. Regulated manufacturing and testing environments additionally depend on this category's more formal controls — vendor approval gating, incoming material quarantine, hazardous-material classification — as auditable evidence that materials entering the laboratory were properly vetted before use, making this category as much a quality-system component as an operational convenience.

Reagent/consumable inventory tracking
Multi-location storage management
Automated reorder point triggers
Third-party inventory marketplace/procurement platform synchronization (e.g., Quartzy)
Supplier/vendor management
Receiving inspection workflow
Lot/expiration tracking
Standard/reagent re-standardization and revaluation tracking (assign new standard value after restandardization)
Hazardous/controlled/regulated material flagging based on physical/chemical stability classification
In-house standard/volumetric solution tracking (concentration, purity, molarity factor) for calculation use
Vendor master list with approval status for inventory order validation
Material quarantine workflow pending QC validation or disposal
Prevention of reagent/standard usage that would expire during the course of testing (mid-test expiration check)
Equipment/asset registry
Calibration/maintenance event scheduling
Storage location hierarchy (freezer/rack/box/position)
Barcode-driven inventory transactions

Category 15 of 28

Document Management & Control

16 functions defined in this category.

This category governs how a laboratory manages its controlled documents — SOPs, specifications, policies, and records — through their complete lifecycle from drafting to retirement: version-controlled repositories, approval workflows, SOP change control, records retention and disposition, document search, and integration with desktop office applications and open-access protocol repositories. Its operational role is ensuring every laboratory employee always works from the current, formally approved version of a document, and that superseded versions remain available for historical reference rather than being lost or, worse, mistakenly followed. This is foundational infrastructure for every laboratory maintaining any controlled documentation, but the compliance stakes rise sharply in regulated environments, where working from an outdated procedure version is a well-documented and specifically audited category of laboratory error. As document repositories grow over months and years, the value of strong search and retrieval capability compounds, since a large, poorly searchable archive of historical SOPs and records becomes progressively less useful even though the underlying documents remain technically preserved.

Version-controlled document repository
Document approval workflows
SOP change control
Centralized protocol repository (team vs personal)
Controlled document distribution/read receipts
Records retention policy enforcement
Document search across repository
File format flexibility (native app editing bridge)
Records disposition scheduling with automated destruction/transfer workflow (ISO 15489-aligned)
Document authenticity/reliability/integrity metadata per ISO 15489
Desktop application bridge allowing attached files to be opened/edited in native desktop apps with automatic save-back to the platform
Real-time Microsoft Office Online co-authoring (Word/Excel/PowerPoint) natively within the platform
Direct import from open-access protocol repositories (e.g., protocols.io)
Native SQL-queryable data warehouse spanning all platform data for advanced analytics
DOI (Digital Object Identifier) assignment and direct open-data publishing from within the platform
SOP/method revision linkage to specific tests performed using that revision

Category 16 of 28

Learning & Competency Management (LMS)

10 functions defined in this category.

This category tracks staff training, qualification, and ongoing competency — verifying not just that a procedure exists, but that the person performing it has been properly trained and remains current on the methods and equipment they use. It typically includes training assignment and completion tracking, competency assessment scheduling, certification expiration alerts, and linkage between training records and the specific SOPs or methods they cover. Operationally, this category matters because personnel qualification is a foundational, frequently audited element of any laboratory quality system — a technically correct procedure performed by an inadequately trained analyst is still a quality risk, and regulators specifically expect documented evidence connecting a person's qualifications to the work they are authorized to perform. This is essential in every accredited or regulated laboratory environment, where training records are a routine, specific focus of external inspections, and increasingly valuable even in unregulated research settings as a way to ensure consistent, competent execution across a growing or rotating staff. Laboratories with very small, stable, informally managed teams may find a lighter-weight approach to this category sufficient.

Dedicated LMS module
Training assignment & tracking
Competency assessment documentation
Annual re-certification workflow
Self-service onboarding content hosting
Regulatory training linkage (GLP/safety)
Infrequent-test competency verification tagging/alerting (additional validation required before performing rarely-run tests)
Batch/bulk personnel data modification tools
Analyst method-specific qualification/authorization tracking (gating workflow access)
Training matrix report showing personnel-to-competency/certification mapping

Category 17 of 28

Client / Patient / Physician Portal & Collaboration

8 functions defined in this category.

This category provides external stakeholders — clients, patients, or referring physicians — with a self-service window into the laboratory's work, without requiring laboratory staff to manually relay every status update or result. It typically covers order submission portals, result and report delivery, status inquiry dashboards, and secure messaging or collaboration features between the laboratory and its external parties. Operationally, a strong portal reduces the administrative burden of fielding routine status inquiries by phone or email, while giving clients and patients more visibility and control over their own orders and results. This is most valuable to laboratories serving external customers directly — commercial reference labs, clinical laboratories reporting to patients and physicians, and contract research organizations — where client-facing service quality is itself a competitive differentiator. Purely internal laboratories, such as an R&D lab serving only its own organization's scientists, have comparatively little use for this category, since all of their result recipients already have direct internal system access rather than needing an external-facing portal experience.

Clinical physician ordering portal
Clinical patient portal
Internal lab portal (cross-department)
CRO / external client portal
Results/report access for external users
Messaging/team collaboration within platform
Recurring test program self-scheduling (client-facing)
GDPR-compliant client communications

Category 18 of 28

Billing, Customer & Project Administration

8 functions defined in this category.

This category covers the business-administration side of laboratory operations: client account management, order and quote management, billing and invoicing tied to completed testing, and project-level cost tracking. Its operational role is connecting the scientific work a laboratory performs to the commercial relationship and financial transaction behind it, ensuring that completed testing translates accurately and efficiently into an invoice, and that client account information stays consistent across every order and interaction. This matters most for laboratories operating as a service business to external customers — commercial reference labs, contract research organizations, and any lab billing clients per sample or per project — where inaccurate or delayed billing directly affects revenue and client relationships. Laboratories performing exclusively internal work for their own parent organization, with no external client billing relationship to manage, will find this category largely inapplicable. Even among labs that do bill externally, the depth of functionality needed scales with the complexity of their pricing model and client base, from simple flat-rate billing to complex, project-based cost accounting.

Customer/client record management
Project setup & tracking
Test price list management
Invoice generation
ERP billing system integration
Contract/pricing tier management
Quote/SOW review and approval workflow (CRO client-facing)
ICD-10 / billing code screening & automation

Category 19 of 28

Business Intelligence, Dashboards & Reporting

27 functions defined in this category.

This category covers how a laboratory turns its accumulated operational and scientific data into visual insight: configurable dashboards, custom report generation, turnaround-time and productivity analytics, trend visualization, and integration with external BI platforms like Power BI or Tableau. Its operational value lies in making patterns and problems visible that would otherwise stay buried in raw transactional data — a slipping turnaround time, an underused instrument, a client whose order volume is quietly declining — well before they become obvious through anecdotal observation alone. Every laboratory benefits from at least basic reporting capability, but the sophistication needed scales with organizational size and complexity: a small lab may be well served by simple built-in reports, while a larger, multi-site organization often needs the deeper cross-departmental analytics and self-service report-building that dedicated BI integration provides. This category also underpins evidence-based management decisions and client-facing performance reporting, making the depth and flexibility of a platform's reporting and dashboard capability a meaningful factor in day-to-day operational visibility and long-term continuous improvement.

Configurable role-based dashboards
Ad hoc query builder
Custom report designer
Trend/charting visualization
KPI tracking (TAT, bottlenecks, OOS rate)
Export to PDF/Excel/Word
SQL/data warehouse access for external BI tools
Scheduled/automated report distribution
Control chart visualization
Client-facing report/dashboard access
Cross-module unified reporting (ELN+LIMS+QMS)
Regulatory submission report formats
Accreditation-status linkage controlling which accreditation labels/logos appear on reports (e.g., WADA, A2LA)
Proactive advance alerting for at-risk turnaround time (TAT) or likely OOS before results are finalized
Amended/reissued report versioning with visible change flag and reason-for-change documentation
NPDES DMR (Discharge Monitoring Report) regulatory package (EPA)
EPA ASR, SEDD, and ERT electronic data exchange format support (environmental regulatory reporting)
Electronic Data Deliverable (EDD) validation linked to Quality Assurance Project Plan (QAPP)
Test utilization / necessity-checking analytics against established benchmarks
Laboratory utilization / test-ordering stewardship analytics
Test-based work capacity/throughput reporting and forecasting
Workflow/value-stream mapping with failure-point identification (lean/continuous-improvement tooling)
Visual drag-and-drop workflow canvas showing linear/non-linear step relationships
Bottleneck/stalled-task detection based on inactivity duration thresholds
In-memory associative analytics engine (high-speed pattern/trend discovery)
Living knowledge graph for scientific data (contextualized cross-entity search)
Regulatory dataset assembly (CDISC SEND/SDTM)

Category 20 of 28

Quality Management, CAPA & Investigation (OOS/OOT)

23 functions defined in this category.

This category manages a laboratory's formal quality system: deviation and nonconformance capture, out-of-specification and out-of-trend investigation workflows, corrective and preventive action (CAPA) tracking, root-cause analysis, and the documented linkage between an investigation and the sample, result, or process event that triggered it. Its operational role is ensuring that when something goes wrong — a failed result, a procedural deviation, a customer complaint — the laboratory has a structured, auditable process for investigating why, documenting the response, and verifying the corrective action actually resolved the underlying problem rather than merely addressing its symptom. This is essential infrastructure in every regulated laboratory, where a formal, functioning CAPA and investigation program is not merely good practice but typically an explicit, named accreditation or regulatory requirement, and where auditors specifically expect to trace an investigation back to its triggering event and forward to its verified resolution. Laboratories without formal accreditation still benefit from this category as a disciplined way to learn from and prevent recurrence of operational problems, though the compliance stakes are highest in accredited and regulated testing environments.

Standalone QMS / document control module
Design Control Document / Device History File for medical device development (21 CFR 820.30)
Device Master Record (DMR) and Device History Record (DHR) management (21 CFR 820.181/184)
Product recall tracking and reconciliation (distributed vs. recovered quantities by lot/batch)
HACCP/food safety plan development and Critical Control Point (CCP) workflow implementation
CAPA workflow
Non-conformance/deviation management
Dedicated OOS investigation module
Root cause analysis documentation
CAPA effectiveness verification and recurrence tracking (curbing repeat incidents)
Animal research subject tracking (acquisition, disposition, euthanization, welfare records, USDA licensing)
Internal audit program management
Compliance checklist management (CAP/CLIA/ISO)
Risk assessment documentation
Risk register with configurable likelihood/impact scoring methodology (ISO 31000-aligned)
Control library with cross-framework mapping (single control satisfies multiple regulatory frameworks)
Key Risk Indicator (KRI) tracking and risk tolerance threshold alerts
Third-party/vendor risk management (supplier assessment, onboarding, ongoing monitoring)
Governance/risk/compliance (GRC) framework
Proficiency testing management
QC sample type configuration (MB/MS/MSD/LCS)
Change control workflow
Customer/client complaint logging, investigation & trend reporting

Category 21 of 28

Statistical Process / Quality Control (SPC/SQC)

6 functions defined in this category.

This category applies statistical methods to ongoing quality control data — control charts, Westgard-style multi-rule QC evaluation, control limit calculation, and trend analysis across QC runs — to distinguish normal method variability from a genuine, actionable shift in performance. Its operational purpose is catching a drifting instrument or degrading method before it produces a batch of invalid patient or product results, using statistically grounded rules rather than relying on an analyst's subjective judgment about whether a QC result looks acceptable. This is especially well-established and valuable in high-volume clinical chemistry and similar disciplines with long, continuously run QC histories, where the underlying statistical rules were largely developed and validated, but the same principles apply to any laboratory running repeated QC measurements over time on a stable method. Smaller laboratories, or those with limited QC history and low testing volume, may find the full sophistication of formal SPC/SQC rule sets less immediately necessary than larger, high-throughput operations where subtle statistical drift can otherwise go unnoticed until it produces an outright failure.

Control chart generation
Rule-based violation detection (Westgard-style)
Trend/shift/drift alerting
Statistical calculation engine (Cpk, Ppk, etc.)
Third-party statistical engine integration
QC sample trending across time/instrument/analyst

Category 22 of 28

Electronic Signatures, Audit Trail & Validation

20 functions defined in this category.

This category provides the electronic-record backbone that regulated laboratory data integrity depends on: 21 CFR Part 11-compliant e-signatures, multi-level signature workflows, immutable and tamper-evident audit trails, revision history with reason-for-change capture, IQ/OQ/PQ validation documentation, ALCOA+ alignment, and advanced cryptographic signature schemes providing independently verifiable non-repudiation. Operationally, these functions are what make an electronic record legally and scientifically equivalent to — and in practice, often more defensible than — a signed paper original, by proving who did what, when, and that the record hasn't been altered since. This is essential in every laboratory operating under 21 CFR Part 11 or equivalent electronic-record regulations, where the evidentiary value of any digital result or document depends directly on the strength of the signature and audit-trail infrastructure behind it. Even outside strictly regulated contexts, many of these functions — version history, tamper-evident logging — are increasingly adopted as best practice for protecting research integrity and intellectual property, though the specific compliance weight of formal validation documentation and Part 11 signatures is concentrated in regulated industries.

21 CFR Part 11-compliant e-signatures
Multi-level signature workflow (analyst/reviewer/approver)
Immutable audit trail (all modules)
Audit trail coverage of administrative/privileged system actions (user accounts, passwords, permissions, system files)
Audit trail logging of failed/unsuccessful action attempts (not just successful changes)
Prevention of e-signature copy/paste/reuse by another user
Tamper-attempt logging on the audit trail itself (recording attempts to modify/delete/disable the audit trail)
Audit trail processing failure detection and alerting (write errors, audit tool failure)
Prevention of electronic signature reuse or reassignment to a different user
Revision history with reason-for-change capture
IQ/OQ/PQ validation documentation package
GAMP 5 risk-based validation alignment
ALCOA+ data integrity design principles
Tamper-evident logging
Time-stamped, non-repudiable action records
Validation support for SaaS/cloud deployment specifically
Autoverification system with rapid manual override/shutdown and revalidation capability
eIDAS-compliant electronic signature (EU qualified trust service provider)
Advanced cryptographic electronic signatures (e.g., Ed25519 public-key) providing independently verifiable non-repudiation, distinct from credential re-entry signatures
Dedicated traceability report module generating a complete linked chain-of-evidence history (materials, protocols, instruments, results) for a given experiment or sample

Category 23 of 28

Security, Identity & Access Management

27 functions defined in this category.

This category governs who can access a laboratory system and what they're permitted to do once inside: authentication methods including multi-factor and single sign-on, role-based and granular permission structures, session management, encryption in transit and at rest, and administrative controls over account provisioning and deprovisioning. Its operational role is protecting both the confidentiality of laboratory data and the integrity of the record itself, since inadequate access controls can allow unauthorized viewing of sensitive results or, more seriously, unauthorized modification of data that later gets treated as authoritative. This matters for every laboratory handling any data with confidentiality or integrity requirements, which in practice describes essentially all laboratories, but the specific depth of controls needed scales with the sensitivity of the data involved and the regulatory framework a laboratory operates under — clinical and pharmaceutical environments in particular expect granular, auditable access control as a baseline expectation. As cyber threats targeting laboratory and healthcare data continue to grow, the sophistication of a platform's security architecture has become an increasingly decisive factor in platform evaluation, independent of any single regulatory mandate.

Role-based access control (RBAC)
SAML 2.0 / OAuth SSO
LDAP/Active Directory integration
Multi-factor authentication (MFA)
AES-256 encryption at rest
TLS 1.2+ encryption in transit
SOC 2 Type 2 attestation
ISO/IEC 27001 certification
Independent annual security audit
HIPAA Business Associate Agreement availability
GDPR/CCPA compliance
Dedicated tenant / data isolation
CJIS Security Policy compliance (password standards, PIV/PKI authentication, encryption, cloud data residency within APB-member countries)
Time-of-day/network-address-based access restriction (chronometric and location-based access control)
Configurable automatic account disablement after inactivity period
Configurable concurrent session control (allow/prevent multiple simultaneous logins per user)
Configurable login banner/consent notification requiring acknowledgment before system use
Configurable account lockout threshold (failed login attempt limit)
Configurable session timeout with on-screen countdown warning before automatic logout
Vendor-enforced logical/physical access restriction to database storage infrastructure
Periodic account revalidation tagging and reminder scheduling (regulatory account certification)
Integration with physical security systems (badge access, building security) in addition to personnel directories
Authentication and role-based access control for embedded cryptographic modules
Explicit-permission activation control for connected cameras/microphones/collaborative devices with activation indicator
PII/PHI de-identification tools with segregation-of-duties enforcement (de-identified-data viewers cannot also hold re-identification access)
Consent management tools (recording and revoking individual consent for PII processing/storage)
Zero Trust security architecture applied to internal access controls

Category 25 of 28

Deployment Architecture & Scalability

9 functions defined in this category.

This category addresses the underlying technical architecture behind a laboratory platform's deployment: cloud versus on-premises hosting options, GxP-validated cloud environments, horizontal and vertical scalability, disaster recovery and backup architecture, uptime guarantees, and multi-tenant infrastructure design. Its operational relevance is largely infrastructural rather than directly user-facing, but it shapes practical questions that matter enormously over a platform's lifetime: how the system performs as sample volume and user count grow, what happens during a regional outage or disaster event, and whether hosting can meet the specific validation requirements a regulated laboratory's quality system demands. Cloud-hosted, GxP-validated deployment has become an increasingly common and often preferred option even in strictly regulated pharmaceutical and clinical environments, while some laboratories — particularly those with air-gapped security requirements or specific data-sovereignty obligations — still require or prefer on-premises, client-hosted deployment. Evaluating this category matters most during initial platform selection and any major growth or disaster-recovery-planning exercise, since architecture decisions made early are often costly to unwind later.

Cloud/SaaS hosting option
On-premises/self-hosted option
Air-gapped deployment support
Independent business-rules/workflow tier (upgrade risk isolation)
Low-code/no-code configuration (no scripting required)
Disaster recovery & business continuity (defined RTO/RPO)
Automated backup with verified restore
Configuration change management & promotion workflow (dev→test→production, audited)
Uptime monitoring & SLA

Category 26 of 28

Clinical / LIS-Specific Capabilities

25 functions defined in this category.

This category addresses functionality specific to clinical laboratories operating as a Laboratory Information System, distinct from general-purpose LIMS functionality: CLIA complexity classification support, patient demographic and order management, HL7 interfacing with hospital information systems, specimen rejection criteria specific to clinical specimens, critical-value alerting, and integration with electronic health records. Its operational role is supporting the specific regulatory and clinical workflow requirements that distinguish patient testing from general industrial, environmental, or research laboratory work — requirements tied directly to patient safety, clinical decision-making, and healthcare billing and reporting ecosystems that don't have close equivalents outside the clinical context. This category is essential to hospital and reference clinical laboratories, where functions like critical-value alerting and EHR integration are not optional conveniences but core expectations tied directly to patient care timelines. General-purpose LIMS platforms serving industrial, environmental, food-safety, or research laboratories typically have little to no need for this category's functions, since their sample data never enters a clinical care pathway with the corresponding safety and regulatory obligations that clinical testing carries.

HL7 v2 interface support
HL7 FHIR support
STAT/routine priority workflow
Patient demographic management
Critical value alert routing
Critical value read-back / acknowledgment documentation
Delta check (current-vs-prior result comparison, misidentification/anomaly flagging)
Specimen rejection criteria & workflow (labeling, integrity, hemolysis/icterus/lipemia flagging)
Cumulative patient report (historical results view across visits)
Reference/send-out lab test tracking (name/address on report, result merge)
Antimicrobial susceptibility breakpoint management (CLSI/EUCAST/FDA)
CLIA/CAP QC framework
Physician ordering / results portal
Split specimen / MRO review routing (toxicology)
Electronic Lab Reporting (ELR) to public health authorities
EMR/EHR system integration (published API, beyond HL7 messaging)
Lab order management & test panel configuration (patient-centric)
Disease surveillance & epidemiological reporting (public health)
Point-of-care testing (POCT) management module (centralized multi-site POCT oversight)
Positive Patient Identification (PPID) at specimen collection
Microbiology expert rules / workup suggestion engine
CDC PHIN (Public Health Information Network) Messaging System interface
USCDI (United States Core Data for Interoperability) v2 standard support
Configurable support for mandated code sets (ICD, HCPCS) in system nomenclature
Veterinary clinical terminology & data exchange standards support (SNOMED CT Veterinary Extension, VeNom Codes, ICAR/VICH, NAHLN HL7)

Category 27 of 28

Industry-Specific Vertical Module Coverage

22 functions defined in this category.

This category captures purpose-built functionality tailored to a specific industry vertical beyond the general-purpose capabilities covered elsewhere in the matrix — cannabis and hemp potency testing, food and agricultural safety testing, environmental and water/wastewater compliance reporting, veterinary diagnostics, forensic toxicology, and other narrowly regulated or specialized testing domains, each often tied to specific state or federal reporting systems and industry-specific regulatory frameworks. Its operational relevance is inherently industry-specific rather than universal: a laboratory operating within one of these named verticals typically finds these purpose-built modules meaningfully reduce the configuration and compliance burden compared to adapting general-purpose functionality to fit specialized regulatory requirements, while a laboratory outside that vertical has no direct use for the corresponding module at all. This category is often where the difference between a truly general-purpose platform and one with deep, named vertical specialization becomes most visible during a platform evaluation, since a vendor's breadth of vertical coverage directly indicates how many distinct, specialized industries it has built dedicated, regulation-aware functionality for rather than relying on general configurability alone.

Clinical Diagnostics
Pharmaceutical & Biotech
Environmental Testing
Forensics / Medical Examiner
Food & Beverage / Agriculture
Cannabis Testing
Academic & Core Research
Veterinary & Animal Health
General Manufacturing QA/QC
Used Oil / Industrial Fleet Testing
Toxicology / Workplace Testing
Clinical Research / Bioanalytical Study Management (CRO, PK/ADA, drug development)
Blood Bank / Transfusion Services Management
Forensic DNA profile interpretation & CODIS-compatible workflow
Anatomic Pathology / Histology & Cytology Workflow
Biobanking / Biorepository Sample Management (aliquot/derivative/pooled tracking, donor/study management)
Mining / Geochemical / Metallurgical Assay
Construction Materials / Geotechnical Testing
Water & Wastewater Utilities
Aerospace & Defense Materials Testing
Public Health Laboratories
Petroleum / Oil & Gas (Upstream & Midstream)

Category 28 of 28

Support, Training & Professional Services

8 functions defined in this category.

This category covers the vendor-provided services surrounding the software itself: implementation and onboarding support, ongoing customer support and service-level commitments, training programs and documentation, professional services for custom configuration or integration work, and community or user-group resources. Its operational relevance, unlike most other categories, is less about a feature within the software and more about the vendor relationship supporting that software over the platform's operational lifetime — how quickly a support ticket gets resolved, how well new staff can be trained on the system, and whether a vendor's professional services team can deliver custom configuration work a laboratory's internal team cannot handle alone. This matters to every laboratory adopting or operating a platform, since even the most capable software still depends on effective onboarding, ongoing support, and staff training to be used correctly and to its full potential. The specific weight a laboratory places on this category often grows with platform complexity and the criticality of the systems involved, since a poorly supported implementation of an otherwise strong platform can still produce a disappointing overall experience.

Email/help desk support
Phone support
24/7 live support
Knowledge base / self-service documentation
Structured onboarding / implementation program
User community forums/groups for peer knowledge-sharing
Dedicated account management
Source code escrow availability

Chapter 29

Vendor Added Categories

This chapter is where a vendor may define its own categories to highlight functions or features unique to its platform that are not covered by the standard 469-function LIMSpec Feature Matrix. Categories added here are numbered 29.1, 29.2, 29.3, and so on as they are added. Every function added under a vendor-added category adds to the overall Vendor LIMSpec Score exactly the same way a standard Feature Matrix function does, earning points by status (1 for Off-the-Shelf or Configurable, 0.5 for Extensible, 0 for Not Supported). No vendor-added categories have been defined yet.

Add Function

Function Name Functional Requirement (optional) Status Vendor/Product Info

Edit Field

Upgrade My LIMSpec

Before You Continue

This is the blank LIMSpec Master Template — it is treated as the upgrade target. If you are not sure this is the latest Master Template, check media.limswiki.org/books/51 first.

Select an existing, filled-out LIMSpec Vendor Profile file below. Its function statuses, Vendor Profile fields, and vendor-added categories will be migrated into a fresh copy of this Master Template. This page itself is never changed — upgrading produces a new file for you to download.

This Master Template's version	—
Selected file's version	No file selected yet

Appendix A

Sources & Standards

The governing standards and frameworks referenced in constructing the Feature Matrix itself.

ASTM E1578 LIMSWiki LIMSpec CLSI LIS08-A CLSI AUTO08 / LIS01 / LIS02 CLSI POCT1-A IHE LAW Profile SiLA 2 AnIML Allotrope Data Format ISA-88 USP <1058> OAIS (ISO 14721) PREMIS (ISO 22927) FAIR Data Principles ISO 15489 ISO 9001 ISO 31000 COSO ERM OCEG GRC Capability Model 21 CFR Part 11 42 CFR Part 493 (CLIA) ISO/IEC 17025 ISO 15189 GAMP 5 WCAG 2.1 / Section 508 eIDAS

Each standard contributed specific functions or category structures to the matrix — for example, ASTM E1578 anchors the overall LIMS/LES/LIS/ELN/SDMS taxonomy and terminology; CLSI LIS08-A and the CAP Laboratory General Checklist anchor the clinical/LIS-specific category; ISA-88 and USP <1058> anchor the Laboratory Execution System category's batch/recipe governance functions; the OAIS Reference Model, PREMIS, and the FAIR Data Principles anchor the digital-preservation functions in the Scientific Data Management category; ISO 15489 anchors the records-management functions in Document Management; and ISO 31000, COSO ERM, and the OCEG GRC Capability Model anchor the governance-risk-compliance functions within Quality Management.

Supplementary Cross-Check Sources (Not Standards)

In addition to formal standards, the matrix was cross-checked against LIMSWiki's own LIMSpec (five separate section pages) and against an independently produced, AI-authored 190-feature ELN platform comparison (Benchling, SciNote, Dotmatics, Labguru, and Labfolder). Neither is a governing standard; both were used only to test the matrix's structural completeness against real-world, deeply researched functional taxonomies, in the same reference-only spirit as the vendor gap-check passes described above.

A Living Document

The Feature Matrix is maintained as a stable reference so that vendor profiles produced at different times remain comparable. Material additions to the matrix are expected to be infrequent, since the matrix has already been reviewed for structural completeness across every major architectural lineage in the laboratory informatics market.

Appendix B

Category Summary Table

All 28 standard categories and their function counts, totaling 469 functions. Any vendor-added categories from Chapter 29 are listed below the standard categories and included in the total.

Category	# Functions
1. Sample & Specimen Management	21
2. Case & Project Management	19
3. Test, Method, Specification & Limits Management	16
4. Laboratory Execution System (LES)	15
5. Electronic Lab Notebook (ELN) Core	26
6. Scientific Data Management (SDMS)	18
7. Stability, Formulation & Batch Management	10
8. Molecular Biology / Life Sciences Tools	27
9. Instrument & Equipment Integration	25
10. Robotics, Automation & IoT	10
11. Enterprise System Integration (ERP / MES / CDS / API)	14
12. AI, Machine Learning & Predictive Analytics	24
13. Mobile, Remote Access & Multi-Site Operation	9
14. Inventory, Reagent & Asset Management	17
15. Document Management & Control	16
16. Learning & Competency Management (LMS)	10
17. Client / Patient / Physician Portal & Collaboration	8
18. Billing, Customer & Project Administration	8
19. Business Intelligence, Dashboards & Reporting	27
20. Quality Management, CAPA & Investigation (OOS/OOT)	23
21. Statistical Process / Quality Control (SPC/SQC)	6
22. Electronic Signatures, Audit Trail & Validation	20
23. Security, Identity & Access Management	27
24. Accessibility, Localization & Standards Compliance	9
25. Deployment Architecture & Scalability	9
26. Clinical / LIS-Specific Capabilities	25
27. Industry-Specific Vertical Module Coverage	22
28. Support, Training & Professional Services	8
TOTAL	469

Appendix C

Complete LIMSpec Methodology Source List

Appendix A lists the standards most directly cited in this document's own preface narrative. The list below is the fuller source list LIMSWiki's own LIMSpec methodology draws from — over 130 regulations, standards, accreditation requirements, and guidance documents that collectively shaped the Feature Matrix, organized by governing body or domain. This list is reproduced here because the preface's narrower citation set understated how broad LIMSWiki's actual sourcing is; it should be read as a supplement to, not a replacement for, Appendix A.

Each function in the Feature Matrix traces back to at least one item below. Where a source is proprietary (for example, certain accreditation body checklists), LIMSWiki notes it was either purchased for review or researched via supporting public documentation. Some further sources — such as AOAC International's Official Methods of Analysis, and the U.S. Food Emergency Response Network / Laboratory Response Network's internal procedures — are excluded entirely because they are either prohibitively proprietary or not published for public reference at all.

U.S. Federal Regulations (CFR)

Citation	Governing Body / Subject
5 CFR Part 930.301	Office of Personnel Management — information systems security awareness training
7 CFR Part 91	USDA Agricultural Marketing Service — commodity laboratory testing programs
7 CFR Part 331	USDA APHIS — possession, use, and transfer of select agents and toxins
9 CFR Part 2	USDA APHIS — animal welfare regulations
9 CFR Part 121	USDA APHIS — select agents and toxins (viruses, serums, organisms)
10 CFR Part 20	Nuclear Regulatory Commission — protection against radiation
10 CFR Part 30	Nuclear Regulatory Commission — licensing of byproduct material
21 CFR Parts 1, 7, 11, 58	FDA — general enforcement, electronic records/signatures, Good Laboratory Practice
21 CFR Parts 106, 110, 111, 112, 114, 117, 120, 123, 129	FDA — food manufacturing, dietary supplements, produce safety, HACCP, seafood, bottled water
21 CFR Parts 211, 212, 225, 226	FDA — cGMP for finished pharmaceuticals, PET drugs, medicated feeds/articles
21 CFR Part 312	FDA — Investigational New Drug Application
21 CFR Part 507	FDA — cGMP/HACCP for animal food
21 CFR Part 606	FDA — cGMP for blood and blood components
21 CFR Parts 810, 812, 820	FDA — medical device recall authority, investigational device exemptions, Quality System Regulation
29 CFR 1910.120, .134, .1030, .1096, .1200, .1450	OSHA — hazardous waste, respiratory protection, bloodborne pathogens, ionizing radiation, hazard communication, lab chemical exposure
40 CFR Part 3	EPA — cross-media electronic reporting
40 CFR Parts 60, 62, 63	EPA — air program emission standards
40 CFR Part 141	EPA — National Primary Drinking Water Regulations
40 CFR Parts 262, 370, 372	EPA — hazardous waste generator standards, community right-to-know reporting
40 CFR Parts 704, 717, 720	EPA — Toxic Substances Control Act reporting/recordkeeping
42 CFR Part 73	Public Health Service — select agents and toxins
42 CFR Part 93	Public Health Service — research misconduct policy
42 CFR Part 493	CMS — CLIA laboratory requirements
45 CFR Parts 160, 162, 164	HHS — HIPAA administrative, security, and privacy requirements
45 CFR Part 170	ONC — health IT certification criteria
61 FR 38806	USDA FSIS — Pathogen Reduction/HACCP Systems

Accreditation Bodies & Laboratory-Specific Programs

Source	Body
A2LA C211 (ISO/IEC 17025 + Veterinary Laboratory Accreditation)	American Association for Laboratory Accreditation
A2LA C223 (Forensic Examination Accreditation — Testing)	American Association for Laboratory Accreditation
AAFCO QA/QC Guidelines for Feed Laboratories	Association of American Feed Control Officials
AAVLD Requirements for an AVMDL	American Association of Veterinary Laboratory Diagnosticians
ABFT Accreditation Manual	American Board of Forensic Toxicology
ACMG Technical Standards for Clinical Genetics Laboratories	American College of Medical Genetics and Genomics
AIHA-LAP Policies	American Industrial Hygiene Association Laboratory Accreditation Programs
APHL LIS Project Management Guidebook	Association of Public Health Laboratories
ASCLD/LAB Supplemental Requirements for Forensic Science Testing Laboratories	American Society of Crime Laboratory Directors / Laboratory Accreditation Board (proxy for ANAB, whose current forensic requirements are not public)
CAP Laboratory Accreditation Manual	College of American Pathologists
NYSDOH CLEP Clinical Laboratory Standards of Practice	New York State Department of Health, Clinical Laboratory Evaluation Program
NYSDOH ELAP Medical Marijuana Microbiology Guidance	New York State Department of Health, Environmental Laboratory Approval Program
TNI EL-V1-2016	The NELAC Institute — environmental laboratory management and technical requirements
USDA Laboratory Approval Service (LAS/LAP) Policies	U.S. Department of Agriculture
USDA Pesticide Data Program (administrative procedures, sampling, data/instrumentation, sample processing)	U.S. Department of Agriculture
USDA Hemp Production Program Laboratory Testing Guidelines	U.S. Department of Agriculture

ASTM, ISO, and Clinical/Technical Standards

Standard	Title / Subject
ASTM E1188-11(2017)	Collection and Preservation of Information and Physical Items by a Technical Investigator
ASTM E1459-13(2018)	Physical Evidence Labeling and Related Documentation
ASTM E1492-11(2017)	Receiving, Documenting, Storing, and Retrieving Evidence in a Forensic Science Laboratory
ASTM E1578-18	Standard Guide for Laboratory Informatics — the core standard LIMSpec is rooted in
ISO 15189:2012	Medical laboratories — Requirements for quality and competence
ISO/IEC 17025:2017	General requirements for the competence of testing and calibration laboratories
ISO/TS 22002-1:2009, -4:2013, -6:2016	Prerequisite programmes on food safety — manufacturing, packaging, feed/animal food
CLSI AUTO15, AUTO16, QMS22	Clinical and Laboratory Standards Institute — automation/informatics and quality management
ISO/IEC/IEEE 29148:2018	Systems and software engineering — requirements engineering (underlies LIMSpec's own requirement-writing methodology)

Food Safety & Agricultural Standards

Source	Body
BRC Global Standard for Food Safety, Issue 8	BRC Global Standards
Codex Alimentarius CXC 1-1969, CXS 193-1995, CXS 234-1999	FAO/WHO Codex Alimentarius — hygiene, contaminants, methods of analysis
FDA HACCP Guidelines	U.S. Food and Drug Administration
GFSI Benchmarking Requirements v2020.1	Global Food Safety Initiative
IFS Food 7 / IFS PACsecure 2	International Featured Standards
Safe Food for Canadians Regulations SOR/2018-108	Government of Canada
SQF Food Safety Code, Ninth Edition (Food Manufacturing, Pet Food, Food Packaging)	FMI / SQF Institute
PFP Human and Animal Food Testing Laboratories Best Practices Manual	Partnership for Food Protection

Environmental, Pharmaceutical & International Guidance

Source	Body
EPA 815-R-05-004 (Drinking Water Lab Certification Manual)	U.S. Environmental Protection Agency
EPA ERLN Laboratory Requirements v1.6	EPA Environmental Response Laboratory Network
EPA Metadata Technical Specification	U.S. Environmental Protection Agency
EPA QA/G-5 (Quality Assurance Project Plans)	U.S. Environmental Protection Agency
EPA SEDD Specification & Data Element Dictionary v5.2	U.S. Environmental Protection Agency
FDA ORA DX Program	U.S. Food and Drug Administration
EMA Guidance on GMP/GDP	European Medicines Agency
E.U. Annex 11; Commission Directive 2003/94/EC; Reg. 852/2004; Reg. 2073/2005	European Union / European Commission
ICH GCP	International Council for Harmonisation — Good Clinical Practice
OECD GLP Principles	Organisation for Economic Co-operation and Development
WHO TRS #961 Annex 13; #986 Annex 2; #996 Annex 5	World Health Organization — laboratory information files, GMP principles, data/record management
DoD General Data Validation Guidelines	U.S. Department of Defense

Security, Public Health & Specialty Domain Standards

Source	Body
CJIS Security Policy	FBI Criminal Justice Information Services
NIST SP 800-53, Rev. 5	National Institute of Standards and Technology
CDC Biosafety in Microbiological and Biomedical Laboratories (BMBL)	U.S. Centers for Disease Control and Prevention
CDC PHIN Messaging System	U.S. Centers for Disease Control and Prevention
ONC United States Core Data for Interoperability (USCDI)	Office of the National Coordinator for Health IT
OSHA 1910.1020, 1910.1200, 1910.1450	Occupational Safety and Health Administration
WADA International Standard for Laboratories (ISL)	World Anti-Doping Agency
WADA International Standard for the Protection of Privacy and Personal Information (ISPPPI)	World Anti-Doping Agency
ICAR 15 Data Exchange	International Committee for Animal Recording
VICH GL53 (Electronic Exchange of Documents)	Veterinary International Conference on Harmonization
NAHLN HL7 Messaging Quick User Guide; NAHLN IT System	National Animal Health Laboratory Network
VeNom Coding Group terminology	Veterinary Nomenclature (VeNom Coding Group)
VTSL terminology	Veterinary Terminology Services Laboratory, Virginia-Maryland College of Veterinary Medicine

Attribution

This source list is reproduced from LIMSWiki's own "LII:LIMSpec/Introduction and methodology" page, which documents that its fourth revision (December 2022) draws on more than 130 resources. LIMSWiki notes this remains a work in progress, with additional sources incorporated as public and private comment identifies gaps. This document defers entirely to LIMSWiki's own account of its sourcing rather than independently verifying each citation.

Appendix D

LIMSpec Version History

This appendix records every versioned revision to the LIMSpec master template since the current major edition (2026R1) was established, per the versioning scheme described in the Preface. Each entry reflects a confirmed version bump, not every individual edit made along the way — some sessions accumulate several changes before a version number is assigned. The 2026R1 baseline itself introduced the major structural upgrade from a flat checklist to the current per-function rationale text, Vendor Profile table, and live scoring architecture.

When Does the Version Increment to a New Major Edition?

Every revision listed below is a decimal increment — 2026R1.1, 2026R1.2, and so on, with no cap — because each one extended or improved the existing document without changing what the document fundamentally is. The dividing line for moving to a new major edition (2026R2, or 2027R1 at a new calendar year) is whether a change alters what the document is, rather than just what it does. A useful test: could a vendor profile filled out under the current major edition still open correctly, with nothing lost, under the proposed new version? If yes, it is decimal territory. If no, it warrants a major-edition bump.

Concretely, a major-edition bump is warranted when:

The Feature Matrix itself changes — functions or categories are added, removed, or renumbered, since the 469-functions-across-28-categories structure is the fixed spine every score, table, and export depends on.
A new calendar year or a planned major edition arrives, per the versioning scheme's own stated fallback.
The underlying data format changes in a way that makes older filled-in profiles genuinely incompatible without a migration step, as opposed to remaining directly openable in the new version.

By contrast, additions as substantial as Chapter 29 (Vendor Added Categories) or replacing the rich-text editing engine both represented real engineering effort and real behavior change, yet stayed decimal increments — because a profile filled out on an earlier decimal version still opens correctly on a later one, with nothing lost. Reversibility and continuity of existing vendor data, not the size or effort of a change, is what determines whether a revision is decimal or major.

Version	Summary of Changes
2026R1.1	Removed the "No Vendor Sponsorship or Review" subsection from Independence & Authorship.
2026R1.2	Renamed the Feature Matrix lightbox's "Vendor Approach" tab to "Vendor Information"; added an initial "Download Word Copy" button.
2026R1.3	Replaced the Word export with a genuine client-side-generated .docx (real OOXML, hand-built ZIP and CRC32, no external libraries), including real Word heading styles, bookmarks, and a working, pre-populated table of contents that renders correctly when opened in both Microsoft Word and Google Docs.
2026R1.4	Restructured the per-category Word export from a single wide table into 469 individual stacked tables, one per function, with Function / Functional Requirement / Vendor-Product Info / Status rows; Sources dropped from the export.
2026R1.5	Changed each per-function Word table from a two-column (label \| value) layout to a single column, with each row's label and value combined on one line.
2026R1.6	Fixed a bug where literal HTML entities in the source data (for example, "'" instead of an apostrophe) displayed as visible text in the Word export; set the Function row to 20pt bold in the Word export.
2026R1.7	Added keep-together page-break behavior to each per-function Word table, so it stays on one page whenever it fits and only splits if it is genuinely longer than a full page.
2026R1.8	Replaced the cover banner's static "Document Type" field with a live "Vendor LIMSpec Score" counter; simplified the scoring model from four statuses to two (Documented / Not Supported only, removing Partially Documented and Not Publicly Documented) across the scoring rubric, the Feature Matrix, and the Word export; fixed a pre-existing bug in the Word export's version-number lookup.
2026R1.9	Added "The LIMSpec Is a LabLynx Creation" subsection to Independence & Authorship, disclosing LabLynx, Inc.'s role in creating LIMSpec and LiMSwiki.org as a joint community effort, and affirming LabLynx's own vendor profile is held to the same evidentiary standard as every other vendor.
2026R1.10	Renamed "Company Profile" to "Vendor Profile" everywhere user-visible; added a dynamic banner title that appends the vendor's Legal Name onto "LIMSpec" once entered and saved.
2026R1.11	Extended the dynamic banner title to also update the dark navy cover-page banner, so both the sidebar and cover page stay in sync.
2026R1.12	Changed the cover banner's label text to bright white for readability; added an entirely new Chapter 29, "Vendor Added Categories," letting a vendor define its own custom categories and function points (autonumbered 29.1, 29.2, 29.3…) that count toward the overall Vendor LIMSpec Score the same way standard functions do, with the Category Summary Table and Word export updated to include them automatically.
2026R1.13	Added a roughly 50-word description field to vendor-added categories; renamed "Rename Category" to "Edit Category" to reflect that it now edits both the name and description together.
2026R1.14	Made the "Download Updated Copy" (HTML) button use the same vendor-based root filename convention as the Word export, so both downloaded files share a matching name.
2026R1.15	Fixed a bug where both download buttons silently did nothing when the file was opened from the local filesystem (a file:// URL) — a Chrome/Chromium security restriction on blob-URL downloads from local pages, not a logic error — by falling back to a data URI in that specific case.
2026R1.16	Fixed a bug where category score lines (for example, "Vendor score: 9 / 21") only computed when a function was edited interactively through the modal, so a file opened with scoring data already present (such as a completed vendor profile) showed no score line until something was edited; added an initialization-time pass that recomputes every category's score display on load, regardless of how the data got there. Added this appendix, Appendix D, recording the version history from 2026R1.1 onward; keeping it current is now standing practice for every future version bump.
2026R1.17	Replaced the raw contenteditable/execCommand rich-text editing (Vendor Information field, Vendor Profile fields, Chapter 29 vendor-added functions) with Quill, a self-hosted, fully offline-embedded WYSIWYG editor (no CDN dependency, no API key) — same formatting capabilities (bold, italic, lists, links, and image upload where previously available) with a more polished editing experience. As part of this change, the Vendor Profile table moved from bulk "edit all 15 fields at once" to one-field-at-a-time modal editing, matching how the Vendor Information and Chapter 29 editors already worked, for a consistent editing pattern throughout the document. Added a new "When Does the Version Increment to a New Major Edition?" subsection to this appendix, explaining the R1-to-R2 threshold.
2026R1.18	Added drag-to-resize and click-to-align (left/center/right, with text wrap) for images within Quill, via the self-hosted quill-blot-formatter2 module (no CDN dependency) registered across all three rich-text editing surfaces. Clicking an image now shows four corner resize handles plus a small alignment/link/alt-text toolbar. Added supporting CSS so a resized or aligned image continues to display correctly with its float and margin outside the live editor as well (e.g. the read-only Vendor Information panel), not just while editing. No changes were needed to the Word export's existing image-handling logic, since a resized/aligned image is still a plain <img> tag (optionally wrapped in an alignment <span>), which the export's existing recursive HTML parser already finds correctly regardless of wrapping.
2026R1.19	Moved "Category Summary Table" out of the Reference section's own numbering (previously "30.") and renumbered it as Appendix B, sitting between Appendix A and the document's former Appendix C; deleted the former Appendix B ("Vendor Cited Sources"), which had defined the sourcing-requirement methodology (Documented only when directly confirmed in a vendor's own materials, everything else Not Supported) for completed vendor profiles. Fixed a resulting dangling cross-reference in Independence & Authorship that had cited "(Appendix B)" for vendor-sourcing traceability; the underlying claim still holds via each function's own Sources field, so the sentence was reworded rather than left pointing at deleted content. Appendix C and Appendix D keep their existing letters and content unchanged.
2026R1.20	Simplified the sidebar TOC label for Chapter 1 from "Chapter 1: Vendor Profile" to just "Vendor Profile" (the in-page chapter header and Word export heading still say "Chapter 1"). Added a new "Laboratory Profile" section to the Introduction group, positioned before Vendor Profile — a 15-field editable table (organization identity, contact information, and general software needs: staff/user count, sample volume, current systems, deployment preference, regulatory requirements, functional priorities, integration needs, timeline/budget) for the laboratory or organization evaluating vendors using this document, using the same per-row Quill-editing pattern as Vendor Profile. Included in the Word export, positioned immediately before Chapter 1, but only when at least one field has been filled in — left blank, it is omitted entirely rather than exporting a section of placeholder rows.
2026R1.21	Added a new chapter, "The LIMSpec and How to Use It," as the first item in the Introduction group, ahead of Open Access License — a practical walkthrough covering what the LIMSpec is (with benefits framed for laboratories, vendors, and both together), how a laboratory reads a completed profile and fills in its own Laboratory Profile, and how a vendor fills in its Vendor Profile, answers functions with proper evidentiary discipline, and uses Chapter 29 for genuine differentiation. Illustrated with 13 real screenshots of the live application itself (captured via a headless Chromium instance already available in the working environment, not hand-drawn illustrations), covering every editing surface: the function detail modal in both tabs, the Quill-based edit view, Chapter 29's add-category and add-function dialogs, the Vendor Profile table and field-edit modal, the dynamically-updated title banner with live score, and the download buttons. Adds roughly 3.5MB to the file (screenshots only); the new chapter is correctly excluded from the Word export, which continues to cover only Laboratory Profile (if filled in), Chapter 1, and the Feature Matrix chapters.
2026R1.22	Added a new "Upgrade LIMSpec" button to the sidebar. Clicking it opens a modal showing the current file's version alongside the latest version, automatically fetched from the canonical published template at media.limswiki.org/books/51; an "Upgrade" button then migrates every function status/write-up/sources, Vendor Profile field, and Laboratory Profile field into a fresh copy of that latest template by matching on function name or field label, carries Chapter 29 vendor-added categories over unchanged (they are not part of the fixed matrix), and downloads the result as a new file, leaving the current file untouched. If the automatic fetch fails for any reason (a cross-origin restriction on the hosting server, or a network issue), the same modal falls back to a manual file picker with a direct link to the source, using identical migration logic either way. Anything that cannot be matched (for example, a renamed function) is reported in an on-screen migration summary rather than silently dropped. Fixed a bug found during testing where the migration code's own generated string contained a literal </script> sequence, which would have prematurely closed the surrounding script tag in any browser.
2026R1.23	Reworked the Upgrade feature (renamed "Upgrade LIMSpec" to "Upgrade My LIMSpec") to reverse the migration direction and remove the network fetch entirely: the template currently open is now treated as the upgrade target on the assumption the user has already navigated to the latest published version at media.limswiki.org/books/51, and the modal simply asks for an older, filled-out LIMSpec file via a local file picker as the migration source — sidestepping the cross-origin question from 2026R1.22 altogether, since nothing is fetched from anywhere. Migrating now also updates this page's own live data immediately (score banner, Vendor Profile table, title banner all refresh in place), not just the downloaded copy. Moved the button out of the sidebar and into the dark navy cover banner, positioned immediately to the right of the Version field, styled with the site's existing orange accent color for visibility against that background.
2026R1.24	Widened the Feature Matrix function detail lightbox by 50% (max-width 760px → 1140px). The lightbox's internal content (icon, tabs, text panel) keeps its own natural width rather than stretching to fill the added space.
2026R1.25	Fixed a bug found immediately after 2026R1.24: the lightbox's outer box had genuinely widened to 1140px, but a global `p { max-width: 860px; }` rule (written for body prose elsewhere in the document) was also silently capping the paragraph text inside the modal, so the visible content barely changed and left a large empty gap on the right. Added a `.mf-panel p { max-width: none; }` override so the text now fills the full widened container. Verified at both a typical laptop width (1280px, text now spans the full box with no dead space) and a narrower window (900px, the modal still shrinks responsively rather than overflowing).
2026R1.26	Fixed a second, more subtle download bug: the file:// fallback for both download buttons used `FileReader.readAsDataURL()`, which is asynchronous, meaning the actual download-triggering click happened inside an async callback after the original click had already completed - a gap in which Chrome can stop treating the action as user-initiated and silently block it with no visible feedback. Rewrote the fallback to be fully synchronous (built via `btoa` directly, no FileReader at all), so the click and the download now happen in the same call stack every time. Reworked "Upgrade My LIMSpec" substantially, introducing an explicit distinction between the blank LIMSpec Master Template and a filled-out LIMSpec Vendor Profile built from it: the title now reads "LIMSpec - Master Template" until a Vendor / Product name is filled in, at which point it switches to "LIMSpec - {name}" as before; the Upgrade button itself is now only shown while the page is the blank Master Template, disappearing once a vendor name is present, since only the Master Template is a valid upgrade target. The uploaded file is now validated immediately upon selection (checked for a version number and the expected Feature Matrix / Vendor Profile data blocks), with a specific inline error shown right away rather than only failing later. Migration no longer touches this page's own live data at all - it works entirely on cloned copies, so the open Master Template is never altered, confirmed by snapshotting its data before and after a migration and verifying an exact match. The modal now has two views: a setup view (file picker) and, after clicking Upgrade, a result view showing the migration summary plus a real, pre-built "Download Upgraded File" link the user clicks themselves, rather than an automatically triggered download - both because it is less ambiguous about what just happened, and because a genuine physical click on a real link sidesteps the async-download-blocking risk entirely. Verified with a real physical mouse click (not a simulated one) in actual Chrome.
2026R1.27	Added a new "Keeping Your LIMSpec Profile Current" section to the end of "The LIMSpec and How to Use It" chapter, covering the Upgrade My LIMSpec feature: why it exists (the template evolves; older profiles do not auto-update), the Master Template vs. Vendor Profile distinction and why the button only appears on the blank template, the actual setup-then-upgrade flow, and what happens when a function cannot be matched during migration (reported plainly, not silently dropped). Illustrated with two real screenshots of the live application (the cover banner showing the button only on the blank Master Template, and the Upgrade modal’s setup view).
2026R1.28	Added a light-gray banner above the dark-navy cover, containing the LiMSwiki logo embedded as inline SVG (fully self-contained, no external image dependency). Removed the cover banner’s "LiMSwiki.org · Version X" eyebrow line entirely and reduced the cover’s top padding (80px → 40px) to close the resulting excess space above the title — the version string now appears in 5 places rather than 6, since this eyebrow was previously one of them. Moved the matrix search box out of the sidebar and into the new gray banner, positioned opposite the logo; the same element IDs were kept throughout, so no JavaScript changes were needed and the existing search, results dropdown, and Ctrl/Cmd+K shortcut all continued working immediately in the new location. Made the search box’s orange border permanent rather than focus-only, and corrected its vertical alignment to be centered with the logo — measured a real 10.8px offset first, then found that the obvious fix (`margin-top`) only corrected half of it because it also grew the flex container and re-centered the logo along with it; switched to a `position: relative; top` offset instead, which does not affect layout sizing, confirmed down to a 0.2px difference. All changes verified visually via real Chrome screenshots, including measuring exact element positions, before being finalized.
2026R1.29	Added a "find in page" widget to the matrix search: typing a query now highlights every occurrence across the visible page (category text and function names, the same content the existing results dropdown already searches) and shows a small counter with Previous/Next buttons to step through matches one at a time, similar to a browser’s built-in Find bar. The widget and the pre-existing results dropdown are mutually exclusive (the widget takes over once there are highlight matches) after an initial version briefly rendered both stacked on top of each other in the same space, caught via a real screenshot rather than the automated tests alone. Closing the widget fully un-wraps every highlight and restores the original text nodes, verified byte-for-byte identical before and after. Fixed a second issue found immediately after: the widget was originally positioned relative to the search box in the gray banner, which is not fixed on scroll, so navigating to a match anywhere past the first screen left the widget over 20,000px off-screen and completely invisible — measured directly rather than assumed. Switched it to `position: fixed`, pinned to the top-right of the viewport, confirmed to remain visible and correctly positioned at every step while navigating through matches far down the document.
2026R1.30	Removed the "LiMSwiki Laboratory Informatics Vendor Profile" line from the dark-navy cover banner (left unchanged everywhere else it appears - sidebar, page title, meta description, license text, Preface). Replaced the cover subtitle text with a description centered on LIMSpec’s actual purpose — a shared, standards-referenced vocabulary letting a laboratory evaluate any vendor on the facts and a vendor describe its own product completely and accurately — sized to within 20 characters of the original (320 vs. 340) so the banner layout is unaffected, confirmed visually.
2026R1.31	Locked the gray logo banner in place: it is now `position: fixed` at the top of the viewport (spanning from the sidebar’s right edge to the viewport edge) so it, and the search box within it, remain visible while scrolling. Added compensating top padding to the main content area matching the banner’s exact measured height so nothing hides underneath it on load. Made the logo a clickable link that smooth-scrolls back to the top of the page. Simplified the find-in-page widget back to being anchored under the search box (`position: absolute` rather than `position: fixed`), since the search box is now always visible and no longer needs the viewport-pinned workaround from 2026R1.29. Replaced the LiMSwiki logo in the gray banner with a new supplied LIMSpec logo (flask/checkmark mark, wordmark, and "Standardized Requirements for Laboratory Software" tagline), embedded as base64 PNG; sized taller (58px, up from 42px) than the previous logo to keep the tagline legible, verified at 2x resolution. Caught and fixed a real bug during this change: the taller logo grew the fixed banner’s height from ~88.6px to 95px, but the compensating top-padding added earlier in this version was still hardcoded to the old value, leaving a 6px overlap; corrected to match exactly, confirmed by re-measuring both values directly rather than assuming. In the sidebar, replaced "LiMSwiki.org" with "LIMSpec.com" linked to https://limspec.com (opens in a new tab), and removed the "LiMSwiki Laboratory Informatics Vendor Profile · 469 Functions · 28 Categories" description line beneath the title entirely, along with its now-unused CSS rule.
2026R1.32	Increased the logo size in the gray banner (68px, up from 58px), remeasuring the banner’s new height (105px, up from 95px) and updating the main content area’s compensating top padding to match exactly, confirmed with no gap or overlap; the logo/search box vertical alignment was also re-verified and needed no adjustment. Renamed the sidebar navigation section "The Feature Matrix" to "Vendor/Product LIMSpec" (the group of 28 category links). Checked for other references to this section specifically and found none needing updates — "Feature Matrix" elsewhere in the document (methodology, appendices, license text) is the established technical term for the 469-function/28-category structure itself, not a reference to this sidebar grouping, and was left unchanged.
2026R1.33	Added a new "Profiles" section to the sidebar navigation, positioned between the Introduction group and the Vendor/Product LIMSpec group. Moved the "Laboratory Profile" and "Vendor Profile" links out of their previous locations (Introduction and Vendor/Product LIMSpec respectively) into this new grouping. No change to the underlying chapter content or physical placement in the document body was required, since both chapters already sat consecutively immediately before "1. Sample & Specimen Management."
2026R1.34	Added a new "Vendor/Product LIMSpec Score" subsection to the Vendor Profile chapter, positioned between the chapter intro and the editable Vendor Profile table. Explains how the score is computed (count of functions marked Documented, summed across all 28 Feature Matrix categories plus any Chapter 29 Vendor Added Categories, with every function weighted equally) and displays the live score in bold. Wired into the existing `updateVendorScore()` function so this new display updates in lockstep with the pre-existing cover-banner score whenever a function's status changes, verified via a scripted UI test that marked a function Documented and confirmed both displays updated to the same value.
2026R1.35	Replaced the plain-text Vendor/Product LIMSpec Score subsection with a live-updating visual badge (vendor icon, vendor/product name, "LIMSpec Score: {value}", and version), embedding the actual LIMSpec flask-and-checkmark icon rather than the generic in-document sprite. The same badge now also appears on the dark cover banner, taking the place of the previous separate "Vendor LIMSpec Score" and "Version" text fields; both badge instances read from and update via the existing `vendorScoreValue`, `coverVersionValue`, and `updateBrandTitle()`/`updateVendorScore()` logic, so no new update wiring was needed and no 6th version-string location was introduced. Removed the Laboratory Profile chapter entirely, including its sidebar nav link, editable table, "Filling In the Laboratory Profile" tutorial subsection and screenshot, and all associated JavaScript (render/edit/save functions, its JSON data block, and every reference in the version-upgrade migration logic and the Word-export logic); the Profiles sidebar group now contains only Vendor Profile. Verified via a full scripted pass confirming zero console errors, correct badge behavior on both the blank Master Template and a filled-in profile, and no orphaned Laboratory Profile references anywhere in the page.
2026R1.36	Moved the "Vendor Profile" sidebar link out of the "Profiles" group (now empty and removed) into the "Vendor/Product LIMSpec" group, positioned before "1. Sample & Specimen Management" — matching the chapter's existing physical position in the document body, which was already immediately before Category 1 and did not need to move. Renamed the "Download Updated Copy" sidebar button to "Download Vendor LIMSpec" (HTML export); the Word export button and its "Download Word Copy" label are unchanged. Both changes verified with a scripted UI pass showing zero console errors and the correct nav order and button label.
2026R1.37	Removed the large circular icon illustration from the top of the function detail modal (below the header, above the Functional Requirement / Vendor Information tabs), reclaiming that vertical space for the description and edit content below; the small icon next to the function title in the modal header is unchanged and still updates per-category as before. Added a live score suffix to the "Vendor Profile" sidebar link, so it now reads "Vendor Profile - {score}" (or "Vendor Profile - No Score" when blank), wired into the existing `updateVendorScore()` function alongside the cover-banner and chapter-badge score displays so it updates in lockstep with no separate event handling required. Verified via a scripted UI pass confirming zero console errors, correct modal layout with the illustration removed, and the nav label updating correctly after marking a function Documented.
2026R1.38	Standardized the downloaded-file naming convention across all three export paths to `limspec-{version}-{vendor}` (lowercase prefix, current document version, then the sanitized Vendor/Product name or "vendor-profile" when blank): the "Download Vendor LIMSpec" HTML button, the "Download Word Copy" button, and the "Upgrade My LIMSpec" migration output (which now appends "-upgraded" instead of the previous "-upgraded-to-{version}" suffix, since the version is already present in the new prefix). Previously each of the three used a different, inconsistent "LiMSpec-{vendor}" pattern with no version in the filename. Verified via a scripted pass exercising all three download paths with both a blank and a filled-in Vendor/Product name, confirming the expected filenames (e.g. `limspec-2026R1.38-vendor-profile.html`, `limspec-2026R1.38-Acme_LabSuite.docx`) and zero console errors.
2026R1.39	Refreshed all 13 screenshots embedded in "The LIMSpec and How to Use It" tutorial chapter, which had gone stale across several versions of visual redesign (old sidebar branding, no fixed logo banner, the pre-badge cover layout, the now-removed modal illustration, the old "Download Updated Copy" button label, and the old flat Vendor/Product LIMSpec Score text). Recaptured each via a scripted Puppeteer pass exercising every subject fresh against the current template: page overview, a Feature Matrix category list, both tabs of the function detail modal, the edit view, the Vendor Profile chapter and cover banner with a sample vendor name and live score, Chapter 29's empty state plus its Add Category and Add Function dialogs and populated result, the sidebar download buttons with an unsaved-edits indicator, and the Upgrade My LIMSpec button and modal on a blank Master Template. Alt text and captions were left untouched; only the image bytes were swapped, each verified to match its existing caption. Corrected one line of prose describing the Upgrade button's position ("next to the version number" → "next to the LIMSpec Score badge") to match the current cover-banner layout. Along the way, found and fixed a genuine Puppeteer bug in the capture tooling itself: `page.screenshot({clip})` resolves clip coordinates against a synthetic full-page render rather than the current scrolled viewport, silently breaking capture of any `position:fixed` overlay (such as these modals) once the page is scrolled — switched to plain viewport screenshots and `elementHandle.screenshot()` instead, which capture correctly regardless of scroll position. Verified via a final scripted pass confirming all 13 images load, zero console errors, and the edit/score workflow still functions correctly.
2026R1.40	Expanded the WYSIWYG toolbar across all three rich-text editors (function Vendor Information, Vendor Profile fields, and Chapter 29 vendor-added functions) to expose Quill formatting already bundled in the page but previously hidden behind a minimal bold/italic/list/link toolbar: a font-size picker (Small/Normal/Large/Huge), underline, strikethrough, text color and highlight/background color, blockquote, text alignment, video embedding (paste a YouTube/Vimeo URL), and a clear-formatting button. The image button remains excluded from the Chapter 29 function editor only, preserving its original simpler design. Extended the from-scratch Word (.docx) export generator to carry underline, strikethrough, and font size through into the exported file; text/background color and embedded video can't translate to a static document, so they degrade to plain text with an italic placeholder note, matching the existing pattern already used for images. Verified via a scripted pass exercising every new toolbar control (including the size picker, underline, color picker, and inserting a video via the built-in URL prompt) in both toolbar variants, confirming the no-image variant still correctly excludes only the image button, and running a full Word export against the resulting content with zero console errors.
2026R1.41	Added the ability to add and delete vendor-defined functions directly under each of the 28 standard Feature Matrix categories (distinct from Chapter 29, which creates an entirely new category) — a "+ Add Function" button on every category page opens the same evidentiary Function / Functional Requirement / Vendor Information / Status structure used throughout, and any function added this way can be freely edited or deleted since it is entirely vendor-authored. The categories themselves remain permanently fixed and cannot be removed. Added a non-destructive Hide/Unhide toggle for the 469 standard functions in place of deletion: a hidden function stays fully intact in the data (and still counts toward the LIMSpec Score if marked Documented), it only disappears from its category's visible list, with a small "N hidden \u2014 show hidden" link per category to reveal and manage them; this avoids the risk a true delete would carry of the function reappearing on a future Upgrade migration. Every count in the document now reflects both additions: the overall LIMSpec Score badge (cover banner, Vendor Profile chapter, sidebar nav), the Function Count Summary appendix table (each standard category row now shows "+N added" alongside its fixed count, with the grand total including everything), and each category's own live intro/score line. Generalized the shared Chapter 29 add/edit/delete modal to serve both use cases from one code path rather than duplicating it. Extended the Word export to include per-category vendor-added functions labeled "(Vendor Added)", and extended the Upgrade migration to carry both the hidden flag and per-category vendor-added functions through intact, verified by decoding an actual migrated file's data. Found and fixed a regression introduced earlier in this same change: inserting the new per-category "hidden functions" placeholder paragraph had silently broken the Word export's lookup for each category's descriptive paragraph (which relied on DOM sibling position) — caught and corrected before release. Verified via a comprehensive scripted pass: add/edit/delete of category-added functions with live score and summary-table checks at each step, hide/unhide with score-unchanged verification and the show/hide toggle link, a full regression pass confirming every original Chapter 29 flow still works identically after the shared-modal refactor, a Word export with zero console errors, and an end-to-end Upgrade migration test confirming hidden flags and vendor-added functions both survive intact.
2026R1.42	Added documentation for the 2026R1.41 feature to "The LIMSpec and How to Use It" tutorial chapter, which had been overlooked when that version shipped. Two new subsections were added after "Adding What the Standard Matrix Doesn't Cover": "Adding a Vendor-Specific Function Within a Standard Category," explaining the per-category "+ Add Function" button, how it differs from a Chapter 29 category, and that only the added functions (not the categories themselves) can be deleted; and "Hiding a Standard Function," explaining why hiding replaces deletion for the fixed 469 functions, that a hidden function stays fully intact in the data and still counts toward the LIMSpec Score if marked Documented, and both ways to unhide it (the toggle in the function's own modal, and each category's "Show hidden" link). Verified via a scripted pass confirming both new sections render correctly under the How to Use It chapter with zero console errors.
2026R1.43	The LIMSpec and How to Use It chapter had grown long and hard to navigate, so it was broken into four subchapters in the sidebar TOC \u2014 What Is the LIMSpec?, How a Lab Uses This Document, How a Vendor Uses This Document, and Keeping Your Profile Current \u2014 each linked to its existing section heading within the chapter, indented beneath the parent chapter link with a dash prefix. Added a chevron toggle button next to any chapter that has subchapters, letting the sidebar collapse or expand that chapter's subchapter list independently of navigating to it; clicking the chapter link itself still navigates normally, and clicking the chevron neither navigates nor scrolls the page. The toggle mechanism is generic (matches a chevron's data-toggle value against a subchapter-group's id), so any future chapter that gains subchapters can reuse the same pattern without new script. Verified via a scripted pass confirming all four subchapter links scroll to the correct heading, the chevron correctly toggles ARIA-expanded state and visibility on repeated clicks without affecting scroll position, and the parent chapter link's own navigation is unaffected, with zero console errors throughout.
2026R1.44	Fixed a bug where applying italic formatting in the Vendor Information Quill editor rendered the text bold instead of italic. The cause was a CSS rule scoped to the shared display-panel class used by both the Functional Requirement and Vendor Information panels, which overrode every <em> tag to render bold and non-italic \u2014 a leftover rule that no standard function's data actually relied on. Since Quill wraps italicized text in <em> tags, and the Vendor Information editor lives inside that same panel both while editing and when displaying saved content, every italic a vendor applied was silently being turned bold. Removed the override; italic now renders correctly as italic, normal-weight text. Verified via a scripted pass applying italic through the editor's keyboard shortcut and confirming correct computed style (italic, normal weight) both while editing and in the saved read-only view, confirming the Chapter 29 editor was unaffected (it was never in the affected panel) and continues to work correctly, and confirming an unrelated, intentionally-styled <em> rule elsewhere in the cover page was untouched by the fix.
2026R1.45	Replaced the two-option scoring system (Documented / Not Supported, 1/0 points) with a four-option system across the entire document: Off-the-Shelf (1 point), Configurable (1 point), Extensible (0.5 point), and Not Supported (0 points). Updated the VAC field-status dropdown, `STATUS_META` and `STATUS_POINTS` (and their Word-export equivalents `WORD_STATUS_META` / `WORD_STATUS_POINTS`), added a shared `formatScore()` helper so fractional totals display as, e.g., "12.5" rather than "12.5000000001" or an unnecessary decimal on whole numbers, and added new CSS pill/item-status classes (`st-o`, `st-c`, `st-e`) alongside the existing `st-n`. Every score computation that previously summed a binary Documented count now sums weighted points instead: `updateVendorScore()`, `recomputeCategoryScore()`, `vacDocumentedCount()`, `categoryAddedDocumentedCount()`, `renderCategoryAdded()`, `renderVendorAdded()`, and all three Word-export score blocks (standard category, category-added functions, and Chapter 29 vendor-added categories) now report a four-way breakdown ("N Off-the-Shelf, N Configurable, N Extensible, N Not Supported") alongside the weighted point total. Updated the Scoring Rubric chapter with the new four-row table and definitions, the "How to Use It" chapter's discussion of scoring discipline and the hide/unhide interaction with scoring, the Vendor Profile chapter's score explanation, and the Chapter 29 intro text (both the static HTML and its two JavaScript-driven variants) to describe weighted points rather than a binary count. The `sourcesHtml` absence-of-documentation check (keyed on `st === 'n'`) required no change since Not Supported is still represented by the same `n` key. Appendix D historical rows were not modified. Verified via a scripted pass confirming the four-option dropdown renders correctly, weighted scores compute and display correctly (including fractional Extensible-only totals), and the Word export reflects the same four-way breakdown with zero console errors.
2026R1.46	Fixed a bug where a function's status badge (the small ✓/⚙/½/✕ symbol shown next to its icon in the category sidebar list) would not appear on page load unless the status had been set by interacting with the UI. The badge was only ever written by `updateLiBadge()`, called reactively from the status-change handler; the page's own initial-load routine looped over `mfData` to reconcile the hidden-function flag into the DOM (`updateLiVisibility()`) but never called `updateLiBadge()` for already-scored functions, so a profile whose `mfData` was populated by directly editing the underlying JSON (rather than through the modal UI) loaded with every sidebar badge missing even though the scores themselves were correct and the category totals computed correctly. Fixed by extending the existing load-time `mfData.forEach` loop with a single conditional call, `if (item.st) { updateLiBadge(item); }`, alongside the existing hidden-flag reconciliation — `updateLiBadge()` already safely no-ops into an update-in-place if a badge element happens to already exist, so this is additive and cannot double-insert a badge. Verified via `node --check` against all nine inline script blocks with zero syntax errors, and a scripted Playwright pass loading both a blank Master Template (0 badges rendered, as expected with nothing scored) and a fully-scored 469-function vendor profile (all 469 badges present immediately on load with no interaction, exact counts matching the underlying data, zero console or page errors).
2026R1.47	Added a Vendor Scoring Summary dashboard — four cards (Off-the-Shelf, Configurable, Extensible, Not Supported) showing the live count of functions currently at each rubric status — to the Vendor Profile chapter, positioned directly beneath the existing Vendor/Product LIMSpec Score badge. Counts are tallied across every source that already contributes to the overall LIMSpec Score: all 469 standard Feature Matrix functions (including hidden ones, matching the score's own long-standing behavior of still counting a hidden function if it has a status), any per-category vendor-added functions, and any Chapter 29 Vendor Added Categories. Implemented as a single new `updateScoreDashboard()` function called from inside the existing `updateVendorScore()` — the same pattern used since 2026R1.35 for the cover-banner and chapter badges — so the new dashboard required no new event wiring and updates automatically alongside the score itself on initial load, every function edit, every vendor-added function/category add-edit-delete, and after an Upgrade migration. Added matching CSS (a four-column grid, collapsing to two columns under 600px, using the same st-o/st-c/st-e/st-n accent colors already established for the sidebar status badges). Verified via a scripted Playwright pass: a blank Master Template shows all four counts at zero; the LabLynx vendor profile built earlier this session shows the dashboard matching its known breakdown (50/147/81/191) immediately on load with no interaction; and, most importantly, editing a single function's status live through the actual modal UI (Configurable → Not Supported) updated the dashboard (147→146, 191→192) and the LIMSpec Score (237.5→236.5) automatically and correctly with zero console errors, confirming the dashboard genuinely tracks live edits rather than only reflecting whatever was true at page load.
2026R1.48	Rebuilt the "Download Word Copy" export to be visually consistent with LIMSpec's own branding, replacing what had been a plain, unstyled document. Added a proper cover page: the embedded LIMSpec flask-and-checkmark logo, an orange "LIMSPEC VENDOR PROFILE" (or "LIMSPEC MASTER TEMPLATE" when blank) kicker label, the existing title, and a new bordered metadata block (Vendor/Product, Version, Generated date, and the live LIMSpec Score, computed once up front from the same `WORD_STATUS_POINTS` weights used elsewhere) framed by thin top/bottom rules matching the vendor-supplied reference design. Added real header and footer parts (previously absent entirely): a right-aligned "LIMSPEC — {VENDOR}" header and a centered "LIMSpec.com · Version {X} · Page {N}" footer using a genuine Word `PAGE` field, present on every page including the cover. Added an orange bottom-border rule to the Heading1 style (matching the reference document's accent treatment) and a new, currently-unused Heading2 style for future finer structure. Restyled every per-function table's "Function" row with a solid navy fill and white bold text, echoing the reference document's navy-header data tables. Colors were sourced from LIMSpec's own established brand (navy #1F3864, orange #E8622A) rather than copied directly from the reference document's LabLynx-specific shades, since the two are related but distinct brands. Implementation required extending `runXml` with color support, `tcXml` with a navy-shading option, and `labeledRowXml` to pass through cell-level styling options — all backward-compatible with existing call sites. Found and fixed two genuine OOXML schema defects in the process: the new cover metadata table and, more significantly, the long-standing general-purpose `tblXml` function used by every data table in the document were both missing the schema-required `tblGrid` element (previously silently auto-repaired by Word on open, only surfaced now under strict validation) — `tblXml` was corrected to compute a matching grid dynamically from actual column count rather than assuming a fixed shape, since it is shared by both the single-column function tables and the two-column Vendor Profile table. Also added a missing required `w:gutter` attribute to the page margin definition. Verified via `node --check` against all nine inline script blocks, an actual "Download Word Copy" click captured through a headless browser (not just code review), full OOXML schema validation (all checks passed after the two fixes above), and a rendered visual review of the resulting document — cover page, table of contents, function tables, and header/footer — across a 247-page fully-scored vendor profile and, separately, confirmation that the blank Master Template's export degrades correctly ("LIMSPEC MASTER TEMPLATE" kicker, "Not yet documented," "No Score," generic header) with zero console errors throughout.
2026R1.49	Added a 16th Vendor Profile field, "Link to Vendor LIMSpec," positioned immediately after "Support model," intended for a URL pointing to where this specific vendor's completed profile is published. Unlike every other Vendor Profile field, it does not use the Quill rich-text editor — the field-edit modal now checks a new `type: 'link'` property on the field's data and, when present, swaps the Quill container for a plain `<input type="url">` instead, since a URL has no need for rich-text formatting. The value is stored as a plain URL string (not HTML) and rendered as a real, clickable anchor tag (`target="_blank" rel="noopener"`) in the on-page table; the Word export renders it as a genuine OOXML hyperlink relationship via the existing `hyperlinkXml()` helper rather than passing it through the HTML-parsing path used by every other field. Left blank on both the Master Template and the already-completed LabLynx profile built earlier this session, since no real target URL exists yet for either — filling it in is a manual step for whoever publishes the finished profile. The existing field-migration logic required no changes: it already matches Vendor Profile fields by label and only copies the `value` key, so a newly-added field with no match in an older source file is simply left at its default (blank) value, and the new `type` property — which lives on the template's own current field definition, not on migrated data — is unaffected either way. Verified via `node --check` against all nine inline script blocks in both the Master Template and the LabLynx profile, a scripted Playwright pass confirming the modal correctly shows the URL input (and hides Quill) only for this field, that saving persists a plain URL string in the underlying JSON, that the on-page table renders it as a working link, and that a real "Download Word Copy" export produces a valid, schema-passing document with an actual hyperlink relationship pointing at the entered URL — confirmed directly in the exported file's `word/_rels/document.xml.rels` and a rendered visual check of the resulting page — with zero console errors throughout.
2026R1.50	Fixed a bug reported by the user: bullet lists typed into any Vendor Information field (or a Vendor Profile field, or a Chapter 29 vendor-added function) displayed correctly while editing, but turned into an orange numbered list the instant the field was saved. Root cause: Quill 2.x's internal list model represents every list type — bullet, numbered, and checklist — as an `<ol><li data-list="...">` structure, relying entirely on Quill's own CSS (scoped to `.ql-editor`) to hide the native numbering and draw a bullet character instead for `data-list="bullet"` items via a `::before` pseudo-element. That scoping CSS is only present inside the live editor; once the raw `.root.innerHTML` is saved and later displayed in the read-only Vendor Information panel (or exported to Word), the browser falls back to native `<ol>` numbering — and a pre-existing, unrelated global rule coloring every `li::marker` orange (originally written for a decorative bullet list elsewhere in the document) made that fallback number appear orange, exactly matching the reported symptom. Fixed by adding a `cleanQuillListHtml()` function that walks Quill's saved markup and regroups the underlying `<li>` elements into genuine, portable `<ul>` or `<ol>` elements (with the Quill-only `data-list` attribute and internal `.ql-ui` marker span stripped out) before the value is ever stored — applied at all three places raw Quill HTML is saved into the data model: the main per-function Vendor Information field, every Vendor Profile field, and Chapter 29 vendor-added functions. This is a genuine, portable HTML conversion, not a display-only patch, so both the on-page read-only view and a future Word export both benefit automatically from the same fix. Verified by reproducing the exact reported bug first (confirmed the raw editing markup is indeed `<ol><li data-list="bullet">`), then confirming after the fix that the stored value is clean semantic HTML with the correct tag (`<ul>` for a bullet list, `<ol>` for a genuine numbered list, tested separately to confirm neither broke the other), that the read-only panel's rendered DOM uses the correct parent tag, and that the marker color remains the intended orange — the fix corrects the tag, not the color, which was always the deliberate design. Verified via `node --check` on all nine inline script blocks and a full scripted Playwright reproduction (type text, apply Quill's own bullet/ordered toolbar buttons, save through the real UI, inspect both the stored data and rendered DOM) with zero console errors throughout.
2026R1.51	Corrected a regression the user found immediately after 2026R1.50: a bullet list saved and displayed correctly, but reopening that same function for editing made the list disappear entirely, leaving only an empty paragraph. Root cause: the 2026R1.50 fix cleaned Quill's list markup into plain semantic `<ul>`/`<ol>` HTML — correct for display, but Quill's own Parchment registry has no blot registered for a bare `<ul>` tag at all (its internal list-container blot is hard-coded to tag name `OL` only, with a `data-list` attribute on each `<li>` distinguishing bullet from ordered from checklist); reloading that cleaned HTML back into the editor via `.root.innerHTML` caused Quill to silently discard the unrecognized `<ul>` content rather than merely losing its formatting. Corrected by reversing where the cleanup happens: the three save points (the main Vendor Information field, every Vendor Profile field, and Chapter 29/category-added functions) now store Quill's raw, native markup again exactly as before 2026R1.50, preserving perfect edit round-tripping, and `cleanQuillListHtml()` is instead applied only at the two read-only display points — the Vendor Information panel and the Vendor Profile table — immediately before that stored HTML is shown outside the editor. Investigating the correct fix surfaced a related, previously undiscovered defect in the Word export: both of its HTML-to-Word-paragraph converters determined bullet-versus-numbered purely from the surrounding `<ul>`/`<ol>` container tag, never inspecting the per-item `data-list` attribute — meaning that even before this correction, every Quill-authored list would have exported to Word as a numbered list regardless of its actual type, a bug distinct from the on-page issue and never previously reported. Added a shared `listItemPrefix()` helper, used by both converters, that reads each `<li>`'s `data-list` attribute first (bullet/checked/unchecked/ordered) and falls back to the container tag only for plain hand-authored HTML with no such attribute — correctly handling both Quill-native content and any plain semantic HTML already stored in existing vendor profiles. Verified with a full round-trip regression: created a bullet list through the real toolbar and saved (confirmed stored HTML is genuine Quill markup); confirmed the read-only panel renders a true `<ul>`; reopened the same function for editing and confirmed both list items are present and intact (the exact scenario that was broken); edited and saved a second time to confirm the round trip holds under repetition; separately confirmed a genuine ordered list still round-trips correctly; and generated a real "Download Word Copy" export, validated against the OOXML schema, then rendered to PDF and visually confirmed the list appears with a genuine bullet character rather than "1./2.". Zero console errors throughout.
2026R1.52	Fixed two bugs the user reported in the "+ Add Function" flow (vendor-added functions attached directly to one of the 28 standard categories, and Chapter 29 vendor-added categories). Bug 1: clicking a previously-saved added function always opened directly into the edit form, with no read-only view first. Fixed by adding a proper view panel to that modal (status pill, functional requirement text, and vendor information rendered read-only via the existing `cleanQuillListHtml()`) with its own Edit button, mirroring the view/edit split every standard Feature Matrix function already has; adding a brand-new function still goes straight to the edit form, since there is nothing yet to view. Bug 2: the edit toolbar visibly grew by one extra copy every time the document was saved and reopened. Root cause: `#cpFieldQuillContainer` (Vendor Profile field editor) and `#vacQuillContainer` (added-function editor) are static elements built into the page's own HTML, and their Quill instances are created unconditionally on every page load - unlike the main function editor, whose container is rebuilt from scratch each time it is needed. Quill inserts its toolbar as a sibling immediately before whichever container it is bound to, and both "Download Word Copy" and "Save my work" serialize `document.documentElement.outerHTML` - a live snapshot of the actual DOM - which bakes that dynamically-created toolbar into the saved file as if it had always been static markup; reopening that file and initializing Quill again then adds a second toolbar beside the one already baked in, compounding by exactly one on every subsequent save-and-reopen cycle. Fixed with a new `removeStaleQuillToolbars()` helper, called immediately before each of the two static Quill instances is created, that strips any leftover `.ql-toolbar` siblings (and resets any Quill-added classes) from a prior save before initializing - self-healing regardless of how many times a given file was affected before this fix existed. Verified by first reproducing bug 2 exactly as reported: loading, saving, and reopening the pre-fix file three times in a row grew the toolbar count from 1 to 2 to 3 for both containers, confirmed via a scripted count of `.ql-toolbar` siblings; the same three-cycle test against the fixed file held steady at exactly 1 throughout, and the toolbar was confirmed still fully functional afterward (typed text, applied bold via the real toolbar button, confirmed the resulting HTML). Bug 1 was verified by adding a function, confirming the reopened view showed the status pill and requirement text with the edit form and Save/Cancel/Delete buttons hidden, clicking Edit to confirm the form correctly reveals with the existing values pre-filled, and confirming Cancel returns cleanly. `node --check` passed on all nine inline script blocks throughout, with zero console errors in every test.