> For the complete documentation index, see [llms.txt](https://docs.openg2p.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/releases/v1.0.0.md). # v1.0.0 AWE Release Notes for v1.0.0 ### Release version: 1.0.0 ### Release date: 19th June 2026 ## Summary AWE Release 1.0.0 is the first tagged release of the **Approval Workflow Engine** — the platform-level service that governs multi-stage approvals for OpenG2P modules. Caller services (Registry, PBMS, and others) post artifacts for approval; AWE resolves stages and approvers, tracks decisions, and notifies callers via HMAC-signed webhook callbacks when the outcome is known. The Registry is the first concrete caller integration. AWE replaces the Registry's single-step change-request approval with configurable, multi-stage workflows while leaving the rest of the change-request machinery (history inserts, register upserts, document handling) untouched. ## Features of this release ### openg2p-awe (backend) 1. **Versioned approval policies** — draft/edit/activate lifecycle; in-flight requests stay pinned to the policy version they started with 2. **Flexible approver resolution** — `user`, Keycloak `role`, `group`, JSONLogic `expression`, and caller `http` resolver rules 3. **Stage decision modes** — `all`, `any-N`, `quorum:N`, `percentage:P`, with conditional `skip_if` and `on_empty` handling 4. **Signed webhook callbacks** — HMAC-SHA256 over timestamp + body; exponential retry schedule on non-2xx responses 5. **Idempotent request creation** — `Idempotency-Key` header deduplicates retried `POST /v1/awe/requests` calls 6. **Immutable audit timeline** — every state transition recorded as an `approval_event` 7. **SLA enforcement** — per-stage `sla_hours` with configurable `on_breach` behaviour 8. **Delegation, reassignment, observers, and segregation-of-duties** support ### openg2p-awe-ui (admin) 1. Policy authoring and activation UI served at `/admin` 2. nginx-served SPA with API proxy to the backend ### Helm chart (`openg2p-awe`) 1. Backend + admin UI deployments 2. PostgreSQL database/role provisioning via `postgres-init` subchart 3. Keycloak OIDC client provisioning via `keycloak-init` subchart (`awe-admin-portal`, `awe-admin-resolver`) 4. Published to [openg2p-helm](https://openg2p.github.io/openg2p-helm) on tag push ## Release contents | Release item | Links | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **AWE source code** | [awe:v1.0.0](https://github.com/OpenG2P/awe/-/tags/v1.0.0) | | **Packaged dockers** | [openg2p-awe:v1.0.0](https://hub.docker.com/r/openg2p/openg2p-awe/tags), [openg2p-awe-ui:v1.0.0](https://hub.docker.com/r/openg2p/openg2p-awe-ui/tags) | | **Helm chart** | `openg2p-awe` v1.0.0 — [`helm/openg2p-awe/`](https://github.com/OpenG2P/awe/tree/v1.0.0/helm/openg2p-awe) | | **Documentation** | [AWE Documentation](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/) | | **API reference** | [Live OpenAPI](https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/api-reference.md), [openapi.json](https://github.com/OpenG2P/awe/blob/v1.0.0/docs/openapi.json) | | **Registry integration** | [Integration with Registry](/platform/platform-services/approval-workflow-engine/integration-with-registry.md) | ## Deploy To deploy AWE on Kubernetes, see the [Deployment guide](/platform/platform-services/approval-workflow-engine/deployment.md). For local development, use `docker compose up --build` from the `awe` repository. When bundled inside a Registry Helm chart, AWE is deployed as a platform subchart with its own `_awe` database and Keycloak clients. ## Compatibility with Registry AWE v1.0.0 is designed to integrate with [`registry-platform` v1.0.0](https://github.com/OpenG2P/registry-platform/releases/tag/v1.0.0). The Registry acts as caller — submitting change requests, proxying approver task UI, and applying terminal webhook outcomes to `g2p_register_change_requests`. Registry Helm charts at `4.2.0-develop` and later bundle AWE as an integrated subchart. Earlier chart lines (4.0.0, 4.1.0) use the Registry's built-in single-step approval and do not require AWE. ## Limitations and known issues 1. Release 1.0.0 has been tested with Registry as the primary caller. PBMS and other caller integrations are planned. 2. Load testing and performance benchmarks at scale are ongoing. 3. On the `develop` branch the Helm chart version remains `0.0.0-develop` until the next tagged release. --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.openg2p.org/platform/platform-services/approval-workflow-engine/releases/v1.0.0.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.