Diagnostic definitions are reusable blueprints that capture a diagnostic's configuration and session structure. They are shared across all users (not tied to a specific owner) and can be instantiated into new diagnostics.
Creating a Diagnostic Definition
From the Diagnostic Definitions list in the sidebar, click New Definition. The definition editor has two views:
Form View
Provides structured fields:
- Name — A unique name for the definition (enforced at the database level).
- Description — Optional context about the definition's purpose.
- Domain — Optional category (e.g., "Cost Savings", "Quality Metrics").
- System Prompt — Instructions defining the AI's role and focus area.
- Tools — Which capabilities the AI has access to.
- Sessions — An ordered list of session definitions, each with:
- Name — Session name.
- Initial Request — The starting prompt for the session.
- Disposition Schema — Structured output schema for the session.
- Dependencies — References to other sessions in the definition (by name), with optional conditional logic on disposition values.
Markdown View
A full-text markdown editor for the definition. The format uses heading levels to structure the definition:
# Template: My Workflow
## Description
A description of the workflow.
## Domain
Risk Management
## System Prompt
You are assisting a healthcare data analyst.
## Tools
QUERY_DATABASE, GET_MEASURE_METADATA, SEARCH_DATA_MODEL, PROMOTE_FINDING
## Sessions
### First Session
- **Initial Request:** Investigate the data
- **Disposition Schema:**
- risk: HIGH | MEDIUM | LOW
### Second Session
- **Initial Request:** Dig into the high-risk cases
- **Dependencies:**
- First Session [risk = HIGH]
Use the Reformat button to clean up markdown formatting. Switching from Markdown to Form view will parse the markdown; errors are shown inline.
Capturing a Diagnostic as a Definition
On any diagnostic detail page, the owner can click Save as Definition to create a new diagnostic definition from the diagnostic's current configuration and sessions. Session dependencies (which use UUIDs internally) are converted to session names in the definition.
Creating a Diagnostic from a Definition
On the definition edit page, click Create Diagnostic. This creates a new diagnostic with the definition's configuration and sessions.
Validation
Diagnostic definitions are validated on save:
- Name is required and must be unique.
- Each session must have a name (no duplicates except against deleted definitions).
- Dependencies cannot self-reference.
- Upstream session names must exist in the definition.
- Conditional dependencies require the upstream session to have the referenced disposition schema key as an enum type, and the value must be in the allowed list.
- Circular dependencies are detected and rejected.
Explorer Personas
Any diagnostic definition can be added as an Explorer persona. In the definition list, each definition has a star icon — click it to add the definition as an Explorer persona. Click again to remove it. On the definition detail page, the same toggle is available as an Add as Persona / Remove Persona button.
The Analyst Assistant definition (in the Explorer domain) is the default persona and its star is always filled in. It cannot be removed.
Starred personas appear in the Persona dropdown on the Explorer page, allowing users to start chats with different AI configurations without creating a full diagnostic. Persona selections are stored per-user.
Access Control
- Authenticated users can view the diagnostic definition list and individual definitions.
- Architects (and above) can create, edit, delete definitions, create diagnostics from definitions, and capture diagnostics to definitions.