LIMS: AI for laboratory records, queries and management-system checks
Connecting data import, business queries, document-based answers and review preparation within an existing laboratory system, with human confirmation for record creation and rule binding.
Case study draft · Client anonymized. Based on project documents and source code; the recorded knowledge-base demonstration is dated 27 August 2026. Production was not accessed for this review. Actual usage and business outcomes remain to be confirmed.
Laboratories work with both structured records and many kinds of documents: client and staff lists, equipment registers, reference-material certificates, testing records, management-system documents and operating requirements. Storing files alone does not make their contents easy to use for queries and review.
This project adds AI capabilities to an existing LIMS (Laboratory Information Management System), in a coal and fuel testing context. It connects data import, business queries, document-based answers and management-system review preparation. AI interprets, extracts and drafts; application code validates and retrieves; people approve record creation, rules and professional conclusions.
Project at a glance
| Area | Context |
|---|---|
| Industry | Laboratory testing; client identity withheld |
| Existing foundation | An Odoo 17 LIMS covering orders, samples, tests, equipment, staff and documents |
| Scope | Initial data import, natural-language business queries, knowledge-base Q&A and review assistance |
| Users | System administrators, internal laboratory staff and management-system staff; access differs by feature |
| Human responsibilities | Correct imported data, approve creation, check sources and review criteria, and make final decisions |
From files to evidence people can check
Tables, documents and certificate photos → Extraction and validation → Human-approved import
Natural language → Business tools or document retrieval → Results and sources
AI-drafted configuration → Trial run and approval → Programmatic execution
1. Data import: preview and validate before creating records
Source files often use different column names, layouts and terminology. AI maps their contents to application fields, creating editable staging rows and flagging missing required values, duplicates and unresolved references.
The implementation covers clients, staff, equipment, reference-material certificates and management-system clauses. Table and document parsing is separate from image recognition for certificate photos. Supported formats depend on the import type; arbitrary files are not treated as ready-to-import data.
People can edit staging rows, rerun validation and select what to create. Business records are written only after confirmation. Creation checks again for duplicates and records success, skipped rows and failures individually, so exceptions can be handled afterwards. The import entry point is currently for administrators.
2. Business queries: natural language calls existing data tools
Internal staff can ask about orders, samples, testing tasks, quality control and reports. The model translates questions into calls to a limited set of tools. The backend queries LIMS data, and the assistant composes a response.
Charts are built by the backend from structured tool results, reducing the need for numbers to be transcribed by the model. Results can also be exported to Excel, Word or PDF for further checking and preparation. “Read-only” here means the business query tools do not change operational records on the user’s behalf; exporting still creates temporary records.
Current access boundary: the assistant accepts internal users, while business tools retrieve data with elevated privileges. This does not establish that query results inherit each user’s business-record permissions. Data scopes for different roles still need to be designed and validated against actual usage requirements. Knowledge-base searches and document reads use the current user’s document access permissions.
3. Document Q&A: show both the source and what is missing
Management-system documents, procedures and method files can have their text extracted and searchable document cards generated. Users can ask directly, select the whole knowledge base, or name a reference with “@file”. Named-file text is supplied to the conversation within a length limit, with notices for truncation or unreadable material.
When retrieval finds nothing, the application adds an explicit instruction to acknowledge missing material. After a response, code compares recognized standard identifiers with content returned in that conversation and adds warnings about unsupported citations. This checks identifiers and source clues; it does not verify the professional meaning of every statement.
For example, if a user asks for a specific operating temperature but the relevant method document has not been added, the appropriate response is to identify the missing basis and suggest adding the file. A remembered model value should not replace the document applicable to that laboratory.
The project documentation dated 27 August 2026 contains 12 recorded system Q&A exchanges, covering named files, cross-document retrieval, informal questions, missing material and source warnings. These are limited demonstrations, not an overall accuracy score. Their business data is not presented here as public performance evidence.
4. Management-system checks: AI drafts, people approve, code executes
A clause must be translated into executable review criteria: which records to inspect, how to scope them, and how to identify missing items or expired dates. The implementation supports AI-assisted rule configuration, an ambiguity list, trial execution and human editing.
Once a person confirms a binding, the review criteria and configuration are saved together. Subsequent reviews retrieve and compare data using the established code, rather than asking the model to redefine the criteria on every run. Requirements outside the available rule types still need human handling or additional development.
The system also connects clauses to supporting documents. AI proposes candidates, reasons and quotation clues; people check and confirm the links. An attachment checksum change marks a linked document for review after revision. The system supplies facts and suggestions; responsible staff retain the final review and professional conclusions.
What the available evidence establishes
| Capability | Evidence reviewed | What it does not establish |
|---|---|---|
| Data import | Documented and coded extraction, preview, validation and approved creation | Complete migration of all historical records, or recognition of every format |
| Queries and exports | Tool allowlist, backend retrieval, chart and export code | Complete separation of business data for every staff role |
| Document Q&A | Retrieval, named-file and source-warning code, plus 12 recorded exchanges | Always-correct answers, or that demonstration files are the full set of currently applicable versions |
| Review assistance | Rule compilation, confirmed binding, programmatic checks and document links | Automatic checking of every clause, or replacement of professional review |
This was a document and source review. Odoo was not run, production databases were not accessed, and model calls were not repeated. The project inventory also notes that some configuration was checked only in development; implemented features cannot all be described as verified production use. No publicly verified time savings, financial returns or overall accuracy figures are available for this draft.
Where ongoing service could help
Potential ongoing work includes document revisions and renewed review, import mappings and validation rules, role-specific data scopes, regression checks using representative questions, and model configuration and usage-cost reviews. These are proposed service areas based on the implementation; scope, acceptance criteria and frequency still need agreement with the client.