Generative AI and enterprise copilots for MedTech, built around the question that determines whether the answer is safe: which version of the device is this, and which document applies to it.
A field service engineer standing beside a unit manufactured six years ago, running firmware two generations behind, with a hardware revision superseded twice, asks how to perform a procedure. A copilot retrieving the current service manual returns a correct answer to a different question. The procedure may have changed, the part numbers may have changed, and the torque specification may apply to a component this unit does not contain. Relevance here is a function of the device, not of the question.
An accurate answer from the wrong device manual is still the wrong answer. And unlike a product copilot this one is used by your own people, which makes it easier to deploy and no less consequential.
Device companies hold design history files, risk files, technical documentation, service manuals, work instructions, specifications and validation records, all under version control, all approved, and all stored in systems built for document control rather than for finding anything. An engineer looking for a specification reads three documents to locate it. A quality engineer assembling an audit response searches by document number because the system has no other usable entry point. The knowledge exists, it is well governed, and it is effectively inaccessible without knowing where to look.
The second problem is that nearly every document is version-sensitive, and the relevant version depends on something outside the question.
Relevance depends on the device, not the question
The right revision is determined by hardware version, firmware, configuration and manufacturing date rather than by what was asked.
Document control systems are not search systems
They are built to prove a document is approved and current, which is a different problem from helping somebody find it.
Superseded revisions remain legitimately stored
Because devices in the field still run them, which means the corpus cannot simply exclude them.
The field has no connectivity guarantee
Service engineers work in hospital basements, and a copilot that requires a reliable connection is unavailable where it matters.
Engineering knowledge is in people, not documents
Why a design decision was made is frequently undocumented, and the person who knows is retiring.
One wrong answer costs more adoption than ten unhelpful ones
Technical users abandon a tool that misled them once, and field engineers talk to each other.
Ask whether your copilot knows which device the user is asking about.
Most enterprise copilot designs treat the question as the whole input. In a device company the critical context is which unit, which hardware revision, which firmware, which configuration and which market, and none of that is in the question text.
A copilot for a device company starts by establishing what it is being asked about: the serial number, the configuration, the installed firmware and the market. Those determine which document revisions are applicable, and retrieval that skips this step returns the current answer rather than the correct one.
Step 1
Establish device context first, from a serial number, an asset record or the service system, before any retrieval occurs.
Step 2
Map document applicability to device configuration, which is the metadata most document control systems hold poorly.
Step 3
Make revision applicability a retrieval condition rather than a filter applied afterwards.
Step 4
Cite with revision and effective date visible, so the user can see which document the answer rests on.
Step 5
Design for intermittent connectivity, since the highest-value user is in a basement with no signal.
Step 6
Define refusal explicitly, because declining is correct when applicability cannot be established.
Step 7
Scope by audience, since engineering, quality, regulatory, service and support have different eligible corpora.
Step 8
Capture the undocumented knowledge deliberately, because a copilot cannot retrieve what nobody wrote down.
Step 9
Request the missing configuration rather than inventing a confident answer, since asking which device is a better response than assuming the current one.
Step 10
Record the interaction including device context, retrieved revisions and the answer given.
A copilot that cannot establish applicability should refuse rather than answer generally.
When the device context is unavailable or ambiguous, the safe response is to say so and ask, not to return the current revision with an implicit assumption nobody stated. Engineers under time pressure at a customer site will act on a confident answer, and the failure mode is a correct procedure performed on the wrong hardware revision.Â
General copilot and retrieval architecture is covered on our enterprise copilot pages. These are the capabilities specific to a company whose documentation is controlled, versioned and tied to hardware configurations in the field.
Resolve
Device Context Resolution
Serial number, hardware revision, firmware, configuration and market established from service or asset systems before retrieval begins.
Revision Applicability Mapping
Which document revisions apply to which device configurations, which is the metadata layer most document control systems do not maintain.
Audience Scoping
Engineering, quality, regulatory, service and support each have a different eligible corpus, enforced in retrieval rather than in guidance.
Refusal Design
What the copilot declines, including every case where applicability cannot be established, which is a correct answer rather than a gap.
Retrieve and Attribute
Controlled Document Retrieval
Retrieval across design history, technical documentation, service manuals, work instructions and specifications with revision state intact.
Structure-Aware Search
Technical documents carry meaning in tables, diagrams, part numbers and cross-references, which flat text retrieval loses.
Citation With Revision
Every answer attributed to a document, revision and effective date, so the user can verify applicability without leaving the interface.
Offline and Degraded Operation
Cached applicable content for field use, since the engineer who needs this most is frequently where connectivity is not.
Govern and Operate
Knowledge Capture
Making undocumented engineering and service knowledge retrievable, since a copilot cannot surface what nobody recorded.
Interaction Recording
Question, device context, retrieved revisions, citations and answer, retained because reproduction is unavailable.
Evaluation Design
Applicability correctness, citation correctness, omission, refusal behaviour and performance after any version change.
Adoption Measurement
Who stopped using it and after what experience, which is the signal that determines whether the deployment survives.
What CaliberFocus does, and does not do?
We make approved MedTech knowledge easier to find, understand and use. We do not make the copilot an independent engineering, quality or regulatory authority. We resolve the device before the question, because in a company whose products stay in service for a decade the current revision is frequently the wrong answer.Â
Each audience has a different eligible corpus and a different tolerance for a wrong answer. The third column is what determines whether a response is usable, and for one of these it is physical rather than informational.
| Audience | What They Ask About | What Determines a Usable Answer |
|---|---|---|
| Field Service | Procedures, parts, diagnostics, configuration | The device in front of them. Wrong revision means wrong procedure on live hardware. |
| Customer Support | Troubleshooting, product behaviour, escalation | Device context plus knowing when a report is potentially a complaint. |
| Design Engineering | Specifications, prior decisions, components, interfaces | Which design baseline applies, and the reasoning that was never written down. |
| Quality | Procedures, records, prior nonconformances, audit evidence | Effective procedure revisions only, since a superseded one actively misleads. |
| Regulatory | Submissions, technical documentation, market requirements | Market applicability and submission state, which vary per geography. |
Support Is the Audience Most Likely to Hear Something Reportable
A customer support agent fielding a routine troubleshooting call is the person most likely to be told, in passing, something that constitutes a complaint or describes a potential adverse event
Semantic similarity establishes topical relevance and nothing else. In a device company three further conditions determine whether a document should inform the answer, and the third column is what each one requires that most document estates do not currently hold.
| Condition | What It Determines | What It Requires |
|---|---|---|
| Topical Relevance | Which content relates to the question | Semantic retrieval, the part that works out of the box. |
| Device Applicability | Whether this document applies to this unit | Configuration-to-revision mapping, rarely maintained as queryable metadata. |
| Revision Currency | Which revision was effective for this device at this time | Effective dating, supersession and the device build record. |
| Audience Eligibility | Whether this user should receive this content | Identity passed into retrieval rather than applied afterwards. |
| Market Applicability | Whether this applies in the relevant geography | Market metadata on technical and regulatory content. |
Pass device context into the retrieval query
Not into the prompt, since the model reasoning about applicability is weaker than a filter enforcing it.
Preserve technical document structure
Tables, part numbers, diagrams and cross-references carry the meaning, and flat chunking discards it.
Show the revision in the citation
A user shown a source without its revision will assume it applies, and in this industry that assumption is frequently wrong.
Cache for the field
The engineer who needs this most works where connectivity is unreliable, and an unavailable copilot is an unused one.
Treat retrieved content as data, never instruction
Technical documents, customer emails and service notes can all carry text that should not steer behaviour.
Make refusal informative
I cannot establish which revision applies to this unit is useful. A confident general answer is not.
Your document control system holds approval state, not applicability.
Document management proves that a revision was approved, when it became effective and what it superseded. It rarely records which device configurations a revision applies to, because that relationship lives in engineering change records, build documentation and service bulletins rather than in the document metadata. Constructing that mapping is the unglamorous foundation of a device company copilot, it is a data project rather than an AI one, and nothing useful can be built until somebody does it.
Enterprise copilots are frequently treated as lower risk than product-embedded ones because the users are employees. That is true for data exposure and false for consequence: a service engineer acting on a wrong procedure, a quality engineer citing a superseded requirement, or a support agent missing a reportable report all produce real outcomes. The governance question is not whether the users are internal but what they do with the answer.
Scope and applicability
- Device applicability enforced in retrieval, since this is the primary safety property of a service-facing copilot
- Audience eligibility scoped per function, because engineering, quality, regulatory and support need different corpora
- Refusal where applicability cannot be established, defined and tested rather than left to model judgement
- A stated position on whether copilot output may enter a controlled record, agreed before deployment
Records and traceability
- Question, device context, retrieved revisions, citations, versions and answer retained, since reproduction is unavailable
- Where output informs a service action or quality record, traceability to the revision cited
- Model, prompt, retrieval configuration and corpus versioned together, because each changes behaviour
- Retention matched to the obligations of the documents the copilot reads and the actions it informed
Compliance
- Engineering controls capable of supporting the frameworks that apply, which may include FDA regulation, ISO 13485 and electronic record expectations
- Applicability, interpretation and validation strategy determined by your quality and regulatory functions rather than by us
- Support-facing deployments designed to route potential complaints rather than resolve them away
- Licensed standards and third-party content used within the terms, which frequently restrict redistribution
Security
- Retrieved content treated as data rather than instruction, since service notes and customer messages enter the corpus
- Copilot permissions never exceeding those of the user who invoked it
- Technical documentation treated as confidential, since design and manufacturing detail is commercially sensitive
- Provider disclosed as a subprocessor, since customer and notified body due diligence extends through it
Internal does not mean low consequence, it means low friction to deploy.
The argument for starting with an enterprise copilot is sound: no patient-facing exposure, no regulated product boundary, users who can partly verify answers, and an organization that can train its own people. None of that means the answers are inconsequential.
A copilot can produce a factually correct answer from an inapplicable document, and standard accuracy evaluation will score it as a success. The measure that matters in a device company is whether the cited revision applies to the device being asked about, and establishing it requires a reference set with device context attached rather than a list of questions and expected answers.
Applicability correctness: Whether the cited revision applies to the device in the question, which is the primary safety measure here.
Applicability correctness: Whether the cited revision applies to the device in the question, which is the primary safety measure here.
Applicability correctness
Whether the cited revision applies to the device in the question, which is the primary safety measure here.
Citation correctness
Whether the cited passage supports the statement, measured rather than inferred from a citation existing.
Omission
What a complete answer should have included, particularly warnings and prerequisites in service procedures.
Refusal in both directions
 Failing to decline on ambiguous applicability is the safety risk, over-refusal is the adoption risk.
Field performance specifically
Because the conditions of use differ from the office, and so does the tolerance for a slow or unavailable answer.
Abandonment
Who stopped asking and after what experience, which in a field population spreads by word of mouth.
Improve the knowledge system, not only the prompt. When the copilot fails, establish whether the cause was missing documentation, incorrect product metadata, weak version management, incomplete access synchronization, poor retrieval ranking, an ambiguous question or model interpretation, because repeated prompt changes cannot resolve a source-data problem.
Build the evaluation set with device context
Questions alone are insufficient, since the same question has different correct answers per configuration.
Include superseded-revision traps deliberately
Cases where the current document is wrong for the device, since that is the failure mode being guarded against.
Keep a failure library
Every meaningful wrong answer added, so a future version proves it did not reintroduce the problem.
Test with field engineers, not in a workshop
Real conditions, real devices, real time pressure, because that is where the tool either works or is abandoned.
Copilot programmes are usually reported as users onboarded and questions answered. The outcomes that matter here are whether answers were applicable to the actual device and whether the people in the field still use it after the first month.
| Category | What We Measure | Why It Matters |
|---|---|---|
| Prove It Applies to the Device | Whether the copilot identified the correct product, established hardware and firmware version, retrieved an approved and applicable source, preserved technical conditions and warnings, cited support the user can open, would abstain if configuration were missing, and reduced total time to a verified answer | If these cannot be answered, a more capable model will not solve the underlying problem. |
| Applicability Correctness | Cited revisions that apply to the device in the question | The primary safety measure, and absent from standard accuracy evaluation. |
| Citation Correctness | Cited passages that genuinely support the statement | Presence is easy to measure and correctness is what matters. |
| Field Abandonment | Service engineers who stopped using it, and their last experience | This population talks to each other, and the verdict spreads fast. |
| Refusal Balance | Correct refusals on ambiguous applicability against over-refusal | One is the safety risk and the other is the adoption risk. |
| Applicability Coverage | Proportion of the document estate with configuration mapping | Bounds what the copilot can safely answer at all. |
Honest Expectation Setting
An assessment may reveal fragmented technical knowledge, missing product configuration metadata, superseded documents in results, weak controlled document indexing, inconsistent access permissions, generic AI tools used without product context, pilots without evaluation datasets, unsupported citations, poor retrieval for technical terminology, unclear ownership of approved knowledge or adoption without measurable improvement.
We will establish whether device configuration can be mapped to document applicability, assess whether retrieval can enforce it, test applicability correctness rather than answer accuracy, review field conditions against the deployment assumption, and identify where undocumented knowledge is the real gap.
Bring us a specialty or clinical setting where clinicians are spending too much time creating notes. We will assess where ambient documentation fits, what must remain clinician controlled, how it should integrate with your EHR, and how to measure whether it is actually reducing burden.
One conversation with people who have run these deployments, and a written readiness view you can use with or without us.
- AI Agents and Workflow Automation
- Voice and Conversational AI
- Document AI and Intelligent Processing
- Generative AI and Enterprise Copilots
- AI Strategy and Governance
- HCC and Risk Adjustment Analytics
Security & Compliance
