01
Authority separation
Safety-critical rules should not depend solely on a generative model reproducing them correctly from memory.
Safety & architecture
Put deterministic safeguards around probabilistic AI.
CelestyxAI's target architecture separates safety-critical policy logic from language-model assistance. The design goal is not to make an LLM authoritative, but to constrain where it is useful and make the resulting workflow inspectable.
Target control stack
1 · Deterministic policy layerExplicit clinical and operational constraints remain authoritative.
2 · Bounded AI orchestrationModel assistance is scoped to defined tasks with structured inputs and outputs.
3 · Schema validationOutputs are checked against expected structure before downstream use.
4 · Professional reviewHuman validation remains part of the intended clinical workflow.
Design principles
Clinical AI should fail visibly, not silently.
02
Bounded generation
Use LLMs for narrow, explicit tasks and require outputs that conform to defined schemas.
03
Auditability
Track relevant model, prompt, policy, version and validation context so outputs can be reviewed after the fact.
04
Human override
Professionals must be able to correct or reject the system's proposed structure or synthesis.
05
Data minimization
Design around the minimum operational data required and align retention with the institutional use case.
06
Continuous evaluation
Model and workflow changes should trigger re-evaluation rather than assuming a one-time benchmark remains valid.
Interoperability
Structured exchange is part of the architecture, not an afterthought.
CelestyxAI is being designed with FHIR-oriented exchange in mind so intake data can eventually move through institutional systems in a structured and governed way. This is a target architecture direction, not a claim that a production FHIR integration is already deployed.
InputStructured + free-text clinical intake
PolicyVersioned deterministic constraints
AIConstrained transformation / synthesis
OutputSchema-validated structured result
ReviewProfessional validation and trace
ExchangeFHIR-oriented downstream integration
Threat model
Risks we explicitly design around.
Hallucination
Generated content may be fluent but unsupported. Critical constraints should therefore not live only inside the model.
Prompt injection
Untrusted text can attempt to alter model behaviour. Inputs, tools and model privileges must remain bounded.
Model drift
Model versions change. Performance assumptions must be version-specific and revalidated.
Workflow mismatch
A technically strong model can still be unsafe if inserted into the wrong clinical role or escalation pathway.
Automation bias
Interface design must not encourage clinicians to accept generated suggestions without appropriate review.
Incomplete traceability
Safety review becomes difficult when the policy, prompt, model and user action cannot be reconstructed.
Evidence