Documentation
How the register works
Every document on this site is one row of a single register: 491 artefacts, 12,07,999 words, each classified on five independent axes, each with an owner, a version, a review date and a place in the lifecycle. This page documents that system, so that a reviewer can read a badge on any page of this site and know exactly what it asserts.
Register compiled 01 August 2026. Every figure below is counted from the register at the moment this page was rendered. None of them is typed by hand.
01
What the register is
A trust centre usually publishes a curated selection: a whitepaper, a policy or two, and a form to request the rest. This one publishes the register: the complete, classified index of every formal artefact that exists between Pensieve and a hospital customer, from first contact to final offboarding, including the ones you cannot open and the ones that do not exist yet.
That has a specific commercial purpose. The single objective of this system is to compress the elapsed time from first contact to money in the bank and to production go-live to under fourteen days. Engineering can deploy a 200-bed hospital in about a week; the bottleneck is paperwork. An artefact that already exists, already classified and already retrievable, cannot be the thing that costs a day.
So the register is designed to be read by a machine and by a reviewer at the same time. Five axes, no collapsing. A document is simultaneously a kind, a tier, a direction, a lifecycle position and a state, and the interface never merges two of them into one badge to save space.
02
The five axes
SPEC-001 Section B.1 fixes five independent axes. They are independent in the strict sense: no value on one axis implies a value on another. A contract can be public or client-only; a disclosure can be bilateral or internal; a form can sit in stage 2 or stage 13.
| Axis | Question it answers | Values |
|---|---|---|
| 1: Kind | What shape of thing it is. | 15 |
| 2: Tier | Who may see it, and what clearing the gate costs in elapsed time. | 5 |
| 3: Direction | Who produces it and who consumes it. | 5 |
| 4: Lifecycle | Which stage of the deal first needs it, and whether it recurs. | 14 |
| 5: State | Where this particular instance is in its own life. | 11 |
Axis 1: Kind
Kind decides how a document is rendered, whether it is printable, which letterhead it takes and whether it can be signed at all.
| Code | Kind | Definition | Signed by | Count |
|---|---|---|---|---|
| K_CONTRACT | Contract | Binding bilateral instrument: MSA, DPA, SLA, NDA, order form, addendum. | Both parties | 39 |
| K_POLICY | Policy | A governing rule Pensieve holds itself to, published as evidence that it exists. | None | 85 |
| K_DISCLOSURE | Disclosure | A factual statement about how Pensieve is built and run: architecture, residency, encryption, sub-processors. | None | 49 |
| K_STATEMENT | Statement | A positive assertion Pensieve signs in its own name. | Pensieve only | 41 |
| K_REPORT | Report | The point-in-time output of an activity: a test, an assessment, a baseline. Its currency is its own date, not its upload date. | Countersigned | 17 |
| K_FORM | Form | A structured artefact somebody fills in, usually the hospital. | Sometimes | 56 |
| K_CHECKLIST | Checklist | An ordered verification list with a pass or fail on every line. | Sign-off line | 41 |
| K_RUNBOOK | Runbook | A step-by-step operational procedure with an owner and a duration per step. | None | 33 |
| K_QUESTIONNAIRE | Questionnaire | A question-and-answer instrument: CAIQ, SIG Lite, a hospital's own security set. | None | 5 |
| K_TEMPLATE | Template | A skeleton that generates a document instance bound to a client and a deal. | n/a | 6 |
| K_NOTICE | Notice | A time-bound communication: breach, change, termination. | Pensieve | 32 |
| K_FINANCE | Finance | A finance instrument: proforma, tax invoice, credit note, receipt, schedule, mandate. | Statutory format | 22 |
| K_REGISTER | Register | A living list maintained over time: sub-processors, assets, risks, incidents. Published as an as-at snapshot. | None | 46 |
| K_WHITEPAPER | Whitepaper | Long-form explanatory technical content. | None | 4 |
| K_CERTIFICATE | Certificate | A ceremonial artefact marking a milestone: go-live, hypercare exit, deletion. | Both parties | 15 |
Axis 3: Direction
Direction is the axis that predicts schedule risk. Everything Pensieve produces, Pensieve controls. Everything the hospital produces is a dependency Pensieve cannot control, so those artefacts are minimised, bundled into a single Hospital Input Pack issued at stage 2 rather than dribbled out over weeks, pre-filled wherever a value can be inferred, and tracked with per-item ageing.
| Code | Direction | Meaning | Count |
|---|---|---|---|
| D_P2H | Pensieve → Hospital | Pensieve produces it; the hospital reads or signs it. | 223 |
| D_H2P | Hospital → Pensieve | The hospital produces or fills it; Pensieve consumes it. | 43 |
| D_MUTUAL | Bilateral | Both parties execute it: contracts, certificates, sign-offs. | 100 |
| D_INTERNAL | Internal | Pensieve-only. It never leaves. | 110 |
| D_P2X | Pensieve → Third party | Pensieve to a third party: a regulator, auditor, insurer, bank or registrar. | 15 |
Axis 4: Lifecycle stage
Fourteen stages, sequential in dependency and deliberately not sequential in wall-clock time. Fourteen days is only reachable by running the stages in parallel swim-lanes, so several stages are in progress at once. Every stage has a named exit gate, because a stage with no gate has no measurable cycle time and therefore cannot be compressed.
| # | Stage | Clock | Target day | Exit gate | Artefacts |
|---|---|---|---|---|---|
| 0 | Always-ReadyS0_READY | None | None | Standing library complete and in-date | 62 |
| 1 | First Contact & QualificationS1_CONTACT | T2C, T2G | Day 0 to 1 | Fit score computed; track assigned | 34 |
| 2 | Discovery & Mutual AccessS2_DISCOVERY | T2C, T2G | Day 1 to 3 | NDA executed; access granted; Intake Pack issued | 47 |
| 3 | Evaluation & AssuranceS3_ASSURANCE | T2C | Day 2 to 6 | Security review closed; no open blockers | 145 |
| 4 | Commercial ProposalS4_PROPOSAL | T2C | Day 3 to 7 | Proposal accepted in principle | 7 |
| 5 | Contracting & ExecutionS5_CONTRACT | T2C | Day 5 to 9 | MSA + DPA + SLA + Order Form executed and stamped | 52 |
| 6 | Invoice & CollectionS6_CASH | T2C | Day 6 to 12 | Funds credited | 16 |
| 7 | Mobilisation & ConfigurationS7_MOBILISE | T2G | Day 2 to 9 | Input Pack complete; environment provisioned | 29 |
| 8 | Deployment & IntegrationS8_DEPLOY | T2G | Day 7 to 12 | UAT signed off; cutover approved | 14 |
| 9 | Go-LiveS9_GOLIVE | T2G | Day 12 to 14 | Production cutover certificate signed | 7 |
| 10 | HypercareS10_HYPERCARE | None | Day 14 to 30 | Hypercare exit certificate signed | 6 |
| 11 | Steady State & Value RealisationS11_STEADY | None | None | Quarterly value statement accepted | 43 |
| 12 | Renewal / ExpansionS12_RENEW | None | None | Renewal order form executed | 6 |
| 13 | Offboarding & ExitS13_EXIT | None | None | Data returned, deleted, certified | 23 |
The seven lanes
Stages are the dependency graph; execution runs in seven concurrent lanes. Every artefact is tagged with exactly one lane, which is what makes it possible to say who is blocked and on what without reading anything.
| Lane | Owns | Artefacts |
|---|---|---|
| CommercialLN_COMM | Qualification, proposal, pricing, negotiation, order form | 52 |
| LegalLN_LEGAL | NDA, MSA, DPA, SLA, addenda, stamping, execution, escrow | 90 |
| AssuranceLN_TRUST | Security, privacy, architecture disclosure, questionnaires, evidence | 184 |
| Data & ConfigLN_DATA | Hospital input pack, masters, migration, tariffs, users | 43 |
| InfrastructureLN_INFRA | Provisioning, deployment, integrations, credentials, cutover | 46 |
| EnablementLN_ENABLE | Training, SOPs, super-users, floor support, hypercare | 13 |
| FinanceLN_FIN | Invoicing, tax, collection, mandates, value measurement | 63 |
03
Axis 2: the tier ladder
Tier is the axis a visitor feels. Pensieve is unknown and has to buy credibility, so the default is public and a higher tier has to be justified rather than assumed. Every gate costs days, and the ladder is designed so that the only gate involving a human being is the one that provisions a workspace, never one in front of a document a prospect needs during evaluation.
| Tier | Who sees it | Gate | Latency | Artefacts |
|---|---|---|---|---|
| PublicT_PUBLIC | Anyone. No account, no form, indexable by search engines. | None | Zero | 108 |
| EmailT_EMAIL | Anyone who supplies a work email address. | Give a work email | Zero: instant | 5 |
| NDAT_NDA | Anyone who accepts the mutual NDA and whose access request an administrator approves. | Accept the mutual NDA | Target 4 business hours | 128 |
| ClientT_CLIENT | Authenticated users of one specific hospital's workspace. | Sign in to your workspace | Target 4 business hours | 141 |
| InternalT_INTERNAL | Pensieve administrators, on a passkey. | Administrator access only | n/a | 109 |
Two rules that follow from the ladder
Locked is not hidden. A document you cannot open is still listed, with its title, its doc ID, its kind, its date and the exact reason it is closed. A reviewer who can see that the full VAPT report exists, and that an approved access request opens it, behaves differently from one who cannot see it at all. Only the internal tier is withheld from listings, and the count of 109 is published anyway, because concealing the count would be the same mistake in a smaller costume.
A padlock that does not explain itself costs a day. Every lock on this site names the gate, states the latency and links to the action that clears it. The one self-service gate, a work email, is instant and opens 5 documents. The mutual NDA is accepted in one click and recorded at once, and its 128 documents open once an administrator approves the request, with a target of four business hours.
04
Axis 5: states, and the freeze rule
The first four axes describe the artefact. The fifth describes one instance of it, bound to one hospital and one deal. A template has no state; the instance rendered from it does.
| State | Tokens resolve | May move to |
|---|---|---|
| DraftDRAFT | Live | Issued, Archived |
| IssuedISSUED | Frozen | Awaiting signature, Acknowledged, Returned for revision, Expired, Archived |
| Awaiting signaturePENDING_SIGNATURE | Frozen | Executed, Returned for revision, Expired |
| AcknowledgedACKNOWLEDGED | Frozen | Active, Superseded, Archived |
| Returned for revisionRETURNED | Frozen | Draft, Archived |
| ExecutedEXECUTED | Frozen | Active, Terminated, Superseded |
| ActiveACTIVE | Frozen | Superseded, Expired, Terminated |
| SupersededSUPERSEDED | Frozen | Archived |
| ExpiredEXPIRED | Frozen | Archived |
| TerminatedTERMINATED | Frozen | Archived |
| ArchivedARCHIVED | Frozen | Terminal. |
The freeze rule
Token resolution is live only in the DRAFT state. The instant a document is issued, sent, signed, executed or submitted, the system persists the rendered HTML, the resolved token snapshot as JSON, the template version and a content hash, and serves those persisted columns from then on.
The consequence is the one a hospital’s counsel cares about: changing Pensieve’s registered address in the admin console updates every draft and every future render, and alters nothing that is already issued or executed. The rule is enforced by a database trigger on the instance table, not by application code, so it holds even against a direct write.
Sub-states
Two kinds carry their own state machine in addition to the one above, because their real lifecycle is not a document lifecycle.
| Applies to | States |
|---|---|
| Forms and checklists | ASSIGNED → IN_PROGRESS → SUBMITTED → UNDER_REVIEW → ACCEPTED | RETURNED |
| Finance instruments | PROFORMA → RAISED → SENT → PART_PAID → PAID → RECONCILED | OVERDUE | WRITTEN_OFF | CREDITED |
05
The document ID scheme
Every artefact has one identifier. It is stable, it is never reused, and it is not recycled when a document is withdrawn: a superseded ID stays pointing at the superseded document so that a contract citing it in 2031 still resolves.
<FAMILY>-<JURISDICTION>-<SEQ>[-<VARIANT>] FAMILY 3 to 4 characters, from the fixed set below JURISDICTION GL | IN | AU | EU | DK | NO | AE SEQ three digits, allocated in order, never reused VARIANT DM1 | DM2 | DM3 | DM4: a deployment-model-specific variant MSA-IN-001 Master Services Agreement, India master, first in sequence DPA-GL-001 Data Processing Agreement, global, first in sequence RBK-GL-003 Runbook, global, third in sequence
Family prefixes
| Prefix | Meaning | In register |
|---|---|---|
| POL | Policy | 92 |
| FRM | Form | 55 |
| DIS | Disclosure | 47 |
| REG | Register | 44 |
| CHK | Checklist | 41 |
| STM | Statement or attestation | 35 |
| RBK | Runbook | 32 |
| NTC | Notice | 29 |
| FIN | Finance instrument | 28 |
| ADD | Addendum | 24 |
| REP | Report | 17 |
| CRT | Certificate | 15 |
| WPR | Whitepaper | 6 |
| QRE | Questionnaire | 5 |
| DPA | Data processing agreement | 4 |
| MSA | Master agreement | 4 |
| PLY | Playbook | 4 |
| NDA | Non-disclosure agreement | 3 |
| ORD | Order form / statement of work | 3 |
| INDEX | Non-conforming. Predates the scheme; internal only. | 2 |
| SLA | Service level agreement | 1 |
2 records do not conform to the scheme: INDEX-11, INDEX-14-AU. They are internal index records that predate it. They are counted here rather than tidied out of the total, because a register that quietly excludes its own exceptions is not a register.
Families: the shelf an artefact sits on
Separately from the ID prefix, every artefact belongs to one of fifteen numbered families. The prefix says what shape the document is; the family says what part of the relationship it governs.
| # | Family | Artefacts |
|---|---|---|
| 1 | Corporate & Entity | 40 |
| 2 | Legal & Contractual | 62 |
| 3 | Security, Privacy & Trust Disclosures | 96 |
| 4 | Assurance & Evidence | 37 |
| 5 | Client Assessment & Fit | 19 |
| 6 | Hospital Input Pack | 30 |
| 7 | Runbooks | 33 |
| 8 | Checklists | 27 |
| 9 | Finance Instruments | 28 |
| 10 | Certificates & Milestones | 15 |
| 11 | Notices | 26 |
| 12 | People, Labour & Internal Governance | 26 |
| 13 | Offboarding & Exit | 9 |
| 14 | Jurisdiction Variant Sets | 32 |
| 15 | Trust Center Meta | 11 |
Jurisdictions
GL is the global master. A national code means the substance genuinely differs in that jurisdiction: a different statute, a different regulator, a different invoicing format, not that the master was reprinted with a new flag on it.
| Code | Jurisdiction | Artefacts |
|---|---|---|
| GL | Global | 336 |
| IN | India | 105 |
| AU | Australia | 14 |
| EU | EU / EEA | 11 |
| DK | Denmark | 7 |
| NO | Norway | 8 |
| AE | United Arab Emirates | 10 |
06
Review and staleness
A trust centre full of documents dated two years ago destroys more trust than no trust centre at all. So every artefact carries a review date, the date is public, and the badge on the document tells the truth about its age whether or not that is flattering.
Review cadence
| Class of document | Cadence |
|---|---|
| Contracts and addenda | 12 months, and immediately on a relevant change in law |
| Security and privacy disclosures | 6 months |
| Policies | 12 months |
| Registers: sub-processors, risks, incidents, assets | Continuous, with a formal review every 3 months |
| Statements and attestations | 12 months, or earlier on any change in the fact stated |
| Reports: assessments, tests | Not reviewed. They are point-in-time and show their own age |
| Forms, checklists, runbooks | 12 months, and after any execution that revealed a defect |
| Whitepapers and notices | 12 months |
A review is a decision, recorded: no change required, revised, withdrawn with a successor named, or superseded. “Reviewed” without one of those four outcomes is not a review. A document is also reviewed immediately, regardless of cadence, on a change in law, a security incident engaging it, a sub-processor change, a deployment-model change, or a customer or auditor identifying an error in it.
What the badge shows, and when
| State | Window | What the public sees | Today |
|---|---|---|---|
| In date | More than 30 days before the review date | Last updated, and nothing else. | 491 |
| Review due soon | Within 30 days of the review date | Last updated, plus Review due. | 0 |
| Review overdue | Up to 90 days past the review date | Last updated, plus Review overdue. | 0 |
| Review badly overdue | More than 90 days past the review date | Last updated, plus Review badly overdue, and the true age, not a refreshed date. | 0 |
The two rules with no exceptions
The badge is never suppressed, and a date is never refreshed without a review. Touching a file to reset its date is falsification, not maintenance.
There is no waiver. A document that cannot be reviewed on time is either withdrawn or published overdue with its true age. The overdue list is published monthly in the update bulletin with the owner and the new date, and a month in which the list is empty says so. As of 01 August 2026 no document on this register is overdue for review.
Point-in-time reports are governed separately: an assessment, penetration test or attestation shows the date of the activity rather than the date it was uploaded, and where the activity is older than its stated validity period the document is marked expired and the replacement’s status is stated, including “not yet commissioned” where that is the fact.
07
What every artefact carries
Beyond the five axes, every row carries the attributes that make the register operational rather than decorative. These are the columns that answer “what is blocking this deal”, “what does this cost in stamp duty” and “which public page breaks if this changes”.
| Attribute | Purpose | In this register |
|---|---|---|
| doc_id | A stable identifier, never reused, never recycled after withdrawal. | 491 issued |
| version | Semantic version of the template. A redline is a version, not an edit. | 3 distinct versions in the corpus |
| printable | Whether it renders to a letterheaded, paginated PDF with page numbers. | 487 printable |
| requires_signature | None, Pensieve, hospital or both, and by which method. | 237 require a signature |
| requires_stamp | Whether stamp duty applies, and on what basis. Stamping is its own blocking step. | 10 require stamping |
| critical_path_to_cash | Whether the artefact directly gates the clock from first contact to funds credited. | 228 on the critical path |
| depends_on[] | The artefact-level dependency graph. This is what answers “what is actually blocking this deal”. | 4,272 declared dependencies |
| source_of_truth_for[] | Which marketing-site pages this artefact feeds. The marketing site consumes; it keeps no copy. | 369 artefacts feed a public page |
| retention_years | How long the executed instance is kept before archival or deletion. | 3, 5, 8, 10 years, by class |
| review_due_on | Drives the staleness badge. A document without one cannot be published. | 491 carry a review date |