Openness is a tool, not a religion
Security engineers draw this line with a simple idea: opening code should shrink your attack surface, never hand attackers a map. So we open everything that makes Trust and Interoperability stronger: client SDKs, healthcare-standard adapters, protocol implementations, the rails everyone benefits from auditing.
And we keep closed the small set of components where publication itself is the vulnerability:
- Safety and Triage internals. The exact thresholds and signals behind Crisis escalation. Published in full, they become an evasion manual for the very system that protects a vulnerable Person on their worst night.
- Anti-Fraud logic. Insurance abuse drains Care from the People it was funded for, and a fraud model loses most of its power the day its rules are published.
- Verification pipelines. The operational details of how we confirm a Practitioner against the Official Records. Publishing the checklist would tell an impersonator exactly what to fake.
- Certain commercial integrations. Kept closed where a Partner's contract requires it, and nothing beyond that.
The test we apply
Every component faces the same question: does opening this make People safer, or does it make attacking them easier? Trust wins ties. Safety wins everything.
Held accountable anyway
Closed does not mean unaccountable. These components sit behind hardened boundaries, follow published security standards, and are built to stay in scope for independent security testing. Regulators and auditing Partners can inspect what the public cannot.
The rule we run on: Open where openness protects you, Closed where openness would expose you, and honest about which is which.
