# Welcome

## The official [Hedera Guardian](https://guardian.hedera.com/) documentation

The Hedera Guardian is an open-source platform for creating, managing, and issuing digital environmental assets. Examples include credit issuance for carbon, renewable energy, and biodiversity; emission and financial disclosures; certifications; climate-smart commodities; and more. Through forms, automated workflows, and connected data streams, it links project developers, auditors, corporates, and standards bodies in a shared ecosystem, using the [Hedera network](https://hedera.com/?utm_source=guardian) as the trust layer. It leverages a customizable workflow engine, calculation engine, verifiable-credential based identity management, and web3 technology to ensure transparent and fraud-proof operations, making it a key tool for transforming sustainability practices and environmental markets. &#x20;

### **Methodology Digitalization and Trust**

Environmental markets depend on trust: trust that issued credits represent real and verifiable outcomes, that data hasn't been altered, and that the methodology and calculations behind a claim are sound. In the past, that trust was enforced through manual audits, closed registries, and siloed spreadsheets: developers and standards bodies routinely spent over $500,000–$1M+ to digitalize a single complex, 100+ page environmental methodology.&#x20;

Today, Guardian makes it programmable through **methodology digitalization**. Guardian policies encode methodology rules directly, the Hedera Network provides an immutable audit trail, and verifiable credentials let any participant confirm the chain of custody without needing to trust a central intermediary. This lowers costs, improves speed and efficiency, while accelerating collaboration across domains such as finance, technology, compliance, and ecology.

#### Want to learn more about methodology digitalization?&#x20;

[View the best practices guide to get started.](/methodology-digitalization/methodology-digitalization-best-practices)

### **Platform at a glance**

Guardian is built around a number of core aspects and understanding how they relate is a good foundation to navigate the docs further.

* **Guardian Policies** are the rules of an environmental methodology and can include data collection forms, role-based approval workflows, calculations, and dMRV endpoints all of which are run as executable software rather than static PDF documents. *A policy for Verra VM0047 specifies exactly what a project proponent submits, what a verifier approves, and how credits are calculated and issued.*
* **Schemas** define the structure of every data submission within a policy — fields, types, and validation rules that make data submissions consistent and machine-readable. *A renewable energy certificate schema requires meter ID, generation timestamp, and grid region.*
* **Calculation Engine** runs math blocks and formula-linked definitions within a policy, turning verified data into calculated quantities. *A water-quality policy converts nutrient-load reductions into tradable credits, while a carbon policy applies leakage, uncertainty, and buffer-pool deductions to net GHG results.*
* **Tokens** are the digital environmental assets produced at key points within a policy workflow and represent outcomes recorded on the Hedera network. *A carbon project mints credits from a shared buffer pool.*
* **TrustChain** is the verifiable audit trail that links every token back to the original submissions, approvals, and calculations that produced it. Any participant can inspect the full chain of custody without relying on a central intermediary. *A deforestation-free supply chain claim is traced end-to-end through every custody handoff to verify compliance.*
* **Standard Registry** is the platform role that publishes policies, onboards project participants, and manages credit issuance. It is the organizing entity for everything that happens in Guardian. *A voluntary carbon credit registry manages the authoring, review, and testing workflows for policies that implement the environmental methodologies they have developed.*&#x20;
* **Methodology Library** is the world's largest open source repository of digitalized environmental methodologies. Anyone can download, import, inspect, test, and run these methodologies. The authoring process continues to be improved through global collaborations and feedback helping to bring costs down for all. *A hackathon participant develops a wildfire fuel reduction methodology and publishes it to the Library; a metered energy cookstove methodology is updated from version 1.2 to 2.0 for registry testing and project developer adoption.*

### **Platform adopters and ecosystem**

Adoption of the Guardian has grown from an early concept in 2020 to a platform being used by dozens of innovative companies including the world’s leading carbon standards and auditors; project developers and enterprises. Ecosystem members have shared back 100+ open source contributors via GitHub, successfully issued numerous types of environmental assets, formed commercial partnerships, and developed the worlds largest open source methodology library. As you explore the platform, you'll notice mature capabilities developed in collaboration with a global ecosystem of stakeholders and community members — who we're grateful and proud of.

### **Where to start**

| I want to…                              | Start here                                                                                          |
| --------------------------------------- | --------------------------------------------------------------------------------------------------- |
| Install and run Guardian                | [Getting Started](/guardian/getting-started)                                                        |
| Create and publish policies             | [Workspace](/guardian/workspace)                                                                    |
| Digitalize an environmental methodology | [Methodology Digitalization](/methodology-digitalization/methodology-digitalization-best-practices) |
| Build on the Guardian API               | [API Reference / guardian](https://dev.guardian.hedera.com/api-reference-guardian/)                 |
| Explore what's published by Guardian    | [Explorers](/explorers/explorers-overview)                                                          |

### **Hedera Network Foundations**

Guardian publishes policy workflow data to the Hedera Network to support discovery and traceability.

Guardian records Hedera Consensus Service transactions in topics. A token mint transaction can include a memo identifier that points to a Hedera message timestamp. That message contains the URL of the related Verifiable Presentation (VP).

The VP links the Verifiable Credentials produced by the policy workflow. Together, these records provide the starting point for tracing the documents behind a token.

{% hint style="info" %}
HIP-19 and HIP-28 established foundational Hedera capabilities used by the Guardian on the Hedera Network
{% endhint %}

[HIP-19](https://hips.hedera.com/hip/hip-19) and [HIP-28](https://hips.hedera.com/hip/hip-28) define this foundational approach. Guardian builds on it through the [TrustChain](/guardian/platform/trustchain).

### **Open source community**

Establishing trust across climate and environmental markets is a hard, shared problem. No single organization can build the infrastructure that markets need on its own. Guardian exists because the problem requires open collaboration — on methodology digitalization, on verification standards, and technical workflows — to accelerate solutions to tough challenges.

Guardian is open source under the Apache 2.0 License and developed collaboratively by Hashgraph alongside carbon registries, auditors, project developers, governments, and enterprises building on the platform. Policies in the Methodology Library are contributed by organizations worldwide by registries, methodology authors, and independent developers.

Community calls, hands-on training sessions, and design workshops are regularly hosted. If you are building on the Guardian, digitizing a methodology, or improving the platform itself — contributions and feedback is welcome.

* [Contributing](/community-and-contributing/contributing)
* [Community Standards](/community-and-contributing/community-standards)
* [Methodology Library](https://github.com/hashgraph/guardian/tree/main/Methodology%20Library)
* [GitHub Milestones](https://github.com/hashgraph/guardian/milestones?sort=due_date\&direction=asc)
* [Share feedback or suggestions](mailto:guardian-feedback@hashgraph.com)

#### **Related**

* Concepts: [Architecture](/guardian/architecture)
* Guide: [Methodology Digitalization](/methodology-digitalization/methodology-digitalization-best-practices)


# Getting Started

Choose a path get started with Guardian.

{% hint style="info" %}
**Not sure where to start?**&#x20;

If you just want to see Guardian in action with minimal setup, we recommend the [**Managed Guardian Service**](https://www.climission.com/mgs?utm_source=guardian-docs), a SaaS offering from [Climission](https://www.climission.com/?utc_source=guardian-docs) who are co-maintainers of this project. If you want to run your own environment quickly, start with **Docker Quickstart**. If you're planning to fork, extend, or contribute to Guardian itself, go with **Build from Source**.
{% endhint %}

## Which path is right for you?

<table><thead><tr><th width="142.4140625">Scenario</th><th>Path</th><th>Best for</th><th>You manage</th><th width="189.2578125">Get started</th></tr></thead><tbody><tr><td><strong>Explore &#x26; evaluate</strong></td><td>Managed Guardian Service</td><td>Trying Guardian, demos, non-technical stakeholders, proof-of-concept</td><td>Nothing, its fully hosted</td><td><a href="https://www.climission.com/?utc_source=guardian">Managed Guardian Service</a></td></tr><tr><td><strong>Turn-key self-hosted</strong></td><td>Docker Quickstart</td><td>Running your own instance fast, technical evaluation, small production deployments</td><td>Your own infrastructure; Guardian handles the rest</td><td><a href="/pages/08i8IcJ6QmQG3fA6OjWR">Guardian README#Quickstart</a></td></tr><tr><td><strong>Extend &#x26; contribute</strong></td><td>Build from Source</td><td>Forking the project, custom development, contributing to core, non-standard configurations</td><td>Dependencies, configuration, upgrades, and the running environment</td><td><a href="https://github.com/hashgraph/guardian#readme">Guardian repository README</a></td></tr></tbody></table>

### Try Guardian without operating infrastructure

Check out the [Managed Guardian Service](https://climission.com/?utm_source=guardian) for a hosted environment to request a free trial.

Choose or explore this path if you do not want to install locally or operate infrastructure or are evaluating the product.

### Run open-source Guardian

[Open-source releases](https://github.com/hashgraph/guardian/releases) are available on GitHub.

Choose one of these paths:

* **Docker containers**: Suitable for users comfortable running and configuring services. This is the fastest way to get a self-hosted instance running.
* **Build from source**: Suitable for contributors and teams needing custom changes, forking the project, or hosting a modified instance. Requires more time and operational knowledge. You manage dependencies, configuration, upgrades, and the running environment.

## Ready to install?

Continue to the [Installation Guide](/guardian/getting-started/installation-guide).


# Guardian Glossary

| Term                                     | Definition                                                                                                                                                                                                                                                                                                                                                                                                                                      |
| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| W3C Decentralized Identifier             | W3C Decentralized Identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.                                        |
| W3C DID Document                         | A W3C DID Document expresses cryptographic material, verification methods, or services, which provide a set of mechanisms enabling a DID controller to prove control of the DID. Services enable trusted interactions associated with the DID subject.                                                                                                                                                                                          |
| W3C Verifiable Credential                | A W3C Verifiable Credential is a set of tamper-evident claims and metadata that cryptographically prove who issued it.                                                                                                                                                                                                                                                                                                                          |
| Credential Issuer                        | An entity that issues a W3C Verifiable Credential                                                                                                                                                                                                                                                                                                                                                                                               |
| Credential Holder                        | An entity in possession of a W3C Verifiable Credential. Note, the Credential Holder does not have to be the subject of the claims in the W3C Verifiable Credential.                                                                                                                                                                                                                                                                             |
| Credential Verifier                      | An entity that cryptographically and schematically verifies the conformance of a W3C Verifiable Credential with the W3C Verifiable Credential standard.                                                                                                                                                                                                                                                                                         |
| W3C Verifiable Presentation              | A Verifiable Presentation expresses data from one or more verifiable credentials, and is packaged in such a way that the authorship of the data is verifiable. If verifiable credentials are presented directly, they become verifiable presentations. Data formats derived from verifiable credentials that are cryptographically verifiable, but do not of themselves contain verifiable credentials, might also be verifiable presentations. |
| Policy Workflow Engine                   | Manages and monitors the state of required policy actions and the required information flow in a policy grouped into a policy workflow, and further determines which are the next policy actions based on the state of a policy workflow. The policy actions may be anything from saving an application form in a document management system to sending a reminder e-mail to users or escalating overdue items to management.                   |
| Policy Workflow                          | The execution of a series of causally connected and deterministic policy actions where the policy workflow or policy action participants are grouped into one or more workgroups that are attached to policy action of a policy workflow.                                                                                                                                                                                                       |
| Policy Action                            | One or more deterministic policy rules applied to the input of a policy action request producing an output of the policy action in the form of a state transition.                                                                                                                                                                                                                                                                              |
| Policy Workflow Group                    | A group of entities participating in a policy workflow.                                                                                                                                                                                                                                                                                                                                                                                         |
| Policy Workflow State Object             | A data object associated with a request for a Policy Action within a given Policy Workflow submitted by a participant in the Policy Workflow Group representing the state of the submitted request.                                                                                                                                                                                                                                             |
| Policy Action Request                    | Request for the execution a Policy Action on a Policy Workflow State Object within a given Policy Workflow submitted by a participant in the Policy Workflow Group using a Policy State Machine                                                                                                                                                                                                                                                 |
| Policy State Machine                     | A technical execution framework calculating the state transition of a Policy Workflow State Object based on a Policy Action Request and the relevant Policy Action instance.                                                                                                                                                                                                                                                                    |
| Policy State Machine Execution Framework | A set of rules allowing for a deterministic computation of a state transition of a Policy Workflow State Object through a Policy Action within a Policy Workflow                                                                                                                                                                                                                                                                                |


# Installation Guide

Install and run the open-source Guardian.

The [Guardian repository README](https://github.com/hashgraph/guardian#readme) provides the definitive installation instructions. It covers prerequisites, environment parameters, unit testing, and deployment options.

Choose an installation approach in the README:

* [Automatic Installation with Docker](https://github.com/hashgraph/guardian#automatic-installation)
* [Build and run manually](https://github.com/hashgraph/guardian#manual-installation)&#x20;

Find supported versions and the latest release notes in the [Guardian releases](https://github.com/hashgraph/guardian/releases).

### Want to go further?

[Development Environments & FAQs](/developer-tools-and-resources/dev-environments-and-faqs) covers local, default, development, and QA deployments. It also covers Docker, Kubernetes, Vault and KMS, upgrades, and session consistency.

Visit that section for additional details and advanced topics.

### Have questions or suggestions?

Send questions or suggestions to <guardian-feedback@hashgraph.com>. You can also review development milestones, open new issues, or pull requests for improvements: see [Contributing](/community-and-contributing/contributing).  For community support, [subscribe to the Guardian calendar and attend a future community call](https://luma.com/guardian).&#x20;


# Frameworks/Libraries

The Guardian platform uses the following major frameworks and libraries.

### Backend

* [NodeJS](https://nodejs.org/)
* [MongoDB](https://www.mongodb.com/)
* [NestJS](https://nestjs.com)
* [Nats](https://nats.io/)
* [MikroORM](https://mikro-orm.io/)
* [W3C VC-JS-HTTP](https://w3c.github.io/vc-data-model/)
* [Verifiable Credentials JS Library](https://github.com/digitalbazaar/vc)
* [MathJS](https://mathjs.org)
* [Filebase](https://filebase.com)
* [Kubo](https://github.com/ipfs/kubo)

### Frontend

* [Angular](https://angular.dev)
* [PrimeNG](https://primeng.org)


# Architecture

Understand Guardian's services, data flows, integrations, and signing paths.

This section explains how Guardian's services, data, and external integrations work together.

* [High Level Architecture](/guardian/architecture/architecture-2) introduces the platform's microservices and their relationships.
* [Deep Dive Architecture](/guardian/architecture/reference-architecture) shows the component-level design and modular implementation.
* [Policies, Projects and Topics Mapping Architecture](/guardian/architecture/schema-architecture) explains Hedera topic structures and policy data migration.
* [External Events](/guardian/architecture/external-events) covers event-driven integrations through NATS and webhooks.
* [MRV Splitting Logic](/guardian/architecture/mrv-splitting-logic) visualizes how MRV data is split.
* The [Vault](/guardian/architecture/internal-with-vault-signing-sequence-diagram) and [Fireblocks](/guardian/architecture/fireblocks-signing-sequence-diagram) sequence diagrams show the available signing paths.


# High Level Architecture

This Diagram represents all the micro services at a very high level.

<figure><img src="/files/vE6PgAm9t4RYt5OAA3NP" alt=""><figcaption></figcaption></figure>


# Deep Dive Architecture

This is a Deep Dive Architecture representing Micro Services at Component level.

This repo contains a reference implementation of the Guardian to learn how to use the components for various applications. This reference implementation is designed with modularity so that different components may be swapped out based on various implementation requirements. Please see the Guardian's architecture diagram below:

<figure><img src="/files/GGXMZQegmxaPe9ZGZPZ5" alt=""><figcaption></figcaption></figure>


# Policies,Projects and Topics Mapping Architecture

**Note:**

Guardian data migration is supported for published Policy instances which are yet to generate any data, i.e. are 'empty'.

As visible from the below Topic Architecture diagram, for each published Policy instance, irrespective of it being a new version of existing Policy or a new Policy altogether, a corresponding new Topic is created in Hedera. This action is coupled with a notification message sent to an appropriate topic, for the former it is the 'new version' message which is posted into the top-level original Policy Topic, for the latter it is the 'new policy' message which is posted into the Standard Registry Topic.

When Policy instance data is migrated into a new Policy instance, Guardian traverses all corresponding Topics and reposts all the messages, and resubmits all the previously generated documents into the new Topic structure (belonging to the new Policy instance). The documents may also be re-signed by the new Standard Registry if they have been modified (extended) during migration. Each of the messages and documents refer to original message/document in the corresponding "evidence" section of the document JSON.

Thus, the newly migrated data is usable as a stand-alone data tree and is backward compatible with all existing Guardian and 3rd party tools, while at the same time the original trail of documents is referenced and accessible which allows for incontrovertible trail of evidence for data provenance.

<figure><img src="/files/VkZdwDh4JyIIMKfpQxXh" alt=""><figcaption></figcaption></figure>


# External Events

Guardian processes tasks asynchronously. As operations complete, it publishes events to an internal NATS message broker. External systems can subscribe to these events to build reliable, event-driven integrations without polling.

There are two ways to consume Guardian events:

* **Direct NATS subscription** — connect your own NATS client to the same broker and subscribe to subjects directly.
* **Application Events Module** — a standalone HTTP service (port 3012) that subscribes to NATS on your behalf and forwards events to registered webhooks or a streaming endpoint. See [Application Events Module](/guardian/architecture/external-events/monitoring-tools/application-events-module).

***

## Subscription Patterns

Guardian events use two NATS interaction patterns.

### Publish / Subscribe

Events with pattern type `publish` follow the standard pub/sub model. The same message is delivered to every active subscriber. If multiple subscribers are running, ensure your application handles potential duplicate delivery.

```js
import { connect, JSONCodec } from "nats";

(async () => {
  const nc = await connect({ servers: "localhost:4222" });
  const c = JSONCodec();

  const sub = nc.subscribe("external-events.token_minted");

  (async () => {
    for await (const m of sub) {
      console.log(`[${sub.getProcessed()}]`, c.decode(m.data));
    }
    console.log("subscription closed");
  })();
})();
```

For more details see the [NATS.js publish/subscribe documentation](https://github.com/nats-io/nats.js#publish-and-subscribe).

### Request / Reply

Events with pattern type `request` require the subscriber to reply. Guardian waits for your response before proceeding. If no listener is registered, or the listener responds with an error, Guardian continues with the original content unmodified.

This pattern is used for IPFS content interception hooks (e.g., encryption/decryption of content before upload or after read).

```js
import { connect, JSONCodec, StringCodec } from "nats";
import * as zlib from "zlib";

(async () => {
  const nc = await connect({ servers: "localhost:4222" });
  const c = JSONCodec();

  const interceptContent = (type, transformFn) => {
    const sub = nc.subscribe(type);
    console.log("Listening to IPFS event:", type);

    (async () => {
      for await (const m of sub) {
        try {
          const payload = c.decode(m.data);
          const transformed = transformFn(Buffer.from(payload.content, "base64"));
          const responseMessage = { body: transformed.toString("base64") };
          const compressed = zlib.deflateSync(JSON.stringify(responseMessage)).toString("binary");
          m.respond(StringCodec().encode(compressed));
        } catch (e) {
          // Respond with error to signal Guardian to skip interception for this message
          const compressed = zlib.deflateSync(JSON.stringify({ error: e.message })).toString("binary");
          m.respond(StringCodec().encode(compressed));
        }
      }
    })();
  };

  // Example: intercept IPFS uploads with a custom transform
  interceptContent("external-events.ipfs_before_upload_content", (buf) => {
    // encrypt or transform buf here, return Buffer
    return buf;
  });
})();
```

***

## Event Reference

### Core External Events

These events are published by Guardian's core services and represent the primary integration surface for external systems.

| Event Subject                                | Pattern   | Description                                                              |
| -------------------------------------------- | --------- | ------------------------------------------------------------------------ |
| `external-events.token_minted`               | publish   | A Hedera token was successfully minted                                   |
| `external-events.token_mint_complete`        | publish   | All token minting operations for a batch are complete                    |
| `external-events.error_logs`                 | publish   | An error was written to the Guardian logger service                      |
| `external-events.block_event`                | publish   | A policy block execution event occurred                                  |
| `external-events.block_complete`             | publish   | Full async execution chain for a block data call has settled             |
| `external-events.ipfs_added_file`            | publish   | A file was successfully added to IPFS                                    |
| `external-events.ipfs_before_upload_content` | request   | Hook: intercept and optionally transform content before IPFS upload      |
| `external-events.ipfs_after_read_content`    | request   | Hook: intercept and optionally transform content after reading from IPFS |
| `external-events.ipfs_loaded_file`           | subscribe | A file load from IPFS has completed                                      |

***

### `external-events.token_minted`

**Pattern:** publish

**Trigger:** Guardian successfully mints a Hedera token during policy execution.

**Payload:**

```json
{
  "tokenId": "0.0.1554488",
  "tokenValue": 10,
  "memo": "policy-mint-batch-1"
}
```

| Field        | Type   | Description                                               |
| ------------ | ------ | --------------------------------------------------------- |
| `tokenId`    | string | Hedera token identifier (`shard.realm.num`)               |
| `tokenValue` | number | Number of tokens minted in this operation                 |
| `memo`       | string | Optional memo string associated with the mint transaction |

***

### `external-events.token_mint_complete`

**Pattern:** publish

**Trigger:** All pending token minting operations in a batch have completed.

**Payload:**

```json
{
  "tokenValue": 10
}
```

| Field        | Type   | Description                                                    |
| ------------ | ------ | -------------------------------------------------------------- |
| `tokenValue` | number | Total number of tokens that were minted in the completed batch |

***

### `external-events.error_logs`

**Pattern:** publish

**Trigger:** An error is written to the Guardian logger service by any internal service.

**Payload:**

```json
{
  "message": "failed store/add invocation",
  "type": "error",
  "attributes": {
    "service": "guardian-service",
    "code": "IPFS_UPLOAD_FAILED"
  }
}
```

| Field        | Type   | Description                                                   |
| ------------ | ------ | ------------------------------------------------------------- |
| `message`    | string | Human-readable error description                              |
| `type`       | string | Severity or error category                                    |
| `attributes` | object | Additional contextual attributes from the originating service |

***

### `external-events.block_event`

**Pattern:** publish

**Trigger:** A policy block executes an action that produces an external event (e.g., a user submits a form, a document is set, a timer fires).

**Payload:**

```json
[
  {
    "type": "Set",
    "blockUUID": "37c1b465-5261-4626-8972-f367301974a1",
    "blockType": "requestVcDocumentBlock",
    "blockTag": "applicant_form",
    "userId": "did:hedera:testnet:zHcDLGFNymFAJiMBKnpbHDgjvTn6yZnwkPPeFhtJBECH_0.0.4532001",
    "data": {
      "documents": []
    }
  }
]
```

The payload is an array of block event objects. Each object has:

| Field       | Type   | Description                                                                                                                                                                             |
| ----------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `type`      | string | Event type — one of `Run`, `Set`, `TickAggregate`, `TickCron`, `DeleteMember`, `StartCron`, `StopCron`, `SignatureQuorumReachedEvent`, `SignatureSetInsufficientEvent`, `Step`, `Chunk` |
| `blockUUID` | string | Unique identifier of the block that produced this event                                                                                                                                 |
| `blockType` | string | The block's type name (e.g., `requestVcDocumentBlock`, `mintDocumentBlock`)                                                                                                             |
| `blockTag`  | string | The human-readable tag assigned to the block in the policy editor                                                                                                                       |
| `userId`    | string | Hedera DID of the user who triggered the block action                                                                                                                                   |
| `data`      | object | Block-specific payload; structure varies by block type                                                                                                                                  |

***

### `external-events.block_complete`

**Pattern:** publish

**Trigger:** Triggered when the full async execution chain (downstream blocks, IPFS uploads, Hedera message submissions) for a `SET_BLOCK_DATA` / `SET_BLOCK_DATA_BY_TAG` call has settled — success or failure. The `trackingId` field matches the value returned in the API response, so external systems can correlate the event with their request without polling.

**Payload:**

```json
{
  "trackingId": "550e8400-e29b-41d4-a716-446655440000",
  "blockType": "requestVcDocumentBlock",
  "blockTag": "request_vc",
  "blockId": "3f2504e0-4f89-11d3-9a0c-0305e82c3301",
  "policyId": "6475a9e0-5f27-4ce3-b2f1-123456789abc",
  "userId": "did:hedera:testnet:z6MkHmF...",
  "status": "success",
  "timestamp": 1745123456789
}
```

| Field        | Type   | Description                                                       |
| ------------ | ------ | ----------------------------------------------------------------- |
| `trackingId` | string | UUID correlating this event to the originating API call           |
| `blockType`  | string | The block's type name                                             |
| `blockTag`   | string | The human-readable tag assigned to the block in the policy editor |
| `blockId`    | string | Unique identifier of the block                                    |
| `policyId`   | string | Identifier of the policy containing the block                     |
| `userId`     | string | Hedera DID of the user whose action triggered the chain           |
| `status`     | string | `success` or `failure`                                            |
| `timestamp`  | number | Unix epoch milliseconds when the chain settled                    |

***

### `external-events.ipfs_added_file`

**Pattern:** publish

**Trigger:** A file (document, schema, artifact) is successfully pinned to IPFS.

**Payload:**

```json
{
  "cid": "QmPs2ufs5VQPYGGX1ewEjKSR8zuEmeuWK4GBKFHZjXTCAQ",
  "url": "ipfs://QmPs2ufs5VQPYGGX1ewEjKSR8zuEmeuWK4GBKFHZjXTCAQ"
}
```

| Field | Type   | Description                     |
| ----- | ------ | ------------------------------- |
| `cid` | string | IPFS content identifier (CIDv0) |
| `url` | string | IPFS URI in `ipfs://` scheme    |

***

### `external-events.ipfs_before_upload_content`

**Pattern:** request/reply

**Trigger:** Guardian is about to upload content to IPFS. The content is delivered as a base64-encoded buffer.

**Payload received:**

```json
{
  "content": "<base64-encoded file content>"
}
```

**Expected reply:**

Return a zlib-deflated JSON object with the (optionally transformed) content:

```json
{
  "body": "<base64-encoded transformed content>"
}
```

To skip transformation and signal an error, respond with:

```json
{
  "error": "reason for skipping"
}
```

If no listener is registered, or the listener responds with an error, Guardian uploads the original content unchanged.

> **Note:** This event is a request/reply hook. It is not forwarded by the Application Events Module. Subscribe directly via NATS.

***

### `external-events.ipfs_after_read_content`

**Pattern:** request/reply

**Trigger:** Guardian has just read content from IPFS. Use this hook to decrypt or post-process content before Guardian consumes it.

**Payload received:**

```json
{
  "content": "<base64-encoded file content>"
}
```

**Expected reply:** Same structure as `ipfs_before_upload_content`. Return the transformed content or an error object.

> **Note:** This event is a request/reply hook. It is not forwarded by the Application Events Module. Subscribe directly via NATS.

***

### `external-events.ipfs_loaded_file`

**Pattern:** subscribe

**Trigger:** An asynchronous IPFS file load has completed (either successfully or with an error).

**Payload:**

```json
{
  "taskId": "be1c8bc2-c100-47c5-af48-46c10b5fde55",
  "fileContent": "<base64-encoded file content>",
  "error": null
}
```

| Field         | Type           | Description                                               |
| ------------- | -------------- | --------------------------------------------------------- |
| `taskId`      | string         | UUID correlating this result to the original load request |
| `fileContent` | string         | Base64-encoded file content; present on success           |
| `error`       | string \| null | Error message if the load failed; `null` on success       |

> **Note:** This event is not forwarded by the Application Events Module. Subscribe directly via NATS.

***

## Policy Engine Events

In addition to the core external events above, the Application Events Module also surfaces Guardian's internal policy coordination events. These are emitted on NATS subjects from the `PolicyEvents` and `PolicyEngineEvents` enumerations (e.g., `policy-event-policy-ready`, `policy-engine-event-publish-policies`).

These events are intended for advanced integrations that need to react to specific policy lifecycle transitions. They are available through the Application Events Module's streaming endpoint and webhook registration. Use **`GET /api/events`** on the Application Events Module to retrieve the complete list of exposed event subjects at runtime.

***

## Reference Implementation

A complete Node.js reference client demonstrating publish/subscribe and request/reply patterns (including IPFS content encryption) is available at:

[`common/src/mq/sample-external-client.ts`](https://github.com/hashgraph/guardian/blob/main/common/src/mq/sample-external-client.ts)


# Monitoring Tools

Guardian's monitoring tools provide infrastructure for external systems to observe and react to Guardian's internal event stream without requiring a direct NATS connection.

## Application Events Module

The [Application Events Module](/guardian/architecture/external-events/monitoring-tools/application-events-module) is a standalone HTTP service (port `3012`) that:

* Subscribes to all Guardian NATS event subjects on startup
* Exposes a REST API for registering and managing webhooks
* Delivers events to registered webhook URLs via HTTP POST
* Provides a streaming JSON endpoint for real-time event consumption

| Capability                        | Endpoint                    |
| --------------------------------- | --------------------------- |
| Register a webhook                | `POST /api/webhooks`        |
| List registered webhooks          | `GET /api/webhooks`         |
| Retrieve a single webhook         | `GET /api/webhooks/{id}`    |
| Update a webhook                  | `PUT /api/webhooks/{id}`    |
| Delete a webhook                  | `DELETE /api/webhooks/{id}` |
| List all available event subjects | `GET /api/events`           |
| Subscribe to live event stream    | `GET /api/events/subscribe` |
| Interactive API documentation     | `GET /api-docs`             |

For full details see [Application Events Module](/guardian/architecture/external-events/monitoring-tools/application-events-module).


# Application-events module

The Application Events Module is a standalone service that bridges Guardian's internal NATS event bus and external HTTP-based systems. It removes the need for external integrators to operate their own NATS client by providing:

* A **webhook registry** — register HTTP endpoints that receive event payloads via POST.
* A **streaming endpoint** — consume all events as a chunked JSON stream over HTTP.
* A **REST API** — manage webhook subscriptions and enumerate available event subjects.

The service runs on port `3012` by default. Interactive Swagger documentation is available at `http://localhost:3012/api-docs`.

***

## Architecture

```
Guardian Services
      │
      │ publishes events to
      ▼
   NATS Broker
      │
      │ subscribed by
      ▼
Application Events Module (port 3012)
      │
      ├──► Registered Webhooks (HTTP POST to your URLs)
      │
      └──► GET /api/events/subscribe (chunked JSON stream)
```

On startup the module:

1. Connects to MongoDB to load persisted webhook registrations.
2. Connects to the NATS broker and subscribes to all exposed event subjects.
3. For each received message, delivers the payload to all matching registered webhooks.

***

## Quickstart: Subscribe via Streaming Endpoint

The simplest way to consume events is the streaming endpoint. It returns a chunked JSON array that stays open as long as the connection is alive. Each element is a JSON object with the event subject and payload.

```bash
curl -N http://localhost:3012/api/events/subscribe
```

Example stream output:

```json
[
{"subject":"external-events.token_minted","payload":{"tokenId":"0.0.1554488","tokenValue":10}},
{"subject":"external-events.ipfs_added_file","payload":{"cid":"QmPs2ufs5VQPYGGX1ewEjKSR8zuEmeuWK4GBKFHZjXTCAQ","url":"ipfs://QmPs2ufs5VQPYGGX1ewEjKSR8zuEmeuWK4GBKFHZjXTCAQ"}},
```

The stream remains open. When the NATS connection closes, the array is terminated with `{"connection":"closed"}]`.

***

## Quickstart: Register a Webhook

**Step 1 — Retrieve the list of available event subjects:**

```bash
curl http://localhost:3012/api/events
```

Returns a JSON array of all event subject strings the module is currently forwarding, for example:

```json
[
  "external-events.token_minted",
  "external-events.token_mint_complete",
  "external-events.error_logs",
  "external-events.block_event",
  "external-events.ipfs_added_file",
  "policy-event-policy-ready",
  "policy-engine-event-publish-policies",
  ...
]
```

**Step 2 — Register a webhook for one or more event subjects:**

```bash
curl -X POST http://localhost:3012/api/webhooks \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-system.example.com/guardian-events",
    "events": [
      "external-events.token_minted",
      "external-events.block_event"
    ]
  }'
```

**Response `201 Created`:**

```json
{
  "id": "63e3e5e8a01b3c001234abcd"
}
```

**Step 3 — Receive events at your endpoint:**

When Guardian mints a token, your endpoint will receive an HTTP POST:

```json
{
  "tokenId": "0.0.1554488",
  "tokenValue": 10,
  "memo": "policy-mint"
}
```

***

## REST API Reference

### List Available Event Subjects

**`GET /api/events`**

Returns the complete list of NATS event subjects the module is currently subscribed to and will forward to webhooks or the streaming endpoint.

**Status:** `200 OK`

```json
[
  "external-events.token_minted",
  "external-events.token_mint_complete",
  "external-events.error_logs",
  "external-events.block_event",
  "external-events.ipfs_added_file",
  "policy-event-generate-policy",
  "policy-event-policy-ready",
  "..."
]
```

***

### Subscribe to Event Stream

**`GET /api/events/subscribe`**

Opens a persistent chunked HTTP response. Each chunk is a JSON object:

```json
{"subject": "<event-subject>", "payload": <event-payload>}
```

The response uses `Transfer-Encoding: chunked` and `Content-Type: application/json`. The stream starts with `[` and each element is separated by `,\n`. The array is closed when the NATS connection terminates.

**Status:** `200 OK` (streaming)

***

### Register a Webhook

**`POST /api/webhooks`**

Persists a new webhook registration. The module will HTTP POST the event payload to `url` whenever an event matching one of the registered `events` subjects is received.

**Request Body:**

```json
{
  "url": "https://your-system.example.com/events",
  "events": [
    "external-events.token_minted",
    "external-events.block_event"
  ]
}
```

| Field    | Type      | Required | Description                                                                     |
| -------- | --------- | -------- | ------------------------------------------------------------------------------- |
| `url`    | string    | Yes      | Publicly reachable HTTPS URL that accepts POST requests                         |
| `events` | string\[] | No       | List of event subjects to subscribe to; omit or pass `[]` to receive all events |

**Status:** `201 Created`

```json
{
  "id": "63e3e5e8a01b3c001234abcd"
}
```

| Field | Description                                          |
| ----- | ---------------------------------------------------- |
| `id`  | MongoDB ObjectId of the created webhook registration |

**Error Responses:**

| Status                      | Description                           |
| --------------------------- | ------------------------------------- |
| `400 Bad Request`           | Request body failed schema validation |
| `500 Internal Server Error` | Database write failed                 |

***

### List Registered Webhooks

**`GET /api/webhooks`**

Returns all persisted webhook registrations.

**Status:** `200 OK`

```json
[
  {
    "_id": "63e3e5e8a01b3c001234abcd",
    "url": "https://your-system.example.com/events",
    "events": ["external-events.token_minted"],
    "createdAt": "2026-04-06T08:00:00.000Z"
  }
]
```

***

### Retrieve a Webhook

**`GET /api/webhooks/{id}`**

Returns a single webhook registration by its MongoDB ObjectId.

**Path Parameters:**

| Parameter | Type   | Required | Description                     |
| --------- | ------ | -------- | ------------------------------- |
| `id`      | string | Yes      | MongoDB ObjectId of the webhook |

**Status:** `200 OK`

```json
{
  "_id": "63e3e5e8a01b3c001234abcd",
  "url": "https://your-system.example.com/events",
  "events": ["external-events.token_minted"],
  "createdAt": "2026-04-06T08:00:00.000Z"
}
```

**Error Responses:**

| Status          | Description                           |
| --------------- | ------------------------------------- |
| `404 Not Found` | No webhook exists with the given `id` |

***

### Update a Webhook

**`PUT /api/webhooks/{id}`**

Replaces the `url` and `events` fields of an existing webhook registration.

**Path Parameters:**

| Parameter | Type   | Required | Description                     |
| --------- | ------ | -------- | ------------------------------- |
| `id`      | string | Yes      | MongoDB ObjectId of the webhook |

**Request Body:**

```json
{
  "url": "https://your-system.example.com/new-endpoint",
  "events": [
    "external-events.token_minted",
    "external-events.token_mint_complete"
  ]
}
```

| Field    | Type      | Required | Description                    |
| -------- | --------- | -------- | ------------------------------ |
| `url`    | string    | Yes      | Updated destination URL        |
| `events` | string\[] | Yes      | Updated list of event subjects |

**Status:** `204 No Content`

**Error Responses:**

| Status            | Description                           |
| ----------------- | ------------------------------------- |
| `400 Bad Request` | Request body failed schema validation |
| `404 Not Found`   | No webhook exists with the given `id` |

***

### Delete a Webhook

**`DELETE /api/webhooks/{id}`**

Removes a webhook registration. The module will immediately stop forwarding events to the associated URL.

**Path Parameters:**

| Parameter | Type   | Required | Description                               |
| --------- | ------ | -------- | ----------------------------------------- |
| `id`      | string | Yes      | MongoDB ObjectId of the webhook to delete |

**Status:** `204 No Content`

***

## Available Event Subjects

The module exposes all events from three sources, minus internal request/reply hooks that are not suitable for HTTP delivery. Use `GET /api/events` to retrieve the live list. The categories are:

### Core External Events

| Subject                               | Description                      |
| ------------------------------------- | -------------------------------- |
| `external-events.token_minted`        | Token successfully minted        |
| `external-events.token_mint_complete` | Mint batch complete              |
| `external-events.error_logs`          | Error written to Guardian logger |
| `external-events.block_event`         | Policy block execution event     |
| `external-events.ipfs_added_file`     | File pinned to IPFS              |

> The following subjects are **excluded** from webhook/stream delivery because they are request/reply hooks requiring a synchronous NATS response: `external-events.ipfs_before_upload_content`, `external-events.ipfs_after_read_content`, `external-events.ipfs_loaded_file`

### Policy Coordination Events (selected)

| Subject                                | Description                                              |
| -------------------------------------- | -------------------------------------------------------- |
| `policy-event-generate-policy`         | Policy instance generation started                       |
| `policy-event-policy-ready`            | Policy instance is ready to serve requests               |
| `policy-event-policy-start-error`      | Policy failed to start                                   |
| `policy-event-delete-policy`           | Policy instance deleted                                  |
| `policy-event-block-update-broadcast`  | A block's state changed and UI should refresh            |
| `policy-event-mrv-data`                | MRV (measurement, reporting, verification) data received |
| `policy-event-record-update-broadcast` | Recording state changed                                  |

### Policy Engine Events (selected)

| Subject                                     | Description                                 |
| ------------------------------------------- | ------------------------------------------- |
| `policy-engine-event-create-policies`       | New policy created                          |
| `policy-engine-event-publish-policies`      | Policy published to Hedera                  |
| `policy-engine-event-dry-run-policies`      | Policy entered dry-run mode                 |
| `policy-engine-event-draft-policies`        | Policy reverted to draft                    |
| `policy-engine-event-delete-policy-async`   | Async policy deletion started               |
| `policy-engine-event-migrate-data`          | Policy data migration started               |
| `policy-engine-event-receive-external-data` | External data submitted to a running policy |

The full enumeration of all policy coordination and engine event subjects is defined in:

* [`interfaces/src/type/messages/policy-events.ts`](https://github.com/hashgraph/guardian/blob/main/interfaces/src/type/messages/policy-events.ts)
* [`interfaces/src/type/messages/policy-engine-events.ts`](https://github.com/hashgraph/guardian/blob/main/interfaces/src/type/messages/policy-engine-events.ts)

***

## Webhook Delivery

When an event is received on a subscribed NATS subject, the module iterates over all registered webhooks whose `events` array includes that subject and performs an HTTP POST to each registered URL.

* **Method:** `POST`
* **Content-Type:** `application/json`
* **Body:** The raw event payload (the object published on NATS)

Delivery is best-effort. If a webhook URL returns an error or times out, the failure is logged and the module moves on. There is no built-in retry mechanism — design your endpoint to be idempotent and implement your own retry handling if required.

***

## Configuration

The module is configured via environment variables. The key variables are:

| Variable      | Default | Description                                         |
| ------------- | ------- | --------------------------------------------------- |
| `PORT`        | `3012`  | HTTP port the service binds to                      |
| `MONGODB_URI` | —       | MongoDB connection string for webhook persistence   |
| `MQ_ADDRESS`  | —       | NATS broker address (e.g., `nats://localhost:4222`) |

Refer to the `application-events/.env.example` file in the repository for the complete list.


# MRV Splitting Logic

<figure><img src="/files/WFkxzHaKU3724ki0rF4P" alt=""><figcaption></figcaption></figure>


# Internal (with Vault)Signing Sequence Diagram

<figure><img src="/files/7cBtZdSPcFoMFFlV0PVZ" alt=""><figcaption></figcaption></figure>


# FireBlocks Signing Sequence Diagram

<figure><img src="/files/qIpqGkBvmE6JOyWMLYy4" alt=""><figcaption></figcaption></figure>


# Workspace

The Workspace navigation section is where you build and manage policy assets. These include schemas, policy logic, artifacts, tools, and modules. You create these assets and can export them with a policy.

### Reference

Workspace is organized into the building blocks of a policy, grouped under **Manage**:

* **Policies** — the set of rules, roles, workflows, and data-handling logic that governs how credentials, attestations, and reports are issued, verified, and used within a methodology or project.
* **Schemas** — structured data definitions that describe the format, attributes, and validation rules for the Verifiable Credentials and Presentations used within a policy.
* **Schema Rules** — validation logic that checks whether values entered into a schema's fields fall within acceptable ranges, using formulas or conditional (if/then/else) logic sourced from any field in the policy.
* **Schema Templates** — standalone entities that own a set of schemas and locking rules outside any policy, so a policy can apply a template, get policy-local copies of its schemas, and stay in sync as the template evolves.
* **Artifacts** — JSON files that represent a policy's or workflow's structure: rules, conditions, actions, parameters, and metadata.
* **Tools** — component-based, standardized pieces of policy logic, linked to policies by reference rather than fully embedded, with restricted editability and the ability to nest other Tools.
* **Modules** — encapsulated, independently-operable units of functionality that can be combined to build policies, workflows, and other system capabilities.
* **Formulas** — human-readable views of a policy's calculation logic, mapping the math variables in a formula back to the schema and document fields they represent.

Each of these lives inside Workspace because it's something you directly author, edit, and own as part of building a policy. To explore capabilities that support these assets and creation workflows, such as roles and permissions, notifications, task status, or search visit the [Platform](/guardian/platform) section.

### Related

* [Policies](/guardian/workspace/policies)
* [Schemas](/guardian/workspace/schemas)
* [Tools](/guardian/workspace/tools)
* [Modules](/guardian/workspace/modules)
* [Artifacts](/guardian/workspace/artifacts)


# Policies

A policy collection of rules, roles, workflows, and data-handling logic that governs how documents (verified credentials), attestations, and reports are issued, verified, and used within an environmental methodology or project.

Policies act like a smart contract template for dMRV orchestrated off-chain by the Guardian where critical checkpoints are anchored to the Hedera network.

#### **Key Components of a Policy**

1. **Policy Roles & Permissions**
   * Define which actors (e.g., Project Developer, Verifier, Standard Body, Registry) can perform specific actions.
   * Example: Only a Verifier role can issue verification credentials.
2. **Schemas**
   * Policies use schemas to structure the data being collected or issued as credentials.
   * Example: A "Project Description VC" schema or "Monitoring Report VC" schema.
3. **Policy Workflows**
   * Step-by-step processes for participants.
   * Example: A Project Developer submits project details → Verifier reviews → Standard Body approves.
4. **Rules & Conditions**
   * Validation checks on data, sequencing of steps, and compliance enforcement.
   * Example: A monitoring report VC must match the schema and include forest carbon flux data before approval.
5. **Credential Lifecycle**
   * Policies define when and how Verifiable Credentials (VCs) and Verifiable Presentations (VPs) are created, validated, mapped, or revoked.
6. **Automation & Anchoring**
   * Automates issuance, verification, and tracking of digital assets (tokens, credits).
   * Anchors hashes of VCs/VPs to the Hedera Consensus Service (HCS) or Hedera Token Service (HTS) for transparency and immutability.


# Policy Glossary

The following terms are used when creating Policies within the Guardian.

| Term                  | Definition                                                                                                          | Example                                                                                                                         |
| --------------------- | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Block                 | Either a Policy Workflow or a Policy Action                                                                         | MRVDataVerification (Policy Workflow)                                                                                           |
| `children`            | Defines a list of Blocks that are grouped into a Policy Workflow                                                    | List of Blocks                                                                                                                  |
| `defaultActive`       | Determines if Policy Workflow or a Policy Action can be executed                                                    | `true`                                                                                                                          |
| `permissions`         | Security Policy associated with a specific role                                                                     | `STANDARD_REGISTRY`                                                                                                             |
| `blockType`           | Specifies the type of Policy Workflow or Policy Action                                                              | `interfaceContainerBlock` (policy workflow name)                                                                                |
| `uiMetaData`          | Specifies the data of the policy workflow and/or Policy Action to be displayed                                      | `type: header___` `fields:___________` `name: document.issuer` `title: Owner_____` `type: text`                                 |
| `tag`                 | Specifies the ID of a policy action which can be referenced in other blocks as a dependency                         | `Request`                                                                                                                       |
| `schema`              | Defines the data schema for a block                                                                                 | `Installer` or `MRV`                                                                                                            |
| `dataType`            | Specifies the Type of data used in the Block                                                                        | `source`                                                                                                                        |
| `dependencies`        | Specifies which blocks `tag` or state transition rules `stateMutation`                                              | See `tag` for referencing other Policy actions and `stateMutation` is a specific example of the name of a state transition rule |
| `roles`               | Available roles from which the user can choose.                                                                     | `Auditor`                                                                                                                       |
| `cyclic`              | Go back one step to enable the creation of the previous object.                                                     | `true`                                                                                                                          |
| `stop propagation`    | End processing here, don't pass control to the next block.                                                          | `true`                                                                                                                          |
| `entityType`          | Gives the document a label in the DB. Needed for filtering.                                                         | `Installer`                                                                                                                     |
| `forceNewDocument`    | Adds new Document                                                                                                   | `true`                                                                                                                          |
| `options`             | List of attributes, which is added to the VC when it is being persistent. Can be used for more flexible filtration. | <p>"name": "status"</p><p>"value": "Minted",</p>                                                                                |
| `documentType`        | Type of Document                                                                                                    | VC/VP/DID                                                                                                                       |
| `topic`               | Specifies Topic Name                                                                                                | topic                                                                                                                           |
| `actor`               | Specifies a person, who will be next Owner                                                                          | Owner/Policy Owner                                                                                                              |
| `issuer`              | Specifies a person, who will be Signer                                                                              | owner / Policy Owner                                                                                                            |
| `onlyOwnDocuments`    | Specifies whether a block applies to only those documents owned by the role specified in `permissions`              | `true` or `false`                                                                                                               |
| `ViewHistory`         | Specifies documents in the Grid with status timeline                                                                | `true` or `false`                                                                                                               |
| `on errors`           | Specifies if the error has occurred in the Block                                                                    | Retry/Go to step/Go to tag                                                                                                      |
| `onlyAssignDocuments` | Specifies which VC should be assigned to the user                                                                   | `true` or `false`                                                                                                               |


# Policy Creation

Policy creation in Hedera Guardian is the foundation for digitizing sustainability standards. It transforms rules into automated, transparent workflows, ensuring trust, compliance, and scalability in environmental asset management.

**Importance of Policy Creation**

1. **Standardization of Methodologies**
   * Digitizes environmental standards into consistent, enforceable rules.
   * Ensures all participants follow the same verified process.
2. **Transparency & Trust**
   * Anchors policy actions (VCs, approvals, tokens) to Hedera.
   * Creates an immutable, auditable trail of activities.
3. **Automation of Workflows**
   * Replaces manual verification with automated checks and triggers.
   * Reduces errors, costs, and administrative overhead.
4. **Interoperability**
   * Policies use W3C-compliant VCs and schemas, enabling global compatibility across registries, standards bodies, and marketplaces.
5. **Flexibility & Governance**
   * Supports versioning for methodology updates.
   * Allows controlled deprecation of outdated policies.
6. **Scalability**
   * Enables large-scale deployment of sustainability projects (thousands of projects under a single policy template).
7. **Regulatory Compliance**
   * Encodes the requirements of standards bodies into enforceable workflows.
   * Provides verifiable proof of compliance for audits and reporting.


# Policy Configurator

The Policy Configurator is the visual editing environment in which a Standard Registry builds and maintains a policy – the executable definition of a methodology, made up of blocks, roles, schemas, tokens, and the events that connect them.

## The Problem It Solves

A Guardian policy is ultimately a single large JSON configuration. Written by hand, that configuration is unforgiving: block tags must be unique, events must reference blocks that exist, every form block must point at a valid schema, and every mint block at a valid token. A misspelled tag or an orphaned event is not visible until the policy is run, and by then the failure surfaces as a broken workflow rather than an obvious typo.

The Configurator removes that class of error from the authoring process. It presents the policy as a navigable tree instead of nested braces, offers only the property values that are valid in context, and validates the whole configuration on demand – so structural mistakes are caught while editing rather than during a project's first submission.

It also solves a collaboration problem. Methodology experts, not developers, own the rules being digitized. A visual editor lets them read, review, and adjust a policy without reading JSON, while still producing exactly the same artifact a developer would.

## How It Works

The Configurator is opened from a policy in **Draft** status and edits that draft in place. Nothing is published to Hedera while editing; the draft is a working copy that can be revised freely until it is dry-run or published.

**A policy is a tree of blocks.** Every policy starts from a single container block and nests other blocks inside it. Each block has a type that determines what it does – rendering a form, requesting a signature, minting a token, calling an external service – and a set of properties that configure that behavior. The Configurator shows this hierarchy in the tree panel on the left; selecting a block loads its properties into the panel on the right.

**Blocks are addressed by tag.** Each block carries a tag that is unique within the policy. Tags are how blocks refer to each other: an event that moves a document from one step to the next names its source and target by tag, not by position in the tree. This is why moving a block within the tree does not break the workflow, and why renaming a tag does.

**Events connect blocks into a workflow.** The tree describes containment; events describe flow. An event fires when something happens in one block – a document is approved, a form is submitted, a timer elapses – and triggers an action in another. Together, the tree and the event graph are what turn a set of blocks into a working process.

**The same policy has three representations.** The Configurator can display the policy as a **tree**, as **JSON**, or as **YAML**, and switching between them converts the current state rather than opening a different document. The tree is the primary editing surface; the text views exist for bulk edits, diffing, and copying configuration between policies. An edit made in any view is an edit to the same underlying configuration.

**Reusable parts come from modules and tools.** Alongside blocks, the Configurator exposes modules and tools – self-contained fragments of policy logic that can be dropped into a policy and edited as a unit. Tools are published and versioned independently, so a policy can adopt a shared, already-validated piece of logic instead of duplicating it.

**Validation is explicit.** The Configurator can validate the entire configuration and report problems against the specific blocks that caused them. A policy that fails validation can still be saved as a draft; it cannot be meaningfully run.

**Editing ends at dry run or publish.** A dry run executes the policy in an isolated environment with virtual users and no Hedera transactions, so the workflow can be exercised before it becomes permanent. Publishing releases a numbered version of the policy to the public domain, at which point the configuration is frozen – further changes require a new version.

## Key Distinctions

**Policy Configurator vs. Policy Wizard.** The Wizard asks a series of questions and generates a policy configuration from the answers. It is a starting point that produces a conventional structure quickly, and its output is an ordinary draft policy. The Configurator is where that draft – or any other policy – is refined, extended, and maintained. The Wizard creates; the Configurator edits.

**Policy Configurator vs. the Policy APIs.** The APIs read and write the same policy configuration programmatically, and are the right tool for automation, CI pipelines, and migrations. The Configurator is the interactive equivalent, aimed at authoring and review rather than repeatable scripted changes.

**Configuring a policy vs. running one.** The Configurator defines what a policy will do. Executing it – registering users, submitting documents, minting tokens – happens in the policy's own interface once it is dry-run or published, and is not part of the Configurator.

## Related

* [Creating a Policy through Policy Configurator](/guardian/tutorials/creating-a-policy-through-policy-configurator) – step-by-step construction of a policy in the editor
* [Getting Started with the Policy Workflows](/guardian/tutorials/creating-a-policy-through-policy-configurator/getting-started-with-the-policy-workflows) – the first blocks of a working policy
* [Available Policy Workflow Blocks](/guardian/workspace/policies/policy-creation/introduction) – the specification for every block type and its properties


# Available Policy Workflow Blocks

Starting with the [Wikipedia definition](https://en.wikipedia.org/wiki/Workflow_engine), a Policy Workflow Engine (PWE) is a software application that manages business processes based on business rules and business data which are defined within the context of a specific policy. A PWE, therefore, manages and monitors the state of required policy actions and the required information flow in a policy grouped into a policy workflow, and determines which are the next policy actions based on the state of a policy workflow. The policy actions may be anything from saving an application form in a document management system to sending a reminder e-mail to users or escalating overdue items to management. Policy Workflow Blocks enable different business logic to exist within the Guardian’s PWE.

### Available Policy Workflows Blocks

<table><thead><tr><th align="center">Block</th><th width="226.33333333333331" align="center">Definition</th><th align="center">Documentation Link</th></tr></thead><tbody><tr><td align="center">InterfaceContainerBlock</td><td align="center">A block which contains and organizes other blocks.</td><td align="center"><a href="/pages/KxODrErWroJ2Qfr6hTZw">InterfaceContainerBlock</a></td></tr><tr><td align="center">PolicyRolesBlock</td><td align="center">A block which determines a role for the user.</td><td align="center"><a href="/pages/6cVQzZ2iITgvyjt7Ixvc">PolicyRolesBlock</a></td></tr><tr><td align="center">InterfaceStepBlock</td><td align="center">Similar to the InterfaceContainerBlock, with the difference that it can only render a single child element.</td><td align="center"><a href="/pages/WVfvk2CXNaNTrkewRkzw">InterfaceStepBlock</a></td></tr><tr><td align="center">requestVCDocumentBlock</td><td align="center">A type of the block which creates a form from the schema, and sends the document to the server.</td><td align="center"><a href="/pages/OdPt6rpdp9tg9zmpUGQy">requestVCDocumentBlock</a></td></tr><tr><td align="center">sendToGuardianBlock</td><td align="center">A type of the block which can save a new or updated document.</td><td align="center"><a href="/pages/puXpj9PkEjjZGUsnCCHN">sendToGuardianBlock</a></td></tr><tr><td align="center">reassigningBlock</td><td align="center">A type of block which re-signs the document and change the user to document owner.</td><td align="center"><a href="/pages/SuNKxcpCnK4w7BcaDXfl">reassigningBlock</a></td></tr><tr><td align="center">InformationBlock</td><td align="center">A block type which can display a notification or a progress bar.</td><td align="center"><a href="/pages/IYvxjIVuBQENGCUCEDg9">InformationBlock</a></td></tr><tr><td align="center">InterfaceDocumentsSourceBlock</td><td align="center">A block type which outputs information from the DB as grid.</td><td align="center"><a href="/pages/qGivLPcEvQDctVr3EHYA">InterfaceDocumentsSourceBlock</a></td></tr><tr><td align="center">paginationAddon</td><td align="center">A block type which adds pagination to the InterfaceDocumentSourceBlock if added</td><td align="center"><a href="/pages/5DMoBqPR2qCFUYgkftc9">paginationAddon</a></td></tr><tr><td align="center">DocumentsSourceAddOn</td><td align="center">A type of block for searching VC as grid</td><td align="center"><a href="/pages/hCyLKjNs5h8wqo8DGhqs">DocumentsSourceAddOn</a></td></tr><tr><td align="center">filtersAddOn</td><td align="center">A child block for 'DocumentsSourceAddon'. Contains additional dynamic filters</td><td align="center"><a href="/pages/KJ45lTZnsbcxYLvKBCHX">filtersAddOn</a></td></tr><tr><td align="center">InterfaceActionBlock</td><td align="center">A block to create custom actions.</td><td align="center"><a href="/pages/mfI9prQxOERUc2JvH5G7">InterfaceActionBlock</a></td></tr><tr><td align="center">externalDataBlock</td><td align="center">Receives data from the external source and passes them over the the next block.</td><td align="center"><a href="/pages/VnMehxszXX5tjEYiaVSY">externalDataBlock</a></td></tr><tr><td align="center">retirementDocumentBlock</td><td align="center">Receives the VC from the previous block and retires based on the rule(s).</td><td align="center"><a href="/pages/xjVnuec3JH8dXBnIDIgA">retirementDocumentBlock</a></td></tr><tr><td align="center">calculateContainerBlock &#x26; calculateMathAddonBlock</td><td align="center">The blocks to calculate. calculateContainerBlock: Receives VC from the previous block. Passes the new VC to the next block.<br>calculateMathOnBlock: Child block for 'calculateContainerBlock'. Contains descriptions of variables and formulas.</td><td align="center"><a href="/pages/i1trk19OS6iAUedFuZa1">calculateContainerBlock &#x26; calculateMathAddonBlock</a></td></tr><tr><td align="center">reportBlock</td><td align="center">The block container for TrustChain.</td><td align="center"><a href="/pages/QYnMFSQa8Qn8BFMxhuNp">reportBlock &#x26; reportItemBlock</a></td></tr><tr><td align="center">reportItemBlock</td><td align="center">The block for setting up the elements of the TrustChain.</td><td align="center"><a href="/pages/QYnMFSQa8Qn8BFMxhuNp">reportBlock &#x26; reportItemBlock</a></td></tr><tr><td align="center">Switch Block</td><td align="center">This block transfers execution to one or more blocks depending on the parameters</td><td align="center"><a href="/pages/dLgS4AgoVq8GL1NEym47">switchBlock</a></td></tr><tr><td align="center">timerBlock</td><td align="center">timer object which triggers the event</td><td align="center"><a href="/pages/SagNI0ixuyRHv6HKDaht">TimerBlock</a></td></tr><tr><td align="center">aggregateDocumentBlock</td><td align="center">block responsible for aggregation of the documents</td><td align="center"><a href="/pages/zFQThAsM0upts6ARbWYG">aggregateDocumentBlock</a></td></tr><tr><td align="center">revocationBlock</td><td align="center">This Block finds related messages in policy topics, and revokes those messages and sends it to Hedera topic, but it doesn’t save documents in DB</td><td align="center"><a href="https://github.com/hashgraph/guardian/blob/develop/docs/available-policy-workflow-blocks/broken-reference/README.md">revocationBlock</a></td></tr><tr><td align="center">setRelationshipsBlock</td><td align="center">Contains DocumentSourceAddOn Block and set relationships for input document.</td><td align="center"><a href="/pages/sMDDscLghqoLYA5CXYrC">setRelationshipBlock</a></td></tr><tr><td align="center">buttonBlock</td><td align="center">Block responsible for creating buttons</td><td align="center"><a href="/pages/jMBjK6bUPfQ0Iwiqk85j">buttonBlock</a></td></tr><tr><td align="center">documentValidatorBlock</td><td align="center">Block to validate documents, including linked documents</td><td align="center"><a href="/pages/3UBIc4ZGijP4jiQuyYHl">documentValidatorBlock</a></td></tr><tr><td align="center">tokenActionBlock</td><td align="center">Block is responsible to automation actions related to tokens</td><td align="center"><a href="/pages/GjcQtvUZHIzn74EAQPt3">tokenActionBlock</a></td></tr><tr><td align="center">tokenConfirmationBlock</td><td align="center">Block enables the owner of the private key for the account to manually perform operations with the token</td><td align="center"><a href="/pages/2aLCDJb0tM88NjC4lVYp">tokenConfirmationBlock</a></td></tr><tr><td align="center">mintDocumentBlock</td><td align="center">Block is responsible for adding configurations on calculating the amount of tokens to be minted.</td><td align="center"><a href="/pages/LvR7TaF526HGBWSxyEZm">mintDocumentBlock</a></td></tr><tr><td align="center">groupManagerBlock</td><td align="center">Block allows to manage group membership, add and remove users from the group.</td><td align="center"><a href="/pages/U5STCXaxOKLpaqDrSt5C">groupManagerBlock</a></td></tr><tr><td align="center">multiSignBlock</td><td align="center">This block provides a way to specify multiple signators for a single VC document, and then create a VP based on it.</td><td align="center"><a href="/pages/NHxvGSgIWjJv60eOw1oQ">multiSignBlock</a></td></tr><tr><td align="center">customLogicBlock</td><td align="center">This block is used to perform Logic</td><td align="center"><a href="/pages/mCbPfxcWwvqbprP1lJOe">customLogicBlock</a></td></tr><tr><td align="center">splitBlock</td><td align="center">This block allows to accumulate VC documents and produce new VCs in fixed chunks</td><td align="center"><a href="/pages/2yH80UWsIHapByG9wwfk">splitBlock</a><br></td></tr><tr><td align="center">wipeDocumentBlock</td><td align="center">This block is used to wipe the Token</td><td align="center"><a href="https://github.com/hashgraph/guardian/blob/develop/docs/guardian/standard-registry/policies/policy-creation/introduction/broken-reference/README.md">wipeDocumentBlock</a></td></tr><tr><td align="center">CreateTokenBlock</td><td align="center">This block is used to create Token template</td><td align="center"><a href="/pages/LSvvaP9Jrb8avf59K765">CreateTokenBlock</a></td></tr><tr><td align="center">impactAddon</td><td align="center">This is an addon to create token impacts</td><td align="center"><a href="/pages/Gcy0v39C4ux2xZQ0xoLQ">impactAddon</a></td></tr><tr><td align="center">Http Request Block</td><td align="center">This block is used to retrieve outside data</td><td align="center"><a href="/pages/QOuvJYVfvjBwtEHWpH3S">HttpRequestBlock</a></td></tr><tr><td align="center">historyAddon</td><td align="center">This block turn on history on interfaceDocumentsSourceBlock.</td><td align="center"><a href="/pages/7kKkvzHlZvffCf7fvilg">historyAddon</a></td></tr><tr><td align="center">selectiveAttributes Block</td><td align="center">This block will filter attributes (option field) in documents returned by documentsSourceAddon.</td><td align="center"><a href="/pages/j3ITkl65tpokLFMpDlrN">selectiveAttributesBlock</a></td></tr><tr><td align="center">tagsManagerBlock</td><td align="center">This block is responsible for managing tags in policies.</td><td align="center"><a href="/pages/KZ9Lgru34543M7URuJ0g">tagsManagerBlock</a></td></tr><tr><td align="center">externalTopicBlock</td><td align="center">This block allows to configure the link to Hedera topics established by other policy instances for monitoring of ‘document published’ messages and ingestion of the targeted VC documents.</td><td align="center"><a href="/pages/sLicPNEMM5018563LA9G">externalTopicBlock</a></td></tr><tr><td align="center">messagesReportBlock</td><td align="center">This block allows to create report based on the inter-referenced messages.</td><td align="center"><a href="/pages/wUHIkdUTzdXf6l9YPcEc">messagesReportBlock</a></td></tr><tr><td align="center">notificationBlock</td><td align="center">This block is used to generate notifications</td><td align="center"><a href="/pages/a0GgrJuB7YVC4kvtv1SK">notificationBlock</a></td></tr><tr><td align="center">extractDataBlock</td><td align="center">This block extractDataBlock provides means to extract a data set which corresponds to any of these embedded schemas (at any depth level)</td><td align="center"><a href="/pages/rJqnI3cyR8cKRnqmzogS">extractDataBlock</a></td></tr><tr><td align="center">button block Addon</td><td align="center">This block is used to display interactive buttons</td><td align="center"><a href="/pages/6P1jyg1XPOZpppkpTmTJ">buttonBlockAddon</a></td></tr><tr><td align="center">Dropdown Block Addon</td><td align="center">The block is to display an interactive dropdown menu</td><td align="center"><a href="/pages/cRaUevRVZ6PmMsh7qvQQ">dropdownBlockAddon</a></td></tr><tr><td align="center">RequestVC Document Block Addon</td><td align="center">This block is to display an interactive button in the interfaceDocumentsSourceBlock.</td><td align="center"><a href="/pages/gbV9YRoUDNKvbhJoWQ5E">requestVcDocumentBlockAddon</a></td></tr><tr><td align="center">Data Transformation Addon</td><td align="center"><p>This block is to produce a transformed result based on the data from the source</p><p>and filters blocks</p></td><td align="center"><a href="/pages/anVZ2yra5fH4tCsqNkCg">Data Transformation Addon</a></td></tr><tr><td align="center">IntegrationButtonBlock</td><td align="center">This block enable interaction with third-party data providers</td><td align="center"><a href="/pages/JzyxokhUbml73wXO0N78">IntegrationButton</a></td></tr><tr><td align="center">Global Events Reader Block</td><td align="center">This block subscribes to global topics and routes incoming events into policy branches</td><td align="center"><p><a href="/pages/qcyg0yIofZLDVRmYkodr">Global Events Reader</a></p><p><a href="/pages/qcyg0yIofZLDVRmYkodr">Block</a></p></td></tr><tr><td align="center">Global Events Writer Block</td><td align="center">This block publishes document references to one or more global Hedera topics</td><td align="center"><p><a href="/pages/QMTRaqcB5KArxDFfWCRd">Global Events Writer</a></p><p><a href="/pages/QMTRaqcB5KArxDFfWCRd">Block</a></p></td></tr><tr><td align="center">mathBlock</td><td align="center">This block defines calculations on document data in mathematical notation</td><td align="center"><a href="/pages/QNB5phDHMJxo5yXbSXFc">MathBlock</a></td></tr></tbody></table>


# InterfaceContainerBlock

### Properties

| Block Property | Definition                                                                        | Example Input                                   | Status |
| -------------- | --------------------------------------------------------------------------------- | ----------------------------------------------- | ------ |
| type           | A block which contains and organizes other blocks.                                | **InterfaceContainerBlock** (Can't be changed). |        |
| tag            | Unique name for the logic block.                                                  | installer\_header.                              |        |
| permissions    | Which entity has rights to interact at this part of the workflow.                 | Installer.                                      |        |
| defaultActive  | Shows whether this block is active at this time and whether it needs to be shown. | Checked or unchecked.                           |        |

{% hint style="info" %}
RefreshEvents are used to refreshing the UI, instead of "dependencies" property.
{% endhint %}

### **UI Properties**

| UI Property | Definition                                                                                                         |
| ----------- | ------------------------------------------------------------------------------------------------------------------ |
| Title       | Provides a title for the UI element.                                                                               |
| Type BLANK  | Does not contain any frame, will render all child elements one after the other.                                    |
| Type TABS   | A container which has a tab for each of the child element. It will render the first child element as type "blank". |

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events)

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyID}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyID<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```javascript
    {
  "uiMetaData": {
    "type": "blank"
  },
  "id": "27c9f288-c4b4-4690-b3b9-9843cc90129f",
  "blockType": "interfaceContainerBlock",

}
```

{% endtab %}
{% endtabs %}


# PolicyRolesBlock

This block allows the user to select a role or a group.

### Properties

| Block Property    | Definition                                                                        | Example Input                                   | Status |
| ----------------- | --------------------------------------------------------------------------------- | ----------------------------------------------- | ------ |
| type              | A block which determines a role for the user.                                     | **PolicyRolesBlock** (Can't be changed).        |        |
| tag               | Unique name for the logic block.                                                  | choose\_role.                                   |        |
| permissions       | Which entity has rights to interact at this part of the workflow.                 | Installer.                                      |        |
| defaultActive     | Shows whether this block is active at this time and whether it needs to be shown. | Checked or unchecked.                           |        |
| roles             | Available roles from which the user can choose.                                   | Select the appropriate roles from the dropdown. |        |
| Available Roles   | list of roles for selected user                                                   | Checked or unchecked.                           |        |
| ·Available Groups | list of groups for selected user                                                  | Checked or unchecked.                           |        |

{% hint style="info" %}
**Note: ‘*****Available Groups*****’** option takes priority and thus, when set, causes the system to ignore **‘*****Available Roles*****’**.
{% endhint %}

{% hint style="info" %}
**Note:** Setting the Permissions property to ‘**No Role’** limits the visibility of this block to those users which have not yet selected a role or a group.
{% endhint %}

{% hint style="info" %}
RefreshEvents are used to refreshing the UI, instead of "dependencies" property.
{% endhint %}

### UI Properties

| UI Property | Definition                                   |
| ----------- | -------------------------------------------- |
| Title       | Provide the a title for the role selector.   |
| Description | Provide a description on the role selection. |

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | PolicyID    |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```javascript
 {
  "roles": [],
  "groups": [
    "VVBs",
    "Project_Proponent"
  ],
  "groupMap": {
    "VVBs": {
      "groupAccessType": "Private",
      "groupRelationshipType": "Multiple"
    },
    "Project_Proponent": {
      "groupAccessType": "Private",
      "groupRelationshipType": "Single"
    }
  },
  "isMultipleGroups": true,
  "uiMetaData": {
    "title": "Roles",
    "description": "Choose Roles"
  }
}

```

{% endtab %}
{% endtabs %}

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

#### Request Body

| Name                                   | Type   | Description |
| -------------------------------------- | ------ | ----------- |
| role<mark style="color:red;">\*</mark> | String |             |
| invitation                             | String | Invite Code |
| Group                                  | String | Group Name  |


# InterfaceStepBlock

### Properties

| Block Property | Definition                                                                                                      | Example Input                              | Status |
| -------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------ | ------ |
| type           | Similar to the **InterfaceContainer**Block, with the difference that it can only render a single child element. | **InterfaceStepBlock** (Can't be changed). |        |
| tag            | Unique name for the logic block.                                                                                | CSD01 Document.                            |        |
| permissions    | Which entity has rights to interact at this part of the workflow.                                               | Standard Registry.                         |        |
| defaultActive  | Shows whether this block is active at this time and whether it needs to be shown.                               | Checked or unchecked.                      |        |
| cyclic         | Go back one step to enable the creation of the previous object.                                                 | Checked or unchecked.                      |        |

{% hint style="info" %}
RefreshEvents are used to refreshing the UI, instead of "dependencies" property.
{% endhint %}

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                                                                                                                   | Description |
| ------------- | ------------ | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ----------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | Type of the event - determines whether this is ingress or egress event for the current block.                                   |             |
| Source        | "source"     | Block tag(string)                                                 | The block which initiates the event.                                                                                            |             |
| Target        | "target"     | Block tag(string)                                                 | The block which receives the event.                                                                                             |             |
| Output Event  | "output"     | Event name(string)                                                | Action or issue that caused the event.                                                                                          |             |
| Input Event   | "input"      | Event name(string)                                                | Action which will be triggered by the event.                                                                                    |             |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |             |
| Disabled      | "disabled"   | True/False                                                        | Allows to disable the event without deleting it.                                                                                |             |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```javascript
{
  "uiMetaData": {
    "type": "blank"
  },
  "index": 8,
  "id": "92fdc241-da15-46cb-9153-d223aeb61c5a",
  "blockType": "interfaceStepBlock",
  "blocks": [
    null,
    null,
    null,
    null,
    null,
    null,
    null,
    null,
    {
      "uiMetaData": {
        "type": "tabs"
      },
      "content": "interfaceContainerBlock",
      "blockType": "interfaceContainerBlock",
      "id": "768d5fae-a907-4566-aa87-62f6929a03c7"
    },
    null,
    null,
    null,
    null,
    null
  ]
}

```

{% endtab %}
{% endtabs %}


# requestVCDocumentBlock

### Properties

| Block Property   | Definition                                                                                                                                                   | Example Input                                                                                                                | Status |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | ------ |
| type             | A type of the block which receives data in the format of a ‘credential subject’ part of a VC Document                                                        | **requestVCDocumentBlock** (Can't be changed).                                                                               |        |
| tag              | Unique name for the logic block.                                                                                                                             | add\_new\_installer\_request.                                                                                                |        |
| permissions      | Which entity has rights to interact at this part of the workflow.                                                                                            | Standard Registry.                                                                                                           |        |
| defaultActive    | Shows whether this block is active at this time and whether it needs to be shown.                                                                            | Checked or unchecked.                                                                                                        |        |
| schema           | Pre-configured schemas for the document relevant for policy action requests. Technically, it's the uuid of the schema, which will be used to build the form. | IRec-Application-Details (to be selected from the drop down of available schemas in your Guardian instance).                 |        |
| ID Type          | Select the type of ID that is populated in the ID field of the Verifiable Credential document.                                                               | Current Options are: DID (creates a new DID), UUID (creates a new UUID), and Owner (which uses the DID of the current user). |        |
| stop propagation | End processing here, don't pass control to the next block.                                                                                                   | Checked or Unchecked.                                                                                                        |        |

{% hint style="info" %}
RefreshEvents are used to refreshing the UI, instead of "dependencies" property.
{% endhint %}

### UI Properties

| UI Property          | Definition                                                                                                                                                                    |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Type                 | Style of the render of the form. It can be either a Page (the form is rendered as a page) or Dialogue (displays a button, which opens a dialogue with the form when clicked). |
| Title                | Provides the Page or Dialogue box a title.                                                                                                                                    |
| Description          | Provides the Page or Dialogue box a description.                                                                                                                              |
| hideWhenDiscontinued | Check if the button should be hidden when policy is discontinued                                                                                                              |
| Button Content       | Text to fill inside a button. Needs the Dialogue box to be selected from the "Type."                                                                                          |
| Dialogue Text        | Provides a tile inside the Dialogue box. Needs the dialogue box to be selected from the "Type."                                                                               |
| Dialogue Description | Provides a description inside the Dialogue box. Needs the dialogue box to be selected from the "Type."                                                                        |

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| uuid<mark style="color:red;">\*</mark>     | String | Block ID    |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```javascript
{
  "id": "ef2a7742-68d4-407f-ada7-14cdce80e24d",
  "blockType": "requestVcDocumentBlock",
  "schema": {
    "userDID": null,
    "_id": "63da04dd9670adb07f82b090",
    "id": "63da04dd9670adb07f82b090",
    "uuid": "6235abf8-6b48-4212-9ecc-c82bdf90405e",
    "hash": "",
    "name": "I-REC Facility & Device Reg",
    "description": "I-REC Facility & Device Reg",
    "entity": "VC",
    "status": "DRAFT",
    "readonly": false,
    "system": false,
    "active": false,
    "version": "",
    "creator": "did:hedera:testnet:9jShvNUsztLFbvEK442VPfkccLYW3F2oU3e6rCHzr7FT_0.0.3075949",
    "owner": "did:hedera:testnet:9jShvNUsztLFbvEK442VPfkccLYW3F2oU3e6rCHzr7FT_0.0.3075949",
    "topicId": "0.0.3120995",
    "messageId": "",
    "documentURL": "",
    "contextURL": "",
    "iri": "#6235abf8-6b48-4212-9ecc-c82bdf90405e",
    "document": {
      "$id": "#6235abf8-6b48-4212-9ecc-c82bdf90405e",
      "$comment": "{ \"@id\": \"#6235abf8-6b48-4212-9ecc-c82bdf90405e\", \"term\": \"6235abf8-6b48-4212-9ecc-c82bdf90405e\" }",
      "title": "I-REC Facility & Device Reg",
      "description": "I-REC Facility & Device Reg",
      "type": "object",
      "properties": {
        "@context": {
          "oneOf": [
            {
              "type": "string"
            },
            {
              "type": "array",
              "items": {
                "type": "string"
              }
            }
          ],
          "readOnly": true
        },
        "id": {
          "type": "string",
          "readOnly": true
        },
        "field0": {
          "title": "Registrant Id",
          "description": "Registrant Id",
          "readOnly": false,
          "type": "string",
          "$comment": "{\"term\":\"field0\",\"@id\":\"https://www.schema.org/text\",\"orderPosition\":0}"
        },
        "policyId": {
          "title": "policyId",
          "description": "policyId",
          "readOnly": true,
          "type": "string",
          "$comment": "{\"term\":\"policyId\",\"@id\":\"https://www.schema.org/text\"}"
        },
        "ref": {
          "title": "ref",
          "description": "ref",
          "readOnly": true,
          "type": "string",
          "$comment": "{\"term\":\"ref\",\"@id\":\"https://www.schema.org/text\"}"
        },
        "field1": {
          "title": "Date",
          "description": "Date",
          "readOnly": false,
          "type": "string",
          "format": "date",
          "$comment": "{\"term\":\"field1\",\"@id\":\"https://www.schema.org/text\",\"orderPosition\":1}"
        },
        "field2": {
          "title": "Is the Registrant also the owner of the Device? (provide evidence) ",
          "description": "Is the Registrant also the owner of the Device? (provide evidence) ",
          "readOnly": false,
          "type": "string",
          "$comment": "{\"term\":\"field2\",\"@id\":\"https://www.schema.org/text\",\"orderPosition\":2}"
        },
        "field3": {
          "title": "Registrant Details",
          "description": "Registrant Details",
          "readOnly": false,
          "$ref": "#dee7e78b-44b8-4bb0-8be0-3a86bde752b2",
          "$comment": "{\"term\":\"field3\",\"@id\":\"#dee7e78b-44b8-4bb0-8be0-3a86bde752b2\",\"orderPosition\":3}"
        },
        "field4": {
          "title": "Production Device Details",
          "description": "Production Device Details",
          "readOnly": false,
          "$ref": "#b61a05c6-bb1a-4d7e-9299-c0932d8c0306",
          "$comment": "{\"term\":\"field4\",\"@id\":\"#b61a05c6-bb1a-4d7e-9299-c0932d8c0306\",\"orderPosition\":4}"
        },
        "field5": {
          "title": "Energy Sources",
          "description": "Energy Sources",
          "readOnly": false,
          "$ref": "#899e042e-dc62-4849-95dc-b982af558e6c",
          "$comment": "{\"term\":\"field5\",\"@id\":\"#899e042e-dc62-4849-95dc-b982af558e6c\",\"orderPosition\":5}"
        }
      },
      "required": [
        "@context",
        "type",
        "policyId",
        "field3",
        "field4",
        "field5"
      ],
      "additionalProperties": false,
      "$defs": {
        "#dee7e78b-44b8-4bb0-8be0-3a86bde752b2": {
          "$id": "#dee7e78b-44b8-4bb0-8be0-3a86bde752b2",
          "$comment": "{ \"@id\": \"#dee7e78b-44b8-4bb0-8be0-3a86bde752b2\", \"term\": \"dee7e78b-44b8-4bb0-8be0-3a86bde752b2\" }",
          "title": "Contact Details",
          "description": "Contact Details",
          "type": "object",
          "properties": {
            "@context": {
              "oneOf": [
                {
                  "type": "string"
                },
                {
                  "type": "array",
                  "items": {
                    "type": "string"
                  }
                }
              ],
              "readOnly": true
            },
            "type": {
              "oneOf": [
                {
                  "type": "string"
                },
                {
                  "type": "array",
                  "items": {
                    "type": "string"
                  }
                }
              ],
              "readOnly": true
            },
            "id": {
              "type": "string",
              "readOnly": true
            },
            "field0": {
              "title": "Organization Name",
              "description": "Organization Name",
              "readOnly": false,
              "type": "string",
              "$comment": "{\"term\":\"field0\",\"@id\":\"https://www.schema.org/text\",\"orderPosition\":0}"
            },
            "field1": {
              "title": "Address line 1",
              "description": "Address line 1",
              "readOnly": false,
              "type": "string",
              "$comment": "{\"term\":\"field1\",\"@id\":\"https://www.schema.org/text\",\"orderPosition\":1}"
            },
            "field2": {
              "title": "Address line 2",
              "description": "Address line 2",
              "readOnly": false,
              "type": "string",
              "$comment": "{\"term\":\"field2\",\"@id\":\"https://www.schema.org/text\",\"orderPosition\":2}"
            },
            "field3": {
              "title": "Address line 3",
              "description": "Address line 3",
              "readOnly": false,
              "type": "string",
              "$comment": "{\"term\":\"field3\",\"@id\":\"https://www.schema.org/text\",\"orderPosition\":3}"
            },
            "field4": {
              "title": "Postal code",
              "description": "Postal code",
              "readOnly": false,
              "type": "string",
              "$comment": "{\"term\":\"field4\",\"@id\":\"https://www.schema.org/text\",\"orderPosition\":4}"
            },
            "field5": {
              "title": "Country",
              "description": "Country",
              "readOnly": false,
              "type": "string",
              "$comment": "{\"term\":\"field5\",\"@id\":\"https://www.schema.org/text\",\"orderPosition\":5}"
            },
            "field6": {
              "title": "Contact person",
              "description": "Contact person",
              "readOnly": false,
              "type": "string",
              "$comment": "{\"term\":\"field6\",\"@id\":\"https://www.schema.org/text\",\"orderPosition\":6}"
.....
```

{% endtab %}
{% endtabs %}

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Request Body

| Name                                       | Type   | Description        |
| ------------------------------------------ | ------ | ------------------ |
| document<mark style="color:red;">\*</mark> | Object | Credential Subject |
| ref                                        | String | ID of linked VC    |


# sendToGuardianBlock

### 1. Properties

| Block Property   | Definition                                                                                                                                                                                                                                                                             | Example Input                                                                                                                                                                                                                   | Status |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ |
| type             | A type of the block which can save a new or updated document.                                                                                                                                                                                                                          | **sendToGuardianBlock** (Can't be changed).                                                                                                                                                                                     |        |
| tag              | Unique name for the logic block.                                                                                                                                                                                                                                                       | save\_new\_approved\_document.                                                                                                                                                                                                  |        |
| permissions      | Which entity has rights to interact at this part of the workflow.                                                                                                                                                                                                                      | Standard Registry.                                                                                                                                                                                                              |        |
| defaultActive    | Shows whether this block is active at this time and whether it needs to be shown.                                                                                                                                                                                                      | Checked or unchecked.                                                                                                                                                                                                           |        |
| entityType       | Gives the document a label in the DB. Needed for filtering.                                                                                                                                                                                                                            | Installer.                                                                                                                                                                                                                      |        |
| stop Propagation | End processing here, don't pass control to the next block.                                                                                                                                                                                                                             | Checked or Unchecked.                                                                                                                                                                                                           |        |
| options          | List of attributes, which is added to the VC when it is being persistent. Can be used for more flexible filtration.                                                                                                                                                                    | <p>"name": "status"</p><p>"value": "Minted",</p>                                                                                                                                                                                |        |
| dataSource       | Where to send Data                                                                                                                                                                                                                                                                     | Database / Hedera Topic / Auto                                                                                                                                                                                                  |        |
| documentType     | Type of Document                                                                                                                                                                                                                                                                       | VC / DID / VP                                                                                                                                                                                                                   |        |
| topic            | Topic to send a document if 'dataSource' = 'Hedera Topic'                                                                                                                                                                                                                              | topic                                                                                                                                                                                                                           |        |
| topicOwner       | if ‘Hedera Topic’ is selected for the ‘Source Type’ a new optional property ‘Topic Owner’ appears which shows which field determines the User, who will own the topic of the document. This is because in ‘Hedera Topic’ only the template of Topic is selected, not the topic itself. | <p>Current User - user whose credentials were used to make the current post request</p><p>Document Owner - creator of the document (has default value)</p><p>Document Issuer - user which was the last to sign the document</p> |        |
| Memo             | if 'Data Source' is Hedera Topic, this field is enabled. This is used to customize the Memo field name                                                                                                                                                                                 | example memo ${document.id}                                                                                                                                                                                                     |        |
| skipSaveState    | Allows to skip save document state to prevent display the state in history. This property is visible only when block has Data Source : “Database” or “Auto”.                                                                                                                           | Checked or Unchecked                                                                                                                                                                                                            |        |

{% hint style="info" %}
**Note:**

‘**Force New Document**’ option has been removed as its usage resulted in the duplicate documents (with the same hashes) polluting the storage and causing confusion in the links (when building trust chain). For the cases when a new document needs to be created on the basis of the old one please use ’**reassigningBlock**’ which would create new *proof* and as result new document with the equivalent content but with a new hash.
{% endhint %}

### 2. Auto Property:

This option applied in most cases. When **Auto** is selected the system applies the following logic:

1\. If the hash of the new document (being saved) is different from the hash of the document then it is based on the message is sent to Hedera into the Policy Instance Topic.

2\. If the database contains another document with the same hash it gets refreshed, otherwise a new document is created in the database.

{% hint style="info" %}
RefreshEvents are used to refreshing the UI, instead of "dependencies" property.
{% endhint %}

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).


# reassigningBlock

### Properties

<table><thead><tr><th width="192.33333333333331">Block Property</th><th>Definition</th><th>Example Input</th><th>Status</th></tr></thead><tbody><tr><td>type</td><td>A block type which re-signs the document and change the user to document owner.</td><td><strong>reassigningBlock</strong> (Can't be changed).</td><td></td></tr><tr><td>tag</td><td>Unique name for the logic block.</td><td>wait_for_approval.</td><td></td></tr><tr><td>permissions</td><td>Which entity has rights to interact at this part of the workflow.</td><td>Installer.</td><td></td></tr><tr><td>defaultActive</td><td>Shows whether this block is active at this time and whether it needs to be shown.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>dependencies</td><td>Establish workflow dependencies that need to be completed prior.</td><td>Select the appropriate block from the dropdown.</td><td><mark style="color:red;">Deprecated</mark></td></tr><tr><td>stop Propagation</td><td>End processing here, don't pass control to the next block.</td><td>Checked or Unchecked.</td><td></td></tr><tr><td>issuer</td><td>Person, who will be a Signer</td><td>not set - Current User<br>owner - document Owner<br>policyOwner - Policy Owner</td><td></td></tr><tr><td>actor</td><td>Person, who will be next Block Owner</td><td>not set - Current User<br>owner - document Owner<br>issuer - document Issuer</td><td></td></tr></tbody></table>

{% hint style="info" %}
RefreshEvents are used to refreshing the UI, instead of "dependencies" property.
{% endhint %}

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).


# InformationBlock

### Properties

<table><thead><tr><th width="192.33333333333331">Block Property</th><th>Definition</th><th>Example Input</th><th>Status</th></tr></thead><tbody><tr><td>type</td><td>A block type which can display a notification or a progress bar.</td><td><strong>InformationBlock</strong> (Can't be changed).</td><td></td></tr><tr><td>tag</td><td>Unique name for the logic block.</td><td>wait_for_approval.</td><td></td></tr><tr><td>permissions</td><td>Which entity has rights to interact at this part of the workflow.</td><td>Installer.</td><td></td></tr><tr><td>defaultActive</td><td>Shows whether this block is active at this time and whether it needs to be shown.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>dependencies</td><td>Establish workflow dependencies that need to be completed prior.</td><td>Select the appropriate block from the dropdown.</td><td><mark style="color:red;">Deprecated</mark></td></tr><tr><td>stop Propagation</td><td>End processing here, don't pass control to the next block.</td><td>Checked or Unchecked.</td><td></td></tr></tbody></table>

{% hint style="info" %}
RefreshEvents are used to refreshing the UI, instead of "dependencies" property.
{% endhint %}

### UI Properties

| UI Property | Definition                                                                                            |
| ----------- | ----------------------------------------------------------------------------------------------------- |
| Type        | Select the type of UI element for notifications. It can be either a LOADER (progress bar) or TEXT box |
| Title       | Provides the Loader or Text box a title.                                                              |
| Description | Provides the Loader or Text box a description.                                                        |

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```javascript
{
  "uiMetaData": {
    "description": "The page will refresh automatically once the application is approved.",
    "type": "text",
    "title": "Submitted for Approval"
  }
}

```

{% endtab %}
{% endtabs %}


# InterfaceDocumentsSourceBlock

### Properties

<table><thead><tr><th width="179">Block Property</th><th>Definition</th><th>Example Input</th><th>Status</th></tr></thead><tbody><tr><td>type</td><td>A block type which outputs information from the DB as grid.</td><td><strong>InterfaceDocumentsSource Block</strong> (Can't be changed).</td><td></td></tr><tr><td>tag</td><td>Unique name for the logic block.</td><td>sensors_grid.</td><td></td></tr><tr><td>permissions</td><td>Which entity has rights to interact at this part of the workflow.</td><td>Installer.</td><td></td></tr><tr><td>defaultActive</td><td>Shows whether this block is active at this time and whether it needs to be shown.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>dataType</td><td>Specify the table to request the data from.</td><td>Current options are: Verifiable Credential, DID, Approve, or Hedera.</td><td></td></tr></tbody></table>

{% hint style="info" %}
RefreshEvents are used to refreshing the UI, instead of "dependencies" property.
{% endhint %}

### UI Properties

<table><thead><tr><th width="312.6507787525413">UI Property</th><th>Definition</th></tr></thead><tbody><tr><td>Title</td><td>Type of the displayed value, possible options. Current options are: TEXT (ordinary text), BUTTON (a button), or BLOCK (a block embedded into the column).</td></tr><tr><td>Enable common sorting</td><td><ol><li>When it is true, user can sort grid data on UI side, or make POST request to interfaceSourceBlock with body ({ orderField: 'option.status', orderDirection: 'asc'}) to change sorting through the API</li><li>When it is false, user can set order to specific documentSourceAddon block by POST request with same body through the API</li></ol></td></tr><tr><td>Field Name</td><td>Object fields to retrieve the values from. Internal fields are separated by ".", access to array elements is via index. This is the field name.</td></tr><tr><td>Field Type</td><td>Current Options: TEXT, BUTTON, AND BLOCK.</td></tr><tr><td>Field Title</td><td>Title of the column.</td></tr><tr><td>Field Tooltip</td><td>Provide a tooltip for the field.</td></tr><tr><td>Field Cell Content</td><td>Content inside the cell.</td></tr><tr><td>Field UI Class</td><td>Arbitrary Class</td></tr><tr><td>Width</td><td>For example : 100px</td></tr><tr><td>Bind Group</td><td>If interfaceDocumentsSourceBlock has more than one documentsSourceAddon, then you can create different columns for each (names must be the same)</td></tr><tr><td>Bind Block</td><td>Specifying a "bindBlock" field would result in the display of the linked block in side the dialog.. Needs for the field type to be a BLOCK or BUTTON with the Action type as DIALOGUE.</td></tr><tr><td>Action</td><td>Needs for the field type to be a BUTTON. Specifies what action will happen when the button is clicked. Action options are currently: LINK to a URL or prompt a DIALOGUE box.</td></tr><tr><td>Dialogue Type</td><td>Currently only json type is supported. Needs for the field type to be a BUTTON and Action to be DIALOGUE.</td></tr><tr><td>Dialogue Content</td><td>Provide content for the dialogue box. Needs for the field type to be a BUTTON and Action to be DIALOGUE.</td></tr><tr><td>Dialogue Class</td><td>Dialog style. Needs for the field type to be a BUTTON and Action to be DIALOGUE.</td></tr></tbody></table>

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```
{
  "data": [
    {
      "_id": "63da084ddb84efbb04da4588",
      "dryRunId": "63da04e19670adb07f82b092",
      "dryRunClass": "VcDocumentCollection",
      "owner": "did:hedera:testnet:7Vn2KdgTZG2DZkz1x3naEJfazEACCEZGBkGLeUwrh45C_0.0.3075949",
      "hash": "29yk1PWG8h8euDCKFRcV9GXeXGCxhipyjaEnTaEw8wb9",
      "document": {
        "id": "urn:uuid:bd06ea41-9037-4294-b13d-f868563e30f1",
        "type": [
          "VerifiableCredential"
        ],
        "issuer": "did:hedera:testnet:7Vn2KdgTZG2DZkz1x3naEJfazEACCEZGBkGLeUwrh45C_0.0.3075949",
        "issuanceDate": "2023-02-01T06:35:57.132Z",
        "@context": [
          "https://www.w3.org/2018/credentials/v1"
        ],
        "credentialSubject": [
          {
            "field1": {
              "type": "bf7109c2-6ff4-47bb-a39d-02a0f11574b0",
              "@context": []
            },
            "field2": {
              "type": "dee7e78b-44b8-4bb0-8be0-3a86bde752b2",
              "@context": []
            },
            "field3": {
              "type": "86f9436f-82fd-48ce-bce8-37a5130263b0",
              "@context": []
            },
            "policyId": "63da04e19670adb07f82b092",
            "@context": [
              "schema#f6ab05cd-95a6-4465-8b3a-e1e87375fef9"
            ],
            "id": "did:hedera:testnet:7Vn2KdgTZG2DZkz1x3naEJfazEACCEZGBkGLeUwrh45C_0.0.3075949",
            "type": "f6ab05cd-95a6-4465-8b3a-e1e87375fef9"
          }
        ],
        "proof": {
          "type": "Ed25519Signature2018",
          "created": "2023-02-01T06:35:57Z",
          "verificationMethod": "did:hedera:testnet:7Vn2KdgTZG2DZkz1x3naEJfazEACCEZGBkGLeUwrh45C_0.0.3075949#did-root-key",
          "proofPurpose": "assertionMethod",
          "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..XUDlrhjJkXHgOIKVdGZETi3koGVRJM2elk70XKzRmCxVL8OyMEfhVyEz9c2z4L7I00dlH0nrZKoirtOdp0puAA"
        }
      },
      "createDate": "2023-02-01T06:35:57.508Z",
      "updateDate": "2023-02-01T06:35:57.508Z",
"created": "2023-02-01T06:35:57.508Z",
      "updated": "2023-02-01T06:35:57.508Z",
      "status": "NEW",
      "signature": 0,
      "type": "registrant",
      "policyId": "63da04e19670adb07f82b092",
      "tag": "create_application(db)",
      "messageId": "1675.233357483",
      "topicId": "0.0.1675233357271",
      "relationships": null,
"option": {
        "status": "Waiting for approval"
      },
      "comment": null,
      "assignedTo": null,
      "assignedToGroup": null,
      "hederaStatus": "ISSUE",
      "schema": "#f6ab05cd-95a6-4465-8b3a-e1e87375fef9",
      "accounts": {
        "default": "0.0.1675233350065"
      },
      "tokens": null,
      "uuid": "801f790a-404c-4869-ae1b-4e5fe1146783",
      "entity": "NONE",
      "iri": "801f790a-404c-4869-ae1b-4e5fe1146783",
      "readonly": false,
      "system": false,
      "active": false,
      "codeVersion": "1.0.0",
      "group": "8e58d3eb-9af5-4705-a9b3-
.....
```

{% endtab %}
{% endtabs %}

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

#### Request Body

| Name           | Type   | Description              |
| -------------- | ------ | ------------------------ |
| orderDirection | String | Order Direction ASC,DESC |
| orderField     | String | Order Field Path         |

### Path Parameters for Pagination and Filtration

#### With Child Blocks

InterfaceDocumentsSourceBlock can accept and pass-on query parameters to the child pagination and filtration add-ons.

**Pagination**

| Name         | Type   |
| ------------ | ------ |
| itemsPerPage | Number |
| page         | Number |

**Filtration**

| Name  | Type   | Description                               |
| ----- | ------ | ----------------------------------------- |
| key   | Number | ID or a tag of the filtration add-ons     |
| Value | String | the filtervalue for the Filtration add-on |

**Example:**

```
/api/v1/policies/<policyId>/blocks/<blockId>?itemsPerPage=20&page=0&Block_5=valuetofilterby
```

#### Without Child Blocks

| Name         | Description                         |
| ------------ | ----------------------------------- |
| filterByUUID | return document with specified uuid |

**Example:**

```
/api/v1/policies/<policyId>/blocks/<blockId>?itemsPerPage=20&page=0&<filterBlock id or tag>=<filterValue>&filterByUUID=<document uuid>
```


# paginationAddon

## Properties

| Block Property | Definition                                                                        | Example Input                                   |
| -------------- | --------------------------------------------------------------------------------- | ----------------------------------------------- |
| type           | A block type which adds pagination to the InterfaceDocumentSourceBlock if added   | **paginationAddon** (Can't be changed).         |
| tag            | Unique name for the logic block.                                                  |                                                 |
| permissions    | Which entity has rights to interact at this part of the workflow.                 | Installer                                       |
| defaultActive  | Shows whether this block is active at this time and whether it needs to be shown. | Checked or Unchecked                            |
| dependencies   | Establish workflow dependancies that need to be completed prior.                  | Select the appropriate block from the dropdown. |

## API Parameters

## Requests Block Data

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

Requests Block Data

#### Path Parameters

| Name                                       | Type   | Description         |
| ------------------------------------------ | ------ | ------------------- |
| policyId<mark style="color:red;">\*</mark> | String | Selected policy ID  |
| uuid<mark style="color:red;">\*</mark>     | String | Selected Block UUID |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```
{
		  "size": 5,
		  "itemsPerPage": 10,
		  "page": 0
}
```

{% endtab %}
{% endtabs %}

## Requests Block Data by Tag

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/tag/{tag}/blocks`

Requests Block Data by Tag

#### Path Parameters

| Name                                       | Type   | Description                  |
| ------------------------------------------ | ------ | ---------------------------- |
| policyId<mark style="color:red;">\*</mark> | String | Selected Policy ID           |
| tag<mark style="color:red;">\*</mark>      | String | Tag from the selected policy |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```
{
		  "size": 5,
		  "itemsPerPage": 10,
		  "page": 0
}
```

{% endtab %}
{% endtabs %}

## Sends data to the specified block

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

Sends data to the specified block

#### Path Parameters

| Name                                       | Type   | Description         |
| ------------------------------------------ | ------ | ------------------- |
| policyId<mark style="color:red;">\*</mark> | String | Selected Policy ID  |
| uuid<mark style="color:red;">\*</mark>     | String | Selected Block UUID |

#### Request Body

| Name                               | Type   | Description                                  |
| ---------------------------------- | ------ | -------------------------------------------- |
| <mark style="color:red;">\*</mark> | Object | Object with the data to be sent to the block |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

{% endtab %}
{% endtabs %}

## Sends data to the specified block by tag

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/tag/{tag}/blocks`

Sends data to the specified block

#### Path Parameters

| Name                                       | Type   | Description         |
| ------------------------------------------ | ------ | ------------------- |
| policyId<mark style="color:red;">\*</mark> | String | Selected Policy ID  |
| uuid<mark style="color:red;">\*</mark>     | String | Selected Block UUID |

#### Request Body

| Name                               | Type   | Description                                  |
| ---------------------------------- | ------ | -------------------------------------------- |
| <mark style="color:red;">\*</mark> | Object | Object with the data to be sent to the block |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

{% endtab %}
{% endtabs %}


# DocumentsSourceAddOn

{% hint style="info" %}
Note: This block is used for dropdown. You can add multiple blocks to 1 grid to combine different data.
{% endhint %}

### Properties

<table><thead><tr><th width="282.3333333333333">Block Property</th><th>Definition</th><th>Example Input</th><th>Status</th></tr></thead><tbody><tr><td>type</td><td>A block for searching VC, for grid</td><td><strong>DocumentsSourceAddOn Block</strong> (Can't be changed).</td><td></td></tr><tr><td>tag</td><td>Unique name for the logic block.</td><td>approve<em>d_documents_</em>grid_source</td><td></td></tr><tr><td>permissions</td><td>Which entity has rights to interact at this part of the workflow.</td><td>Installer.</td><td></td></tr><tr><td>defaultActive</td><td>Shows whether this block is active at this time and whether it needs to be shown.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>dependencies</td><td>Automatic update. The block is automatically re-rendered if any of the linked components gets updated.</td><td>Select the appropriate block from the dropdown.</td><td></td></tr><tr><td>Data Type</td><td>Specify the table to request the data from.</td><td>Current options are: Verifiable Credential, DID, Approve, or Hedera.</td><td></td></tr><tr><td>Schema</td><td>Filters the VC according to the selected scheme</td><td>iRec Application Details (1.0.0) PUBLISHED</td><td></td></tr><tr><td>onlyOwnDocuments</td><td>When checked, filter out only VCs created by the user</td><td>checked or unchecked</td><td></td></tr><tr><td>onlyAssignDocuments</td><td>When checked, it filter only VCs assigned to the user</td><td>checked or unchecked</td><td></td></tr><tr><td>Order Field</td><td>name of the field</td><td>Source</td><td></td></tr><tr><td>Order Direction</td><td>Ascending or Descending direction of the order</td><td>ASC/DESC</td><td></td></tr></tbody></table>

{% hint style="info" %}
Note: If no Order Field is specified, but Order Direction is specified, then Order Field will be automatically filled = createDate and data will be sorted by createDate
{% endhint %}

### Filter Properties

| Filter Property | Definition                                                 | Example Input |
| --------------- | ---------------------------------------------------------- | ------------- |
| Field           | Name of the field to filter, it can be nested using "."    | option.status |
| Type            | Filter on the basis of type (Equal, Not Equal, In, Not In) | Equal         |
| Value           | The field by which to filter Value                         | Verified      |

### API Parameters

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyID<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

#### Request Body

| Name           | Type   | Description                |
| -------------- | ------ | -------------------------- |
| orderBy        | String | Order Field Path           |
| orderDirection | String | Order Direction, ASC, DESC |


# filtersAddOnBlock

{% hint style="info" %}
Note: This block is used for dropdown. You can add multiple blocks to 1 grid to combine different data.
{% endhint %}

### Properties

| Block Property | Definition                                                                                                                                       | Example Input                                                         |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------- |
| type           | A block for providing dynamic filters to DocumentsSourceAddOn Block                                                                              | **filtersAddOnBlock** (Can't be changed).                             |
| tag            | Unique name for the logic block.                                                                                                                 | report\_\_by\_\_project                                               |
| permissions    | Which entity has rights to interact at this part of the workflow.                                                                                | Installer.                                                            |
| defaultActive  | Shows whether this block is active at this time and whether it needs to be shown.                                                                | Checked or unchecked.                                                 |
| dependencies   | Automatic update. The block is automatically re-rendered if any of the linked components gets updated.                                           | Select the appropriate block from the dropdown.                       |
| type           | Filter type, so far only Dropdown type - allows the user to select one of the available values.                                                  | The list of available values is provided by DocumentsSourceAddonBlock |
| canBeEmpty     | if true - if the filter is empty, then it is not taken into account when filtering. If false - then after filtering there will be an empty array | checked or unchecked                                                  |
| field          | the field by which the filtering will take place                                                                                                 | document.credentialSubject.0.ref                                      |
| optionName     | the field to be used as the label                                                                                                                | document.credentialSubject.0.id                                       |
| optionValue    | the field that will act as the value                                                                                                             | document.credentialSubject.0.id                                       |

### UI Properties

| Filter Property | Definition             | Example Input |
| --------------- | ---------------------- | ------------- |
| Title           | Filter title           | Filter1       |
| Button Context  | text inside the button | Project       |

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyID<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid                                       | String | Block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```javascript
{
  "id": "a4b87158-7428-48ac-b69b-762f96777edc",
  "blockType": "filtersAddon",
  "type": "dropdown",
  "uiMetaData": {
    "options": [],
    "content": "Device"
  },
  "data": [
    {
      "name": "device1",
      "value": "did:hedera:testnet:EHXwuE486eSD4yGXr6qTNLstmb8H1B2Jn4kx3PeWZzjv_0.0.1675232535045"
    }
  ],
  "optionName": "document.credentialSubject.0.field4.field0",
  "optionValue": "document.credentialSubject.0.id",
  "filterValue": "did:hedera:testnet:EHXwuE486eSD4yGXr6qTNLstmb8H1B2Jn4kx3PeWZzjv_0.0.1675232535045"
}

```

{% endtab %}
{% endtabs %}

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

#### Request Body

| Name                                          | Type   | Description      |
| --------------------------------------------- | ------ | ---------------- |
| filterValue<mark style="color:red;">\*</mark> | String | New filter value |


# InterfaceActionBlock

### Properties

| Block Property   | Definition                                                                        | Example Input                                                                  | Status |
| ---------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------ |
| type             | A block to create custom actions.                                                 | **InterfaceActionBlock** (Can't be changed).                                   |        |
| tag              | Unique name for the logic block.                                                  | download\_config\_btn.                                                         |        |
| permissions      | Which entity has rights to interact at this part of the workflow.                 | Installer.                                                                     |        |
| defaultActive    | Shows whether this block is active at this time and whether it needs to be shown. | Checked or unchecked.                                                          |        |
| stop Propagation | End processing here, don't pass control to the next block.                        | Checked or unchecked.                                                          |        |
| type             | Specific the type of action workflow action block.                                | Current options are: SELECTOR (select an action) and DOWNLOAD (download files) |        |

### UI Properties

| UI Property    | Definition                                                                                                                                                                                                                                                                                      | Status |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ |
| Title          | Provides the title.                                                                                                                                                                                                                                                                             |        |
| Field          | Provides the field name. Action workflow type needs to be SELECTOR.                                                                                                                                                                                                                             |        |
| Option Name    | Provides the name of the option. Action workflow type needs to be SELECTOR.                                                                                                                                                                                                                     |        |
| Option Value   | Provides the value of the option. Action workflow type needs to be SELECTOR.                                                                                                                                                                                                                    |        |
| UI Class       | Button style. Action workflow type needs to be SELECTOR.                                                                                                                                                                                                                                        |        |
| Button Content | Provide the content for the button. Action workflow type needs to be DOWNLOAD.                                                                                                                                                                                                                  |        |
| Schema         | Pre-configured schemas relevant for download to be selected from the drop down of available schemas in your Guardian instance. Only needed in the reference implementation of the Guardian because of the IoT Simulator that is generating MRV data. Action workflow type needs to be DOWNLOAD. |        |
| Target URL     | Set the target URL where the file should be stored. Only needed in the reference implementation of the Guardian because of the IoT Simulator that is generating MRV data. Action workflow type needs to be DOWNLOAD.                                                                            |        |
| User           | Action workflow type needs to be SELECTOR. It determines who will get update actions (Dependencies property in other blocks) and which user will be used in next Blocks. It can be "Current" or "Owner". "Current" - user under which the action is performed. "Owner" - document owner.        |        |
| Option Tag     | Name of the dynamic events                                                                                                                                                                                                                                                                      |        |

![](/files/8Col1pFQWF31XV2SsINo)

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```javascript
{
  "id": "448ff538-1c3b-45eb-a310-9414ae223b81",
  "blockType": "interfaceActionBlock",
  "type": "dropdown",
  "uiMetaData": {
    "options": [],
    "content": "VVB"
  },
  "name": "document.credentialSubject.0.field0",
  "value": "group",
  "field": "assignedToGroup",
  "options": [
    {
      "name": "1",
      "value": "6b3efd88-037c-4335-a4d1-02776e23973c"
    }
  ]
}

```

{% endtab %}
{% endtabs %}

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

#### Request Body

| Name                                       | Type | Description |
| ------------------------------------------ | ---- | ----------- |
| document<mark style="color:red;">\*</mark> | VC   | VC Document |


# externalDataBlock

### Properties

| Block Property | Definition                                                                                                                     | Example Input                             | Status |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------- | ------ |
| type           | Receives data from the external source and passes them over the the next block.                                                | **externalDataBlock** (Can't be changed). |        |
| tag            | Unique name for the logic block.                                                                                               | mrv\_source.                              |        |
| permissions    | Which entity has rights to interact at this part of the workflow.                                                              | Installer.                                |        |
| defaultActive  | Shows whether this block is active at this time and whether it needs to be shown.                                              | Checked or unchecked.                     |        |
| entityType     | Specify the type of Entity this workflow block is for.                                                                         | MRV.                                      |        |
| schema         | Pre-configured schemas relevant for download to be selected from the drop down of available schemas in your Guardian instance. | MRV.                                      |        |

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).


# retirementDocumentBlock

### Properties

| Block Property   | Definition                                                                        | Example Input                                  | Status |
| ---------------- | --------------------------------------------------------------------------------- | ---------------------------------------------- | ------ |
| type             | Receives the VC from the previous block and retires based on the rule(s).         | **retirementDocumentBlock**(Can't be changed). |        |
| tag              | Unique name for the logic block.                                                  | retire\_token.                                 |        |
| permissions      | Which entity has rights to interact at this part of the workflow.                 | Standard Registry.                             |        |
| defaultActive    | Shows whether this block is active at this time and whether it needs to be shown. | Checked or unchecked.                          |        |
| stop Propagation | End processing here, don't pass control to the next block.                        | Checked or unchecked.                          |        |

### UI Properties

| UI Property | Definition                                                                                                                                                                   |
| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Token       | Select which token to retire. The token must exist in the Guardian instance.                                                                                                 |
| Rule        | Rules under which the number of tokens is calculated. Math operations are supported, e.g. the following will result in 20 tokens: data = { amount: 2 } rule = "amount \* 10" |

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).


# calculateContainerBlock & calculateMathAddOnBlock

## calculateContainerBlock

This Block accepts source VC as input and generates output as new VC document.

### Input Parameters:

#### inputSchema : source VC schema

#### inputFields : array of variables which would be taken from the source VC.

| Variable | Definition                               | Example of Input |
| -------- | ---------------------------------------- | ---------------- |
| name     | Refer to the specified field value       | field0           |
| title    | Title of the operation                   | Summary          |
| value    | Variable to store the value of the field | E0               |

```
"inputFields": [
                    {
                      "name": "field0",
                      "title": "Summary",
                      "value": "E0"
                    },
                ]
```

New variable "E0" would be created with a value set to one from the "field0" in the VC document.

{% hint style="info" %}
"title" is not a mandatory parameter. The value is set automatically as per the user convenience.
{% endhint %}

### Output Parameters

#### outputSchema : output VC schema

#### outputFields : array of variables of output VC, which will be the field with the values from the variables.

| Variable | Definition                                | Example of Input |
| -------- | ----------------------------------------- | ---------------- |
| name     | Variable that refers to specified field   | field0           |
| title    | Title of the operation                    | Summary          |
| value    | Points to the value of specified variable | E1               |

```
outputFields: [
                    {
                      "name": "field0",
                      "title": "Summary",
                      "value": "E1"
                    }
                ]
```

The output variable "field0" will contain the value from the variable "E1".

{% hint style="info" %}
"title" is not a mandatory parameter. The value is set automatically as per the user convenience.
{% endhint %}

## calculateMathAddonBlock

This Block performs mathematical calculations sequentially.

#### equations : array of formulas.

```
"equations": [
                    {
                      "variable": "E1",
                      "formula": "E0*10"
                    }
                ]
```

When above code is executed, a new variable, "E1" will be created which would contain the value of the calculation "E0\*10".

{% hint style="info" %}
Note: All the expressions available in [Math.js](https://mathjs.org/docs/) are supported by calculateMathAddOnBlock.
{% endhint %}

<table><thead><tr><th>Operator</th><th>Name</th><th>Syntax</th><th width="140">Associativity</th><th>Example</th><th>Result</th></tr></thead><tbody><tr><td><code>(</code>, <code>)</code></td><td>Grouping</td><td><code>(x)</code></td><td>None</td><td><code>2 * (3 + 4)</code></td><td><code>14</code></td></tr><tr><td><code>[</code>, <code>]</code></td><td>Matrix, Index</td><td><code>[...]</code></td><td>None</td><td><code>[[1,2],[3,4]]</code></td><td><code>[[1,2],[3,4]]</code></td></tr><tr><td><code>{</code>, <code>}</code></td><td>Object</td><td><code>{...}</code></td><td>None</td><td><code>{a: 1, b: 2}</code></td><td><code>{a: 1, b: 2}</code></td></tr><tr><td><code>,</code></td><td>Parameter separator</td><td><code>x, y</code></td><td>Left to right</td><td><code>max(2, 1, 5)</code></td><td><code>5</code></td></tr><tr><td><code>.</code></td><td>Property accessor</td><td><code>obj.prop</code></td><td>Left to right</td><td><code>obj={a: 12}; obj.a</code></td><td><code>12</code></td></tr><tr><td><code>;</code></td><td>Statement separator</td><td><code>x; y</code></td><td>Left to right</td><td><code>a=2; b=3; a*b</code></td><td><code>[6]</code></td></tr><tr><td><code>;</code></td><td>Row separator</td><td><code>[x; y]</code></td><td>Left to right</td><td><code>[1,2;3,4]</code></td><td><code>[[1,2],[3,4]]</code></td></tr><tr><td></td><td>Statement separator</td><td><code>x \n y</code></td><td>Left to right</td><td><code>a=2 \n b=3 \n a*b</code></td><td><code>[2,3,6]</code></td></tr><tr><td><code>+</code></td><td>Add</td><td><code>x + y</code></td><td>Left to right</td><td><code>4 + 5</code></td><td><code>9</code></td></tr><tr><td><code>+</code></td><td>Unary plus</td><td><code>+y</code></td><td>Right to left</td><td><code>+4</code></td><td><code>4</code></td></tr><tr><td><code>-</code></td><td>Subtract</td><td><code>x - y</code></td><td>Left to right</td><td><code>7 - 3</code></td><td><code>4</code></td></tr><tr><td><code>-</code></td><td>Unary minus</td><td><code>-y</code></td><td>Right to left</td><td><code>-4</code></td><td><code>-4</code></td></tr><tr><td><code>*</code></td><td>Multiply</td><td><code>x * y</code></td><td>Left to right</td><td><code>2 * 3</code></td><td><code>6</code></td></tr><tr><td><code>.*</code></td><td>Element-wise multiply</td><td><code>x .* y</code></td><td>Left to right</td><td><code>[1,2,3] .* [1,2,3]</code></td><td><code>[1,4,9]</code></td></tr><tr><td><code>/</code></td><td>Divide</td><td><code>x / y</code></td><td>Left to right</td><td><code>6 / 2</code></td><td><code>3</code></td></tr><tr><td><code>./</code></td><td>Element-wise divide</td><td><code>x ./ y</code></td><td>Left to right</td><td><code>[9,6,4] ./ [3,2,2]</code></td><td><code>[3,3,2]</code></td></tr><tr><td><code>%</code></td><td>Percentage</td><td><code>x%</code></td><td>None</td><td><code>8%</code></td><td><code>0.08</code></td></tr><tr><td><code>%</code></td><td>Addition with Percentage</td><td><code>x + y%</code></td><td>Left to right</td><td><code>100 + 3%</code></td><td><code>103</code></td></tr><tr><td><code>%</code></td><td>Subtraction with Percentage</td><td><code>x - y%</code></td><td>Left to right</td><td><code>100 - 3%</code></td><td><code>97</code></td></tr><tr><td><code>%</code> <code>mod</code></td><td>Modulus</td><td><code>x % y</code></td><td>Left to right</td><td><code>8 % 3</code></td><td><code>2</code></td></tr><tr><td><code>^</code></td><td>Power</td><td><code>x ^ y</code></td><td>Right to left</td><td><code>2 ^ 3</code></td><td><code>8</code></td></tr><tr><td><code>.^</code></td><td>Element-wise power</td><td><code>x .^ y</code></td><td>Right to left</td><td><code>[2,3] .^ [3,3]</code></td><td><code>[8,27]</code></td></tr><tr><td><code>'</code></td><td>Transpose</td><td><code>y'</code></td><td>Left to right</td><td><code>[[1,2],[3,4]]'</code></td><td><code>[[1,3],[2,4]]</code></td></tr><tr><td><code>!</code></td><td>Factorial</td><td><code>y!</code></td><td>Left to right</td><td><code>5!</code></td><td><code>120</code></td></tr><tr><td><code>&#x26;</code></td><td>Bitwise and</td><td><code>x &#x26; y</code></td><td>Left to right</td><td><code>5 &#x26; 3</code></td><td><code>1</code></td></tr><tr><td><code>~</code></td><td>Bitwise not</td><td><code>~x</code></td><td>Right to left</td><td><code>~2</code></td><td><code>-3</code></td></tr><tr><td><code>|</code></td><td>Bitwise or</td><td><code>x | y</code></td><td>Left to right</td><td><code>5 | 3</code></td><td><code>7</code></td></tr><tr><td><code>^|</code></td><td>Bitwise xor</td><td><code>x ^| y</code></td><td>Left to right</td><td><code>5 ^| 2</code></td><td><code>7</code></td></tr><tr><td><code>&#x3C;&#x3C;</code></td><td>Left shift</td><td><code>x &#x3C;&#x3C; y</code></td><td>Left to right</td><td><code>4 &#x3C;&#x3C; 1</code></td><td><code>8</code></td></tr><tr><td><code>>></code></td><td>Right arithmetic shift</td><td><code>x >> y</code></td><td>Left to right</td><td><code>8 >> 1</code></td><td><code>4</code></td></tr><tr><td><code>>>></code></td><td>Right logical shift</td><td><code>x >>> y</code></td><td>Left to right</td><td><code>-8 >>> 1</code></td><td><code>2147483644</code></td></tr><tr><td><code>and</code></td><td>Logical and</td><td><code>x and y</code></td><td>Left to right</td><td><code>true and false</code></td><td><code>false</code></td></tr><tr><td><code>not</code></td><td>Logical not</td><td><code>not y</code></td><td>Right to left</td><td><code>not true</code></td><td><code>false</code></td></tr><tr><td><code>or</code></td><td>Logical or</td><td><code>x or y</code></td><td>Left to right</td><td><code>true or false</code></td><td><code>true</code></td></tr><tr><td><code>xor</code></td><td>Logical xor</td><td><code>x xor y</code></td><td>Left to right</td><td><code>true xor true</code></td><td><code>false</code></td></tr><tr><td><code>=</code></td><td>Assignment</td><td><code>x = y</code></td><td>Right to left</td><td><code>a = 5</code></td><td><code>5</code></td></tr><tr><td><code>?</code> <code>:</code></td><td>Conditional expression</td><td><code>x ? y : z</code></td><td>Right to left</td><td><code>15 > 100 ? 1 : -1</code></td><td><code>-1</code></td></tr><tr><td><code>:</code></td><td>Range</td><td><code>x : y</code></td><td>Right to left</td><td><code>1:4</code></td><td><code>[1,2,3,4]</code></td></tr><tr><td><code>to</code>, <code>in</code></td><td>Unit conversion</td><td><code>x to y</code></td><td>Left to right</td><td><code>2 inch to cm</code></td><td><code>5.08 cm</code></td></tr><tr><td><code>==</code></td><td>Equal</td><td><code>x == y</code></td><td>Left to right</td><td><code>2 == 4 - 2</code></td><td><code>true</code></td></tr><tr><td><code>!=</code></td><td>Unequal</td><td><code>x != y</code></td><td>Left to right</td><td><code>2 != 3</code></td><td><code>true</code></td></tr><tr><td><code>&#x3C;</code></td><td>Smaller</td><td><code>x &#x3C; y</code></td><td>Left to right</td><td><code>2 &#x3C; 3</code></td><td><code>true</code></td></tr><tr><td><code>></code></td><td>Larger</td><td><code>x > y</code></td><td>Left to right</td><td><code>2 > 3</code></td><td><code>false</code></td></tr><tr><td><code>&#x3C;=</code></td><td>Smallereq</td><td><code>x &#x3C;= y</code></td><td>Left to right</td><td><code>4 &#x3C;= 3</code></td><td><code>false</code></td></tr><tr><td><code>>=</code></td><td>Largereq</td><td><code>x >= y</code></td><td>Left to right</td><td><code>2 + 4 >= 6</code></td><td><code>true</code></td></tr></tbody></table>

### Example

In the input VC is { "field0" : 5 }

```
		calculateContainerBlock:
			"inputFields": [
				{
				  "name": "field0",
				  "value": "E0"
				}
			]
			"outputFields": [
				{
				  "name": "field0",
				  "value": "E1"
				}
			]
		calculateMathAddon
			"equations": [
				{
				  "variable": "E1",
				  "formula": "E0*10"
				}
			]
```

Then

1. input VC variable "E0" will contain 5 (eg. "E0" = 5)
2. When executed a new variable "E1" will be created with the value "E1" = E0\*10 = 5 \* 10 = 50
3. In the output VC there will be "E1" variable
4. The result will be VC = { "field0" : 50 }


# reportBlock & reportItemBlock

## reportBlock

### 1. Properties

| Block Property | Definition                                                                        | Example Input                      | Status |
| -------------- | --------------------------------------------------------------------------------- | ---------------------------------- | ------ |
| type           | Type of workflow logic                                                            | **reportBlock**(Can't be changed). |        |
| tag            | Unique name for the logic block.                                                  | report.                            |        |
| permissions    | Which entity has rights to interact at this part of the workflow.                 | Standard Registry.                 |        |
| defaultActive  | Shows whether this block is active at this time and whether it needs to be shown. | Checked or unchecked.              |        |

### 2. Impacts Section

We have added new Impacts Section to display Primary/Secondary Impacts token details in Trustchain:

<figure><img src="/files/LF0X7uFHelFd2sW8bRUS" alt=""><figcaption></figcaption></figure>

In the case when multiple linked mint blocks are used then the system displays all linked VPs as shown below:

<figure><img src="/files/R1VTxztdbijQibRSk7wx" alt=""><figcaption></figcaption></figure>

#### 2.1 Data Format:

Ingress Document has following sections:

| Document Type         | Description                                                   |
| --------------------- | ------------------------------------------------------------- |
| vpDocument            | VP document found based on its hash                           |
| vcDocument            | VC document found based on its hash                           |
| impacts (new)         | array of Impacts (VCs) if exist                               |
| mintDocument          | VC document describing the mint                               |
| policyDocument        | VC document describing the policy                             |
| policyCreatorDocument | VC document describing the Standard Registry                  |
| documents             | collection of VC documents retrieved from the reportItemBlock |
| additionalDocuments   | array of VPs linked with the selected document                |

### 3. Token Transfer Section

Token transfer, which shows how much tokens is already transferred (will display only when transfer is needed)

<figure><img src="/files/McSnhyoBjuH2dOFn2OD2" alt=""><figcaption></figcaption></figure>

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```javascript
{
  "hash": "BV4VxNEGvBjodqZ6KWCoV6r4xks4LYSGu8mjWyXLLX52",
  "data": {
    "vpDocument": {
      "type": "VP",
      "title": "Verifiable Presentation",
      "tag": "mint_token",
      "hash": "BV4VxNEGvBjodqZ6KWCoV6r4xks4LYSGu8mjWyXLLX52",
      "issuer": "did:hedera:testnet:7Q9aPi8rEhceMGMqviCdya9APf515YVbtiyjHrHYPh5N_0.0.3075949",
      "username": "Virtual User 1",
      "document": {
        "_id": "63da2203db84efbb04da45a7",
        "dryRunId": "63da04e19670adb07f82b092",
        "dryRunClass": "VpDocumentCollection",
        "owner": "did:hedera:testnet:7Q9aPi8rEhceMGMqviCdya9APf515YVbtiyjHrHYPh5N_0.0.3075949",
        "hash": "BV4VxNEGvBjodqZ6KWCoV6r4xks4LYSGu8mjWyXLLX52",
        "document": {
          "id": "urn:uuid:0bb9966d-bbce-4e7d-a943-21c7d6283adc",
          "type": [
            "VerifiablePresentation"
          ],
          "@context": [
            "https://www.w3.org/2018/credentials/v1"
          ],
          "verifiableCredential": [
            {
              "id": "urn:uuid:7aeb978a-01bf-4ceb-be52-33997832e32d",
              "type": [
                "VerifiableCredential"
              ],
              "issuer": "did:hedera:testnet:9jShvNUsztLFbvEK442VPfkccLYW3F2oU3e6rCHzr7FT_0.0.3075949",
              "issuanceDate": "2023-02-01T08:25:38.804Z",
              "@context": [
                "https://www.w3.org/2018/credentials/v1"
              ],
              "credentialSubject": [
                {
                  "field0": "did:hedera:testnet:7Q9aPi8rEhceMGMqviCdya9APf515YVbtiyjHrHYPh5N_0.0.3075949",
                  "field1": "did:hedera:testnet:EHXwuE486eSD4yGXr6qTNLstmb8H1B2Jn4kx3PeWZzjv_0.0.1675232535045",
                  "field2": {
                    "field0": "Organization Name",
                    "type": "dee7e78b-44b8-4bb0-8be0-3a86bde752b2",
                    "@context": []
                  },
                  "field3": {
                    "field0": "device1",
                    "type": "b61a05c6-bb1a-4d7e-9299-c0932d8c0306",
                    "@context": []
                  },
                  "field6": "2023-02-01",
                  "field7": 1,
                  "field8": "2023-02-01",
                  "field17": "StandardRegistry",
                  "field18": "0.0.3075944",
                  "policyId": "63da04e19670adb07f82b092",
                  "ref": 
"did:hedera:testnet:EHXwuE486eSD4yGXr6qTNLstmb8H1B2Jn4kx3PeWZzjv_0.0.1675232535045",
                  "@context": [
                    "schema#80b8a663-8dec-411f-83fd-6e4cb7170427"
                  ],
                  "id": "urn:uuid:bdc30a12-443f-43a1-b1ff-05fdb4d39017",
                  "type": "80b8a663-8dec-411f-83fd-6e4cb7170427"
                }
              ],
              "proof": {
                "type": "Ed25519Signature2018",
                "created": "2023-02-01T08:25:38Z",
                "verificationMethod": "did:hedera:testnet:9jShvNUsztLFbvEK442VPfkccLYW3F2oU3e6rCHzr7FT_0.0.3075949#did-root-key",
                "proofPurpose": "assertionMethod",
                "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..hcXXdjwaicZzXlUraPIaQqEpMkt9tRYJWAEMX8j8ipXUcrh1dgTDeHxHmVfxOrpOaxqgoo2Sf2VltQi8FRjvBA"
              }
            },
            {
              "id": "urn:uuid:c6ae4294-bd77-43ec-9389-f0c1a9bbc830",
              "type": [
                "VerifiableCredential"
              ],
              "issuer": "did:hedera:testnet:9jShvNUsztLFbvEK442VPfkccLYW3F2oU3e6rCHzr7FT_0.0.3075949",
              "issuanceDate": "2023-02-01T08:25:38.920Z",
              "@context": [
                "https://www.w3.org/2018/credentials/v1"
              ],
              "credentialSubject": [
                {
                  "date": "2023-02-01T08:25:38.917Z",
                  "tokenId": "0.0.3120996",
                  "amount": "1",
                  "@context": [
                    "ipfs://bafkreib67gunqam5jcv6xx3ioapfzyrnvte5wvpmcq56emso5acckercae"
                  ],
                  "type": "MintToken"
                }
              ],
              "proof": {
                "type": "Ed25519Signature2018",
                "created": "2023-02-01T08:25:38Z",
                "verificationMethod": 
.....
```

{% endtab %}
{% endtabs %}

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

#### Request Body

| Name                                          | Type   | Description |
| --------------------------------------------- | ------ | ----------- |
| filterValue<mark style="color:red;">\*</mark> | String | VP Hash     |

## reportItemBlock

### Properties

| Block Property  | Definition                                                                                                                                                                              | Example Input                                                                                                                                                                                                                                               |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Title           | Title of the element                                                                                                                                                                    | Report                                                                                                                                                                                                                                                      |
| Description     | Description of the element                                                                                                                                                              | Reporting                                                                                                                                                                                                                                                   |
| Visibility      | Visibility of the element. False if there is a need to build a chain of elements which must not be shown                                                                                | False                                                                                                                                                                                                                                                       |
| Multiple        | which allows store multiple documents in Report Item                                                                                                                                    | True                                                                                                                                                                                                                                                        |
| Filters         | Array of filters for the VC for this element                                                                                                                                            | <p>"filters": \[</p><p>{</p><p>"field": "document.id", "value": "actionId", "typeValue": "variable", "type": "equal"</p><p>},</p><p>{</p><p>"typeValue": "value",</p><p>"field": "type",</p><p>"type": "equal",</p><p>"value": "report"</p><p>}</p><p>]</p> |
| Dynamic Filters | We can set “Field Path” (in current Report Item Document\[s]), “Next Item Field Path” and “Type” (Filter Type) to filter documents in Report Items dynamically directly in trust chain. | Type                                                                                                                                                                                                                                                        |
| Variables       | List of common variables. It gets filled in in the process of the transition from one reportItemBlock to the next                                                                       | <p>"variables": \[</p><p>{</p><p>"value":"document.credentialSubject.0.ref",</p><p>"name": "projectId"</p><p>}</p><p>]</p>                                                                                                                                  |

A new variable projectId will be created which would be assigned the value from document.credentialSubject.0.ref.


# switchBlock

### Properties

| Block Property     | Definition                                                                        | Example Input                                                                                                                                                                          | Status |
| ------------------ | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ |
| tag                | Unique name for the logic Block.                                                  | **switchBlock**                                                                                                                                                                        |        |
| permissions        | Which entity has rights to interact at this part of the workflow.                 | Standard Registry                                                                                                                                                                      |        |
| defaultActive      | Shows whether this block is active at this time and whether it needs to be shown. | Checked or Unchecked                                                                                                                                                                   |        |
| On errors          | Called if the system error occurs in the Block                                    | <ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul>                                                                                                         |        |
| stop Propagation   | End processing here, don't pass control to the next block.                        | Checked or Unchecked                                                                                                                                                                   |        |
| Execution Flow     | Flow of Execution                                                                 | <ol><li>First True - only the ‘branch’ under the first ‘true’ condition gets executed.</li><li>2. All True - branches under all conditions evaluated as ‘true’ get executed.</li></ol> |        |
| Condition(i)       | number of the condition                                                           | if (field(0))>1                                                                                                                                                                        |        |
| Condition Type     | Type of the condition                                                             | Equal - resolves as true if the condition is true - Not Equal - resolved as true if the condition is false - Unconditional - always true                                               |        |
| Condition (String) | condition expression which can contain math formulas                              | field0 > 0                                                                                                                                                                             |        |
| Actor              | the permissions/role context of the execution of the next block                   | Current User - user under whom the condition is evaluated - Document Owner - the creator of the document - Document Issuer - the signator of the document                              |        |
| Condition Tag      | The name of the dynamic events to use                                             | Condition 1                                                                                                                                                                            |        |

![](/files/huuq8zrGHki593hnoRxH)

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).


# aggregateDocumentBlock

### Properties

Input - a document or an array of documents which will be aggregated

Output - an array of documents, after the reporting period expired or the condition is met

| Block Property   | Definition                                                                                  | Example Input                                                                  | Status |
| ---------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------ |
| tag              | Unique name for the logic block.                                                            | **aggregateDocumentBlock**                                                     |        |
| permissions      | Which entity has rights to interact at this part of the workflow.                           | Standard Registry.                                                             |        |
| defaultActive    | Shows whether this block is active at this time and whether it needs to be shown.           | Checked or unchecked.                                                          |        |
| On errors        | Called if the system error occurs in the Block                                              | <ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul> |        |
| stop Propagation | End processing here, don't pass control to the next block.                                  | Checked or unchecked.                                                          |        |
| GroupByFields    | We can set additional fields to group documents. Also documents are always grouped by user. | Field Path                                                                     |        |
| AggregateType    | Type of Aggregate                                                                           | <ul><li>Cumulative Dimension</li><li>Period</li></ul>                          |        |

```
If ‘Aggregate Type’ = ‘Cumulative Dimension’
			Expressions - calculated variables which help to ease the work with Condition and enable complex calculations
				Expression (i)
					Variable Name (string) - name of the variable
					Variable Value (string) - formula for calculating of the value of the variable
			Condition (string) - condition expression which can contain math formulas
		
If ‘Aggregate Type’ = ‘Period’
			Timer - timer object to track the aggregation period (launched separately)
			(Please note that this functionality will change in the near future)

			Empty Data - if this parameter is set to true the timer gets triggered even if there were no data
```

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).


# TimerBlock

### Properties

Input - document which is needed to start the timer for different users separately.

| Block Property   | Definition                                                                        | Example Input                                                                                                                                                                                                                                                                                                                      | Status |
| ---------------- | --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ |
| tag              | Unique name for the logic block.                                                  | **timerBlock**                                                                                                                                                                                                                                                                                                                     |        |
| permissions      | Which entity has rights to interact at this part of the workflow.                 | Standard Registry.                                                                                                                                                                                                                                                                                                                 |        |
| defaultActive    | Shows whether this block is active at this time and whether it needs to be shown. | Checked or unchecked.                                                                                                                                                                                                                                                                                                              |        |
| On errors        | Called if the system error occurs in the Block                                    | <ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul>                                                                                                                                                                                                                                                     |        |
| stop Propagation | End processing here, don't pass control to the next block.                        | Checked or unchecked.                                                                                                                                                                                                                                                                                                              |        |
| Start Date       | date/time to start the timer                                                      | 16-05-2022 16:00 (UTC+04:00)                                                                                                                                                                                                                                                                                                       |        |
| End Date         | date/time to stop the timer                                                       | 16-05-2022 16:00 (UTC+04:00)                                                                                                                                                                                                                                                                                                       |        |
| Period           | specification of the period which timer triggers (starting from the Start Date)   | <p>Yearly</p><p>Monthly</p><p>Weekly</p><p>Daily</p><p>Hourly</p><p>Custom - advanced period</p><p>configuration</p><p>If ‘Period’ = ‘Custom’<br>Mask - cron mask for timer (example: <a href="https://crontab.guru/"><https://crontab.guru/></a>)<br>Interval (number) - trigger timer on every tick<br>(e.g. every two days)</p> |        |
| Custom Period    | open dialogue window to set Mask and Interval                                     | 0 12 \*\*\*\* 4                                                                                                                                                                                                                                                                                                                    |        |

### Events

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

To know more information about events, please look at [Events](/guardian/workspace/policies/policy-creation/introduction/events).


# revokeBlock

This block finds related messages in policy topics, and revokes those messages and sends it to Hedera topic, but it doesn’t save documents in DB. Output of this Block is the documents array.

### Properties

| Block Property                  | Definition                                                                        | Example Input                                                                  | Status |
| ------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------ |
| tag                             | Unique name for the logic block.                                                  | **revokeBlock**                                                                |        |
| permissions                     | Which entity has rights to interact at this part of the workflow.                 | Registrant                                                                     |        |
| defaultActive                   | Shows whether this block is active at this time and whether it needs to be shown. | Checked or unchecked.                                                          |        |
| On errors                       | Called if the system error occurs in the Block                                    | <ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul> |        |
| stop Propagation                | End processing here, don't pass control to the next block.                        | Checked or unchecked.                                                          |        |
| Update previous document status | flag which updates previous document status.                                      | Checked or unchecked.                                                          |        |
| Status value                    | Value of the Previous document status                                             | Waiting for approval                                                           |        |


# setRelationshipsBlock

This block contains DocumentsSourceAddOn and **set relationships** for input document from DocumentsSourceAddOn documents (messageId’s). It doesn’t save document to database.

### Properties

| Block Property   | Definition                                                                        | Example Input                                                                  | Status |
| ---------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------ |
| tag              | Unique name for the logic block.                                                  | **setRelationshipsBlock**                                                      |        |
| permissions      | Which entity has rights to interact at this part of the workflow.                 | VVB                                                                            |        |
| defaultActive    | Shows whether this block is active at this time and whether it needs to be shown. | Checked or unchecked.                                                          |        |
| On errors        | Called if the system error occurs in the Block                                    | <ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul> |        |
| stop Propagation | End processing here, don't pass control to the next block.                        | Checked or unchecked.                                                          |        |
| Include Accounts | Merges all the accounts from the documents                                        | Checked or unchecked.                                                          |        |
| Change Owner     | It takes owner from first document                                                | Checked or unchecked.                                                          |        |
| Include Tokens   | We can get token template name and appropriate token id from related documents    | Checked or unchecked.                                                          |        |


# buttonBlock

### Properties

| Block Property   | Definition                                                                        | Example Input                                                                  | Status |
| ---------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------ |
| tag              | Unique name for the logic block.                                                  | **buttonBlock**                                                                |        |
| permissions      | Which entity has rights to interact at this part of the workflow.                 | VVB                                                                            |        |
| defaultActive    | Shows whether this block is active at this time and whether it needs to be shown. | Checked or unchecked.                                                          |        |
| On errors        | Called if the system error occurs in the Block                                    | <ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul> |        |
| stop Propagation | End processing here, don't pass control to the next block.                        | Checked or unchecked.                                                          |        |

### Button

| Block Property            | Definition                                                                                                                                                                                                           | Example Input                                                                                                            | Status |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------ |
| Type                      | Type of the Button                                                                                                                                                                                                   | <p>Two types of buttons:<br>1. Selector : Simply button. 2. Selector - dialog : button with dialog</p>                   |        |
| Button Tag                | Tag of the button will be chosen in events tab                                                                                                                                                                       | Button\_0                                                                                                                |        |
| Dialog Title              | pop - up dialog title. this field gets enabled when button type is Selector-dialog                                                                                                                                   | Reject                                                                                                                   |        |
| Dialog Description        | It is the text inside dialog pop up. This field is enabled when button type is Selector - dialog                                                                                                                     | Enter reject reason                                                                                                      |        |
| Button Name               | Label of the button                                                                                                                                                                                                  | Validate                                                                                                                 |        |
| Field                     | Field of document to change                                                                                                                                                                                          | option.status                                                                                                            |        |
| Value                     | Value to set                                                                                                                                                                                                         | Validated                                                                                                                |        |
| UI Class                  | UI class of the button                                                                                                                                                                                               | btn-approve                                                                                                              |        |
| hideWhenDiscontinued      | Check if the button should be hidden when policy is discontinued                                                                                                                                                     | Checked/Unchecked                                                                                                        |        |
| Filters                   | array of addition visible filters                                                                                                                                                                                    | <p>Field (field) – field of document.</p><p>Value (value) – field to compare.</p><p>Type (type)– type of comparison.</p> |        |
| dialogResultFieldPath     | This will allow to define destination field where value from dialog will be stored. Also it will not override value of this field, it will only be replaced to array or value will be just pushed to existing array. | Field Path                                                                                                               |        |
| Enable Individual Filters | As per button visibility filters instead of hiding all buttons                                                                                                                                                       | Checked or Unchecked                                                                                                     |        |

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```javascript
{
  "id": "fa4c1642-700a-44f6-a8eb-1089e77c4d64",
  "blockType": "buttonBlock",
  "type": "selector",
  "uiMetaData": {
    "options": [
      {
        "title": "",
        "name": "Add",
        "tooltip": "",
        "type": "text",
        "value": "Waiting for Validation",
        "uiClass": "btn-approve",
        "bindBlock": "save_added",
        "tag": "Option_0"
      }
    ],
    "content": "VVB",
    "buttons": [
      {
        "tag": "Option_0",
        "name": "Add",
        "type": "selector",
        "filters": [],
        "field": "option.status",
        "value": "Waiting for Validation",
        "uiClass": "btn-approve"
      }
    ]
  }
}

```

{% endtab %}
{% endtabs %}

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

#### Request Body

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| document<mark style="color:red;">\*</mark> | Object | VC Document |


# documentValidatorBlock

This block is to validate documents, including linked documents. This block returns an error if at least one of the checks don’t pass. It can be placed as a ‘child’ document, or as a link in the sequence of the blocks.

![](/files/e8fxnpLALHJn8XwWKeIt)

### Properties

<table><thead><tr><th width="208">Block Property</th><th>Definition</th><th>Example Input</th><th>Status</th></tr></thead><tbody><tr><td>tag</td><td>Unique name for the logic block.</td><td><strong>documentValidatorBlock</strong></td><td></td></tr><tr><td>permissions</td><td>Which entity has rights to interact at this part of the workflow.</td><td>VVB</td><td></td></tr><tr><td>defaultActive</td><td>Shows whether this block is active at this time and whether it needs to be shown.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>On errors</td><td>Called if the system error occurs in the Block</td><td><ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul></td><td></td></tr><tr><td>stop Propagation</td><td>End processing here, don't pass control to the next block.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>DocumentType</td><td>Type of the documents to be validated.</td><td><p>· VC Document</p><p>· VP Document</p><p>· Related VC<br>Document</p><p>. Related VP Document</p></td><td></td></tr><tr><td>Check Schema</td><td>Validates schema documents.</td><td>Schema</td><td></td></tr><tr><td>Check Own Document</td><td>If ‘true’ validates document owners.</td><td>True / False</td><td></td></tr><tr><td>Check Assign Document</td><td>If ‘true’ validates document owners.</td><td>True / False</td><td></td></tr><tr><td>Conditions</td><td>Array containing conditions for validation.</td><td>Array</td><td></td></tr></tbody></table>

![](/files/VGuvDRtWdlGNBxOBgBBS)

### Document Type

The following document types are supported:

1. VC Document : validates the main document and its type (Verifiable Credential).
2. VP Document : validates the main document and its type (Verifiable Presentation).
3. Related VC Document : validates the document linked to the main document and its type (Verifiable Credential)
4. Related VP Document : validates the document linked to the main document and its type (Verifiable Presentation)

### Conditions

#### Condition N

#### Type:

1. Equal – resolves to ‘true’ if value of the field is equal the content of the Value parameter.
2. Not Equal – resolves to ‘true’ if value of the field is NOT equal the content of the Value parameter.
3. In – resolves to ‘true’ if value of the field is present in the array.
4. Not In – resolves to ‘true’ if value of the field is present in the array.

#### Field :

This field of the document to validate the Value parameter.

#### Value:

The content of this parameter is compared to the content of the Field.


# Document Validator Block Source Validations

The Source Validations feature of `documentValidatorBlock` lets a policy step verify that a related document already exists in the Guardian database and that specific fields on that document satisfy conditions defined against the incoming document — before the workflow is allowed to proceed.

### The Problem It Solves

Many environmental MRV workflows depend on sequencing: a monitoring report is only valid after a project registration has been approved; an emission reduction claim must reference a methodology document that is already on record or search by projectID specific document and validate dates. Without a cross-document check at the block level, enforcing this ordering requires either a custom logic block or a manual review gate — all of which add complexity and introduce surface area for errors.

The Source Validations feature moves this responsibility into `documentValidatorBlock` itself. The block can query the Guardian database for documents that match a schema and ownership criteria, then test field-level conditions that span both the incoming document and the queried results, routing the event to the error output if the check fails.

### How It Works

A `documentValidatorBlock` can hold any number of Source Validation entries. Each entry is evaluated independently in order.

**Query phase.** The block builds a database filter from the entry's configuration:

* **Source Collection** — whether to query `VcDocument` or `VpDocument` records.
* **Schema** — restricts the query to documents that match a specific schema.
* **Ownership and assignment flags** — optionally limits results to documents owned by the current user, owned by their group, assigned to the user, or assigned to their group.
* **Source Filters** — field-level conditions on the source documents themselves (e.g. `credentialSubject.0.status` equals `Approved`). Each filter compares a source-document field to either a literal value or a field from the incoming document.

**Condition phase.** Once the query returns a set of candidate source documents, each one is tested against the entry's cross-document **Conditions**. A condition has two sides: each side can be a literal value, a path on the incoming document (`Input Document`), or a path on the candidate source document (`Source Document`). Supported operators are: `equal`, `not_equal`, `in`, `not_in`, `gt`, `gte`, `lt`, `lte`.

**Pass/fail semantics.** The entry passes if **at least one** candidate source document satisfies **all** conditions. If the query returns no documents, or every candidate fails at least one condition, the entry fails.

**Error reporting.** On failure the block constructs a detailed message describing which conditions failed and on how many source documents. If a custom Fail Message is set on the entry, it is prepended to the detail. The error is emitted as a `BlockActionError` that routes the event to the `ErrorEvent` output.

The full validation sequence for a document is:

1. Document existence check
2. Document type check (VC Document, VP Document, Related VC Document, Related VP Document)
3. Ownership checks (user or group)
4. Assignment checks (user or group)
5. Schema validation
6. Same-document Conditions (field conditions on the incoming document only)
7. Source Validations (cross-document, one entry at a time)

Any step that fails stops evaluation immediately and emits the error event.

### Key Distinctions

**Conditions vs. Source Validations.** The block has two separate condition mechanisms. The top-level **Conditions** array checks fields on the incoming document only — no database query is involved. **Source Validations** perform a database query and then compare fields across two documents. Use top-level Conditions for simple field checks; use Source Validations when the check depends on the state of another document.

**Source Filters vs. Source Validation Conditions.** Within a Source Validation entry, **Source Filters** narrow the database query (they affect which documents are candidates). **Conditions** test relationships between the candidate and the incoming document after the query returns. Filters reduce the candidate set; conditions determine whether any candidate in that set is sufficient.

**Pass if any, not pass if all.** The entry passes as soon as one candidate document satisfies all conditions. It does not require every queried document to satisfy the conditions.

### Related

* Task: [Configure Source Validations in documentValidatorBlock](/guardian/workspace/policies/policy-creation/introduction/documentvalidatorblock/configure-source-validations-in-documentvalidatorblock)
* Reference: [documentValidatorBlock](/guardian/workspace/policies/policy-creation/introduction/documentvalidatorblock)


# Configure Source Validations in documentValidatorBlock

Add one or more Source Validation entries to a `documentValidatorBlock` to make a policy step verify that a related document already exists in the Guardian database before allowing the workflow to continue.

### Prerequisites

* You have a policy open in edit mode.
* The policy contains a `documentValidatorBlock`, or you are about to add one.
* You know the schema names of the documents you want to validate against (visible in the Schemas section of the policy configuration).

### Steps

#### Add a Source Validation entry

1. Click the `documentValidatorBlock` in the policy canvas to open its configuration panel.
2. Scroll to the **Source Validations** section and click **Add Source Validation**.
3. In the new entry, open the **Source Collection** dropdown and select **VcDocument** or **VpDocument** depending on the type of documents you are querying.
4. (Optional) Open the **Schema** selector and choose the schema the source documents must match. Leave empty to query all documents in the collection.
5. (Optional) Enable any combination of the four ownership and assignment checkboxes:
   * **Only Own Documents** — restricts results to documents owned by the current user.
   * **Only Own by Group Documents** — restricts results to documents owned by the current user's group.
   * **Only Assigned Documents** — restricts results to documents assigned to the current user.
   * **Only Assigned by Group Documents** — restricts results to documents assigned to the current user's group.
6. (Optional) Enter a **Fail Message**. This text appears at the start of the error message when this entry fails. Use it to explain the business rule being enforced (e.g., `An approved project registration must exist before submitting a monitoring report.`).

#### Add Source Filters

Source Filters narrow which documents the block retrieves from the database. Add a filter for each field on the source document that must match a specific value or a value from the incoming document.

7. Inside the entry, expand **Source Filters** and click **Add Filter**.
8. Set **Field** to the JSON path of the field on the source document (e.g., `status`). Use the document-path picker to browse available fields.
9. Select an **Operator**: `equal`, `not_equal`, `in`, `not_in`, `gt`, `gte`, `lt`, or `lte`.
10. Set **Value Type**:
    * **Value** — compare against a literal string you enter directly.
    * **Variable** — compare against a field from the incoming document; enter the path using the document-path picker (e.g., `credentialSubject.0.projectId`).
11. Enter or select the comparison **Value**.
12. Repeat steps 7–11 for each additional filter.

#### Add cross-document Conditions

Conditions test relationships between fields on the queried source documents and fields on the incoming document. At least one source document must satisfy all conditions for the entry to pass.

13. Inside the entry, expand **Conditions** and click **Add Condition**.
14. Configure the **left side** of the condition:
    * Set **Left Source** to **Input Document**, **Source Document**, or **Value**.
    * If you selected a document source, enter the field path using the document-path picker. If you selected **Value**, enter a literal string.
15. Select an **Operator**.
16. Configure the **right side** of the condition using the same approach as step 14 (**Right Source** and the right-side field or literal).
17. Repeat steps 13–16 for each additional condition.

#### Add more Source Validation entries

18. To enforce multiple independent cross-document checks, click **Add Source Validation** again and repeat steps 3–17 for each entry. All entries must pass for the block to succeed.

#### Save

19. Click **Save** in the configuration panel.

### Result

When the policy executes this block, it processes each Source Validation entry in order. For each entry the block queries the database using the schema, ownership flags, and Source Filters you configured. It then tests each returned document against the Conditions. If at least one source document satisfies all conditions, the entry passes and execution continues to the next entry. If no source document satisfies all conditions — or the query returns no results — the block emits a `BlockActionError` with a detailed message listing which conditions failed and on how many candidate documents. The event is routed to the `ErrorEvent` output.

### Troubleshooting

**"No source documents found" error on every submission.** The query returned zero results. Check that the selected schema matches documents that actually exist in the policy's context, that the ownership/assignment flags match how those documents were created, and that each Source Filter field path is correct.

**Conditions fail even though the expected source document exists.** The error message lists the field name, operator, and values for each failing condition. Confirm that the field paths on both sides resolve correctly — use the document-path picker rather than typing paths manually. Also confirm that the value types are set to **Variable** (not **Value**) when you intend to compare against a field on the incoming document.

**An entry passes when it should fail.** Remember that the pass condition is "at least one source document satisfies all conditions." If multiple source documents match the query and one of them happens to satisfy the conditions, the entry will pass. Add more restrictive Source Filters to narrow the candidate set (e.g., filter documents by `projectId`).

### Related

* Concept: [Document Validator Block Source Validations](/guardian/workspace/policies/policy-creation/introduction/documentvalidatorblock/document-validator-block-source-validations)
* Reference: [documentValidatorBlock](/guardian/workspace/policies/policy-creation/introduction/documentvalidatorblock)


# tokenActionBlock

This block is responsible in performing automatic actions on the token.

### Properties

<table><thead><tr><th width="208">Block Property</th><th>Definition</th><th>Example Input</th><th>Status</th></tr></thead><tbody><tr><td>tag</td><td>Unique name for the logic block.</td><td><strong>tokenActionBlock</strong></td><td></td></tr><tr><td>permissions</td><td>Which entity has rights to interact at this part of the workflow.</td><td>VVB</td><td></td></tr><tr><td>defaultActive</td><td>Shows whether this block is active at this time and whether it needs to be shown.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>On errors</td><td>Called if the system error occurs in the Block</td><td><ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul></td><td></td></tr><tr><td>Stop Propagation</td><td>End processing here, don't pass control to the next block.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>Token</td><td>The token which is affected by the action</td><td>iREC token</td><td></td></tr><tr><td>Account Type</td><td><p>The type of the account under which the action is performed. If set to ‘Default’ the account of the currently logged in user is used (i.e. the owner of the document).</p><p>If set to ‘Custom’ the account specified in the ‘accountId’ field is used.</p></td><td>Custom</td><td></td></tr><tr><td>Account Id (Field)</td><td>The value from this field is used as the ID of the account under which the action is performed when ‘Account Type’ is set to ‘Custom’.</td><td>field0</td><td></td></tr><tr><td>Action</td><td>Action to be performed on Token</td><td><ul><li>Associate</li><li>Dissociate</li><li>Freeze</li><li>Unfreeze</li><li>Grant Kyc</li><li>Revoke Kyc</li></ul></td><td></td></tr><tr><td>Use Template</td><td>This needs to be enabled if we need to use token template, which is created already.</td><td>Enabled or Disabled</td><td></td></tr><tr><td>Token Template</td><td>Which will take created tokenId from input document by template name</td><td>token_template<em>_</em>0</td><td></td></tr></tbody></table>

![](/files/QXzP7UikLo5MP7Mrg47Y)

![](/files/aIPUCgKibXy111Hhxhb8)

{% hint style="info" %}
**Note:**

1. Only fields of ‘Hedera Account’ type can be used for ‘accountId’.
2. If the field specified in the ‘accountId’ is not found in the current document then the system will look for it in the parent documents.
3. ‘Associate’ and ‘Dissociate’ actions are not available when ‘Account Type’ is set to ‘Custom’. For these operations ‘[**tokenConfirmationBlock**](/guardian/workspace/policies/policy-creation/introduction/tokenconfirmationblock)’ should be used instead.
   {% endhint %}

### Actions

| Action Name | Purpose                                                                                                                                                        |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Associate   | Links the account with the token. This operation is required to enable the account to perform transactions (including receiving) with the token.               |
| Dissociate  | Removes the aforementioned ‘link’.                                                                                                                             |
| Freeze      | Freezes the account                                                                                                                                            |
| Unfreeze    | Unfreezes the account                                                                                                                                          |
| Grant KYC   | This action is mandatory if the token is configured to require KYC. The owner of the token is required to ‘grant KYC’ to enable transactions with the account. |
| Revoke KYC  | This revokes the account’s permission to participate in transactions with the token.                                                                           |

![](/files/WXU21LRZYqw00EBNcuxt)


# tokenConfirmationBlock

This block enables the owner of the private key for the account to manually perform operations with the token, including those not available in the ‘[**tokenActionBlock**](/guardian/workspace/policies/policy-creation/introduction/tokenactionblock)**’.**

### **1. Properties**

| Block Property     | Definition                                                                                                                                                                                                                                                     | Example Input                                                                  | Status |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------ |
| tag                | Unique name for the logic block.                                                                                                                                                                                                                               | **tokenConfirmationBlock**                                                     |        |
| permissions        | Which entity has rights to interact at this part of the workflow.                                                                                                                                                                                              | VVB                                                                            |        |
| defaultActive      | Shows whether this block is active at this time and whether it needs to be shown.                                                                                                                                                                              | Checked or unchecked.                                                          |        |
| On errors          | Called if the system error occurs in the Block                                                                                                                                                                                                                 | <ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul> |        |
| Stop Propagation   | End processing here, don't pass control to the next block.                                                                                                                                                                                                     | Checked or unchecked.                                                          |        |
| Token              | The token which is affected by the action                                                                                                                                                                                                                      | iREC token                                                                     |        |
| Account Type       | <p>The type of the account under which the action is performed. If set to ‘Default’ the account of the currently logged in user is used (i.e. the owner of the document).</p><p>If set to ‘Custom’ the account specified in the ‘accountId’ field is used.</p> | Custom                                                                         |        |
| Account Id (Field) | The value from this field is used as the ID of the account under which the action is performed when ‘Account Type’ is set to ‘Custom’.                                                                                                                         | field0                                                                         |        |
| Action             | Action to be performed on Token                                                                                                                                                                                                                                | <ul><li>Associate</li><li>Dissociate</li></ul>                                 |        |
| Use Template       | This needs to be enabled if we need to use token template, which is created already.                                                                                                                                                                           | Enabled/Disabled                                                               |        |
| Token Template     | Which will take created tokenId from input document by template name                                                                                                                                                                                           | token\_template\_\_\_0                                                         |        |

{% hint style="info" %}
**Notes:**

1. Only fields of ‘Hedera Account’ type can be used for ‘accountId’.
2. If the field specified in the ‘accountId’ is not found in the current document then the system will look for it in the parent documents.
3. Users can skip the action by selecting “I will *Action* manually” option in the UI. This would require the user to perform the corresponding action off-Guardian platform (directly on Hedera chain).
   {% endhint %}

![Block Properties](/files/s5mlBay11jl6ADKmMi41)

![JSON View of the Block](/files/uP1RFSkYD1PcBh7O0TOx)

![Configuring tokenConfirmationBlock](/files/KKnu3FU1TwJBAjatlGtU)

![Creating Event to move to next step](/files/xZg8psih7toBJGar4Hu5)

### 2. Performing Token Associate using Guardian UI

The user need to input the private key for the account to enable Guardian to perform the action. The key is used once for the operation specified, it is not saved and not logged anywhere.

{% hint style="info" %}
**Note:** Users can skip the action in UI if they prefer to perform it outside Guardian (directly with Hedera blockchain).
{% endhint %}

![](/files/cX3HR7w8NV4owky93eNe)

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```
{
  "id": "484c57c2-5ceb-41ed-97b3-61c52fce473e",
  "blockType": "tokenConfirmationBlock",
  "action": "associate",
  "accountId": "0.0.1",
  "tokenName": "GHG Token",
  "tokenSymbol": "GHG",
  "tokenId": "0.0.3121118"
}

```

{% endtab %}
{% endtabs %}

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy Id   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

#### Request Body

| Name                                               | Type   | Description                |
| -------------------------------------------------- | ------ | -------------------------- |
| action<mark style="color:red;">\*</mark>           | String | action                     |
| hederaAccountKey<mark style="color:red;">\*</mark> | String | Hedera Account Private Key |


# mintDocumentBlock

This block is responsible for adding configurations on calculating the amount of tokens to be minted.

### Properties

<table><thead><tr><th width="208">Block Property</th><th>Definition</th><th>Example Input</th><th>Status</th></tr></thead><tbody><tr><td>tag</td><td>Unique name for the logic block.</td><td><strong>mintDocumentBlock</strong></td><td></td></tr><tr><td>permissions</td><td>Which entity has rights to interact at this part of the workflow.</td><td>VVB</td><td></td></tr><tr><td>defaultActive</td><td>Shows whether this block is active at this time and whether it needs to be shown.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>On errors</td><td>Called if the system error occurs in the Block</td><td><ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul></td><td></td></tr><tr><td>Stop Propagation</td><td>End processing here, don't pass control to the next block.</td><td>Checked or unchecked.</td><td></td></tr></tbody></table>

### Additional Properties

<table><thead><tr><th width="208">Block Property</th><th>Definition</th><th>Example Input</th><th>Status</th></tr></thead><tbody><tr><td>Round Method</td><td>The method used to round the number of tokens.</td><td><p>Select an option from the dropdown ('Round to nearest' is selected by default):</p><ul><li>Round up</li><li>Round down</li><li>Round to nearest</li></ul></td><td></td></tr><tr><td></td><td></td><td></td><td></td></tr></tbody></table>

### UI Properties

| UI Property        | Definition                                                                                                                                                          | Example Input                                                                     |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| Token              | The token which is affected by the action                                                                                                                           | GHG Token                                                                         |
| Account Type       | The value from this field is used as the ID of the account under which the action is performed when ‘Account Type’ is set to ‘Custom Account Field’.                | <ul><li>Custom Account Field</li><li>Custom Account Value</li></ul>               |
| Rule               | Math expression for calculation of the amount of tokens to mint.                                                                                                    | field7 \* 100                                                                     |
| Account Id (Field) | The value from this field is used as the ID of the account which is used for token transfer action when ‘Account Type’ is set to ‘Custom’.                          | field5                                                                            |
| Account Id (Value) | Allow users to set custom Hedera account id directly in policy configuration (for token transferring). This field is displayed only when Custom Account Value type. | 0.0.48640912                                                                      |
| Memo               | The value in this field is used to customize the Memo field name.                                                                                                   | "mint date is $ {document.verifiableCredential\[0],credentialSubject\[0].field5}" |
| Use Template       | This needs to be enabled if we need to use token template, which is created already.                                                                                | Enabled/Disabled                                                                  |
| Token Template     | Which will take created tokenId from input document by template name                                                                                                | token\_template\_\_\_0                                                            |

<figure><img src="/files/aOkxUrqEmUgbTw5kx8m1" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**Notes:**

1. Only fields of ‘Hedera Account’ type can be used for ‘accountId’.
2. If the field specified in the ‘accountId’ not found in the current document the system will look for it in the parent documents.
   {% endhint %}


# Events

There is a new tab called ‘Events’ for every block in the GUI where events can be configured. The events allow Policy creators to transfer control/execution on exit from the current block to an arbitrary block and thus build non-linear workflows.

![](/files/SMtelQlqCmQatiLJDu9V)

### Settings:

| Property Name | Name in JSON | Property Value                                                    | Value in JSON                          | Description                                                                                                                     |
| ------------- | ------------ | ----------------------------------------------------------------- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Event Type    | -            | <p>Input Event</p><p>Output Event</p>                             | -                                      | Type of the event - determines whether this is ingress or egress event for the current block.                                   |
| Source        | "source"     | Block tag(string)                                                 | "block\_tag"                           | The block which initiates the event.                                                                                            |
| Target        | "target"     | Block tag(string)                                                 | "block\_tag"                           | The block which receives the event.                                                                                             |
| Output Event  | "output"     | Event name(string)                                                | "event\_name"                          | Action or issue that caused the event.                                                                                          |
| Input Event   | "input"      | Event name(string)                                                | "event\_name"                          | Action which will be triggered by the event.                                                                                    |
| Event Actor   | "actor"      | <p>Event Initiator</p><p>Document Owner</p><p>Document Issuer</p> | <p>""</p><p>"owner"</p><p>"issuer"</p> | Allows to transfer control of the block (execution context) to another user. Empty field leaves control at the Event Initiator. |
| Disabled      | "disabled"   | True/False                                                        | true/false                             | Allows to disable the event without deleting it.                                                                                |

![](/files/SMtelQlqCmQatiLJDu9V)

![](/files/FqSLl5xOMqjuW0pVTAGm)

{% hint style="info" %}
Note: The event is shown in both source and target blocks tabs regardless of where it was added initially.
{% endhint %}

### Default Events

Default events correspond to the implicit default transfer of execution control from the current to the next (adjacent) block graphically represented by the block immediately below the current one.

Default events can be switched off by setting ‘Disabled’ to ‘true’ on the Events tab, or ‘Stop Propagation’ to ‘true’ on the Properties tab as in the older Guardian versions.

![](/files/UQ7sZBguzDaD0ghLC4sS)

### Output Events

Output events are events which are created by the ‘Source’ blocks.

**Output Event (enum):**

**All Blocks:**

* RunEvent - appears upon the completion of main logic of the block.
* RefreshEvent - triggered upon the changes in the state of the block.

![](/files/uWI3JlMub47QF9hSrTx3)

**TimerBlock:**

* TimerEvent – triggered upon each ‘tick’ of the timer

**switchBlock:**

* Condition 1..N - each condition expression in the switch block maps to the corresponding event created upon the evaluation of its condition into ‘true’

![](/files/huuq8zrGHki593hnoRxH)

**InterfaceActionBlock:**

* Option 1..N - each Option (button) triggers a corresponding event upon the button press action from the user

![](/files/8Col1pFQWF31XV2SsINo)

#### Calculate Block, Custom Logic Block, DocumentValidatorBlock, ExternalDataBlock, MintBlock, Reassigning Block, RequestVcDocumentBlock, RetirementBlock, RevokeBlock, SendToGuardianBlock, TokenActionBlock, TokenConfirmationBlock

* Error Event : Which is called and passed the input data when error occur.

### Input Events

Input Events are received and processed by the egress interface of the ‘Target’ block.

**Input Event (enum):**

**All Blocks:**

* RunEvent - triggers the execution of the main logic of the block.
* RefreshEvent - triggers the refresh of the block (in the UI it re-draws the component)

**aggregateDocumentBlock:**

* TimerEvent - triggers the execution of the time(period)-activated aggregation logic, and passes the aggregated data further
* PopEvent - removes the document from the aggregation.

![](/files/CNrYv4tZtrwdrBKZiyNT)

**timerBlock:**

* StartTimerEvent - starts the timer for the user (to ‘tick’ for the time-activated aggregation logic)
* StopTimerEvent – stops the ‘ticking’ timer for the user

#### RequestVcDocumentBlock:

* RestoreEvent - Which receive input vc document to restore data.

#### mintDocumentBlock:

* AdditionalMintEvent - allows linking of the result of one mint block with another mint block.
* RetryMintEvent - It allows to retry mint action if there were some errors, issues there. Environment variable RETRY\_MINT\_INTERVAL is setting up retry mint interval (in minutes), default is 10 minutes.

<figure><img src="/files/ixxTSGJaqmnChKegG8qY" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**Note:**

1. The link starts with “RunEvent” of the main Mint Block and ends with “AdditionalMintEvent” of the secondary Mint Block
2. “Default Event” of the main Mint Block must be switched off if linked Mint Blocks follow each other
   {% endhint %}

### Event Actor

Allows to change the user-context of the execution

*For example*: in the situation where the Standard Registry confirms the form data from the user and the Policy author would like to come back to the execution of the StepBlock as the original user the ‘Document Owner’ should be configured here instead of the ‘Event Initiator’.

* Event Initiator - Actor which triggered the event.
* Document Owner- Actor is changed to the owner of the document.
* Document Issuer - Actor is changed to the user who signed (confirmed) the document.

### Viewer

#### Output events

![](/files/HQDyzC3BuQwqjk8iML0b)

#### Input events

![](/files/AzY2ccvZRbSLs1jF9G2F)

#### Default Events

![](/files/3953ympYWMQKQzTtO99s)

#### Tooltips

![](/files/Gm9ypZK0Ul4AyVUfNt8V)

#### Filters

![](/files/b6Z6m1EoZMRdAdKtqBDh)


# groupManagerBlock

This block allows to manage group membership, add and remove users from the group.

### 1. Properties

| Block Property   | Definition                                                                        | Example Input                                                                               | Status |
| ---------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ------ |
| tag              | Unique name for the logic block.                                                  | **groupManagerBlock**                                                                       |        |
| permissions      | Which entity has rights to interact at this part of the workflow.                 | NoRole                                                                                      |        |
| defaultActive    | Shows whether this block is active at this time and whether it needs to be shown. | Checked or unchecked.                                                                       |        |
| On errors        | Called if the system error occurs in the Block                                    | <ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul>              |        |
| Stop Propagation | End processing here, don't pass control to the next block.                        | Checked or unchecked.                                                                       |        |
| Can Invite       | specifies who can create invites                                                  | <p>· Group Owner – only the creator of the group</p><p>· All – all members of the group</p> |        |
| Can Delete       | specifies who can remove users from the group                                     | <p>· Group Owner – only the creator of the group</p><p>. All – all members of the group</p> |        |

<figure><img src="/files/JyM0aUtits5dNJlxt4Co" alt=""><figcaption></figcaption></figure>

### 2. Usage

#### 2.1 **List of the groups in which the user is included:**

<figure><img src="/files/nQdPxKLEEypEQ69hkcT3" alt=""><figcaption></figcaption></figure>

#### **2.2 List of the users included in the group**

<figure><img src="/files/K9ShxCrI2s8v5PA0SlUn" alt=""><figcaption></figcaption></figure>

#### **2.3 Inviting users to groups**

First step is to select the role to invite the user as shown below:

<figure><img src="/files/vqI9P0xd0q9YVxxeq2Ek" alt=""><figcaption></figcaption></figure>

Next step is to copy and send the unique invite or the link to the invite.

<figure><img src="/files/QPq7XzYVIsda1mVmckut" alt=""><figcaption></figcaption></figure>

#### 2.4 **Removing users from groups**

<figure><img src="/files/oc7BBUcDnXOfCaa8yT7U" alt=""><figcaption></figcaption></figure>

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```javascript
{
  "data": [
    {
      "id": "6b3efd88-037c-4335-a4d1-02776e23973c",
      "role": "VVB(manager)",
      "groupName": "VVBs",
      "groupLabel": "vvb_group1",
      "type": "Owner",
      "groupRelationshipType": "Multiple",
      "groupAccessType": "Private",
      "canInvite": true,
      "canDelete": true,
      "roles": [
        "VVB"
      ],
      "data": [
        {
          "did": "did:hedera:testnet:HdSCbrXJjjfvzymnnzzybNVWQGGGY48p6JGo6Ao5UHnT_0.0.3075949",
          "username": "Virtual User 1",
          "role": "VVB(manager)",
          "type": "Owner",
          "current": true
        },
        {
          "did": "did:hedera:testnet:CJotqpGfK9zVqDHgjtkHg5EPvkTShQVc3hZjojw8St3N_0.0.3075949",
          "username": "Virtual User 2",
          "role": "VVB",
          "type": "Member",
          "current": false
        }
      ]
    }
  ]
}


```

{% endtab %}
{% endtabs %}

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

#### Request Body

| Name                                      | Type   | Description      |
| ----------------------------------------- | ------ | ---------------- |
| action<mark style="color:red;">\*</mark>  | String | invite/delete    |
| role<mark style="color:red;">\*</mark>    | String | role             |
| group<mark style="color:red;">\*</mark>   | String | group            |
| user<mark style="color:red;">\*</mark>    | String | User DID         |
| message<mark style="color:red;">\*</mark> | String | removing message |


# multiSignBlock

This block provides a way to specify multiple signators for a single VC document, and then create a VP based on it.

### 1. Properties

| Block Property   | Definition                                                                                                                                                     | Example Input                                                                  | Status |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | ------ |
| tag              | Unique name for the logic block.                                                                                                                               | **multiSignBlock**                                                             |        |
| permissions      | Which entity has rights to interact at this part of the workflow.                                                                                              | NoRole                                                                         |        |
| defaultActive    | Shows whether this block is active at this time and whether it needs to be shown.                                                                              | Checked or unchecked.                                                          |        |
| On errors        | Called if the system error occurs in the Block                                                                                                                 | <ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul> |        |
| Stop Propagation | End processing here, don't pass control to the next block.                                                                                                     | Checked or unchecked.                                                          |        |
| Threshold (%)    | Proportion Of signators which are required to sign the document to achieve quorum for it to transition to ‘signed’ status. Must be a number between 0 and 100. | 0-100                                                                          |        |

{% hint style="info" %}
**Note:** The system assigns ‘not signed’ status to the document when 100 – threshold percentage of users indicated rejection status.
{% endhint %}

### 2. Events

| Event                         | Description                                                                          | Content                                                                     |
| ----------------------------- | ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------- |
| SignatureQuorumReachedEvent   | This event occurs when the threshold number (quorum) of signatures has been reached. | now-signed target VC document which can then be used for further processing |
| SignatureSetInsufficientEvent | This event occurs when the threshold number (quorum) of rejections has been achieved | rejected (target) VC document which can be used for further processing      |

### 3. Data Format

#### 3.1 POST request

```
{
	"document":{
		"id":"…" – ID of the VC document
	},
	"status":"SIGNED" – new status, can be SIGNED or DECLINED
}

```

#### 3.2 GET request

```
{
	blockType: "multiSignBlock"
	id:"61ed0335-8b7e-44d9-aedd-0c86c5806442"
	status: {
		confirmationStatus: - final status, it is ‘null’ if the quorum is not reached
		data: [
				{
						username,
						did – did and username of the user which took the decision
						status – the decision of the user, the value space is: SIGNED/DECLINED
		                 }
		       ] 
	         }
}

```

#### Array of the decisions for each user can be as follows:

| Type of Decision  | Description                                                                                                |
| ----------------- | ---------------------------------------------------------------------------------------------------------- |
| declinedCount     | number of users who declined signing the document                                                          |
| declinedPercent   | percentage of users who need to decline signing the document                                               |
| declinedThreshold | threshold number of users who need to decline signing the document to reach the final decision             |
| documentStatus    | status of the document for the current users, null if the user has not made a selection to sign or decline |
| signedCount       | number of users who have signed the document                                                               |
| signedPercent     | percentage of users who have signed the document                                                           |
| signedThreshold   | threshold number of users who need to sign the document to reach the final decision                        |
| threshold         | threshold in terms of percentage                                                                           |
| total             | total number of users in the signing group                                                                 |

### 4. Example

#### 4.1 Important Points

4.1.1 multiSignBlock must be used with Groups.

<figure><img src="/files/kV71cR0bGltZlZpy4CM2" alt=""><figcaption></figcaption></figure>

4.1.2 multiSignBlock must be child block of grid block to receive all data it requires to operate.

<figure><img src="/files/BiMYrnWy23rY6dFSB93X" alt=""><figcaption></figcaption></figure>

### 5. UI

#### 5.1 Signing the document

We have an option of Signing/ Declining the document by clicking on "Sign" or "Decline" button for the document as shown below:

<figure><img src="/files/mtEqpXPOLMhVuLO0xcDK" alt=""><figcaption></figcaption></figure>

#### 5.2 Threshold Display

Number of users, who have signed or declined the document can be displayed with threshold as shown below:

<figure><img src="/files/W0Y5JyzDENXsDJMLKVi0" alt=""><figcaption></figcaption></figure>

#### 5.3 Detailed Signature Information

To get detailed information on Signature status, we have an info icon near the threshold as shown below:

<figure><img src="/files/2PcpIvtGTOsqTlsqCtet" alt=""><figcaption></figcaption></figure>

#### 5.4 Final Signature Result

To get the final Signature Result with detailed information such as which users have Signed / Declined, we need to hover on the Status as shown below:

<figure><img src="/files/uwL1I99TVvVGBbCygh3w" alt=""><figcaption></figcaption></figure>

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```javascript
{
  "id": "1c922d1a-7f9d-492f-b0f9-f319eb2b66be",
  "blockType": "multiSignBlock"
}

```

{% endtab %}
{% endtabs %}

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

#### Request Body

| Name                                       | Type   | Description     |
| ------------------------------------------ | ------ | --------------- |
| status<mark style="color:red;">\*</mark>   | String | Signed/Declined |
| document<mark style="color:red;">\*</mark> | Object | VC Document     |


# customLogicBlock

## Properties

<table><thead><tr><th width="208">Block Property</th><th>Definition</th><th width="200">Example Input</th><th>Status</th></tr></thead><tbody><tr><td>tag</td><td>Unique name for the logic block.</td><td><strong>customLogicBlock</strong></td><td></td></tr><tr><td>permissions</td><td>Which entity has rights to interact at this part of the workflow.</td><td>NoRole</td><td></td></tr><tr><td>defaultActive</td><td>Shows whether this block is active at this time and whether it needs to be shown.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>On errors</td><td>Called if the system error occurs in the Block</td><td><ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul></td><td></td></tr><tr><td>Stop Propagation</td><td>End processing here, don't pass control to the next block.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>Output Schema</td><td>Sending the logic output to this particular Schema</td><td>Report Employee schema</td><td></td></tr><tr><td>Document Signer</td><td>defines who will sign processed document.<br>Options:<br>1. Policy Owner<br>2. First Document Owner<br>3. First Document Issues</td><td>Policy Owner</td><td></td></tr><tr><td>Id Type</td><td>defines Id Type in credential subject of processed document.<br>Options:<br>1. DID (new DID)<br>2. UUID (new UUID)<br>3. Owner (Owner DID)</td><td>UUID (new UUID)</td><td></td></tr></tbody></table>

{% hint style="info" %}
**Note:** Only this block supports artifacts for now.
{% endhint %}

This block supports two types of artifacts : JSON (.json) and Executable Code (.js).

**JSON** : will be added to the “artifacts” variable which is array in specific order (for example artifacts\[0] is e\_grid\_mapping json object).

**Executable Code** : will be executed before main function.

To access table data in custom logic block, please check [Custom Logic Block & Tables](/guardian/workspace/schemas/available-schema-types/table-data-input-field/custom-logic-block-and-tables) for more details.


# splitBlock

This block allows to accumulate VC documents and produce new VCs in fixed chunks.

If the value in the VC is higher than the chunking threshold the VC would be spilt into multiple VCs containing values equal to the threshold value.

## 1. Properties

<table><thead><tr><th width="208">Block Property</th><th>Definition</th><th width="200">Example Input</th><th>Status</th></tr></thead><tbody><tr><td>tag</td><td>Unique name for the logic block.</td><td><strong>splitBlock</strong></td><td></td></tr><tr><td>permissions</td><td>Which entity has rights to interact at this part of the workflow.</td><td>NoRole</td><td></td></tr><tr><td>defaultActive</td><td>Shows whether this block is active at this time and whether it needs to be shown.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>On errors</td><td>Called if the system error occurs in the Block</td><td><ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul></td><td></td></tr><tr><td>Stop Propagation</td><td>End processing here, don't pass control to the next block.</td><td>Checked or unchecked.</td><td></td></tr><tr><td>Threshold</td><td>The size of a single ‘portion’ (chunk) the original document would be split into.<br>Note: It is always number>0</td><td>1000</td><td></td></tr><tr><td>Source field</td><td>It is the path to the field in the VC document which is the parameter used in the calculation of the ‘size’ of the VC.<br><strong>Note</strong>: <em>is a field to which the ‘source field’ path points. It must be of numeric type.</em></td><td>source path link</td><td></td></tr></tbody></table>

## 2. Data(VC documents) format

After ‘splitting’ of the VC document into several chunks these new created VCs will contain:

1. All fields except the ‘source field’ copied without any changes.
2. Added **evidence** section of the following content:

```
{
            "type": [
                "SourceDocument"
            ],
            "messageId": "1655895001.624621306",
            "sourceField": "document.credentialSubject.0.field0",
            "sourceValue": 200,
            "threshold": 50,
            "chunkNumber": 1,
            "maxChunk": 4
        }

```


# Create Token Block

## Properties

| Block Property   | Definition                                                                                      | Example Input                              | Status |
| ---------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------ | ------ |
| type             | A type of the block which creates a form from the schema, and sends the document to the server. | **Create Token Block** (Can't be changed). |        |
| tag              | Unique name for the logic block.                                                                | add\_new\_installer\_request.              |        |
| permissions      | Which entity has rights to interact at this part of the workflow.                               | Standard Registry.                         |        |
| defaultActive    | Shows whether this block is active at this time and whether it needs to be shown.               | Checked or unchecked.                      |        |
| stop propagation | End processing here, don't pass control to the next block.                                      | Checked or Unchecked.                      |        |
| Token Template   | We can set template by which we want to create token                                            | token\_template\_\_\_0                     |        |

## UI Properties

| UI Property          | Definition                                                                                                                                                                    |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Type                 | Style of the render of the form. It can be either a Page (the form is rendered as a page) or Dialogue (displays a button, which opens a dialogue with the form when clicked). |
| Title                | Provides the Page or Dialogue box a title.                                                                                                                                    |
| Description          | Provides the Page or Dialogue box a description.                                                                                                                              |
| Button Content       | Text to fill inside a button. Needs the Dialogue box to be selected from the "Type."                                                                                          |
| Dialogue Text        | Provides a tile inside the Dialogue box. Needs the dialogue box to be selected from the "Type."                                                                               |
| Dialogue Description | Provides a description inside the Dialogue box. Needs the dialogue box to be selected from the "Type."                                                                        |

### API Parameters

<mark style="color:blue;">`GET`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

{% tabs %}
{% tab title="200: OK Successful Operation" %}

```javascript
{
  "id": "a411e417-bff7-49dc-bbf0-a4e5b7501b73",
  "blockType": "createTokenBlock",
  "uiMetaData": {
    "type": "page",
    "title": "Create Token",
    "description": "Please enter token info"
  },
  "active": true,
  "data": {
    "templateTokenTag": "token_template_0",
    "tokenType": "fungible",
    "decimals": 3,
    "enableAdmin": true,
    "changeSupply": true
  }
}
```

{% endtab %}
{% endtabs %}

<mark style="color:green;">`POST`</mark> `/policies/{policyId}/blocks/{uuid}`

#### Path Parameters

| Name                                       | Type   | Description |
| ------------------------------------------ | ------ | ----------- |
| policyId<mark style="color:red;">\*</mark> | String | Policy ID   |
| uuid<mark style="color:red;">\*</mark>     | String | Block UUID  |

#### Request Body

| Name                                           | Type    | Description              |
| ---------------------------------------------- | ------- | ------------------------ |
| tokenName<mark style="color:red;">\*</mark>    | String  | Token Name               |
| tokenSymbol<mark style="color:red;">\*</mark>  | String  | Token Symbol             |
| tokenType<mark style="color:red;">\*</mark>    | String  | Fungible or Non Fungible |
| decimals<mark style="color:red;">\*</mark>     | String  | Token decimals           |
| enableAdmin<mark style="color:red;">\*</mark>  | Boolean | Enable Admin Flag        |
| enableSupply<mark style="color:red;">\*</mark> | Boolean | Enable Supply Flag       |
| enableFreeze<mark style="color:red;">\*</mark> | Boolean | Enable Freeze Flag       |
| enableKYC<mark style="color:red;">\*</mark>    | Boolean | Enable KYC Flag          |
| enableWipe<mark style="color:red;">\*</mark>   | Boolean | Enable Wipe Flag         |


# impactAddon

This Addon for the mint block which allows to add additional info for the token being created.

### 1. Properties

<table><thead><tr><th width="200.33333333333331">Property Name</th><th>Description</th><th>Example</th><th>Status</th></tr></thead><tbody><tr><td>Tag</td><td>Unique name for the logic block.</td><td><strong>impactAddon_1</strong></td><td></td></tr><tr><td>Permissions</td><td>Which entity has rights to interact at this part of the workflow.</td><td>Standard Registry</td><td></td></tr><tr><td>Default Active</td><td>Shows whether this block is active at this time and whether it needs to be shown.</td><td>Checked or UnChecked</td><td></td></tr><tr><td>Stop Propagation</td><td>End processing here, don't pass control to the next block.</td><td>Checked or UnChecked</td><td></td></tr><tr><td>On Errors</td><td>Called if the system error occurs in the Block</td><td><ul><li>No action</li><li>Retry</li><li>Go to step</li><li>Go to tag</li></ul></td><td></td></tr><tr><td>Impact Type</td><td>shows the type of the impact</td><td>Primary Impacts / Secondary Impacts</td><td></td></tr><tr><td>Label</td><td>Title of the Impact</td><td>Test</td><td></td></tr><tr><td>Description</td><td>Description of the impact</td><td>Impact description</td><td></td></tr><tr><td>Amount (Formula)</td><td>Formula for calculating the impact quantitative representation based on the data from the source VC</td><td>field0</td><td></td></tr><tr><td>Unit</td><td>Unit of measurement of impact amounts</td><td>Kg</td><td></td></tr></tbody></table>

<figure><img src="/files/UHIqMzyBTEB4BDKNb7h0" alt=""><figcaption></figcaption></figure>

### 2. Data Format

Adding impactAddon changes VP documents such that:

2.1 New VC documents are added for each impact describing it

```
{
    "id": "732d46ca-1e19-43a2-a4b1-49cf5ea08aa9",
    "type": [
        "VerifiableCredential"
    ],
    "issuer": "did:hedera:testnet:BJDCUTd8gFSaFwW4w7Tw8dbx7DfnkfLjJ14s2dquesS9_0.0.49039174",
    "issuanceDate": "2022-12-06T11:27:37.964Z",
    "@context": [
        "https://www.w3.org/2018/credentials/v1"
    ],
    "credentialSubject": [
        {
            "@context": [
                "ipfs://bafkreiabgmqbzd4s2u2jy74ebkawbtvs3ohc76qhphx4vvuymskpfmjj2u"
            ],
            "type": "ActivityImpact",
            "impactType": "Primary Impacts",
            "date": "2022-12-06T11:27:37.959Z",
            "amount": "2000",
            "unit": "kg",
            "label": "Test 1",
            "description": "Test Description 1"
        }
    ],
    "proof": {
        "type": "Ed25519Signature2018",
        "created": "2022-12-06T11:27:37Z",
        "verificationMethod": "did:hedera:testnet:BJDCUTd8gFSaFwW4w7Tw8dbx7DfnkfLjJ14s2dquesS9_0.0.49039174#did-root-key",
        "proofPurpose": "assertionMethod",
        "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..nK_fvwC9nW9jtKHm2U4yAHhIcgpGCkr1H7PiPNwKzAj9gW2sblpu0TAQEow9OR9v1aREEH-fFLmyAGEfXWfXAw"
    }
}

```

2.2 All source VCs are substituted for a single cumulative VC containing links to the source (original) VCs.

```
{
    "id": "443e9e7b-3a67-4ad9-a22d-d85c2d28562f",
    "type": [
        "VerifiableCredential"
    ],
    "issuer": "did:hedera:testnet:BJDCUTd8gFSaFwW4w7Tw8dbx7DfnkfLjJ14s2dquesS9_0.0.49039174",
    "issuanceDate": "2022-12-06T11:27:37.936Z",
    "@context": [
        "https://www.w3.org/2018/credentials/v1"
    ],
    "credentialSubject": [
        {
            "@context": [
                "ipfs://bafkreicnjditzstltfyu2327pqqcstuwl5vegwe2hepbwcque2gjvwsm3y"
            ],
            "type": "TokenDataSource",
            "dataSource": [
                "1670.326057800",
                "1670.451857512"
            ]
        }
    ],
    "proof": {
        "type": "Ed25519Signature2018",
        "created": "2022-12-06T11:27:37Z",
        "verificationMethod": "did:hedera:testnet:BJDCUTd8gFSaFwW4w7Tw8dbx7DfnkfLjJ14s2dquesS9_0.0.49039174#did-root-key",
        "proofPurpose": "assertionMethod",
        "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..N5sOQOgxBxPdvGvCJbfJ4rWBc6374Ht96xKTAN6Pwrhr8Pk4SWqS6IwDePBySTIbvVETPFFxjzGQZMsbENx5BA"
    }
}

```


# Http Request Block

Block for retrieving information from outside (3rd party) services via HTTP requests.

## Properties

| Property Name    | Description                                                                       | Example                   | Status |
| ---------------- | --------------------------------------------------------------------------------- | ------------------------- | ------ |
| Tag              | Unique name for the logic block.                                                  | **Http\_Block**           |        |
| Permissions      | Which entity has rights to interact at this part of the workflow.                 | Standard Registry         |        |
| Default Active   | Shows whether this block is active at this time and whether it needs to be shown. | Checked or UnChecked      |        |
| Stop Propagation | End processing here, don't pass control to the next block.                        | Checked or UnChecked      |        |
| On Errors        | Called if the system error occurs in the Block                                    | <p>No action<br>Retry</p> |        |
| URL              | URL of the external service end point                                             | <http://localhost:8080>   |        |
| Method           | HTTP method of the request                                                        | GET/POST/DELETE/PUT/PATCH |        |
| Body             | Body of the HTTP request                                                          | $(document)               |        |
| Headers          | Additional HTTP headers (can be used for authentication purposes)                 | Bearer $(document).Source |        |

<figure><img src="/files/WqVfS9D2BLbc2TeAJOmd" alt=""><figcaption></figcaption></figure>

To prevent sensitive headers such as Bearer tokens from being published to IPFS during policy export, an "Include value in exported policy" checkbox was added to each HTTP header in the httpRequestBlock.

This mechanism ensures that secrets are not accidentally leaked when the policy is published and stored on IPFS.

{% hint style="info" %}
Note:

1. By default, this checkbox is set to false, meaning the header's value will not be included in the exported policy.
2. If a header has a value but the "Include" option is not enabled, publishing the policy will fail with a validation error. The user must either enable the checkbox or remove the header value.
   {% endhint %}

## 2. Dynamic Variables

The values of the URL, Body and Header parameters can contain variables of the format ${variable}.

Possible values are as follows:

* “did” – DID of the current user
* “username” – name of the current user
* “document” or “documents” – a single document or an array of document correspondingly, which have been passed to the block on entry


# historyAddon

This block turn on history on interfaceDocumentsSourceBlock. This block should be placed inside interfaceDocumentsSourceBlock.

### Properties

| Property Name           | Description                                                                       | Example                                                   | Status |
| ----------------------- | --------------------------------------------------------------------------------- | --------------------------------------------------------- | ------ |
| Tag                     | Unique name for the logic block.                                                  | **history\_addon**                                        |        |
| Permissions             | Which entity has rights to interact at this part of the workflow.                 | Registrant                                                |        |
| Default Active          | Shows whether this block is active at this time and whether it needs to be shown. | Checked or Unchecked                                      |        |
| Stop Propagation        | End processing here, don't pass control to the next block.                        | Checked or Unchecked                                      |        |
| On Errors               | Called if the system error occurs in the Block                                    | <p>- No action<br>- Retry</p>                             |        |
| timelineLabelPath       | Label of timeline point                                                           | “option.status”. It is default value if setting is empty  |        |
| timelineDescriptionPath | Description of timeline point                                                     | “option.comment”. It is default value if setting is empty |        |

<figure><img src="/files/oEPlQVK2Ro5yB24RH8oL" alt=""><figcaption></figcaption></figure>


# selectiveAttributes Block

This Block can be placed inside documentsSourceAddon. This will filter attributes (option field) in documents returned by documentsSourceAddon.

### Properties

| Property Name    | Description                                                                       | Example                                                                                                                                                                                                       | Status |
| ---------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ |
| Tag              | Unique name for the logic block.                                                  | **selective\_attributes\_addon**                                                                                                                                                                              |        |
| Permissions      | Which entity has rights to interact at this part of the workflow.                 | Registrant                                                                                                                                                                                                    |        |
| Default Active   | Shows whether this block is active at this time and whether it needs to be shown. | Checked or Unchecked                                                                                                                                                                                          |        |
| Stop Propagation | End processing here, don't pass control to the next block.                        | Checked or Unchecked                                                                                                                                                                                          |        |
| On Errors        | Called if the system error occurs in the Block                                    | <p>- No action<br>- Retry</p>                                                                                                                                                                                 |        |
| Attributes       | Array of attributes to select                                                     | <p>"attributes": \[</p><p>{</p><p>"attributePath": "status"</p><p>},<br><br><strong>Note:</strong> If value is empty no attributes will be selected and field option in returned documents will be empty.</p> |        |

<figure><img src="/files/MKX2gOphiJDD4KRDadRM" alt=""><figcaption></figcaption></figure>


# tagsManagerBlock

Block ***tagsManager*** is responsible for managing tags in policies. This block should be added as a ‘child’ block to the grid and linked to one of its columns. This block does not have any settings.

## Properties

| Property Name    | Description                                                                       | Example                       | Status |
| ---------------- | --------------------------------------------------------------------------------- | ----------------------------- | ------ |
| Tag              | Unique name for the logic block.                                                  | **tags\_manager**             |        |
| Permissions      | Which entity has rights to interact at this part of the workflow.                 | Registrant                    |        |
| Default Active   | Shows whether this block is active at this time and whether it needs to be shown. | Checked or Unchecked          |        |
| Stop Propagation | End processing here, don't pass control to the next block.                        | Checked or Unchecked          |        |
| On Errors        | Called if the system error occurs in the Block                                    | <p>- No action<br>- Retry</p> |        |

<figure><img src="/files/f3nNyEWQbwCtnExHYXfd" alt=""><figcaption></figcaption></figure>


# extractDataBlock

This block is used for VC documents which are based on (or ‘conform to’) a schema which contains embedded schemas, extractDataBlock provides means to extract a data set which corresponds to any of these embedded schemas (at any depth level), and if required after processing to return the updated values back into the VC dataset to their original ‘place’.

## 1. Properties

| Property Name | Details                                                                                                                                                                 | Example                                                                                                                                                                                                    | Status |
| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ |
| Action        | an action which is executed by the block                                                                                                                                | <p>o Get – find and extract the part of the document which corresponds to the specified schema</p><p>o Set – update the part of the document, which corresponds to the specified schema, with new data</p> |        |
| Schema        | the schema which is target of the action. It is used to identify the embedded part of the data object - i.e. the field in the document which corresponds to this schema | Contact Details (1.1)                                                                                                                                                                                      |        |

### 1.1 Extraction

<figure><img src="/files/h2azSBUUp5BUchw6k6qp" alt=""><figcaption></figcaption></figure>

### 1.2 Update

<figure><img src="/files/leMy29SIYaXQtHWxDe9L" alt=""><figcaption></figcaption></figure>


# externalTopicBlock

This block allows to configure the link to Hedera topics established by other policy instances for monitoring of ‘document published’ messages and ingestion of the targeted VC documents.

<figure><img src="/files/1tz7kEJ2nVqLJbCnkiZZ" alt=""><figcaption></figcaption></figure>

## 1.1 Properties

| Property Name    | Description                                                                                                                                                                                                                                                                                                  | Example                       | Status |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- | ------ |
| Tag              | Unique name for the logic block.                                                                                                                                                                                                                                                                             | **externalTopic**             |        |
| Permissions      | Which entity has rights to interact at this part of the workflow.                                                                                                                                                                                                                                            | Standard Registry             |        |
| Default Active   | Shows whether this block is active at this time and whether it needs to be shown.                                                                                                                                                                                                                            | Checked or Unchecked          |        |
| Stop Propagation | End processing here, don't pass control to the next block.                                                                                                                                                                                                                                                   | Checked or Unchecked          |        |
| On Errors        | Called if the system error occurs in the Block                                                                                                                                                                                                                                                               | <p>- No action<br>- Retry</p> |        |
| Schema           | a schema containing the minimal structure/content requirements for the VC documents to comply with in order to be ingested from the topic. A compliant document can be a super set of the minimal schema, i.e. it can contain other properties/data so long as it also has what is specified in this schema. | Schema                        |        |

## 1.2 Data Format

### 1.2.1 GET

```
{
    documentTopicId – topic which contains links to documents to be ingested (optional/required depending on the stage in the workflow)
    policyTopicId – topic which contains policy messages (optional/required depending on the stage in the workflow)
    instanceTopicId – topic which contains policy instance specific messages (optional/required depending on the stage in the workflow)
    documentMessage – message with the information about the document topic(documentTopicId)
    policyMessage – message with the information about the policy topic(policyTopicId)
    policyInstanceMessage – message with the information about the policy instance topic(instanceTopicId)
    schemas – schemas accessible in the select policy (if specified)
    schema – schema which was selected by the user
    lastUpdate – time stamp of the last synchronisation
    status – link status
}

```

### 1.2.2 POST

* **Topic selection** – allow the user to specify the topic which contains messages about the documents to be ingested.

```
{
    "operation": "SetTopic",
    "value": "topicId"
}
```

* **Schema selection** – allows the user to specify the schema for selecting (filtering) the documents to be ingested.

```
{
    "operation": "SetSchema",
    "value": "schemaId"
}
```

* **Schema verification** – verifies if the selected schema is compliant with the settings of the block

```
{
    "operation": "VerificationSchema",
    "value": "schemaId"
}
```

* **Manual loading of the documents** – triggers immediate (out of schedule) synchronization of the documents (the automatic synchronization will still takes place as per the schedule)

```
{
    "operation": "VerificationSchemas",
}
```

* **Reset of the link** – allows to reset settings and specify afresh.

```
{
    "operation": "Restart",
}
```


# messagesReportBlock

## 1. messagesReportBlock:

This Block allows to create report based on the inter-referenced messages.

![image1.png](/files/QIZXi1f6VcL2U38quLNL)

## **1.1 Properties**

Does not contain additional settings.

## **1.2 Data format**

### **GET**

**status** – current report status

1. FAILED – error encountered during the building
2. STARTED – reporting building is in progress
3. FINISHED – reporting building has been successfully completed

**target** – the document which is the subject of the report

**report** – the current report

```
{
"roles" – documents showing users and their roles
"users" – list of identified users
"schemas" – list of identified schemas
"tokens" – list of identified tokens
"topics" – hierarchical structure of Hedera topics and messages relevant to the target document
{
"topicId" – unique topic identifier
"message" – document describing the topic
"messages" – list of documents referenced in the topic
"children" – child topics
}
}
```

### **POST**

* Target document identification based on message ID - the system creates the report on the document which is referenced in the Header message with the specified ID (the presence of the document in the local Guardian database is not required)

```
{
"filterValue": "hedera message id"
}
```

* Target document identification by its hash – they system build the report on the document in the local DB which has the specified hash

```
{
"filterValue": "hash"
}
```

* Resets the report

```
{
"filterValue": "",
}
```

## 2. Example

Block can work independently (stand-alone):

![image2.png](/files/05ewmeLaUKRjpb5O2W3K)

Or used in conjunctions with other blocks (e.g. with grid)

![image3.png](/files/WNfCnAekCcFtvxagYKKJ)

### **2.1 Display** **Modes**

#### **2.1.1 Simplified** – folds all messages for a policy into a single ‘swim lane’.

* Only policy topics are displayed
* Auxiliary events (such as publishing policy) are hidden

![image4.png](/files/nrfLuCi6KfAxVNRmSG77)

#### **2.1.2 Advanced** – complete information is displayed with

* Full hierarchical topic structure
* All auxiliary and system events

![image5.png](/files/TpmhjgaXRHBGNOHXj4lW)

#### **2.1.3 Display layout**

* Left-side panel shows hierarchical catalog of Header topics.

![image6.png](/files/lXZLbthIvlHZJDIsPKad)

* Central area shows the timeline of the events as they have been recorded (in messages) in the specific topics

![image5.png](/files/TpmhjgaXRHBGNOHXj4lW)

* Right-side panel shows detailed information about the selected message

![image1.png](/files/QIZXi1f6VcL2U38quLNL)


# notificationBlock

This Block is used to generate Notifications.

<figure><img src="/files/hiv8ESX9xWEaV2jXIrir" alt=""><figcaption></figcaption></figure>

## 1.1 Properties

| Property Name               | Description                                                                                           | Example                                                                      | Status |
| --------------------------- | ----------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ------ |
| Tag                         | Unique name for the logic block.                                                                      | notificationBlock                                                            |        |
| Permissions                 | Which entity has rights to interact at this part of the workflow.                                     | Standard Registry                                                            |        |
| Default Active              | Shows whether this block is active at this time and whether it needs to be shown.                     | Checked or Unchecked                                                         |        |
| Stop Propagation            | End processing here, don't pass control to the next block.                                            | Checked or Unchecked                                                         |        |
| On Errors                   | Called if the system error occurs in the Block                                                        | <p>- No action<br>- Retry</p>                                                |        |
| Title                       | .Notification title                                                                                   | Schema Creation                                                              |        |
| Type                        | type of notification                                                                                  | ERROR, SUCCESS, INFO, WARN                                                   |        |
| Message                     | Notification message                                                                                  | Schema is created                                                            |        |
| Link notification to policy | If checked : policy will be opened by clicking on notification                                        | Checked or Unchecked                                                         |        |
| User                        | If User == “ROLE”, users can setup appropriate role and also mark it as “Only for current user group” | ALL,CURRENT,POLICY\_OWNER,DOCUMENT\_OWNER,DOCUMENT\_ISSUER,GROUP\_OWNER,ROLE |        |


# Button Block Addon (buttonBlockAddon)

The purpose of this block is to display interactive buttons in documents source block (interfaceDocumentsSourceBlock).

## Usage

As shown in the example below, buttonBlockAddon blocks should be placed inside interfaceDocumentsSourceBlock blocks.

<figure><img src="/files/HNZzv3hR27RJ2j15iuC5" alt=""><figcaption></figcaption></figure>

## Properties

<table><thead><tr><th>Property Name</th><th>Description</th><th width="243">Example</th><th>Status</th></tr></thead><tbody><tr><td>Button Name (<em>name</em>)</td><td>The label (name) of the button as displayed to the user</td><td>"Approve", "Reject"</td><td></td></tr><tr><td>UI Class (<em>uiClass</em>)</td><td>The UI class of the button</td><td>“btn-approve”, “btn-reject”, “btn-link”</td><td></td></tr><tr><td>hideWhenDiscontinued</td><td>Check if the button should be hidden when policy is discontinued</td><td>Checked/Unchecked</td><td></td></tr><tr><td>Dialog (<em>dialog)</em></td><td>Determines if a dialog should be opened after the button is clicked</td><td>true, false.</td><td></td></tr><tr><td>Dialog Options (<em>dialogOptions</em>)</td><td>Will be shown only if the Dialog setting is set to true.</td><td><ol start="1"><li>Dialog Title (<em>dialogOptions.dialogTitle</em>): The title of the dialog. Example: “Rejection”.</li><li>Dialog Description (<em>dialogOptions.dialogDescription</em>): The description of the dialog. Example: “Enter reject reason”.</li><li>Dialog Result Field Path (<em>dialogOptions.dialogResultFieldPath</em>): The field which will contain the result value from the dialog. Example: “option.comment”.</li></ol></td><td></td></tr></tbody></table>

<figure><img src="/files/nuCjLgX6kGbybQWYngp5" alt=""><figcaption></figcaption></figure>

## Events

Button block addon events will be automatically added to document source.

<figure><img src="/files/3cgCsptFT96YyzihFCIN" alt=""><figcaption></figcaption></figure>

## API

The API for the buttonBlockAddon features both GET and POST methods:

1. Example response to the GET request:

```
{
    "id": "4e43f63f-f2e9-4336-a69e-931ec4aafaee",
    "blockType": "buttonBlockAddon",
    "dialog": true,
    "dialogOptions": {
        "dialogTitle": "Reject",
        "dialogDescription": "Enter reject reason",
        "dialogResultFieldPath": "option.comment"
    },
    "name": "Reject",
    "uiClass": "btn-reject",
}

```

The response to the GET request includes all block settings.

2. Example payload for the POST request:

```
{
  "documentId": "66b2838927c34db3c18e3c49",
  "dialogResult": "Typo in name"
}

```

Where

documentId - selected document identifier.

dialogResult is used for the dialog only.


# Dropdown Block Addon (dropdownBlockAddon)

The purpose of this block is to display an interactive dropdown menu in the interfaceDocumentsSourceBlock.

## Usage

As shown in the example below, dropdownBlockAddon blocks should be placed inside interfaceDocumentsSourceBlock blocks. Source addons, which return documents for the dropdown, should be placed inside dropdownBlockAddon.

<figure><img src="/files/PQ1hl29SgSXgMu561M9m" alt=""><figcaption></figcaption></figure>

## Properties

| Property Name                | Description                                                                   | Example                             | Status |
| ---------------------------- | ----------------------------------------------------------------------------- | ----------------------------------- | ------ |
| Option Name (*optionName*)   | The label (name) which is shown in dropdown items.                            | document.credentialSubject.0.field0 |        |
| Option Value (*optionValue*) | The value which will be used when a specific item is clicked.                 | document.credentialSubject.0.id     |        |
| Field (*field*)              | The field in selected document which will be populated with the option value. | assignedTo                          |        |

<figure><img src="/files/tht1AYv0Z5sZmqXUWXA3" alt=""><figcaption></figcaption></figure>

## Events

Dropdown block addon events will be automatically added to document source.

<figure><img src="/files/JtX6AQ11kqsUZuLK9KKa" alt=""><figcaption></figcaption></figure>

## API

The API for the dropdownBlockAddon has both GET and POST methods:

1. Example response to the GET request:

```
{
    "id": "47169fdc-900f-4e07-abb4-5510d7be1175",
    "blockType": "dropdownBlockAddon",
    "optionName": "document.credentialSubject.0.field0",
    "optionValue": "document.credentialSubject.0.id",
    "field": "assignedTo",
    "documents": [
        {
            "name": "example",
            "optionValue": "did:hedera:testnet:9XvzF671JeyoVRg8PvSZBTTyKyrvnZu2Mz7qE6FZXY8P_0.0.4481265",
            "value": "66b28683d029375c10f0f4ef"
        }
    ],
}

```

A response to the GET request includes all block settings and:

● documents - Dropdown options

2. Example payload for the POST request:

```
{
  "documentId": "66b28672d029375c10f0f4b6",
  "dropdownDocumentId": "66b28683d029375c10f0f4ef"
}
```

● documentId - Selected document

● dropdownDocumentId - Dropdown item which was clicked


# Request Vc Document Block Addon (requestVcDocumentBlockAddon)

The purpose of this block is to display an interactive button in the interfaceDocumentsSourceBlock.

## Usage

As shown in the example below, requestVcDocumentBlockAddon blocks should be placed inside interfaceDocumentsSourceBlock blocks.

<figure><img src="/files/65zWrbikuQzvI1MLH9yb" alt=""><figcaption></figcaption></figure>

## Properties

| Property Name                  | Description                                                      | Example                                                                                                                                      | Status |
| ------------------------------ | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ------ |
| Button Name (*buttonName*)     | The label (name) of the button as displayed to the user.         | Add report                                                                                                                                   |        |
| UI Class (*uiClass*)           | The UI class of the button.                                      | "btn-approve”, “btn-reject”, “btn-link                                                                                                       |        |
| hideWhenDiscontinued           | Check if the button should be hidden when policy is discontinued | Checked/Unchecked                                                                                                                            |        |
| Dialog Title (*dialogTitle*)   | The title of the dialog.                                         | Add report                                                                                                                                   |        |
| Schema (*schema*)              | Schema which will be used for document creation.                 | #de62118a-d746-4c9f-ba1a-2278b13a2137                                                                                                        |        |
| Id Type (*idTypev)*            | Type of identifier in document which will be created.            | “UUID”, “DID”, “OWNER”                                                                                                                       |        |
| Preset (*preset*)              | Will selected document be used as preset.                        | true, false                                                                                                                                  |        |
| Preset Schema (*presetSchema*) | Schema which will be used as a preset schema.                    | #de62118a-d746-4c9f-ba1a-2278b13a2137                                                                                                        |        |
| Preset Fields (*presetFields*) | Preset fields configuration.                                     | <p>\[</p><p>{</p><p>"name": "field0",</p><p>"title": "Project Details",</p><p>"value": "field0",</p><p>"readonly": false</p><p>}</p><p>]</p> |        |

<figure><img src="/files/AUhTtmtLNB1Hizacj3VW" alt=""><figcaption></figcaption></figure>

## Events

Request VC document block addon events will be automatically added to document source.

<figure><img src="/files/9zX7AOuSpjhOMy8wugYM" alt=""><figcaption></figcaption></figure>

## API

The API for the dropdownBlockAddon has both GET and POST methods:

1\. Example response to the GET request:

```
{
  "id": "20639b5d-c43d-4aa0-a1d1-d0ac36e867de",
  "blockType": "requestVcDocumentBlockAddon",
  "buttonName": "Add Report",
  "uiClass": "link",
  "dialogTitle": "Add Report",
  "presetFields": [
    {
      "name": "field0",
      "title": "Project Details",
      "value": "field0",
      "readonly": false
    },
	...
  ],
  "schema": {
    ...
  },
  "idType": "UUID",
  "preset": true,
  "presetSchema": "#de62118a-d746-4c9f-ba1a-2278b13a2137",
}

```

A response to the GET request includes all block settings and:

● schema - Schema document

2. Example payload for the POST request:

```

 	  "document": {
    "field0": "Device",
    "field1": "Organization",
    ...
  },
  "ref": "66ba0cad0edaef237a78b44b"
}

```

● document - Credential subject

● ref - Reference document identifier


# Data Transformation Addon

The purpose of this block is to produce a transformed result based on the data from the source

and filters blocks.

This block can be used in conjunction with pagination and filters for the

source block.

<figure><img src="/files/2pCeLNmBPEOaantuX6HN" alt=""><figcaption></figcaption></figure>

## Usage

As shown in the example below, dataTransformationAddon blocks should be placed after

documentsSourceAddon and filtersAddon blocks.

<figure><img src="/files/03rNvp3Xitz3Fz45YERO" alt=""><figcaption></figcaption></figure>

## Properties

| Property Name        | Description                                                                                                                            | Example                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
| -------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Expression           | <p>A custom JavaScript</p><p>function that transforms</p><p>the existing source data</p><p>and returns it in a</p><p>custom format</p> | <p><code>function main(documents){</code></p><p><code>let sum = 0;</code></p><p><code>for(let i=0; i< documents.length; i++) {</code></p><p><code>sum+=</code></p><p><code>documents\[i].document.credentialSubject\[0].fiel</code></p><p><code>d0 +</code></p><p><code>d1;</code></p><p><code>documents\[i].document.credentialSubject\[0].fiel</code></p><p><code>}</code></p><p><code>return {</code></p><p><code>sum</code></p><p><code>}</code></p><p><code>}</code></p><p><code>done(main(documents));</code></p> |
| hideWhenDiscontinued | Check if the button should be hidden when policy is discontinued                                                                       | Checked/Unchecked                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |

## API

The API for the dataTransformationAddon uses the GET method

Example response to a GET request that returns the sum of 2 fields in a custom format:

```
{
"sum": 10
}
```

The request can be fulfilled through both endpoint

*`/api/v1/policies/{policyId}/blocks/{blockId}`*

and

*`/api/v1/policies/{policyId}/tag/{blockTag}/blocks`*


# IntegrationButtonBlock

The purpose of this block is to enable interaction with third-party data providers through configurable parameters and caching mechanisms.

Below is a description of the available options and supported services:

## 1.1 Properties <a href="#id-1.1-properties" id="id-1.1-properties"></a>

<table><thead><tr><th>Property Name</th><th width="269.6015625">Description</th><th>Example</th></tr></thead><tbody><tr><td>Button name</td><td>The display name of the button</td><td>Integration Data</td></tr><tr><td>Enable caching</td><td>If set to true, and the data was previously saved to the database (e.g., via the "sendToGuardian" block), future requests with the same parameters will retrieve the data from the cache instead of performing a new request.</td><td>Checked/unchecked</td></tr><tr><td>Integration</td><td><p>Type of integration. Currently supported values:</p><ul><li>GLOBAL_FOREST_WATCH</li><li>KANOP_IO</li><li>WORLD_BANK</li><li>FIRM</li></ul></td><td>KANOP_IO</td></tr><tr><td>hideWhenDiscontinued</td><td>Check if the button should be hidden when policy is discontinued</td><td>Checked/Unchecked</td></tr><tr><td>Request type</td><td>The name of the specific request to execute (varies per integration).</td><td>getDatasets</td></tr><tr><td>Request params</td><td>Parameters required for the selected request. These are integration-specific.</td><td>datasets</td></tr></tbody></table>

<figure><img src="https://docs.hedera.com/guardian/~gitbook/image?url=https%3A%2F%2F1556785885-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FNYWPEEAknX9Vki1yV5HY%252Fuploads%252FIagZQVulGgAMVzRwvKGL%252Fimage.png%3Falt%3Dmedia%26token%3Dfeb0ba56-aa6c-4113-9c0e-982cd327b4d8&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=bcd756be&#x26;sv=2" alt=""><figcaption></figcaption></figure>

## 1.2 Output Events <a href="#id-1.2-output-events" id="id-1.2-output-events"></a>

This block can emits the following events:

* RunEvent
* ReleaseEvent
* RefreshEvent

<figure><img src="https://docs.hedera.com/guardian/~gitbook/image?url=https%3A%2F%2F1556785885-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FNYWPEEAknX9Vki1yV5HY%252Fuploads%252FShQR7hOiHrSkgf1lcBIK%252Fimage.png%3Falt%3Dmedia%26token%3Dd7902a14-392c-4bf4-a69b-d27842a90cad&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=b08eb688&#x26;sv=2" alt=""><figcaption></figcaption></figure>

To enable caching functionality, data must be saved to the database using the "sendToGuardian" block with the source set to auto or database. You can link the IntegrationButton to the "sendToGuardian" block using the RunEvent output event.

<figure><img src="https://docs.hedera.com/guardian/~gitbook/image?url=https%3A%2F%2F1556785885-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FNYWPEEAknX9Vki1yV5HY%252Fuploads%252FkAHcZs6ia2IQT1ndhREY%252Fimage.png%3Falt%3Dmedia%26token%3D4c90437a-c575-4389-b88f-1e580c2117af&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=dbaffe2c&#x26;sv=2" alt=""><figcaption></figcaption></figure>

## 1.3 Supported Integrations <a href="#id-1.3-supported-integrations" id="id-1.3-supported-integrations"></a>

This block supports four third-party data providers:

1\. [Global Forest Watch](https://data-api.globalforestwatch.org/)

2\. [Kanop](https://www.kanop.io/)

3\. [World Bank Governance Indicators](https://databank.worldbank.org/source/worldwide-governance-indicators)

4\. [NASA FIRMS](https://firms.modaps.eosdis.nasa.gov/)

<figure><img src="https://docs.hedera.com/guardian/~gitbook/image?url=https%3A%2F%2F1556785885-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FNYWPEEAknX9Vki1yV5HY%252Fuploads%252Feqoda6K0NQWTeRuixYF7%252Fimage.png%3Falt%3Dmedia%26token%3De32c1907-92a6-409c-866e-5ef54955d5a3&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=d5408100&#x26;sv=2" alt=""><figcaption></figcaption></figure>

## 1.4 Request UI Parameters <a href="#id-1.4-request-ui-parameters" id="id-1.4-request-ui-parameters"></a>

Each integration has a list of supported requests and associated parameters. For each request parameter, two input methods are available:

| Parameter          | Description                                                   |
| ------------------ | ------------------------------------------------------------- |
| Path field for ... | A Path input to extract data from an existing field.          |
| Value for ...      | A manual input for static values (e.g., known dataset names). |

{% hint style="info" %}
**Note: If both fields are filled, "Value for ..." takes precedence.**
{% endhint %}

<figure><img src="https://docs.hedera.com/guardian/~gitbook/image?url=https%3A%2F%2F1556785885-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FNYWPEEAknX9Vki1yV5HY%252Fuploads%252FhB05XVxFlflvB1Qi0UhN%252Fimage.png%3Falt%3Dmedia%26token%3De26ca44b-e9b5-42ec-b8bf-3adc5016a30f&#x26;width=768&#x26;dpr=4&#x26;quality=100&#x26;sign=58027a6c&#x26;sv=2" alt=""><figcaption></figcaption></figure>


# Global Events Writer Block

Publishes document references to one or more global Hedera topics.

* Publishes reference/metadata only (does not create, update, or re-anchor the document).
* Can publish to multiple global topics.
* Publishes each time the block is executed in the policy flow.
* Lets you control publishing per topic/stream in the Writer UI:
* Active ON/OFF — ON = publish, OFF = skip.
* Hidden (optional) — stays in configuration but is hidden in UI.
* Document Type — set per-topic type (vc/json/csv/text/any).

<figure><img src="/files/Od1nPyit60pax4Mkb2J6" alt=""><figcaption></figcaption></figure>

## 1.1 Properties

| Property Name                          | Description                                                                                               | Example           |
| -------------------------------------- | --------------------------------------------------------------------------------------------------------- | ----------------- |
| Default Active(in the block Meta Data) | controls the visibility in the runtime UI                                                                 | Checked/Unchecked |
| Show Next button                       | enable to use this block inside a Step container                                                          | Checked/Unchecked |
| Global topics                          | the list of default topicIds that Admin adds to the block configuration                                   | 0.0.7559767       |
| Active by default                      | controls the visibility                                                                                   | Checked/Unchecked |
| Document type                          | which documentType the Writer writes into the event message for this topic (VC / JSON / CSV / TEXT / ANY) | VC                |

<figure><img src="/files/3RR3fpPzO6a5iMmiIXNX" alt=""><figcaption></figcaption></figure>

## 1.2 API

* Uses the standard policy blocks API (setData), same as other blocks.
* Reader/Writer don’t introduce a new API — they only define their own payload format and supported operation values.

```
Writer payload (Update streams):
{
  "operation": "Update",
  "streams": [
    { "topicId": "0.0.45345345", "documentType": "vc", "active": true }
  ]
}
```


# Global Events Reader Block

Subscribes to global topics and routes incoming events into policy branches.

* Can subscribe to multiple global topics.
* Reads/handles messages only from topics with Active = ON (OFF = ignore this topic).
* Lets you control subscriptions per topic/stream in the Reader UI:
* Active ON/OFF — ON = read/process, OFF = ignore.
* Hidden (optional) — stays in configuration but is hidden in UI.
* Routes an event into a branch only if validations pass:
* Document type matches branch configuration.
* If configured, the schema matches / validates for that branch.
* If applicable, field filters match.
* Applies filters only for VC, and only when Admin configured a schema for the branch.

## 1.1 Properties

| Property Name                           | Description                                                             | Example                  |
| --------------------------------------- | ----------------------------------------------------------------------- | ------------------------ |
| Default Active (in the block Meta Data) | controls the visibility in the runtime UI                               | Checked/Unchecked        |
| Show Next button                        | enable to use this block inside a Step container.                       | Checked/Unchecked        |
| Global topics                           | the list of default topicIds that Admin adds to the block configuration | 0.0.750....              |
| Active by default                       | controls the visibility of topicID                                      | Checked/Unchecked        |
| Branch event                            | output event name to trigger                                            | branch 1                 |
| Document type                           | expected type for this branch (VC / JSON / CSV / TEXT / ANY)            | VC                       |
| Schema (optional)                       | local policy schema used for VC validation before routing.              | Registrant & Participant |

<figure><img src="/files/0JPqtB6366nrZUMKmHB5" alt=""><figcaption></figcaption></figure>

* Events tab - setting output events to the branches.

<figure><img src="/files/jWI3HGJ6f1ysAqHeBnjB" alt=""><figcaption></figcaption></figure>

## 1.2 API

* Uses the standard policy blocks API (setData), same as other blocks.
* Reader/Writer don’t introduce a new API — they only define their own payload format and supported operation values.

```
Reader payload (Update streams):
{
  "operation": "Update",
  "value": {
    "streams": [
      {
        "globalTopicId": "0.0.7559767",
        "active": true,
        "branchDocumentTypeByBranch": { "branch 1": "vc", "branch 2": "vc" },
        "filterFieldsByBranch": {}
      }
    ]
  }
}
```


# mathBlock

The *mathBlock* (also known as *formula calculation block or FCB*) lets you to define calculations on document data in mathematical notation to be performed directly, without the need or optionally with limited use of coding.

<figure><img src="/files/6wJxk5rtPyhx55WWgsIr" alt=""><figcaption></figcaption></figure>

## 1.1 Properties

|               |                                                                                             |                       |
| ------------- | ------------------------------------------------------------------------------------------- | --------------------- |
| Input Schema  | The input document schema.Required                                                          | Net\_ERR\_Calculation |
| Output Schema | The output (results) document schema. Optional. If not specified, the input schema is used. | Net\_ERR\_Calculation |
| Unsigned VC   | Allows the use of a simple JSON document as input (no VC-style proofs required)             | Checked/Unchecked     |
| Expression    | The set of formulas and commands executed at policy runtime.                                | formulas defined      |

## 1.1.1 Expression definition

Expression definition is guided by a wizard with in-place test execution, allowing policy authors to define formulas and the data they apply to at policy runtime. It includes the following sections:

#### 1. Inputs

Use this section to map fields from the input document to short variable names that you can reference in formulas.

<figure><img src="/files/afds8oxsWRHFcnnPIMwP" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/vLWDnZIQ760ISEJpsx7Q" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**Note 1**: A variable in a formula may reference data from any field in any document, not just the input document itself. However, the referenced document must be associated with the input document (i.e. be part of its 'relationships' chain). If no such relationship exists, the value cannot be resolved at runtime, which may lead to unpredictable or undefined behavior.
{% endhint %}

{% hint style="info" %}
**Note 2**: Source documents are located based on schema matching. If multiple related documents match the required schema, the system selects the nearest (most recent) document in the relationships chain as the data source.
{% endhint %}

### 2. Formulas

This section provides UI to defined formulas using standard mathematical notation and/or LateX or MathJSON formats.

<figure><img src="/files/OjrqaCnUyDIjpEDbre6M" alt=""><figcaption></figcaption></figure>

**2.1 Formula definition**

To define a formula, complete the following steps:

* Specify the formula name.
* Add () after the formula name and list any parameters inside. Separate parameters with a comma (,).

<figure><img src="/files/ZUWNd9tJluTAzrxvBBtI" alt=""><figcaption></figcaption></figure>

* Create the expression using math notation or an alternative format (LaTeX, MathJSON).

<figure><img src="/files/8gTvy73NxmqEcbgSZB9B" alt=""><figcaption></figcaption></figure>

In some cases, switching between math notation, LaTeX and MathJSON can help you verify or correct a formula. You can edit in any format; the system automatically synchronizes changes across formats.

<figure><img src="/files/6B6EwJcsRQX5A22MTmvZ" alt=""><figcaption></figcaption></figure>

You can reuse defined formulas in other formulas (by name) and in the code on the Advanced tab.

{% hint style="success" %}
**Note**: Not all commands supported in math notation are represented correctly in LaTeX. In LaTeX view, unsupported commands may appear as plain strings. For the complete list of commands supported by Guardian in math notation, see the MathLive Compute Engine standard library documentation: <https://mathlive.io/compute-engine/standard-library>
{% endhint %}

{% hint style="success" %}
**Note**: The single-letter names `i` and `e` are reserved by the Compute Engine. Single-letter names used as variable inputs (e.g. `A`, `R`) must appear **without** `\mathrm{}` wrapping in formulas — use bare `A`, `R` rather than `\mathrm{A}`, `\mathrm{R}`.
{% endhint %}

**2.2 Variables**

When parentheses are not included after the name (e.g., x vs. x()), it is treated as a variable definition. The variable value is calculated at initialization time.

<figure><img src="/files/VA7Y5JttLsBcSZhckfgM" alt=""><figcaption></figcaption></figure>

**2.3 Supported Compute Engine Functions**

Guardian formulas run on the MathLive Compute Engine. The following standard CE functions have been verified to work correctly in Guardian formulas.

**Array functions**

| Function | LaTeX                                                                | Description                                                                                                       |
| -------- | -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| `Map`    | `\mathrm{Map}\left(1..N,\ \mathrm{index} \mapsto \text{expr}\right)` | Applies an expression to each index from `1` to `N` and returns the resulting array.                              |
| `At`     | `\mathrm{At}\left(\mathrm{arr},\ \mathrm{index}\right)`              | Returns the element at 1-based position `index` from array `arr`. Used inside `Map` to access per-element values. |
| `Length` | `\mathrm{Length}\left(\mathrm{arr}\right)`                           | Returns the number of elements in array `arr`. Typically used as the upper bound in `Map` or `Sum`.               |
| `Sum`    | `\sum_{n=1}^{N} \text{expr}`                                         | Sums an expression over an index range.                                                                           |

**Math functions**

| Function | LaTeX                            | Description                        |
| -------- | -------------------------------- | ---------------------------------- |
| `Max`    | `\mathrm{Max}\left(a,\ b\right)` | Returns the larger of two values.  |
| `Min`    | `\mathrm{Min}\left(a,\ b\right)` | Returns the smaller of two values. |
| `Power`  | `base^{exp}`                     | Raises `base` to the power `exp`.  |

**Logic functions**

| Function | LaTeX                                         | Description                                                                                                                                                                                                                                          |
| -------- | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Boole`  | `\mathrm{Boole}\left(\text{condition}\right)` | Returns 1 if the condition is true, 0 otherwise. Use as a numeric multiplier to conditionally include a term. The condition can be written as an operator (At(qaVal, index) = 1) or as an explicit Equal call (Equal(At(arr1, n), At(arr2, index))). |
| `Equal`  | `a = b`                                       | Returns true if `a` equals `b`. Works correctly for numbers and for string elements retrieved from arrays via `At()`. For scalar string input fields use `EqualString` instead (see section 2.4).                                                    |
| `Not`    | `\mathrm{Not}\left(\text{condition}\right)`   | Negates a boolean condition.                                                                                                                                                                                                                         |

**Example — computing a value per instance:**

```latex
\mathrm{Map}\left(1..\mathrm{Length}\left(\mathrm{plantingCohort}\right),\ \mathrm{index} \mapsto
  \mathrm{At}\left(\mathrm{CWPwoodyABt},\ \mathrm{index}\right) \times \left(1 + \mathrm{At}\left(R,\ \mathrm{index}\right)\right)
\right)
```

**Example — summing array elements that match a condition:**

```latex
\sum_{n=1}^{\mathrm{Length}\left(\mathrm{qaVal}\right)} \mathrm{Boole}\left(\mathrm{At}\left(\mathrm{qaVal},\ n\right) = 1\right)
```

**Example — conditionally including a term based on a flag:**

```latex
\mathrm{Boole}\left(\mathrm{At}\left(\mathrm{eqIsArea},\ \mathrm{index}\right) = 1\right) \times \mathrm{At}\left(\mathrm{eqCWPt},\ \mathrm{index}\right)
```

{% hint style="warning" %}
**Known unsupported or unreliable functions**: `Reduce` with `Add` does not work reliably — use `\sum` instead. `IndexWhere` is not supported. `If` and `Which` as standalone return values produce empty results — replace conditionals with `Boole` multiplied terms instead (e.g. `Boole(cond) * val1 + Boole(Not(cond)) * val2`).
{% endhint %}

**2.4 Built-in Lookup Functions**

Guardian provides the following built-in functions for looking up values in arrays by key. These are particularly useful when working with per-instance data arrays (e.g. one row per instance).

| Function      | Signature                                   | Description                                                                                                                                                                                |
| ------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `Lookup`      | `Lookup(values, keys, id)`                  | Returns the value at the first position where `keys[i] == id`. Returns `0` if not found.                                                                                                   |
| `LookupTwo`   | `LookupTwo(values, keys1, id1, keys2, id2)` | Returns the value where both `keys1[i] == id1` and `keys2[i] == id2`. Useful for matching on two dimensions (e.g. instance + year). Returns `0` if not found or if array lengths differ.   |
| `LookupMin`   | `LookupMin(values, keys, id, sortKeys)`     | Among all rows where `keys[i] == id`, returns the value with the minimum `sortKeys[i]`. Useful for selecting the earliest year value. Returns `0` if not found.                            |
| `LookupMax`   | `LookupMax(values, keys, id, sortKeys)`     | Among all rows where `keys[i] == id`, returns the value with the maximum `sortKeys[i]`. Useful for selecting the most recent value when data has multiple years. Returns `0` if not found. |
| `EqualString` | `EqualString(a, b)`                         | Returns `1` if `a` and `b` are equal as strings, `0` otherwise. Use this instead of `Equal` when comparing string-typed input fields (e.g. `Yes`/`No`).                                    |

**Example usage in LaTeX:**

```latex
\mathrm{Lookup}\left(\mathrm{CWPwoodyABt},\ \mathrm{CWPwoodyABtId},\ \mathrm{At}\left(\mathrm{plantingCohort},\ \mathrm{index}\right)\right)
```

```latex
\mathrm{LookupMax}\left(\mathrm{mt},\ \mathrm{mtId},\ \mathrm{At}\left(\mathrm{plantingCohort},\ \mathrm{index}\right),\ \mathrm{mtYear}\right)
```

```latex
\mathrm{EqualString}\left(\mathrm{biomassBurningBoundary},\ \text{Yes}\right)
```

{% hint style="info" %}
**When to use `Lookup` vs `LookupMax`**: Use `Lookup` for parameters that have a single value per instance (no `year` field in the source data). Use `LookupMax` for monitored parameters that may have multiple yearly measurements — it selects the most recent one. Use `LookupMin` to select the earliest.
{% endhint %}

{% hint style="warning" %}
**Important — NaN propagation**: All lookup functions return `0` (not `NaN`) when no match is found. This is intentional: the Compute Engine evaluates all subexpressions immediately, so a `NaN` result from a lookup would propagate through any arithmetic that uses it (e.g. `NaN * 0 = NaN`), corrupting downstream calculations. Returning `0` ensures that expressions gated by a flag multiplied by `0` correctly produce `0` rather than `NaN`.
{% endhint %}

{% hint style="warning" %}
**String comparison**: The standard `Equal` operator works for numeric values and for string elements retrieved from arrays via `At()`. However, for scalar string input fields (e.g. `Yes`/`No`), use `EqualString` instead of `Equal`. `Equal` on a string scalar produces unexpected results because the Compute Engine stores scalar strings as symbols rather than string literals.
{% endhint %}

**2.5 Code (advanced)**

For complex scenarios where formulas are not sufficient for the required data transformations, use the Advanced (Optional) tab to add logic in JavaScript.

<figure><img src="/files/20YHBYTAXOUiiWKYnsIq" alt=""><figcaption></figcaption></figure>

In code, you can reference all defined formulas and variables by name.

<figure><img src="/files/X2hGwu62MhSOvriFqXHD" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/L2iRESl9mj5d0e2IRO7s" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/XPZFXVQzUzEHzG1o3EmB" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**Note — JavaScript execution order**: The JavaScript code section executes **after** all formula variables have been evaluated. This means JavaScript can read formula results but cannot influence formula evaluation. Use JavaScript for post-processing tasks such as filtering arrays by a condition, aggregating results across instances or writing values that depend on multiple formula outputs. Avoid duplicating mathematical logic in JavaScript that can be expressed in formulas.
{% endhint %}

### 3. Outputs

Use this section to configure which document fields receive the results of calculations from the previous sections.

<figure><img src="/files/kC9ZOrUua8z5kKzpZpZB" alt=""><figcaption></figcaption></figure>

In this section, you can reference input/output fields and variables only. Formulas can be referenced only in the Formulas section.

<figure><img src="/files/WrvBHcUDwVu5BAgG6pkr" alt=""><figcaption></figcaption></figure>

{% hint style="warning" %}
**Note — Output type constraint**: Only variables of type `variable` (not `function`) can be mapped to output fields. If a formula result needs to be written to an output, wrap it in an intermediate variable first.
{% endhint %}

### 4. Tabs

For convenience Inputs\Formulas\Outputs can be visually partitioned using tabs. This partitioning has not impact on the functionality of the policy, it is used to ease UI navigation by policy authors.

#### 4.1 Creation

<figure><img src="/files/jyRSqpjUO0QLwIpbbuOe" alt=""><figcaption></figcaption></figure>

#### 4.2 Renaming

Tabs can be renamed as required.

<figure><img src="/files/gmfAsqfJU2TjjrPdFQoM" alt=""><figcaption></figcaption></figure>

#### 4.3 Deletion

Tabs can be deleted.

<figure><img src="/files/VcdCNtBr7MKnWbDJfN0d" alt=""><figcaption></figcaption></figure>

#### 4.4 Navigation

<figure><img src="/files/4jqMmHGmdUSRYkwRbfLX" alt=""><figcaption></figcaption></figure>

### 5. Test

After you define formulas, you can validate them using the Test section. Complete the following steps:

#### a. Inputs

To begin testing, specify the main Input Document.

<figure><img src="/files/csrIL1JxK5dJMceiRZzn" alt=""><figcaption></figcaption></figure>

If required, add additional documents associated with the input document. Make sure these documents are part of the main Input Document's relationships chain.

<figure><img src="/files/UsH2PRBgqv2WLpRF4KV0" alt=""><figcaption></figcaption></figure>

Provide input data in a document using one of the following three options:

* Use a form that matches the input schema.

<figure><img src="/files/D4XHLFPlnkRrpTbJXqZB" alt=""><figcaption></figcaption></figure>

* Provide JSON.

<figure><img src="/files/fyuA0yQkrCyK3jOsOKDv" alt=""><figcaption></figcaption></figure>

* Upload a file (the file must contain valid JSON).

<figure><img src="/files/eDYvVLB7njXvHWmJ1xLs" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**Note — Test button scope**: The Test button executes formulas entirely within the frontend. It does not invoke the policy-service. This means test results reflect formula evaluation only.
{% endhint %}

#### b. Select Test

<figure><img src="/files/rvl8ImwBDToGZiLtTk38" alt=""><figcaption></figcaption></figure>

#### c. Results

Guardian displays test results for each element

<figure><img src="/files/ynaAgCnVLSbX0oKVPn0b" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/MvnwfVVwKyqwGM28FNhR" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/jOFjokBcB80YgicCT8Ne" alt=""><figcaption></figcaption></figure>

## 1.2 Visualization at Policy runtime

Once a policy is published, Guardian generates Formula-Linked Definitions (FLDs) for all mathBlock elements in the policy. You can explore these the same way as standard FLDs.

<figure><img src="/files/qkPraj9DwiQh1De2IPEG" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/Z06xKAyPrFXBK8NB6IZz" alt=""><figcaption></figcaption></figure>

{% hint style="warning" %}
**Note:** The *mathBlock* code section is not used when automatically generating FLDs and is not represented in any way in the resulting visuals.
{% endhint %}

## 1.3 Known Limitations

| Limitation                                                                                         | Workaround                                                                                                  |
| -------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Single-letter variable names (`A`, `R`, etc.) must not be wrapped in `\mathrm{}` in formula bodies | Use bare `A`, `R` in expressions; only multi-character names need `\mathrm{}`                               |
| `Equal` does not work reliably for scalar string fields (e.g. `Yes`/`No` flags)                    | Use `EqualString(field, "Yes")` instead                                                                     |
| The JavaScript code section runs **after** formula evaluation                                      | Do not rely on JavaScript to set values that formulas will consume; use JavaScript only for post-processing |
| Output fields can only reference `variable` type items, not `function` type                        | Wrap formula results in intermediate variables before mapping to outputs                                    |
| `Reduce` with `Add` does not work reliably for summing arrays                                      | Use `\sum_{n=1}^{N}` syntax instead                                                                         |
| `If` and `Which` as standalone return values produce empty results                                 | Split conditionals into `Boole`-multiplied terms (e.g. `Boole(cond) * val1 + Boole(Not(cond)) * val2`)      |


# API Execution Payloads

This guide documents how external systems interact with Guardian policy blocks through the REST API. It is the primary reference for integrators building MRV data pipelines, verification systems, or any application that submits data into a Guardian policy.

## Overview

A Guardian policy is a directed graph of blocks. External systems interact with blocks through three patterns:

| Pattern            | Method | URL                                            | When to use                                               |
| ------------------ | ------ | ---------------------------------------------- | --------------------------------------------------------- |
| Read block state   | GET    | `/api/v1/policies/{policyId}/blocks/{blockId}` | Get current form schema, document list, or block UI state |
| Submit data        | POST   | `/api/v1/policies/{policyId}/blocks/{blockId}` | Submit a form, trigger a button, select a role            |
| Push external data | POST   | `/api/v1/external/{policyId}/{blockTag}`       | Push MRV/oracle data without a Guardian user session      |

## Authentication

All block API calls require a JWT Bearer token from `POST /api/v1/accounts/login`.

```http
Authorization: Bearer <jwt_token>
```

The calling user must have been assigned the appropriate role within the policy.

***

## Standard Block Response Envelope

When calling `GET /policies/{policyId}/blocks/{blockId}`, Guardian returns a block-specific response. All responses share these common fields:

| Field      | Type    | Description                                                     |
| ---------- | ------- | --------------------------------------------------------------- |
| id         | string  | Block UUID                                                      |
| blockType  | string  | Block type identifier from `BlockType` enum                     |
| policyId   | string  | Owning policy ID                                                |
| readonly   | boolean | Whether the calling user can submit data to this block          |
| uiMetaData | object  | Block-specific display configuration (title, description, type) |

***

## Block Data Submission Response

When calling `POST /policies/{policyId}/blocks/{blockId}` or `POST /policies/{policyId}/tag/{tagName}/blocks`, Guardian acknowledges the submission synchronously and returns a response that includes a `trackingId` for correlating the request with the async completion event.

| Field      | Type   | Description                                                                                                                                                                                                      |
| ---------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| trackingId | string | UUID that uniquely identifies this block execution. Matches the `trackingId` in the `external-events.block_complete` event, allowing external systems to correlate requests with async outcomes without polling. |
| response   | object | Present when `history=true`. The direct output of `blockSetData`.                                                                                                                                                |
| result     | object | Present when `history=true`. The final result from the last downstream step.                                                                                                                                     |
| steps      | array  | Present when `history=true`. Ordered list of intermediate step results across the async execution chain. Empty array when `history` is not requested.                                                            |

**Example response (default):**

```json
{
  "trackingId": "550e8400-e29b-41d4-a716-446655440000"
}
```

**Example response with `history=true`:**

```json
{
  "trackingId": "550e8400-e29b-41d4-a716-446655440000",
  "response": { "...": "blockSetData output" },
  "result": { "...": "last step result" },
  "steps": [
    { "...": "step 1 result" },
    { "...": "step 2 result" }
  ]
}
```

> The submission response is returned as soon as the block accepts the data. The full async chain (IPFS uploads, HCS message submissions, downstream block execution) continues in the background and is reported via the `external-events.block_complete` event.

***

## Block-Specific Payloads

### `requestVcDocumentBlock`

Presents a data entry form based on a schema. The user fills the form and submits a VC document.

**GET response — block state:**

```json
{
  "id": "block-uuid",
  "blockType": "requestVcDocumentBlock",
  "uiMetaData": {
    "type": "page",
    "title": "Installer Registration",
    "description": "Fill in your facility details"
  },
  "schema": {
    "$id": "#installer-schema-uuid",
    "title": "Installer Application",
    "type": "object",
    "properties": {
      "field0": { "title": "Organization Name", "type": "string" },
      "field1": { "title": "Country", "type": "string" },
      "field2": { "title": "Facility Name", "type": "string" },
      "field3": { "title": "Installed Capacity (MW)", "type": "number" }
    },
    "required": ["field0", "field1", "field2"]
  },
  "presetSchema": null,
  "presetFields": []
}
```

**POST request — submit document:**

```json
{
  "document": {
    "credentialSubject": [
      {
        "type": "#installer-schema-uuid",
        "field0": "Acme Energy Corp",
        "field1": "Kenya",
        "field2": "Nairobi Solar Farm 1",
        "field3": 10.5
      }
    ]
  },
  "ref": null
}
```

| Field                      | Type   | Required | Description                                            |
| -------------------------- | ------ | -------- | ------------------------------------------------------ |
| document                   | object | Yes      | VC document to submit                                  |
| document.credentialSubject | array  | Yes      | Array with one object containing schema-defined fields |
| ref                        | string | No       | Parent document ID for relationship linking            |

***

### `uploadVcDocumentBlock`

Accepts file uploads or pre-built VC documents.

**POST request:**

```json
{
  "document": {
    "credentialSubject": [
      {
        "type": "#mrv-schema-uuid",
        "field0": 0.0,
        "field1": 1250.5,
        "field2": "MWh",
        "field3": "2025-01-01",
        "field4": "2025-12-31"
      }
    ]
  }
}
```

***

### `interfaceDocumentsSourceBlock`

Displays a list of documents to the user. Read-only; no POST required.

**GET response:**

```json
{
  "id": "block-uuid",
  "blockType": "interfaceDocumentsSourceBlock",
  "data": [
    {
      "id": "doc-id-123",
      "type": "VC",
      "owner": "did:hedera:testnet:...",
      "document": { ... },
      "option": { "status": "WAITING" },
      "createDate": "2026-03-31T08:00:00.000Z"
    }
  ],
  "fields": [
    { "title": "Status", "name": "option.status", "type": "text" },
    { "title": "Created", "name": "createDate", "type": "date" }
  ],
  "total": 1,
  "page": 0,
  "size": 10
}
```

***

### `buttonBlock`

Displays action buttons that trigger workflow transitions (e.g., Approve/Reject).

**GET response:**

```json
{
  "id": "block-uuid",
  "blockType": "buttonBlock",
  "uiMetaData": {
    "buttons": [
      {
        "tag": "approve_btn",
        "name": "Approve",
        "type": "selector",
        "field": "option.status",
        "value": "APPROVED",
        "uiClass": "btn-approve"
      },
      {
        "tag": "reject_btn",
        "name": "Reject",
        "type": "selector",
        "field": "option.status",
        "value": "REJECTED",
        "uiClass": "btn-reject"
      }
    ]
  }
}
```

**POST request — trigger a button:**

```json
{
  "document": {
    "id": "doc-id-123",
    "option": { "status": "WAITING" }
  },
  "tag": "approve_btn"
}
```

| Field    | Type   | Required | Description                                                          |
| -------- | ------ | -------- | -------------------------------------------------------------------- |
| document | object | Yes      | The document to act on (must include `id`)                           |
| tag      | string | Yes      | Button tag to trigger — must match one of `uiMetaData.buttons[].tag` |

***

### `policyRolesBlock`

Assigns a role to the current user within the policy.

**GET response:**

```json
{
  "id": "block-uuid",
  "blockType": "policyRolesBlock",
  "uiMetaData": { "title": "Select Your Role" },
  "roles": ["Installer", "Standard Registry", "Auditor"]
}
```

**POST request — select role:**

```json
{
  "role": "Installer"
}
```

| Field | Type   | Required | Description                                                             |
| ----- | ------ | -------- | ----------------------------------------------------------------------- |
| role  | string | Yes      | Role name — must be one of the values in the GET response `roles` array |

***

### `mintDocumentBlock`

Mints environmental asset tokens after document approval. This is a server-side block (`post: false`, `get: false`) — it is triggered automatically by the policy engine when an upstream block fires a `RunEvent`. There is no direct GET or POST available from the API.

The block calculates a token amount by evaluating the configured rule expression against the incoming VC documents, creates a mint VC and VP, publishes both to HCS, and calls the Hedera token service to mint the tokens to the target account.

To observe mint outcomes, query the `interfaceDocumentsSourceBlock` that follows the mint block in the policy flow — documents there will carry a `type` of `"MINT"` once minting completes.

***

### `retirementDocumentBlock`

Retires (wipes) tokens from a holder account. This is a server-side block (`post: false`, `get: false`) — it is triggered automatically by the policy engine when an upstream block fires a `RunEvent`. There is no direct GET or POST available from the API.

The block evaluates the configured rule expression (fungible tokens) or serial number expression (non-fungible tokens) against the incoming VC documents, creates a wipe VC and VP, publishes both to HCS, and calls the Hedera token wipe service.

***

### `createTokenBlock`

Presents a token configuration form that allows a user to define and create a new Hedera token within the policy's token template. The block can also be set to `autorun`, in which case it creates the token automatically without user interaction.

**GET response — token template:**

```json
{
  "id": "block-uuid",
  "blockType": "createTokenBlock",
  "title": "Create Token",
  "description": "Define the token parameters",
  "data": {
    "tokenName": "iREC Token",
    "tokenSymbol": "iREC",
    "tokenType": "fungible",
    "decimals": "2",
    "initialSupply": "0",
    "enableAdmin": true,
    "changeSupply": true,
    "enableFreeze": false,
    "enableKYC": false,
    "enableWipe": true,
    "wipeContractId": null
  }
}
```

Fields already locked by the policy template will be returned in `data` but cannot be overridden in the POST — submit only the fields the policy leaves editable.

**POST request — submit token configuration:**

```json
{
  "tokenName": "iREC Token",
  "tokenSymbol": "iREC",
  "tokenType": "fungible",
  "decimals": "2",
  "initialSupply": "0",
  "enableAdmin": true,
  "changeSupply": true,
  "enableFreeze": false,
  "enableKYC": false,
  "enableWipe": true,
  "wipeContractId": null
}
```

| Field          | Type           | Description                                        |
| -------------- | -------------- | -------------------------------------------------- |
| tokenName      | string         | Human-readable token name                          |
| tokenSymbol    | string         | Short token symbol (e.g. `"iREC"`)                 |
| tokenType      | string         | `"fungible"` or `"non-fungible"`                   |
| decimals       | string         | Decimal precision for fungible tokens (e.g. `"2"`) |
| initialSupply  | string         | Initial supply for fungible tokens (e.g. `"0"`)    |
| enableAdmin    | boolean        | Enables admin key on the token                     |
| changeSupply   | boolean        | Enables supply key (required for minting)          |
| enableFreeze   | boolean        | Enables freeze key                                 |
| enableKYC      | boolean        | Enables KYC key                                    |
| enableWipe     | boolean        | Enables wipe key (required for retirement)         |
| wipeContractId | string \| null | Optional Hedera contract ID to use as wipe key     |

On success the block publishes the new token to HCS, stores the resulting `tokenId` in the policy document's `tokens` map, and fires a `RunEvent` to the next block.

***

### `tokenConfirmationBlock`

Prompts the current user to associate (or dissociate) their Hedera account with a specific token, or to skip the step. This is required before a user can receive minted tokens.

**GET response:**

```json
{
  "id": "block-uuid",
  "blockType": "tokenConfirmationBlock",
  "action": "associate",
  "accountId": "0.0.1234567",
  "tokenName": "iREC Token",
  "tokenId": "0.0.9876543"
}
```

| Field     | Type   | Description                                                                        |
| --------- | ------ | ---------------------------------------------------------------------------------- |
| action    | string | `"associate"` or `"dissociate"` — the operation the user is being asked to confirm |
| accountId | string | The user's Hedera account ID that will be associated                               |
| tokenName | string | Display name of the token                                                          |
| tokenId   | string | Hedera token ID to associate                                                       |

**POST request — confirm association:**

```json
{
  "action": "confirm",
  "hederaAccountKey": "302e020100300506032b657004220420..."
}
```

**POST request — skip:**

```json
{
  "action": "skip"
}
```

| Field            | Type   | Required                          | Description                                                                                         |
| ---------------- | ------ | --------------------------------- | --------------------------------------------------------------------------------------------------- |
| action           | string | Yes                               | `"confirm"` to proceed with the association/dissociation, `"skip"` to bypass                        |
| hederaAccountKey | string | Only when `action` is `"confirm"` | The user's Hedera ED25519 private key (hex or DER-encoded) used to sign the association transaction |

> **Security note:** `hederaAccountKey` is transmitted over HTTPS and used in-process to sign the Hedera association transaction. It is not stored by Guardian.

***

### `externalDataBlock`

Receives data pushed from external systems. This is the block to target with `POST /external/{policyId}/{blockTag}`.

**GET response:**

```json
{
  "id": "block-uuid",
  "blockType": "externalDataBlock",
  "tag": "mrv_data_ingestion"
}
```

**External push via** `POST /api/v1/external/{policyId}/{blockTag}`:

```json
{
  "owner": "did:hedera:testnet:zHcDLGFNTnbmDMkaGEfb5zToJKj4KdwNPJ5mGFNjrEV",
  "policyTag": "iREC_V3_Installer",
  "document": {
    "@context": ["https://www.w3.org/2018/credentials/v1"],
    "type": ["VerifiableCredential"],
    "issuer": "did:hedera:testnet:...",
    "issuanceDate": "2026-03-31T00:00:00.000Z",
    "credentialSubject": [
      {
        "type": "#mrv-schema-uuid",
        "field0": 0.0,
        "field1": 1250.5,
        "field2": "MWh",
        "field3": "2025-01-01",
        "field4": "2025-12-31"
      }
    ]
  }
}
```

| Field                      | Type   | Required | Description                                                |
| -------------------------- | ------ | -------- | ---------------------------------------------------------- |
| owner                      | string | Yes      | DID of the document submitter                              |
| policyTag                  | string | Yes      | Policy tag string (from policy configuration)              |
| document                   | object | Yes      | Full or partial VC document                                |
| document.credentialSubject | array  | Yes      | Array containing one credential subject with schema fields |

***

### `reportBlock`

Generates a trust chain / audit trail view. Read-only.

**GET response:**

```json
{
  "id": "block-uuid",
  "blockType": "reportBlock",
  "uiMetaData": { "title": "Trust Chain Report" },
  "items": [
    {
      "title": "Registration Document",
      "document": { ... },
      "type": "VC",
      "tag": "installer_registration",
      "issuer": "did:hedera:testnet:..."
    },
    {
      "title": "MRV Report",
      "document": { ... },
      "type": "VC",
      "tag": "mrv_submission"
    },
    {
      "title": "Minted Token",
      "tokenId": "0.0.1234567",
      "amount": 1250,
      "type": "TOKEN"
    }
  ]
}
```

***

### `switchBlock`

Routes documents to different workflow paths based on conditions. Evaluated automatically by the policy engine — no external interaction required.

***

### `aggregateDocumentBlock`

Collects multiple documents until a threshold is met, then batches them. Evaluated automatically.

***

### `calculateContainerBlock` / `mathBlock`

Performs arithmetic on document fields. Evaluated automatically.

***

### `sendToGuardianBlock`

Sends a document to the Hedera blockchain (IPFS + HCS). Evaluated automatically after form submission or approval.

***

## External Data Submission API Reference

### POST /api/v1/external/{policyId}/{blockTag}

The primary integration endpoint for external MRV systems, IoT sensors, and oracles.

**Authentication:** Not required for `externalDataBlock` configured as public. JWT required otherwise.

**Path Parameters:**

| Parameter | Type   | Required | Description                                      |
| --------- | ------ | -------- | ------------------------------------------------ |
| policyId  | string | Yes      | Policy MongoDB ID or published policy message ID |
| blockTag  | string | Yes      | Unique tag of the target `externalDataBlock`     |

**Full Request Body Schema:**

```json
{
  "owner": "string — DID of document owner (required)",
  "policyTag": "string — policy tag identifier (required)",
  "document": {
    "@context": ["array of JSON-LD context URLs"],
    "type": ["VerifiableCredential"],
    "issuer": "string — DID of issuer",
    "issuanceDate": "string — ISO 8601 date",
    "credentialSubject": [
      {
        "type": "string — schema type IRI",
        "field0": "value matching schema field type",
        "field1": "...",
        "fieldN": "..."
      }
    ],
    "proof": {
      "type": "string",
      "created": "string",
      "verificationMethod": "string",
      "proofPurpose": "string",
      "jws": "string"
    }
  }
}
```

The `proof` field is optional — Guardian will sign the document if not provided.

**Response 200 OK:**

```json
true
```

**Error Codes:**

| Code | Description                                      |
| ---- | ------------------------------------------------ |
| 400  | Missing required fields                          |
| 404  | Policy or block tag not found                    |
| 422  | Document validation failed against policy schema |
| 500  | Internal server error                            |

***

## Tag-Based Block Access

Blocks can also be accessed by tag name instead of UUID:

```
GET  /api/v1/policies/{policyId}/tag/{tagName}/blocks
POST /api/v1/policies/{policyId}/tag/{tagName}/blocks
```

This is useful when block UUIDs change between policy versions but tags remain stable.

***

## Complete Integration Workflow

### Step 1 — Authenticate

```http
POST /api/v1/accounts/login
Content-Type: application/json

{ "username": "mrv_provider", "password": "securepassword" }
```

```json
{ "accessToken": "eyJhbGciOiJSUzI1NiJ9...", "did": "did:hedera:testnet:..." }
```

### Step 2 — Find Published Policy

```http
GET /api/v1/policies?pageIndex=0&pageSize=10
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...
```

Locate the policy by `name` or `policyTag` in the response. Note its `id`.

### Step 3 — Navigate to Roles Block

```http
GET /api/v1/policies/{policyId}/navigation
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...
```

Find the `policyRolesBlock` in the block tree. Note its `id`.

### Step 4 — Select Role

```http
POST /api/v1/policies/{policyId}/blocks/{rolesBlockId}
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...
Content-Type: application/json

{ "role": "MRV Submitter" }
```

### Step 5 — Get Submission Form Schema

```http
GET /api/v1/policies/{policyId}/blocks/{formBlockId}
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...
```

Extract the `schema.properties` to determine which fields to populate.

### Step 6 — Submit Document

```http
POST /api/v1/policies/{policyId}/blocks/{formBlockId}
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...
Content-Type: application/json

{
  "document": {
    "credentialSubject": [
      {
        "type": "#schema-uuid",
        "field0": 0.0,
        "field1": 1250.5,
        "field2": "MWh"
      }
    ]
  }
}
```

The response includes a `trackingId` to correlate this submission with its async completion event:

```json
{
  "trackingId": "550e8400-e29b-41d4-a716-446655440000"
}
```

### Step 7 — Track Async Completion

Guardian processes block submissions asynchronously. IPFS uploads, HCS message submissions, and downstream blocks all run after the POST returns. There are two ways to observe completion:

**Option A — Subscribe to `external-events.block_complete` (recommended)**

Configure a webhook or SSE listener for the `external-events.block_complete` event. When the full async chain settles, Guardian emits:

```json
{
  "trackingId": "550e8400-e29b-41d4-a716-446655440000",
  "blockType": "requestVcDocumentBlock",
  "blockTag": "mrv_submission",
  "blockId": "3f2504e0-4f89-11d3-9a0c-0305e82c3301",
  "policyId": "6475a9e0-5f27-4ce3-b2f1-123456789abc",
  "userId": "did:hedera:testnet:z6MkHmF...",
  "status": "success",
  "timestamp": 1745123456789
}
```

Match the event's `trackingId` to the value returned in Step 6 to confirm your submission completed. When `status` is `"failure"`, the `error` and `errorDetails` fields contain diagnostics.

| Event field  | Type   | Description                                                                                           |
| ------------ | ------ | ----------------------------------------------------------------------------------------------------- |
| trackingId   | string | Matches the value returned by the POST response in Step 6                                             |
| blockType    | string | Block type that processed the submission                                                              |
| blockTag     | string | Block tag identifier                                                                                  |
| blockId      | string | Block UUID                                                                                            |
| policyId     | string | Policy ID                                                                                             |
| userId       | string | DID of the submitting user                                                                            |
| status       | string | `"success"` or `"failure"`                                                                            |
| outputData   | object | Optional. Direct output from `blockSetData` when available                                            |
| error        | string | Optional. Human-readable description of the first error (when `status` is `"failure"`)                |
| errorDetails | array  | Optional. All errors collected across the async chain — each entry has `message` and optional `stack` |
| timestamp    | number | Unix millisecond timestamp when completion was determined                                             |

**Option B — Poll document status**

```http
GET /api/v1/policies/{policyId}/blocks/{viewerBlockId}
Authorization: Bearer eyJhbGciOiJSUzI1NiJ9...
```

Poll until `data[0].option.status` changes to `APPROVED` or `REJECTED`. Use this when you cannot configure an event listener.


# Creating a Policy Reference

Once you login as a Standard Registry and finish the setup, click on Policies tab.

![](/files/u0AuIzldK3koai5Zcodn)

We have two options to create Policy :

1. Creating Policy from scratch
2. Importing Policy (zip file format)either from file or from IPFS.

### 1. Creating Policy from Scratch

1.1 To create Policy from scratch, we need to click on "Create Policy" button.

![](/files/G9tL6KvNJfj72peovv0Q)

1.2 Once you click on Create Policy , you get a dialog box to fill out basic Policy details.

![](/files/eizVtnpOmXhwGqHvjmy9)

1.3 Once the details are filled and clicked on OK. Initially, Policy is created in Draft status.

![](/files/exKKouXzrsJTXh5WflNX)

1.4 You can even edit the Policy by clicking Edit button.

![](/files/2TVWGCM0ClZJxDVHUA7W)

1.5 When clicked on Edit, the screen is navigated to Policies configuration tab, which gives an option to add/remove any block from the Policy.

![](/files/VdsPph5qkyN3e9Uwa7mx)

1.6 Once the Policy is configured, you can go to Policies tab and click on Publish.

![](/files/ndds00M5ksSNpl3loC75)

### 2. Importing Policy either from File or from IPFS

Instead of creating Policy from scratch, there is an option of importing the Policy zip file from Local system.

{% hint style="info" %}
**Note:** Files with **.policy** extension are only accepted. These files are in zip format, i.e. they are zip archives of the text file.
{% endhint %}

![](/files/Z7kbQzuL6SupljAFPz2D)

2.1 Once the .zip file is selected, we get the Policy Import Review screen. Once everything looks good, click on Import Button.

![](/files/WvypiOuiYc77CkNQ9DkN)

2.2 The Policy can also be imported by importing it from IPFS.

![](/files/8IzN9miihVOvLmEF80ad)

2.3 To do this, you can use the sample policy that we have already uploaded to IPFS by entering the Hedera Message IDs.

```
1655293847.166673000 (new iREC Policy)
```

![](/files/NBvxXDhlB1o5IHfVqpks)

2.4 If the timestamp entered is correct, we get Policy Import Preview screen. If the imported Policy looks good, click on **Import** button.

![](/files/eg2kLwNAdGlS3YrSYiA2)

2.5 Once the Policy is imported, if everything looks good, click on Publish button. Policy will be published and it is represented by changing the status as Published.

![](/files/7cJxnw5MmxT88tywJ6Y8)

2.6 There is also an option to Export the Policy. To export the policy click on Export button. Once, you click on Export, you get Export dialog, where we have two exporting options: Copy message Identifier and saving the Policy as file.

![](/files/CUs66CicnoRQcfE2wNAR)

When you click on Save to file, Policy is exported as a .zip file.

**Note:** While importing tool via file, or policy via file or IPFS, you can change used tools in preview dialog, it will change tools references in schemas and config automatically.

To get complete information about tools, please refer to [Tools](https://github.com/hashgraph/guardian/blob/develop/Methodology%20Library/CDM/Tools/README.md) section.

<figure><img src="/files/15obJ5vCJzPgHqyiFR83" alt=""><figcaption></figcaption></figure>

### 3. Filtering Policies

On the Policy page, it is now possible to filter the policies list by policy name and tags. All available tags are presented in the dropdown list, which you can create using "Create Tag" for each policy, which makes it easier using the filter.

### 4. Select and Delete Multiple Policies

Users can select and delete policies from the Policies table in Guardian UI and also through the API.

<figure><img src="/files/d76NnNjhpsAKKNV6yXLW" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Note:

1. Selected items remain selection across pagination.
2. Dependencies are considered when deleting multiple schemas.
   {% endhint %}

### 5. Policy Disconnection

#### 5.1 Disconnecting from a Local Policy

<figure><img src="/files/CMEQisE97hs9XDNZNJ4U" alt=""><figcaption></figcaption></figure>

After disconnection:

* The policy is removed from your active policies grid and moved to the Disconnected Policies section

<figure><img src="/files/tEfXW2nLS73gPcz2omOD" alt=""><figcaption></figcaption></figure>

* All documents created by you within that policy are marked accordingly to inform other policy participants that you have disconnected.

<figure><img src="/files/OeKSEVwReAlQo7p70MAr" alt=""><figcaption></figcaption></figure>

The disconnection operation is reversible. If necessary (for example, in case of accidental disconnection), you can reconnect to the policy at any time.

<figure><img src="/files/GY2YLQZtQuM66kFP6GCR" alt=""><figcaption></figcaption></figure>


# Creating Policy Navigation (Stepper)

There is tab menu in right side in the policy configurator called "Navigation", which helps to configure the stepper in the policies.

<figure><img src="/files/EZOMT82K6YlIr5Jx7yjy" alt=""><figcaption></figcaption></figure>

There are all the roles for which you can create navigation:

<figure><img src="/files/I2rpnmQF8ySCJTbtefhe" alt=""><figcaption></figcaption></figure>

You can also add steps and change step name and must select block (to be able to navigate through the navigation the block must be of the container type "interfaceContainerBlock")

<figure><img src="/files/nGfDn7afn5tLPJYCrQ1K" alt=""><figcaption></figcaption></figure>

Level in the above screenshot means sub-items of the menu

For example:

<figure><img src="/files/hwNbmxyzpUly5KccFZ7s" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/44bMhDB0LdlwyD3hqarf" alt=""><figcaption></figcaption></figure>


# Policy Versioning and Deprecation

Policy versioning in Guardian allows a methodology or workflow to evolve over time without breaking existing projects. Each policy can have multiple versions, ensuring traceability, flexibility, and regulatory compliance.

**Key Points:**

* New versions are created when standards bodies, registries, or auditors update rules, schemas, or workflows.
* Old versions remain intact so existing projects continue without disruption.
* Each version has a unique identifier (e.g., VM0042 v1.0, VM0042 v2.1).
* Backward compatibility is maintained via data migration tools.

Deprecation means a policy version is officially discontinued and cannot be used for new projects, though historical data is preserved for auditability.

**Key Points:**

* A deprecated policy cannot onboard new users or issue new credentials.
* Existing projects under that policy may either:
  * Continue under old rules (frozen state), or
  * Migrate to a newer version using Guardian’s Migration Wizard.
* Deprecation ensures stakeholders are aligned with up-to-date methodologies.


# Policy Versioning & Deprecation

This protocol comes into effect beginning with Guardian 1.3.0

Guardian Policy documents capture policy workflows – a combination of policy actions, information flows and rules under which the run-time sequence of steps is constructed and executed. The content of Guardian Policies is determined by the specific sustainability use-case they are designed to address. As such there three main driving forces for the changes in the area of policy definition and management:

* The evolution of the sustainability industry use-case targeted by the policy in questions.
* Introduction of new use-cases and corresponding policies.
* The evolution of Guardian Policy Engine technology, where new capabilities are added existing modified or removed.

These forces result in the following events:

* New versions of policies created periodically with arbitrary modifications to the workflow, user roles and information requirements.
* New elements (blocks) added to the policy definition language, and/or existing augmented or removed.

To avoid breaking existing users, Guardian Policies follow a versioning and deprecation protocol for aspects of the Policies that are targeted to be modified or removed.

### Policy Versioning

The Guardian Policies are versioned using semantic versioning in the major.minor.micro format. Each number incremented sequentially to denote the following changes:

* major: the Policy version contains breaking changes.
* minor: the Policy version contains notable new capabilities and non-breaking changes.
* micro: the Policy release contains non-breaking changes only.

Guardian system does not generate versions automatically, it is the responsibility of the Policy authors (Standard Registry) to keep track of its policies/versions and correctly reflect changes in the version number.

Wherever possible and relevant, Guardian Policy version header contains a reference to the original (paper) document version from the guiding which this policy represents.

### Version Compatibility

Guardian Policy authors should take care to ensure that policy workflow blocks, their sequence, properties and parameters are preserved to be backward compatible with earlier versions. A new Policy element should be added to the policy if/when it is necessary to make a non-backward compatible change. Policy workflow sequence or existing elements should be removed/changed in accordance with the Policy deprecation policy.

### Non - Breaking changes

The non-breaking changes to the Policy which do not warrant the change in the major version number are changes in:

* Descriptive UI properties of the block, such as Title, Description, Field Name.
* Default state of the element.
* Permissions (which actor/entity has rights to interact at this part of the workflow).
* Error handling sequence, messages and actions.

### Breaking changes

* Removing or renaming a block, changing any of its non-descriptive properties.
* Changing used schema version to a new one with breaking changes.
* Changing workflow sequence, dependencies or bind block.
* Introducing new, or changing existing external data source.

### Policy Version Deprecation

Deprecation notice is used to inform the API users that a specific Policy version is now considered obsolete and thus no longer advised for the use in applications. The notice is issued at least 2 months before the end-of-life date, or for the duration or by a deadline mandated by the governing regulation/policy.

The notice is issued via a notice message in the corresponding Hedera Topic, and via the Release Notes where the end-of-life date is also specified. On the date of the version expiry, a VC revocation notice is issued into the Hedera Topic.

A Policy may be discontinued without prior warning if the existing behavior if incorrect or to patch a security vulnerability.

### Policy Definition language (PDL)

For the purposes of backwards compatibility Guardian differentiates between existing policies and the creation of new policies and implements separate rules accordingly.

Guardian Policy documents feature two independent version numbers, one describing the version, in other words ‘iteration’, of the policy itself (as described in the section above), and the other one describing the version of the PDL that this version of the policy is expressed in. Like the former, the latter uses semantic versioning in the major.minor.micro format. Each number incremented sequentially, the difference in numbers between two documents denote the following differences:

* major: PDL in documents contains breaking changes, manual conversion on import is required.
* minor: PDL in the newer document contains notable new capabilities and non-breaking changes, the policy will be converted into the new format on import automatically.
* micro: the PDL versions contains non-breaking changes only.

Guardian generates PDL versions for Policy document automatically. Each new release of Guardian may or may not bring a new PDL version. However, new PDL versions can only be introduced as part of the new release of Guardian.

### Existing Policies

Due to long-term nature of some sustainability projects Policy Engine (PE) maintains unlimited ‘read’ backward compatibility with 'old’ policy definition language elements. In other words, new PE versions will recognize and be able to process all existing valid policies defined starting from the beginning of Guardian existence.

This does not guarantee that all policy elements will be processed in the same way as they previously were, nor displayed in the UI or accessed via APIs in the same way. New versions of Guardian would always recognize blocks/elements correctly, maintain the original policy workflow and meaning of the blocks and elements.

A Policy element may become unsupported (ignored for processing triggering a warning) without prior warning if the existing behavior if incorrect or to patch a security vulnerability.

### New Policies

Each new version of Guardian may introduce changes to the policy language definition without prior notice. All changes will be reflected in the documentation for the release.

Furthermore, the use of ‘obsolete’ elements may become prohibited in the new versions/policies created by the release. To clarify, on such occasions any ‘old’ versions or policies would continue be supported in-use (in already established and/or new projects). However, any new policies, including when created by copying the ‘old’ valid policy, containing the obsolete elements would not be accepted for ‘publishing’. The authors would be required to remove/replace the ‘obsolete’ blocks with new ones to create an acceptable policy definition.


# Editing Policy Parameters at Runtime

How to edit policy parameters at runtime without having to republish a policy?

## Editing policy parameters at runtime

This feature lets you modify policy parameters after the policy has been published. First, define which parameters can be edited. To do that, use the new button in the Policy Configurator.

<figure><img src="/files/cVr7CHjLCStWvbcVmweH" alt=""><figcaption></figcaption></figure>

Clicking this button opens a new dialog with dynamic property groups. You can add any number of properties. Each property includes the following fields: **Block**, **Property**, **Visible**, **Apply for**, **Label**, and **Description**.

<figure><img src="/files/e4IYqlyHZNV89GLXWzMq" alt=""><figcaption></figcaption></figure>

The **Blocks** dropdown contains only blocks from the current policy that have at least one editable property. The **Visible** field determines who can modify the property. **Apply for** specifies the roles that receive the change. **Label** and **Short Description** appear in the runtime form for editing policy parameters.

After you configure the policy parameters and publish the policy, a new **Parameter Settings** button appears on the policy.

<figure><img src="/files/iHMIYlhOpTYgOUgy9rKy" alt=""><figcaption></figcaption></figure>

These settings include the parameters configured in the Policy Configurator. Values for editable parameters are stored in a new database table: `policy_parameters`.

<figure><img src="/files/akxA7n2GtXIKUDRHHFHO" alt=""><figcaption></figcaption></figure>

If some parameters are marked as required, this form opens automatically when the user opens the policy.

<figure><img src="/files/2YIezXZrKJ8nErQixhuA" alt=""><figcaption></figcaption></figure>

In this example, the **Information** block can be modified. Before the changes are applied, the text configured in the corresponding property is displayed.

<figure><img src="/files/yruzUDUCB94CMXMp2mKY" alt=""><figcaption></figcaption></figure>

After you add new text to this property, it appears on the page.

<figure><img src="/files/CzWvdR7Gw4pprHmjM85t" alt=""><figcaption></figcaption></figure>

## Endpoints for this feature

1. Retrieve the policy parameter configuration.

```
GET 
/:policyId/parameters/config
```

2. Save policy parameters.

```
POST 
/:policyId/parameters 
[{ 
  blockType: string; 
  blockTag: string; 
  propertyPath: string; 
  visible: string[]; 
  applyTo: string[]; 
  label: string; 
  required: boolean; 
  shortDescription: string; 
  value?: any; 
}]
```

## Related Issues

* [https://github.com/hashgraph/guardian/issues/5539](https://github.com/hashgraph/guardian/issues/1987)


# Dry Run & Policy Integrity Tests

Dry Run mode refers to a feature that allows users to simulate the execution of policies or workflows without actually applying any changes or triggering actions in the live environment. It enables users to test and evaluate the behavior and outcomes of policies or workflows in a controlled manner before implementing them in a production environment.

This offers a safe and controlled environment for testing, validation, and optimization of policies or workflows. It enables users to assess the behavior and outcomes of policies without affecting live data or systems. By utilizing the dry run mode, users can enhance the reliability, accuracy, and performance of policies or workflows within the Guardian system.


# Dry Run Mode Reference

1. [Step By Step Process](#id-1.-step-by-step-process)
2. [Demo Video](#id-2.-demo-video)

## 1. Step By Step Process

In this mode of operation all artifacts (files, documents and transactions) that are produced in the course of execution of the policy are stored in the local database but not sent out to Hedera or IPFS. The artifacts are stored in the database in a separate table specific for the ‘dry run’ mode. This also allows the trial for executing the workflow without real accounts.

### 1. Starting Dry Run Mode

There are different ways to start the Dry Run Mode after importing Policy.

#### 1.1 From the Policies Page

When the Policy is imported, its in Draft status by default. This status can be seen in the Status/Actions column. To change the Draft status to Dry Run status, click on the drop down arrow and select **Dry Run** option.

![](/files/HafWQqsa9eufLTAEpcOO)

![](/files/iV9UhZ547NqbQSnNXkw1)

#### 1.2 From Policy Configurator Page:

When imported Policy is opened for editing, there's an option of changing the Policy status from Draft to Dry Run. The Dry Run option can be selected by clicking on drop down arrow and selecting **Dry Run** option as shown below:

![](/files/9FxhewDA23rK9CEIWAS2)

#### 1.3 By calling the API

Dry Run mode can be started by calling the following API:

```
PUT: /api/v1/policies/{policyId}/dry-run
```

To get complete information on the above API, please check : [Running Policy without making any changes](/developer-tools-and-resources/api-reference/dry-run-mode-using-apis/running-policy-without-making-any-changes#dry-run-policy)

### 2. Exit Dry Run and return to Draft status

There are different ways to exit from Dry Run to Draft mode.

#### 2.1 From the Policies Page

Policy, which are in the Dry Run status, can be changed to Draft/Publish state by selecting respective option from the drop down arrow. To change the Policy status to Draft, please select **Stop** option and to change the Policy status to Publish, please select **Publish** option.

![](/files/6XPEa0fbzW2zL1frjXzd)

#### 2.2 From the Policy Configurator Page

Policy status can be changed from Dry Run to Draft/Publish by selecting from the drop down option in Policy Configurator Page.

![](/files/SjcBQ94sHLb3Fe7LjDyi)

#### 2.3 By calling the API

Dry Run mode can be exited to Draft status by calling following API:

```
PUT: /api/v1/policies/{policyId}/draft
```

To get complete information on the above API, please check : [Returning Policy to Editing](/developer-tools-and-resources/api-reference/dry-run-mode-using-apis/returning-policy-to-editing#return-policy-to-editing)

### 3. Opening of a running Policy in Dry Run mode

There are two ways to open the Policy in Dry Run mode:

#### 3.1 From the Policies Page

To open the Policy in Dry Run mode, click on a **Go** button in the Operation column.

![](/files/uXLWRAGcp9B85xnSTmaE)

#### 3.2 From the Policy Configurator Page

There's a **Go** option in Policy Configurator page to view the Policy in Dry Run mode.

![](/files/2ZGVbmgz64BY9RvwxyKW)

### 4. Policy Instance

#### 4.1 View Config

This option is used to navigate back to the Policy Configurator page to edit the Policy in Dry Run mode.

![](/files/AVPn8MKR4YSAJB5j1Ufb)

#### 4.2 Restart

Restart is used to reset the state of the Policy by removing all the records for the previous ‘Dry Run’ of the Policy. It can be performed by different ways:

#### 4.2.1 From Policy View Page

By clicking on **Restart** button, which is located beside View Config.

![](/files/o7fXCa7cz2vGIz0Bvv5W)

#### 4.2.2 By calling the API

Restart can also be performed by calling the following API:

```
POST: /api/v1/policies/{policyId}/dry-run/restart
```

To get complete information on above API, please check :[Restarting the execution of Policy](/developer-tools-and-resources/api-reference/dry-run-mode-using-apis/restarting-the-execution-of-policy#restarts-the-execution-of-the-policy)

#### 4.3 Create User

The system provides a facility for the creation of ‘virtual’ users to enable the ‘Dry Run’ execution flow.

#### 4.3.1 From the Policy View Page

Virtual User can be created by clicking on **Create User** button as shown below:

![](/files/6NKinKkhaqq9qfdKIOZ7)

#### 4.3.2 By calling an API

Virtual User for Dry Run can also be created by calling following API:

```
POST: /api/v1/policies/{policyId}/dry-run/user
```

To get complete information on the above API, please check : [Creating Virtual Account](/developer-tools-and-resources/api-reference/dry-run-mode-using-apis/creating-virtual-account#create-a-new-virtual-account)

#### 4.4 Users

Allows to switch between virtual accounts of users. For a single policy in the ‘Dry Run’ mode a Standard Registry can be operating as a single (virtual) user at any point in time. This is enforced on the server.

Virtual user can be selected in multiple ways:

#### 4.4.1 From the Policy View Page

Virtual user can be selected by clicking on respective users in the drop down list as shown below:

![](/files/n9iOwQW56p8nXmm2cUqq)

#### 4.4.2 By calling the API

Virtual user also can be selected by calling the following API:

```
POST: /api/v1/policies/{policyId}/dry-run/login
```

To get complete information on above API, please check : [Logging Virtual User](/developer-tools-and-resources/api-reference/dry-run-mode-using-apis/logging-virtual-user#logs-virtual-user-into-the-system)

#### 4.5 Policy View

This option is used to view complete Policy with its tabs in it.

![](/files/wffMRE5DpEOaTRBHJ7Hq)

#### 4.6 Transactions

This tab shows the list of mock transactions performed as part of the execution of the policy. These transactions do not actually get executed, they will be performed when the policy runs in the production mode. These transaction records only exist in the local database.

These transactions can be viewed in different ways:

#### 4.6.1 From the Policy View Page

All the transactions can be viewed by clicking on **Transactions** tab as shown below:

![](/files/D8qJ2pzLcV3Usn0KGpQE)

#### 4.6.2 By calling an API

Transactions can also be viewed by calling the following API:

```
GET: /api/v1/policies/{policyId}/dry-run/transactions?pageIndex=0&pageSize=100
```

To get more information on the above API, please check:[Returns List of Transactions](/developer-tools-and-resources/api-reference/dry-run-mode-using-apis/returns-list-of-transactions#returns-lists-of-virtual-transactions)

#### 4.7 Artifacts

This tab contains the list of documents created during the execution of the Policy.

These Artifacts can be viewed in different ways:

#### 4.7.1 From Policy View Page

All the Artifacts can be viewed by clicking on **Artifacts** option as shown below:

![](/files/f0rDYYKoFvafeBE3H725)

#### 4.7.2 By calling an API

We can also view Artifacts list by calling the following API:

```
GET: /api/v1/policies/{policyId}/dry-run/artifacts?pageIndex=0&pageSize=100
```

To get complete information on the above API, please check : [Returns List of Artifacts](/developer-tools-and-resources/api-reference/dry-run-mode-using-apis/returns-list-of-artifacts#returns-lists-of-virtual-artifacts)

#### 4.8 IPFS

This tab shows the list of files that would have been saved in IPFS during the execution of the policy. In ‘Dry Run’ these files are not exported into IPFS and only exist in the local database.

There are different ways to view the list of files:

#### 4.8.1 From the Policy View Page

To view the list of the files, that will be stored in IPFS, click on **IPFS** option as shown below:

![](/files/FissNL90PjYlOmCbpck4)

#### 4.8.2 By calling an API

The IPFS files list can also be viewed by calling the following API:

```
GET: /api/v1/policies/{policyId}/dry-run/ipfs?pageIndex=0&pageSize=100
```

To get complete information on above API, please check : [/pages/W8njNFhFucKaB9RrrWGj#returns-lists-of-ipfs-files.](https://dev.guardian.hedera.com/guardian/workspace/policies/dry-run/pages/W8njNFhFucKaB9RrrWGj#returns-lists-of-ipfs-files. "mention")

#### 4.9 Savepoint

Savepoint will allow to mark any of the action in the dry run as savepoint, which can restored from that point. This feature is similar to adding checkpoints in the execution workflow.

<figure><img src="/files/rIvS9wB4Br1fKimnuAKv" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/LumXfDds329ODzesBclb" alt=""><figcaption></figcaption></figure>

## 2. Demo Video

[Youtube](https://www.youtube.com/watch?v=fLoQcCOBgfU\&t=115s)


# Dry Run Virtual Users

### feat/3642-dry-run-virtual-user

#### Get virtual user by DID

`GET /api/v1/policies/:policyId/dry-run/user/:did`

* Returns a single virtual user by DID in Dry Run mode
* Requires `POLICIES_POLICY_UPDATE`

#### Create virtual user v2

`POST /api/v1/policies/:policyId/dry-run/user` with header `Api-Version: 2`

* Creates a virtual user and returns only the created user object:

{ "username": "Virtual User 3", "did": "did:...", "hederaAccountId": "0.0.123", "active": false }

* More efficient than v1 — there is no need to re-fetch the full user list after creation

#### Deprecations

**Create virtual user v1**

`POST /api/v1/policies/:policyId/dry-run/user`

* Deprecated. Scheduled for removal: 2026-07-24 (4 months per API Deprecation Policy)
* v1 creates a virtual user and returns the full list of all virtual users (array)
* Migration: add header `Api-Version: 2` to receive only the created user object
* Frontend has already been migrated to v2

#### Internal Changes

* Added CREATE\_VIRTUAL\_USER\_V2 NATS event in PolicyEngineEvents
* Added GET\_VIRTUAL\_USER NATS event in PolicyEngineEvents
* Added countVirtualUsers() and getVirtualUser(did) methods to DatabaseServer
* Username generation optimized: uses countVirtualUsers() instead of loading all users

## Related Issues

* [https://github.com/hashgraph/guardian/issues/3642](https://github.com/hashgraph/guardian/issues/1987)


# Dry Run Mock Docs

## Overview

When testing a Guardian policy in **Dry Run** mode, blocks that interact with external services (IPFS, Hedera Topics, tokens, or third-party REST APIs) often cannot execute — there is no live environment for them to talk to. The **Mock Data** feature solves this by letting policy authors define and manage substitute responses for every external call a policy makes, enabling a fully self-contained, end-to-end dry-run test without any real network dependencies.

Mock data can be recorded automatically as the policy runs, entered manually, or imported from another policy's session — making it suitable for both exploratory testing and repeatable regression scenarios.

***

### Visual walkthrough

<div><figure><img src="/files/ApM3PtZQmxQtPzzDhbI9" alt=""><figcaption></figcaption></figure> <figure><img src="/files/Q0IScubqlFzWEDDOFzCd" alt=""><figcaption></figcaption></figure> <figure><img src="/files/BtMPsAlIGNRM0ypMfnlR" alt=""><figcaption></figcaption></figure> <figure><img src="/files/u2U2eUl5ttpUQfAQjtqa" alt=""><figcaption></figcaption></figure> <figure><img src="/files/uW0GRCTjvLspFb1RaWeM" alt=""><figcaption></figcaption></figure> <figure><img src="/files/iu3FOLiPp3FaIdcZbe2Q" alt=""><figcaption></figcaption></figure> <figure><img src="/files/gJlLCHtDcIEo79PTkIYU" alt=""><figcaption></figcaption></figure> <figure><img src="/files/ydkwUVflRXdVCZACKy81" alt=""><figcaption></figcaption></figure> <figure><img src="/files/TQBzDnHchfkLs1GUVO7N" alt=""><figcaption></figcaption></figure> <figure><img src="/files/su8KENiQSaOZdteARMir" alt=""><figcaption></figcaption></figure> <figure><img src="/files/wrGXyXpFLWxY5dKCo5bv" alt=""><figcaption></figcaption></figure> <figure><img src="/files/m7g1v6S5isxxJ5M63YUE" alt=""><figcaption></figcaption></figure> <figure><img src="/files/lNTlVak0ZCgnsDxgUPHq" alt=""><figcaption></figcaption></figure> <figure><img src="/files/PsU2z9ZKBVSvrshHX3Zu" alt=""><figcaption></figcaption></figure> <figure><img src="/files/ewqun1KzcP3TYGLePsuQ" alt=""><figcaption></figcaption></figure> <figure><img src="/files/QUT37Xa7v2cjnd4YpvW6" alt=""><figcaption></figcaption></figure></div>

***

## Key Capabilities

| Capability                  | Description                                                                                                                      |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Per-block configuration** | Enable or disable mocking individually for each block in the policy.                                                             |
| **Auto-recording**          | Live responses from external services are captured and stored automatically while the policy runs, so you can replay them later. |
| **Manual data entry**       | Add or edit mock responses directly in the UI without needing to make real external calls.                                       |
| **Cross-policy sharing**    | Export a mock dataset from one policy and import it into another, enabling coordinated multi-policy test scenarios.              |
| **Scoped mock types**       | Dedicated mock stores for IPFS files, Hedera topic messages, tokens, and generic REST API calls.                                 |

***

## Enabling Mock Data

### Option 1 — Enable at Dry Run Start

When you switch a policy to **Dry Run** mode for the first time, a dialog is shown:

> **"Enable Mock Data"**
>
> Mock Data intercepts all external service calls (IPFS, Topics, Tokens, and API requests) and returns pre-configured test responses instead of making real network calls. This lets you run and test your policy in a fully self-contained offline environment.
>
> You can change this setting and configure individual blocks at any time from the **Mock Config** panel.
>
> \[ **Enable** ] \[ **Disable** ]

### Option 2 — Enable After the Session Has Started

If you skipped the prompt above or want to toggle mocking mid-session, open the **Mock Config** panel from the policy toolbar and use the master **Enable Mock Data** toggle. Changes take effect immediately for subsequent block executions.

### Option 3 — Configure Individual Blocks

In the **Mock Config** panel, each block that performs external calls is listed separately with its own enable/disable toggle. This is useful when you want some blocks to use real external calls while others use mocked responses.

***

## Mock Config and Mock Data Panels

There are two separate panels for managing mock data, both accessible from the policy editor toolbar while a Dry Run session is active:

* **Mock Config** — controls mocking globally via a master enable/disable toggle, and allows switching mocking on or off for each individual block. This is where you configure the mocking rules.
* **Mock Data** — manages the actual mock payloads (IPFS files, topic messages, tokens, and API responses). This is where you view, add, edit, and delete the data that mocked blocks will serve.

Each tab also displays any responses that were **recorded automatically** while the policy ran with mocking disabled for that block. Recorded entries appear inline alongside manually added entries and can be edited or deleted directly within the same view.

The **Mock Data** panel contains four sections:

### 1. IPFS

Stores mock responses for blocks that read from or write files to IPFS.

Each entry maps an **IPFS CID** to a stored file payload. When a policy block requests a file by CID, the mock layer returns the stored payload instead of making a real IPFS network request.

**Adding an entry:**

* Click **"+ Add IPFS File Mock"**
* Enter the expected CID and upload or paste the file content
* Click **Save**

### 2. Topics / Messages

Stores mock Hedera Consensus Service (HCS) messages for blocks that read from or submit to topics.

Each entry maps a **Topic ID** to an ordered list of messages. When a policy block reads from a topic, messages are served from this list in sequence.

**Adding an entry:**

* Click **"+ Add Topic / Message Mock"**
* Enter the Topic ID and add one or more message payloads (JSON)
* Click **Save**

### 3. API

Stores mock responses for blocks that call external REST APIs.

Each entry maps an **HTTP method + URL pattern** to a fixed response (status code, headers, and body). When a policy block makes an outbound HTTP request matching a URL pattern, the mock layer returns the configured response instead.

**Adding an entry:**

* Click **"+ Add API Mock"**
* Select the HTTP method (GET, POST, PUT, DELETE, etc.)
* Enter the URL or URL pattern (wildcards supported, e.g. `https://api.example.com/data/*`)
* Define the response: status code, Content-Type, and body (JSON or plain text)
* Click **Save**

***

## Cross-Policy Data Sharing

If you have two policies where **Policy A** writes data somewhere (e.g., to a Hedera topic) and **Policy B** reads that data, you can share mock data between them:

{% stepper %}
{% step %}

### Enable Mock Data in both policies

Enable Mock Data in **both** policies.
{% endstep %}

{% step %}

### Run Policy A

Run **Policy A** through the steps that produce the data. Responses are captured automatically.
{% endstep %}

{% step %}

### Export the mock data

In Policy A's **Mock Data** panel, click **Export Mock Data** → save the `.json` file.
{% endstep %}

{% step %}

### Import into Policy B

Open Policy B's **Mock Data** panel, click **Import Mock Data** → select the saved file.
{% endstep %}

{% step %}

### Use the shared responses

Policy B now has all the mock responses produced by Policy A available for its dry-run session.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
The import merges incoming entries with existing mock data. Conflicting entries (same key or URL) prompt you to choose whether to overwrite or keep the existing value.
{% endhint %}

***

## API Reference

Base path: `/api/v1/policies/{policyId}/dry-run/mock`

### Get Mock Configuration

```http
GET /api/v1/policies/{policyId}/dry-run/mock/config
```

Returns the current mock configuration for the policy's dry-run session, including the master enabled flag and the per-block enable/disable map.

**Path Parameters**

| Parameter  | Type   | Required | Description                          |
| ---------- | ------ | -------- | ------------------------------------ |
| `policyId` | string | ✅        | The unique identifier of the policy. |

**Response `200 OK`**

```json
{
  "enabled": true,
  "blocks": [
    { "uuid": "block-uuid-1", "enabled": true },
    { "uuid": "block-uuid-2", "enabled": false }
  ]
}
```

***

### Update Mock Configuration

```http
POST /api/v1/policies/{policyId}/dry-run/mock/config
```

Updates the mock configuration — master toggle and/or per-block overrides.

**Request Body**

```json
{
  "enabled": true,
  "blocks": [
    { "uuid": "block-uuid-1", "enabled": false }
  ]
}
```

**Response `200 OK`** — Returns the updated configuration object (same schema as GET above).

***

### Get Stored Mock Data

```http
GET /api/v1/policies/{policyId}/dry-run/mock/data
```

Returns all currently stored mock entries (IPFS, Topics, Tokens, and API) for this policy.

**Response `200 OK`**

```json
{
  "ipfs": [
    { "cid": "Qm...", "content": "<base64-encoded file content>" }
  ],
  "topics": [
    { "topicId": "0.0.12345", "messages": [ { "sequenceNumber": 1, "payload": {} } ] }
  ],
  "tokens": [
    { "tokenId": "0.0.67890", "state": { "balance": 1000, "decimals": 2 } }
  ],
  "api": [
    { "method": "GET", "url": "https://api.example.com/data", "status": 200, "body": {} }
  ]
}
```

***

### Save Mock Data

```http
POST /api/v1/policies/{policyId}/dry-run/mock/data
```

Saves (creates or updates) mock data entries. The request body follows the same schema as the GET response. Existing entries for the same key are overwritten; all other existing entries are preserved.

**Response `200 OK`** — Returns the complete updated mock data object.

***

### Export Mock Data

```http
GET /api/v1/policies/{policyId}/dry-run/mock/export
```

Exports all stored mock data as a downloadable compressed `.mock` file (zip archive), which contains separate files for each data type. The response is streamed with `Content-Disposition: attachment`.

**Response `200 OK`**

```http
Content-Type: application/zip
Content-Disposition: attachment; filename="mock-{currentDateTime}.mock"
```

***

### Import Mock Data

```http
POST /api/v1/policies/{policyId}/dry-run/mock/import
```

Imports mock data from a previously exported `.mock` file and merges it into the current mock dataset.

**Request Body** — `multipart/form-data`

| Field  | Type | Description                                                 |
| ------ | ---- | ----------------------------------------------------------- |
| `file` | file | A `.mock` file previously exported via the Export endpoint. |

**Response `200 OK`** — Returns the complete updated mock data object after the merge.

***

### Execute API Mock Request (Frontend Blocks)

```http
POST /api/v1/policies/{policyId}/dry-run/mock/request/api
```

Triggers a mocked external API call on behalf of a policy block whose logic executes on the **frontend** (client-side code blocks). The server resolves the request against the stored API mock entries and returns the configured response.

**Request Body**

```json
{
  "method": "GET",
  "url": "https://api.example.com/endpoint",
  "headers": { "Authorization": "Bearer ..." },
  "body": {}
}
```

**Response `200 OK`** — Returns the mock response as configured in the API mock store.

***

### Execute IPFS Mock Request (Frontend Blocks)

```http
POST /api/v1/policies/{policyId}/dry-run/mock/request/ipfs
```

Triggers a mocked IPFS file retrieval on behalf of a policy block whose logic executes on the **frontend**. The server resolves the CID against the stored IPFS mock entries and returns the configured payload.

**Request Body**

```json
{
  "cid": "QmExampleCID123..."
}
```

**Response `200 OK`** — Returns the mock file payload as configured in the IPFS mock store.

***

## Permissions

All Mock Data operations require the **`POLICIES_POLICY_UPDATE`** permission. Users without this permission will receive a `403 Forbidden` response from all mock API endpoints and will not see the Mock Config or Mock Data panels in the UI.

## Related Issues

* [https://github.com/hashgraph/guardian/issues/5247](https://github.com/hashgraph/guardian/issues/1987)


# Savepoints

Savepoints allow users to capture and restore the state of a policy execution at specific moments during a dry run.

* Savepoints have names, each savepoint represents a specific Policy execution path.
* Savepoints are used to restore execution context to continue execution from the same point. They can be renamed, or deleted.
* Multiple savepoints per policy are supported, up to 5 in total per policy.
* The active savepoint is protected from accidental deletion.
* Bulk operations (delete all, apply multiple) are available.

All major data requests in the UI — including navigation, groups, blocks, and virtual users — can be executed in the context of a specific savepoint by using the savepointIds parameter. This ensures the dry-run session reproduces the exact saved state.


# Savepoints Reference

1. Step By Step
2. Demo

## 1. Step By Step

### 1.1 Create Savepoint:

* Click the **Savepoint** button.
* Enter a name in the dialog box.
* Click **Add** → the system will store a new savepoint for the current step of the Dry Run.

<figure><img src="/files/FYGFwry94c00d7Wxd1Ob" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/7GFtRpZJc9nhVbXbSP0k" alt=""><figcaption></figcaption></figure>

### 1.2 Restore Savepoint:

* Click the **Restore** button → a dialog opens showing all existing savepoints.
* From the dialog, you can:
  * **Apply** a savepoint → the Dry Run resumes from that state.
  * **Rename** a savepoint.
  * **Delete** a savepoint.
  * **Delete All Savepoints** → removes all savepoints for the policy.

<figure><img src="/files/4qf1OPfmzzs7fqlVxhBi" alt=""><figcaption></figcaption></figure>

### 1.3 Continue After Editing Policy

You can stop the Dry Run, modify the policy in the editor, and then restart the Dry Run.

{% hint style="danger" %}
**Note:** If you make changes to blocks that are already linked to existing savepoints, restoring those savepoints may cause unexpected behavior.
{% endhint %}

## 2. Demo Video

[Youtube](https://youtu.be/cO6Ls-j1ROE?si=ecjATzGYQECjiqTr\&t=120)


# Record & Replay

**“**&#x52;ecord/Run” options provide facilities to capture policy execution events, save and/or export them in a records file, which can then be replayed in the context of a different policy.

{% hint style="info" %}
Note: This functionality currently works in a Dry Run mode only.
{% endhint %}


# Record & Replay Reference

1. [Step By Step Process](#id-1.-step-by-step-process)
2. [Demo Video](#id-2.-demo-video)

## 1. Step By Step Process

## 1. Record

The recording starts on the press of the ‘Record’ button.

{% hint style="info" %}
Note: It is strongly recommended to initiate recording at the very beginning of the policy execution, otherwise issues may be encountered at the ‘Replay’ stage.
{% endhint %}

![image1.png](/files/SXChTLFGasrwarEaPPqu)

### 1.1 Menu

<figure><img src="/files/K05XDMwWyNbM5zLNrEWb" alt=""><figcaption></figcaption></figure>

1. “Stop” - ends the recording and downloads the capture file.

![image3.png](/files/fHKsuSCFFZwBYhHB6rg7)

2. Actions - shows/hides the list of recorded steps/events.

![image4.png](/files/jpwOsF3jiz7keYbVZEFi)

## 2. Replay

Pressing the ‘Run’ button will initiate replay of the previously recorded file.

![image5.png](/files/Q0ze3eDbitRO8A8dBwzL)

![image6.png](/files/tCHVmhgaXH4huAHGq8X6)

### 2.1 Menu

<figure><img src="/files/wD10N2AfpqSSLFU0reGZ" alt=""><figcaption></figcaption></figure>

1. Fast Forward - quick transition to the next step (skipping the replay of the recorded pause).

![image8.png](/files/Pe2WdDdCWVR2FJ4YuGM8)

2. Stop - ends the replay

![image9.png](/files/dQ3gH2CgeyCVEVjoxBi6)

3. Actions - shows/hides the list of replayed steps/events

![image10.png](/files/3pcTR6wYlWfmNSR92hhI)

### 2.2 Error

![image11.png](/files/UH7D4hx0zDCtyqzzCAbY)

In the case of an error the following actions are possible

1. Retry - attempts to repeat the errored step/event

![image12.png](/files/vyDgbjO4a8lF3tjVR9ib)

2. Skip - skips the errored step/event and execute the next one

![image13.png](/files/oFxFCj1wKYi8mx0X5cKK)

### 2.3 Results

A summary dialogue is shown at the end of the replay. This dialogue contains the information about the tokens and document created during the policy execution, and the extend to which these artifacts are similar to those produced during the original execution (when the ‘records’ file was created).

![image14.png](/files/qrad9zCjsLwC783cAM5P)

The ‘details’ page shows detailed breakdown of differences between the corresponding documents or tokens.

![image15.png](/files/AzpQA8lhL8TFGQKbcHbf)

## 2. Demo Video

[Youtube](https://youtu.be/WU_ntIM5SJA?si=MtY9JUD5mmVd4Gpp\&t=108)


# Policy Testing Reference

## **Add test data to the Policy**

Tests can be added to the Policy, when such a policy gets published then the added tests get embedded into the policy file.

Such tests are imported/exported together with their respective policies.

{% hint style="info" %}
**Note:** Tests can be run only when the policy is in the dry-run or demo status.
{% endhint %}

### 1. Adding Tests

Tests can be added to the policy via the corresponding menu option as shown on the screenshots below:

<figure><img src="/files/IUgrd8Jo8uSZp6I3X4S0" alt=""><figcaption></figcaption></figure>

![](/files/tuZzntTv3pQ7aNjdfeJJ)

### 2. Running Tests

To launch a test navigate to the tests list using the ‘Test details’ menu option\\

<figure><img src="/files/MCaq4lhNZSFgQJPxnWgk" alt=""><figcaption></figcaption></figure>

\
Select the desired test in the grid and press ***Run (or Re-Run)***

![](/files/Km61Ytzs2dwtYpxznXUv)

{% hint style="info" %}
**Note:** There could be only one active (running) test per policy, multiple policies can be running tests at the same time.
{% endhint %}

<figure><img src="/files/2z5iA6QLexl2OVAQsBc9" alt=""><figcaption></figcaption></figure>

### 3. View Test Results

Test results can be viewed in the test window

<figure><img src="/files/cyz1kdWrnNLDzIngabCm" alt=""><figcaption></figcaption></figure>

There are potential outcomes of running policy tests

1. **Stopped** – test was stopped by the user
2. **Success** – test was successfully executed and the results are fully matching those originally captured

![](/files/cUMXJwrijnAYklPRICLR)

3. **Failure (1)** – an error has occurred during the run of the test, the execution of the test was not completed

![](/files/wJEyrRVRFNYIBnObYk7j)

4. **Failure (2)** – test was executed, however test results (i.e. the produced artifacts) differ from those originally captured

![](/files/bpKFCl3whOdIx66iC5se)

Detailed comparison of the execution results (documents) can be performed by clicking on the ‘Show more details’ button.

![](/files/CxPXZsRM9JdRxcKpyZZu)

![](/files/MUCVzjJkQmSWPMqLuaC2)

### 4. Removing Tests

Tests which are not being run can be deleted.

![](/files/FDedGbyoeQEsjyVSLyHt)

### 5. Access from the grid

Tests can be managed and run from the Manage Policies grid.

<figure><img src="/files/1lDe2rjqaj4hTdLJEKQh" alt=""><figcaption></figcaption></figure>

This view allows to:

* Add a test to the policies if it does not yet have any tests
* Run the most recently added test
* Re-run the most recently run test
* Monitor the status of the test being run

## 2. Demo Mode

To simplify the UI of policy testing (useful for novice users) a new ‘**Demo**’ mode of policy import has been introduced. In this mode all policy processing is ‘read-only’, policy editing is not possible, and no communication with external systems such as Hedera network and/or IPFS is performed. Policy execution in the **Demo** mode is similar to **dry-run**.

To use demo mode the corresponding option should be selected on the policy import dialogue.

<figure><img src="/files/4hTMrkgwDsffHzcg5ciE" alt=""><figcaption></figcaption></figure>


# Policy Integrity Tests

Policy Integrity Tests are an end-to-end (e2e) testing capability that lets policy authors define expected inputs and outputs for a policy and verify automatically whether the policy produces them. A test passes when the declared outputs match. A test fails when they do not.

### The problem they solve

Policies change. Guardian upgrades. Methodologies get refined. Each of these events can silently alter how a policy behaves — producing different document outputs, triggering unexpected workflow paths, or failing to issue tokens under conditions that previously worked. Without a way to verify expected behavior, errors surface in production and affect real project data and real environmental asset issuance.

Policy Integrity Tests give registry operators and policy authors a repeatable, automated way to confirm that a policy still behaves as intended after any change — to the policy itself, to Guardian, or to the underlying system.

### How they work

An author defines a test by specifying two things: the input documents the policy should receive, and the output documents the policy should produce. Guardian runs the policy against those inputs and evaluates whether the outputs match the author's declaration. The result is a simple pass or fail.

Tests are accessible from both the UI and the API, and can be re-run at any point in the policy lifecycle.

### Key distinctions

Guardian already supports automated end-to-end comparison through its record-and-replay capability, which captures an entire workflow execution and replays it to detect any divergence. That approach performs a technical comparison of the full execution — including UUIDs and other system-level metadata that policy authors do not own or control.

Policy Integrity Tests build upon this functionality and instead of comparing entire workflow executions, they let authors declare scope: which documents are the input, and which specific output documents need to match. The test passes when the declared outputs match, regardless of surrounding workflow differences outside that declared scope. This makes tests stable across policy edits and Guardian version upgrades — they only fail when the logic the author actually cares about changes.

### When to use them

Tests are most valuable at two points in the policy lifecycle.

**During authoring and iteration** — before publishing, tests confirm that the policy logic matches the methodology specification. In complex multi-role workflows, a misconfigured block can produce incorrect output without any visible error. Tests surface that before it reaches production.

**After changes** — when a policy is updated or Guardian is upgraded to a new version, re-running the policy integrity tests confirms that the behavior authors care about is preserved. This is regression testing for policy logic and verificable credential document outputs.

### Who creates them

Policy Integrity Tests are created and managed by Standard Registry operators and policy authors — the roles responsible for the correctness of the policy. Tests are part of the policy authoring and governance workflow, not end-user functionality.

### Related

* [Create a Policy Integrity Test](/guardian/workspace/policies/dry-run/policy-integrity-tests/create-a-policy-integrity-test)
* [Attach a Policy Integrity Test](/guardian/workspace/policies/dry-run/policy-integrity-tests/attach-a-policy-integrity-test)
* [Run a Policy Integrity Test](/guardian/workspace/policies/dry-run/policy-integrity-tests/run-a-policy-integrity-test)


# Create a Policy Integrity Test

Create a Policy Integrity Test when you want to test that given inputs will produce known outputs. This is useful for example during calculation engine steps where a user may submit input data which are then used by mathematical results included in output documents. These outputs are often part of policy validation and testing. By recording this, the test can later be attached to a policy which can skip manual validation in the future.

#### Prerequisites

* Introduced in Guardian 3.6.0

#### Steps

1. Set your policy to be in dry run mode
2. Open the policy and start recording
3. Navigate within the policy to a form that includes inputs you want to capture as part of your test
4. Click the 'Test' drop down to open the menu and check the box to capture the input of the next form submission as part of the test
5. Submit the form
6. Inspect the 'Test' drop down to see which verifiable credential document outputs have been created
7. Navigate within the UI or click the view document link in the drop down to inspect the values of the document to confirm that they are correct
8. Open to the 'Test' drop drop and check the box beside the document output that you confirmed as correct and want to include in the test
9. Repeat to include additional form submissions and/or document outputs
10. Stop the recording
11. Enter a title for the record file and include a description that describes what is included in this test

#### Result

You now have saved a policy integrity test record file.

#### Troubleshooting

None

#### Related

* [Policy Integrity Tests](/guardian/workspace/policies/dry-run/policy-integrity-tests)

{% embed url="<https://www.loom.com/share/5f0d1f86ae7947698f63827e57aced68>" %}

## Related issues

* <https://github.com/hashgraph/guardian/issues/5910>
* <https://github.com/hashgraph/guardian/issues/5911>
* <https://github.com/hashgraph/guardian/issues/5912>
* <https://github.com/hashgraph/guardian/issues/5913>
* <https://github.com/hashgraph/guardian/issues/6002>
* <https://github.com/hashgraph/guardian/issues/6020>
* <https://github.com/hashgraph/guardian/issues/6021>


# Attach a Policy Integrity Test

Attach a policy integrity test so that it can be run against a policy at a later date.

#### Prerequisites

* Introduced in Guardian 3.6.0

Remove this section entirely if there are no prerequisites.

#### Steps

1. Navigate to Manage Policies
2. Open the policy context menu and select the Test Details menu item
3. Click the Add Test button
4. Choose a Policy Integrity Test Record to attach to the policy

#### Result

The Test Details Dialog shows all tests attached to a policy.

#### Troubleshooting

NA

#### Related

* [Policy Integrity Tests](/guardian/workspace/policies/dry-run/policy-integrity-tests)


# Run a Policy Integrity Test

Run a Policy Integrity Test to test to verify outputs produced during policy execution

#### Prerequisites

* Introduced in Guardian 3.6.0

#### Steps

1. Navigate to Manage Policies
2. Open the policy context menu
3. Select the Test Details menu item
4. View the tests attached to the policy
5. Run test(s)
   1. Click the Run button on the right side of the policy test table
   2. Click Re-Run to run all tests attached to the policy
6. Inspect results when the test has completed running

#### Result

When tests have completed running it will either pass or fail. You can then inspect the test results to compare the document outputs to understand which fields did/did not match the expected output under the present execution.

#### Troubleshooting

NA

#### Related

* [Policy Integrity Tests](/guardian/workspace/policies/dry-run/policy-integrity-tests)


# Capture, Replay, and Compare Data for Published Policies

For published policies, Guardian provides a **Capture and Replay** mechanism that allows you to:

* Automatically **record all actions** performed by a policy after it is published
* Store immutable execution records on **Hedera** with payloads persisted in **IPFS**
* **Import recorded executions** when re-importing a policy
* **Replay those executions** in Dry Run mode
* **Compare results** between the originally published run and the Dry Run execution

This capability is especially useful for:

* Regression testing
* Validating policy changes
* Auditing and traceability
* Debugging behavior differences between versions


# How to record, replay, and capture data for published policies with VM0042?

1. Step By Step
2. Demo

## 1. Step by Step

1. Import the VM0042 and publish the policy.

In the **Publish Policy modal**, highlight **☑ Record policy actions** (enabled by default)

<figure><img src="/files/OOagyzN3w2gRDIKLITui" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Note: By default, Guardian records every action executed by the policy once it’s published.\
These actions are written to Hedera and stored immutably, with payloads in IPFS.”
{% endhint %}

2. Once the policy is published, submit the Project Registration by logging in as Project Proponent:

<figure><img src="/files/w9QIM1YA3TMsFMLs2u1u" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Note: “Each step you see here—data submission, validation, calculations—is recorded as a discrete step.\
These steps are timestamped, ordered, and linked to IPFS payloads.”
{% endhint %}

3. Login as Standard Registry and approve the Project Proponent:

<figure><img src="/files/N2L9U4lcriFOl58DRaI7" alt=""><figcaption></figcaption></figure>

4. Login as VVB and submit VVB Registration:

<figure><img src="/files/I3UTiPjGkWsJBFKOAICR" alt=""><figcaption></figcaption></figure>

5. Login as Standard Registry and approve the VVB:

<figure><img src="/files/DFhIgXt5yCVt06M0cZxB" alt=""><figcaption></figcaption></figure>

6. Submit the Project Data as Project Proponent:

<figure><img src="/files/5isq56ggr737JZGcAvsd" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/fsjWvY34toeqrZXuhmAf" alt=""><figcaption></figcaption></figure>

7. Assign the VVB to the submitted Project for review:

<figure><img src="/files/5NcNZbLEmx7zOvRD8xn9" alt=""><figcaption></figcaption></figure>

8. Login as VVB and approve it:

<figure><img src="/files/1jifseKKdr1QHBhXqJiS" alt=""><figcaption></figcaption></figure>

9. Now, I login as Project Proponent and submit the Emission Reduction data where the Emission factor of Calcimite is taken as a default value as 0.12:

<figure><img src="/files/nKWNAoFPIeWepblzhLHs" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/XR1N3kmTtjVV7pRTnGtW" alt=""><figcaption></figcaption></figure>

10. Now, I copy the message identifier of this policy in order to import it.

<figure><img src="/files/ddmn6TO1bgSmajCIn2jj" alt=""><figcaption></figcaption></figure>

Also, check: **☑ Import existing record for this policy** during the import

<figure><img src="/files/gk9TqQi17Nf1pwZgAt5Q" alt=""><figcaption></figcaption></figure>

11. Now, I would change the Emission Factor of Calcimite from 0.12 to 0.026 in the policy configurator in draft status and then save it.

<figure><img src="/files/cpeZbYDDbsJv6rUZK76a" alt=""><figcaption></figcaption></figure>

12. Now, we run the policy in the dry run mode:

<figure><img src="/files/iSe5oj0bLrJlLeFRWpDq" alt=""><figcaption></figcaption></figure>

13. We now click on "Run" by enabling: **☑ Use records imported with this policy**

<figure><img src="/files/hC6DXsCIs75y5Ykiu4Vz" alt=""><figcaption></figcaption></figure>

Optional: Also, include newly recorded steps (steps that were recorded after policy with the steps was imported)

<figure><img src="/files/NUfAZR5LRZsaTt4MQz3b" alt=""><figcaption></figcaption></figure>

14. We should be able to see all the recorded steps when clicked on "Run"

<figure><img src="/files/gKbB9fSO7Uugow0ZPpm2" alt=""><figcaption></figcaption></figure>

15. We can also view the Playback information:

<figure><img src="/files/KLR3w8wNtYTCePTPmqny" alt=""><figcaption></figcaption></figure>

16. Documents can be compared by clicking on "Details" button:

<figure><img src="/files/8oguuXzLtvdhEIwS8nUV" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/FhDe2OTUKCY5EI7JP6UJ" alt=""><figcaption></figcaption></figure>


# Creating Policy Roles and Groups

1. [Step By Step Process](#id-1.-step-by-step-process)
2. [Demo Video](#id-2.-demo-video)

## 1. Step By Step Process

### 1. Roles

Set of textual constants that are used to separate users into different roles.

#### 1.1 Creation of Roles

Roles can be created by adding Role Property and its Value in Policy Configurator as shown below:

<figure><img src="/files/nITfljedJMxHsKxgv0EI" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/g9sMFnX42GiAJOeoBc5Z" alt=""><figcaption></figcaption></figure>

#### 1.2 Usage

This is used for setting Permissions for a block, which limits which users can see this block or access it via the API.

<figure><img src="/files/Ra9HbHz6GJPNjVh468Qg" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/E2U343Lwy8vZne1pxjCE" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
**Note:** Permissions do not affect the Block via Events.
{% endhint %}

### 2. Groups

Groups are separate sets of documents access , which can be limited to users who are members of the group.

{% hint style="info" %}
**Note**: A user can be included into any number of groups with a single role within each. User roles can be different in different groups.
{% endhint %}

#### 2.1 Properties

| Property Name     | Definition                                                                                                                                                                                                                                                                                            |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Name              | The name of the group                                                                                                                                                                                                                                                                                 |
| Creator Role      | Role which is assigned to the creator of the group                                                                                                                                                                                                                                                    |
| Members Role      | The list of roles which can be assigned to members of the group                                                                                                                                                                                                                                       |
| Relationship Type | <p>· Single – only a single user can be included in the group. This type is maintained for backward compatibility with historic policy versions.</p><p>· Multiple – the group can include multiple users. This is the new mode of operation.</p>                                                      |
| Access Type       | <p>· Global – static group is created at the start. The creator of the group is the creator of the policy.</p><p>· Private – a new instance of the group is created every time a user selects group creation action. The creator of the group is the user who executed the group creation action.</p> |

<figure><img src="/files/kKarFJRNcC07IpwLsW4K" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/Sslwso6bwLaWYfN5oGZa" alt=""><figcaption></figcaption></figure>

#### 2.2 Usage

**documentsSourceAddon** has multiple filters which allow us to select relevant documents

| Owned by User | Owned by Group | Document Selection                                              |
| ------------- | -------------- | --------------------------------------------------------------- |
| False         | False          | Documents are not filtered by Owner.                            |
| True          | False          | Only documents created by the current user (in all groups)      |
| False         | True           | Only documents created in the current group (by all users)      |
| True          | True           | Only documents created by the current user in the current group |

<figure><img src="/files/FgL0b5H8tKF9rFz4ESm7" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/UBkyfoJygBQmkGX0Ivi6" alt=""><figcaption></figcaption></figure>

### 3. Switching between Groups

When a policy contains multiple groups, users have an option to switch between those they are included in. The selection menu also allows to switch to the ‘no group’ default state, i.e. the state in which the user is not acting as a member of any group.

<figure><img src="/files/4wBWX2u9mMtSVdGKLeRV" alt=""><figcaption></figcaption></figure>

## 2. Demo Video

[Youtube](https://youtu.be/yPQ_iabLczs?si=vEbhhvl2DKKYEr6o\&t=115)


# Global Policy Search & Compare

Global Policy Search & Compare feature allows users to efficiently manage and analyze policies across different Guardian instances. Here are the main aspects of this feature:

1. **Global Search**: Users can perform comprehensive searches across all policies within the system using the UI. This functionality includes searching for specific policy elements, steps, or documents based on keywords or metadata.
2. **Policy Comparison**: The comparison tool enables users to identify differences between policies. This is particularly useful when updating or migrating policies, as it helps ensure consistency and correctness. Users can see a detailed, side-by-side view of the policies being compared.
3. **API Support**: The system provides APIs for both searching and comparing policies, allowing for integration with other tools and automated workflows. This includes:
   * Comparing policies to highlight differences and similarities.
   * Searching policies and exporting comparison results.
4. **UI Features**: The user interface supports policy differentiation and comparison through visual aids and interactive elements, making it easier to spot and understand differences between policy versions.
5. **Export Functionality**: Users can export the results of policy comparisons for documentation or further analysis.


# Global search and comparison UI

1. [Step By Step Process](#id-1.-step-by-step-process)
2. [Demo Video](#demo-video)

## 1. Step By Step Process

## 1. Configuration

Global policy search and comparison relies on Indexer for some of its functionality. Such Indexer can be deployed locally, or run elsewhere so long as there is an HTTP access path which must be specified in the *ANALYTICS\_SERVICE* parameter in the .env configuration file:\
\
\&#xNAN;*Example:*

*"ANALYTICS\_SERVICE": "<http://localhost:3021>",*

### **1.1 Compare**

There are a several way to select policies for comparison, all of which **do not** require/result in the importing of the policies into Guardian.

![](/files/9FxNZGuqv6VC7vl5a7Kf)

![](/files/KDAfkNObnJINM1mtKRmf)

Policies can be selected from different sources

* Already imported (i.e. now ‘local’) policies

<figure><img src="/files/JPmQSizFTun9RMTsEya3" alt=""><figcaption></figcaption></figure>

* by message ID

![](/files/DBiSq8QlfnG4YgMjTrci)

* from local file

![](/files/dyDugZjFc2m4q60qclyK)

### **1.2 Search**

Not using content similarity criteria for searching.

<figure><img src="/files/PQ64Jz4lxQwL3JQqONRw" alt=""><figcaption></figcaption></figure>

Searching based on the content similarity to the existing policy.

![](/files/VF4DVkn3lAHjpOXnE9oO)

#### **1.2.1 Filters**

<figure><img src="/files/6IApvfRHsfbNn4iwjXkD" alt=""><figcaption></figcaption></figure>

* **Type –** data source
  * Search only imported – search only ‘local’ policies which have been imported (as ‘drafts’)
  * Local Guardian search – search in all published ‘local’ policies
  * Global search – global search through all policies (using Indexer)
* **Search** – search using keywords
* **Minted Tokens** – include only those policies which already produced issued/minted tokens, with the minimal quantity as specified
* **VC Documents** – include only those policies which already produced VC documents, with the minimal quantity as specified
* **VP Documents** – include only those policies which already produced VP documents, with the minimal quantity as specified
* **Policy Owner** – include only those owned by specific DID\[s]
* **Tools** - search by tool name

#### **1.2.2 Import**

Users can import found policies into local Guardian instance.

![](/files/We9GldH7GcwjbhEmo9yS)

### 2. Comparison Result

We have several different sections in our comparison screen including filter parameters:

<figure><img src="/files/g2GIB4RM53wHIDsrHZC9" alt=""><figcaption></figcaption></figure>

Selected Policies are compared to the first Policy (displayed in the section on the left-hand side), the rest of the sections show the results of the ‘diffs’.

<figure><img src="/files/cOpiMtymtR5OSaQaOmym" alt=""><figcaption></figcaption></figure>

### 2.1 Comparison Parameters

1. **Events:** configures if differences in events are reflected in the results of the comparison of blocks

| Parameter     | Definition                                                             |
| ------------- | ---------------------------------------------------------------------- |
| Don't compare | event differences are not reflected in the results of comparing blocks |
| All events    | event differences are reflected in the block comparison results        |

2\. **Properties :** configures how differences in Properties are reflected in the results of comparing blocks

| Parameter              | Definition                                                                                                            |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Don't compare          | differences in properties do not have effect on the comparison of blocks, except the ‘tag’ and ‘block type’ which do. |
| Only simple properties | only simple Properties influence block comparison                                                                     |
| All properties         | all Properties are taken into consideration for block comparison                                                      |

3\. **Children** : configures how differences in child blocks influence the results of comparing parent blocks

| Parameter                            | Definition                                                                           |
| ------------------------------------ | ------------------------------------------------------------------------------------ |
| Don't compare                        | when parents blocks are compared their child blocks are not taken into consideration |
| Only child blocks of the first level | only immediate children of parent blocks are compared when comparing parent blocks   |
| All children                         | all children of parent blocks are compared when comparing parent blocks              |

4\. **UUID** : configures if UUID and Hedera ID are taken into consideration when comparing blocks

| Parameter     | Definition                                                                                                                                                                                                                                                                                          |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Don't compare | UUIDs of schemas, tokens, topics, etc and their Properties are not compared when blocks are compared                                                                                                                                                                                                |
| All UUID      | <p>all IDs are taken into consideration when comparing blocks<br><em>(for example when this option is chosen if all Properties of tokens in two Policies being compared are the same these tokens would still be considered different since they would by definition have different UUIDs)</em></p> |

### 2. Sections:

There are different sections in the comparison such as

1. **Main** – shows results of comparison of the main fields of the Policies
2. **Policy Roles** – shows results of comparison of the roles of Policies
3. **Policy Groups** – shows results of comparison of the groups
4. **Policy Topics** – shows results of comparison of dynamic topics
5. **Policy Tokens** – shows results of comparisons of dynamic tokens
6. **Policy Blocks** – shows results of comparisons of Policy block structures

We have several Display settings in Policy Blocks section:

<figure><img src="/files/3kLVcNK38ccYyKhk0qOy" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/IOrILxCocdikYyJLcZgc" alt=""><figcaption></figcaption></figure>

**Display Settings:** description and show/hide settings for each color/type of difference:

| Color         | Purpose                                                                                 |
| ------------- | --------------------------------------------------------------------------------------- |
| Green         | blocks are equal, including their child blocks                                          |
| Green - Amber | blocks are equal, but their child blocks are different                                  |
| Amber         | blocks are of the same type and are partially equal, there are some notable differences |
| Red           | blocks are absent in the other Policy                                                   |

Block comparison displays can be unfolded to display a detailed view of the block Properties.

<figure><img src="/files/AeBqUcPLKTjg9gW8uvMt" alt=""><figcaption></figcaption></figure>

## Demo Video

[Youtube](https://youtu.be/qzUIqAa2m4E?si=ANBfV-vmJoJsMuvq\&t=155)


# Policy Comparison Reference

1. [Step By Step Process](#step-by-step-process)
2. [Demo Video](#demo-video)

## Step by Step Process

### 1. Start Comparison and choose policies:

To compare the policies, we need to click on **Compare** button in the policies tab as shown below:

<figure><img src="/files/PSEt8cV5tDeDE2zvlvXP" alt=""><figcaption></figcaption></figure>

When Compare button is clicked, we get a pop up to select policies, which we want to perform comparison off.

<figure><img src="/files/BRvim3GfIIyVEWv0psJd" alt=""><figcaption></figcaption></figure>

### 2. Comparison Result

We have several different sections in our comparison screen including filter parameters:

<figure><img src="/files/g2GIB4RM53wHIDsrHZC9" alt=""><figcaption></figcaption></figure>

Selected Policies are compared to the first Policy (displayed in the section on the left-hand side), the rest of the sections show the results of the ‘diffs’.

<figure><img src="/files/cOpiMtymtR5OSaQaOmym" alt=""><figcaption></figcaption></figure>

### 2.1 Comparison Parameters

1. **Events:** configures if differences in events are reflected in the results of the comparison of blocks

| Parameter     | Definition                                                             |
| ------------- | ---------------------------------------------------------------------- |
| Don't compare | event differences are not reflected in the results of comparing blocks |
| All events    | event differences are reflected in the block comparison results        |

2\. **Properties :** configures how differences in Properties are reflected in the results of comparing blocks

| Parameter              | Definition                                                                                                            |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Don't compare          | differences in properties do not have effect on the comparison of blocks, except the ‘tag’ and ‘block type’ which do. |
| Only simple properties | only simple Properties influence block comparison                                                                     |
| All properties         | all Properties are taken into consideration for block comparison                                                      |

3\. **Children** : configures how differences in child blocks influence the results of comparing parent blocks

| Parameter                            | Definition                                                                           |
| ------------------------------------ | ------------------------------------------------------------------------------------ |
| Don't compare                        | when parents blocks are compared their child blocks are not taken into consideration |
| Only child blocks of the first level | only immediate children of parent blocks are compared when comparing parent blocks   |
| All children                         | all children of parent blocks are compared when comparing parent blocks              |

4\. **UUID** : configures if UUID and Hedera ID are taken into consideration when comparing blocks

| Parameter     | Definition                                                                                                                                                                                                                                                                                          |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Don't compare | UUIDs of schemas, tokens, topics, etc and their Properties are not compared when blocks are compared                                                                                                                                                                                                |
| All UUID      | <p>all IDs are taken into consideration when comparing blocks<br><em>(for example when this option is chosen if all Properties of tokens in two Policies being compared are the same these tokens would still be considered different since they would by definition have different UUIDs)</em></p> |

### 2. Sections:

There are different sections in the comparison such as

1. **Main** – shows results of comparison of the main fields of the Policies
2. **Policy Roles** – shows results of comparison of the roles of Policies
3. **Policy Groups** – shows results of comparison of the groups
4. **Policy Topics** – shows results of comparison of dynamic topics
5. **Policy Tokens** – shows results of comparisons of dynamic tokens
6. **Policy Blocks** – shows results of comparisons of Policy block structures

We have several Display settings in Policy Blocks section:

<figure><img src="/files/3kLVcNK38ccYyKhk0qOy" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/IOrILxCocdikYyJLcZgc" alt=""><figcaption></figcaption></figure>

**Display Settings:** description and show/hide settings for each color/type of difference:

**Icons:** In addition to colors, icons are displayed between the compared blocks to help users quickly identify the type of difference.

* **Color-blind mode:** A "Color-blind mode" toggle is available in the comparison toolbar to switch between the standard color scheme and an accessible color palette optimized for users with color vision deficiencies.

<table><thead><tr><th width="374">Color</th><th>Color Blind Mode</th><th>Purpose</th></tr></thead><tbody><tr><td>Green</td><td>Blue</td><td>blocks are equal, including their child blocks</td></tr><tr><td>Green - Amber</td><td>Blue-Orange</td><td>blocks are equal, but their child blocks are different</td></tr><tr><td>Amber</td><td>Orange</td><td>blocks are of the same type and are partially equal, there are some notable differences</td></tr><tr><td>Red</td><td>Purple</td><td>blocks are absent in the other Policy</td></tr></tbody></table>

<figure><img src="/files/eKF1XaNR1xeACAeBSszA" alt=""><figcaption></figcaption></figure>

Block comparison displays can be unfolded to display a detailed view of the block Properties.

<figure><img src="/files/AeBqUcPLKTjg9gW8uvMt" alt=""><figcaption></figcaption></figure>

## Demo Video

[Youtube](https://www.youtube.com/watch?v=wdPjoAgWSuI\&list=PLnld0e1pwLhqdR0F9dusqILDww6uZywwR\&index=10)


# Block/Policy Discoverability

Guardian policy authors can search for occurrences of the block usage in a similar context, i.e. embedded into the policy content of similar structure (surrounded by similar blocks), across all published policies within the Guardian instance using the search button in the policy editor.

In addition to block, Guardian also have an ability to search policy with similar workflow and can display the similarity percentage with the source policy.


# Search Policy using UI

1. [Step By Step Process](#id-1.-step-by-step-process)
2. [Demo Video](#id-2.-demo-video)

## 1. Step By Step Process

Policies can be searched by clicking on "Search policies" button. It can be searched based on their similarity to the given policy.

<figure><img src="/files/M8eXc60L0wXQWaMhlAHl" alt=""><figcaption></figcaption></figure>

The results are displayed in the descending order, the most similar policy is displayed at the top. It also displays similarity rate percentage.

<figure><img src="/files/KO3yKAtTh7F6G6XbOvmF" alt=""><figcaption></figcaption></figure>

We can also have an option for full display mode of similarity result as shown:

<figure><img src="/files/bYA0AEGGBrqo93vzb5AN" alt=""><figcaption></figcaption></figure>

## 2. Demo Video

[Youtube](https://youtu.be/qvmSPYIZx8k?si=1zSNjIFzzB0iVWCX\&t=108)


# Search Block using UI

1. [Step By Step Process](#id-1.-step-by-step-process)
2. [Demo Video](#id-2.-demo-video)

## 1. Step By Step Process

## 1. Search Example

Blocks of similar configuration can be searched by clicking on search icon with respect to the block as shown below:

<figure><img src="/files/nZYxAI0DDCuD5ZpgC3SF" alt=""><figcaption></figcaption></figure>

## 2. Search Result

Search result displays all the policies and its blocks, which have same flow with respect to the base block search.

<figure><img src="/files/DuGVHxBiR0GGsOP2LxVY" alt=""><figcaption></figcaption></figure>

### 2.1 Context

The search finds and displays the ranked list (most similar on top) of longest continuous matching sequences of blocks surrounding the target block (highlighted). The search considers all dimensions - next/previous, parent/child - to be of equal weight and thus ranks results by the number of blocks in the found ‘similar’ sequence.

<figure><img src="/files/VEUtYpClM0x64cIEtJP7" alt=""><figcaption></figcaption></figure>

Additionally, the system compares the configuration of the blocks individually, and displays the %% of similarity to the right of each block in comparison with the corresponding blocks in the base policy.

### 2.2 Block Configuration

Right panel of the UI displays the configuration details of the currently selected block as shown below.

Clicking “Apply” button will transfer (or apply) the configuration of the found block to the corresponding base policy block.

{% hint style="info" %}
**Note:** Original settings of the base policy block will be lost if ‘Apply’ action is executed.
{% endhint %}

<figure><img src="/files/G6KsRvWMWZ5PcMtdc3UO" alt=""><figcaption></figcaption></figure>

### 2.3 Search Results Layout Display

Search results are displayed as folded groups by Policy (policy name is displayed in the group heading).

<figure><img src="/files/s11zj77p1V8OsWE2oHAg" alt=""><figcaption></figcaption></figure>

The results are sorted by (in the correct order):

1\. The number of the similar blocks in the matching sequence

2\. Cumulative similarity score (%%) of the blocks

<figure><img src="/files/7SLH49HJN2G78TPuEAZB" alt=""><figcaption></figcaption></figure>

## 2. Demo Video

[Youtube](https://youtu.be/qvmSPYIZx8k?si=1zSNjIFzzB0iVWCX\&t=108)




---

[Next Page](/llms-full.txt/1)

