Explain force enacting

roadmap/implementers-guide/src/node/utility/candidate-validation.md

@@ -32,7 +32,7 @@ For a [`CandidateValidationMessage`][CVM]`::ValidateFromExhaustive`, these param
 
 For a [`CandidateValidationMessage`][CVM]`::ValidateFromChainState`, some more work needs to be done. Due to the uncertainty of Availability Cores (implemented in the [`Scheduler`](../../runtime/scheduler.md) module of the runtime), a candidate at a particular relay-parent and for a particular para may have two different valid validation-data to be executed under depending on what is assumed to happen if the para is occupying a core at the onset of the new block. This is encoded as an `OccupiedCoreAssumption` in the runtime API.
 
-For this reason this subsystem uses a convenient Runtime API endpoint — [`AssumedValidationData`](../../types/overseer-protocol.md#runtime-api-message). It accepts two parameters: parachain ID and the expected hash of the validation data, — the one we obtain from the `CandidateDescriptor`. Then the runtime tries to construct the validation data for the given parachain first without force enacting the core and, if its hash doesn't match the expected one, tries again with it. In case of a match the API returns the constructed validation data along with the corresponding validation code hash, or `None` otherwise. The latter means that the validation data hash in the descriptor is not based on the relay parent and thus given candidate is invalid.
+For this reason this subsystem uses a convenient Runtime API endpoint — [`AssumedValidationData`](../../types/overseer-protocol.md#runtime-api-message). It accepts two parameters: parachain ID and the expected hash of the validation data, — the one we obtain from the `CandidateDescriptor`. Then the runtime tries to construct the validation data for the given parachain first under the assumption that the block occupying the core didn't advance the para, i.e. it didn't reach the availability, if the data hash doesn't match the expected one, tries again with force enacting the core, temporarily updating the state as if the block had been deemed available. In case of a match the API returns the constructed validation data along with the corresponding validation code hash, or `None` otherwise. The latter means that the validation data hash in the descriptor is not based on the relay parent and thus given candidate is invalid.
 
 The validation backend, the one that is responsible for actually compiling and executing wasm code, keeps an artifact cache. This allows the subsystem to attempt the validation by the code hash obtained earlier. If the code with the given hash is missing though, we will have to perform another request necessary to obtain the validation function: `ValidationCodeByHash`.