Part 2 answers: What exactly are we checking against?
Every check needs an oracle: something that knows the right answer. Prose specifications are ambiguous, incomplete and sometimes wrong, so the first job of verification is to turn intent into rules a machine can check and models that compute expected results.
This part covers the oracle problem, turning sentences into numbered rules, reference models at different levels of detail, specification review as a bug-finding activity, traceability from requirement to result, and the opposite danger: checks that forbid legal behaviour.
Turn a prose requirement into checkable rules.
Choose the right level of detail for a reference model.
Review a specification for ambiguity and trace every requirement to evidence.
Answer each in your head before opening it. If two or more feel shaky, revisit Part 1: What Can Go Wrong first.
Any four of: corner case, concurrency, integration, configuration, performance, reset or power, specification.
Each block is tested against its own understanding of the interface; the disagreement only appears when they meet.
In new, complex and recently changed logic, and at boundaries between blocks and teams.
# | Lesson | Level | Status |
|---|---|---|---|
2.1 | W · Working | Ready | |
2.2 | W · Working | Ready | |
2.3 | S · Senior | Ready | |
2.4 | S · Senior | Ready | |
2.5 | S · Senior | Ready | |
2.6 | P · Principal | Ready | |
2.7 | P · Principal | Ready | |
— | all levels | Ready |
Every lesson in this part is ready. Work through them in order: each one sets up the problem the next one solves.
This course teaches the decisions behind verification. These lessons teach the tools and syntax that carry them out, so this part links to them instead of repeating them.