Protocol Feasibility

Protocol feasibility is a queue-backed AI workflow used as guided decision support, not as a raw background job.

The product treats feasibility as a repeatable workflow tied to a trial and a specific tab or module. Generation, run tracking, and output retrieval are separate parts of the same process.

This screenshot is generated from the docs capture workflow so the page can use a durable asset rather than a transient browser artifact.

Who this is for

This page is for teams that use AI-assisted feasibility output to inform trial planning or challenge current assumptions in a specific trial module.

What teams need to understand

• feasibility output is generated by trial and tab or module
• feasibility runs can be listed and revisited after generation
• output retrieval is separate from generation itself
• queue availability and permissions affect the workflow

Where protocol feasibility fits

Protocol feasibility is decision support inside a governed workflow. It helps teams explore or stress-test parts of trial planning, but it is not an automatic decision-maker.

For most customers, the important message is that feasibility output is useful when it helps a team ask better questions, compare options, or prepare for discussion.

Typical protocol feasibility workflow

1. Start a feasibility run for a specific trial and workflow tab.
2. Wait for the queue-backed process to generate output.
3. Review available runs for that trial and tab.
4. Open the latest output, compare it to current understanding, and decide what to keep.
5. Use human review before turning feasibility output into an operational decision.

When to run feasibility again

Teams should consider a new run when:

• the underlying trial context has changed materially
• the relevant tab or workflow area has been updated
• the older output no longer reflects the current planning question
• a prior run produced something useful, but the team needs a refreshed viewpoint

Reviewing runs and output

Generation and interpretation are separate responsibilities.

Teams should be encouraged to:

• review multiple runs over time when the planning context changes
• compare output against current trial assumptions, not just accept the newest run
• capture disagreements or caveats before using the output in planning conversations

Operational expectations

Teams should know that:

• feasibility generation can fail or be unavailable if queue-backed services are not ready
• permissions still apply to generation and retrieval flows
• the same trial may have multiple runs over time for the same tab
• the best current output is something the team interprets, not something the system should apply automatically

Governance stance

Protocol feasibility belongs in the same customer guidance family as other AI-assisted workflows:

• generation is useful, but review is required
• permissions and service availability still shape the experience
• run history matters because planning context changes over time
• output should influence conversation and analysis, not silently rewrite the trial record

What teams should decide

• which trial modules are a good fit for feasibility runs
• when to generate a new run instead of relying on an older output
• how feasibility output will be captured, reviewed, and challenged internally
• which stakeholders need to see the result before it influences planning

Common customer misunderstandings to prevent

• a completed run is not the same thing as an approved recommendation
• the newest output is not automatically the best output
• output retrieval is part of the workflow, not just a background implementation detail
• queue-backed behavior means timing and availability are part of the user experience

Related pages

• AI Workflows
• Trial Design
• Actions And Runs

API reference

Use TrialStack API reference for the exact generate, list-runs, and output-retrieval contracts for protocol feasibility by trial and tab.