diff --git a/polkadot/roadmap/implementors-guide/src/node/utility/candidate-validation.md b/polkadot/roadmap/implementors-guide/src/node/utility/candidate-validation.md
index 30c110fdef1ed83c3bb286684f0ec6323ea3dab3..6ad59f60f31e98fb0c2f4bc7048a0ecb9e7b88df 100644
--- a/polkadot/roadmap/implementors-guide/src/node/utility/candidate-validation.md
+++ b/polkadot/roadmap/implementors-guide/src/node/utility/candidate-validation.md
@@ -2,12 +2,22 @@
 
 This subsystem is responsible for handling candidate validation requests. It is a simple request/response server.
 
+A variety of subsystems want to know if a parachain block candidate is valid. None of them care about the detailed mechanics of how a candidate gets validated, just the results. This subsystem handles those details.
+
 ## Protocol
 
-Input:
+Input: [`CandidateValidationMessage`](../../type-definitions.html#validation-request-type)
 
-- [`CandidateValidationMessage`](../../type-definitions.html#validation-request-type)
+Output: [`Statement`](../../type-definitions.html#statement-type) via the provided `Sender<Statement>`.
 
 ## Functionality
 
-Given a candidate, its validation code, and its PoV, determine whether the candidate is valid. There are a few different situations this code will be called in, and this will lead to variance in where the parameters originate. Determining the parameters is beyond the scope of this subsystem.
+Given the hashes of a relay parent and a parachain candidate block, and either its PoV or the information with which to retrieve the PoV from the network, spawn a short-lived async job to determine whether the candidate is valid.
+
+Each job follows this process:
+
+- Get the full candidate from the current relay chain state
+- Check the candidate's proof
+   > TODO: that's extremely hand-wavey. What does that actually entail?
+- Generate either `Statement::Valid` or `Statement::Invalid`. Note that this never generates `Statement::Seconded`; Candidate Backing is the only subsystem which upgrades valid to seconded.
+- Return the statement on the provided channel.
diff --git a/polkadot/roadmap/implementors-guide/src/type-definitions.md b/polkadot/roadmap/implementors-guide/src/type-definitions.md
index d8c90bba50d07228a58499405fc6d315c74b1032..1c730e9a3b6f3d544ea3fbf962800e97b0417348 100644
--- a/polkadot/roadmap/implementors-guide/src/type-definitions.md
+++ b/polkadot/roadmap/implementors-guide/src/type-definitions.md
@@ -91,16 +91,9 @@ enum CandidateBackingMessage {
 Various modules request that the [Candidate Validation subsystem](node/utility/candidate-validation.html) validate a block with this message
 
 ```rust
-enum PoVOrigin {
-  /// The proof of validity is available here.
-  Included(PoV),
-  /// We need to fetch proof of validity from some peer on the network.
-  Network(CandidateReceipt),
-}
-
 enum CandidateValidationMessage {
   /// Validate a candidate and issue a Statement
-  Validate(CandidateHash, RelayHash, PoVOrigin),
+  Validate(CandidateHash, RelayHash, PoV, Sender<Statement>),
 }
 ```