What a complete TryPromptFlow diagnostic package looks like — shown as a labeled illustrative example.
This page shows the structure and content of a TryPromptFlow diagnostic output. The scenario, findings, and corrected artifacts below are entirely fictional and created to illustrate what users receive. This is not a real customer result. The actual content of your diagnostic will reflect your specific workflow, prompt, or operating system.
Fictional scenario: Order Status Notification Workflow — a process in which customers are notified of order status changes by an AI-assisted system that updates a CRM, sends email notifications, and escalates failed deliveries to an operations team.
Product used in this scenario: Workflow Doctor (for human-facing and AI-assisted workflows).
Readiness verdict: REVIEW — The workflow contains three high-severity gaps that prevent safe autonomous operation. Two medium-severity gaps should be addressed before scaling to higher order volumes. No critical blockers prevent manual operation with existing human oversight.
Top findings:
Confidence note: This finding is based on the submitted workflow description. It does not account for implementation details, system constraints, or organizational context not provided in the submission. Human review is required before acting on these findings.
| # | Finding | Severity | Recommended fix |
|---|---|---|---|
| F-01 | No escalation owner for failed delivery queue | High | Name a specific role as the escalation owner; define the trigger condition and response time |
| F-02 | Unbounded notification retry | High | Add a retry limit (e.g. 3 attempts); define the escalation action when the limit is reached |
| F-03 | Non-atomic CRM update and notification send | High | Sequence CRM update before notification send; only send if update confirms success |
| F-04 | No duplicate-event detection | Medium | Add idempotency key to each order status event; deduplicate before processing |
| F-05 | Acceptance criteria for exception states missing | Medium | Add explicit acceptance criteria for failed, pending, and partial delivery states |
| F-06 | No monitoring for notification delivery rate | Low | Add a delivery-rate metric and alert threshold to the operations dashboard |
Before (submitted):
3. Send notification email to customer when order status changes.
After (corrected):
3. On order status change event: a. Check for duplicate: if this event ID was processed in the last 24 hours, skip and log. b. Update CRM record with new status. If update fails, log error and escalate to Operations queue — do not proceed to notification. c. Send notification email to customer. Retry up to 3 times on transient failure. d. If all retries fail, add to failed-notification queue and alert the Notification Owner role. e. Record delivery status in the CRM order record. Acceptance: CRM shows updated status AND customer receives notification OR failed-notification queue entry exists with alert sent.
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Customer receives duplicate notification | Medium | Customer confusion, support volume | Idempotency key on each event (F-04) |
| Failed delivery silently accumulates | High | Customer SLA breach, no visibility | Named escalation owner + alert (F-01) |
| CRM and notification state diverge | Medium | Incorrect customer record, support escalation | Sequence and confirm CRM update first (F-03) |
| Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Monitor notification queue | Operations | Operations Lead | Engineering | Customer Success |
| Escalate failed deliveries | Operations | Operations Lead | — | Customer Success |
| Resolve delivery failure | Engineering | Engineering Lead | Operations | Customer Success |
Phase 1 — Critical fixes (address before scaling):
Phase 2 — Hardening (address within 30 days):
Phase 3 — Observability (address within 60 days):
| Metric | Measures | Alert threshold |
|---|---|---|
| Notification delivery rate | % of triggered notifications successfully delivered | Below 98% in any 1-hour window |
| Failed-delivery queue depth | Number of unresolved failed-delivery items | Above 10 unresolved items |
| CRM-notification divergence rate | % of orders where CRM status and notification status disagree | Above 0.5% |
| Escalation response time | Time from alert to Operations team acknowledgement | Above 30 minutes |
Threshold values are illustrative and should be calibrated to your actual operational volume and SLA commitments.
No. The scenario, findings, and all data on this page are entirely fictional and created to show the structure of a TryPromptFlow diagnostic output. It does not represent any real customer, workflow, or result.
The sample above is structured around Workflow Doctor. Agentic Workflow Doctor and Workflow OS Doctor produce similar artifact sets but focus on different diagnostic criteria — pre-launch risk for agent workflows, and cross-functional operating system gaps, respectively.
Most TryPromptFlow diagnostics complete in under 10 minutes. The time depends on the length and complexity of the submitted workflow or instruction set.
No. Submit your workflow, SOP, prompt, or agent instructions in whatever format you have — plain text, a numbered list, a document excerpt. TryPromptFlow works from the structure of what you submit, not from a required template.