> For the complete documentation index, see [llms.txt](https://guardian.hedera.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guardian.hedera.com/docs/3.6.0/guardian/complex-iterative-review-and-approval-workflows.md).
# Complex iterative review and approval workflows
The Complex Iterative Workflow is a digital process within Guardian that enables project developers (proponents) and validators (VVBs) to efficiently perform multiple rounds of feedback, clarifications, and document corrections during validation. Instead of lengthy, fragmented exchanges via email or offline documents, every step is captured, versioned, and discussable inside the Guardian environment, providing a full audit trail and transparency at each stage of project review and approval.
### Multi-Stage, Multi-Role Feedback Loops
* **Field-Level Commenting**: Validators can annotate any field in the project document, identifying precisely what requires clarification, correction, or further detail.
* **Targeted Discussions**: Each comment generates a discussion thread linked to a specific document section, so issues remain contextualized and easily trackable.
* **Privacy Controls**: Each thread can be made public (visible to all roles), restricted to certain roles (e.g., only Validator and Registry), or assigned to specific users, ensuring sensitive topics remain confidential where necessary.
* **Role-Based Progression**: Only designated roles can advance the workflow to the next step, ensuring authorized actors are responsible for decision-making at each validation point.
### Iterative Updates and Resubmissions
* **Dynamic Correction Cycle**: Following a validator's comment, the project developer addresses the issue directly within the Guardian interface, updating specific fields and notifying reviewers of changes.
* **Repeatable Validation**: This loop (comment, correction, re-validation) continues as many times as necessary, until all outstanding questions are resolved and the project can be approved or validated.
* **Structured Statuses**: The platform automatically updates project status (e.g., Waiting for Clarification, Under Review, Ready for Validation) to reflect the state of each iterative loop.
### Complete Audit Trail and Digital Verifiability
* **Traceable Communication**: All comments, changes, and resolutions are timestamped and linked to both user identity and document version.
* **Transparent Accountability**: At any stage, stakeholders can review the entire back-and-forth – from initial submission through every cycle of clarification, correction, and approval – directly in Guardian.
### Why Use the Complex Iterative Workflow?
* **Clarity & Focus**: Every clarification stays linked to its context, reducing confusion and “lost in translation” risks.
* **Faster Resolution**: Developers know exactly what to correct and where, minimizing unnecessary delays due to vague feedback.
* **Confidentiality Options**: Not all discussions belong in the open; privacy controls make the workflow suitable for sensitive topics.
* **Verifiable History**: In regulated environments, being able to prove precisely who said what, when, and in which context is essential for audits and conflict resolution.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://guardian.hedera.com/docs/3.6.0/guardian/complex-iterative-review-and-approval-workflows.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.