When I started thinking about this solution, the problem was very simple.
In eLIMS, users have a lot of data, but getting quick answers is not always easy. A user may want to know something like:
Show me studies not completed on time.
To answer this, the system has to check study details, planned completion date, completion data, actual completion date, user access, legal entity, and then decide whether the study is on time, delayed, or missing information.
So the question I had was:
Can we allow users to ask this in simple English, but still keep the backend safe and controlled?
That is the main problem this solution is solving.
Overall Design
The Main Design Decision
The most important decision I made was:
AI should not directly query the database.
AI is only used to understand what the user is asking.
It creates a plan.
That plan may be right or wrong. So I do not execute it directly. First, I send it to the validator.
Only if the validator says the plan is safe, the backend will execute it.
This is the main difference between this solution and a normal chatbot.
A chatbot may answer directly.
Here, AI only prepares the plan.
The application still controls what can run.
Why I Designed It This Way
In a system like eLIMS, we cannot allow AI to freely access data.
There are roles.
There are legal entities.
There are allowed services.
There are allowed fields.
There are audit needs.
There should not be any write operation from this assistant.
So I kept a clear boundary.
AI can understand the question.
Validator decides whether the plan is allowed.
Execution engine decides what data to read.
Audit service records what happened.
This keeps the user experience simple, but the backend is still controlled.
What Happens When User Asks a Question
Let us take this example:
Show me studies not completed on time.
The Angular UI sends this question to the .NET API.
The API asks the plan generator to convert this question into a structured plan. The plan may say that study service and core lab service are needed, and the output should include delayed or indeterminate studies.
But before doing anything with data, the validator checks the plan.
It checks:
This validator is very important. Even if AI gives a wrong service name or tries to use a field that is not allowed, the request will stop there.
No data will be read.
Execution Logic
Once the plan is valid, the execution engine takes over.
It checks whether the user has the right role and legal entity access.
After that, it reads the approved data and applies the business logic.
For the current use case, it checks study planned completion date and TestP actual completion date.
The classification is simple:
| Case | Result |
|---|
| Actual completion date is before or equal to planned date | On Time |
| Actual completion date is after planned date | Delayed |
| Planned date or actual completion date is missing | Indeterminate |
I kept Indeterminate separately because missing data should not be hidden. In real systems, missing data is also an important signal.
Why Service Registry Is Used
I did not want service names and fields to be hardcoded everywhere.
So I introduced a service registry.
The service registry tells the system:
This makes the design easier to extend.
Tomorrow, if we want to add sample service or protocol service, we do not have to change the full design. We add the service contract, allowed fields, and purpose. Then the same pattern can continue.
Why Audit Is Important
I also added audit as part of the flow.
For every request, we should know:
What did the user ask?
What plan was generated?
Which validation checks passed?
Which services were called?
What result was returned?
This is useful for support, debugging, and review.
In production systems, we cannot just show an answer and forget how it was created. We need traceability.
Final Architecture Pattern
The full pattern is this:
This is the pattern I wanted to prove with this solution.
Not AI directly reading everything.
Not a chatbot giving random answers.
Not a hardcoded report.
It is a controlled assistant.
The user gets a simple way to ask questions.
The system keeps control of validation, access, execution, and audit.
That is the balance I wanted in this design.
My View
For enterprise applications, AI should be used carefully.
It should help users ask better questions and get faster insights. But it should not bypass the application rules.
In this solution, AI is useful because it understands the user’s question. But the actual responsibility still stays with the application.
That is why I designed the eLIMS Insight Assistant as:
Question → Plan → Validate → Authorize → Execute → Audit → Result
This keeps it simple for the user and safe for the system.
