# AEG-V15-037 — Business hold versus technical failure

## Scope

- **WBS ID:** `AEG-V15-037`; **Requirement / API / DB / Job / UI / Test:** `REQ-V15-SCH-05` / `V15-SCH-API` / `MIG-0020` / `J31~J40` / `Cross` / `T-V15-SCH-05`.
- **Dependency / Gate:** `AEG-V15-036` (completed, commit `00957bf`) / `G3`.
- **Acceptance:** no blind retry; every business hold records reason and hold-until.

## Source / Assumption / Unknown / Decision Required

- **Source:** `ModelOperationExecution` permits both `BusinessHold` and `Failed`, while `MIG-0020` provides `hold_until` and `status_reason_code`. The current pure state machine does not model a hold expiry.
- **Assumption:** `BusinessHold` requires a future `holdUntil` and may resume only through an explicit subsequent transition. A technical `Failed` transition must not accept a hold expiry, making retry disposition explicit rather than implicit.
- **Unknown:** the execution-state persistence/update handler is not yet implemented in the active path; this Slice changes the pure policy contract and tests it without inventing a new persistence workflow.
- **Decision Required:** automated retry limits/backoff for technical failures are not approved by the schedule contract and remain outside this Slice.

## Actual evidence

- `dotnet test tests/KArtSell.ModelOperations.UnitTests/KArtSell.ModelOperations.UnitTests.csproj -c Release --filter FullyQualifiedName~ModelOperationExecutionTests --logger "trx;LogFileName=ModelOperationExecutionTests_20260809.trx" --results-directory evidence/AEG-V15-037`
- Result: passed `3/3`; artifact: `evidence/AEG-V15-037/ModelOperationExecutionTests_20260809.trx`; SHA-256: `2F2CD06B1DFD3F76F336A0636598553599CD05CF7FA82E477DB160425975085F`.
- The policy is deterministic and I/O-free: a hold has an explicit reason and future expiry, explicit resume clears it, and a technical failure cannot masquerade as a timed business hold. No retry policy, schedule activation, or persistence workflow was introduced.