fix more links

Author: Rand McKinney

docs/manifest/assertions-actions.md

@@ -7,7 +7,7 @@ title: Assertions and actions
 
 Assertions provide information about when, where, and how an asset was created or transformed. 
 
-In the JSON manifest, each assertion is specified by a [ManifestAssertion](../manifest/manifest-ref#manifestassertion) object.  All the assertions in the manifest are in the `assertions` array. A ManifestAssertion object has two required properties, `label`, a string, and `data`, which can contain arbitrary information; and two optional properties, `kind` and `instance`. 
+In the JSON manifest, each assertion is specified by a [ManifestAssertion](../manifest/manifest-ref.mdx#manifestassertion) object.  All the assertions in the manifest are in the `assertions` array. A ManifestAssertion object has two required properties, `label`, a string, and `data`, which can contain arbitrary information; and two optional properties, `kind` and `instance`. 
 
 The standard form of an assertion in a JSON manifest is:
 
@@ -37,7 +37,7 @@ Metadata assertions must include one or more `@context` properties in the `data`
 
 ### C2PA standard assertions
 
-The C2PA Technical Specification defines a [set of standard assertions](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_standard_c2pa_assertion_summary) and their corresponding labels.  In addition, you can define [custom assertions](#custom-assertions) for your specific application.
+The C2PA Technical Specification defines a [set of standard assertions](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_standard_c2pa_assertion_summary) and their corresponding labels.  In addition, you can define [custom assertions](#custom-assertions) for your specific application.
 
 The following table summarizes some of the most important standard assertions.
 
@@ -71,7 +71,7 @@ The value of each of these properties is an object with a `use` property that ca
 - `notAllowed`: Permission is NOT granted for this type of use.
 - `constrained`: Permission is not unconditionally granted for this use.  You can provide more details (such as contact information) in the `constraints_info` text property.
 
-For more information, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.3/specs/C2PA_Specification.html#_training_and_data_mining).
+For more information, see the [C2PA Technical Specification](https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_training_and_data_mining).
 
 For example:
 

docs/manifest/examples.mdx

@@ -9,9 +9,9 @@ import CodeBlock from '@theme/CodeBlock';
 
 The C2PA [public-testfiles](https://github.com/c2pa-org/public-testfiles) repository contains numerous examples of asset files with Content Credentials. See https://c2pa.org/public-testfiles/ for links to easily inspect each asset file using Verify using [an asset URL](../verify#entering-an-asset-url) and to the corresponding [manifest report](../c2patool/#displaying-manifest-data) and [detailed manifest report](../c2patool/#detailed-manifest-report) from C2PA Tool.
 
-## Examples from c2patool
+## Examples from C2PA Tool
 
-The command-line tool [`c2patool`](/docs/c2patool) is helpful when developing applications to work with manifest data. When saving a manifest, it has two modes:
+The command-line [C2PA Tool](/docs/c2patool), `c2patool`, is helpful when developing applications to work with manifest data. When saving a manifest, it has two modes:
 
 - **Standard mode** (the default), where it saves a manifest file in JSON format, which is simplified and slightly different from the underlying binary manifest structure.
 - **Detailed mode** (specified with the `-d` option), where it saves a file that more closely reflects the actual structure of the binary data, including assertions with JUMBF URLs and their associated hashes.

docs/manifest/ingredients.md

@@ -15,7 +15,7 @@ The C2PA Technical Specification describes _ingredient assertions_ but the CAI S
 
 ## Ingredient objects
 
-Each ingredient used to create an asset is listed in the [JSON manifest](manifest-ref) `ingredients` array.  When an ingredient itself has Content Credentials, those manifests are included in the composed asset's manifest store to keep the provenance data intact. 
+Each ingredient used to create an asset is listed in the [JSON manifest](manifest-ref.mdx) `ingredients` array.  When an ingredient itself has Content Credentials, those manifests are included in the composed asset's manifest store to keep the provenance data intact. 
 
 The `ingredients` array contains an [ingredient object](manifest-ref#ingredient) for each ingredient.  The only required property of the `ingredient` object is the `title` property, which usually is the source file name.
 

docs/manifest/signing-manifests.md

@@ -4,7 +4,7 @@ title: Signing manifests
 ---
 
 :::tip
-Before reading this page, be sure to read [Getting started](/docs/getting-started) so you'll have some basic background on public-key infrastructure (PKI) technology, certificates, and signing manifests.
+Before reading this page, be sure to read [Getting started](../getting-started.mdx) so you'll have some basic background on public-key infrastructure (PKI) technology, certificates, and signing manifests.
 :::
 
 ## Overview
@@ -72,7 +72,7 @@ The information in this table is based on the [C2PA specification Trust Model se
 Here is an example of generating a C2PA-compliant set of credentials using [GlobalSign](http://globalsign.com/) certificate authority (CA).    
 
 :::note
-GlobalSign is just one of many CAs. For a list of some others, see [Getting started](/docs/getting-started#getting-a-security-certificate).
+GlobalSign is just one of many CAs. For a list of some others, see [Getting started](../getting-started.mdx#getting-a-security-certificate).
 :::note
 
 Credential management is a complex topic and different for every organization.   See [above](#overview) for links to best practices.
@@ -167,7 +167,7 @@ You now have all the needed information to configure C2PA Tool for manifest sign
 
 The `private_key` and `sign_cert` properties must be full paths to the key and certificate chain files generated above.
 
-You can now use C2PA Tool as described in its [documentation](/docs/c2patool/#adding-a-manifest-to-an-asset-file) to add a manifest to an image or other asset file. The command will be something like this:
+You can now use C2PA Tool as described in its [documentation](../c2patool/readme.md#adding-a-manifest-to-an-asset-file) to add a manifest to an image or other asset file. The command will be something like this:
 
 ```
 c2patool -m my_manifest.json -o signed_image.jpg my_image.jpg
@@ -176,7 +176,7 @@ c2patool -m my_manifest.json -o signed_image.jpg my_image.jpg
 The example above uses the information in `my_manifest.json` to add a new manifest to output `signed_image.jpg` using source `my_image.jpg`. The manifest will be signed using the PS256 signature algorithm with private key `mykey.pem`. The manifest will contain the trust chain specified in `mycerts.pem`.
 
 :::warning
-In a production application, do not access a private key and certificate directly from the file system as shown in this example. Doing so is fine during development, but not in production because it exposes these sensitive files to potential attackers. Instead use a hardware security module (HSM) and optionally a Key Management Service (KMS) to access them; for example as show in the [C2PA Python Example](../../docs/c2pa-python-example).
+In a production application, do not access a private key and certificate directly from the file system as shown in this example. Doing so is fine during development, but not in production because it exposes these sensitive files to potential attackers. Instead use a hardware security module (HSM) and optionally a Key Management Service (KMS) to access them; for example as show in the [C2PA Python Example](../c2pa-python-example/readme.md).
 :::
 
 ### Confirm it worked