diff --git a/docs/js-sdk/getting-started/overview.mdx b/docs/js-sdk/getting-started/overview.mdx
index bff11152..b5ad0226 100644
--- a/docs/js-sdk/getting-started/overview.mdx
+++ b/docs/js-sdk/getting-started/overview.mdx
@@ -44,8 +44,8 @@ Key features of the JavaScript library include:
 - **Developer friendly**: Full TypeScript support and robust debugging support using the [debug](https://github.com/debug-js/debug) library make integration easy.
 - **Performance**: The processing code of the library uses a high-performance [WebAssembly](https://developer.mozilla.org/en-US/docs/WebAssembly) binary. Additionally, the library offloads processing tasks to a configurable Web Worker pool to enable parallelization and avoid blocking a web application's main thread.
 - **Lazy loading and processing**: Since images can be quite large, the library inspects the start of an asset file for C2PA manifest data before requesting the entire file, [if the server supports it](../guides/hosting#range-requests). The library will download the rest of the asset only if it finds the metadata marker. Additionally, it delays loading the WebAssembly binary until it makes the first processing request.
-- **Adherence to the C2PA specification**: The library strives to maintain compliance with the [C2PA specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html) as much as possible, and the web components follow the [C2PA user experience guidance](https://c2pa.org/specifications/specifications/1.0/ux/UX_Recommendations.html) recommendations.
-- **Security and encryption**: The library handles all [validation](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_validation) via the [Web Crypto API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API) and passes any validation errors back to the client. It supports all ECDSA and RSASSA-PSS algorithms listed in the [C2PA specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_digital_signatures).
+- **Adherence to the C2PA specification**: The library strives to maintain compliance with the [C2PA specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html) as much as possible, and the web components follow the [C2PA user experience guidance](https://c2pa.org/specifications/specifications/1.0/ux/UX_Recommendations.html) recommendations.
+- **Security and encryption**: The library handles all [validation](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_validation) via the [Web Crypto API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API) and passes any validation errors back to the client. It supports all ECDSA and RSASSA-PSS algorithms listed in the [C2PA specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_digital_signatures).
   :::caution
   The JavaScript library does not currently support Ed25519 signatures.
   :::caution
diff --git a/docs/js-sdk/guides/validation.mdx b/docs/js-sdk/guides/validation.mdx
index 3b74825d..d1415481 100644
--- a/docs/js-sdk/guides/validation.mdx
+++ b/docs/js-sdk/guides/validation.mdx
@@ -3,11 +3,11 @@ id: validation
 title: Validation & errors
 ---
 
-Part of processing an asset involves [validating the manifests](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_validation) that it contains. During validation, errors can occur in the active manifest and in ingredients.
+Part of processing an asset involves [validating the manifests](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_validation) that it contains. During validation, errors can occur in the active manifest and in ingredients.
 
 ## Validation errors in the active manifest
 
-When [c2pa.read](../api/c2pa.c2pa#methods) loads C2PA assets, it validates the current manifest and assigns any [failure codes](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_failure_codes) to the `manifestStore.validationStatus` array.
+When [c2pa.read](../api/c2pa.c2pa#methods) loads C2PA assets, it validates the current manifest and assigns any [failure codes](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_failure_codes) to the `manifestStore.validationStatus` array.
 
 Manifest validation errors can occur when:
 
@@ -17,7 +17,7 @@ Manifest validation errors can occur when:
 
 ## Validation errors in ingredients
 
-[Ingredients](../../introduction#key-concepts) are validated when they are imported into an asset. The results of this are stored in the manifest in the ingredient's [`validationStatus`](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_existing_manifests) object, which contains both [success](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_success_codes) and [failure](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_failure_codes) codes that represent the results of all of the validation checks that took place.
+[Ingredients](../../introduction#key-concepts) are validated when they are imported into an asset. The results of this are stored in the manifest in the ingredient's [`validationStatus`](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_existing_manifests) object, which contains both [success](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_success_codes) and [failure](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_failure_codes) codes that represent the results of all of the validation checks that took place.
 
 Access validation errors in ingredients in JavaScript code as follows:
 
diff --git a/docs/manifest/validation.md b/docs/manifest/validation.md
index 3f6857b1..ed20109c 100644
--- a/docs/manifest/validation.md
+++ b/docs/manifest/validation.md
@@ -7,7 +7,7 @@ Processing an asset includes [validating the manifests](https://c2pa.org/specifi
 
 ## Validation errors in manifests
 
-When you load an asset, all the manifests in the manifest store are validated and any [failure codes](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_failure_codes) are assigned to the `validation_status` array. Inspect the array to find the validation errors. Validation returns ONLY error codes; success is not explicitly indicated.
+When you load an asset, all the manifests in the manifest store are validated and any [failure codes](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_failure_codes) are assigned to the `validation_status` array. Inspect the array to find the validation errors. Validation returns ONLY error codes; success is not explicitly indicated.
 
 Manifest validation errors can occur, for example, when:
 
@@ -27,7 +27,7 @@ Only errors that are not already recorded in the `validation_status` of an ingre
 
 ## Error status codes
 
-The following table describes some common validation error status codes. Refer to the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_failure_codes) for the full list.
+The following table describes some common validation error status codes. Refer to the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_failure_codes) for the full list.
 
 | Validation Status Code| Description  | Type of URI |
 | --------------------- | ------------ | ----------- |
@@ -47,7 +47,7 @@ Validation error status codes can contain JUMBF URIs that reference assertions o
 - **Assertion URI**: A URI like `self#jumbf=c2pa.assertions/<ASSERTION>` where `<ASSERTION>` is either `stds.schema-org.*` or `c2pa.*`.
 - **Signature Box URI**: A URI like `self#jumbf=c2pa.signature`.
 
-For more information, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_uri_references).
+For more information, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_uri_references).
 
 <!--
 Actions and assertions:
diff --git a/docs/trust-list.mdx b/docs/trust-list.mdx
index 53ee9d61..29fa9a61 100644
--- a/docs/trust-list.mdx
+++ b/docs/trust-list.mdx
@@ -23,7 +23,7 @@ The C2PA intends to publish an official public list of known certificates. Until
 The [contentcredentials.org](https://contentcredentials.org/) site hosts the following files that it uses to [validate signing certificates](https://c2pa.org/specifications/specifications/2.0/specs/C2PA_Specification.html#_c2pa_signers). Together, these files form the _temporary known certificate list_:
 
 - **The temporary end-entity certificate list** in https://contentcredentials.org/trust/allowed.pem consists of end-entity certificates. If the certificate is on this list, it is considered "known." To reduce bandwidth consumption, a [version with SHA-256 hashes](https://contentcredentials.org/trust/allowed.sha256.txt) of the certificates is also available.
-- **The temporary known anchor list** in https://contentcredentials.org/trust/anchors.pem contains the list of known anchor certificates. If an end-entity [certificate's chain](../getting-started.mdx#signing-and-certificates) can be traced back to an anchor certificate on this list, the certificate is considered "known."
+- **The temporary known anchor list** in https://contentcredentials.org/trust/anchors.pem contains the list of known anchor certificates. If an end-entity [certificate's chain](getting-started.mdx#signing-and-certificates) can be traced back to an anchor certificate on this list, the certificate is considered "known."
 - **The configuration file**, https://contentcredentials.org/trust/store.cfg, specifies the [Extended Key Usage (EKU)](https://datatracker.ietf.org/doc/html/rfc9336) values accepted for end-entity certificates. An end-entity certificate must have at least one of the EKUs in this list to be valid.
 
 ## Using the known certificate list
diff --git a/docs/verify.mdx b/docs/verify.mdx
index 75911632..14874770 100644
--- a/docs/verify.mdx
+++ b/docs/verify.mdx
@@ -168,9 +168,18 @@ For example, suppose you downloaded a file from Adobe Stock and renamed it `my_s
 
 **Signing information**
 
-This section displays the the issuer of the claim signature from the `signature_info.issuer` property in the active manifest, as shown in the example snippet below. It shows the organization name only if the signing certificate includes the "O" or [Organization Name attribute](https://www.alvestrand.no/objectid/2.5.4.10.html) (OID value 2.5.4.10) in the certificate's distinguished name information.
+If the Content Credential was signed by a certificate that is NOT on the [known certificate list](verify-known-cert-list), such as the CAI test certificate in the SDK, then Verify displays "Unrecognized" at the top of this section with this notice:
 
-If the Content Credential was signed by a certificate on the [known certificate list](verify-known-cert-list), then this section also displays the time of the claim signature from the `signature_info.time` property in the active manifest, as shown in the example snippet below. The date is converted from UTC to the local time zone.
+import verify_unknown_source from '../static/img/verify-cc-unknown-source.png';
+
+<img
+  src={verify_unknown_source}
+  style={{ width: '283px', display: 'block', margin: '10px auto' }}
+/>
+
+However, if the Content Credential was signed by a certificate on the [known certificate list](verify-known-cert-list), then this section displays the name of the issuer of the claim signature from the `signature_info.issuer` property in the active manifest, as shown in the example snippet below. It shows the organization name only if the signing certificate includes the "O" or [Organization Name attribute](https://www.alvestrand.no/objectid/2.5.4.10.html) (OID value 2.5.4.10) in the certificate's distinguished name information.
+
+For signers on the known certificate list, this section also displays the time of the claim signature from the `signature_info.time` property in the active manifest, as shown in the example snippet below. The date is converted from UTC to the local time zone.
 
 ```json
 "signature_info": {
@@ -182,15 +191,46 @@ If the Content Credential was signed by a certificate on the [known certificate
 
 If the issuer string is too long, then the date might be truncated or not shown at all. If so, refer to the [**About this Content Credential**](#about-this-content-credential) section for the full date.
 
-If the Content Credential was signed by a certificate that is NOT on the [known certificate list](verify-known-cert-list), then Verify displays this notice:
+### Validation status
 
-import verify_unknown_source from '../static/img/verify-cc-unknown-source.png';
+If the manifest has [validation errors](manifest/validation.md), then Verify displays this notice:
+
+import verify_validation_error from '../static/img/verify-validation-error.png';
 
 <img
-  src={verify_unknown_source}
+  src={verify_validation_error}
   style={{ width: '300px', display: 'block', margin: '10px auto' }}
 />
 
+Verify displays this warning if the `validation_status` array contains any elements. For example, a [this image](https://contentcredentials.org/verify?source=https://c2pa.org/public-testfiles/image/jpeg/adobe-20220124-E-dat-CA.jpg) with a hard binding hash mismatch error, as shown in [this manifest store](https://c2pa.org/public-testfiles/image/jpeg/manifests/adobe-20220124-E-dat-CA/manifest_store.json):
+
+```
+"validation_status": [
+    {
+      "code": "assertion.dataHash.mismatch",
+      "url": "self#jumbf=/c2pa/contentauth:urn:uuid:04cdf4ec-f713-4e47-a8d6-7af56501ce4b/c2pa.assertions/c2pa.hash.data",
+      "explanation": "asset hash error, name: jumbf manifest, error: hash verification( Hashes do not match )"
+    }
+  ]
+```
+
+Another example that can result in this message is shown in [this image](https://contentcredentials.org/verify?source=https://c2pa.org/public-testfiles/image/jpeg/adobe-20220124-E-clm-CAICAI.jpg) with a missing referenced claim, as shown in [this manifest store](https://c2pa.org/public-testfiles/image/jpeg/manifests/adobe-20220124-E-clm-CAICAI/manifest_store.json):
+
+```
+"validation_status": [
+    {
+      "code": "assertion.hashedURI.mismatch",
+      "url": "self#jumbf=c2pa.assertions/c2pa.ingredient__1",
+      "explanation": "hash does not match assertion data: self#jumbf=c2pa.assertions/c2pa.ingredient__1"
+    },
+    {
+      "code": "claim.missing",
+      "url": "self#jumbf=/c2pa/contentbeef:urn:uuid:8bb8ad50-ef2f-4f75-b709-a0e302d58019",
+      "explanation": "ingredient not found"
+    }
+  ]
+```
+
 ### Credit and usage
 
 The **Credit and usage** section displays information about the asset's author and usage rights, divided into these subsections:
diff --git a/static/img/verify-cc-unknown-source.png b/static/img/verify-cc-unknown-source.png
index e2a7d7d2..78f85287 100644
Binary files a/static/img/verify-cc-unknown-source.png and b/static/img/verify-cc-unknown-source.png differ
diff --git a/static/img/verify-validation-error.png b/static/img/verify-validation-error.png
new file mode 100644
index 00000000..dbce3645
Binary files /dev/null and b/static/img/verify-validation-error.png differ