[ 00 ]Documentation

There is no public docs site. Here is what there is instead.

Praxa’s full technical documentation is provided to customers and design partners during onboarding, scoped to the deployment model and the workflows they are actually running. It is not published on the open web.

That is a deliberate choice, not a gap we are hiding. Praxa is not a self-serve product: there is no public API to sign up for, no sandbox key, and no integration a developer can complete without us in the room. Documentation written for a reader we have never met would describe a product nobody can buy that way.

This page tells you honestly what material exists, what state each piece is in, and which of our public pages already answers the question you probably arrived with.

[ 01 ]What exists today

Five documents, in three honest states.

The technical documentation package is a set of five documents. Two are written and reviewed and go out on request under a mutual NDA. The rest are in progress, and we would rather name them and tell you their state than list five titles as though they were all finished.

Nothing below is a link, because none of it is hosted publicly. Ask for what you need and say who will be reading it — a CISO, an integration engineer, and a compliance reviewer get different documents, and sending all five to all three wastes everyone’s week.

Package: 5 documents — scoped per reader
Access: On request — mutual NDA for the security set
Format: PDF — plus a walkthrough call if useful
Public API reference: Does not exist
Self-serve sandbox: Does not exist
Versioning: Not yet published — documents are dated, not numbered

Doc 01

Integration overview

Available on request

How a Praxa operator connects to the systems a health system already runs: the integration methods in order of preference, what each one needs from your team, and what happens when a system of record has no usable interface at all. Written for an integration engineer and an application owner reading it together.

The public summary of the same material is on the platform page.

Read the public version

Doc 02

Security architecture

Available on request

The trust boundary in detail: where the operator runs, what crosses the perimeter and what never does, how credentials are issued and revoked, the access model, and how protected health information is handled in each deployment model. This is the document a security reviewer should start with, and it goes out under a mutual NDA.

Most of its substance is already public, at length, on the security page.

Read the public version

Doc 03

Deployment guide

In progress

Environment prerequisites, network requirements, the install and upgrade path, and rollback procedure for each supported deployment model. It exists as working notes we walk design partners through on a call; it is not yet a document we would hand to an infrastructure team and leave them with.

Until it is finished, deployment is scoped live with your team rather than read off a page. The public overview of the models is on the platform page.

Deployment models

Doc 04

Audit-record schema

In progress

The formal field-level specification for the record an operator writes for every action: what is captured, what each field means, retention, export format, and how a record is verified after the fact. The record itself is in production; the specification document that a compliance team can review independently is still being written.

The security page describes the record’s contents and properties in prose today.

What a record contains

Doc 05

Operator configuration reference

In progress

How a workflow is defined and tuned: the configuration surface, confidence thresholds and how they are raised, exception routing, escalation rules, and the review queue behaviour. This changes as the product does, which is exactly why we will not publish a reference that would be wrong within a quarter.

Configuration is currently done with a Praxa engineer rather than from a document. How autonomy is granted is described publicly on the platform page.

Confidence and autonomy

Absent · Do not go looking

Things a docs page usually has that this one does not.

A public REST or GraphQL API reference. Praxa does not expose a public API, so there is no endpoint list, no request and response examples, and no authentication guide to publish.
Client libraries or SDKs. None have been released under the Praxa name. If you find a package claiming to be one, it is not ours — please tell us.
A quickstart, a free tier, or a sandbox key. Every deployment is scoped with our engineers; there is nothing to self-provision.
Version numbers and a changelog. The documents are dated rather than versioned, and we will not invent a version history to look more mature than we are.
A status page or uptime history. There is no public multi-tenant service to report the status of; operators run inside customer environments.

[ 02 ]Start here instead

The pages that are live, sorted by what you came for.

These are not marketing summaries standing in for documentation. The security page in particular runs to the trust boundary, the data handling rules, the audit record, and the compliance posture including the attestations we do not hold.

Route 01How an operator worksThe full execution model, stage by stage: how a document is read, how a multi-step process is carried out across systems of record, where a human sits in the loop, and what happens on an exception./platform Route 02Integration methodsWhat Praxa connects to and how, including the honest answer to the question most integration engineers arrive with: how this works when the system of record has no API behind it at all./platform#integrations Route 03Security architectureThe long version, written for the review you are about to run: trust boundary, PHI residency, credentials and access, the audit record, deployment trade-offs, and the compliance posture as it actually stands./security Route 04Trust centerWhat is in the review package we send a security team, what we can share before an NDA and what we cannot, and how to start a vendor review without waiting on a sales cycle./security#trust-center Route 05Engineering writingWhere we write up the parts of this problem that do not fit on a product page — extraction on genuinely bad documents, evaluation harnesses, and decisions we got wrong./blog

If you read all five and your question is still unanswered, that is useful signal about our public writing. Send us the question and we will either answer it directly or publish the answer.

[ 03 ]Request access

Ask for the package.

Email us with the documents you want, who will be reading them, and what decision you are trying to make. The security set goes out under a mutual NDA; the integration overview does not need one.

Tell us if a walkthrough call would be more useful than a PDF. For the two documents still in progress, we will say so plainly rather than sending you a draft and calling it a guide.

Request the documentation Start a security review

Deliberately not stated here: a turnaround time. We are small enough that a published figure would be a guess. Say in your email when you need it by and we will tell you honestly whether we can meet that.

01Integration overview — no NDA required
02Security architecture — mutual NDA
03Deployment guide — in progress, walkthrough call instead
04Audit-record schema — in progress, prose version public
05Operator configuration reference — in progress, scoped live
06Technical questions — Support