An app is a user-facing UI surface within a project. Every app declares an audience at creation. Audience is not a configuration detail — it drives routing, permissions, authentication, and PHI policy for that surface.
Apps are distinct from projects (the container) and from workflows (the automation primitive). A project can have many apps. An app can participate in many workflows by emitting events that workflows listen to.
Creating an app
Describe the surface you want in chat:
“Add a patient intake form that patients can access without logging in.”
The system infers:
- Audience: Public (because “without logging in”)
- Path:
/intake (or proposes one if there’s a collision)
- Entities: Prompts for or creates a
patient entity
If the audience is non-obvious, the system states its inference: “I’ll make this a public app — accessible without login. Does that sound right?”
Audience taxonomy
| Audience | Requires login | PHI handling | Typical example |
|---|
| Public | No | Strict detection + redaction | Patient intake portal accessible by URL |
| Authenticated end-user | Yes (org identity provider) | Org-wide PHI policy | Patient self-service portal for existing patients |
| Role-gated | Yes + specific role | Org-wide PHI policy | Clinician triage Kanban; admin panel; billing workspace |
| Agent-callable | N/A — invoked by AgentCaller | PHI policy per delegation scope | Surface designed to be driven by a delegated agent |
| Internal-only | N/A — no UI exposure | Org-wide PHI policy | Headless utility surface, API-only |
App URLs
Apps are served at the org’s runtime subdomain:
acme.usehasp.run/intake ← Public app
acme.usehasp.run/portal ← Authenticated end-user app
acme.usehasp.run/triage ← Role-gated app (clinical staff)
What apps do
By default, an app has implicit CRUD access to the entities it’s associated with. You don’t need a workflow for an app that simply reads and writes entity records. Workflows are what apps add when behavior beyond CRUD is needed:
- Trigger on form submission — User submits an intake form → workflow fires
- Trigger on button click — User clicks “Approve” → workflow fires
- Trigger on page load — App opens → workflow fetches and enriches data
- Emit data-change events — User modifies a record → other workflows react
The live app center pane
When you’re working on a UI-backed app or its associated workflow, the center pane renders the live app. During authoring, the app runs against sandbox data. Once released, it runs against production.
This is not a preview mock — it is the actual deployed app running against real (sandbox) data. You interact with it the same way your users will.
The live app center pane renders real sandbox data. If your sandbox environment contains synthesized PHI for testing, PHI handling policy applies to those interactions. Do not paste real patient data into sandbox unless your organization’s sandbox PHI policy permits it.
Audience changes
You can change an app’s audience through chat at any time before release. Changing audience is a draft change — it becomes part of the project’s pending changeset and is included in the next release. Audience changes may have routing and permission consequences; the system surfaces these when they’re significant.
Custom composition
The system generates the initial app contract from your conversational description. You can refine it:
- Add fields — “Add a phone number field, optional.”
- Change layout — “Put the risk banner at the top of the form.”
- Add conditional sections — “Show the emergency contact section only if the patient is under 18.”
- Add role-gated actions — “Show the approve button only to staff with the clinician role.”
All changes go through chat. The app contract is compiled by the system; there is no visual editor for app layout or fields. 
