Printed on the standard letterhead. Page furniture, margins and repeating table headers come from the same stylesheet the PDF service uses.

Pensieve Labs

The operating system for hospitals

DIS-GL-027

v1.0.0 | 31 July 2026

AI / ML Feature Disclosure

Position as at 31 July 2026. This document is reviewed and republished whenever a feature using a model is added, changed or removed, which is why its review date is shorter than the rest of the disclosure set.

Applicability

`DM-1` Dedicated	`DM-2` Shared	`DM-3` Customer Cloud	`DM-4` On-Premise
Yes	Yes	Yes	Features requiring an external model provider are unavailable where the deployment has no permitted egress (Section 6)

1. The four commitments

These are the answers to the four questions a hospital actually asks, stated before the detail.

#	Commitment
1	No feature using a model makes, supports or influences a clinical decision. No diagnosis, no triage, no clinical risk score, no patient-specific dose, no image or signal interpretation, no treatment recommendation. The boundary is `DIS-GL-028` Section 7 and it is enforced at the design gate, not at review
2	Hospital data is never used to train, fine-tune, or improve a model offered to any other hospital, or to `Edsol Edtech Pvt. Ltd.` itself. Not aggregated, not de-identified, not "with permission". The answer is no, and it is contractual: `DPA-GL-001`
3	Any third party that would receive hospital data to run a model is a sub-processor, appears in `DIS-GL-009` Section 2, and requires 30 days' notice with an objection right. As at `31 July 2026` there is none
4	Every model-assisted feature is optional and can be switched off per hospital, and where the output reaches a person, a named human reviews it before it has any effect

2. The feature inventory

This is the complete, dated list. A feature not on this list does not use a model.

Feature	Function	Data used	Human review	Model runs	Opt-out	Status
Clinical coding suggestion	Suggests billing and diagnosis codes to a coder, from documentation the clinician has already authored, for the purpose of billing, never as a clinical conclusion	The hospital's own documentation, within the tenant	Yes: the coder accepts, edits or rejects every suggestion. Nothing is applied automatically	Within the deployment	Yes, per hospital	[TO BE SUPPLIED] (see Section 3)
Claim denial likelihood	Flags a claim as likely to be queried by a payer, so a human checks it before submission, from claim and payer history, not from clinical risk	Claim, tariff and payer-response history, within the tenant	Yes, a billing user decides	Within the deployment	Yes	[TO BE SUPPLIED]
Demand and stock forecasting	Forecasts consumption, bed occupancy and staffing demand from historical operational data	Aggregate operational data, within the tenant	Yes, a manager decides	Within the deployment	Yes	[TO BE SUPPLIED]
Roster optimisation	Proposes a roster against constraints the hospital sets	Staff availability and constraint data	Yes, the roster is approved by a person	Within the deployment	Yes	[TO BE SUPPLIED]
Document classification	Routes a scanned document to the right record and document type	The document and its metadata, within the tenant	Yes, misfiling is correctable and the correction is logged	Within the deployment	Yes	[TO BE SUPPLIED]
Natural-language search over the record	Finds records a user is already permitted to see. Search, not summarisation, and not inference	The tenant's own records, subject to the same authorisation as any other read	Not applicable: it returns records, it does not assert anything	Within the deployment	Yes	[TO BE SUPPLIED]
Transcription of dictated notes	Converts a clinician's dictation to text for the clinician to review, edit and sign. No clinical interpretation, no structuring into a diagnosis	The audio the clinician dictates	Yes: the clinician signs. Unsigned transcription is not a record	Within the deployment	Yes	[TO BE SUPPLIED]
Financial and operational anomaly detection	Flags unusual patterns in billing, stock and access data for human investigation	Financial, inventory and audit data	Yes	Within the deployment	Yes	[TO BE SUPPLIED]

Every function above is administrative or operational. Not one of them touches a clinical decision, and each is designed so that a person makes the decision the output relates to.

3. The honest status statement

As at 31 July 2026, the enablement status of each feature in Section 2 is [TO BE SUPPLIED]. The table above states the inventory and the boundary that governs any feature using a model, so that a hospital's evaluation can proceed against a published constraint rather than a conversation. A hospital should ask which of these are enabled in its own deployment, and the answer is recorded in the Deployment Record.

Pensieve Labs publishes the constraint before the capability deliberately: a boundary published after a feature ships is a rationalisation, and a boundary published before it is a design rule.

4. What is never done

Stated as prohibitions, because positive commitments are easier to satisfy loosely.

No clinical decision output. DIS-GL-028 Section 7.1 is the operative list, and every item on it applies to model-based features as much as to rule-based ones.
No training on hospital data. Not on one hospital's data for another, not for a shared model, not for a Pensieve Labs product, not de-identified, not aggregated. This is a contractual undertaking in DPA-GL-001 and a Pensieve Labs position stated in WPR-GL-001 Section 12.1.
No cross-tenant inference. A model available to one hospital does not see, learn from, or produce an output influenced by another hospital's data, in any deployment model including DM-2.
No hidden model. Every feature using a model is on the Section 2 list. A feature that starts using one is added to the list and the document is republished before the feature is enabled.
No autonomous action. No model-derived output writes to a clinical record, sends a message to a patient, submits a claim, places an order or changes a configuration without a named person's action.
No secondary use. Hospital data is not used for Pensieve Labs's research, benchmarking, marketing, model evaluation or product analytics.
No undisclosed third-party model provider. Section 5.

5. Third-party model providers

As at 31 July 2026 Edsol Edtech Pvt. Ltd. engages no third-party artificial intelligence or machine learning provider that receives Customer Personal Data. DIS-GL-009 Section 4 records this as an empty row rather than an omission.

If that changes:

Step	What happens
The provider is added to `DIS-GL-009` Section 2, the tier that processes Customer Personal Data	Not Section 3, and not an unlisted "AI vendor"
30 days' advance notice to every affected hospital, with an objection right	`DPA-GL-001` clause 8.4
Published in `DIS-GL-010` on the day of the change	None
This document is republished naming the provider, the feature, the data sent, the processing location, whether the provider may retain or train on the data (a provider that may is not engaged), and the retention period	None
The hospital's opt-out remains available	Section 7

The commitment behind the process: Pensieve Labs will not engage a model provider whose terms permit it to retain hospital data or to train on it. That is a selection criterion, not a negotiating position.

6. Per-deployment-model position

Model	Position
`DM-1`, `DM-2`	Model-based features run within the deployment's own project, under the same encryption, authorisation and audit controls as every other function
`DM-3`	Same, inside the hospital's own project. Any egress required by a feature must be permitted by the hospital's own egress policy
`DM-4`	Features that require an external model provider or an outbound connection are unavailable where the deployment has no permitted egress. Features that run locally are available subject to the hardware specification in `ADD-GL-008`. This is stated at qualification, not discovered at go-live

7. Opt-out and control

Control	Position
Per-hospital enablement	Every feature in Section 2 is off unless the hospital enables it, and can be switched off at any time through the support channel
Per-feature, not all-or-nothing	A hospital may enable coding suggestions and disable transcription
Effect of switching off	The feature disappears from the interface. No model output is retained or applied thereafter
Visibility of model-assisted output	Where an output originated from a model, the interface says so, and the audit trail records that the suggestion was model-generated and who accepted, edited or rejected it
Patient-level opt-out	Not applicable: no feature in Section 2 produces an output about an individual patient's clinical care. Where a hospital nonetheless wants a record class excluded from a feature's scope, it is configurable

8. Governance

Control	Position
Design gate	Every proposed feature using a model is assessed against `DIS-GL-028` Section 7 before it is built, and the assessment is recorded (`DIS-GL-018` Section 5.1)
Language gate	The banned vocabulary in `DIS-GL-028` Section 8 applies to every description of these features, in product, documentation and sales material
Change control	A change to a model, a prompt, a threshold or a training set that alters behaviour is a release under `DIS-GL-031`, with a change record
Human accountability	Every feature has a named human decision point. A feature that cannot be given one is not built
Ethics position on research use	Using hospital data to develop or validate a model is biomedical research under the applicable Indian ethical guidance, requiring institutional ethics committee review and, in most framings, participant consent. This is a second, independent reason for commitment 2 in Section 1, alongside the data protection analysis. `Pensieve Labs` does not do it
Algorithmic due diligence	The Indian rules place a due-diligence obligation on a significant data fiduciary in respect of algorithmic software. `Pensieve Labs` is not so designated, and applies the discipline voluntarily: every feature in Section 2 is assessed for whether its output could disadvantage a Data Principal, and the assessment is recorded

9. Limitations

9.1 The enablement status is not yet published. Section 3. The inventory and the boundary are; the per-feature status is [TO BE SUPPLIED] and is recorded per deployment.

9.2 A model's output is not explainable line by line. Where a feature suggests a code or flags a claim, Pensieve shows the evidence it drew on, but does not produce a formal explanation of the model's internal reasoning. This is why every feature has a human decision point rather than an explainability claim.

9.3 Suggestions can be wrong. A coding suggestion may be incorrect and a forecast may be inaccurate. The controls are that a person decides, that the decision is logged, and that no output has an automatic effect. Pensieve Labs does not claim accuracy figures it has not measured and published.

9.4 Transcription is not a clinical record until a clinician signs it. An unsigned transcription is a draft. A hospital that treats it otherwise has created a clinical-safety risk that no software control can address.

9.5 Bias. Any model trained on operational data reflects the patterns in that data. For the administrative functions in Section 2 the consequence is an inaccurate suggestion rather than a clinical harm, which is one of the reasons the boundary in DIS-GL-028 matters: it keeps the failure mode financial and operational rather than clinical. Pensieve Labs does not currently publish bias testing results for these features.

9.6 No independent assessment. No third party has reviewed these features, their boundaries or their governance.

Question	Document
The regulatory boundary these features must stay inside	`DIS-GL-028` Clinical Safety Boundary Statement
Whether any model provider receives hospital data	`DIS-GL-009` Subprocessor Register Section 2 and Section 4
Notification if a model provider is engaged	`DIS-GL-010`
The contractual prohibition on training and secondary use	`DPA-GL-001`
Data classes and what may be processed	`DIS-GL-022`
The design gate	`DIS-GL-018` Section 5.1
Release control over model changes	`DIS-GL-031`

11. Change history

Version	Date	Author	Summary
1.0.0	`31 July 2026`	`Pensieve Labs` Security	First published edition. Four commitments, complete feature inventory with human review points, seven prohibitions, and the process for engaging a model provider. Enablement status published as unsupplied rather than asserted.

Edsol Edtech Pvt. Ltd. | CIN [TO BE SUPPLIED] | 28, Jamunather, Bulandshahar, Uttar Pradesh, India

DIS-GL-027 v1.0.0 | Last Modified On: 31 July 2026

info@pensievelabs.org | pensievelabs.org | trust.pensievelabs.org

#AI / ML Feature Disclosure

#Applicability

#1. The four commitments

#2. The feature inventory

#3. The honest status statement

#4. What is never done

#5. Third-party model providers

#6. Per-deployment-model position

#7. Opt-out and control

#8. Governance

#9. Limitations

#10. Related documents

#11. Change history