We do not only test whether the happy path works. We try to break the safety boundaries.
The Cross-Jurisdiction Red Team tests defined safety invariants under injected faults. The result is evidence of tested contract behavior, not proof of a perfect or clinically validated system.
New Clinical Revenue suites remain separated by evidence class.
The 12-scenario suite is not presented as full database-persistence proof. The 15-scenario Full Pipeline Re-Test represents the stronger end-to-end/persistence evidence class. This separation prevents evidence inflation.
We do not test because people should work perfectly. We test because systems must survive faults, races and failure.
Healthcare is not a lab. Requests arrive twice. Credentials change. A process can crash mid-commit. Two transfers can compete. The Red Team intentionally creates these uncomfortable situations before they surprise a real care workflow.
40/40 PASS in the reported Pure-Logic run.
22 DACH scenarios, 18 North America scenarios, 15 fault-injection classes. Reported runtime: 374 ms.
Race Conditions
Competing transfers must not both commit.
Credential Revocation
Authority change must stop stale execution.
Rule / Order Change
Bound versions must not silently survive.
Crash / Recovery
Partial transfer must not appear COMMITTED.
Two transfers start from the same state.
Two transfers start from the same state.
Both attempt to commit different target contexts.
CAS/concurrency guard allows at most one commit.
The competing path receives conflict instead of creating a second reality.
What 40/40 explicitly does not mean.
Being clear about limits is part of trust.
Not clinical validation
The tests do not prove clinical effectiveness.
Not certification
PASS is not MDR, AI Act, HIPAA or other certification.
Pure Logic
Real database/network concurrency is an additional test layer.
No perfection claim
Tested invariants are a scope, not all of reality.
Frequently asked questions
What was tested?
Competing transfers, credential revocation, rule/order changes, crash states, reconciliation, client manipulation and idempotency, among other scenarios.
Why publish test limits?
Because credible technical communication must separate implemented behavior, test scope, clinical validation and regulatory conformity.
