Why inspect active analysis types in each scenario?

Short Answer

A scenario is just the active pairing of one mode with one corner — but the scenario existing in the database says nothing about whether it's actually doing useful work. Setup, hold, or other required analysis can be individually turned off inside a scenario that otherwise looks perfectly configured and named correctly.

Technical Explanation

• A scenario name in the database is only as useful as the constraints and analysis types actually active within it — trusting the name alone is how a disabled hold check quietly slips through signoff.
• Always audit both the scenario's definition and its status together — don't assume a well-named, well-constrained scenario is automatically checking everything it should be.

What To Check

• Warning sign: The MCMM matrix has all expected names but omits the critical check type.
• Inspect: Compare one named object across the related reports; the same object should tell a consistent story.
• Correct: Correct scenario status in the setup and rerun coverage reports across the required matrix.

Healthy, Suspicious & Hard-stop Results

• Expected: A scenario can exist while setup, hold, or other required analysis is inactive.
• Stop before floorplanning when required logic or timing coverage is missing or unexplained.

What The Interviewer Is Testing

Be ready to explain why this matters before floorplanning.

Follow-up Question & Model Response

Model response: “I would save the report, inspect one affected object in the correct block and scenario, and make or request this correction. ”