From 19efaa076fc8117b33dfeacc3828ea181c837f3b Mon Sep 17 00:00:00 2001 From: Daniel Swid Date: Wed, 18 Mar 2026 06:55:09 -0700 Subject: [PATCH 1/2] docs: correct typos across docs * thats it Story: <5856> Reviewed-by: na Test-scope: n Signed-off-by: Daniel Swid --- .../information-workflow-block.md | 2 +- .../paginationaddon.md | 2 +- .../reassigningblock.md | 2 +- ... secret in KMS according to environment.md | 32 +++++++++---------- docs/environments/Ecosystem-Environment.md | 14 ++++---- .../indipendent-services-images.md | 6 ++-- ...nce-configuration-according-environment.md | 4 +-- docs/faqs/faqs.md | 2 +- .../monitoring-tools.md | 2 +- .../architecture/schema-architecture.md | 2 +- ...rves-u.s.-landfill-protocol-version-6.0.md | 2 +- ...renewable-electricity-generation-v.18.0.md | 2 +- ...ss-for-thermal-applications-by-the-user.md | 4 +-- ...-acm0001-flaring-or-use-of-landfill-gas.md | 2 +- ...ation-from-biomass-in-power-only-plants.md | 2 +- ...i.a.-electricity-generation-by-the-user.md | 2 +- ...eneration-for-captive-use-and-mini-grid.md | 2 +- .../demo-guide/carbon-offsets/cdm-ams-ii.g.md | 2 +- .../carbon-offsets/cdm-ams-iii.bb.md | 6 ++-- .../carbon-offsets/cdm-ams-iii.d.md | 4 +-- ...rves-u.s.-landfill-protocol-version-6.0.md | 2 +- .../demo-guide/carbon-offsets/dovu-mmcm.md | 2 +- ...afforestation-and-reforestation-ar-v2.0.md | 2 +- .../goldstandard-metered-energy-cooking.md | 2 +- .../carbon-offsets/verra-redd+-demo-guide.md | 2 +- .../irec-7-demo-guide.md | 2 +- docs/guardian/faqs.md | 2 +- .../demo-using-ui.md | 2 +- ...figuration-according-to-the-environment.md | 4 +-- .../environments/ecosystem-environments.md | 4 +-- ...m-database-hashicorp-vault-during-setup.md | 6 ++-- .../installation/backup-tools.md | 2 +- .../README.md | 2 +- .../installation/cloud-deployment.md | 4 +-- .../getting-started/installation/upgrading.md | 4 +-- docs/guardian/readme/roadmap.md | 8 ++--- .../bring-your-own-byo-dids-ui.md | 4 +-- .../discontinue-policy.md | 2 +- .../fireblocks-signing-in-guardian-ui.md | 2 +- ...import-and-export-excel-file-user-guide.md | 4 +-- .../block-policy-discoverability/README.md | 2 +- ...-integrating-external-policies-using-ui.md | 2 +- .../downloadgeotiff.md | 4 +-- .../getnasaviirsfirealertsfeatures.md | 2 +- .../exports-comparison-result.md | 2 +- .../module-differentiation-using-ui.md | 2 +- .../policy-workflow-wrap-up.md | 2 +- .../prerequesite-steps.md | 2 +- .../introduction/customlogicblock.md | 2 +- .../information-workflow-block.md | 2 +- .../policy-creation/introduction/mathblock.md | 2 +- .../introduction/paginationaddon.md | 2 +- .../introduction/reassigningblock.md | 2 +- .../policies/tagging/tagging-using-ui.md | 4 +-- .../creating-system-schema-using-ui.md | 2 +- .../updating-schema.md | 2 +- .../tokens/creating-token-using-ui.md | 2 +- .../associating-user-with-the-hedera-token.md | 2 +- .../bottom-up-data-traceability-using-ui.md | 4 +-- docs/meeco/integration.md | 6 ++-- docs/meeco/mermaid-code.md | 10 +++--- .../README.md | 2 +- .../chapter-outlines.md | 2 +- .../part-3/chapter-10/README.md | 4 +-- .../part-3/chapter-9/README.md | 4 +-- .../part-5/chapter-19/README.md | 4 +-- .../prerequesite-steps.md | 2 +- .../policy-workflow-wrap-up.md | 2 +- .../updating-schema.md | 2 +- docs/secrets manager/guardian-vault.md | 18 +++++------ .../associating-user-with-the-hedera-token.md | 2 +- 71 files changed, 130 insertions(+), 130 deletions(-) diff --git a/docs/available-policy-workflow-blocks/information-workflow-block.md b/docs/available-policy-workflow-blocks/information-workflow-block.md index da741c67ba..33b6fe5b34 100644 --- a/docs/available-policy-workflow-blocks/information-workflow-block.md +++ b/docs/available-policy-workflow-blocks/information-workflow-block.md @@ -2,7 +2,7 @@ ### Properties -
Block PropertyDefinitionExample InputStatus
typeA block type which can display a notification or a progress bar.InformationBlock (Can't be changed).
tagUnique name for the logic block.wait_for_approval.
permissionsWhich entity has rights to interact at this part of the workflow.Installer.
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
dependenciesEstablish workflow dependancies that need to be completed prior.Select the appropriate block from the dropdown.Deprecated
stop PropagationEnd processing here, don't pass control to the next block.Checked or Unchecked.
+
Block PropertyDefinitionExample InputStatus
typeA block type which can display a notification or a progress bar.InformationBlock (Can't be changed).
tagUnique name for the logic block.wait_for_approval.
permissionsWhich entity has rights to interact at this part of the workflow.Installer.
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
dependenciesEstablish workflow dependencies that need to be completed prior.Select the appropriate block from the dropdown.Deprecated
stop PropagationEnd 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. diff --git a/docs/available-policy-workflow-blocks/paginationaddon.md b/docs/available-policy-workflow-blocks/paginationaddon.md index 0935f23f27..c5ca1df419 100644 --- a/docs/available-policy-workflow-blocks/paginationaddon.md +++ b/docs/available-policy-workflow-blocks/paginationaddon.md @@ -25,7 +25,7 @@ Selected policy ID Selected Block UUID {% endswagger-parameter %} -{% swagger-response status="200: OK" description="Succesful Operation" %} +{% swagger-response status="200: OK" description="Successful Operation" %} ``` { "size": 5, diff --git a/docs/available-policy-workflow-blocks/reassigningblock.md b/docs/available-policy-workflow-blocks/reassigningblock.md index 4eecc0186c..f804fdde3f 100644 --- a/docs/available-policy-workflow-blocks/reassigningblock.md +++ b/docs/available-policy-workflow-blocks/reassigningblock.md @@ -2,7 +2,7 @@ ### Properties -
Block PropertyDefinitionExample InputStatus
typeA block type which re-signs the document and change the user to document owner.reassigningBlock (Can't be changed).
tagUnique name for the logic block.wait_for_approval.
permissionsWhich entity has rights to interact at this part of the workflow.Installer.
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
dependenciesEstablish workflow dependancies that need to be completed prior.Select the appropriate block from the dropdown.Deprecated
stop PropagationEnd processing here, don't pass control to the next block.Checked or Unchecked.
issuerPerson, who will be a Signernot set - Current User
owner - document Owner
policyOwner - Policy Owner
actorPerson, who will be next Block Ownernot set - Current User
owner - document Owner
issuer - document Issuer
+
Block PropertyDefinitionExample InputStatus
typeA block type which re-signs the document and change the user to document owner.reassigningBlock (Can't be changed).
tagUnique name for the logic block.wait_for_approval.
permissionsWhich entity has rights to interact at this part of the workflow.Installer.
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
dependenciesEstablish workflow dependencies that need to be completed prior.Select the appropriate block from the dropdown.Deprecated
stop PropagationEnd processing here, don't pass control to the next block.Checked or Unchecked.
issuerPerson, who will be a Signernot set - Current User
owner - document Owner
policyOwner - Policy Owner
actorPerson, who will be next Block Ownernot set - Current User
owner - document Owner
issuer - document Issuer
{% hint style="info" %} RefreshEvents are used to refreshing the UI, instead of "dependencies" property. diff --git a/docs/environments/Dynamic secret in KMS according to environment.md b/docs/environments/Dynamic secret in KMS according to environment.md index ee2a29fe9d..e87466f2bb 100644 --- a/docs/environments/Dynamic secret in KMS according to environment.md +++ b/docs/environments/Dynamic secret in KMS according to environment.md @@ -5,11 +5,11 @@ Guardian platform manage to segregate secret data basing on the variables defined in the ecosystem environment. As in the database case the two variables leveraged to discriminate secret storage are the GUARDIAN_ENV and HEDERA_NET variables. -Each KMS use slight different approach to naming conventiion of holded secret. the KMS have to be configured with this two dimension(GUARDIAN_ENV and HEDERA_NET) and insert them in the secret name, in the Roles name and in the Policies that define the access rules to that secret. +Each KMS use slight different approach to naming convention of held secret. the KMS have to be configured with this two dimension(GUARDIAN_ENV and HEDERA_NET) and insert them in the secret name, in the Roles name and in the Policies that define the access rules to that secret. Guardian has adopted a specialized adapter to interact with secret managers. To implement the data separation each specialized adapter instance adds a two dimensional prefix GUARDIAN_ENV and HEDERA_NET to the PATH or NAME that identify the secret. So the adapter is aware of the MultiEnvironment. -The SECRET_MANAGER variable has to be configured in the system environemnt to grant the general secret manager class to work properly by the means of the right adapter in the way that is described at docs/secrets manager/guardian-vault.md +The SECRET_MANAGER variable has to be configured in the system environment to grant the general secret manager class to work properly by the means of the right adapter in the way that is described at docs/secrets manager/guardian-vault.md *Set SECRET_MANAGER as empty when not using any Secret Manager* @@ -17,7 +17,7 @@ The SECRET_MANAGER variable has to be configured in the system environemnt to gr SECRET_MANAGER can assume the following values: ['hcp', 'aws', 'azure'] -On the other hand the following variables have been mantained for compliance backward reason, and possible developed guardian extensions, but are not used for the Guardian Secret Manager implementation. +On the other hand the following variables have been maintained for compliance backward reason, and possible developed guardian extensions, but are not used for the Guardian Secret Manager implementation. VAULT_PROVIDER="database" #Always set to "database" HASHICORP_TOKEN="Q5D>3nu+Z#TbN.@9PWHSyL" #just written in NodeVault.VaultOptions never used @@ -35,7 +35,7 @@ Hashicorp Vault manage the TLS communication between each of the services as cli The R/W secrets permission Keys are added to the right environment file depending on the GUARDIAN_ENV variable. For this reason the guardian /vault/hashicorp/.env.template file has been enriched with the two variables GUARDIAN_ENV and HEDERA_NET. Then, as it is described at docs/secrets manager/guardian-vault.md, before the execution of the script, cut and paste the /vault/hashicorp/.env.template to create a /vault/hashicorp/.env file and configure the variables in it as of your needs. -The following environment variables has been introduced in the ecosystem environemnt to grant the Hashicorp Vault to work properly. +The following environment variables has been introduced in the ecosystem environment to grant the Hashicorp Vault to work properly. SECRET_MANAGER="hcp" added in the ecosystem environment variable VAULT_API_VERSION=v1 @@ -57,7 +57,7 @@ In this latter case the steps described for [hashicorp](https://github.com/hashg - **Step 5** is not needed any more: jump step 5. -- **Step 6** bring vault and consul up. Step 6 is breaked down in the following two steps: +- **Step 6** bring vault and consul up. Step 6 is broken down in the following two steps: 1. Only for first guardian installation: the guardian_default docker Network need to exist before Vault server Use it, in guardian folder execute: >$ docker network create guardian_default @@ -68,7 +68,7 @@ In this latter case the steps described for [hashicorp](https://github.com/hashg >$ docker compose up -d consul vault - The two cointainers are going to run referencing the guardian_default network as all other guradian services. + The two containers are going to run referencing the guardian_default network as all other Guardian services. - **Step 7** When the two services are running execute the script ./vault/hashicorp/scripts/vault/vault_init.sh from the guardian folder (or the vault_init_mac.init in apple platforms). @@ -77,29 +77,29 @@ In this latter case the steps described for [hashicorp](https://github.com/hashg VAULT_APPROLE_ROLE_ID= VAULT_APPROLE_SECRET_ID= - if not present the variables are inserted only in the 4 services: auth-service, guardian-ervice, policy-service, and worker-service. Their value are populated in the ./\/configs/.env.\.\ files by the script basing on the previously defined GUARDIAN_ENV variable. + if not present the variables are inserted only in the 4 services: auth-service, guardian-service, policy-service, and worker-service. Their value are populated in the ./\/configs/.env.\.\ files by the script basing on the previously defined GUARDIAN_ENV variable. The same script create a set of files in folder ./vault/hashicorp/configs/vault/secrets/tokens//.env.secrets this files are kept to allow configuration of other environment - **Step 8** start Guardian as usual -For Hashicorpp Vault the secret multienvironment naming convetion defined in the Vault by the execution of the script is going to be: +For HashiCorp Vault the secret multienvironment naming convention defined in the Vault by the execution of the script is going to be: / / -The script executed at stop 7 produce two kind of policies to manage the case when varialbe is empty. +The script executed at stop 7 produce two kind of policies to manage the case when variable is empty. Policy1: / Policy2: / / - **Adding other new environment :** After the first execution of the 8 steps every of the services is configured as Application with the Role needed to access the secrets following the policies configured. -To add other environment you need to create new secrets in the Vault per every of the environemt and configure the two variables in every of the right environmet in the .//configs/.env... +To add other environment you need to create new secrets in the Vault per every of the environment and configure the two variables in every of the right environment in the .//configs/.env... VAULT_APPROLE_ROLE_ID= VAULT_APPROLE_SECRET_ID= - To execute this actions automatically configure the GUARDIAN_ENV variable at folder ./vault/hashicorp/.env with the new environment name and run the provided script: ./vault/hashicorp/scripts/vault/vault_new_env.sh. The script configure the environemnt file of every of the four service and push the new secrets to the vault server. + To execute this actions automatically configure the GUARDIAN_ENV variable at folder ./vault/hashicorp/.env with the new environment name and run the provided script: ./vault/hashicorp/scripts/vault/vault_new_env.sh. The script configure the environment file of every of the four service and push the new secrets to the vault server. Now you can stop and start the guardian application: configure the new ecosystem environment per all its files and restart the application. ## AWS Secret Manager @@ -107,15 +107,15 @@ To add other environment you need to create new secrets in the Vault per every o Change in the ecosystem environment the SECRET_MANAGER variable to SECRET_MANAGER="aws" -For AWS Secret Manager one variable has been added to the system environemnt templates files of Guardian. +For AWS Secret Manager one variable has been added to the system environment templates files of Guardian. # AWS AWS_REGION=eu-central-1 -The script provided by Guardian and described at docs/secrets manager/guardian-vault.md is able to configure the ROLE / POLICIES secret in a Multi-environment fashion inside the AWS Secret Manager. As in the preciding case, the script is based on the two new environment variables defined at ./vault/aws/.env.template GUARDIAN_ENV and HEDERA_NET +The script provided by Guardian and described at docs/secrets manager/guardian-vault.md is able to configure the ROLE / POLICIES secret in a Multi-environment fashion inside the AWS Secret Manager. As in the preceding case, the script is based on the two new environment variables defined at ./vault/aws/.env.template GUARDIAN_ENV and HEDERA_NET The Policies that are defined in the scripts are compliant with the AWS security rules and the Action defined in the policies json files (folder:vault/aws/configs/policies) do not use wildcards but specified the following single actions: GetSecretValue, CreateSecret, ListSecrets. -In the case of AWS Secret Manager the secret multienvironment naming convetion defined is +In the case of AWS Secret Manager the secret multienvironment naming convention defined is / / @@ -125,12 +125,12 @@ In the case of AWS Secret Manager the secret multienvironment naming convetion Change the SECRET_MANAGER variable to "azure" in the ecosystem environment. SECRET_MANAGER="azure" -For Azure Key Vault one variable has been added to the system environemnt templates files of Guardian. +For Azure Key Vault one variable has been added to the system environment templates files of Guardian. # Azure Key Vault Configs AZURE_VAULT_NAME="" -The secret multienvironment naming convetion defined is +The secret multienvironment naming convention defined is GuardianenvHederanetPathToSecret diff --git a/docs/environments/Ecosystem-Environment.md b/docs/environments/Ecosystem-Environment.md index 60ec6421fc..146ff2198a 100644 --- a/docs/environments/Ecosystem-Environment.md +++ b/docs/environments/Ecosystem-Environment.md @@ -2,14 +2,14 @@ ###### \#1923, \#1639 -The set of environmet parameters represent the context in which a service it is executed. Each service needs to know this context to adapt its behaviour to the real working condition. At the service level the node dotenv library allows to read environment of the kind \ this library by default reads from .env file. The data are reads in a the process.environment data structure available in the execution context of Node process. +The set of environment parameters represent the context in which a service it is executed. Each service needs to know this context to adapt its behaviour to the real working condition. At the service level the node dotenv library allows to read environment of the kind \ this library by default reads from .env file. The data are reads in a the process.environment data structure available in the execution context of Node process. A unique file define the environment and keeps the responsibility to create the shared operative ecosystem. All Guardian Microservices share a common set of Environment variables. In this way Guardian can be seen as an ecosystem with several services and common set of parameters leading his behaviour. This environment parameters are shared between all the services of the Guardian ecosystem. -All variables are defined in a ".env.\.guardian.system" file. The file name is parametric so it is possible to define a different files for different possible running configuration, for example production, develop, test1. The ecosystem environment file follow the .env.template.guardian.system file that let write new configurations with the set of necessary variables. Both the template file and the resulting environmets files are in the folder "./configs/", they can be discriminated by its name to spread the session. +All variables are defined in a ".env.\.guardian.system" file. The file name is parametric so it is possible to define a different files for different possible running configuration, for example production, develop, test1. The ecosystem environment file follow the .env.template.guardian.system file that let write new configurations with the set of necessary variables. Both the template file and the resulting environment files are in the folder "./configs/", they can be discriminated by its name to spread the session. -The parameter GUARDIAN_ENV is defined univocally in a .env file. The containers orchestration will be responsible to push the environment in to the container in a way the environment will be available to the Node server. For example in the execution of Guardian using docker compose tool the tool inject the environment in each container. Docker compose push the environment in the container by the means of the env-file attribute and the environment attribute. Overmore the environment attribute can be parametrized by variables defined in a ".env" file located next to the docker_compose.yaml. +The parameter GUARDIAN_ENV is defined univocally in a .env file. The containers orchestration will be responsible to push the environment in to the container in a way the environment will be available to the Node server. For example in the execution of Guardian using docker compose tool the tool inject the environment in each container. Docker compose push the environment in the container by the means of the env-file attribute and the environment attribute. Furthermore, the environment attribute can be parametrized by variables defined in a ".env" file located next to the docker_compose.yaml. ![hierarchy.png](https://images.zenhubusercontent.com/63dbe2bd4d4d6290bed6780c/12790cd6-19b5-4f3c-aad2-9d28081e8498) @@ -22,9 +22,9 @@ Per each installed service the environment is configured using the two file: 2) "./guardian/\/configs/.env.\.develop" file The environment is loaded in the service by the file config.ts. the Environment is read in to two steps: at first steps the service .env file is loaded by Node while at second step ".env.\.\" file is loaded. -A new environmet variable OVERRIDE as "true"/"false" it has been added to let variables defined in the ".env.\.\.\" to override the common defined variables or add new ones. For example If OVERRIDE=true a variable with the same name as the one already defined in the ".env"" file will assume the value specify at service level. The OVERRIDE parameter is not mandatory. if OVERRIDE="false" (default value) specific service variables can only be added to the global ones. In each service a new "./configs" folder holds the set of paramentric service level environment files. +A new environment variable OVERRIDE as "true"/"false" it has been added to let variables defined in the ".env.\.\.\" to override the common defined variables or add new ones. For example If OVERRIDE=true a variable with the same name as the one already defined in the ".env"" file will assume the value specify at service level. The OVERRIDE parameter is not mandatory. if OVERRIDE="false" (default value) specific service variables can only be added to the global ones. In each service a new "./configs" folder holds the set of parametric service level environment files. -With this implementation the service orchestrator can push not just the econsystem environment but the service specific variables too or leave the service specific variables under the responsibility of the service itself. +With this implementation the service orchestrator can push not just the ecosystem environment but the service specific variables too or leave the service specific variables under the responsibility of the service itself. For example it is possible to use docker compose to orchestrate the service in a single node. Dcoker compose has “env-file” and “environment” attributes to define environment. There is a precedence between this two attributes as define at https://docs.docker.com/compose/environment-variables/envvars-precedence/#simple-example. In this way override=”true” always and variables re-assigned in the environment attributes override what has been defined in the .env.\.guardian.system env-file. @@ -44,7 +44,7 @@ GUARDIAN_ENV="develop" # OVERRIDE="false" ``` -Every variable that is used by the service is configured inside the .guardian/\/configs folder. Because GUARDIAN_ENV is configured as "develop" each service confiiguration are stored in files with format "./guardian/\/configs/.env.\.develop" that follows the template in the same folder. +Every variable that is used by the service is configured inside the .guardian/\/configs folder. Because GUARDIAN_ENV is configured as "develop" each service configuration are stored in files with format "./guardian/\/configs/.env.\.develop" that follows the template in the same folder. Configure the guardian-service in ./guardian/guardian-service/configs/.env.guardian.develop @@ -146,7 +146,7 @@ INITIALIZATION_TOPIC_ID="0.0.1960" -## 2) to mantain the same database already in use +## 2) to maintain the same database already in use --------------------------------------- ### at root level: diff --git a/docs/environments/indipendent-services-images.md b/docs/environments/indipendent-services-images.md index 2ec404a02e..c26a014d99 100644 --- a/docs/environments/indipendent-services-images.md +++ b/docs/environments/indipendent-services-images.md @@ -1,11 +1,11 @@ -### Indipendent services images +### Independent services images ###### \#1604 -The dockerized services images needs to be indipendent from the environment that describes the context in wich the images itself are running. +The dockerized services images needs to be independent from the environment that describes the context in which the images itself are running. In each service loading .env files at build time by means of dockerfiles, forces rebuilding the docker image for changes to be applied to the environment. To prevent this behavior the usage of “env_file” has been Introduced in the docker_compose file. In this way the environment variables are loaded in each container during the bootstrap of the application and passed to the image without the need to rebuild the image itself. The dockerfiles have been changed accordingly: the command “copy” of the .env file was commented out. Actually the .env file is not needed at build time while it’s going to be charged during the bootstrap of the containers at the compose-level. To prevent this behavior the usage of “env_file” has been Introduced in the docker_compose file. In this way the environment variables are loaded in each container during the bootstrap of the application and passed to the image without the need to rebuild the image itself. -The dockerfiles have been changed accordingly: the command “copy” of the .env file was commented out. Actually the .env file is not needed at build time while it’s going to be charged during the bootstrap of the containers at the compose-level. \ No newline at end of file +The dockerfiles have been changed accordingly: the command “copy” of the .env file was commented out. Actually the .env file is not needed at build time while it’s going to be charged during the bootstrap of the containers at the compose-level. diff --git a/docs/environments/persistance-configuration-according-environment.md b/docs/environments/persistance-configuration-according-environment.md index 2ead8a51da..ea8bb08793 100644 --- a/docs/environments/persistance-configuration-according-environment.md +++ b/docs/environments/persistance-configuration-according-environment.md @@ -5,7 +5,7 @@ Content of data stored during Guardian operative sessions are discriminated acco Persisted data during each session regarding transactions both towards Headera net and or Guardian database are easily discriminated in terms of environment and remain consistent with target Hedera network. The persistence consistency is guaranteed leveraging the environment variable which describe the target Headera Network(HEDERA_NET) used together with the "Guardian ecosystem-environment" name itself (GUARDIAN_ENV). -This two environment attribute can be considered as a key of the other session parameters, infact there is a functional dependency between the couple  and the data written to the DB during a working session. +This two environment attribute can be considered as a key of the other session parameters, in fact there is a functional dependency between the couple  and the data written to the DB during a working session. The implementation goes in the same line as Data level separation of concerns: in order to discriminate data stored to the database it has been added a different database per each Hedera network and Guardian environment. The new db names have the following format  @@ -15,6 +15,6 @@ The implementation goes in the same line as Data level separation of concerns: i It has been introduced a new parameter PREUSED_HEDERA_NET, this parameter is intended to hold the target Hedera network that the system already started to notarized data to. The PREUSED_HEDERA_NET can assume the values mainnet, testnet, previewnet, localnode. -To mantain the usage of the current databse the GUARDIAN_ENV parameter has to be left empty while the PREUSED_HEDERA_NET should be configured as stated before. +To maintain the usage of the current database the GUARDIAN_ENV parameter has to be left empty while the PREUSED_HEDERA_NET should be configured as stated before. Using this configuration the system will keep behaving in the same way as now and the original database names will be used for the data related to the currently used HEDERA_NET and current Guardian environment. In this way the modification will not impact the current data but will be possible to define multiple different environments and hedera net target BC sharing the same infrastructure without data separation concerns. diff --git a/docs/faqs/faqs.md b/docs/faqs/faqs.md index c1e76fbf71..56bfc1c8ae 100644 --- a/docs/faqs/faqs.md +++ b/docs/faqs/faqs.md @@ -64,7 +64,7 @@ A standard registry is an organization that establishes science-based standards When a policy is published a message is sent to the policy topic (on the policies page) where the policy (VP) and schemas are stored. -In the guardian a VP is a VP. It's just an object with schemas and dids inside of it. +In the guardian a VP is a VP. It's just an object with schemas and DIDs inside of it. **17. How does Guardian Provenance works?** diff --git a/docs/guardian-in-production/monitoring-tools.md b/docs/guardian-in-production/monitoring-tools.md index 5d315c73db..623a2e9942 100644 --- a/docs/guardian-in-production/monitoring-tools.md +++ b/docs/guardian-in-production/monitoring-tools.md @@ -14,7 +14,7 @@ Prometheus is an open-source monitoring system that excels at collecting and sto With Prometheus, you can instrument your Guardian application to expose various metrics, such as request latency, error rates, resource utilization, and custom application-specific metrics. Prometheus stores this data in a time-series database, allowing you to query historical metrics and generate meaningful insights. Additionally, Prometheus offers a flexible querying language called PromQL, which enables advanced data analysis and aggregation. -Grafana is a popular open-source data visualization and analytics platform that complements Prometheus by providing a feature-rich dashboarding solution. It allows you to create visually appealing and customizable dashboards to monitor and analyze metrics collected by Prometheus. Grafana supports a wide range of visualization options, including graphs, tables, heatmaps, and alerts. +Grafana is a popular open-source data visualization and analytics platform that complements Prometheus by providing a feature-rich dashboard solution. It allows you to create visually appealing and customizable dashboards to monitor and analyze metrics collected by Prometheus. Grafana supports a wide range of visualization options, including graphs, tables, heatmaps, and alerts. We have integrated Prometheus with Grafana, allowing you to create real-time dashboards that display critical metrics and provide a holistic view of your Guardian application's performance. These dashboards can help you identify bottlenecks, track trends, and troubleshoot issues promptly. Grafana also allows you to set up alerts based on predefined thresholds or complex rules, ensuring that you receive notifications when important metrics cross certain boundaries. diff --git a/docs/guardian/architecture/schema-architecture.md b/docs/guardian/architecture/schema-architecture.md index d47eaa9c67..8b1440867c 100644 --- a/docs/guardian/architecture/schema-architecture.md +++ b/docs/guardian/architecture/schema-architecture.md @@ -8,6 +8,6 @@ As visible from the below Topic Architecture diagram, for each published Policy 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 useable 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. +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.
diff --git a/docs/guardian/demo-guide/carbon-emissions/climate-action-reserves-u.s.-landfill-protocol-version-6.0.md b/docs/guardian/demo-guide/carbon-emissions/climate-action-reserves-u.s.-landfill-protocol-version-6.0.md index 88906eab37..b802a784fe 100644 --- a/docs/guardian/demo-guide/carbon-emissions/climate-action-reserves-u.s.-landfill-protocol-version-6.0.md +++ b/docs/guardian/demo-guide/carbon-emissions/climate-action-reserves-u.s.-landfill-protocol-version-6.0.md @@ -91,7 +91,7 @@ This policy is available for import via GitHub or IPFS timestamp. * **Attestation of Regulatory Compliance:** This attestation confirms that the project complies with all applicable federal, state, and local laws and regulations (e.g., environmental, safety). The Project Developer must disclose any instances of non-compliance to the verifier, who assesses the impact on credit issuance. * **Environmental Safeguards:** This schema ensures that project activities align with environmental best practices, minimizing unintended impacts on local ecosystems, air, water, and soil quality. The Project Developer must document steps taken to prevent adverse environmental effects, such as controlling potential pollutants, managing resource use, and protecting nearby habitats. This schema may also include periodic environmental impact assessments as part of ongoing compliance and verification. -## **Token (**Climate Reserve Tonnes - CRTs**)** +## **Token (**Climate Reserve Tonnes - CRTs**)** Each CRT represents one metric tonne of carbon dioxide equivalent (tCO₂e) reduced or avoided through the approved project activities. diff --git a/docs/guardian/demo-guide/carbon-offsets/ams-i.d-grid-connected-renewable-electricity-generation-v.18.0.md b/docs/guardian/demo-guide/carbon-offsets/ams-i.d-grid-connected-renewable-electricity-generation-v.18.0.md index a85714a5cc..356113cc98 100644 --- a/docs/guardian/demo-guide/carbon-offsets/ams-i.d-grid-connected-renewable-electricity-generation-v.18.0.md +++ b/docs/guardian/demo-guide/carbon-offsets/ams-i.d-grid-connected-renewable-electricity-generation-v.18.0.md @@ -83,7 +83,7 @@ At Monitoring Periods: ### Demo Video -[Youtube ](https://www.youtube.com/watch?v=QiH0R3NVKJo\&list=PLnld0e1pwLho3M7uAzcbyzyJobn-X9wG_\&index=3) +[YouTube ](https://www.youtube.com/watch?v=QiH0R3NVKJo\&list=PLnld0e1pwLho3M7uAzcbyzyJobn-X9wG_\&index=3) ### Policy Workflow diff --git a/docs/guardian/demo-guide/carbon-offsets/ams-i.e-switch-from-non-renewable-biomass-for-thermal-applications-by-the-user.md b/docs/guardian/demo-guide/carbon-offsets/ams-i.e-switch-from-non-renewable-biomass-for-thermal-applications-by-the-user.md index a7f0768c2a..99325dd70e 100644 --- a/docs/guardian/demo-guide/carbon-offsets/ams-i.e-switch-from-non-renewable-biomass-for-thermal-applications-by-the-user.md +++ b/docs/guardian/demo-guide/carbon-offsets/ams-i.e-switch-from-non-renewable-biomass-for-thermal-applications-by-the-user.md @@ -64,7 +64,7 @@ Various methodologies are used to quantify emissions reductions in cookstove pro ### Demo Video -[Youtube](https://www.youtube.com/watch?v=ekk_FT4aQBE) +[YouTube](https://www.youtube.com/watch?v=ekk_FT4aQBE) ### Policy Workflow @@ -125,7 +125,7 @@ Certified Emission Reduction (CER) credits, each equivalent to one tonne of CO2. ![](<../../../.gitbook/assets/11 (16).png>) -5. Сreate a new user again and assign their role as “VVB”. +5. Create a new user again and assign their role as “VVB”. ![](<../../../.gitbook/assets/12 (14).png>) diff --git a/docs/guardian/demo-guide/carbon-offsets/cdm-acm0001-flaring-or-use-of-landfill-gas.md b/docs/guardian/demo-guide/carbon-offsets/cdm-acm0001-flaring-or-use-of-landfill-gas.md index b001c951b9..4abfe1587a 100644 --- a/docs/guardian/demo-guide/carbon-offsets/cdm-acm0001-flaring-or-use-of-landfill-gas.md +++ b/docs/guardian/demo-guide/carbon-offsets/cdm-acm0001-flaring-or-use-of-landfill-gas.md @@ -122,7 +122,7 @@ Certified Emission Reduction (CER) credits, each equivalent to one tonne of CO2.
-5. Сreate a new user again and assign their role as “VVB”. +5. Create a new user again and assign their role as “VVB”.
diff --git a/docs/guardian/demo-guide/carbon-offsets/cdm-acm0018-electricity-generation-from-biomass-in-power-only-plants.md b/docs/guardian/demo-guide/carbon-offsets/cdm-acm0018-electricity-generation-from-biomass-in-power-only-plants.md index ec5667ba98..656a31f9b0 100644 --- a/docs/guardian/demo-guide/carbon-offsets/cdm-acm0018-electricity-generation-from-biomass-in-power-only-plants.md +++ b/docs/guardian/demo-guide/carbon-offsets/cdm-acm0018-electricity-generation-from-biomass-in-power-only-plants.md @@ -121,7 +121,7 @@ Certified Emission Reduction (CER) credits, each equivalent to one tonne of CO2.
-5. Сreate a new user again and assign their role as “VVB”. +5. Create a new user again and assign their role as “VVB”.
diff --git a/docs/guardian/demo-guide/carbon-offsets/cdm-ams-i.a.-electricity-generation-by-the-user.md b/docs/guardian/demo-guide/carbon-offsets/cdm-ams-i.a.-electricity-generation-by-the-user.md index f3fe9a4d06..40c89663b3 100644 --- a/docs/guardian/demo-guide/carbon-offsets/cdm-ams-i.a.-electricity-generation-by-the-user.md +++ b/docs/guardian/demo-guide/carbon-offsets/cdm-ams-i.a.-electricity-generation-by-the-user.md @@ -116,7 +116,7 @@ Certified Emission Reduction (CER) credits, each equivalent to one tonne of CO2.
-5. Сreate a new user again and assign their role as “VVB”. +5. Create a new user again and assign their role as “VVB”. 6. The VVB can now provide their name or the name they would like users to see when reviewing projects (i.e. their organization’s name).
diff --git a/docs/guardian/demo-guide/carbon-offsets/cdm-ams-i.f.-renewable-electricity-generation-for-captive-use-and-mini-grid.md b/docs/guardian/demo-guide/carbon-offsets/cdm-ams-i.f.-renewable-electricity-generation-for-captive-use-and-mini-grid.md index d885473051..3158e430bb 100644 --- a/docs/guardian/demo-guide/carbon-offsets/cdm-ams-i.f.-renewable-electricity-generation-for-captive-use-and-mini-grid.md +++ b/docs/guardian/demo-guide/carbon-offsets/cdm-ams-i.f.-renewable-electricity-generation-for-captive-use-and-mini-grid.md @@ -116,7 +116,7 @@ Certified Emission Reduction (CER) credits, each equivalent to one tonne of CO2.
-5. Сreate a new user again and assign their role as “VVB”. +5. Create a new user again and assign their role as “VVB”.
diff --git a/docs/guardian/demo-guide/carbon-offsets/cdm-ams-ii.g.md b/docs/guardian/demo-guide/carbon-offsets/cdm-ams-ii.g.md index 4dee78f03e..fb34adfc0e 100644 --- a/docs/guardian/demo-guide/carbon-offsets/cdm-ams-ii.g.md +++ b/docs/guardian/demo-guide/carbon-offsets/cdm-ams-ii.g.md @@ -106,7 +106,7 @@ Certified Emission Reduction (CER) credits, each equivalent to one tonne of CO2.
-5. Сreate a new user again and assign their role as VVB. +5. Create a new user again and assign their role as VVB.
diff --git a/docs/guardian/demo-guide/carbon-offsets/cdm-ams-iii.bb.md b/docs/guardian/demo-guide/carbon-offsets/cdm-ams-iii.bb.md index 29840e3f81..a061ac352e 100644 --- a/docs/guardian/demo-guide/carbon-offsets/cdm-ams-iii.bb.md +++ b/docs/guardian/demo-guide/carbon-offsets/cdm-ams-iii.bb.md @@ -105,11 +105,11 @@ Key parameters play a vital role in the implementation and monitoring of AMS-III The AMS-III.BB methodology plays a vital role in addressing the growing need for sustainable electrification in communities that lack access to reliable electricity. It provides a structured approach for projects aimed at extending the grid or constructing new mini grids to connect consumers who were previously off the grid. These initiatives aim to displace high-carbon-intensive electricity sources and fuel-based lighting systems, thus reducing greenhouse gas emissions and fostering economic development in underserved regions. To understand the significance of AMS-III.BB, it's essential to compare the merits and considerations of mini grids versus grid electricity. -Mini-grids are localized power generation and distribution systems, often deployed in remote or rural areaswhere connecting to the national or regional grid is cost-prohibitive. They bring electricity to communities that were once reliant on high-carbon-intensive mini-grids or stand-alone power generators. While mini grids offer reliable electricity access and the potential to integrate renewable energy sources, they can be economically challenging to establish and may rely on fossil fuel generators. In contrast, grid electricity operates within large, interconnected networks, benefiting from economies of scale and efficient power transmission. Grids can access a diverse energy mix, including renewables, and are subject to stringent environmental regulations, generally resulting in lower emissions compared to mini grids. The choice between mini-grids and grid electricity depends on the specific needs, geographic location, and economic viability of the targeted community or region. +Mini-grids are localized power generation and distribution systems, often deployed in remote or rural areas where connecting to the national or regional grid is cost-prohibitive. They bring electricity to communities that were once reliant on high-carbon-intensive mini-grids or stand-alone power generators. While mini grids offer reliable electricity access and the potential to integrate renewable energy sources, they can be economically challenging to establish and may rely on fossil fuel generators. In contrast, grid electricity operates within large, interconnected networks, benefiting from economies of scale and efficient power transmission. Grids can access a diverse energy mix, including renewables, and are subject to stringent environmental regulations, generally resulting in lower emissions compared to mini grids. The choice between mini-grids and grid electricity depends on the specific needs, geographic location, and economic viability of the targeted community or region. ### Demo Video -[Youtube](https://www.youtube.com/watch?v=CN0IDPGGS44\&list=PLnld0e1pwLho3M7uAzcbyzyJobn-X9wG_\&index=10) +[YouTube](https://www.youtube.com/watch?v=CN0IDPGGS44\&list=PLnld0e1pwLho3M7uAzcbyzyJobn-X9wG_\&index=10) ### Policy Workflow @@ -212,7 +212,7 @@ Certified Emission Reduction (CER) credits, each equivalent to one tonne of CO2.
-17. Once minting is completed after clicking on Mint, we can view Trustchain by clikcing on "View Trustchain" +17. Once minting is completed after clicking on Mint, we can view Trustchain by clicking on "View Trustchain"
diff --git a/docs/guardian/demo-guide/carbon-offsets/cdm-ams-iii.d.md b/docs/guardian/demo-guide/carbon-offsets/cdm-ams-iii.d.md index 09380ff330..644c8db5b1 100644 --- a/docs/guardian/demo-guide/carbon-offsets/cdm-ams-iii.d.md +++ b/docs/guardian/demo-guide/carbon-offsets/cdm-ams-iii.d.md @@ -42,7 +42,7 @@ In the context of modern emission reduction projects, the necessity for transpar ## Demo Video -[Youtube](https://www.youtube.com/watch?v=jWpCgWl-92E\&t=7s) +[YouTube](https://www.youtube.com/watch?v=jWpCgWl-92E\&t=7s) ## Policy Workflow @@ -113,7 +113,7 @@ Certified Emission Reduction (CER) credits, each equivalent to one tonne of CO2.
-6. Сreate a new user again and assign their role as VVB. +6. Create a new user again and assign their role as VVB.
diff --git a/docs/guardian/demo-guide/carbon-offsets/climate-action-reserves-u.s.-landfill-protocol-version-6.0.md b/docs/guardian/demo-guide/carbon-offsets/climate-action-reserves-u.s.-landfill-protocol-version-6.0.md index 88906eab37..79891f6c6d 100644 --- a/docs/guardian/demo-guide/carbon-offsets/climate-action-reserves-u.s.-landfill-protocol-version-6.0.md +++ b/docs/guardian/demo-guide/carbon-offsets/climate-action-reserves-u.s.-landfill-protocol-version-6.0.md @@ -91,7 +91,7 @@ This policy is available for import via GitHub or IPFS timestamp. * **Attestation of Regulatory Compliance:** This attestation confirms that the project complies with all applicable federal, state, and local laws and regulations (e.g., environmental, safety). The Project Developer must disclose any instances of non-compliance to the verifier, who assesses the impact on credit issuance. * **Environmental Safeguards:** This schema ensures that project activities align with environmental best practices, minimizing unintended impacts on local ecosystems, air, water, and soil quality. The Project Developer must document steps taken to prevent adverse environmental effects, such as controlling potential pollutants, managing resource use, and protecting nearby habitats. This schema may also include periodic environmental impact assessments as part of ongoing compliance and verification. -## **Token (**Climate Reserve Tonnes - CRTs**)** +## **Token (Climate Reserve Tonnes - CRTs**)** Each CRT represents one metric tonne of carbon dioxide equivalent (tCO₂e) reduced or avoided through the approved project activities. diff --git a/docs/guardian/demo-guide/carbon-offsets/dovu-mmcm.md b/docs/guardian/demo-guide/carbon-offsets/dovu-mmcm.md index 2b18658892..9e58428bf6 100644 --- a/docs/guardian/demo-guide/carbon-offsets/dovu-mmcm.md +++ b/docs/guardian/demo-guide/carbon-offsets/dovu-mmcm.md @@ -56,7 +56,7 @@ It is crucial that we record all RVSFs along with their associated ELV submissio ## Usage -While this policy can be used throught the standard UI the usage of the policy is primarily API based with the aim to automate ingestion, utilising the generic dMRV project structure and tools from DOVU: +While this policy can be used through the standard UI the usage of the policy is primarily API based with the aim to automate ingestion, utilising the generic dMRV project structure and tools from DOVU: * [DOVU Middleware API](https://github.com/dovuofficial/guardian-middleware-api/) * [DOVU PHP SDK](https://github.com/dovuofficial/guardian-php-sdk) diff --git a/docs/guardian/demo-guide/carbon-offsets/gold-standard-afforestation-and-reforestation-ar-v2.0.md b/docs/guardian/demo-guide/carbon-offsets/gold-standard-afforestation-and-reforestation-ar-v2.0.md index 5835468871..3221d8d3ca 100644 --- a/docs/guardian/demo-guide/carbon-offsets/gold-standard-afforestation-and-reforestation-ar-v2.0.md +++ b/docs/guardian/demo-guide/carbon-offsets/gold-standard-afforestation-and-reforestation-ar-v2.0.md @@ -12,7 +12,7 @@ description: Policy developed by Envision Blockchain ## **Policy Description**: -The Gold Standard Afforestation and Reforestation (AR) methodology is a set of guidelines and procedures developed by The Gold Standard Foundation for quantifying and verifying greenhouse gas (GHG) emissions reductions resulting from afforestation and reforestation projects. The methodology provides a standardized framework for calculating the carbon sequestration potential of these types of projects, taking into account removals from both aboveground and belowground tree biomass, and also quantifies emissions from biomass burning for site preparation and the use of nitrogen fertilizer. +The Gold Standard Afforestation and Reforestation (AR) methodology is a set of guidelines and procedures developed by The Gold Standard Foundation for quantifying and verifying greenhouse gas (GHG) emissions reductions resulting from afforestation and reforestation projects. The methodology provides a standardized framework for calculating the carbon sequestration potential of these types of projects, taking into account removals from both above ground and belowground tree biomass, and also quantifies emissions from biomass burning for site preparation and the use of nitrogen fertilizer. The AR methodology sets out requirements for project design, implementation, and monitoring. It outlines the steps necessary to establish a baseline for GHG emissions and carbon sequestration potential, and to assess the project's impact on local biodiversity. The methodology also includes provisions for addressing potential leakage and permanence risks, which can impact the long-term effectiveness of the project in sequestering carbon. diff --git a/docs/guardian/demo-guide/carbon-offsets/goldstandard-metered-energy-cooking.md b/docs/guardian/demo-guide/carbon-offsets/goldstandard-metered-energy-cooking.md index 3e58eb5ad9..9842cd4e1f 100644 --- a/docs/guardian/demo-guide/carbon-offsets/goldstandard-metered-energy-cooking.md +++ b/docs/guardian/demo-guide/carbon-offsets/goldstandard-metered-energy-cooking.md @@ -169,7 +169,7 @@ VVB is the external independent third party responsible for reviewing Project De ### Future proofing(Automated credit issuance) -This workflow includes a bonus flow which is a major distinction from other existing policies. Building monitoring reports for cookstove projects is a very manual and error-prone process due to distributed nature of project. Often, a sample group of households are selected to be monitored and results are extrapolated for all the households(in thousands) leading to overcrediting. Since this methodology focuses on having direct measurement devices associated with a stove, an automated way of monitoring is possible. +This workflow includes a bonus flow which is a major distinction from other existing policies. Building monitoring reports for cookstove projects is a very manual and error-prone process due to distributed nature of project. Often, a sample group of households are selected to be monitored and results are extrapolated for all the households(in thousands) leading to over crediting. Since this methodology focuses on having direct measurement devices associated with a stove, an automated way of monitoring is possible.
diff --git a/docs/guardian/demo-guide/carbon-offsets/verra-redd+-demo-guide.md b/docs/guardian/demo-guide/carbon-offsets/verra-redd+-demo-guide.md index b580beab86..cd0d8094f5 100644 --- a/docs/guardian/demo-guide/carbon-offsets/verra-redd+-demo-guide.md +++ b/docs/guardian/demo-guide/carbon-offsets/verra-redd+-demo-guide.md @@ -94,7 +94,7 @@ After creating the group, we will see the New Project button. When we click on t
{% hint style="info" %} -Note: If there are more than one VVB, we need atleast 70% consensus to get the finalized decision on the Project to proceed. +Note: If there are more than one VVB, we need at least 70% consensus to get the finalized decision on the Project to proceed. {% endhint %} 16\. Once the Project is validated, we log out as VVB and login as Project Proponent. Monitoring Report details should be added by clicking on Add Report diff --git a/docs/guardian/demo-guide/renewable-energy-credits/irec-7-demo-guide.md b/docs/guardian/demo-guide/renewable-energy-credits/irec-7-demo-guide.md index dc3eb44cf0..4e71eb23fa 100644 --- a/docs/guardian/demo-guide/renewable-energy-credits/irec-7-demo-guide.md +++ b/docs/guardian/demo-guide/renewable-energy-credits/irec-7-demo-guide.md @@ -62,6 +62,6 @@ Once device details are entered, they are submitted for approval.
-13\. To view the trustchain, we need to click on View Trustchain in Token Histroy tab or Trustchain tab. +13\. To view the trustchain, we need to click on View Trustchain in Token History tab or Trustchain tab.
diff --git a/docs/guardian/faqs.md b/docs/guardian/faqs.md index 0b3ddb7e21..b62c0efb51 100644 --- a/docs/guardian/faqs.md +++ b/docs/guardian/faqs.md @@ -73,7 +73,7 @@ We are uploading Verifiable Presentation document to IPFS and CID will be attach (ONLY NFT) Open tokens page, click on appropriate token or open ledger works explorer manually https://explore.lworks.io/testnet/tokens/{tokenId} ([https://explore.lworks.io/testnet/tokens/0.0.4554172](https://explore.lworks.io/testnet/tokens/0.0.4554172)), open "NFT HOLDERS" tab and click on appropriate serial, click on "OVERVIEW" tab and in metadata you can get VP message identifier (1721049137.243457003). \ -(FT, NFT) Open tokens page, copy appropriate token identifier, open dragonglass explorer https://testnet.dragonglass.me/tokens/{tokenId} ([https://testnet.dragonglass.me/tokens/0.0.4554298](https://testnet.dragonglass.me/tokens/0.0.4554298)), click on "All transactions" tab, click on appropriate mint transaction, in memo you can get VP message identifier (1721049808.933544003). +(FT, NFT) Open tokens page, copy appropriate token identifier, open Dragonglass explorer https://testnet.dragonglass.me/tokens/{tokenId} ([https://testnet.dragonglass.me/tokens/0.0.4554298](https://testnet.dragonglass.me/tokens/0.0.4554298)), click on "All transactions" tab, click on appropriate mint transaction, in memo you can get VP message identifier (1721049808.933544003). \ In our case it will be [https://testnet.mirrornode.hedera.com/api/v1/topics/messages/1721049137.243457003](https://testnet.mirrornode.hedera.com/api/v1/topics/messages/1721049137.243457003)\ diff --git a/docs/guardian/project-account-relayer-account/demo-using-ui.md b/docs/guardian/project-account-relayer-account/demo-using-ui.md index 64dfa3b4e3..0c5e35c79f 100644 --- a/docs/guardian/project-account-relayer-account/demo-using-ui.md +++ b/docs/guardian/project-account-relayer-account/demo-using-ui.md @@ -27,7 +27,7 @@ To add an existing account, the account name, the Hedera account ID, and its pri It is also possible to create a new Hedera account and set it up as one of the relayer account for the user. {% hint style="info" %} -Note 1: hbar balance of the new account would be 0 and would need to be toped-up (externally to Guardian) for the account to become useable. +Note 1: hbar balance of the new account would be 0 and would need to be topped-up (externally to Guardian) for the account to become usable. {% endhint %}
diff --git a/docs/guardian/readme/environments/dynamic-vault-kms-path-configuration-according-to-the-environment.md b/docs/guardian/readme/environments/dynamic-vault-kms-path-configuration-according-to-the-environment.md index 3d49b86cf6..161ea5113a 100644 --- a/docs/guardian/readme/environments/dynamic-vault-kms-path-configuration-according-to-the-environment.md +++ b/docs/guardian/readme/environments/dynamic-vault-kms-path-configuration-according-to-the-environment.md @@ -2,7 +2,7 @@ Guardian platform manage to segregate secret data basing on the variables defined in the ecosystem environment. As in the database case the two variables leveraged to discriminate secret storage are the GUARDIAN\_ENV and HEDERA\_NET variables. -Each KMS use slight different approach to naming convention of holded secret. The KMS has to be configured with this two dimension(GUARDIAN\_ENV and HEDERA\_NET) and insert them in the secret name, in the Roles name and in the Policies that define the access rules to that secret. +Each KMS use slight different approach to naming convention of held secret. The KMS has to be configured with this two dimension(GUARDIAN\_ENV and HEDERA\_NET) and insert them in the secret name, in the Roles name and in the Policies that define the access rules to that secret. Guardian has adopted a specialized adapter to interact with secret managers. To implement the data separation each specialized adapter instance adds a two dimensional prefix GUARDIAN\_ENV and HEDERA\_NET to the PATH or NAME that identifies the secret, so that the adapter is aware of the MultiEnvironment. @@ -82,7 +82,7 @@ if not present the variables are inserted only in the 4 services: auth-service, * **Step 8** start Guardian as usual -For Hashicorpp Vault the secret multi-environment naming convention defined in the Vault by the execution of the script is going to be: +For Hashicorp Vault the secret multi-environment naming convention defined in the Vault by the execution of the script is going to be: ``` / / diff --git a/docs/guardian/readme/environments/ecosystem-environments.md b/docs/guardian/readme/environments/ecosystem-environments.md index 7d3fb20993..829d084b78 100644 --- a/docs/guardian/readme/environments/ecosystem-environments.md +++ b/docs/guardian/readme/environments/ecosystem-environments.md @@ -1,8 +1,8 @@ # Ecosystem Environments -The set of environment parameters represent the context in which a service is executed. Each service needs to know this context to adapt its behavour to the real working condition. At the service level the node .env library allows to read environment of the kind \ this library by default reads from .env file. The data are reads in a process .environment data structure available in the execution context of Node process. A unique file defines the environment and keeps the responsibility to create the shared operative ecosystem. +The set of environment parameters represent the context in which a service is executed. Each service needs to know this context to adapt its behaviour to the real working condition. At the service level the node .env library allows to read environment of the kind \ this library by default reads from .env file. The data are reads in a process .environment data structure available in the execution context of Node process. A unique file defines the environment and keeps the responsibility to create the shared operative ecosystem. -All Guardian Micro-services share a common set of Environment variables. In this way, Guardian can be seen as an ecosystem with several services and common set of parameters leading his behavour. This environment parameters are shared between all the services of the Guardian ecosystem. All variables are defined in a `.env..guardian.system` file. The file name is parametric so it is possible to define a different files for different possible running configuration, for example production, develop, test1. The ecosystem environment file follow the .env.template.guardian.system file that let write new configurations with the set of necessary variables. Both the template file and the resulting environments files are in the folder `./configs/`, they can be discriminated by its name to spread the session. +All Guardian Micro-services share a common set of Environment variables. In this way, Guardian can be seen as an ecosystem with several services and common set of parameters leading his behaviour. This environment parameters are shared between all the services of the Guardian ecosystem. All variables are defined in a `.env..guardian.system` file. The file name is parametric so it is possible to define a different files for different possible running configuration, for example production, develop, test1. The ecosystem environment file follow the .env.template.guardian.system file that let write new configurations with the set of necessary variables. Both the template file and the resulting environments files are in the folder `./configs/`, they can be discriminated by its name to spread the session. The parameter GUARDIAN\_ENV is defined univocally in an `.env` file. The containers orchestration will be responsible to push the environment in to the container in a way the environment will be available to the Node server. For example in the execution of Guardian using docker compose tool the tool inject the environment in each container. Docker compose push the environment in the container by the means of the env-file attribute and the environment attribute. Environment attribute can be parametrized using the variables defined in the `.env` file located next to the docker\_compose.yaml this paramenter is used to select the file to read the environment variables from. All the variables defined in the file will be loaded in the container environment and be available to Node. diff --git a/docs/guardian/readme/getting-started/how-to-restore-account-from-database-hashicorp-vault-during-setup.md b/docs/guardian/readme/getting-started/how-to-restore-account-from-database-hashicorp-vault-during-setup.md index 4252ca3101..89221f6ff2 100644 --- a/docs/guardian/readme/getting-started/how-to-restore-account-from-database-hashicorp-vault-during-setup.md +++ b/docs/guardian/readme/getting-started/how-to-restore-account-from-database-hashicorp-vault-during-setup.md @@ -8,7 +8,7 @@ Mongo DB databases set in .env (.env.docker) files or via environment variables * auth-service - auth\_db * guardian-service - guardian\_db -* logger-service (not nesessary) - logger\_db +* logger-service (not necessary) - logger\_db Example using mongo utils: @@ -28,6 +28,6 @@ mongorestore --db guardian_db ./dump/guardian_db mongorestore --db logger_db ./dump/logger_db ``` -#### Hashicorp Vault: +#### HashiCorp Vault: -For Hashicorp vault backup and restore use this instructions: [https://developer.hashicorp.com/vault/tutorials/standard-procedures/sop-backup](https://developer.hashicorp.com/vault/tutorials/standard-procedures/sop-backup) +For HashiCorp vault backup and restore use this instructions: [https://developer.hashicorp.com/vault/tutorials/standard-procedures/sop-backup](https://developer.hashicorp.com/vault/tutorials/standard-procedures/sop-backup) diff --git a/docs/guardian/readme/getting-started/installation/backup-tools.md b/docs/guardian/readme/getting-started/installation/backup-tools.md index 71fdf7ea20..175ba1c217 100644 --- a/docs/guardian/readme/getting-started/installation/backup-tools.md +++ b/docs/guardian/readme/getting-started/installation/backup-tools.md @@ -355,7 +355,7 @@ Finally, we use the child\_process.spawn method to run the duplicity command as Backups are an important part of application development. In order to ensure this feature in the Guardian application the following steps could be taken if you want to save the backups in the Amazon S3. This [repository](https://github.com/IntellectEU/nodejs-app-backup) contains an example of how to simulate in detail the process to backup the mongodb collections and .env files. The same could be applied to the Guardian application. 1. Create a new folder called backup in the root folder of the Guardian Application. -2. Change the current docker-compose.yml addin this service: +2. Change the current docker-compose.yml in this service: ``` backup: diff --git a/docs/guardian/readme/getting-started/installation/building-from-source-and-run-using-docker/README.md b/docs/guardian/readme/getting-started/installation/building-from-source-and-run-using-docker/README.md index 6910b52ff4..43fc87ee96 100644 --- a/docs/guardian/readme/getting-started/installation/building-from-source-and-run-using-docker/README.md +++ b/docs/guardian/readme/getting-started/installation/building-from-source-and-run-using-docker/README.md @@ -169,7 +169,7 @@ For each service, you must add its secret key \`SERVICE\_JWT\_SECRET\_KEY\` and {% endhint %} {% hint style="info" %} -Note: Please use the appropriate Private Key and Public Key as shown in the above iimage. +Note: Please use the appropriate Private Key and Public Key as shown in the above image. {% endhint %} ## 4. Setup IPFS diff --git a/docs/guardian/readme/getting-started/installation/cloud-deployment.md b/docs/guardian/readme/getting-started/installation/cloud-deployment.md index bc48b460ed..79a8fb1dd0 100644 --- a/docs/guardian/readme/getting-started/installation/cloud-deployment.md +++ b/docs/guardian/readme/getting-started/installation/cloud-deployment.md @@ -84,7 +84,7 @@ kubectl --kubeconfig KUBECONFIG-FILE -n ingress-nginx get svc -o wide ``` -You can also find the load balancer using your cloud privider console. The domain name configuration and, DNS records and TLS certificates with SSL termination on the load balancer are out of the scope of this document. +You can also find the load balancer using your cloud provider console. The domain name configuration and, DNS records and TLS certificates with SSL termination on the load balancer are out of the scope of this document. #### Guardian manifests @@ -163,7 +163,7 @@ These are third party services that are not part of the Guardian platform, but a * mongo * ipfs/kubo * message-broker -* hashicorp vault +* HashiCorp vault * mongo-express For production workloads it is recommended to use a more robust setup for these services, like a replica set for mongo, a cluster for ipfs, a cluster for the message broker, etc. Navigating to the Apps section of Rancher, you can find the official [Helm](https://helm.sh/) charts for these services, with Rancher support, which can be used to deploy them in a more robust way. As an example, you can follow the steps below to deploy a message broker cluster using the Rancher UI, you'll see something similar to this: diff --git a/docs/guardian/readme/getting-started/installation/upgrading.md b/docs/guardian/readme/getting-started/installation/upgrading.md index cea7556cc3..c3aadd21d9 100644 --- a/docs/guardian/readme/getting-started/installation/upgrading.md +++ b/docs/guardian/readme/getting-started/installation/upgrading.md @@ -287,7 +287,7 @@ The Data mapping document describes the model for the data migration. The docume * **Data reduction and filtering** (splitting to several collections). * **Data views:** to allow the maintenance of DAO contracts during Data reduction. -The canvas Itself provides the framework in which the data belongs. Overmore the document should: +The canvas Itself provides the framework in which the data belongs. Furthermore, the document should: * Map every data to User Functionality (Rest API) that involves that data. * Map every data to message data flows to realize the functionality. @@ -338,7 +338,7 @@ The following information is contained in the table: Architects recommend the use of “separation of concerns”: strong internal cohesion in each microservice and loose coupling microservices should be grouped according to their problem domain. -Architects need to have a strong understanding of the relation between impacted use cases and backend data flows in a way to always map use case modification in backend microservices upgrading and know how data modification impacts interservices messages between consumer and produced services and their APIs. +Architects need to have a strong understanding of the relation between impacted use cases and backend data flows in a way to always map use case modification in backend microservices upgrading and know how data modification impacts inter-service messages between consumer and produced services and their APIs. A service here has the sole authority over its data and exposes operations to other services. diff --git a/docs/guardian/readme/roadmap.md b/docs/guardian/readme/roadmap.md index d5fd0e3faf..1997d61b9a 100644 --- a/docs/guardian/readme/roadmap.md +++ b/docs/guardian/readme/roadmap.md @@ -1,6 +1,6 @@ # Roadmap -
FeatureRelease monthDevelop branch?Released?Release Version
Development of AMS-I.E and Mass Comparison on CookstoveJuly 2024YesYes2.27
Indexer APIJuly 2024YesYes2.27
Development of VMR0006July 2024YesYes2.27
Filtering data for blocks is stateful API, introduce stateless data filters for API usage.July 2024YesYes2.27
Auto-testing community submitted policiesOctober 2024YesYes3.0
Code audit: support and resolution of issuesOctober 2024YesYes3.0
GHG Scorecards ResearchOctober 2024YesYes3.0
Token action block to work with token templatesOctober 2024YesYes3.0
Different token IDs for different projects by the same policyOctober 2024YesYes3.0
Enhance MongoDB IntegrationOctober 2024YesYes3.0
Leverage the pre-built images as the default way to start Guardian locallyOctober 2024YesYes3.0
Global Carbon Council (GCC) GCCM001October 2024YesYes3.0
Default values for schema-defined fieldsOctober 2024YesYes3.0
Rationalize API and UI return error codesOctober 2024YesYes3.0
Simplify default SR schema to take out optional propertiesOctober 2024YesYes3.0
Guardian analytics: bottom-up data traceabilityOctober 2024YesYes3.0
API versioning and support/deprecation scheduleOctober 2024YesYes3.0
Data Parameterization and Conditional Review LogicOctober 2024YesYes3.0
Calculation logic for values in 'automatic fields' in schemasOctober 2024YesYes3.0
Verify and Fix the features that got affected by Mirror node changesOctober 2024YesYes3.0
Climate Action Reserve's U.S. Landfill ProtocolJanuary 2025YesYes3.1
Scope 3/PCF Referencing Demo (Methodology Breakdown)January 2025YesYes3.1
Development of AMS-I.CJanuary 2025YesYes3.1
API facilities to retrieve unique references (IDs) of results for API-triggered operationsJanuary 2025YesYes3.1
Guardian analytics: labels and top down data way pointsJanuary 2025YesYes3.1
Trustchain support for contract-based issuance and retirement implementationJanuary 2025YesYes3.1
GHGP Version 3January 2025YesYes3.1
Enhancements and Bugs of IndexerJanuary 2025YesYes3.1
Formula Linked Definitions & Schema Tree EnhancementJanuary 2025YesYes3.1
Dry-run policy execution 'savepoints' - restart policy dry-run from the list of 'saved' placesJanuary 2025YesYes3.1
Standardize UI on Angular Material, remove/replace PrimeNGJanuary 2025YesYes3.1
Enhancing Research on Indexer and Analytics Use CasesJanuary 2025YesYes3.1
Add policy support for more than one external data blockMay 2025YesYes3.2
Firing external event when minting process is finishedMay 2025YesYes3.2
Establish deprecation policy for architectural APIsMay 2025YesYes3.2
Cross-context (API+UI) refresh token invalidation (regression from v2.18.0)May 2025YesYes3.2
Business UseCase for Emissions Reduction/Removals (ERRs)Calculation Pre-Calculator in GuardianMay 2025YesYes3.2
Add capabilities to display complex geoJSON shapes superimposed on mapsMay 2025YesYes3.2
Weak Default configurationMay 2025YesYes3.2
System Logs Accessible by All RegistriesMay 2025YesYes3.2
Development of VM0042 v2.1: Improved Agricultural Land ManagementMay 2025YesYes3.2
Manual trigger of re-indexing for specific policy, SR, tokenMay 2025YesYes3.2
Article 6.4 Forms ResearchMay 2025YesYes3.2
Session Token in URLMay 2025YesYes3.2
Accessing a Guardian policy from a Guardian instance other than the publishing instanceMay 2025YesYes3.2
Exporting Project Data in CSV formatJuly 2025YesYes3.3
Missing Authentication between ServicesJuly 2025YesYes3.3
Server-Side Request Forgery (SSRF) in Request Data moduleJuly 2025YesYes3.3
No Password PolicyJuly 2025YesYes3.3
Development of VM0033July 2025YesYes3.3
Detailed Research on Indexer EnhancementsJuly 2025YesYes3.3
Guardian policy embedded code testing/debugging facility for Custom Logic, Calculate, etc blocksJuly 2025YesYes3.3
Substitute Google maps API in Guardian UI with an OSS alternativeJuly 2025YesYes3.3
Outdated Software/LibrariesJuly 2025YesYes3.3
Identifying, Implementing and Integrating 3rd Party data resourcesJuly 2025YesYes3.3
Authorization Headers Potentially Leaked through IPFS in Request Data ModuleJuly 2025YesYes3.3
Facilities to use specialist math tooling (such as R language) for calculatio
ns in Guardian Policies .		July 2025YesYes3.3
Payload Shapefile IngestionAugust 2025YesYes3.4
Improvement in the error handling for excel schema exportsAugust 2025YesYes3.4
Dry-run savepoint[s] to survive exit and policy editingAugust 2025YesYes3.4
Locations Data Field enhancementAugust 2025YesYes3.4
SLA Ticket Import and Policy Publish Performance in GuardianAugust 2025YesYes3.4
Validation for project data submissionSeptember 2025YesYes3.4
Guardian Form UI ImprovementsSeptember 2025YesYes3.4
Add an option to hide some buttons in case the policy is discontinuedSeptember 2025YesYes3.4
Make testing easier for subflowsSeptember 2025YesYes3.4
Complex iterative review and approval workflows​October 2025YesYes3.4
Policy warningsOctober 2025YesYes3.4
Import Excel to check for duplicates by schema name​October 2025YesYes3.4
Project (Relayer) Account (ex:Project Developer or Accountable Impact Organization)October 2025YesYes3.4
Nested schemas for complex conditionsOctober 2025YesYes3.4
Need to implement best practices on Schema CycleOctober 2025YesYes3.4
Update Walkthroughs in DocumentationOctober 2025YesYes3.4
Schema deletion with child schemasOctober 2025YesYes3.4
Capability to retire tokens by serial numberOctober 2025YesYes3.4
Option to delete all schemas for a particular policy in Draft stage​October 2025YesYes3.4
Next phase of 'Tools' evolution in Guardian PoliciesNovember 2025YesYes3.5
Implementing Artifacts such as Schemas/Policies/tokens Deletion all at once​November 2025YesYes3.5
Graphical View of formula linked definitionsNovember 2025YesYes3.5
Capture/replay and compare data of published policiesNovember 2025YesYes3.5
Formula-linked definitions enhancements​November 2025YesYes3.5
Guardian as a multi-workflow engine for independent data streams​December 2025YesYes3.5
Tamper-resistant Policy and Module export/importDecember 2025YesYes3.5
Data Entry UpdatabilityDecember 2025YesYes3.5
Fine grained Policy workflow certification labels​January 2026YesYes3.5
Extend Policy definition language to include a Formula calculations block​January 2026YesYes3.5
Deterministic CompressionJanuary 2026YesYes3.5
Add API endpoint to generate example payloads matching UI auto-fill logicJanuary 2026YesYes3.5
Add Support for Synchronous Event ExecutionJanuary 2026YesYes3.5
Implement Form View for Image TagsJanuary 2026YesYes3.5
Improve schema version handlingJanuary 2026YesYes3.5
Enable the "Publish" button only when the policy version is correctJanuary 2026YesYes3.5
UI Ticket — Pop-Up Window Size Too Small for Data EntryFebruary 2026YesYes3.5
UI Ticket — Add Tables to Improve Data EntryFebruary 2026YesYes3.5
UI Ticket — ERR Table Display: No Ability to See Tables for Summarized InformationFebruary 2026YesYes3.5
Main Framework Schema Design for GHGP v3February 2026Yes
Improvements for Data Migration Tool – Progress Tracking & Large Load ReliabilityFebruary 2026Yes
UI Ticket — Add Navigation Panel to Jump Between SectionsFebruary 2026Yes
Redesign of the Hedera network configurationFebruary 2026Yes
Embed gitbook documentation assistant into GuardianFebruary 2026Yes
Disconnect functionality for Decentralized featureFebruary 2026Yes
Improving Naming Conventions of the Features in DocumentationMarch 2026
Guardian UI improvementsMarch 2026
API documentation improvementsMarch 2026
Guardian Policy Development for VM0047 (Afforestation, Reforestation, and Revegetation v1.1)March 2026
DR: policy state 'save points' capability to be restarted from for restore operationsMarch 2026
Revised documentation on Formula linked definitions featureMarch 2026
Initial Toolbox Schema Design for GHGP v3March 2026
Top-level (generic) API calls for common tasksApril 2026
Create Guardian UI terminology 'dictionary'April 2026
Review the list of Blocks documentationApril 2026
Add filter/search option in schemas with their IDApril 2026
Configurable rounding strategy for the token minting processApril 2026
feat: user managed credentials for external servicesApril 2026
Create external event for "token failed"April 2026
VM0049 Carbon Capture and Storage, v1.0*May 2026
Enhance diff and search to be less (ideally in-) sensitive to the order of schemas/fieldsMay 2026
feat: dry-run external servicesMay 2026
Not able to revert back after selecting a role in the policy workflow​May 2026
Impossible to change policy binding for schemasMay 2026
Creating and assigning sub schemasMay 2026
Disabling the option to rebind the policy in created schemaMay 2026
Manual input of additional data for inclusion into the VC documentMay 2026
Add the ability to create any type of user in production environment using Guardian UIMay 2026
Export Schema Tree and Tree Diagrams in editable UML format such as Plant UMLMay 2026
Use {cid} as a placeholder for IPFS_PUBLIC_GATEWAY environment variable instead of ${cid}May 2026
Support the Development of GHGP v3June 2026
Make the build process of docker images fasterJune 2026
Extend the Python libraries supported by GuardianJune 2026
Review the current list of supported Python librariesJune 2026
Granular global search/diff matching arbitrary policy block subtreesJune 2026
Multi-Factor Authentication Not SupportedJune 2026
Need a placeholder code to write expressions within Schema UI on importJune 2026
Confusing 'not working' button - grey it out until the action is possibleJune 2026
Refreshing of available filter state on Guardian (Potential Caching Issue)​June 2026
Add Worker Tasks to the permission modalJune 2026
Development of AMS-II.J.: Demand-side activities for efficient lighting technologies --- Version 8.0*June 2026
Duplicate validation during ImportJuly 2026
Support for Multi-Strata Schema Fields, Auto-Calculation Enhancements, and Improved Schema–UI IntegrationJuly 2026
UI/UX enhancementsJuly 2026
Testing and Piloting GHGP v3July 2026
Development of VM0050: Energy Efficiency and Fuel-Switch Measures in Cookstoves, v1.0*
Development of AMS-II.C: Demand-side energy efficiency activities for specific technologies*
Development of VM0045: Improved Forest Management Using Dynamic Matched Baselines from National Forest Inventories, v1.2*
Development of AR-ACM0003 : Afforestation and reforestation of lands except wetlands - Version 2.0*
Development of VM0051 : Improved Management in Rice Production Systems, v1.0*
Development of ACM0022: Alternative waste treatment processes --- Version 3.0*
Development of AMS-III.C.: Emission reductions by electric and hybrid vehicles --- Version 16.0*
Development of AMS-III.F.: Avoidance of methane emissions through controlled biological treatment of biomass --- Version 8.0*
Development of VM0008 Weatherization of Single Family and Multi-Family Buildings, v1.2*
Development of VM0043 CO2 Utilization in Concrete Production, v1.1*
Development of VM0041 Methodology for the Reduction of Enteric Methane Emissions from Ruminants through the Use of Feed Ingredients, v2.0*
Development of VM0044 Biochar Utilization in Soil and Non-Soil Applications, v1.2*
Development of ACM0008: Abatement of methane from coal mines --- Version 8.0*
Development of ACM0009: Fuel switching from coal or petroleum fuel to natural gas --- Version 5.0*
+
FeatureRelease monthDevelop branch?Released?Release Version
Development of AMS-I.E and Mass Comparison on CookstoveJuly 2024YesYes2.27
Indexer APIJuly 2024YesYes2.27
Development of VMR0006July 2024YesYes2.27
Filtering data for blocks is stateful API, introduce stateless data filters for API usage.July 2024YesYes2.27
Auto-testing community submitted policiesOctober 2024YesYes3.0
Code audit: support and resolution of issuesOctober 2024YesYes3.0
GHG Scorecards ResearchOctober 2024YesYes3.0
Token action block to work with token templatesOctober 2024YesYes3.0
Different token IDs for different projects by the same policyOctober 2024YesYes3.0
Enhance MongoDB IntegrationOctober 2024YesYes3.0
Leverage the pre-built images as the default way to start Guardian locallyOctober 2024YesYes3.0
Global Carbon Council (GCC) GCCM001October 2024YesYes3.0
Default values for schema-defined fieldsOctober 2024YesYes3.0
Rationalize API and UI return error codesOctober 2024YesYes3.0
Simplify default SR schema to take out optional propertiesOctober 2024YesYes3.0
Guardian analytics: bottom-up data traceabilityOctober 2024YesYes3.0
API versioning and support/deprecation scheduleOctober 2024YesYes3.0
Data Parameterization and Conditional Review LogicOctober 2024YesYes3.0
Calculation logic for values in 'automatic fields' in schemasOctober 2024YesYes3.0
Verify and Fix the features that got affected by Mirror node changesOctober 2024YesYes3.0
Climate Action Reserve's U.S. Landfill ProtocolJanuary 2025YesYes3.1
Scope 3/PCF Referencing Demo (Methodology Breakdown)January 2025YesYes3.1
Development of AMS-I.CJanuary 2025YesYes3.1
API facilities to retrieve unique references (IDs) of results for API-triggered operationsJanuary 2025YesYes3.1
Guardian analytics: labels and top down data way pointsJanuary 2025YesYes3.1
Trustchain support for contract-based issuance and retirement implementationJanuary 2025YesYes3.1
GHGP Version 3January 2025YesYes3.1
Enhancements and Bugs of IndexerJanuary 2025YesYes3.1
Formula Linked Definitions & Schema Tree EnhancementJanuary 2025YesYes3.1
Dry-run policy execution 'savepoints' - restart policy dry-run from the list of 'saved' placesJanuary 2025YesYes3.1
Standardize UI on Angular Material, remove/replace PrimeNGJanuary 2025YesYes3.1
Enhancing Research on Indexer and Analytics Use CasesJanuary 2025YesYes3.1
Add policy support for more than one external data blockMay 2025YesYes3.2
Firing external event when minting process is finishedMay 2025YesYes3.2
Establish deprecation policy for architectural APIsMay 2025YesYes3.2
Cross-context (API+UI) refresh token invalidation (regression from v2.18.0)May 2025YesYes3.2
Business UseCase for Emissions Reduction/Removals (ERRs)Calculation Pre-Calculator in GuardianMay 2025YesYes3.2
Add capabilities to display complex geoJSON shapes superimposed on mapsMay 2025YesYes3.2
Weak Default configurationMay 2025YesYes3.2
System Logs Accessible by All RegistriesMay 2025YesYes3.2
Development of VM0042 v2.1: Improved Agricultural Land ManagementMay 2025YesYes3.2
Manual trigger of re-indexing for specific policy, SR, tokenMay 2025YesYes3.2
Article 6.4 Forms ResearchMay 2025YesYes3.2
Session Token in URLMay 2025YesYes3.2
Accessing a Guardian policy from a Guardian instance other than the publishing instanceMay 2025YesYes3.2
Exporting Project Data in CSV formatJuly 2025YesYes3.3
Missing Authentication between ServicesJuly 2025YesYes3.3
Server-Side Request Forgery (SSRF) in Request Data moduleJuly 2025YesYes3.3
No Password PolicyJuly 2025YesYes3.3
Development of VM0033July 2025YesYes3.3
Detailed Research on Indexer EnhancementsJuly 2025YesYes3.3
Guardian policy embedded code testing/debugging facility for Custom Logic, Calculate, etc blocksJuly 2025YesYes3.3
Substitute Google maps API in Guardian UI with an OSS alternativeJuly 2025YesYes3.3
Outdated Software/LibrariesJuly 2025YesYes3.3
Identifying, Implementing and Integrating 3rd Party data resourcesJuly 2025YesYes3.3
Authorization Headers Potentially Leaked through IPFS in Request Data ModuleJuly 2025YesYes3.3
Facilities to use specialist math tooling (such as R language) for calculations in Guardian Policies .July 2025YesYes3.3
Payload Shapefile IngestionAugust 2025YesYes3.4
Improvement in the error handling for excel schema exportsAugust 2025YesYes3.4
Dry-run savepoint[s] to survive exit and policy editingAugust 2025YesYes3.4
Locations Data Field enhancementAugust 2025YesYes3.4
SLA Ticket Import and Policy Publish Performance in GuardianAugust 2025YesYes3.4
Validation for project data submissionSeptember 2025YesYes3.4
Guardian Form UI ImprovementsSeptember 2025YesYes3.4
Add an option to hide some buttons in case the policy is discontinuedSeptember 2025YesYes3.4
Make testing easier for subflowsSeptember 2025YesYes3.4
Complex iterative review and approval workflows​October 2025YesYes3.4
Policy warningsOctober 2025YesYes3.4
Import Excel to check for duplicates by schema name​October 2025YesYes3.4
Project (Relayer) Account (ex:Project Developer or Accountable Impact Organization)October 2025YesYes3.4
Nested schemas for complex conditionsOctober 2025YesYes3.4
Need to implement best practices on Schema CycleOctober 2025YesYes3.4
Update Walkthroughs in DocumentationOctober 2025YesYes3.4
Schema deletion with child schemasOctober 2025YesYes3.4
Capability to retire tokens by serial numberOctober 2025YesYes3.4
Option to delete all schemas for a particular policy in Draft stage​October 2025YesYes3.4
Next phase of 'Tools' evolution in Guardian PoliciesNovember 2025YesYes3.5
Implementing Artifacts such as Schemas/Policies/tokens Deletion all at once​November 2025YesYes3.5
Graphical View of formula linked definitionsNovember 2025YesYes3.5
Capture/replay and compare data of published policiesNovember 2025YesYes3.5
Formula-linked definitions enhancements​November 2025YesYes3.5
Guardian as a multi-workflow engine for independent data streams​December 2025YesYes3.5
Tamper-resistant Policy and Module export/importDecember 2025YesYes3.5
Data Entry UpdatabilityDecember 2025YesYes3.5
Fine grained Policy workflow certification labels​January 2026YesYes3.5
Extend Policy definition language to include a Formula calculations block​January 2026YesYes3.5
Deterministic CompressionJanuary 2026YesYes3.5
Add API endpoint to generate example payloads matching UI auto-fill logicJanuary 2026YesYes3.5
Add Support for Synchronous Event ExecutionJanuary 2026YesYes3.5
Implement Form View for Image TagsJanuary 2026YesYes3.5
Improve schema version handlingJanuary 2026YesYes3.5
Enable the "Publish" button only when the policy version is correctJanuary 2026YesYes3.5
UI Ticket — Pop-Up Window Size Too Small for Data EntryFebruary 2026YesYes3.5
UI Ticket — Add Tables to Improve Data EntryFebruary 2026YesYes3.5
UI Ticket — ERR Table Display: No Ability to See Tables for Summarized InformationFebruary 2026YesYes3.5
Main Framework Schema Design for GHGP v3February 2026Yes
Improvements for Data Migration Tool – Progress Tracking & Large Load ReliabilityFebruary 2026Yes
UI Ticket — Add Navigation Panel to Jump Between SectionsFebruary 2026Yes
Redesign of the Hedera network configurationFebruary 2026Yes
Embed gitbook documentation assistant into GuardianFebruary 2026Yes
Disconnect functionality for Decentralized featureFebruary 2026Yes
Improving Naming Conventions of the Features in DocumentationMarch 2026
Guardian UI improvementsMarch 2026
API documentation improvementsMarch 2026
Guardian Policy Development for VM0047 (Afforestation, Reforestation, and Revegetation v1.1)March 2026
DR: policy state 'save points' capability to be restarted from for restore operationsMarch 2026
Revised documentation on Formula linked definitions featureMarch 2026
Initial Toolbox Schema Design for GHGP v3March 2026
Top-level (generic) API calls for common tasksApril 2026
Create Guardian UI terminology 'dictionary'April 2026
Review the list of Blocks documentationApril 2026
Add filter/search option in schemas with their IDApril 2026
Configurable rounding strategy for the token minting processApril 2026
feat: user managed credentials for external servicesApril 2026
Create external event for "token failed"April 2026
VM0049 Carbon Capture and Storage, v1.0*May 2026
Enhance diff and search to be less (ideally in-) sensitive to the order of schemas/fieldsMay 2026
feat: dry-run external servicesMay 2026
Not able to revert back after selecting a role in the policy workflow​May 2026
Impossible to change policy binding for schemasMay 2026
Creating and assigning sub schemasMay 2026
Disabling the option to rebind the policy in created schemaMay 2026
Manual input of additional data for inclusion into the VC documentMay 2026
Add the ability to create any type of user in production environment using Guardian UIMay 2026
Export Schema Tree and Tree Diagrams in editable UML format such as Plant UMLMay 2026
Use {cid} as a placeholder for IPFS_PUBLIC_GATEWAY environment variable instead of ${cid}May 2026
Support the Development of GHGP v3June 2026
Make the build process of docker images fasterJune 2026
Extend the Python libraries supported by GuardianJune 2026
Review the current list of supported Python librariesJune 2026
Granular global search/diff matching arbitrary policy block subtreesJune 2026
Multi-Factor Authentication Not SupportedJune 2026
Need a placeholder code to write expressions within Schema UI on importJune 2026
Confusing 'not working' button - grey it out until the action is possibleJune 2026
Refreshing of available filter state on Guardian (Potential Caching Issue)​June 2026
Add Worker Tasks to the permission modalJune 2026
Development of AMS-II.J.: Demand-side activities for efficient lighting technologies --- Version 8.0*June 2026
Duplicate validation during ImportJuly 2026
Support for Multi-Strata Schema Fields, Auto-Calculation Enhancements, and Improved Schema–UI IntegrationJuly 2026
UI/UX enhancementsJuly 2026
Testing and Piloting GHGP v3July 2026
Development of VM0050: Energy Efficiency and Fuel-Switch Measures in Cookstoves, v1.0*
Development of AMS-II.C: Demand-side energy efficiency activities for specific technologies*
Development of VM0045: Improved Forest Management Using Dynamic Matched Baselines from National Forest Inventories, v1.2*
Development of AR-ACM0003 : Afforestation and reforestation of lands except wetlands - Version 2.0*
Development of VM0051 : Improved Management in Rice Production Systems, v1.0*
Development of ACM0022: Alternative waste treatment processes --- Version 3.0*
Development of AMS-III.C.: Emission reductions by electric and hybrid vehicles --- Version 16.0*
Development of AMS-III.F.: Avoidance of methane emissions through controlled biological treatment of biomass --- Version 8.0*
Development of VM0008 Weatherization of Single Family and Multi-Family Buildings, v1.2*
Development of VM0043 CO2 Utilization in Concrete Production, v1.1*
Development of VM0041 Methodology for the Reduction of Enteric Methane Emissions from Ruminants through the Use of Feed Ingredients, v2.0*
Development of VM0044 Biochar Utilization in Soil and Non-Soil Applications, v1.2*
Development of ACM0008: Abatement of methane from coal mines --- Version 8.0*
Development of ACM0009: Fuel switching from coal or petroleum fuel to natural gas --- Version 5.0*
**Note: The above items marked as "\*"are subject to change.** @@ -372,7 +372,7 @@ Referral Link: [https://github.com/hashgraph/guardian/issues/3730](https://githu * Tool 07- Tool to calculate the emission factor for an electricity system * Tool 09- Determining the baseline efficiency of thermal or electric energy generation systems * Tool 12- Project and leakage emissions from transportation of freight - * Tool 16- Project and leakage emissions from biomas + * Tool 16- Project and leakage emissions from biomass * Tool 19- Demonstration of additionality of microscale project activities * Tool 21- Demonstration of additionality of small-scale project activities  * Tool 22- Leakage in biomass small-scale project activities @@ -433,7 +433,7 @@ Referral Link: [https://github.com/hashgraph/guardian/issues/3525](https://githu **Business UseCase for Emissions Reduction/Removals (ERRs)Calculation Pre-Calculator in Guardian** -We are in the process of creating a few approaches to this ticket from the business use case perspective. One is essentially an “estimator” with a simplified workflow that can be used to estimate emission reductions, token issuance, etc. upfront to help the user better anticipate issuances and the impacts of various project activities and methodological choices. The other is more of a “summary preview” of the actual calculation results, that can be implemented just before validation (or anytime thereafter) to see summary KPIs based on the actual inputs and methodological choices made by the user, and they can then interact with the data like the Nerd Wallet retirement calculator to see how changes to the project activities could impact issuances. To be discussed further with the team. +We are in the process of creating a few approaches to this ticket from the business use case perspective. One is essentially an “estimator” with a simplified workflow that can be used to estimate emission reductions, token issuance, etc. upfront to help the user better anticipate issuance and the impacts of various project activities and methodological choices. The other is more of a “summary preview” of the actual calculation results, that can be implemented just before validation (or anytime thereafter) to see summary KPIs based on the actual inputs and methodological choices made by the user, and they can then interact with the data like the Nerd Wallet retirement calculator to see how changes to the project activities could impact issuance. To be discussed further with the team. Referral Link: [https://github.com/hashgraph/guardian/issues/4562](https://github.com/hashgraph/guardian/issues/4562) @@ -985,7 +985,7 @@ Documentation Link: [https://guardian.hedera.com/guardian/standard-registry/poli Introduce a Formula calculation block which would: -* Allow Policy authors to input mathematical formulas directly into the policy (using Gurdian UI formula editor) in the standard mathematical notation ([https://cortexjs.io/mathlive/editor/](https://cortexjs.io/mathlive/editor/)) +* Allow Policy authors to input mathematical formulas directly into the policy (using Guardian UI formula editor) in the standard mathematical notation ([https://cortexjs.io/mathlive/editor/](https://cortexjs.io/mathlive/editor/)) * Enable policy authors to bind variables/parameters in these formulas to data (fields in schemas) for inputs/outputs to integrate the block into the Policy workflow * At Policy run time perform the calculations directly without any additional input etc from users ([https://arthanzel.github.io/evaluatex/](https://arthanzel.github.io/evaluatex/)) diff --git a/docs/guardian/standard-registry/bring-your-own-dids/bring-your-own-byo-dids-ui.md b/docs/guardian/standard-registry/bring-your-own-dids/bring-your-own-byo-dids-ui.md index 92c91d13df..9958b1859c 100644 --- a/docs/guardian/standard-registry/bring-your-own-dids/bring-your-own-byo-dids-ui.md +++ b/docs/guardian/standard-registry/bring-your-own-dids/bring-your-own-byo-dids-ui.md @@ -38,7 +38,7 @@ Example:
-Selecting ‘Custom DID document’ option enables the dialogue text window where the externally-generated/controlled DID document can be pasted from the clip-board. The document must contain Ed25519VerificationKey2018 and Bls12381G2Key2020 verification methods to be useable by Guardian. +Selecting ‘Custom DID document’ option enables the dialogue text window where the externally-generated/controlled DID document can be pasted from the clip-board. The document must contain Ed25519VerificationKey2018 and Bls12381G2Key2020 verification methods to be usable by Guardian. ### 1.3 Keys @@ -86,4 +86,4 @@ For more details, please refer to section [1.3](bring-your-own-byo-dids-ui.md#id ## 2. Demo Video -[Youtube](https://youtu.be/VVwHSu4LJ_w?si=warN7AxOVopv85G4\&t=117) +[YouTube](https://youtu.be/VVwHSu4LJ_w?si=warN7AxOVopv85G4\&t=117) diff --git a/docs/guardian/standard-registry/discontinuing-policy-workflow/apis-related-to-discontinuing-policy-workflow/discontinue-policy.md b/docs/guardian/standard-registry/discontinuing-policy-workflow/apis-related-to-discontinuing-policy-workflow/discontinue-policy.md index d5d768ee1e..b23f087cfb 100644 --- a/docs/guardian/standard-registry/discontinuing-policy-workflow/apis-related-to-discontinuing-policy-workflow/discontinue-policy.md +++ b/docs/guardian/standard-registry/discontinuing-policy-workflow/apis-related-to-discontinuing-policy-workflow/discontinue-policy.md @@ -2,7 +2,7 @@ {% swagger method="put" path="" baseUrl="/policies/{policyId}/discontinue" summary="Discontinue policy." %} {% swagger-description %} -Discontunue policy. Only users with the Standard Registry role are allowed to make the request. +Discontinue policy. Only users with the Standard Registry role are allowed to make the request. {% endswagger-description %} {% swagger-parameter in="path" name="policyId" type="String" required="true" %} diff --git a/docs/guardian/standard-registry/fireblocks-raw-signing/fireblocks-signing-in-guardian-ui.md b/docs/guardian/standard-registry/fireblocks-raw-signing/fireblocks-signing-in-guardian-ui.md index b6c242fd52..917e2086fb 100644 --- a/docs/guardian/standard-registry/fireblocks-raw-signing/fireblocks-signing-in-guardian-ui.md +++ b/docs/guardian/standard-registry/fireblocks-raw-signing/fireblocks-signing-in-guardian-ui.md @@ -62,7 +62,7 @@ Additionally OPERATOR\_KEY is used for the following operations: ## Enabling Fireblocks Remote Signing: -When creating a user, select the “**Use fireblocks signing**” option and populate the following fields with values from your Fireblocks account configuration: +When creating a user, select the “**Use Fireblocks signing**” option and populate the following fields with values from your Fireblocks account configuration: * Fireblocks Vault ID * Fireblocks Asset ID diff --git a/docs/guardian/standard-registry/import-export-in-excel/import-and-export-excel-file-user-guide.md b/docs/guardian/standard-registry/import-export-in-excel/import-and-export-excel-file-user-guide.md index cd6ebebc3d..106774ba99 100644 --- a/docs/guardian/standard-registry/import-export-in-excel/import-and-export-excel-file-user-guide.md +++ b/docs/guardian/standard-registry/import-export-in-excel/import-and-export-excel-file-user-guide.md @@ -149,7 +149,7 @@ The fields from embedded schema definition tab (e.g. titled as ‘Production Dev 2. **How they are processed by Guardian on import** -On import for each VC schema imported Guardian will create basic scaffolding of Policy block, which includes “_requestVcDocumentBlock” and a “customLogicBlock”_ if the imported schema contained’Auto-Calculate’ fields. +On import for each VC schema imported Guardian will create basic scaffolding of Policy block, which includes “_requestVcDocumentBlock” and a “customLogicBlock”_ if the imported schema contained ’Auto-Calculate’ fields.
@@ -193,7 +193,7 @@ If the Excel contains unsupported function Guardian would generate the comment a 4. Main calculations -The main body of the script is incapsulated into the ‘main’ function and consist of the following main sections:\ +The main body of the script is encapsulated into the ‘main’ function and consist of the following main sections:\ \ \- Declaration of the used variables diff --git a/docs/guardian/standard-registry/policies/block-policy-discoverability/README.md b/docs/guardian/standard-registry/policies/block-policy-discoverability/README.md index 9ac513ca4a..f7de3eeb46 100644 --- a/docs/guardian/standard-registry/policies/block-policy-discoverability/README.md +++ b/docs/guardian/standard-registry/policies/block-policy-discoverability/README.md @@ -2,4 +2,4 @@ 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 disaply the similarity percentage with the source policy. +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. diff --git a/docs/guardian/standard-registry/policies/demo-on-integrating-external-policies-using-ui.md b/docs/guardian/standard-registry/policies/demo-on-integrating-external-policies-using-ui.md index 4ec1e1a496..b73222c932 100644 --- a/docs/guardian/standard-registry/policies/demo-on-integrating-external-policies-using-ui.md +++ b/docs/guardian/standard-registry/policies/demo-on-integrating-external-policies-using-ui.md @@ -24,7 +24,7 @@ Here are the following steps to Integrate external policies as data sources:
{% hint style="info" %} -**Note:** Documents between the policies are synchronized automatically. Additionally, it can also be synched by clicking on sync button as shown below: +**Note:** Documents between the policies are synchronized automatically. Additionally, it can also be synced by clicking on sync button as shown below: {% endhint %}
diff --git a/docs/guardian/standard-registry/policies/integrating-3rd-party-data-resources/supported-global-forest-watch-api-methods/downloadgeotiff.md b/docs/guardian/standard-registry/policies/integrating-3rd-party-data-resources/supported-global-forest-watch-api-methods/downloadgeotiff.md index 303e653c71..76410fbe0a 100644 --- a/docs/guardian/standard-registry/policies/integrating-3rd-party-data-resources/supported-global-forest-watch-api-methods/downloadgeotiff.md +++ b/docs/guardian/standard-registry/policies/integrating-3rd-party-data-resources/supported-global-forest-watch-api-methods/downloadgeotiff.md @@ -2,11 +2,11 @@ description: 'API Version: 0.3.0' --- -# downloadGeoTiff +# downloadGeoTIFF `GET` `/dataset/{dataset}/{version}/download/geotiff` -Get geotiff raster tile. +Get geoTIFF raster tile. **Headers** diff --git a/docs/guardian/standard-registry/policies/integrating-3rd-party-data-resources/supported-global-forest-watch-api-methods/getnasaviirsfirealertsfeatures.md b/docs/guardian/standard-registry/policies/integrating-3rd-party-data-resources/supported-global-forest-watch-api-methods/getnasaviirsfirealertsfeatures.md index 574d053bae..7a45e99233 100644 --- a/docs/guardian/standard-registry/policies/integrating-3rd-party-data-resources/supported-global-forest-watch-api-methods/getnasaviirsfirealertsfeatures.md +++ b/docs/guardian/standard-registry/policies/integrating-3rd-party-data-resources/supported-global-forest-watch-api-methods/getnasaviirsfirealertsfeatures.md @@ -6,7 +6,7 @@ description: 'API Version: 0.3.0' `GET` `/dataset/nasa_viirs_fire_alerts/{version}/features` -Get Nasa Viirs fire alerts features. +Get NASA Viirs fire alerts features. **Headers** diff --git a/docs/guardian/standard-registry/policies/modules/modules-differentiation/module-differentiation-apis/exports-comparison-result.md b/docs/guardian/standard-registry/policies/modules/modules-differentiation/module-differentiation-apis/exports-comparison-result.md index ee36e9ddd6..47ea580b25 100644 --- a/docs/guardian/standard-registry/policies/modules/modules-differentiation/module-differentiation-apis/exports-comparison-result.md +++ b/docs/guardian/standard-registry/policies/modules/modules-differentiation/module-differentiation-apis/exports-comparison-result.md @@ -26,7 +26,7 @@ depth (level) of child block comparison (0/1/2) {% endswagger-parameter %} {% swagger-parameter in="body" name="idLvl" type="String" required="false" %} -depth (level) of uuid comparision (0/1) +depth (level) of uuid comparison (0/1) {% endswagger-parameter %} {% swagger-response status="200: OK" description="Successful Operation" %} diff --git a/docs/guardian/standard-registry/policies/modules/modules-differentiation/module-differentiation-using-ui.md b/docs/guardian/standard-registry/policies/modules/modules-differentiation/module-differentiation-using-ui.md index 9603fc4810..ed4115b0bc 100644 --- a/docs/guardian/standard-registry/policies/modules/modules-differentiation/module-differentiation-using-ui.md +++ b/docs/guardian/standard-registry/policies/modules/modules-differentiation/module-differentiation-using-ui.md @@ -99,7 +99,7 @@ Input: "childrenLvl":"0" – depth (level) of child block comparison (0/1/2) -"idLvl":"0" – depth (level) of uuid comparision (0/1) +"idLvl":"0" – depth (level) of uuid comparison (0/1) } diff --git a/docs/guardian/standard-registry/policies/policy-creation/creating-a-policy-through-policy-configurator/policy-workflow-wrap-up.md b/docs/guardian/standard-registry/policies/policy-creation/creating-a-policy-through-policy-configurator/policy-workflow-wrap-up.md index 5c52794610..d84656cfc2 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/creating-a-policy-through-policy-configurator/policy-workflow-wrap-up.md +++ b/docs/guardian/standard-registry/policies/policy-creation/creating-a-policy-through-policy-configurator/policy-workflow-wrap-up.md @@ -8,7 +8,7 @@ We can also look at the code that has been created programmatically from the def ![](../../../../../.gitbook/assets/PW\_image\_34.png) -The full coded version of the policy we just demoed is below (Reminder the coded version of this policy is for Guardian verison 1.0.2): +The full coded version of the policy we just demoed is below (Reminder the coded version of this policy is for Guardian version 1.0.2): ``` //Policy logic starts with block 1. diff --git a/docs/guardian/standard-registry/policies/policy-creation/creating-a-policy-using-apis/prerequesite-steps.md b/docs/guardian/standard-registry/policies/policy-creation/creating-a-policy-using-apis/prerequesite-steps.md index c3fce552d6..a11a379693 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/creating-a-policy-using-apis/prerequesite-steps.md +++ b/docs/guardian/standard-registry/policies/policy-creation/creating-a-policy-using-apis/prerequesite-steps.md @@ -1,6 +1,6 @@ # Prerequesite Steps -Prior to creating a policy there are a few steps that need to be done first. Please see below for the prerequesite steps: +Prior to creating a policy there are a few steps that need to be done first. Please see below for the prerequisite steps: ### **New Standard Registry registration** diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/customlogicblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/customlogicblock.md index 15ccf17e83..4aba32ebce 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/customlogicblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/customlogicblock.md @@ -14,4 +14,4 @@ This block supports two types of artifacts : JSON (.json) and Executable Code (. **Executable Code** : will be executed before main function. -To access table data in customlogic block, please check [Custom Logic Block & Tables](../../../schemas/available-schema-types/table-data-input-field/custom-logic-block-and-tables.md) for more details. +To access table data in custom logic block, please check [Custom Logic Block & Tables](../../../schemas/available-schema-types/table-data-input-field/custom-logic-block-and-tables.md) for more details. diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/information-workflow-block.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/information-workflow-block.md index 03b73dbcf9..cdb77e22c0 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/information-workflow-block.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/information-workflow-block.md @@ -2,7 +2,7 @@ ### Properties -
Block PropertyDefinitionExample InputStatus
typeA block type which can display a notification or a progress bar.InformationBlock (Can't be changed).
tagUnique name for the logic block.wait_for_approval.
permissionsWhich entity has rights to interact at this part of the workflow.Installer.
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
dependenciesEstablish workflow dependancies that need to be completed prior.Select the appropriate block from the dropdown.Deprecated
stop PropagationEnd processing here, don't pass control to the next block.Checked or Unchecked.
+
Block PropertyDefinitionExample InputStatus
typeA block type which can display a notification or a progress bar.InformationBlock (Can't be changed).
tagUnique name for the logic block.wait_for_approval.
permissionsWhich entity has rights to interact at this part of the workflow.Installer.
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
dependenciesEstablish workflow dependencies that need to be completed prior.Select the appropriate block from the dropdown.Deprecated
stop PropagationEnd 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. diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/mathblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/mathblock.md index 7b49c3b719..b10399be60 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/mathblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/mathblock.md @@ -39,7 +39,7 @@ This section provides UI to defined formulas using standard mathematical notatio
-**2.1 Formula defintion** +**2.1 Formula definition** To define a formula, complete the following steps: diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/paginationaddon.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/paginationaddon.md index 0935f23f27..c5ca1df419 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/paginationaddon.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/paginationaddon.md @@ -25,7 +25,7 @@ Selected policy ID Selected Block UUID {% endswagger-parameter %} -{% swagger-response status="200: OK" description="Succesful Operation" %} +{% swagger-response status="200: OK" description="Successful Operation" %} ``` { "size": 5, diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/reassigningblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/reassigningblock.md index 677805cede..6421282c55 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/reassigningblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/reassigningblock.md @@ -2,7 +2,7 @@ ### Properties -
Block PropertyDefinitionExample InputStatus
typeA block type which re-signs the document and change the user to document owner.reassigningBlock (Can't be changed).
tagUnique name for the logic block.wait_for_approval.
permissionsWhich entity has rights to interact at this part of the workflow.Installer.
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
dependenciesEstablish workflow dependancies that need to be completed prior.Select the appropriate block from the dropdown.Deprecated
stop PropagationEnd processing here, don't pass control to the next block.Checked or Unchecked.
issuerPerson, who will be a Signernot set - Current User
owner - document Owner
policyOwner - Policy Owner
actorPerson, who will be next Block Ownernot set - Current User
owner - document Owner
issuer - document Issuer
+
Block PropertyDefinitionExample InputStatus
typeA block type which re-signs the document and change the user to document owner.reassigningBlock (Can't be changed).
tagUnique name for the logic block.wait_for_approval.
permissionsWhich entity has rights to interact at this part of the workflow.Installer.
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
dependenciesEstablish workflow dependencies that need to be completed prior.Select the appropriate block from the dropdown.Deprecated
stop PropagationEnd processing here, don't pass control to the next block.Checked or Unchecked.
issuerPerson, who will be a Signernot set - Current User
owner - document Owner
policyOwner - Policy Owner
actorPerson, who will be next Block Ownernot set - Current User
owner - document Owner
issuer - document Issuer
{% hint style="info" %} RefreshEvents are used to refreshing the UI, instead of "dependencies" property. diff --git a/docs/guardian/standard-registry/policies/tagging/tagging-using-ui.md b/docs/guardian/standard-registry/policies/tagging/tagging-using-ui.md index 51731e0b4a..b97a005d29 100644 --- a/docs/guardian/standard-registry/policies/tagging/tagging-using-ui.md +++ b/docs/guardian/standard-registry/policies/tagging/tagging-using-ui.md @@ -13,7 +13,7 @@ Document objects which can be attached to Schemas, Policies, Modules, Tokens, DI #### **1.1 Object** -* _**uuid**_ – unique tag identificator, tags with the same uuid are considered to be the same +* _**uuid**_ – unique tag identification, tags with the same uuid are considered to be the same * _**name**_ – label visible to the user and the criteria upon which tags are grouped * _**description**_ – optional text field to provide additional information about tags * _**owner**_ – DID of the user who created the tag @@ -92,7 +92,7 @@ Tags which have been imported with the Policy or Schema are marked as _**History #### **2.5 Tag updates (synchronization)** -Any credentialed entity can create/remove a tag on any object at any point of time independently from the Guardian instance where this tagable object (document etc) has been created. This presents a challenge for displaying the up-to-date state of 3rd party tags associated with the object, since continuous search and import/updates of such tags can affect UI responsiveness and general UX. Guardian users can refresh (or ‘pull’) 3rd party tags and update their display in their local Guardian instance by clicking on the corresponding icon (highlighted on the screenshot below). +Any credentialed entity can create/remove a tag on any object at any point of time independently from the Guardian instance where this taggable object (document etc) has been created. This presents a challenge for displaying the up-to-date state of 3rd party tags associated with the object, since continuous search and import/updates of such tags can affect UI responsiveness and general UX. Guardian users can refresh (or ‘pull’) 3rd party tags and update their display in their local Guardian instance by clicking on the corresponding icon (highlighted on the screenshot below). ![synchronization icon](<../../../../.gitbook/assets/8 (1) (1) (1) (1) (1) (1) (1) (1).png>) diff --git a/docs/guardian/standard-registry/schemas/creating-system-schema-using-ui.md b/docs/guardian/standard-registry/schemas/creating-system-schema-using-ui.md index db12827d87..e3b5b5d6c2 100644 --- a/docs/guardian/standard-registry/schemas/creating-system-schema-using-ui.md +++ b/docs/guardian/standard-registry/schemas/creating-system-schema-using-ui.md @@ -61,7 +61,7 @@ Schema JSON definition contains the following editable fields 2. **title** – field title 3. **description** – schema description (visible to the user) 4. **required** – field visibility/type (Auto Calculate, Hidden, Required, None) - 5. **type** – field value tipe (Number, String, Enum, …) or the sub-schema reference (#be764ef6-…) + 5. **type** – field value type (Number, String, Enum, …) or the sub-schema reference (#be764ef6-…) 6. **isArray** – boolean field (true\false) determining whether the field is an array 7. **property** – optional field mapping onto the corresponding property from dMRV framework ([https://interworkalliance.github.io/TokenTaxonomyFramework/dmrv/spec/](https://interworkalliance.github.io/TokenTaxonomyFramework/dmrv/spec/)) 8. **private** – if the field is private (only relevant for ‘selective disclosure’ EVCs) diff --git a/docs/guardian/standard-registry/schemas/schema-creation-using-apis/updating-schema.md b/docs/guardian/standard-registry/schemas/schema-creation-using-apis/updating-schema.md index 612e5c8b02..ead26fbc2b 100644 --- a/docs/guardian/standard-registry/schemas/schema-creation-using-apis/updating-schema.md +++ b/docs/guardian/standard-registry/schemas/schema-creation-using-apis/updating-schema.md @@ -17,7 +17,7 @@ Updates the schema matching the id in the request body. Only users with the Stan | \* | schema | Object that contains a valid schema including the id of the schema that is to be update | {% tabs %} -{% tab title="200: OK Succesful Operation" %} +{% tab title="200: OK Successful Operation" %} ```javascript { content: diff --git a/docs/guardian/tokens/creating-token-using-ui.md b/docs/guardian/tokens/creating-token-using-ui.md index cb68cd378e..0119535183 100644 --- a/docs/guardian/tokens/creating-token-using-ui.md +++ b/docs/guardian/tokens/creating-token-using-ui.md @@ -12,4 +12,4 @@ Step 2: Once button is clicked, we get a pop up box to enter token details such Following are the parameters required to complete the token creation process: -
Field NameDescriptionExmaple
Token NameName of the tokeniREC Token
Token SymbolSymbol of the tokenI
Token Typewhether the token to be fungible and non fungibleF/N
DecimalsDecimals to be allowed to the token2
Enable AdminEnabled to make changes in the token settings even after creating tokenChecked or Unchecked
Change SupplyEnabled to change the token supplyChecked or Unchecked
Enable FreezeEnabling Freezing of the tokenChecked or Unchecked
Enable KYCEnabling KYC when token is createdChecked or Unchecked
Enable WipeEnabled to wipe the token supplyChecked or Unchecked
+
Field NameDescriptionExample
Token NameName of the tokeniREC Token
Token SymbolSymbol of the tokenI
Token Typewhether the token to be fungible and non fungibleF/N
DecimalsDecimals to be allowed to the token2
Enable AdminEnabled to make changes in the token settings even after creating tokenChecked or Unchecked
Change SupplyEnabled to change the token supplyChecked or Unchecked
Enable FreezeEnabling Freezing of the tokenChecked or Unchecked
Enable KYCEnabling KYC when token is createdChecked or Unchecked
Enable WipeEnabled to wipe the token supplyChecked or Unchecked
diff --git a/docs/guardian/tokens/token-operations/apis-for-asynchronous-execution/associating-user-with-the-hedera-token.md b/docs/guardian/tokens/token-operations/apis-for-asynchronous-execution/associating-user-with-the-hedera-token.md index df751b3aaf..96329d0f3c 100644 --- a/docs/guardian/tokens/token-operations/apis-for-asynchronous-execution/associating-user-with-the-hedera-token.md +++ b/docs/guardian/tokens/token-operations/apis-for-asynchronous-execution/associating-user-with-the-hedera-token.md @@ -20,7 +20,7 @@ Token ID ``` {% endswagger-response %} -{% swagger-response status="401: Unauthorized" description="Unauthroized" %} +{% swagger-response status="401: Unauthorized" description="Unauthorized" %} ```javascript { // Response diff --git a/docs/guardian/users/bottom-up-data-traceability/bottom-up-data-traceability-using-ui.md b/docs/guardian/users/bottom-up-data-traceability/bottom-up-data-traceability-using-ui.md index db3d83225e..2fbefc0dd5 100644 --- a/docs/guardian/users/bottom-up-data-traceability/bottom-up-data-traceability-using-ui.md +++ b/docs/guardian/users/bottom-up-data-traceability/bottom-up-data-traceability-using-ui.md @@ -148,7 +148,7 @@ To enable the use of **Definitions** for creating **Assessments** of real data, #### **3.1 Creation** -Published **Definitions** can be used for creating an **Assessment** by pressing the **Create** button for the corresponding Statistics **Definition** which launches the **Assessment** wizard**.** +Published **Definitions** can be used for creating an **Assessment** by pressing the **Create** button for the corresponding Statistics **Definition** which launches the **Assessment Wizard**. ![](<../../../.gitbook/assets/16 (13).png>) @@ -248,4 +248,4 @@ Example Hedera message on the publication of a new Statistics **Assessment** ## 2. Demo Video -[Youtube](https://youtu.be/tYLsr4rxw58?si=XNRvpap7aosnwuhh\&t=107) +[YouTube](https://youtu.be/tYLsr4rxw58?si=XNRvpap7aosnwuhh\&t=107) diff --git a/docs/meeco/integration.md b/docs/meeco/integration.md index ced09d968b..a9f0fa9aff 100644 --- a/docs/meeco/integration.md +++ b/docs/meeco/integration.md @@ -9,7 +9,7 @@ Users have an option to login by Meeco using VC4OIDC as follows: 1. User click on "Meeco Login" Button to Login by Meeco -2. Guardian Client Sends **MEECO_AUTH_REQUEST** Message over Websocket connetion +2. Guardian Client Sends **MEECO_AUTH_REQUEST** Message over Websocket connection 3. Guardian API gateway receives the message and send a **MEECO_AUTH_START** command to Auth service over the NATS service @@ -23,7 +23,7 @@ Users have an option to login by Meeco using VC4OIDC as follows: - Auth Service decodes serialized KEK - Auth Service get serialized Keypair from SVX - Auth Service decodes serialized Keypair by KEK - - Auth Service exteract unsigned_jwt from preserntation request and signs it + - Auth Service extract unsigned_jwt from presentation request and signs it - Auth Service updates presentation request by adding signature of unsigned_jwt - Auth Service construct the redirect_uri from presentation request @@ -68,7 +68,7 @@ Users have an option to login by Meeco using VC4OIDC as follows: ``` 21. The websocket get the payload and call the Meeco URl once approved, and get the user data with all verifiable credentials. - During the process, the user is created in the Guardian application, the username is defined but also managed to avoid colisions. + During the process, the user is created in the Guardian application, the username is defined but also managed to avoid collisions. - Auth Service submits verified submission to SVX platform - persists data to database - generates JWT token diff --git a/docs/meeco/mermaid-code.md b/docs/meeco/mermaid-code.md index 8d9615b9b3..61e71867a8 100644 --- a/docs/meeco/mermaid-code.md +++ b/docs/meeco/mermaid-code.md @@ -23,7 +23,7 @@ sequenceDiagram SVX-->>-Au: 200 {presentationRequest} Au->>+SVX: GET /me SVX-->>-Au: 200 {me} - Au->>Au: exteract externaId from me.user.did + Au->>Au: extract externalId from me.user.did Au->>+SVX: GET /key_encryption_key SVX-->>-Au: 200 {key_encryption_key} Au->>+SVX: GET /keypairs/external_id/${externalId} @@ -49,9 +49,9 @@ sequenceDiagram break Submission received Au->>Au: Verify Submission alt Submission is Valid - Au->>Au: Exteract VC - Au->>GW: Send NATS message MEECO_VERIFY_VP {cid,credentailSubject,presentationRequestId,submissionIs} - GW->>GUI: Send WS MEECO_VERIFY_VP {credentailSubject,presentationRequestId,submissionIs} + Au->>Au: Extract VC + Au->>GW: Send NATS message MEECO_VERIFY_VP {cid,credentialSubject,presentationRequestId,submissionIs} + GW->>GUI: Send WS MEECO_VERIFY_VP {credentialSubject,presentationRequestId,submissionIs} else Submission is Invalid Au->>GW: Send NATS message MEECO_VERIFY_VP_FAILED {cid,credentailSubject,error} GW->>GUI: Send WS MEECO_VERIFY_VP_FAILED {error} @@ -74,7 +74,7 @@ sequenceDiagram H->>GUI: hit Approve button GUI->>GW: Send WS message MEECO_APPROVE_SUBMISSION_RESPONSE {presentationRequestId,submissionId} GW->>+Au: Send NATS message MEECO_APPROVE_SUBMISSION {cid,presentationRequestId,submissionId} - Au->>+SVX: PATCH /oidc/presentations/requests/${requestId}/submissions/${submissionId} {submisiion: {status: "verified}} + Au->>+SVX: PATCH /oidc/presentations/requests/${requestId}/submissions/${submissionId} {submission: {status: "verified}} SVX-->>-Au: 200 OK Au->>Au: generate JWT Au-->>-GW: {cid,JWT} diff --git a/docs/methodology-digitization-handbook/README.md b/docs/methodology-digitization-handbook/README.md index 4968348aec..a4ca9464b8 100644 --- a/docs/methodology-digitization-handbook/README.md +++ b/docs/methodology-digitization-handbook/README.md @@ -44,7 +44,7 @@ The Methodology Digitization Handbook is a comprehensive guide for transforming **Complete Process Coverage**: From initial PDF analysis to production deployment with VM0033 digitization example throughout. {% endhint %} -
FeaturesDescription
Comprehensive Coverage• Complete process from PDF analysis to deployment
• Real examples from VM0033 implementation
• Practical focus with actionable steps
• Best practices from successful digitizations
Why VM0033?• 135-page methodology that covers most challenges
• Active use in blue carbon projects
• Guardian policy being used by Verra in production
• Built in collaboration with Verra & Allcot with real project data and testing
Streamlined Structure• 27 focused chapters across 8 parts
• 20-30 hours total reading time
• Practical, hands-on approach throughout
• Reduced complexity while maintaining comprehensive coverage
+
FeaturesDescription
Comprehensive Coverage• Complete process from PDF analysis to deployment
• Real examples from VM0033 implementation
• Practical focus with actionable steps
• Best practices from successful digitalizations
Why VM0033?• 135-page methodology that covers most challenges
• Active use in blue carbon projects
• Guardian policy being used by Verra in production
• Built in collaboration with Verra & Allcot with real project data and testing
Streamlined Structure• 27 focused chapters across 8 parts
• 20-30 hours total reading time
• Practical, hands-on approach throughout
• Reduced complexity while maintaining comprehensive coverage
## Handbook Structure and Flow diff --git a/docs/methodology-digitization-handbook/chapter-outlines.md b/docs/methodology-digitization-handbook/chapter-outlines.md index 81566b0bb5..f30f021f5e 100644 --- a/docs/methodology-digitization-handbook/chapter-outlines.md +++ b/docs/methodology-digitization-handbook/chapter-outlines.md @@ -359,7 +359,7 @@ * Compliance monitoring and automated audit trail generation * API integration and external system connectivity -**VM0033 Context**: Using Guardian Indexer to monitor VM0033 tidal wetland restoration projects, track VCU credit issuances, and generate compliance reports for Verra registry requirements. +**VM0033 Context**: Using Guardian Indexer to monitor VM0033 tidal wetland restoration projects, track VCU credit issuance, and generate compliance reports for Verra registry requirements. ## Part VII: Advanced Topics and Best Practices diff --git a/docs/methodology-digitization-handbook/part-3/chapter-10/README.md b/docs/methodology-digitization-handbook/part-3/chapter-10/README.md index 69caa260b5..d0581f21d0 100644 --- a/docs/methodology-digitization-handbook/part-3/chapter-10/README.md +++ b/docs/methodology-digitization-handbook/part-3/chapter-10/README.md @@ -13,7 +13,7 @@ Monitoring schemas extend your PDD implementation to handle ongoing project oper * **Quality Control**: Data validation and evidence documentation for verification activities * **Temporal Relationships**: Maintaining connections between annual data and cumulative results -Usually, there's always a section on methodology PDF(including VM0033) on data and parameters to be monitored. Typcially, those fields are submitted as part of Monitoring report. +Usually, there's always a section on methodology PDF(including VM0033) on data and parameters to be monitored. Typically, those fields are submitted as part of Monitoring report. ![Subsection of Herbaceous Vegetation Stratum Data for Project in MR schema](<../../../.gitbook/assets/image (38).png>) @@ -78,7 +78,7 @@ Yes | (New) MP Herbaceous Vegetat 1 | | | Measurements for each stratum | Yes | For methodologies with multiple strata like VM0033, create stratum-specific monitoring: -Create "(New) MP Herbaceous Vegetat 1" worksheet(names are trimmed to accomodate excel's limitations): +Create "(New) MP Herbaceous Vegetat 1" worksheet(names are trimmed to accommodate excel's limitations): ```excel (New) MP Herbaceous Vegetation Stratum Data for Project diff --git a/docs/methodology-digitization-handbook/part-3/chapter-9/README.md b/docs/methodology-digitization-handbook/part-3/chapter-9/README.md index 786696f3ca..71be11eab9 100644 --- a/docs/methodology-digitization-handbook/part-3/chapter-9/README.md +++ b/docs/methodology-digitization-handbook/part-3/chapter-9/README.md @@ -64,9 +64,9 @@ The first functional field should be your primary conditional logic driver. For Row 5: Yes | Enum | Choose project certific (enum) | | Choose project certification type | No | VCS v4.4 ``` -This creates an enum field that determines which additional requirements appear. The parameter reference "Choose project certific (enum)" points to a separate enum tab defining the options. +This creates an enum field that determines which additional requirements appear. The parameter reference "Choose project certificate (enum)" points to a separate enum tab defining the options. -**Create the Enum Tab**: Add a new worksheet named "Choose project certific (enum)" with(sheet names might be trimmed to accomodate excel's limitations): +**Create the Enum Tab**: Add a new worksheet named "Choose project certificate (enum)" with(sheet names might be trimmed to accommodate excel's limitations): ```excel Schema name | Project Description (Auto) diff --git a/docs/methodology-digitization-handbook/part-5/chapter-19/README.md b/docs/methodology-digitization-handbook/part-5/chapter-19/README.md index 25861cda56..9719002b31 100644 --- a/docs/methodology-digitization-handbook/part-5/chapter-19/README.md +++ b/docs/methodology-digitization-handbook/part-5/chapter-19/README.md @@ -67,7 +67,7 @@ There are 4 types of items available in order to compose a formula: - `Link (Output)` which indicates the field in the document schema where the text should be shown. - `Relationships` field where you can select all the variables, constants and formulas that are related. -Using the combination of the above 4 items, a Formula Linked Definitions can be generated which will explain the code/calculations that happen in the CustomLogicBlock. The best approach is to go from bottom to top i.e. create all the small formulas and variables/constants it is related to and then work you way up to create the final formula that represents the Main Formula of the methodology. A formula item can be used inside another formula which will create a heirarchy for the end users to track how each component is being calculated. +Using the combination of the above 4 items, a Formula Linked Definitions can be generated which will explain the code/calculations that happen in the CustomLogicBlock. The best approach is to go from bottom to top i.e. create all the small formulas and variables/constants it is related to and then work you way up to create the final formula that represents the Main Formula of the methodology. A formula item can be used inside another formula which will create a hierarchy for the end users to track how each component is being calculated. Once you have published the policy with the FLDs set up, 'fx' button will appear next to the fields for which the formulas were added in the FLDs and once clicked on the button you will hierarchy of the formulas and the variables involved and how it led to the calculated value. (Image attached in `Viewing Formula Linked Definitions` section) @@ -110,4 +110,4 @@ Chapter 20 will demonstrate implementing specific AR Tool calculation patterns, - [VM0033 Calculation Implementation](../../_shared/artifacts/er-calculations.js) - [VM0033 Test Case Artifacts](../../_shared/artifacts/VM0033_Allcot_Test_Case_Artifact.xlsx) - [VM003 Policy with FLDs attached](../../../../Methodology%20Library/Verra/Verified%20Carbon%20Standard%20(VCS)/VM0033/VM0033.policy) ---- \ No newline at end of file +--- diff --git a/docs/policy-creation-using-the-guardian-apis/prerequesite-steps.md b/docs/policy-creation-using-the-guardian-apis/prerequesite-steps.md index ccbabaf765..5ba0395aec 100644 --- a/docs/policy-creation-using-the-guardian-apis/prerequesite-steps.md +++ b/docs/policy-creation-using-the-guardian-apis/prerequesite-steps.md @@ -1,6 +1,6 @@ # Prerequesite Steps -Prior to creating a policy there are a few steps that need to be done first. Please see below for the prerequesite steps: +Prior to creating a policy there are a few steps that need to be done first. Please see below for the prerequisite steps: ### **New Standard Registry registration** diff --git a/docs/policy-workflow-creation-using-the-guardian-user-interface/policy-workflow-wrap-up.md b/docs/policy-workflow-creation-using-the-guardian-user-interface/policy-workflow-wrap-up.md index b70218751c..1624579756 100644 --- a/docs/policy-workflow-creation-using-the-guardian-user-interface/policy-workflow-wrap-up.md +++ b/docs/policy-workflow-creation-using-the-guardian-user-interface/policy-workflow-wrap-up.md @@ -8,7 +8,7 @@ We can also look at the code that has been created programmatically from the def ![](../.gitbook/assets/PW\_image\_34.png) -The full coded version of the policy we just demoed is below (Reminder the coded version of this policy is for Guardian verison 1.0.2): +The full coded version of the policy we just demoed is below (Reminder the coded version of this policy is for Guardian version 1.0.2): ``` //Policy logic starts with block 1. diff --git a/docs/schema-creation-using-the-guardian-apis/updating-schema.md b/docs/schema-creation-using-the-guardian-apis/updating-schema.md index 41c9041de0..9b07ea228b 100644 --- a/docs/schema-creation-using-the-guardian-apis/updating-schema.md +++ b/docs/schema-creation-using-the-guardian-apis/updating-schema.md @@ -15,7 +15,7 @@ Schema ID Object that contains a valid schema including the id of the schema that is to be update {% endswagger-parameter %} -{% swagger-response status="200: OK" description="Succesful Operation" %} +{% swagger-response status="200: OK" description="Successful Operation" %} ```javascript { content: diff --git a/docs/secrets manager/guardian-vault.md b/docs/secrets manager/guardian-vault.md index f658470269..03dc73de0a 100644 --- a/docs/secrets manager/guardian-vault.md +++ b/docs/secrets manager/guardian-vault.md @@ -38,17 +38,17 @@ _Note_: In order to generate vault and consul config files, the simplest way is _Note_: In order to start and configure Vault it can be simply done by running `make vault_up` command in the roo directory of guardian. -- __Initialize Vault__: Initializes vault operator and generates root token and unsealing keys. Root token can be used further for adminstration of vault. Unsealing keys must be used to unseal vault. Vault requires `secret-shares` and `secret-threshold` to generate unseal keys. `secret-shares` is the number of keys genrated and `secret-threshold` is the number of keys must be used to unseal vault. These parameters are configured by `VAULT_UNSEAL_SECRET_SHARES` and `VAULT_UNSEAL_SECRET_THRESHOLD` variables inside .env file. root token and unsealing keys are stored in `hashicorp/vault/.root` file and must be removed after being generated. +- __Initialize Vault__: Initializes vault operator and generates root token and unsealing keys. Root token can be used further for administration of vault. Unsealing keys must be used to unseal vault. Vault requires `secret-shares` and `secret-threshold` to generate unseal keys. `secret-shares` is the number of keys genrated and `secret-threshold` is the number of keys must be used to unseal vault. These parameters are configured by `VAULT_UNSEAL_SECRET_SHARES` and `VAULT_UNSEAL_SECRET_THRESHOLD` variables inside .env file. root token and unsealing keys are stored in `hashicorp/vault/.root` file and must be removed after being generated. - __Unseal Vault__: Having initialized the vault insance, it is still sealed and must be sealed by `secret-threshold` number of unsealing keys. The script automatically unseals the vault instance by running unseal command. - __Enable KV V2 Secret Engine__: -- __Enable AppRole Auth Method__: Approle is an auth method for authentication of machines or apps with defined roles. Roles are defined by a set of policies which narrows the accessibility of roles to vault resources. Approle is consisting a set of workflows that provides `role_id` and `secret_id` as credentials (very similiar to username and password) that must be used in authentication process to generate auth token that is authorized according to the role that is defined for the role_id. +- __Enable AppRole Auth Method__: Approle is an auth method for authentication of machines or apps with defined roles. Roles are defined by a set of policies which narrows the accessibility of roles to vault resources. Approle is consisting a set of workflows that provides `role_id` and `secret_id` as credentials (very similar to username and password) that must be used in authentication process to generate auth token that is authorized according to the role that is defined for the role_id. -- __Create Policies for All guardian Service__: Each service like guardian-service has a specific access and permission to the vault resources. As an example guardian-service has access to wallets and operator key, while auth-service has access to auth secret key only. The access permissions must be defined by policies and attached to the roles that will be created for each service aftewards. A number of policy files are created and stored in the `hashicorp/configs/vault/policies`. The script will automatically retrieve policy files from the directory and create policies accordingly. +- __Create Policies for All guardian Service__: Each service like guardian-service has a specific access and permission to the vault resources. As an example guardian-service has access to wallets and operator key, while auth-service has access to auth secret key only. The access permissions must be defined by policies and attached to the roles that will be created for each service afterwards. A number of policy files are created and stored in the `hashicorp/configs/vault/policies`. The script will automatically retrieve policy files from the directory and create policies accordingly. -- __Create roles associated with policies for all services__: Having created a set of policies, roles with neccessary policies must be created. An approle config file that implies each role and its policies is created and stored in `hashicorp/configs/vault/approle`. The script retrieves the `approle.json` file and creates roles with specified policies. +- __Create roles associated with policies for all services__: Having created a set of policies, roles with necessary policies must be created. An approle config file that implies each role and its policies is created and stored in `hashicorp/configs/vault/approle`. The script retrieves the `approle.json` file and creates roles with specified policies. - __Get AppRole Credentials for all services__: Each service has a role with a set of specific policies, needs approle credentials to acquire auth token to access secrets. The credentials are fetched from vault for each role and immediately written to .env and .env.docker files. The env file paths are configured by `approle.json` file. @@ -58,7 +58,7 @@ _Note_: In order to start and configure Vault it can be simply done by running ` ## AWS Secrets Manager -AWS Secrets Manager provides a secure secret manager service with lots of flexibilites that lower the burden of deploying Hashicorp Vault instance as secret manager. AWS secrets manager does not require any credentials in order to authenticate as they are accissible withing a vps network by an EC2 instance or lambda function in the same region of secrets manager. However, the EC2 instance is required to acquire permissions to access the secret resources. Permissions are defined by roles consisting a set of policies, each define a specific permission to an AWS resource. +AWS Secrets Manager provides a secure secret manager service with lots of flexibilities that lower the burden of deploying Hashicorp Vault instance as secret manager. AWS secrets manager does not require any credentials in order to authenticate as they are accessible withing a vps network by an EC2 instance or lambda function in the same region of secrets manager. However, the EC2 instance is required to acquire permissions to access the secret resources. Permissions are defined by roles consisting a set of policies, each define a specific permission to an AWS resource. Scripts are created to automatically execute the required steps to prepare AWS secrets manager to be utilized by guardian services. @@ -73,7 +73,7 @@ _Note_: Before running the scripts it is necessary to login into AWS service by Azure Vault provides a centralised service to manage sensitive data safe and secure. It provides three services to manage Secrets, Keys and Certificates: -* Secrets Manager: Azure Key Vault enables secure storage of secrets such as Passwordds, API Keys, etc. Secrets can be easily managed, rotated, and accessed programmatically. +* Secrets Manager: Azure Key Vault enables secure storage of secrets such as passwords, API Keys, etc. Secrets can be easily managed, rotated, and accessed programmatically. * Key Manager: Cryptographic keys can be generated and managed within Azure Key Vault. These keys can be used for encryption, decryption, signing, and verification purposes. Azure Key Vault supports a variety of key types and algorithms. @@ -83,7 +83,7 @@ Guardian is supporting Azure Vault Secrets Manager to handle securely the secret 1. __Create a Key Vault__: From the Azure Portal navigate to __Key Vaults__, choose a Resource Group has been created before from the list, insert a name for the Vault instance, select the region and carefully prepare other configurations and follow to the Next page. -2. Choose __Vault Access Policy__ as Permission model and __Azure Virtual Machines for deployment__ as Resource Access. Under Access Policies, click on __Create__ and in the prompt window choose all neccessary permissions required to grant to a User. For Guardian at least __Get__ and __Set__ of __Secrets__ are required. Next find the registered User to grant access. In the last step choose a registered application if has been created in Azure Active Directory before; otherwise select Next and finalize the process. +2. Choose __Vault Access Policy__ as Permission model and __Azure Virtual Machines for deployment__ as Resource Access. Under Access Policies, click on __Create__ and in the prompt window choose all necessary permissions required to grant to a User. For Guardian at least __Get__ and __Set__ of __Secrets__ are required. Next find the registered User to grant access. In the last step choose a registered application if has been created in Azure Active Directory before; otherwise select Next and finalize the process. 3. Configure Networking, Add Tags and create the Vault. @@ -93,7 +93,7 @@ Guardian is supporting Azure Vault Secrets Manager to handle securely the secret Google Cloud Platform (GCP) Secrets Manager is a managed service that helps you securely store and manage secrets, such as API keys, database credentials, and other sensitive information. It provides a central repository for storing secrets, with built-in security features and integration with other GCP services. It enables secure storage of secrets, secrets versioning and rotation, integration with other Google Cloud services like Cloud Run, VMs, App Engine, etc, supports Access Control, so on. -Guardian is now suport GCP Secrets Manager to store its secrets. In order to access Gcp Secrets Manager it is required to set the identifier of the project created in google cloud platfer that the GCP Secrets Mnager is supposed to be resided, as __GCP_PROJECT_ID__ in the .env file in the configs of auth service. +Guardian is now support GCP Secrets Manager to store its secrets. In order to access Gcp Secrets Manager it is required to set the identifier of the project created in google cloud platform that the GCP Secrets Mnager is supposed to be resided, as __GCP_PROJECT_ID__ in the .env file in the configs of auth service. Here is the steps to create secrets manager in google cloud platform. It is assumed that the project has been created in prior. @@ -105,4 +105,4 @@ Here is the steps to create secrets manager in google cloud platform. It is assu 4. Configure Secret manager by adding Name, Replication policy, Rotation, Expiration, etc according to security policies and click on Create Secret button -__*NOTE*__ According to the tests of read/write operations of secrets to the GCP Secrets manager, each secret R/W operation take around 1 second which is too slow to be used constantly in the Guardian Application. The reason is, Guardian generates lots of wallets and requires tp retrieve them from the Vault in order to sign transactions. The late response from GCP leads to make Guardian functioning too slowly. Consequently, it is not recommended to use GCP for constant R/W of secrets. \ No newline at end of file +__*NOTE*__ According to the tests of read/write operations of secrets to the GCP Secrets manager, each secret R/W operation take around 1 second which is too slow to be used constantly in the Guardian Application. The reason is, Guardian generates lots of wallets and requires tp retrieve them from the Vault in order to sign transactions. The late response from GCP leads to make Guardian functioning too slowly. Consequently, it is not recommended to use GCP for constant R/W of secrets. diff --git a/docs/token-related-apis-for-asynchronous-execution/associating-user-with-the-hedera-token.md b/docs/token-related-apis-for-asynchronous-execution/associating-user-with-the-hedera-token.md index dc8b8113f7..6a4f95fddb 100644 --- a/docs/token-related-apis-for-asynchronous-execution/associating-user-with-the-hedera-token.md +++ b/docs/token-related-apis-for-asynchronous-execution/associating-user-with-the-hedera-token.md @@ -20,7 +20,7 @@ Token ID ``` {% endswagger-response %} -{% swagger-response status="401: Unauthorized" description="Unauthroized" %} +{% swagger-response status="401: Unauthorized" description="Unauthorized" %} ```javascript { // Response From b32d3aa4d747730213ec4ff8224c4477e9c50a66 Mon Sep 17 00:00:00 2001 From: Daniel Swid Date: Wed, 18 Mar 2026 13:46:37 -0700 Subject: [PATCH 2/2] docs: address a number of grammatical issues across doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * that's it * [optional footer(s)] BREAKING CHANGE: Refs: Story: #5856 Reviewed-by: na Test-scope: na Signed-off-by: Daniel Swid --- .../readMe.md | 2 +- .../README.md | 2 +- .../aggregatedocumentblock.md | 4 +-- .../buttonblock.md | 2 +- .../customlogicblock.md | 2 +- .../documentvalidatorblock.md | 14 ++++---- .../groupmanagerblock.md | 2 +- .../mintdocumentblock.md | 4 +-- .../multisignblock.md | 4 +-- .../revokeblock.md | 2 +- .../setrelationshipsblock.md | 18 +++++------ .../splitblock.md | 4 +-- .../switchblock.md | 26 +++++++-------- .../timerblock.md | 4 +-- .../tokenactionblock.md | 2 +- .../tokenconfirmationblock.md | 2 +- .../api-architecture-customization.md | 4 +-- .../cloud-infrastructure.md | 2 +- .../performing-ui-automation-testing.md | 2 +- .../guardian-policy-standards-gps.md | 2 +- .../ghgp-corporate-standard-v2.md | 2 +- .../ghgp-corporate-standard.md | 2 +- .../guidance-for-open-source-policy.md | 2 +- docs/guardian/readme/guardian-glossary.md | 32 +++++++++---------- .../asynchronous-tasks-status.md | 2 +- .../library-of-policy-examples/README.md | 2 +- .../policy-workflow-step-11.md | 2 +- .../introduction/aggregatedocumentblock.md | 4 +-- .../introduction/buttonblock.md | 2 +- .../introduction/customlogicblock.md | 2 +- .../introduction/documentvalidatorblock.md | 12 +++---- .../introduction/externaltopicblock.md | 2 +- .../introduction/groupmanagerblock.md | 2 +- .../introduction/historyaddon.md | 2 +- .../introduction/http-request-block.md | 2 +- .../introduction/impactaddon.md | 2 +- .../introduction/mintdocumentblock.md | 4 +-- .../introduction/multisignblock.md | 4 +-- .../introduction/notificationblock.md | 2 +- .../introduction/revokeblock.md | 2 +- .../introduction/selectiveattributes-block.md | 2 +- .../introduction/send-workflow-block.md | 2 +- .../introduction/setrelationshipsblock.md | 2 +- .../introduction/splitblock.md | 4 +-- .../introduction/switchblock.md | 2 +- .../introduction/tagsmanagerblock.md | 2 +- .../introduction/timerblock.md | 4 +-- .../introduction/tokenactionblock.md | 2 +- .../introduction/tokenconfirmationblock.md | 2 +- .../schemas/system-policy-schemas.md | 2 +- .../standard-registry/trustchain/README.md | 2 +- docs/guardian/users/user-profile-setup.md | 2 +- docs/user-guide-glossary/guardian-glossary.md | 32 +++++++++---------- 53 files changed, 125 insertions(+), 125 deletions(-) diff --git a/Methodology Library/Greenhouse Gas (GHG)/GHG Protocol Corporate Standard v2/readMe.md b/Methodology Library/Greenhouse Gas (GHG)/GHG Protocol Corporate Standard v2/readMe.md index 79966fe5b9..c070f3247a 100644 --- a/Methodology Library/Greenhouse Gas (GHG)/GHG Protocol Corporate Standard v2/readMe.md +++ b/Methodology Library/Greenhouse Gas (GHG)/GHG Protocol Corporate Standard v2/readMe.md @@ -19,7 +19,7 @@ ## Introduction -The GHG Protocol Corporate Accounting and Reporting Standard (GHGP Corporate Standard) is the world’s leading standard outlining requirements and guidance for corporate-level and organizational-level GHG emission inventories. Approximately 92% of Fortune 500 companies responding to the CDP—an investor-led effort to increase corporate carbon disclosures—referenced the used the GHGP Corporate Standard to conduct their GHG inventories. Also, many other GHG-related standards—such as the Natural Capital Partner’s CarbonNeutral Protocol and the Science Based Targets Initiative (SBTi)—point to the Greenhouse Gas Protocol as the commonplace standard for the quantification and accounting of corporate GHG emissions. As future regulations and standards are developed and implemented, they may prescribe or encourage the use of Greenhouse Gas Protocol standards. +The GHG Protocol Corporate Accounting and Reporting Standard (GHGP Corporate Standard) is the world’s leading standard outlining requirements and guidance for corporate-level and organizational-level GHG emission inventories. Approximately 92% of Fortune 500 companies responding to the CDP—an investor-led effort to increase corporate carbon disclosures—referenced the used GHGP Corporate Standard to conduct their GHG inventories. Also, many other GHG-related standards—such as the Natural Capital Partner’s CarbonNeutral Protocol and the Science Based Targets Initiative (SBTi)—point to the Greenhouse Gas Protocol as the commonplace standard for the quantification and accounting of corporate GHG emissions. As future regulations and standards are developed and implemented, they may prescribe or encourage the use of Greenhouse Gas Protocol standards. This Guardian Policy mints Carbon Emission Tokens (CETs) in accordance with the GHGP Corporate Standard, including the Scope 2 Guidance, which was later published as an amendment to the GHGP Corporate Standard. In addition, the policy includes functionality to attribute emissions to products and services and use this data to calculate and publish product carbon footprints (PCFs) in accordance with the Pathfinder Framework v2.0. The policy and methodologies are designed to calculate emissions based on MRV data that can either be input manually by the organization, or automatically through API and trusted external data sources. The policy is equipped with standard emission factors (such as eGRID emission rates) and Intergovernmental Panel on Climate Change (IPCC) global warming potentials (GWPs). diff --git a/Methodology Library/Greenhouse Gas (GHG)/GHG Protocol Corporate Standard v3/README.md b/Methodology Library/Greenhouse Gas (GHG)/GHG Protocol Corporate Standard v3/README.md index d4fa3e2189..1647ef2957 100644 --- a/Methodology Library/Greenhouse Gas (GHG)/GHG Protocol Corporate Standard v3/README.md +++ b/Methodology Library/Greenhouse Gas (GHG)/GHG Protocol Corporate Standard v3/README.md @@ -25,7 +25,7 @@ ## Introduction -The GHG Protocol Corporate Accounting and Reporting Standard (GHGP Corporate Standard) is the world’s leading standard outlining requirements and guidance for corporate-level and organizational-level GHG emission inventories. As of 2023, approximately 97% of S&P 500 companies responding to the CDP an investor led effort to increase corporate carbon disclosures referenced the used the GHG Protocol to conduct their GHG inventories.[^1] Also, many other GHG-related frameworks and regulations such as the Corporate Sustainability Reporting Directive (CSRD) and the Science Based Targets Initiative (SBTi) point to the Greenhouse Gas Protocol as the default standard for the quantification and accounting of corporate GHG emissions. As future regulations and standards are developed and implemented, they are likely to either prescribe or encourage the use of Greenhouse Gas Protocol standards. +The GHG Protocol Corporate Accounting and Reporting Standard (GHGP Corporate Standard) is the world’s leading standard outlining requirements and guidance for corporate-level and organizational-level GHG emission inventories. As of 2023, approximately 97% of S&P 500 companies responding to the CDP an investor led effort to increase corporate carbon disclosures referenced the used GHG Protocol to conduct their GHG inventories.[^1] Also, many other GHG-related frameworks and regulations such as the Corporate Sustainability Reporting Directive (CSRD) and the Science Based Targets Initiative (SBTi) point to the Greenhouse Gas Protocol as the default standard for the quantification and accounting of corporate GHG emissions. As future regulations and standards are developed and implemented, they are likely to either prescribe or encourage the use of Greenhouse Gas Protocol standards. The GHGP Guardian Policy mints Carbon Emission Tokens (CETs) in accordance with the GHGP Corporate Standard, including the Scope 2 Guidance, which was later published as an amendment to the GHGP Corporate Standard. The policy and methodologies are designed to calculate emissions based on MRV data that can either be provided manually by the organization or automatically sourced via API from sources such as ERP systems and IoT-enabled meters. diff --git a/docs/available-policy-workflow-blocks/aggregatedocumentblock.md b/docs/available-policy-workflow-blocks/aggregatedocumentblock.md index 399f031f1e..51cfca2011 100644 --- a/docs/available-policy-workflow-blocks/aggregatedocumentblock.md +++ b/docs/available-policy-workflow-blocks/aggregatedocumentblock.md @@ -12,7 +12,7 @@ Output - an array of documents, after the reporting period expired or the condit | 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. | | | dependencies | Establish workflow dependancies that need to be completed prior. | Select the appropriate block from the dropdown. | Deprecated | -| On errors | Called if the system error has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | 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 |
  • Cumulative Dimension
  • Period
| | @@ -23,7 +23,7 @@ Output - an array of documents, after the reporting period expired or the condit 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 the variable + 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 diff --git a/docs/available-policy-workflow-blocks/buttonblock.md b/docs/available-policy-workflow-blocks/buttonblock.md index 4c631ed35b..709a11ae7c 100644 --- a/docs/available-policy-workflow-blocks/buttonblock.md +++ b/docs/available-policy-workflow-blocks/buttonblock.md @@ -7,7 +7,7 @@ | tag | Unique name for the logic block. | approve\__reject\_btn_ | | | 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 has occurs in the Block |

  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |

  • No action
  • Retry
  • Go to step
  • Go to tag
| | | stop Propagation | End processing here, don't pass control to the next block. | Checked or unchecked. | | ### Button diff --git a/docs/available-policy-workflow-blocks/customlogicblock.md b/docs/available-policy-workflow-blocks/customlogicblock.md index b16d65d3d2..6d7b468ae2 100644 --- a/docs/available-policy-workflow-blocks/customlogicblock.md +++ b/docs/available-policy-workflow-blocks/customlogicblock.md @@ -2,7 +2,7 @@ ## Properties -
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.multiSignBlock
permissionsWhich entity has rights to interact at this part of the workflow.NoRole
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error has occurs in the Block

  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
Output SchemaSending the logic output to this particular SchemaReport Employee schema
Document Signerdefines who will sign processed document.
Options:
1. Policy Owner
2. First Document Owner
3. First Document Issues		Policy Owner
Id Typedefines Id Type in credential subject of processed document.
Options:
1. DID (new DID)
2. UUID (new UUID)
3. Owner (Owner DID)		UUID (new UUID)
+
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.multiSignBlock
permissionsWhich entity has rights to interact at this part of the workflow.NoRole
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error occurs in the Block

  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
Output SchemaSending the logic output to this particular SchemaReport Employee schema
Document Signerdefines who will sign processed document.
Options:
1. Policy Owner
2. First Document Owner
3. First Document Issues		Policy Owner
Id Typedefines Id Type in credential subject of processed document.
Options:
1. DID (new DID)
2. UUID (new UUID)
3. Owner (Owner DID)		UUID (new UUID)
{% hint style="info" %} **Note:** Only this block supports artifacts for now. diff --git a/docs/available-policy-workflow-blocks/documentvalidatorblock.md b/docs/available-policy-workflow-blocks/documentvalidatorblock.md index 68eab9a919..d8c98c6d89 100644 --- a/docs/available-policy-workflow-blocks/documentvalidatorblock.md +++ b/docs/available-policy-workflow-blocks/documentvalidatorblock.md @@ -6,7 +6,7 @@ This block is to validate documents, including linked documents. This block retu ### Properties -
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.documentValidatorBlock
permissionsWhich entity has rights to interact at this part of the workflow.VVB
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error has occurs in the Block

  • No action
  • Retry
  • Go to step
  • Go to tag
stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
DocumentTypeType of the documents to be validated.

· VC Document

· VP Document

· Related VC
Document

. Related VP Document

Check SchemaValidates schema documents.Schema
Check Own DocumentIf ‘true’ validates document owners.True / False
Check Assign DocumentIf ‘true’ validates document owners.True / False
ConditionsArray containing conditions for validation.Array
+
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.documentValidatorBlock
permissionsWhich entity has rights to interact at this part of the workflow.VVB
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error occurs in the Block

  • No action
  • Retry
  • Go to step
  • Go to tag
stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
DocumentTypeType of the documents to be validated.

· VC Document

· VP Document

· Related VC
Document

. Related VP Document

Check SchemaValidates schema documents.Schema
Check Own DocumentIf ‘true’ validates document owners.True / False
Check Assign DocumentIf ‘true’ validates document owners.True / False
ConditionsArray containing conditions for validation.Array
@@ -27,14 +27,14 @@ The following document types are supported: #### Type: -1. Equal – resolves to ‘true’ if value of the field is equal the the content of the Value parameter. -2. Not Equal – resolves to ‘true’ if value of the field is NOT equal the the content of the Value parameter. -3. In – resolves to ‘true’ if value of the field is present the the array. -4. Not In – resolves to ‘true’ if value of the field is present the the array. +1. Equal – resolves to ‘true’ if the value of the field is equal to the content of the Value parameter. +2. Not Equal – resolves to ‘true’ if the value of the field is NOT equal the content of the Value parameter. +3. In – resolves to ‘true’ if the value of the field is present in the array. +4. Not In – resolves to ‘true’ if the value of the field is present in the array. -#### Field : +#### Field: -This field of the document to validates the Value parameter. +The Field of the document to validate the Value parameter. #### Value: diff --git a/docs/available-policy-workflow-blocks/groupmanagerblock.md b/docs/available-policy-workflow-blocks/groupmanagerblock.md index c4464b1470..91bbfbba2b 100644 --- a/docs/available-policy-workflow-blocks/groupmanagerblock.md +++ b/docs/available-policy-workflow-blocks/groupmanagerblock.md @@ -9,7 +9,7 @@ This block allows to manage group membership, add and remove users from the grou | 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | Stop Propagation | End processing here, don't pass control to the next block. | Checked or unchecked. | | | Can Invite | specifies who can create invites |

· Group Owner – only the creator of the group

· All – all members of the group

| | | Can Delete | specifies who can remove users from the group |

· Group Owner – only the creator of the group

. All – all members of the group

| | diff --git a/docs/available-policy-workflow-blocks/mintdocumentblock.md b/docs/available-policy-workflow-blocks/mintdocumentblock.md index 6fd271ff5a..b2b52279d5 100644 --- a/docs/available-policy-workflow-blocks/mintdocumentblock.md +++ b/docs/available-policy-workflow-blocks/mintdocumentblock.md @@ -4,7 +4,7 @@ This block is responsible for adding configurations on calculating the amount of ### Properties -
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.mintDocumentBlock
permissionsWhich entity has rights to interact at this part of the workflow.VVB
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error has occurs in the Block

  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
+
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.mintDocumentBlock
permissionsWhich entity has rights to interact at this part of the workflow.VVB
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error occurs in the Block

  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
### UI Properties @@ -15,7 +15,7 @@ This block is responsible for adding configurations on calculating the amount of | 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 filed is used to customize the Memo field name. | "mint date is $ {document.verifiableCredential\[0],credentialSubject\[0].field5}" | +| 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 | diff --git a/docs/available-policy-workflow-blocks/multisignblock.md b/docs/available-policy-workflow-blocks/multisignblock.md index 3399ea92f7..c08dd78ebd 100644 --- a/docs/available-policy-workflow-blocks/multisignblock.md +++ b/docs/available-policy-workflow-blocks/multisignblock.md @@ -9,7 +9,7 @@ This block provides a way to specify multiple signators for a single VC document | 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | 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 | | @@ -63,7 +63,7 @@ This block provides a way to specify multiple signators for a single VC document | Type of Decision | Description | | ----------------- | ---------------------------------------------------------------------------------------------------------- | | declinedCount | number of users who declined signing the document | -| declinedPercent | percentage of users who declined need 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 | diff --git a/docs/available-policy-workflow-blocks/revokeblock.md b/docs/available-policy-workflow-blocks/revokeblock.md index 03392e9498..70974c015d 100644 --- a/docs/available-policy-workflow-blocks/revokeblock.md +++ b/docs/available-policy-workflow-blocks/revokeblock.md @@ -9,7 +9,7 @@ This block finds related messages in policy topics, and revokes those messages a | tag | Unique name for the logic block. | revoke\__issue\_device_ | | | 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 has occurs in the Block |

  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |

  • No action
  • Retry
  • Go to step
  • Go to tag
| | | 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 | | diff --git a/docs/available-policy-workflow-blocks/setrelationshipsblock.md b/docs/available-policy-workflow-blocks/setrelationshipsblock.md index c08cbc1873..e0eaa9f3dd 100644 --- a/docs/available-policy-workflow-blocks/setrelationshipsblock.md +++ b/docs/available-policy-workflow-blocks/setrelationshipsblock.md @@ -4,13 +4,13 @@ This block contains DocumentsSourceAddOn and **set relationships** for input doc ### Properties -| Block Property | Definition | Example Input | Status | -| ---------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ------ | -| tag | Unique name for the logic block. | set\__relationships\_to\_rejected\_vvb_ | | -| permissions | Which entity has rights to interact at this part of the workflow. | VVB | | +| Block Property | Definition | Example Input | Status | +| ---------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ------ | +| tag | Unique name for the logic block. | set\__relationships\_to\_rejected\_vvb_ | | +| 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 has occurs in the Block |

  • No action
  • Retry
  • Go to step
  • Go to tag
| | -| 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. | | +| On errors | Called if the system error occurs in the Block |

  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| 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. | | diff --git a/docs/available-policy-workflow-blocks/splitblock.md b/docs/available-policy-workflow-blocks/splitblock.md index 5cc7fb6c5b..b2668f7d66 100644 --- a/docs/available-policy-workflow-blocks/splitblock.md +++ b/docs/available-policy-workflow-blocks/splitblock.md @@ -2,13 +2,13 @@ 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. +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 -
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.multiSignBlock
permissionsWhich entity has rights to interact at this part of the workflow.NoRole
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error has occurs in the Block

  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
ThresholdThe size of a single ‘portion’ (chunk) the original document would be “split” into.
Note: It is always number>0		1000
Source fieldIt is the path to the field in the VC document which is the parameter used in the calculation of the ‘size’ of the VC.
Note: is a field to which the ‘source field’ path points. It must be of numeric type.		source path link
+
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.multiSignBlock
permissionsWhich entity has rights to interact at this part of the workflow.NoRole
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error occurs in the Block

  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
ThresholdThe size of a single ‘portion’ (chunk) the original document would be split into.
Note: It is always number>0		1000
Source fieldIt is the path to the field in the VC document which is the parameter used in the calculation of the ‘size’ of the VC.
Note: is a field to which the ‘source field’ path points. It must be of numeric type.		source path link
## 2. Data(VC documents) format diff --git a/docs/available-policy-workflow-blocks/switchblock.md b/docs/available-policy-workflow-blocks/switchblock.md index d630bc12f8..ba58cd19a4 100644 --- a/docs/available-policy-workflow-blocks/switchblock.md +++ b/docs/available-policy-workflow-blocks/switchblock.md @@ -2,20 +2,20 @@ ### 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 | | +| 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | -| stop Propagation | End processing here, don't pass control to the next block. | Checked or Unchecked | | -| Execution Flow | Flow of Execution |
  1. First True - only the ‘branch’ under the first ‘true’ condition gets executed.
  2. 2. All True - branches under all conditions evaluated as ‘true’ get executed.
| | -| 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 | | -| Target Block | the block which gets executed when the condition is true | Block\_1 | Deprecated | -| Condition Tag | The name of the dynamic events to use | Condition 1 | | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| stop Propagation | End processing here, don't pass control to the next block. | Checked or Unchecked | | +| Execution Flow | Flow of Execution |
  1. First True - only the ‘branch’ under the first ‘true’ condition gets executed.
  2. 2. All True - branches under all conditions evaluated as ‘true’ get executed.
| | +| 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 | | +| Target Block | the block which gets executed when the condition is true | Block\_1 | Deprecated | +| Condition Tag | The name of the dynamic events to use | Condition 1 | | ![](../.gitbook/assets/Events\_11.png) diff --git a/docs/available-policy-workflow-blocks/timerblock.md b/docs/available-policy-workflow-blocks/timerblock.md index 3abf5c50b9..38e47964ed 100644 --- a/docs/available-policy-workflow-blocks/timerblock.md +++ b/docs/available-policy-workflow-blocks/timerblock.md @@ -10,11 +10,11 @@ Input - document which is needed to start the timer for different users separate | 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. | | | dependencies | Establish workflow dependancies that need to be completed prior. | Select the appropriate block from the dropdown. | Deprecated | -| On errors | Called if the system error has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | 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 which timer triggers (starting from the Start Date) |

Yearly

Monthly

Weekly

Daily

Hourly

Custom - advanced period

configuration

If ‘Period’ = ‘Custom’
Mask - cron mask for timer (example: https://crontab.guru/)
Interval (number) - trigger timer on every tick
(e.g. every two days)

| | +| Period | specification of the period which timer triggers (starting from the Start Date) |

Yearly

Monthly

Weekly

Daily

Hourly

Custom - advanced period

configuration

If ‘Period’ = ‘Custom’
Mask - cron mask for timer (example: https://crontab.guru/)
Interval (number) - trigger timer on every tick
(e.g. every two days)

| | | Custom Period | open dialogue window to set Mask and Interval | 0 12 \*\*\*\* 4 | | ### Events diff --git a/docs/available-policy-workflow-blocks/tokenactionblock.md b/docs/available-policy-workflow-blocks/tokenactionblock.md index b3893cff54..e32f5ba021 100644 --- a/docs/available-policy-workflow-blocks/tokenactionblock.md +++ b/docs/available-policy-workflow-blocks/tokenactionblock.md @@ -4,7 +4,7 @@ This block is responsible in performing automatic actions on the token. ### Properties -
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.tokenActionBlock
permissionsWhich entity has rights to interact at this part of the workflow.VVB
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error has occurs in the Block

  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
TokenThe token which is affected by the actioniREC token
Account Type

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).

If set to ‘Custom’ the account specified in the ‘accountId’ field is used.

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
ActionAction to be performed on Token

  • Associate
  • Dissociate
  • Freeze
  • Unfreeze
  • Grant Kyc
  • Revoke Kyc
Use TemplateThis needs to be enabled if we need to use token template, which is created already.Enabled or Disabled
Token TemplateWhich will take created tokenId from input document by template nametoken_template_0
+
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.tokenActionBlock
permissionsWhich entity has rights to interact at this part of the workflow.VVB
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error occurs in the Block

  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
TokenThe token which is affected by the actioniREC token
Account Type

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).

If set to ‘Custom’ the account specified in the ‘accountId’ field is used.

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
ActionAction to be performed on Token

  • Associate
  • Dissociate
  • Freeze
  • Unfreeze
  • Grant Kyc
  • Revoke Kyc
Use TemplateThis needs to be enabled if we need to use token template, which is created already.Enabled or Disabled
Token TemplateWhich will take created tokenId from input document by template nametoken_template_0
diff --git a/docs/available-policy-workflow-blocks/tokenconfirmationblock.md b/docs/available-policy-workflow-blocks/tokenconfirmationblock.md index b85204766d..70eaf6e06d 100644 --- a/docs/available-policy-workflow-blocks/tokenconfirmationblock.md +++ b/docs/available-policy-workflow-blocks/tokenconfirmationblock.md @@ -9,7 +9,7 @@ This block enables the owner of the private key for the account to manually perf | 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | 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 |

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).

If set to ‘Custom’ the account specified in the ‘accountId’ field is used.

| Custom | | diff --git a/docs/guardian-in-production/api-architecture-customization.md b/docs/guardian-in-production/api-architecture-customization.md index 01b61917ff..ba5309a7ca 100644 --- a/docs/guardian-in-production/api-architecture-customization.md +++ b/docs/guardian-in-production/api-architecture-customization.md @@ -154,7 +154,7 @@ app.listen(port, () => { ``` -After that, we can apply a bunch of improvements such us middlewares or even packages to increase the security. In this case some packages are recommended: +After that, we can apply a bunch of improvements such as middlewares or even packages to increase the security. In this case some packages are recommended: **Helmet**: Helmet is a middleware package that adds various HTTP headers to your responses to increase security. These headers can help to protect against various attacks, such as cross-site scripting (XSS), clickjacking, and cross-site request forgery (CSRF). @@ -167,7 +167,7 @@ After that, we can apply a bunch of improvements such us middlewares or even pac ## 3. Dead letter/Retries \ -For some kinds of events due to their own criticality, it would be interesting to contain a recovery or a mechanism to rerun specific payloads, such as dead-letter resources to handle unsubscribed events or even to handle subscriptions that could not run properly. Many applications contain this kind of solution such us Google Pub/Sub, AWS SQS, and so on. +For some kinds of events due to their own criticality, it would be interesting to contain a recovery or a mechanism to rerun specific payloads, such as dead-letter resources to handle unsubscribed events or even to handle subscriptions that could not run properly. Many applications contain this kind of solution such as Google Pub/Sub, AWS SQS, and so on. Recently we face a situation that leads some events in NATS to cause the TIMEOUT. In this situation, if we were in Production, we won’t be able to trigger these events again and all the messages would be lost. diff --git a/docs/guardian-in-production/cloud-infrastructure.md b/docs/guardian-in-production/cloud-infrastructure.md index 22c0ab8596..4c9de40126 100644 --- a/docs/guardian-in-production/cloud-infrastructure.md +++ b/docs/guardian-in-production/cloud-infrastructure.md @@ -31,7 +31,7 @@ Apache Mesos is a distributed systems kernel that can manage both containers and **Kubernetes: it can also help to manage and automate container deployments across multiple cloud environments. In fact, Kubernetes has become the standard for services/microservices architecture and our best option for faster support on different cloud providers.** -**Almost every cloud provider has its own implementation of managed kubernetes clusters, which eases the cluster creation and management, and withdrAWS the responsibility to the final user of maintaining the control plane and the worker nodes.** +**Almost every cloud provider has its own implementation of managed kubernetes clusters, which eases the cluster creation and management, and withdraws the responsibility to the final user of maintaining the control plane and the worker nodes.** ### Kubernetes packages diff --git a/docs/guardian/automation-testing/performing-ui-automation-testing.md b/docs/guardian/automation-testing/performing-ui-automation-testing.md index 597ea2d24d..d1f67ce14f 100644 --- a/docs/guardian/automation-testing/performing-ui-automation-testing.md +++ b/docs/guardian/automation-testing/performing-ui-automation-testing.md @@ -30,7 +30,7 @@ Finally, all the selected test runs and you can see the key components of the Te
-**Test Status Menu:** The menu shows a summary of the number of tests passed, passed, failed, or incomplete, and the time spent on the test. +**Test Status Menu:** The menu shows a summary of the number of tests pending, passed, failed, or incomplete, and the time spent on the test. **URL Preview:** Shows the URL of the test, helps track the URL. diff --git a/docs/guardian/community-standards/guardian-policy-standards-gps.md b/docs/guardian/community-standards/guardian-policy-standards-gps.md index c52d446b00..977e406e2d 100644 --- a/docs/guardian/community-standards/guardian-policy-standards-gps.md +++ b/docs/guardian/community-standards/guardian-policy-standards-gps.md @@ -16,7 +16,7 @@ The GPS proposal process involves several stages: **Idea:** A proposer conceives an idea for a new policy that they believe will benefit the Guardian ecosystem. -**Draft:** The proposer drafts a GPS proposal following the requirements outlined above and submits it to the Guardian repository for review. In the case of a policy revision, release notes must be provided that detail the differences between the prior version of the policy and the new proposer. +**Draft:** The proposer drafts a GPS proposal following the requirements outlined above and submits it to the Guardian repository for review. In the case of a policy revision, release notes must be provided that detail the differences between the prior version of the policy and the new proposal. **Review:** The responsibility lies with the proposer to drive community review and acceptance. The proposer should solicit feedback and address any questions or concerns raised by the community. diff --git a/docs/guardian/demo-guide/carbon-emissions/ghgp-corporate-standard-v2.md b/docs/guardian/demo-guide/carbon-emissions/ghgp-corporate-standard-v2.md index 538149643c..8e3a4c2a94 100644 --- a/docs/guardian/demo-guide/carbon-emissions/ghgp-corporate-standard-v2.md +++ b/docs/guardian/demo-guide/carbon-emissions/ghgp-corporate-standard-v2.md @@ -28,7 +28,7 @@ ### Introduction -The GHG Protocol Corporate Accounting and Reporting Standard (GHGP Corporate Standard) is the world’s leading standard outlining requirements and guidance for corporate-level and organizational-level GHG emission inventories. Approximately 92% of Fortune 500 companies responding to the CDP—an investor-led effort to increase corporate carbon disclosures—referenced the used the GHGP Corporate Standard to conduct their GHG inventories.\[1] Also, many other GHG-related standards—such as the Natural Capital Partner’s CarbonNeutral Protocol and the Science Based Targets Initiative (SBTi)—point to the Greenhouse Gas Protocol as the commonplace standard for the quantification and accounting of corporate GHG emissions. As future regulations and standards are developed and implemented, they may either prescribe or encourage the use of Greenhouse Gas Protocol standards. +The GHG Protocol Corporate Accounting and Reporting Standard (GHGP Corporate Standard) is the world’s leading standard outlining requirements and guidance for corporate-level and organizational-level GHG emission inventories. Approximately 92% of Fortune 500 companies responding to the CDP—an investor-led effort to increase corporate carbon disclosures—referenced the used GHGP Corporate Standard to conduct their GHG inventories.\[1] Also, many other GHG-related standards—such as the Natural Capital Partner’s CarbonNeutral Protocol and the Science Based Targets Initiative (SBTi)—point to the Greenhouse Gas Protocol as the commonplace standard for the quantification and accounting of corporate GHG emissions. As future regulations and standards are developed and implemented, they may either prescribe or encourage the use of Greenhouse Gas Protocol standards. This Guardian Policy mints Carbon Emission Tokens (CETs) in accordance with the GHGP Corporate Standard, including the Scope 2 Guidance, which was later published as an amendment to the GHGP Corporate Standard. In addition, the policy includes functionality to attribute emissions to products and services and use this data to calculate and publish product carbon footprints (PCFs) in accordance with the Pathfinder Framework v2.0. The policy and methodologies are designed to calculate emissions based on MRV data that can either be input manually by the organization, or automatically through API and trusted external data sources. The policy is equipped with standard emission factors (such as eGRID emission rates) and Intergovernmental Panel on Climate Change (IPCC) global warming potentials (GWPs). diff --git a/docs/guardian/demo-guide/carbon-emissions/ghgp-corporate-standard.md b/docs/guardian/demo-guide/carbon-emissions/ghgp-corporate-standard.md index 760d909db6..f766753037 100644 --- a/docs/guardian/demo-guide/carbon-emissions/ghgp-corporate-standard.md +++ b/docs/guardian/demo-guide/carbon-emissions/ghgp-corporate-standard.md @@ -34,7 +34,7 @@ description: This policy is developed by Envision ## Introduction -The GHG Protocol Corporate Accounting and Reporting Standard (GHGP Corporate Standard) is the world’s leading standard outlining requirements and guidance for corporate-level and organizational-level GHG emission inventories. As of 2016, approximately 92% of Fortune 500 companies responding to the CDP—an investor-led effort to increase corporate carbon disclosures—referenced the used the GHGP Corporate Standard to conduct their GHG inventories.\[1] Also, many other GHG-related standards—such as the Natural Capital Partner’s CarbonNeutral Protocol and the Science Based Targets Initiative (SBTi)—point to the Greenhouse Gas Protocol as the default standard for the quantification and accounting of corporate GHG emissions. As future regulations and standards are developed and implemented, they are likely to either prescribe or encourage the use of Greenhouse Gas Protocol standards. +The GHG Protocol Corporate Accounting and Reporting Standard (GHGP Corporate Standard) is the world’s leading standard outlining requirements and guidance for corporate-level and organizational-level GHG emission inventories. As of 2016, approximately 92% of Fortune 500 companies responding to the CDP—an investor-led effort to increase corporate carbon disclosures—referenced the used GHGP Corporate Standard to conduct their GHG inventories.\[1] Also, many other GHG-related standards—such as the Natural Capital Partner’s CarbonNeutral Protocol and the Science Based Targets Initiative (SBTi)—point to the Greenhouse Gas Protocol as the default standard for the quantification and accounting of corporate GHG emissions. As future regulations and standards are developed and implemented, they are likely to either prescribe or encourage the use of Greenhouse Gas Protocol standards. This Guardian Policy mints Carbon Emission Tokens (CETs) in accordance with the GHGP Corporate Standard, including the Scope 2 Guidance, which was later published as an amendment to the GHGP Corporate Standard. The policy and methodologies are designed to calculate emissions based on MRV data that can either be manually input, or automatically transmitted by devices such as IoT-enabled electricity meters. The policy is equipped with standard emission factors (such as eGRID emission rates) and Intergovernmental Panel on Climate Change (IPCC) global warming potentials (GWPs). diff --git a/docs/guardian/guidance-for-open-source-policy.md b/docs/guardian/guidance-for-open-source-policy.md index 3a416c4cab..4e84b0345f 100644 --- a/docs/guardian/guidance-for-open-source-policy.md +++ b/docs/guardian/guidance-for-open-source-policy.md @@ -28,7 +28,7 @@ This policy supports the tokenization of Renewable Energy Certificates (RECs) in **Workflow Description**: -The workflow begins with the Registrant, generally the owner of an energy production facility or a party acting in their behalf, submitting an application to the Issuer for approval. Once approved, the Registrant submits a registration request to the Issuer for the facility/device that will be providing the MRV data. This will include both general information, as well as attributes (e.g., energy sources, location, etc.). Note that devices must be, and often are already, independently verified. Under certain circumstances an inspection may be necessary. Once the Issuer processed and approves the facility/device registration, an issue request can be sent to the Issuer along with independently verified meter data. After the Issuer approves the issue request, I-REC(E) certificates are issued. +The workflow begins with the Registrant, generally the owner of an energy production facility or a party acting on their behalf, submitting an application to the Issuer for approval. Once approved, the Registrant submits a registration request to the Issuer for the facility/device that will be providing the MRV data. This will include both general information, as well as attributes (e.g., energy sources, location, etc.). Note that devices must be, and often are already, independently verified. Under certain circumstances an inspection may be necessary. Once the Issuer processes and approves the facility/device registration, an issue request can be sent to the Issuer along with independently verified meter data. After the Issuer approves the issue request, I-REC(E) certificates are issued.
diff --git a/docs/guardian/readme/guardian-glossary.md b/docs/guardian/readme/guardian-glossary.md index 56a00ef6a7..b00bd04f35 100644 --- a/docs/guardian/readme/guardian-glossary.md +++ b/docs/guardian/readme/guardian-glossary.md @@ -1,19 +1,19 @@ # 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. | +| 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 a 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 | +| 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 | diff --git a/docs/guardian/standard-registry/asynchronous-tasks-status.md b/docs/guardian/standard-registry/asynchronous-tasks-status.md index 677665bf12..d0669a8f20 100644 --- a/docs/guardian/standard-registry/asynchronous-tasks-status.md +++ b/docs/guardian/standard-registry/asynchronous-tasks-status.md @@ -14,4 +14,4 @@ Worker Tasks tab displays active user's jobs performed asynchronously by the ‘
-Architecturally, all errors (if any) are passed back to the Guardian process initiated the task (e.g. ‘publish schema’), which may result in the entire execution flow being rolled back. In the case of task manual restart and its successful completion the success status is passed back to the process originally initiated the task. +Architecturally, all errors (if any) are passed back to the Guardian process that initiated the task (e.g. ‘publish schema’), which may result in the entire execution flow being rolled back. In the case of task manual restart and its successful completion the success status is passed back to the process originally initiated the task. diff --git a/docs/guardian/standard-registry/policies/library-of-policy-examples/README.md b/docs/guardian/standard-registry/policies/library-of-policy-examples/README.md index ccf63adc15..dd6f3a2266 100644 --- a/docs/guardian/standard-registry/policies/library-of-policy-examples/README.md +++ b/docs/guardian/standard-registry/policies/library-of-policy-examples/README.md @@ -1,6 +1,6 @@ # Library of Policy Examples -Guardian ecosystem is enriched with a comprehensive "Library of Policy Examples," designed to facilitate and inspire the development of robust and effective policies for managing digital environmental assets. This library serves as a foundational resource for users navigating the complexities of policy creation within the the Guardian platform. +Guardian ecosystem is enriched with a comprehensive "Library of Policy Examples," designed to facilitate and inspire the development of robust and effective policies for managing digital environmental assets. This library serves as a foundational resource for users navigating the complexities of policy creation within the Guardian platform. ### Description of the Library of Policy Examples diff --git a/docs/guardian/standard-registry/policies/policy-creation/creating-a-policy-through-policy-configurator/policy-workflow-step-11.md b/docs/guardian/standard-registry/policies/policy-creation/creating-a-policy-through-policy-configurator/policy-workflow-step-11.md index aee3a2604c..254e87d1c5 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/creating-a-policy-through-policy-configurator/policy-workflow-step-11.md +++ b/docs/guardian/standard-registry/policies/policy-creation/creating-a-policy-through-policy-configurator/policy-workflow-step-11.md @@ -83,7 +83,7 @@ To do that, we click on the “sensors\_grid” button, and then click on “Bin "dialogClass": "", //"dialogType" - currently only json type is supported. "dialogType": "json" - // additionally specifying a "bindBlock" field would result in the display of the linked block in side the dialog. + // additionally specifying a "bindBlock" field would result in the display of the linked block inside the dialog. }, { "name": "document.id", diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/aggregatedocumentblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/aggregatedocumentblock.md index cdf272d24d..02a931474d 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/aggregatedocumentblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/aggregatedocumentblock.md @@ -11,7 +11,7 @@ Output - an array of documents, after the reporting period expired or the condit | 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | 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 |
  • Cumulative Dimension
  • Period
| | @@ -20,7 +20,7 @@ Output - an array of documents, after the reporting period expired or the condit 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 the variable + 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 diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/buttonblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/buttonblock.md index ae246be413..e980f02d54 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/buttonblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/buttonblock.md @@ -7,7 +7,7 @@ | 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | stop Propagation | End processing here, don't pass control to the next block. | Checked or unchecked. | | ### Button diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/customlogicblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/customlogicblock.md index 4aba32ebce..47f0c18cfd 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/customlogicblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/customlogicblock.md @@ -2,7 +2,7 @@ ## Properties -
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.customLogicBlock
permissionsWhich entity has rights to interact at this part of the workflow.NoRole
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error has occurs in the Block
  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
Output SchemaSending the logic output to this particular SchemaReport Employee schema
Document Signerdefines who will sign processed document.
Options:
1. Policy Owner
2. First Document Owner
3. First Document Issues		Policy Owner
Id Typedefines Id Type in credential subject of processed document.
Options:
1. DID (new DID)
2. UUID (new UUID)
3. Owner (Owner DID)		UUID (new UUID)
+
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.customLogicBlock
permissionsWhich entity has rights to interact at this part of the workflow.NoRole
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error occurs in the Block
  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
Output SchemaSending the logic output to this particular SchemaReport Employee schema
Document Signerdefines who will sign processed document.
Options:
1. Policy Owner
2. First Document Owner
3. First Document Issues		Policy Owner
Id Typedefines Id Type in credential subject of processed document.
Options:
1. DID (new DID)
2. UUID (new UUID)
3. Owner (Owner DID)		UUID (new UUID)
{% hint style="info" %} **Note:** Only this block supports artifacts for now. diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/documentvalidatorblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/documentvalidatorblock.md index 415e2a2873..46a13125b1 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/documentvalidatorblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/documentvalidatorblock.md @@ -6,7 +6,7 @@ This block is to validate documents, including linked documents. This block retu ### Properties -
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.documentValidatorBlock
permissionsWhich entity has rights to interact at this part of the workflow.VVB
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error has occurs in the Block
  • No action
  • Retry
  • Go to step
  • Go to tag
stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
DocumentTypeType of the documents to be validated.

· VC Document

· VP Document

· Related VC
Document

. Related VP Document

Check SchemaValidates schema documents.Schema
Check Own DocumentIf ‘true’ validates document owners.True / False
Check Assign DocumentIf ‘true’ validates document owners.True / False
ConditionsArray containing conditions for validation.Array
+
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.documentValidatorBlock
permissionsWhich entity has rights to interact at this part of the workflow.VVB
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error occurs in the Block
  • No action
  • Retry
  • Go to step
  • Go to tag
stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
DocumentTypeType of the documents to be validated.

· VC Document

· VP Document

· Related VC
Document

. Related VP Document

Check SchemaValidates schema documents.Schema
Check Own DocumentIf ‘true’ validates document owners.True / False
Check Assign DocumentIf ‘true’ validates document owners.True / False
ConditionsArray containing conditions for validation.Array
![](<../../../../../.gitbook/assets/image (23) (5) (1).png>) @@ -25,14 +25,14 @@ The following document types are supported: #### Type: -1. Equal – resolves to ‘true’ if value of the field is equal the the content of the Value parameter. -2. Not Equal – resolves to ‘true’ if value of the field is NOT equal the the content of the Value parameter. -3. In – resolves to ‘true’ if value of the field is present the the array. -4. Not In – resolves to ‘true’ if value of the field is present the the array. +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 validates the Value parameter. +This field of the document to validate the Value parameter. #### Value: diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/externaltopicblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/externaltopicblock.md index 8f85f54932..3baf8347c6 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/externaltopicblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/externaltopicblock.md @@ -12,7 +12,7 @@ This block allows to configure the link to Hedera topics established by other po | 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 has occurs in the Block |

- No action
- Retry

| | +| On Errors | Called if the system error occurs in the Block |

- No action
- Retry

| | | 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 diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/groupmanagerblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/groupmanagerblock.md index c5885b233f..9110ae9e85 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/groupmanagerblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/groupmanagerblock.md @@ -9,7 +9,7 @@ This block allows to manage group membership, add and remove users from the grou | 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | Stop Propagation | End processing here, don't pass control to the next block. | Checked or unchecked. | | | Can Invite | specifies who can create invites |

· Group Owner – only the creator of the group

· All – all members of the group

| | | Can Delete | specifies who can remove users from the group |

· Group Owner – only the creator of the group

. All – all members of the group

| | diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/historyaddon.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/historyaddon.md index 1408bbcf07..e9bc45fe45 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/historyaddon.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/historyaddon.md @@ -10,7 +10,7 @@ This block turn on history on interfaceDocumentsSourceBlock. This block should b | 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 has occurs in the Block |

- No action
- Retry

| | +| On Errors | Called if the system error occurs in the Block |

- No action
- Retry

| | | 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 | | diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/http-request-block.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/http-request-block.md index 0905188f44..50a912080d 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/http-request-block.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/http-request-block.md @@ -10,7 +10,7 @@ Block for retrieving information from outside (3rd party) services via HTTP requ | 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 has occurs in the Block |

No action
Retry

| | +| On Errors | Called if the system error occurs in the Block |

No action
Retry

| | | 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) | | diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/impactaddon.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/impactaddon.md index 4546282451..effe7b2e81 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/impactaddon.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/impactaddon.md @@ -4,7 +4,7 @@ This Addon for the mint block which allows to add additional info for the token ### 1. Properties -
Property NameDescriptionExampleStatus
TagUnique name for the logic block.impactAddon_1
PermissionsWhich entity has rights to interact at this part of the workflow.Standard Registry
Default ActiveShows whether this block is active at this time and whether it needs to be shown.Checked or UnChecked
Stop PropagationEnd processing here, don't pass control to the next block.Checked or UnChecked
On ErrorsCalled if the system error has occurs in the Block
  • No action
  • Retry
  • Go to step
  • Go to tag
Impact Typeshows the type of the impactPrimary Impacts / Secondary Impacts
LabelTitle of the ImpactTest
DescriptionDescription of the impactImpact description
Amount (Formula)Formula for calculating the impact quantitative representation based on the data from the source VCfield0
UnitUnit of measurement of impact amountsKg
+
Property NameDescriptionExampleStatus
TagUnique name for the logic block.impactAddon_1
PermissionsWhich entity has rights to interact at this part of the workflow.Standard Registry
Default ActiveShows whether this block is active at this time and whether it needs to be shown.Checked or UnChecked
Stop PropagationEnd processing here, don't pass control to the next block.Checked or UnChecked
On ErrorsCalled if the system error occurs in the Block
  • No action
  • Retry
  • Go to step
  • Go to tag
Impact Typeshows the type of the impactPrimary Impacts / Secondary Impacts
LabelTitle of the ImpactTest
DescriptionDescription of the impactImpact description
Amount (Formula)Formula for calculating the impact quantitative representation based on the data from the source VCfield0
UnitUnit of measurement of impact amountsKg
diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/mintdocumentblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/mintdocumentblock.md index b526173c18..897000e94f 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/mintdocumentblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/mintdocumentblock.md @@ -4,7 +4,7 @@ This block is responsible for adding configurations on calculating the amount of ### Properties -
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.mintDocumentBlock
permissionsWhich entity has rights to interact at this part of the workflow.VVB
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error has occurs in the Block
  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
+
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.mintDocumentBlock
permissionsWhich entity has rights to interact at this part of the workflow.VVB
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error occurs in the Block
  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
### UI Properties @@ -15,7 +15,7 @@ This block is responsible for adding configurations on calculating the amount of | 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 filed is used to customize the Memo field name. | "mint date is $ {document.verifiableCredential\[0],credentialSubject\[0].field5}" | +| 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 | diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/multisignblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/multisignblock.md index ea59736510..d6d8176ace 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/multisignblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/multisignblock.md @@ -9,7 +9,7 @@ This block provides a way to specify multiple signators for a single VC document | 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | 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 | | @@ -63,7 +63,7 @@ This block provides a way to specify multiple signators for a single VC document | Type of Decision | Description | | ----------------- | ---------------------------------------------------------------------------------------------------------- | | declinedCount | number of users who declined signing the document | -| declinedPercent | percentage of users who declined need 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 | diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/notificationblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/notificationblock.md index 92f9772e2f..5df1398463 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/notificationblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/notificationblock.md @@ -12,7 +12,7 @@ This Block is used to generate Notifications. | 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 has occurs in the Block |

- No action
- Retry

| | +| On Errors | Called if the system error occurs in the Block |

- No action
- Retry

| | | Title | .Notification title | Schema Creation | | | Type | type of notification | ERROR, SUCCESS, INFO, WARN | | | Message | Notification message | Schema is created | | diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/revokeblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/revokeblock.md index 9b9ef04716..d73f323282 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/revokeblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/revokeblock.md @@ -9,7 +9,7 @@ This block finds related messages in policy topics, and revokes those messages a | 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | 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 | | diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/selectiveattributes-block.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/selectiveattributes-block.md index e02b9bcb9b..b9cf0e0ee1 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/selectiveattributes-block.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/selectiveattributes-block.md @@ -10,7 +10,7 @@ This Block can be placed inside documentsSourceAddon. This will filter attribute | 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 has occurs in the Block |

- No action
- Retry

| | +| On Errors | Called if the system error occurs in the Block |

- No action
- Retry

| | | Attributes | Array of attributes to select |

"attributes": [

{

"attributePath": "status"

},

Note: If value is empty no attributes will be selected and field option in returned documents will be empty.

| |
diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/send-workflow-block.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/send-workflow-block.md index bba601158d..1e8f72b5d8 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/send-workflow-block.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/send-workflow-block.md @@ -14,7 +14,7 @@ | 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 the topic itself. |

Current User - user whose credentials were used to make the current post request

Document Owner - creator of the document (has default value)

Document Issuer - user which was the last to sign the document

| | +| 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. |

Current User - user whose credentials were used to make the current post request

Document Owner - creator of the document (has default value)

Document Issuer - user which was the last to sign the document

| | | 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 | | diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/setrelationshipsblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/setrelationshipsblock.md index f58ed653d9..0c3a04fe22 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/setrelationshipsblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/setrelationshipsblock.md @@ -9,7 +9,7 @@ This block contains DocumentsSourceAddOn and **set relationships** for input doc | 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | 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. | | diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/splitblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/splitblock.md index 0bd90ea5ad..911060d44a 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/splitblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/splitblock.md @@ -2,11 +2,11 @@ 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. +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 -
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.splitBlock
permissionsWhich entity has rights to interact at this part of the workflow.NoRole
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error has occurs in the Block
  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
ThresholdThe size of a single ‘portion’ (chunk) the original document would be “split” into.
Note: It is always number>0		1000
Source fieldIt is the path to the field in the VC document which is the parameter used in the calculation of the ‘size’ of the VC.
Note: is a field to which the ‘source field’ path points. It must be of numeric type.		source path link
+
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.splitBlock
permissionsWhich entity has rights to interact at this part of the workflow.NoRole
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error occurs in the Block
  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
ThresholdThe size of a single ‘portion’ (chunk) the original document would be split into.
Note: It is always number>0		1000
Source fieldIt is the path to the field in the VC document which is the parameter used in the calculation of the ‘size’ of the VC.
Note: is a field to which the ‘source field’ path points. It must be of numeric type.		source path link
## 2. Data(VC documents) format diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/switchblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/switchblock.md index d1b61546b6..dc9f6e7831 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/switchblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/switchblock.md @@ -7,7 +7,7 @@ | 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | stop Propagation | End processing here, don't pass control to the next block. | Checked or Unchecked | | | Execution Flow | Flow of Execution |
  1. First True - only the ‘branch’ under the first ‘true’ condition gets executed.
  2. 2. All True - branches under all conditions evaluated as ‘true’ get executed.
| | | Condition(i) | number of the condition | if (field(0))>1 | | diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/tagsmanagerblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/tagsmanagerblock.md index fc43b0e75e..4577c8095b 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/tagsmanagerblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/tagsmanagerblock.md @@ -10,6 +10,6 @@ Block _**tagsManager**_ is responsible for managing tags in policies. This block | 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 has occurs in the Block |

- No action
- Retry

| | +| On Errors | Called if the system error occurs in the Block |

- No action
- Retry

| |
diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/timerblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/timerblock.md index 2da2c39700..ac3982b177 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/timerblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/timerblock.md @@ -9,11 +9,11 @@ Input - document which is needed to start the timer for different users separate | 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | 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 which timer triggers (starting from the Start Date) |

Yearly

Monthly

Weekly

Daily

Hourly

Custom - advanced period

configuration

If ‘Period’ = ‘Custom’
Mask - cron mask for timer (example: https://crontab.guru/)
Interval (number) - trigger timer on every tick
(e.g. every two days)

| | +| Period | specification of the period which timer triggers (starting from the Start Date) |

Yearly

Monthly

Weekly

Daily

Hourly

Custom - advanced period

configuration

If ‘Period’ = ‘Custom’
Mask - cron mask for timer (example: https://crontab.guru/)
Interval (number) - trigger timer on every tick
(e.g. every two days)

| | | Custom Period | open dialogue window to set Mask and Interval | 0 12 \*\*\*\* 4 | | ### Events diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/tokenactionblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/tokenactionblock.md index 5e65dc9ce4..ff41feeb00 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/tokenactionblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/tokenactionblock.md @@ -4,7 +4,7 @@ This block is responsible in performing automatic actions on the token. ### Properties -
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.tokenActionBlock
permissionsWhich entity has rights to interact at this part of the workflow.VVB
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error has occurs in the Block
  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
TokenThe token which is affected by the actioniREC token
Account Type

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).

If set to ‘Custom’ the account specified in the ‘accountId’ field is used.

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
ActionAction to be performed on Token
  • Associate
  • Dissociate
  • Freeze
  • Unfreeze
  • Grant Kyc
  • Revoke Kyc
Use TemplateThis needs to be enabled if we need to use token template, which is created already.Enabled or Disabled
Token TemplateWhich will take created tokenId from input document by template nametoken_template_0
+
Block PropertyDefinitionExample InputStatus
tagUnique name for the logic block.tokenActionBlock
permissionsWhich entity has rights to interact at this part of the workflow.VVB
defaultActiveShows whether this block is active at this time and whether it needs to be shown.Checked or unchecked.
On errorsCalled if the system error occurs in the Block
  • No action
  • Retry
  • Go to step
  • Go to tag
Stop PropagationEnd processing here, don't pass control to the next block.Checked or unchecked.
TokenThe token which is affected by the actioniREC token
Account Type

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).

If set to ‘Custom’ the account specified in the ‘accountId’ field is used.

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
ActionAction to be performed on Token
  • Associate
  • Dissociate
  • Freeze
  • Unfreeze
  • Grant Kyc
  • Revoke Kyc
Use TemplateThis needs to be enabled if we need to use token template, which is created already.Enabled or Disabled
Token TemplateWhich will take created tokenId from input document by template nametoken_template_0
![](<../../../../../.gitbook/assets/image (17) (3).png>) diff --git a/docs/guardian/standard-registry/policies/policy-creation/introduction/tokenconfirmationblock.md b/docs/guardian/standard-registry/policies/policy-creation/introduction/tokenconfirmationblock.md index 08fda5c52a..59634f6762 100644 --- a/docs/guardian/standard-registry/policies/policy-creation/introduction/tokenconfirmationblock.md +++ b/docs/guardian/standard-registry/policies/policy-creation/introduction/tokenconfirmationblock.md @@ -9,7 +9,7 @@ This block enables the owner of the private key for the account to manually perf | 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 has occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | +| On errors | Called if the system error occurs in the Block |
  • No action
  • Retry
  • Go to step
  • Go to tag
| | | 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 |

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).

If set to ‘Custom’ the account specified in the ‘accountId’ field is used.

| Custom | | diff --git a/docs/guardian/standard-registry/schemas/system-policy-schemas.md b/docs/guardian/standard-registry/schemas/system-policy-schemas.md index d6a24e34f9..116a7227c2 100644 --- a/docs/guardian/standard-registry/schemas/system-policy-schemas.md +++ b/docs/guardian/standard-registry/schemas/system-policy-schemas.md @@ -55,6 +55,6 @@ To create module schema, we need to click on Create New button: ### Using schemas: -Select module schema in “BaseSchema” fileld in module variables section +Select module schema in “BaseSchema” field in module variables section
diff --git a/docs/guardian/standard-registry/trustchain/README.md b/docs/guardian/standard-registry/trustchain/README.md index 379832425f..097abd76ed 100644 --- a/docs/guardian/standard-registry/trustchain/README.md +++ b/docs/guardian/standard-registry/trustchain/README.md @@ -2,7 +2,7 @@ ### Introduction -In the ever-evolving landscape of digital asset management and environmental sustainability, Guardian introduces a groundbreaking feature known as the Trust Chain. This component is crucial for establishing verifiable and transparent chains of custody for digital environmental assets, ensuring the integrity and reliability of transactions within the the Guardian ecosystem. +In the ever-evolving landscape of digital asset management and environmental sustainability, Guardian introduces a groundbreaking feature known as the Trust Chain. This component is crucial for establishing verifiable and transparent chains of custody for digital environmental assets, ensuring the integrity and reliability of transactions within the Guardian ecosystem. ### Description diff --git a/docs/guardian/users/user-profile-setup.md b/docs/guardian/users/user-profile-setup.md index 779d3a064a..e8eefa1ac0 100644 --- a/docs/guardian/users/user-profile-setup.md +++ b/docs/guardian/users/user-profile-setup.md @@ -20,7 +20,7 @@ Users are able to filter the list of standard registries by policy name and geog
-One the user has clicked on "Apply" they can see the Standard Registry related by the policy name and geography. +Once the user has clicked on "Apply" they can see the Standard Registry related by the policy name and geography.
diff --git a/docs/user-guide-glossary/guardian-glossary.md b/docs/user-guide-glossary/guardian-glossary.md index 62a17173ea..e1118f2a95 100644 --- a/docs/user-guide-glossary/guardian-glossary.md +++ b/docs/user-guide-glossary/guardian-glossary.md @@ -1,19 +1,19 @@ # 🎓 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. | +| 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 a 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 | +| 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 |