What runs today, and what is direction.
Three statements are kept distinct on this page: built, verified in a particular deployment, and available to outside developers. The table is the first. Which release you would build on, and what it exposes, is a conversation.
| Capability | Built | Direction |
|---|---|---|
| Clinical contract | The shape of the record and the actions allowed on it, declared in writing and loaded by the platform at startup. | Publishing the contract as a versioned package for outside developers. |
| Workflow actions | Booking, tasks, referrals, medication changes, billing, note sections, demographic change review, terminology. | A review step for agent proposals; delegation of individual actions. |
| Decision support | An incremental rule engine that keeps thousands of rules evaluated as the record changes, serving suggestions to the clinical application with the previous engine as a fallback. | The sentence-style rule editor; retiring the previous engine. |
| Live updates | Updates on a patient, task or appointment, delivered consistently. | Re-checking permissions on every update. |
| Collaborative notes | Shared editing with history and live updates; structured sections with a stated basis. | One permission path shared with the rest of the platform. |
| Permissions | Standard, scoped permissions on the clinical interface; a responsible clinician named on every non-patient change. | Bounded delegation, so an agent's authority is a subset of its principal's. |
| Accountability | Every version kept; clinician attribution on changes. | A uniform record of reads, changes and agent actions. |
| Openness of the source | The core server is open source. Breeze's own clinical definitions are not yet released. | An explicit scope for wider release and for operating the platform independently. |
What open means here.
Openness at three levels: documented access to data and workflow capabilities; the ability to extend or replace services and to choose who provides the AI; and inspectable software with a viable path to operating the platform independently. An interface alone does not fulfil that. What is released, under which terms, and what it takes to run are stated explicitly for each offering, and where they are not yet settled this page says so.
Three statements, kept apart.
Built means implemented in the platform's source and covered by its tests, and that is what the table on this page records. Verified in a deployment means exercised in a particular installation with its connections, credentials and configuration; a laboratory connection is built once but verified per practice. Available to outside developers means published with a contract, onboarding and terms, which no capability on this site is yet.
Numbers are handled the same way. The contract declares a certain number of record types and actions; a deployment publishes the number it actually loaded, which is what a caller should read. A count of declarations is never quoted here as a count of available endpoints.
What is not yet modular.
Three things the platform depends on are real but not yet cleanly separated. One policy path: permissions are enforced on the clinical interface, and collaborative notes have their own path; the direction is one policy for every surface, including delegation to agents. An attachable audit service: history and attribution exist and some parts emit audit records; the uniform service does not exist yet. Declared packaging: a deployment is assembled by hand rather than described as a reviewable bill of services and modules.
Source and licensing today.
The FHIR server at the center of the platform is open source under a permissive licence. Breeze's own clinical definitions, the contract described on the architecture page, are proprietary at present. The complete platform is not yet offered as an independently deployable package, and publishing the contract as a versioned package for outside developers is direction. When those things change, this page will say so in the same terms.
How to read a demonstration.
Ask three questions. Which release is being shown? Which connections are live in it, and which are stubs? Which of the workflows you care about are built, and which are direction? The honest answers are the ones this site is written to give, and a demonstration should give them the same way.