IS.2:5.1 - Distinguish access, capability and consequences
Continue the constructed Harbor Design case. The helper reconstructs three episodes:
| Episode | What happened | What it changes |
|---|---|---|
| A source check with a working direct link | The analyst identified the relevant revision and explained its effect. | This episode supports use of the known operation with that access; it does not prove every analyst’s general capability. |
| A check through the usual shared portal | The needed revision was unavailable, and the analyst used an older one. | The portal condition is a concrete repair target. |
| An early challenge with the correct revision | The manager deferred the challenge to preserve the release date; the analyst received an adverse response for delay. | Correct detection is insufficient while the receiving consequence defeats its use. |
The helper does not average these into “low readiness”. The source owner repairs the portal; the responsible manager and technical lead settle how a legitimate concern reaches the release decision and how its time is provided. OCE.10 supplies that organizational response.
Suppose the next supported episode succeeds with one analyst, while a second still cannot compare the two revisions. That different finding opens a bounded HCD question about the second analyst’s operation. It does not retrospectively turn the portal failure into a learning defect.
If the manager refuses the needed change, the helper reports that the promised early-challenge practice remains unsupported. The source repair can still be useful. Another workshop cannot be represented as closure of the unresolved organizational condition.