Input validation
Every file is validated independently before conversion. The interface treats file size as a per-file constraint, not a batch-wide loophole. This protects the queue from oversized documents and gives the user precise feedback about the specific file that needs attention. Validation also prevents wasted conversion time on clearly unsupported or empty inputs.
Conversion execution
Once accepted, each file is written to a temporary location and passed to Microsoft MarkItDown. The product monitors output and normalizes it before the user sees it. This matters because raw converter output may contain encoding issues, control characters, or malformed fences that would degrade preview quality if passed through unexamined.
Preview and review
The preview stage is part of the supported workflow, not a cosmetic extra. It exists so that users can verify structure, catch encoding anomalies, and decide whether a document is immediately usable. For batch jobs, preview is selective: users focus on representative or suspicious files rather than reading every output line by line.
Export behavior
Exports are intentionally per-file because the product preserves file identity throughout the queue. This keeps downstream handling simple. A user can immediately map one source file to one Markdown artifact, compare outputs, or move only the completed files into another system while leaving failures for later follow-up.
Failure interpretation
A supported workflow also defines what failure means. If a file times out, exceeds the size limit, or produces unreadable output, the UI should surface that state as information the user can act on. Silent partial success is worse than an explicit failure because it encourages low-trust content to enter the next stage unnoticed.