In the previous step, I made duplicate detection profile-specific. [Previous article: profile-specific duplicate rules] https://dev.to/fastapier/i-added-profile-specific-duplicate-rules-to-my-csv-intake-console-4-4pno That improved the intake logic. But there was still a practical problem: an operator could be given the right result, and still not trust the screen. So this update was about the operator view. I cleaned up the parts of the console that matter when someone is trying to understand a staged import quickly: headline run counts row-by-row decisions remediation context for blocked rows run history with downloadable remediation packs The goal here was not to make the UI “prettier.” It was to make the intake state readable. A staged run should immediately answer questions like: How many rows are actually ready? Which row is blocked? Why was it blocked? Can I export the blocked set and retry safely later? Can I trace what happened across runs? That is where intake systems usually get weak.…