From 97ad1550429384634ef8e941f2bc38d37b35dc3f Mon Sep 17 00:00:00 2001
From: alelpoan <155192176+alelpoan@users.noreply.github.com>
Date: Thu, 14 May 2026 12:19:04 +0300
Subject: [PATCH 1/3] fix: grammar typo in future-directions

---
 docs/overview/future-directions.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/overview/future-directions.mdx b/docs/overview/future-directions.mdx
index 475265d..9f1beae 100644
--- a/docs/overview/future-directions.mdx
+++ b/docs/overview/future-directions.mdx
@@ -11,7 +11,7 @@ We need base standards to exist, and believe the future should be built in open
 
 ## The Beginning of Agent Commerce
 
-By defining patterns and protocols for verifiable identity and payments, ACK begins to addresses critical gaps left by traditional financial systems and offers a blueprint for developers and institutions building for the agent economy. But this is only a beginning.
+By defining patterns and protocols for verifiable identity and payments, ACK begins to address critical gaps left by traditional financial systems and offers a blueprint for developers and institutions building for the agent economy. But this is only a beginning.
 
 We don't yet have all the shared basic standards to unlock possibilities such as:
 

From d362861d9ec327e8321ddb32a84e3f43014d24de Mon Sep 17 00:00:00 2001
From: alelpoan <155192176+alelpoan@users.noreply.github.com>
Date: Thu, 14 May 2026 12:20:57 +0300
Subject: [PATCH 2/3] fix: grammar typo in components-roles

---
 docs/ack-pay/components-roles.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/ack-pay/components-roles.mdx b/docs/ack-pay/components-roles.mdx
index 1a63060..8ef17cb 100644
--- a/docs/ack-pay/components-roles.mdx
+++ b/docs/ack-pay/components-roles.mdx
@@ -29,7 +29,7 @@ These roles define the actors within the ACK-Pay ecosystem that orchestrate paym
 
 ## Component Interactions with a Payment Service
 
-The following component activity diagram illustrates a sophisticated flow involved a Payment Service.
+The following component activity diagram illustrates a sophisticated flow involving a Payment Service.
 
 !["Components and Roles Diagram"](/images/componentsandroles.png)
 

From fc5557b9d3d9e31add8c80b7a0d13bf6f1a8b46d Mon Sep 17 00:00:00 2001
From: alelpoan <155192176+alelpoan@users.noreply.github.com>
Date: Thu, 14 May 2026 12:31:46 +0300
Subject: [PATCH 3/3] fix: grammar typo in client-initiated-sequence.mdx

---
 docs/ack-pay/client-initiated-sequence.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/ack-pay/client-initiated-sequence.mdx b/docs/ack-pay/client-initiated-sequence.mdx
index 23fb60b..04ea7f6 100644
--- a/docs/ack-pay/client-initiated-sequence.mdx
+++ b/docs/ack-pay/client-initiated-sequence.mdx
@@ -16,7 +16,7 @@ This sequence is employed when a Client agent needs to pay based on a known obli
    - Details of the payment method the Client will use for funding.
    - Necessary reference information (e.g., invoice number, order ID).
    - Authentication credentials for the client agent (potentially leveraging ACK-ID).
-4. **Approvals and HITL:** The Client and Payment Service may optionally exchange further details or Human-in-the-Loop approvals as needed (e.g., specific pay-in instructions, risk checks, or or other dynamic interactions).
+4. **Approvals and HITL:** The Client and Payment Service may optionally exchange further details or Human-in-the-Loop approvals as needed (e.g., specific pay-in instructions, risk checks, or other dynamic interactions).
 5. **Payment Execution:** The Client authorizes the Payment Service to execute the payment according to the selected option. The Payment Service handles the interaction with the underlying Settlement Network, including any necessary conversions or compliance checks.
 6. **Receipt Issuance:** Upon successful settlement, the Payment Service (or its designated Receipt Service) issues an ACK Receipt (a Verified Credential) back to the initiating Client Agent. Optionally, the original requesting source or the final recipient may also be notified via the optional `serviceCallback` parameter if provided during initiation.