Sapphire runs where a mistake costs money, a survey finding, or a resident’s care. So every guarantee below is described as a mechanism — something that either is or is not in the code — rather than as a badge. The last section says plainly what we are not claiming yet.
Sign-in happens on your identity provider’s own page, over an authorization-code flow with PKCE. Sapphire receives a verified identity token back — never your credentials. There is no password field anywhere in the product.
Which applications, facilities and records you can reach is resolved at the data boundary, not by anything the browser is told. Knowing or typing a URL does not grant access, and a mistake in a screen does not become a disclosure.
Facility scope is part of the data model rather than a filter applied on the way out. Authorization remains active even when a screen or a service makes a mistake, which is why we describe the boundary as forced rather than applied.
Your session is held in a short-lived, HTTP-only cookie that page scripts cannot read, and it is cleared when you sign out. The browser holds a session reference, not your identity.
Modules that touch protected health information are marked as such in the registry, and access to them is granted deliberately rather than by default. A role that does not need clinical data does not receive it.
Missing policy or uncertain data produces a named unavailable state rather than a plausible number. Dates, currencies, sources and effective policy stay attached to every operating fact, so a figure can be traced back to what produced it.
Most vendor security pages are a list of logos. This one is shorter on purpose: a claim we cannot substantiate today is a claim we will not print.
We answer security and procurement reviews directly, including the questions where the honest answer is “not yet.”