Workflow Playbooks

This page answers one question: where should Mighty go in a real product flow?

Use it like a menu. Pick the workflow that matches your app, then follow the scan plan.

The Pattern

Every workflow has the same shape:

untrusted material -> Mighty scan -> product route -> trusted next step

Mighty should run before material reaches:

• AI model context.
• OCR or extraction.
• Permanent storage.
• Search or indexing.
• Payment or approval.
• Agent tools.
• Human review queues.

Pick Your Workflow

Chat Apps

Goal: stop risky prompts before the model runs, then scan public output before users see it when strict output safety matters.

Scan plan:

Use Vercel AI SDK Chat Guardrail when this is a Next.js AI SDK route.

File Intake

Goal: stop suspicious uploads before storage, OCR, extraction, indexing, or automation trusts them.

Scan plan:

Use one scan_group_id for the original file and all derived scans from that file.

OCR And IDP

Goal: prevent hidden document instructions, OCR errors, and poisoned extracted text from becoming workflow facts.

Scan plan:

Common mistake: scanning only the extracted text. Scan the original file first when possible.

Damage Photo Review

Goal: flag suspicious image evidence before it drives a claim, repair, or payment decision.

Scan plan:

Say Mighty flagged suspicious evidence. Do not say Mighty proved fraud.

Invoice And Estimate Review

Goal: check invoices and repair estimates before approval, payment, or AI summarization.

Scan plan:

Use metadata such as workflow=invoice_review, vendor_id, claim_id, and invoice_id when available.

Agent Tool Review

Goal: keep unsafe tool output, retrieved documents, and browser content out of the next model step.

Scan plan:

Agents are multistep. Use one session_id for the agent run. Use scan groups for related prompt, retrieval, tool output, and final answer chains.

Batch Intake

Goal: scan many records or files without losing traceability.

Scan plan:

Common mistake: one scan_group_id for the whole batch. Use one group per item.

Human Review Queues

Goal: give reviewers enough context to decide what happens next.

Store:

Mighty routes risk. Your team makes the final business decision.

Default Routing

Three response fields drive workflow decisions, and each comes from a different part of the response.

action — the routing decision. Switch on this:

scan_status — async lifecycle. Only meaningful for mode=comprehensive + async=true:

authenticity.verdict — forensics finding on file content (image / PDF), distinct from routing:

AI-Agent Prompt

Choose the Mighty workflow for this product and implement it.

First identify the workflow:
- chat app
- public AI output
- file upload
- OCR or IDP
- damage photo review
- invoice or estimate review
- agent tool review
- batch intake
- human review queue

For each workflow:
- Put POST /v1/scan before the first trust boundary.
- Use scan_phase=input for submitted material.
- Use scan_phase=output for generated, extracted, summarized, or tool-created material.
- Choose content_type from text, image, pdf, document, or auto.
- Use mode=secure by default.
- Use mode=comprehensive and async=true for high-value image or PDF review.
- Use focus=both when AI will consume the material or authenticity matters.
- Use data_sensitivity=tolerant when normal business PII is expected.
- Use data_sensitivity=strict for public AI output.
- Store scan_id, request_id, scan_group_id, session_id, action, risk_score, and risk_level.
- Route ALLOW, WARN, BLOCK, indeterminate, pending, and failed.

Acceptance criteria:
- Every workflow has a clear scan point before trust.
- Derived OCR, extraction, model, and tool output scans reuse the correct scan_group_id.
- Review wording says Mighty flagged risk, not that Mighty proved fraud.
- Tests cover ALLOW, WARN, BLOCK, scan failure, and output scanning.