Search all 478 artefacts by title, document ID or content.
Deployment models
Written for the person who has to decide whose computers this runs on, and who does the watching.
All four models are supported and fully papered. The same Pensieve Labs build runs in every one of them. There is no cut-down on-premise edition and no premium hosted edition. What changes is who owns the infrastructure, who holds the keys, who is watching at 2 a.m., and how many days it takes to go live.
The recommendation
One isolated cloud project per hospital inside Edsol Edtech's organisation: dedicated services, dedicated database, dedicated buckets, dedicated keys. It is the fastest to go live, it needs nothing from your IT team, and its isolation story is short enough to satisfy a board in one meeting. Choose it unless you have a specific reason not to.
Said before you sign
On-premise adds hardware procurement, delivery, room preparation and installation: typically 60 to 90 days, and often more. Nobody has ever shortened a hardware delivery by asking nicely. It is the slowest and most expensive model and Pensieve will tell you so before you sign, not after.
The limit of the SLA
In DM-4 there is no availability commitment and no RTO or RPO commitment: response times only. If the air conditioning fails on a Sunday, that is your event, and no contract can change that. Pensieve will not sell you an uptime number it has no mechanism to deliver.
Section 1
Every technical disclosure in this register carries a deployment-model applicability matrix at the top, because a security or residency claim that is only true for one model is worse than no claim at all. This is the top-level version of that matrix.
| Model | DM-1DedicatedPensieve-hosted, isolatedDefault | DM-2SharedPensieve-hosted, multi-tenant | DM-3Customer CloudHospital's own cloud project | DM-4On-PremiseHospital's own hardware |
|---|---|---|---|---|
| What it is | One isolated GCP project per hospital inside Edsol Edtech's organisation. Dedicated Cloud Run services, dedicated database, dedicated buckets, dedicated KMS keys. | Shared platform with logical isolation by tenant, row-level security and per-tenant encryption keys. | The hospital owns and pays for the cloud project; Pensieve deploys and operates inside it under a delegated-access agreement. | Deployed on hardware inside the hospital's own server room or private datacentre. |
| Controller and processor postureWho is the Data Fiduciary and who is the Data Processor | Hospital = Data Fiduciary; Pensieve = Data Processor | Hospital = Data Fiduciary; Pensieve = Data Processor | Hospital = Data Fiduciary and infrastructure owner; Pensieve = Data Processor with delegated administrative access | Hospital = Data Fiduciary and full custodian; Pensieve = supplier and support, limited or no data access |
| Cloud account ownerWhose name is on the account, and therefore who can revoke access unilaterally | Edsol Edtech | Edsol Edtech | Hospital | Hospital |
| Effect on the scheduleAgainst the 14-day target from 00-BRIEF Section 3 | Fastest to go-live. The default and recommended path. | Same schedule as DM-1. Tenant creation completes in minutes. | Adds days. Requires a separate Delegated Cloud Access & Administration Agreement. | The slowest and most expensive model. It breaks the 14-day target, and Pensieve's uptime SLA cannot apply to hardware it does not control. |
| Pensieve’s position | Recommended. Choose this unless you have a reason not to. | Supported and fully documented. Choose it where cost dominates and logical isolation is acceptable. | Supported. Choose it where a policy requires the hospital to own the cloud account. | Supported, and Pensieve will tell you before you sign that it costs months rather than weeks. |
The full treatment (architecture, control boundaries, network paths and the decision tree) is Deployment Models Explained. DM-2 isolation is logical, in four layers, and is documented separately in the multi-tenancy isolation disclosure. It is not equivalent to DM-1, and Pensieve Labs does not describe it as though it were.
Section 2
The six commitments a security reviewer actually tests. Each is written per model rather than as one vague clause that is true of none of them.
| Commitment | DM-1Dedicated | DM-2Shared | DM-3Customer Cloud | DM-4On-Premise |
|---|---|---|---|---|
| Security controlsWhich of the whitepaper's controls Pensieve can actually execute for you | The full control set is Pensieve's to execute: hardening, patching, detection, key management, privileged access and break-glass. | The same control set. Isolation is logical in four layers rather than physical, so the blast radius of an application flaw can reach more than one tenant. | The same control set, executed inside your project. Organisation policy, egress rules and network guardrails are yours, and you see every Pensieve action natively in your own logs. | Physical, environmental, network and endpoint security transfer to you. Pensieve specifies the requirement in the On-Premise Supplement and cannot enforce it on hardware it does not control. |
| Data residencyWhere the records physically sit | The Indian cloud region named on your Order Form. | The Indian cloud region named on your Order Form. | The region you select inside your own cloud project. | Your building. This is the only model that satisfies a requirement that data must not leave the campus, and you should choose it knowing what that costs. |
| Business continuity and disaster recovery | Pensieve's backups, Pensieve's restore drill, measured and recorded. The restore verification report is an artefact, not a claim. | As DM-1, on the shared platform's backup and restore schedule. | Pensieve configures and operates backup inside your project. You own the retention configuration and you pay for the storage. | Backup custody, media, off-site copy and restore testing are yours. Pensieve specifies the procedure; you execute it, and only you can prove it worked. |
| Incident response and breach notification | Pensieve detects, contains and notifies. The notification content commitment runs from Pensieve becoming aware, and it is a contract term rather than a statement of intent. | As DM-1. | As DM-1 for the platform. Detection on infrastructure you control, and the organisation-level response, are yours. | Pensieve cannot detect an incident on your infrastructure at all. You are accountable and responsible for detection as well as for notification; Pensieve supports with evidence and technical explanation. |
| RTO and RPO | Committed in the Service Level Agreement and measured against the restore drill. | Committed. | Committed, conditional on the factors you control: quota, network, your own change freezes. | No RTO or RPO commitment. Pensieve does not commit recovery objectives for infrastructure it does not control, and will not sign one. |
| Availability and support | Availability commitment with service credits, plus the support escalation matrix. | Availability commitment with service credits. | Availability commitment, conditional on hospital-controlled factors, with the same escalation matrix. | No availability commitment: response times only. Pensieve's uptime SLA cannot apply to hardware it does not control, and no clause can make it. |
Each row is a summary of a document, not a substitute for one. The residency position per market is the Data Residency Statement; backup and recovery is DIS-GL-014; the notification commitment is DIS-GL-016; the availability and capacity position is DIS-GL-030; and the remote access and support model is DIS-GL-033.
Section 3
The single business objective is to compress first contact to cash and to production go-live to under 14 days. The deployment model is the largest single input to that number, which is why it is settled at qualification rather than at contracting.
| Model | Realistic time to go-live | Typical track | Why |
|---|---|---|---|
| DM-1Dedicated | 14 days or less | ExpressT2C 10d | T2G 14d | Project creation, service deployment and tenant configuration complete inside the mobilisation window. Nothing waits on a third party. |
| DM-2Shared | 14 days or less | ExpressT2C 10d | T2G 14d | Tenant creation completes in minutes on a platform that is already running. |
| DM-3Customer Cloud | Weeks: typically 30 to 45 days | StandardT2C 30d | T2G 45d | Adds the time your organisation takes to create a cloud account, agree the delegated-access arrangement, and obtain its own internal approvals. None of that is engineering work and none of it can be compressed by Pensieve. |
| DM-4On-Premise | Months: typically 60 to 90 days, often more | ComplexT2C 60d | T2G 90d | Adds hardware specification, procurement, delivery, room preparation, power and cooling, network provisioning and installation. This is the model that breaks the 14-day target, and the client-fit score penalises it for exactly that reason. |
Track targets are the register’s own: Express is 10 days to cash and 14 to go-live; Standard is 30 and 45; Complex is 60 and 90. The track is assigned at first contact and it sets the due date on every artefact downstream of it.
Section 4
It is worth being equally clear about what is identical in all four, because a reviewer whose model changes late should not have to re-do the evaluation.
One Pensieve Labs build. No cut-down on-premise edition, no premium hosted edition, no feature held back to sell an upgrade.
One Master Services Agreement, one Data Processing Agreement, one Service Level Agreement and one Order Form, with model-specific variations rather than four separate paper stacks.
The hospital is the Data Fiduciary and Edsol Edtech Pvt. Ltd. is the Data Processor in every model. In DM-4 the processor role is limited or no data access. It does not invert.
Pensieve Labs never owns hospital data, never sells it, and never trains models on it for anyone else, in any model.
The export commitment and the deletion process apply identically in all four. See exit and portability.
The hospital holds its own credentials and Pensieve Labs calls external systems as the hospital, in every model. See ABDM, NHCX and BYOK.
Section 5
DM-3 and DM-4 each require an instrument the hosted models do not. Both are published in full at the public tier so your advocate can read them before you choose, rather than discovering the negotiation after you have chosen.
You own and pay for the cloud project; Pensieve Labs deploys and operates inside it. That requires a written grant of administrative access, and the agreement sets out the IAM roles granted, the least-privilege scope of each, the break-glass procedure, the logging that is visible to you natively in your own project, and precisely what happens to Pensieve Labs’s access on termination. It is the price of being able to revoke a vendor structurally rather than contractually, and for some boards that is the right trade.
Accept the mutual NDA to request access to this tier. Your acceptance is recorded at once and protects both sides; an administrator then grants access, with a target of four business hours.Accept the mutual NDAWait: target 4 business hours
The supplement covers hardware specification, environmental requirements, physical security, backup custody, patching windows and the remote-access mechanism, and it states plainly that Pensieve Labs’s uptime SLA cannot apply to hardware it does not control. Read the limitations before the specification: they are the part that changes the decision.
Accept the mutual NDA to request access to this tier. Your acceptance is recorded at once and protects both sides; an administrator then grants access, with a target of four business hours.Accept the mutual NDAWait: target 4 business hours
A proof of value before a full commitment runs on DM-1 or DM-2 only, under the Pilot / Proof-of-Value Agreement, because a pilot that requires hardware procurement is not a pilot.
Section 6
Most of the register applies to all four models. These are the ones that do not: read the row for the model you are choosing, and ignore the rest.
379 artefacts apply | 1 written for this model alone
Accept the mutual NDA to request access to this tier. Your acceptance is recorded at once and protects both sides; an administrator then grants access, with a target of four business hours.Accept the mutual NDAWait: target 4 business hours
380 artefacts apply | 2 written for this model alone
Accept the mutual NDA to request access to this tier. Your acceptance is recorded at once and protects both sides; an administrator then grants access, with a target of four business hours.Accept the mutual NDAWait: target 4 business hours
Accept the mutual NDA to request access to this tier. Your acceptance is recorded at once and protects both sides; an administrator then grants access, with a target of four business hours.Accept the mutual NDAWait: target 4 business hours
379 artefacts apply | 1 written for this model alone
Accept the mutual NDA to request access to this tier. Your acceptance is recorded at once and protects both sides; an administrator then grants access, with a target of four business hours.Accept the mutual NDAWait: target 4 business hours
379 artefacts apply | 1 written for this model alone
Accept the mutual NDA to request access to this tier. Your acceptance is recorded at once and protects both sides; an administrator then grants access, with a target of four business hours.Accept the mutual NDAWait: target 4 business hours
Section 7
The model is recorded on the Order Form and it can be changed. Moving between DM-1 and DM-2 is a migration Pensieve Labs runs. Moving to DM-3 requires you to stand up a cloud project and execute the delegated-access agreement. Moving to DM-4 requires hardware, and the timeline for that move is the same timeline as choosing it at the start.
The honest advice is the same as the recommendation: most hospitals of 50 to 200 beds should choose DM-1. Choose DM-3 if your organisation has a genuine policy requiring it to own the cloud account and has people who can operate one. Choose DM-4 only if you cannot use public cloud at all, and accept, before you start, that you are choosing a timeline measured in months rather than weeks.
The deployment model decides most of what a security review will ask about next.