EVIDE for Healthcare and Diagnostic AI - Preserving Observable Evidence

Section 1

1. Why This Matters Now

Every diagnostic AI system may eventually face an evidentiary question.

When a diagnostic result is challenged or placed under review, whether by a patient, a clinical board or a supervisory authority, the question concerns more than what the system produced. It also concerns what can be independently reconstructed after the event.

The use of artificial intelligence in healthcare diagnostics offers significant opportunities, but it introduces a problem at a specific point: the moment at which the system interprets received content, such as a report, a diagnostic image, structured clinical data, a laboratory result or sensor-generated data. Depending on its declared function, the system may be expected to distinguish, for example, clinical data from operational instructions, and ordinary information from possible manipulation.

Regulatory timelines may be foreseeable. Incidents are not always so.

An incident occurring before an evidentiary procedure has been established does not lose its significance. It may simply leave fewer independently preserved elements available for later reconstruction.

Section 2

2. Why the Evidentiary Boundary Matters in Healthcare

In healthcare, the distinction between clinical data, instruction, metadata and external content can directly affect classifications, priorities, escalations, reports and recommendations. The same content may present:

a surface declared as visible to the human operator;
a surface declared as readable or interpretable by the machine;
elements not immediately visible, present in metadata, markup, attachments or other representations.

This is one of the points at which an anomaly, if not observed or preserved, may become partially or wholly unreconstructable.

Section 3

3. The Risk Is Not Limited to Traditional Cybersecurity

Cybersecurity protects systems, networks and access. But an event may also concern the way an AI system interprets content that is formally accessible and legitimate. Three forms of concern should be kept distinct:

an external instruction: text or other content directed at the system that is present in, or accompanies, the material received;
a manipulation attempt: an effort by an actor to influence the system's behaviour, where such an effort is declared or otherwise supported;
an anomalous condition: altered, corrupted or unexpected content or state, with no intent implied.

Across these forms, the situations of concern include:

instructions hidden within reports, pages, images or metadata;
a system treating an external instruction as if it were part of the clinical content;
modified or contaminated diagnostic images and health values;
a possible lesion being overlooked, or its priority being improperly reduced;
false positives leading to unnecessary tests or treatment;
an altered classification, recommendation or urgency level;
uncertainty being concealed, making a result appear more reliable than it is;
a changed recipient, content or transmission path for a report;
the system using tools or data beyond the declared task.

These are risk scenarios, not statements that such events have occurred in any particular facility or technology. Which of these forms applies in a given case is not determined by EVIDE.

The domain is broad: diagnostic images, structured clinical data, laboratory results, sensor-generated data, triage systems, telemedicine systems, medical devices containing AI components, and systems producing classifications, priorities, recommendations or escalations, not only textual reports.

Section 4

4. Human-Visible and Machine-Visible Surfaces

The same content may present at least five distinct conditions:

visible to the human operator;
machine-readable but not immediately human-visible;
hidden or embedded content;
transformed or extracted representation;
unavailable or unverifiable upstream representation.

The classification of a surface as human-visible or machine-visible may be declared by the system or participant and, where possible, supported through technical artefacts. EVIDE preserves that distinction and its level of support without presuming that internal visibility has been independently verified.

This distinction connects directly to the declared visibility surfaces already provided for in the EVIDE architecture.

Section 5

5. The Observable Interpretation Boundary

EVIDE does not preserve the model's internal chain of thought. It preserves the observable boundary at which a declared classification, an artefact-supported condition or another externally observable signal was associated with an action, block, escalation or output.

Depending on its declared function, the system may be expected to distinguish, for example, clinical data from instructions, information from commands, trusted content from unverified content, diagnostic output from operational direction, and ordinary processing from a condition requiring escalation.

Where the system is expected to draw such distinctions, they may constitute a genuine evidentiary boundary.

Section 6

6. Instruction Conflict Signature — ICS

An Instruction Conflict Signature is a proposed evidentiary concept under evaluation within the EVIDE framework.

It describes a candidate set of observable signals associated with a possible conflict between the declared task scope and instructions present in an external source. Possible signals:

an external instruction directed at the system;
conflict with the declared task;
attempted workflow modification;
request for access to additional tools or data;
attempted transmission to a different destination;
blocking, escalation or request for confirmation;
inability to classify the content with sufficient confidence.

The presence of an Instruction Conflict Signature may constitute a candidate evidentiary trigger. It is not proof of an attack, error, malicious intent, clinical harm, causation or responsibility.

An ICS is not a clinical standard, a validated function, or a capability already implemented automatically in the platform.

Section 7

7. When an EVIDE Intake May Be Triggered

The declared or observed presence of an ICS does not necessarily activate an intake. It may satisfy a previously defined evidentiary materiality condition and, according to the applicable scope, lead to the proposal or activation of an evidentiary checkpoint. It does not follow a deterministic sequence of the type "ICS detected → automatic intake required."

Conditions that may be relevant:

an anomaly meeting a previously defined evidentiary materiality condition;
declared or artefact-supported divergence between the human-visible and machine-visible surfaces;
content classified as a possible external instruction;
modification of, or an attempt to modify, the intended action;
blocking or escalation;
a request for human review;
a result produced in the presence of unresolved signals;
inability to verify an upstream representation.

Section 8

8. What the Intake Can Preserve

The following fields constitute a candidate Minimum Evidentiary Set to be tested and refined for the defined system, boundary and experimental scope. They are not a universal schema already established:

event identifier;
declared source and provenance;
declared origin of the referenced artefact;
declared transfer path;
receipt timestamp;
preservation timestamp;
artefact digest;
custody condition at the intake boundary;
representation actually received;
declared visibility surface;
materially relevant segment;
declared task or objective;
declared or artefact-supported anomaly or conflict condition;
system-declared classification;
proposed or attempted action;
operational consequence;
human intervention or confirmation;
model, policy and tool versions;
external evidence references;
level of independent support for each material assertion;
unresolved signals and any applicable unverifiable condition.

A digest and a receipt or preservation timestamp do not, by themselves, establish authorship, origin, authenticity, creation time or truth of the referenced content.

Section 9

9. Observable Outcomes and Evidentiary States

To avoid ambiguity, "ignored" is not used on its own, as it can carry opposite meanings. Candidate evidentiary outcome labels for this proposed use case may include:

detection_declared
detection_independently_supported
no_action_taken
external_instruction_disregarded
blocked
escalated
submitted_for_human_review
executed
unresolved
unverifiable

These candidate labels are presented for evaluation and do not necessarily correspond to fields or states already implemented in the EVIDE platform. unresolved and unverifiable can be linked to existing EVIDE capabilities; the rest of the list remains candidate.

None of these labels determines clinical correctness, compliance, causation, fault or responsibility.

Section 10

10. What EVIDE Does Not Do

EVIDE preserves

the observable conditions under which a diagnostic or operational outcome was produced, modified, blocked, escalated or transmitted

EVIDE does not

diagnose;
determine clinical correctness;
replace medical professionals;
authorise treatments or healthcare decisions;
control the device during execution;
replace cybersecurity, safety engineering or regulatory validation;
acquire or certify the model's internal chain of thought;
automatically establish an attack, error, causation, fault or responsibility.

Reconstructability is an evidentiary condition, not a clinical or governance determination.

Section 11

11. Potential Operational Evaluation Path

This is not a clinically validated integration path, nor a solution ready for any healthcare environment. It is a possible evaluation path:

System and boundary identification
Evidentiary materiality conditions
Checkpoint selection
Candidate Minimum Evidentiary Set
External Artifacts linkage
Intake configuration
Reconstruction-sufficiency review
Periodic review of triggers and limitations

No promise is made of clinical certification, diagnostic validity, operational safety or automatic compliance.

Section 12

12. Governance Lab Experimental Path

Controlled experimentation, initially without real health data and using synthetic scenarios, following the Lab's standard sequence:

Registration
Identity confirmation
NDA where required
Scope Draft
Participant-side Profile Freeze
Bilateral Scope Freeze
Experiment start

Possible experiments:

a synthetic report containing an embedded instruction;
divergence between a human-visible and a machine-readable representation;
simulated metadata alteration;
conflict between a declared clinical task and an external instruction;
blocking, escalation or human review;
an unavailable original representation;
comparison between a final output and the preserved evidentiary sequence.

Participation in the Lab does not constitute approval, certification or validation of the participant or of the technology.

Section 13

13. Data Minimisation and Synthetic Testing

A synthetic-first approach: no real health data during the initial phase.
Selective preservation rather than indiscriminate recording.
Digests and references where transfer of the artefact is unnecessary.
Separation between clinical data and evidentiary records.
Scope-defined retention.
Limited and documented access.

Synthetic testing reduces exposure to real health data but does not, by itself, establish clinical validity, operational safety or regulatory compliance.

Section 14

14. Evidentiary Reconstruction After an Incident

In the absence of an evidentiary checkpoint, the final output may remain available while the conditions that produced it disappear.

With EVIDE, reconstruction does not have to depend solely on the final report; it can draw on elements preserved at the checkpoint. Where those elements are available and within the defined scope, an EVIDE-supported reconstruction may include the received input, declared visibility surface, active versions, declared or artefact-supported conflict condition, human intervention, operational consequence and unresolved signals.

Section 15

15. Illustrative Scenarios

The following are illustrative scenarios, not descriptions of real incidents.

Scenario A — An embedded instruction in a report

A system receives a report containing visible clinical text and an embedded instruction that is not immediately visible to the operator. The instruction purports to modify the priority of the case.

Sequence:

Content received
Visibility divergence declared or artefact-supported
Instruction-conflict candidate identified
Action blocked or escalated
Human review requested
Relevant artefacts and states anchored
No automatic conclusion concerning attack, clinical error, causation or responsibility

Scenario B — An agent receives a denial and attempts another path

An AI agent performing a declared task within a healthcare organisation requests access to a resource, which may be patient data, a diagnostic tool or a clinical workflow. The access-control system returns a denial. The agent then makes further attempts, and a later access is declared to have been obtained through a different path.

Where the relevant steps are submitted to EVIDE within the defined scope, a reconstruction may link:

the agent's initial request;
the access decision returned, including a denial;
subsequent attempts;
any later access through another declared or artefact-supported path;
the outcome of each step;
any human intervention or confirmation;
unresolved or unverifiable steps.

Sequence:

Request
Access decision returned (denial)
Subsequent attempts
Later access through another declared or artefact-supported path
Outcome
Human intervention or confirmation

Where supported by the applicable scope and implementation, related steps may be connected through linked intake records and applicable chain references. The linkage records the relationship between the entries; it does not establish that one caused another.

What this scenario does not establish

EVIDE does not grant or deny access;
EVIDE does not block the agent in real time;
EVIDE does not replace identity and access management, access controls or security monitoring;
a later access does not prove circumvention, impropriety or causal connection with the earlier denial;
an alternative path may have been legitimate;
the absence of a preserved step does not prove that the step did not occur;
EVIDE does not establish attack, error, causation, fault or responsibility.

Section 16

16. Who Can Work With EVIDE

Public and private healthcare providers
Hospitals and clinics
Diagnostic laboratories
Medical-device manufacturers
Healthcare AI developers and integrators
Telemedicine providers
Universities and research centres
Clinical governance teams
Cybersecurity and incident-response teams
Regulators, public authorities and oversight bodies

Section 17

17. Proposed Research Questions

Which interpretation boundaries carry genuine evidentiary materiality?
What minimum set allows sufficient reconstruction?
Who should define and approve the triggers?
How can an observable deviation be distinguished from a clinical judgement?
When is human review necessary?
How should what remains upstream and unverifiable be documented?
How can sufficient information be preserved without total recording?
How can a denial, subsequent attempts and any access obtained through another path be linked without recording the underlying patient data?

Section 18

18. Closing

Potential Operational Evaluation

For providers and manufacturers interested in evaluating checkpoints, intake and reconstruction sufficiency in a defined system or process.

Discuss an Evidentiary Use Case ↗

Governance Lab Experiment

For organisations interested in a circumscribed, synthetic-first study that is bilaterally frozen before it begins.

Propose a Synthetic Experiment ↗

Contact EVIDE Governance Lab ↗

References

Related use case: app.certifywebcontent.com/docs/evide-physical-ai/
EVIDE for Legal & Evidentiary Use: app.certifywebcontent.com/legal-evidentiary-use
EVIDE API Documentation: app.certifywebcontent.com/docs/evide-intake-schema/
EVIDE External Artifacts: app.certifywebcontent.com/docs/evide-artifacts/
EVIDE Governance Lab: lab.certifywebcontent.com
EVIDE Framework: certifywebcontent.com - Evidentiary Deposit
Contact: info@certifywebcontent.com