Feat/audit trails dev new product name

.cargo/config.toml

@@ -1,3 +1,3 @@
 [alias]
 docs-notarization = "doc -p notarization"
-docs-audit-trail = "doc -p audit_trail"
+docs-audit-trail = "doc -p audit_trails"

.claude/skills/sync-product-docs/SKILL.md

@@ -254,7 +254,7 @@ is exactly how drift survives a commit that "already updated the docs".
 
 ## What "aligned" looks like — example
 
-For an entry `[audit_trail.locking.new]` (the `LockingConfig::new`
+For an entry `[audit_trails.locking.new]` (the `LockingConfig::new`
 constructor):
 
 - **Move** (`<move-sc-path>/locking.move`): "Create a new locking

.claude/skills/update-api-mapping/SKILL.md

@@ -255,7 +255,7 @@ Expected behavior:
 3. Find e.g. an added `public fun pause_trail` in `audit_trail.move`, an
    added `PauseTrail` struct + `PauseTrail::new` in `audit-trail-rs/src`,
    and `WasmPauseTrail` with the usual two methods in the WASM crate.
-4. Propose a new `[audit_trail.main.pause_trail]` section with both arrays
+4. Propose a new `[audit_trails.main.pause_trail]` section with both arrays
    prefilled.
 5. Find e.g. that `delete_records_batch`'s removed Rust helper
    `TrailRecords::delete_batch_legacy` should be dropped from the existing

.github/workflows/wasm-publish.yml

@@ -145,4 +145,4 @@ jobs:
         if: ${{ github.event.inputs.package == 'audit-trail' }}
         shell: bash
         run: |
-          npm dist-tag add @iota/audit-trail@${{ github.event.inputs.retag-version }} ${{ github.event.inputs.retag-tag }}
+          npm dist-tag add @iota/audit-trails@${{ github.event.inputs.retag-version }} ${{ github.event.inputs.retag-tag }}

.github/workflows/wasm-retag-npm.yml

@@ -42,4 +42,4 @@ jobs:
         env:
           NODE_AUTH_TOKEN: ${{ secrets.NPM_NOTARIZATION_TOKEN }}
         run: |
-          npm dist-tag add @iota/audit-trail@${{ github.event.inputs.version }} ${{ github.event.inputs.tag }}
+          npm dist-tag add @iota/audit-trails@${{ github.event.inputs.version }} ${{ github.event.inputs.tag }}

CLAUDE.md

@@ -15,23 +15,30 @@ 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 Trail**
-  - In the context of Notarization Toolkit documentation, Single Notarization and Audit Trail are called components
-  - In the context of IOTA Trust Framework documentation, Single Notarization and Audit Trail are called 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 name of TF products resp. Notarization Toolkit components is allways a singular term
-  - Use capitalization (a.k.a. title case) for the words of a product name if the product is meant itself - examples `Audit Trail`, `Notarization`
-  - Use plural (i.e. `audit trails` or `notarizations`) only where multiple instances of the TF product are meant
+- 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 ..."
+    - Use capitalization (a.k.a. title case) - examples `Audit Trails`, `Notarization`
+  - If multiple instances of a product (typically equivalent to multiple on-chain objects) are meant:
+    - Use plural (i.e. `Using multiple audit trails facilitates ...` or `Avoid creating too much notarizations for ...`)
     - Use lower case for the plural form - except at the beginning of sentences and in markdown titles
-  - In situations where the TF product itself or the plural form can be addressed choose whatever fits best
-  - This rule - including capitalization aspects - only applies to TF products resp. Notarization Toolkit components using
-    plural for other entities like i.e. Notarization Methods (`Locked Notarization`, `Dynamic Notarization` - see below) is OK.
-  - Example `Audit Trail`:
-    - Do not use `Audit Trails` - always use `Audit Trail` to denote the product itself
-    - Use plural (i.e. `audit trails` or `Audit trails`) only where multiple instances of the TF product are meant - Examples:
-      - `A client for creating and managing audit trails on the IOTA blockchain`
-      - `Audit trails and their records are ...`
-      - `Audit trails provide ...` (could also be `Audit Trail provides ...`)
+  - If the TF product or multiple product instances could be meant: Prefer the TF product variant if possible. Only
+    use the plural variant where clearly more suitable.
+  - This rule - including the capitalization aspects - only applies to TF products (resp. Toolkit components). Using the
+    plural form with title case for other entities like i.e. Notarization Methods (`Locked Notarization`, `Dynamic Notarization` - see below) is OK.
+  - If onchain objects of the TF product are addressed:
+    - In source code documentation related to the TF product specific Move object type (i.e. `AuditTrail`, `Notarization`),
+      the type name followed by "object" resp. "objects" shall be used (examples: "To create a `Notarization` object use ...",
+      "`AuditTrail` objects can be batch deleted using ...").
+    - In less technical documentation, typically in the context of general descriptions of TF products or Notarization Toolkit components:
+      - the product name in singular of plural form shall be used (see above) without any extensions
+      - if the onchain object, equivalent to the product itself, is addressed, use either the Move object type based form (see above)
+        or the product name followed by "object" resp. "objects" (examples: "`Notarization` onchain objects facilitate ...",
+        "Audit Trails on-chain objects must be managed ... ") whatever is most suitable.
 - Regarding Single Notarization (Component/TF product):
   - Single Notarization provides two **Notarization Methods**: **Locked Notarization** and **Dynamic Notarization**
     - There might be additional Notarization Methods in future versions of Single Notarization (i.e. "Custom Notarization")
@@ -197,7 +204,7 @@ let cap = client
 
 Use `CapabilityIssueOptions { issued_to, valid_from_ms, valid_until_ms }` to restrict who may use the capability or set a validity window.
 
-**Key types** (from `audit_trail::core::types`): `Data`, `InitialRecord`, `ImmutableMetadata`, `LockingConfig`, `LockingWindow`, `TimeLock`, `Permission`, `PermissionSet`, `CapabilityIssueOptions`, `RoleTags`.
+**Key types** (from `audit_trails::core::types`): `Data`, `InitialRecord`, `ImmutableMetadata`, `LockingConfig`, `LockingWindow`, `TimeLock`, `Permission`, `PermissionSet`, `CapabilityIssueOptions`, `RoleTags`.
 
 ### Notarization example patterns
 

MOVE-DOC-STYLEGUIDE.md

@@ -172,7 +172,7 @@ For `Option<T>` returns, document both branches:
   abort list. The reader can follow the reference; we don't drift out of
   sync.
 - Inside the same module, omit the module prefix
-  (`` `add_record` `` rather than `` `audit_trail::main::add_record` ``).
+  (`` `add_record` `` rather than `` `audit_trails::main::add_record` ``).
 - Refer to permission variants by their bare enum name in backticks
   (`` `AddFoo` `` rather than `` `Permission::AddFoo` ``) — the
   context makes the type unambiguous and matches the permission constants
@@ -199,7 +199,7 @@ For `Option<T>` returns, document both branches:
   Field docs follow the same brevity rules as function summaries.
 - Error constants (`#[error] const E…`) carry the user-facing abort message;
   no separate doc comment is required when the message is self-explanatory.
-- Module-level docs (the `///` block above `module audit_trail::…;`) must
+- Module-level docs (the `///` block above `module audit_trails::…;`) must
   describe the module's purpose in one or two sentences.
 
 ## Don'ts

README.md

@@ -28,7 +28,7 @@ The toolkit includes:
 
 - **Single Notarization**
   Use this for individual locked or dynamic notarizations of arbitrary data, documents, hashes, or latest-state records.
-- **Audit Trail**
+- **Audit Trails**
   Use this for structured record histories with sequential entries, role-based access control, locking, and tagging.
 
 Each toolkit component is available as:
@@ -50,40 +50,40 @@ Use **Single Notarization** when your main need is proving the existence, integr
 
 ### I want an audit trail
 
-Use **Audit Trail** when you need a structured record history with permissions, capabilities, tagging, and write or delete controls.
+Use **Audit Trails** when you need a structured record history with permissions, capabilities, tagging, and write or delete controls.
 
-- [Audit Trail Rust Package](./audit-trail-rs)
-- [Audit Trail Move Package](./audit-trail-move)
-- [Audit Trail Wasm Package](./bindings/wasm/audit_trail_wasm)
-- [Audit Trail examples](./bindings/wasm/audit_trail_wasm/examples/README.md)
+- [Audit Trails Rust Package](./audit-trail-rs)
+- [Audit Trails Move Package](./audit-trail-move)
+- [Audit Trails Wasm Package](./bindings/wasm/audit_trail_wasm)
+- [Audit Trails examples](./bindings/wasm/audit_trail_wasm/examples/README.md)
 
 ### I want the on-chain contracts
 
 - [Single Notarization Move](./notarization-move)
-- [Audit Trail Move](./audit-trail-move)
+- [Audit Trails Move](./audit-trail-move)
 
 ### I want to build an application
 
 - [Single Notarization Rust](./notarization-rs)
-- [Audit Trail Rust](./audit-trail-rs)
+- [Audit Trails Rust](./audit-trail-rs)
 - [Single Notarization Wasm](./bindings/wasm/notarization_wasm)
-- [Audit Trail Wasm](./bindings/wasm/audit_trail_wasm)
+- [Audit Trails Wasm](./bindings/wasm/audit_trail_wasm)
 
 ## Toolkit Components
 
 | Component           | Best for                                                                    | Move Package                               | Rust Package                           | Wasm Package                                             |
 | ------------------- | --------------------------------------------------------------------------- | ------------------------------------------ | -------------------------------------- | -------------------------------------------------------- |
 | Single Notarization | Individual locked or dynamic notarizations for documents, hashes, and state | [`notarization-move`](./notarization-move) | [`notarization-rs`](./notarization-rs) | [`notarization_wasm`](./bindings/wasm/notarization_wasm) |
-| Audit Trail         | Shared sequential records with roles, capabilities, tagging, and locking    | [`audit-trail-move`](./audit-trail-move)   | [`audit-trail-rs`](./audit-trail-rs)   | [`audit_trail_wasm`](./bindings/wasm/audit_trail_wasm)   |
+| Audit Trails        | Shared sequential records with roles, capabilities, tagging, and locking    | [`audit-trail-move`](./audit-trail-move)   | [`audit-trail-rs`](./audit-trail-rs)   | [`audit_trail_wasm`](./bindings/wasm/audit_trail_wasm)   |
 
 ### Which one should I use?
 
 | Need                                                                      | Best fit            |
 | ------------------------------------------------------------------------- | ------------------- |
 | Locked proof object for arbitrary data                                    | Single Notarization |
 | Dynamic latest-state notarization flow                                    | Single Notarization |
-| Shared sequential records with roles, capabilities, and record tag policy | Audit Trail         |
-| Team or system audit log with governance and operational controls         | Audit Trail         |
+| Shared sequential records with roles, capabilities, and record tag policy | Audit Trails        |
+| Team or system audit log with governance and operational controls         | Audit Trails        |
 
 ## Documentation And Resources
 
@@ -95,12 +95,12 @@ Use **Audit Trail** when you need a structured record history with permissions,
 - [Single Notarization examples](./bindings/wasm/notarization_wasm/examples/README.md)
 - [IOTA Notarization Docs Portal](https://docs.iota.org/developer/iota-notarization)
 
-### Audit Trail
+### Audit Trails
 
-- [Audit Trail Rust Package README](./audit-trail-rs/README.md)
-- [Audit Trail Move Package README](./audit-trail-move/README.md)
-- [Audit Trail Wasm Package README](./bindings/wasm/audit_trail_wasm/README.md)
-- [Audit Trail examples](./bindings/wasm/audit_trail_wasm/examples/README.md)
+- [Audit Trails Rust Package README](./audit-trail-rs/README.md)
+- [Audit Trails Move Package README](./audit-trail-move/README.md)
+- [Audit Trails Wasm Package README](./bindings/wasm/audit_trail_wasm/README.md)
+- [Audit Trails examples](./bindings/wasm/audit_trail_wasm/examples/README.md)
 
 ### Shared
 
@@ -111,7 +111,7 @@ Use **Audit Trail** when you need a structured record history with permissions,
 [Foreign Function Interface (FFI)](https://en.wikipedia.org/wiki/Foreign_function_interface) bindings available in this repository:
 
 - [Web Assembly for Single Notarization](./bindings/wasm/notarization_wasm)
-- [Web Assembly for Audit Trail](./bindings/wasm/audit_trail_wasm)
+- [Web Assembly for Audit Trails](./bindings/wasm/audit_trail_wasm)
 
 ## Contributing
 

audit-trail-move/Move.toml

@@ -1,9 +1,9 @@
 [package]
-name = "IotaAuditTrail"
+name = "IotaAuditTrails"
 edition = "2024.beta"
 
 [dependencies]
 TfComponents = { git = "https://github.com/iotaledger/product-core.git", subdir = "components_move", rev = "v0.8.19" }
 
 [addresses]
-audit_trail = "0x0"
+audit_trails = "0x0"

audit-trail-move/README.md

@@ -16,11 +16,11 @@
 
 ---
 
-# IOTA Audit Trail Move Package
+# IOTA Audit Trails Move Package
 
 ## Introduction
 
-`audit-trail-move` is the on-chain Move package behind IOTA Audit Trail.
+`IotaAuditTrails` is the on-chain Move package behind IOTA Audit Trails.
 
 It defines the shared `AuditTrail` object and the supporting types needed for:
 
@@ -35,15 +35,15 @@ The package depends on `TfComponents` for reusable capability, role-map, and tim
 
 ## Modules
 
-- `audit_trail::main`
+- `audit_trails::main`
   Core shared object, events, trail lifecycle, record mutation, metadata updates, roles, and capabilities.
-- `audit_trail::record`
+- `audit_trails::record`
   Record payloads, initial records, and correction metadata.
-- `audit_trail::locking`
+- `audit_trails::locking`
   Locking configuration and lock evaluation helpers.
-- `audit_trail::permission`
+- `audit_trails::permission`
   Permission constructors and admin permission presets.
-- `audit_trail::record_tags`
+- `audit_trails::record_tags`
   Tag registry and role tag helpers.
 
 ## Development And Testing
@@ -81,7 +81,7 @@ The package history files [`Move.lock`](./Move.lock) and [`Move.history.json`](.
 
 ## Contributing
 
-We would love to have you help us with the development of IOTA Audit Trail. Each and every contribution is greatly valued.
+We would love to have you help us with the development of IOTA Audit Trails. Each and every contribution is greatly valued.
 
 Please review the [contribution](https://docs.iota.org/developer/iota-notarization/contribute) sections in the [IOTA Docs Portal](https://docs.iota.org/developer/iota-notarization/).