What enters the diagnostic, how failure modes are identified, how findings are validated, and where human judgment is still required.
This page explains TryPromptFlow's diagnostic approach at a conceptual level. It does not expose proprietary system prompts, internal reasoning chains, or model-selection logic. The purpose is to let users, evaluators, and researchers understand how the diagnosis works — and what it cannot do — without relying on black-box trust.
The user submits one of the following:
A single AI instruction — a system prompt, a user message template, or a reusable instruction pattern — submitted for quality diagnosis and repair.
A multi-step process description, checklist, or standard operating procedure — covering the steps, conditions, handoffs, and expected outputs in a human or AI-assisted workflow.
The instructions given to an AI agent — what it is allowed to do, what tools it can use, what approval gates exist, what success looks like, and what it should do when something fails.
A description of how multiple workflows connect — ownership assignments, system-of-record definitions, handoff conditions, and exception paths across teams or functions.
The diagnostic operates on the submitted artifact and the context the user provides. No external data sources are consulted unless the user supplies them. The scope of the diagnosis is bounded by what was submitted.
The diagnostic is grounded in the submitted artifact. TryPromptFlow does not assume facts about the user's system, team, or environment that were not provided. Where context is missing, the diagnostic identifies it as a gap — it does not fill it with assumptions.
Constraints stated by the user — regulatory requirements, system limitations, organizational rules — are carried through the diagnostic and reflected in the corrected artifact. If a constraint appears to conflict with a best practice, that conflict is flagged for human review rather than silently resolved.
Each diagnostic product applies a structured set of quality criteria to the submitted artifact:
Where TryPromptFlow applies multiple analytical passes to a diagnostic, each pass is designed to surface a different category of gap. One pass may focus on completeness and missing steps. Another may focus on edge cases and exception paths. A third may focus on constraint enforcement and risk.
Different AI models have different patterns of blind spots — one may identify the most likely failure path while another surfaces a less obvious but significant edge case. Using multiple perspectives, where they are applied, reduces the risk that a structural gap passes undetected. The result is synthesized into a single coherent diagnostic finding, not a set of conflicting opinions.
This page does not describe which models are used, in what order, or how conflicts between perspectives are resolved. That level of implementation detail is proprietary.
Findings are checked against the submitted artifact before they are included in the diagnostic output. A finding that is not supported by something in the submitted artifact — a missing step, an undefined condition, an unsafe assumption — is not included in the final output.
This grounding check reduces the risk of findings that do not apply to the user's actual situation. It does not guarantee that all findings are correct or complete. Human review is always required.
The corrected artifact is a rebuilt version of what the user submitted — a repaired prompt, a corrected SOP, a hardened agent instruction set — with the identified gaps addressed. Where the original artifact had an undefined failure path, the corrected version defines one. Where it had a vague instruction, the corrected version makes it specific.
The corrected artifact is a structured starting point for review, not a final production-ready document. It reflects the diagnostic findings applied to the submitted artifact. Human review, application of organizational context, and final approval are always the user's responsibility.
For longer-scope diagnostics (Workflow Doctor, Agentic Workflow Doctor, Workflow OS Doctor), the output may include supplemental artifacts:
A structured list of identified risks — their likelihood, potential impact, and recommended mitigation — derived from the diagnostic findings.
A mapping of who is responsible, accountable, consulted, and informed for each significant step or decision in the workflow — based on what was submitted and what gaps were found.
A phased sequence of recommended changes — highest-priority gaps first, sequenced to avoid creating new failures in adjacent workflows or systems.
Suggested measures for tracking whether the implemented changes have the intended effect — tied to the specific failure modes identified in the diagnostic.
TryPromptFlow supports human review — it does not replace it. Human judgment is required for:
TryPromptFlow does not:
No. The diagnostic approach is described here at a conceptual level. Internal system prompts, reasoning chains, and model-selection logic are proprietary and are not exposed in any public output.
Submissions are processed to produce the diagnostic output and are not used to train models. See the data handling policy for how submissions are processed, retained, and isolated.
Different AI models have different architectural patterns and training characteristics, which produce different patterns of blind spots. Using models from different families increases the chance that a gap one model overlooks will be caught by another. Asking the same model the same question twice tends to produce the same blind spots both times.
No. The corrected artifact is a structured starting point. It reflects the diagnostic findings applied to your submission, but it has not been reviewed for your specific operational context, compliance requirements, or edge cases specific to your environment. Human review is always required before production use.