Four addresses, and a person behind each one.
Praxa is early and small. There is no ticket portal, no chatbot, and no tiered support desk between you and the engineers who wrote the thing you are asking about. Pick the right address below and you will reach someone who can actually answer.
This page also explains how support works during a design-partner engagement, how to report a security vulnerability, and answers the technical questions we get asked most — with links to the pages that cover them properly.
Where to write, and what each address is for.
Using the right one is not bureaucracy. A security report sent to the general inbox waits behind sales email, and a deployment question sent to press goes to someone who cannot answer it.
General enquiries
Anything that is not covered by the three addresses beside this one: a workflow you want to talk through, a design-partner conversation, a procurement question, an invoice, or a request for the technical documentation package.
hello@praxaai.aiTechnical and customer support
For people already running Praxa: a workflow behaving unexpectedly, a queue backing up, an exception you cannot interpret, an integration that stopped authenticating, or a configuration change you want made.
support@praxaai.aiSecurity disclosure
For reporting a suspected vulnerability in Praxa software, this website, or our infrastructure. Reports here reach a security engineer, not a marketing inbox. Please do not open a public issue or post details before we have replied.
security@praxaai.aiPress and media
For journalists and analysts: interview requests, fact checks, and company background. Approved boilerplate and brand guidance are already on the press page, so start there if that is all you need.
press@praxaai.aiNo response-time commitment is published on this page. Every address is monitored on business days across US time zones, and every message is read by a person. A specific figure — four hours, one business day, anything — would be a number nobody here is yet staffed to guarantee, and a support promise we cannot keep is worse than no promise at all. Contracted response commitments are agreed in writing with each customer, not published as marketing.
If you found something, we want to hear it.
Praxa runs inside health system environments, so a vulnerability in our software is a vulnerability in somebody’s clinical operations. We would rather hear about it from you, awkwardly and early, than from an incident.
Report to security@praxaai.ai. Include enough detail for us to reproduce the issue: the affected component or URL, the steps, what you observed, and what you think the impact is. If you have a proof of concept, attach it rather than describing it.
Please give us a reasonable window to investigate and fix before you publish. We will tell you where we have got to, and we will credit you in the fix notes if you want to be credited.
- Report to
- security@praxaai.ai
- Encryption
- PGP key not yet published — ask and we will arrange a secure channel
- Acknowledgement
- Sent by a security engineer — timing agreed in the first reply
- Bug bounty
- No paid programme — credit offered, no payment implied
- Public disclosure
- Coordinated with you
- Safe harbour
- Good-faith research — see the commitment below
Step 01 · Report
Email security@praxaai.ai with the component, the reproduction steps, and your assessment of impact. One report per issue. If the issue involves customer data you have inadvertently accessed, say so immediately and in the first line.
Step 02 · Acknowledge
A security engineer replies, confirms whether we can reproduce it, and tells you what happens next — including a realistic timeline rather than a template one. If we disagree that it is a vulnerability, we will explain why rather than closing silently.
Step 03 · Fix
We remediate, and where a customer environment is affected we notify the affected customers through their named contact. You get told when the fix ships.
Step 04 · Disclose
We agree the timing of any public write-up with you. We will not ask you to stay silent indefinitely, and we will not ask you to sign anything in order to report a bug.
In scope
- This website and any Praxa-operated subdomain.
- Praxa operator software and the operator console, in an environment you are authorised to test.
- Authentication, authorisation, and scoping flaws — including anything that would let one tenant or role see another’s data.
- Anything that would let an operator take an action outside its granted authority, or take one without writing an audit record.
- Exposed credentials, keys, or secrets belonging to Praxa, wherever you found them.
Out of scope, and please do not
- Testing against a customer environment, or any system you are not explicitly authorised to test.
- Accessing, downloading, altering, or retaining anyone’s data. Stop at the point you have demonstrated the issue.
- Denial of service, load testing, spam, or anything that degrades service for other people.
- Social engineering of our staff, our customers, or our vendors, and physical access attempts.
- Third-party services we merely use, reported to us rather than to them.
- Scanner output with no demonstrated impact, missing best-practice headers with no exploit path, and reports that arrive with an invoice attached.
Our good-faith commitment. If you research in good faith, stay inside the scope above, avoid privacy violations and service degradation, and give us a chance to respond before publishing, we will not pursue or support legal action against you, and we will not ask your employer to. We will treat your report as a security matter rather than a public relations one. What we are not promising: a payment, a fixed acknowledgement time, or a bounty tier. There is no paid programme today, and we will not imply one to attract reports we cannot compensate.
Support is the same engineers who built it.
Praxa is forward-deployed, which changes what support means. There is no handoff from an implementation team to a support team, because there is no support team to hand off to. The engineer who built your workflow is the engineer who answers when it misbehaves.
That is an advantage while we are this size — nobody has to be briefed, nobody escalates a question they cannot answer — and it is also a constraint we are honest about. We can only run a small number of engagements at this level of attention, which is exactly why the 2026 design-partner cohort is small.
Current stage · Design partners
Described below is how support works in a design-partner engagement today. It is not a published support policy, it does not override anything agreed in your contract, and it will change as we grow. Where the two differ, your agreement wins.
- 01A named engineer who knows your workflow, not a rotating queue
- 02A shared channel with your team, for the small things
- 03Email to support@praxaai.ai for anything that needs a record
- 04A standing weekly call for the duration of the engagement
- 05Escalation to a founder, named in your onboarding pack
- 06Response commitments agreed in writing, not published here
Named contact
Every engagement has a named Praxa engineer who built or co-built the workflows you are running, plus a named backup so you are never waiting on one person’s calendar. Both names, and how to reach them, are in your onboarding pack rather than buried in a portal.
Shared channel
We set up a shared channel with your team for the day-to-day: an exception nobody recognises, a payer that changed a form, a question that is faster asked than written up. No protected health information in the channel — reference the case by its identifier in your own system and we will look at the record on your side of the boundary.
Written record
Anything that needs a trail — a defect, a configuration change, an accuracy question, a request to raise an autonomy threshold — goes to support@praxaai.ai so there is a record that survives the channel scrollback and can be referenced in a review.
Escalation path
If a live queue is affected and the named engineer is not responding, escalate to the founder named in your onboarding pack. It is a short path on purpose. Using it is not a complaint about anyone, and we would much rather you used it early.
Suspending an operator
You do not need us to stop a workflow. Autonomy is granted through credentials your team issues, so revoking access stops the operator immediately and without a support ticket. Tell us afterwards and we will work out what happened together.
How access is grantedReviews and reporting
Accuracy, volume, and exception rates for each workflow are reported to you on a regular cadence, measured on your documents and your queue rather than on a benchmark. We bring the numbers whether or not they flatter us.
Six questions, answered short, with the long version linked.
These are the ones that come up in nearly every first conversation. Each answer is the summary; the page behind it is the version to send to your security or integration reviewer.
Q 01
Where do the operators actually run?
Inside your environment. Praxa deploys on your side of the trust boundary in customer-hosted models — your virtual private cloud or on-premise — rather than as a multi-tenant service you send data to. That is also why there is no public status page to point you at: there is no shared service whose status would be meaningful.
Trust boundary in fullQ 02
Does protected health information leave our environment?
No. In both customer-hosted deployment models, protected health information stays inside your perimeter. Praxa does not train a shared model on your data. The security page sets out exactly what does cross the boundary and what never does, which is the detail a reviewer will want rather than this one-line assurance.
How data is handledQ 03
How does an operator get permission to act on its own?
It earns it, one workflow at a time. A new workflow starts with a human reviewing every item. Confidence thresholds then let routine cases through as measured accuracy justifies it — never as a launch setting, never across the board, and never for anything irreversible without a reviewed history behind it.
The authority itself is yours to grant and revoke: the operator acts under credentials your team issues, scopes, and can withdraw at any time.
The autonomy ladderQ 04
What is actually in an audit record?
Every read, every write, and every decision an operator makes is recorded as an attributable, replayable record — per action, not per session. It is designed to answer the question a compliance officer eventually asks: what exactly did it do, on whose record, and on whose authority.
The field-level specification document is still being written. The security page describes the record’s contents and properties in full prose today, which is enough for most reviews.
What a record containsQ 05
One of our systems has no API. Does this still work?
Yes, and this is the normal case rather than the exception. Much of this work arrives as a scanned PDF, a fax, an HL7 message, or a portal screen with nothing behind it. Praxa prefers a real interface where one exists and works the surface a person would use where one does not — under your credentials, with the same audit record either way.
Integration methodsQ 06
Will an operator ever make a clinical decision?
No, and this is a product constraint rather than a disclaimer. Praxa does not diagnose, triage, or make clinical decisions. It moves information and carries out administrative steps that a qualified person has already decided should happen. Keeping that line bright is what makes the rest of it safe to deploy.
Why we hold that lineIf your question is not here, it is probably answered at length on the platform or security page — both are written for a technical reader rather than a buyer. If it is not on either, ask us and we will answer it, then add it here.
Just write to us.
If you cannot tell which address you need, use the general one and we will route it internally. That is our job, not yours. Tell us what you are trying to do and, if it is time-sensitive, when you need an answer by.
- 01Security reviews and the trust package — Trust center
- 02Technical documentation package — Documentation
- 03Media, boilerplate, and brand assets — Press
- 04Working here rather than writing to us — Careers