diff --git a/index.js b/index.js
index 06cbd16..fe07c18 100644
--- a/index.js
+++ b/index.js
@@ -8,6 +8,7 @@ module.exports = {
 	validateArguments: require("./src/api/validate-arguments"),
 	validateOptions: require("./src/api/validate-options"),
 	validateValue: require("./src/api/validate-value"),
+	testValue: require("./src/api/test-value"),
 
 	AggregrateValidationError: require("./src/aggregrate-validation-error"),
 	RemainingArguments: require("./src/api/validate-arguments/remaining-arguments-symbol")
diff --git a/src/aggregrate-errors.js b/src/aggregrate-errors.js
index 71d3a60..f31e8f2 100644
--- a/src/aggregrate-errors.js
+++ b/src/aggregrate-errors.js
@@ -19,6 +19,7 @@ function joinPathSegments(segments) {
 		: "(root)";
 }
 
+// FIXME: Render error codes (grayed out) after error messages, as a stable identifier
 function renderErrorList(errors, subErrorLevels = 0) {
 	let rephrasedErrors = errors.map((error, i) => {
 		let pathSegments = error.path.map((segment) => {
diff --git a/src/api/test-value.js b/src/api/test-value.js
new file mode 100644
index 0000000..2ca9736
--- /dev/null
+++ b/src/api/test-value.js
@@ -0,0 +1,12 @@
+"use strict";
+
+const applyValidators = require("../apply-validators");
+
+// NOTE: This will *not* give you access to either the errors or the transformed value! It's typically used for conditional logic in business logic *after* the initial validation has already taken place. This allows for reusing the entire ecosystem of Validatem validators for "does this value match format X, if yes, run this code"-type logic.
+// FIXME: Put this in the documentation instead.
+
+module.exports = function (value, rules) {
+	let { errors } = applyValidators(value, rules);
+
+	return (errors.length === 0);
+};
diff --git a/src/api/validate-arguments/index.js b/src/api/validate-arguments/index.js
index 6ce74ed..763cfb0 100644
--- a/src/api/validate-arguments/index.js
+++ b/src/api/validate-arguments/index.js
@@ -17,6 +17,7 @@ const RemainingArguments = require("./remaining-arguments-symbol");
 // TODO: Simplify below by treating it like an array or object? Or would that introduce too much complexity through specialcasing?
 // TODO: Find a way to produce validatem-style errors for the below invocation errors, without introducing recursion
 // TODO: Maybe create a validatedFunction(rules, (foo, bar) => ...) type abstraction for "pre-processed", more performant validation usecases? At the cost of having to specify the validation rules outside of the function, which you'd need to do anyway in that case. Upside would be that you don't need to specify `arguments` manually anymore.
+// TODO: Special-case callsite extraction from stacktrace when using validateArguments, as the user will probably be interested in where the validator-fenced code was *called from*, not where the rules are defined (unlike with validateValue)
 
 function arrayToNormalized(array) {
 	return array.map((definition) => {
diff --git a/src/colors.js b/src/colors.js
index d0ca137..d54f1cc 100644
--- a/src/colors.js
+++ b/src/colors.js
@@ -16,8 +16,8 @@ if (supportsColor.stderr) {
 } else {
 	openHighlight = "";
 	openDim = "";
-	openHighlightBold = ""; // cyan bold
-	openDimBold = ""; // gray bold
+	openHighlightBold = "";
+	openDimBold = "";
 	closeColor = "";
 }
 
diff --git a/src/compose-rules.js b/src/compose-rules.js
index 57d631b..d772bfd 100644
--- a/src/compose-rules.js
+++ b/src/compose-rules.js
@@ -70,6 +70,7 @@ module.exports.compose = function composeValidators(validators) {
 	}
 
 	return function composedValidator(value, context) {
+		// FIXME: Does this still need to be a special case, now that we have the callIfNull property?
 		if (isRequired && value == null) {
 			return validationResult({
 				errors: [ new ValidationError(`Required value is missing`) ],