docs: add Proof of Inclusion documentation

CLAUDE.md

@@ -15,10 +15,12 @@ IOTA Notarization enables creation of immutable, on-chain records for arbitrary
     whatever suites into the context the best. In this stylguide `Toolkit` is used for referencing the term. Use "title case"
     allways for `Notarization Toolkit` (never use `Notarization toolkit` or `notarization toolkit`).
 - The IOTA Trust Framework consist of Trust Framework Products (TF products)
-- The Notarization Toolkit contains two TF products: **Single Notarization** and **Audit Trails**
-  - In the context of Notarization Toolkit documentation, Single Notarization and Audit Trails are called components
-  - In the context of IOTA Trust Framework documentation, Single Notarization and Audit Trails are called TF products
-  - These rules also apply to future TF products in the Notarization Toolkit (i.e. "Proof of Inclusion")
+- The Notarization Toolkit contains three TF products: **Single Notarization**, **Audit Trails**, and **Proof of Inclusion**
+  - In the context of Notarization Toolkit documentation, Single Notarization, Audit Trails, and Proof of Inclusion are
+    called components
+  - In the context of IOTA Trust Framework documentation, Single Notarization, Audit Trails, and Proof of Inclusion are
+    called TF products
+  - These rules also apply to future TF products in the Notarization Toolkit
 - Regarding usage of singular and plural in TF product resp. Notarization Toolkit component names:
   - If the product is meant itself:
     - Use the product name (i.e. `Audit Trails`, `Notarization`) with singular form - example: "Audit Trails is the best ..."

README.md

@@ -10,6 +10,7 @@
 <p align="center">
   <a href="#introduction">Introduction</a> ◈
   <a href="#where-to-start">Where To Start</a> ◈
+  <a href="#packages">Packages</a> ◈
   <a href="#documentation-and-resources">Documentation & Resources</a> ◈
   <a href="#contributing">Contributing</a>
 </p>
@@ -28,30 +29,37 @@ The toolkit includes:
   Use this for individual locked or dynamic notarizations of arbitrary data, documents, hashes, or latest-state records.
 - **Audit Trails**
   Use this for structured record histories with sequential entries, role-based access control, locking, and tagging.
+- **Proof of Inclusion**
+  Use this to construct portable cryptographic evidence that a transaction, event, or object state is included in a
+  certified IOTA checkpoint, and to verify that evidence locally.
 
-Each toolkit component is available as:
+## Where To Start
 
-- **Move Package** for the on-chain contracts
-- **Rust Package** for typed client access and transaction builders
-- **TypeScript/JS Package** using wasm bindings for the above-mentioned Rust package
+Use [Single Notarization](#single-notarization) for one on-chain object that stores arbitrary data, a document hash, or
+the latest state of a record.
 
-## Where To Start
+Use [Audit Trails](#audit-trails) for structured record histories with permissions, capabilities, tagging, and write or
+delete controls.
 
-See [Single Notarization resources](#single-notarization) for one on-chain proof object, such as a document hash, immutable record, or dynamic latest-state record.
+Use [Proof of Inclusion](#proof-of-inclusion) when a verifier needs portable evidence that a transaction, event, or
+object state is included in a certified checkpoint. Proof of Inclusion verifies existing ledger activity and does not
+define a separate on-chain object or Move Package.
 
-See [Audit Trails resources](#audit-trails) for structured record histories with permissions, capabilities, tagging, and write or delete controls.
+## Packages
 
-If you need to integrate the Notarization on-chain contracts into your own Move Package:
+Single Notarization and Audit Trails provide on-chain contracts:
 
-- [Notarization Move Package](./notarization-move)
+- [Single Notarization Move Package](./notarization-move)
 - [Audit Trails Move Package](./audit-trail-move)
 
-If you want to build a client application:
+All three components provide Rust and TypeScript/JavaScript packages:
 
-- [Rust client for notarized records](./notarization-rs)
-- [Rust client for audit trails](./audit-trail-rs)
-- [Wasm bindings for notarized records](./bindings/wasm/notarization_wasm)
-- [Wasm bindings for audit trails](./bindings/wasm/audit_trail_wasm)
+- [Single Notarization Rust Package](./notarization-rs)
+- [Audit Trails Rust Package](./audit-trail-rs)
+- [Proof of Inclusion Rust Package](./poi-rs)
+- [Single Notarization Wasm Package](./bindings/wasm/notarization_wasm)
+- [Audit Trails Wasm Package](./bindings/wasm/audit_trail_wasm)
+- [Proof of Inclusion Wasm Package](./bindings/wasm/poi_wasm)
 
 ## Documentation and Resources
 
@@ -75,6 +83,15 @@ If you want to build a client application:
 - [Wasm Package README](./bindings/wasm/audit_trail_wasm/README.md)
 - [Wasm Examples](./bindings/wasm/audit_trail_wasm/examples/README.md)
 
+### Proof of Inclusion
+
+- [Rust Package README](./poi-rs/README.md)
+- [Rust API documentation](https://iotaledger.github.io/notarization/poi_rs/index.html)
+- [Build the CLI from source](./poi-rs/README.md#building-the-cli-from-source)
+- [Rust Examples](./examples/poi/README.md)
+- [Wasm Package README](./bindings/wasm/poi_wasm/README.md)
+- [Wasm Examples](./bindings/wasm/poi_wasm/examples/README.md)
+
 ## Contributing
 
 We would love to have you help us with the development of the IOTA Notarization Toolkit. Each and every contribution is greatly valued.
@@ -83,4 +100,4 @@ Please review the [contribution](https://docs.iota.org/developer/iota-notarizati
 
 To contribute directly to the repository, simply fork the project, push your changes to your fork and create a pull request to get them included.
 
-The best place to get involved in discussions about these libraries or to look for support at is the `#notarization` channel on the [IOTA Discord](https://discord.gg/iota-builders). You can also ask questions on our [Stack Exchange](https://iota.stackexchange.com/).
+The best place to get involved in discussions about these Packages or to look for support at is the `#notarization` channel on the [IOTA Discord](https://discord.gg/iota-builders). You can also ask questions on our [Stack Exchange](https://iota.stackexchange.com/).

bindings/wasm/README.md

@@ -1,86 +1,88 @@
-# WASM build projects using wasm-bindgen
+# IOTA Notarization Toolkit Wasm Packages
 
-This folder contains several crates using wasm-bindgen to import or export TS types from & to JS runtimes. These crates
-are named _artifact_ in the following to indicate that the NodeJS based JS build system is used instead of cargo.
+This folder contains the Notarization Toolkit Wasm Packages. Each Package uses `wasm-bindgen` to expose Rust types and
+functions to JavaScript and TypeScript runtimes.
 
-The `build` folder provides build scripts needed to build the artifacts.
+The `build` folder provides the shared scripts needed to build the Packages.
 
-Here is an overview of the existing artifacts:
+The following Packages are available:
 
 - `notarization_wasm`<br>
   Public surface of notarization-rs exported to JS/TypeScript
 - `audit_trail_wasm`<br>
   Public surface of audit-trail-rs exported to JS/TypeScript
+- `poi_wasm`<br>
+  Proof of Inclusion client and public surface of poi-rs exported to JS/TypeScript
 
-## Building an Artifact
+## Building a Package
 
-For build instructions please have a look into the artifact README file.
+See each Package README for its build instructions.
 
 ## Build process in general
 
-Each artifact is located in its own artifact folder (see above) containing the following important files and subfolders:
+Each Package has its own folder containing the following files and subfolders:
 
 - `tsconfig` files for the `nodejs` and `web` runtimes
 - The `package.json` file
 - `lib` folder<br>
   Contains TS files used for wasm-bindings
   - Contains `tsconfig` files for the `nodejs` and `web` runtimes with additional TS compiler configurations
 - `node` folder<br>
-  Distribution folder for the `nodejs` runtime
+  Distribution folder for the Node.js runtime
 - `web` folder<br>
   Distribution folder for the `web` runtime
 - `src` folder<br>
-  Rust code of the crate/artifact
+  Rust code of the Package
 - `tests` folder<br>
   Test code
 - `examples` folder<br>
   Example code
 
-The build process is defined by run scripts contained in the artifacts `package.json` file.
-The build process for the `nodejs` and `web` runtimes, consists of the following steps:
+The scripts in each Package's `package.json` file define its build process.
+The build process for the Node.js and web runtimes consists of the following steps:
 
-- cargo build of the crate with target wasm32-unknown-unknown
-- wasm-bindgen CLI call, generating `___.js` and `___.d.ts` files in the distribution folder of the artifact (`node` or
+- Cargo build of the crate with target `wasm32-unknown-unknown`
+- `wasm-bindgen` CLI call, generating `___.js` and `___.d.ts` files in the Package distribution folder (`node` or
   `web`)
 - execute the `build/node` or `build/web` build script (see below)
-- typescript transpiler call (tsc)<br>
+- TypeScript compiler call (`tsc`)<br>
   Converts the TS files in the `lib` folder into JS files.
-  JS files are written into the distribution folder of the artifact.
+  JS files are written into the Package distribution folder.
   The distribution folder is configured
-  in the applied tsconfig file (located in the `lib` folder of the artifact).
+  in the applied `tsconfig` file located in the Package's `lib` folder.
 - execute the `build/replace_paths` build script (see below)
 
 ## Build scripts contained in the `build` folder
 
 ### node.js
 
-Used by the `bundle:nodejs` run task in the package.json file of the artifact.
+Used by the `bundle:nodejs` script in the Package's `package.json` file.
 
 Process steps:
 
 - Add a [node-fetch polyfill](https://github.com/seanmonstar/reqwest/issues/910)
-  at the top of the main js file of the artifact
-- Generate a `package.json` file derived from the original package.json of the artifact
+  at the top of the Package's main JS file
+- Generate a `package.json` file derived from the Package's original `package.json`
   (done by `utils/generatePackage.js`)
 
 ### web.js
 
-Used by the `bundle:web` run task in the package.json file of the artifact.
+Used by the `bundle:web` script in the Package's `package.json` file.
 
 Process steps:
 
-- In the main js file of the artifact:
+- In the Package's main JS file:
   - Comment out a webpack workaround by commenting out all occurrences of<br>
     `input = new URL(<SOME_CAPTURED_REGEX_GROUP>, import.meta.url);`
-  - Create an init function which imports the artifact wasm file.
+  - Create an initialization function that imports the Package's Wasm file.
 - In the typescript source map file `<ARTIFACT_NAME>.d.ts`:
   - Adds the declaration of the above created init function to the typescript source map file
-- Generate a `package.json` file derived from the original package.json file of the artifact
+- Generate a `package.json` file derived from the Package's original `package.json`
   (done by `utils/generatePackage.js`)
 
 ### replace_paths.js
 
-Processes all JS and TS files contained in the artifact distribution folder that have previously been created
+Processes all JS and TS files previously created in the Package distribution folder
 by wasm-bindgen and the TS compiler (tsc) call.
 
 For each file, it replaces aliases defined in the
@@ -98,7 +100,7 @@ It is used by the following run tasks for the following tsconfig files and distr
 
 ## Documentation Style Guide for generated TSDoc/JSDoc
 
-The [DOC-STYLEGUIDE.md](./DOC-STYLEGUIDE.md) states rules to be followed for the documentation
-of Rust types being compiled in TS/JS types using wasm-bindgen.
+The [DOC-STYLEGUIDE.md](./DOC-STYLEGUIDE.md) defines the documentation rules for Rust types compiled into
+JavaScript/TypeScript types with `wasm-bindgen`.
 
 These rules are obligatory for developers and AI agents.