Copy edit Getting Started and Overview for clarity

Fix a typo, add context for jargon (HISP, edge protocols, "stubbing
out"), and improve sentence flow so the pages read more clearly for
readers unfamiliar with Direct/HISP concepts.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MsSB32wF5xp5oBm3q87efX

Author: gm2552

docs/getting-started.md

@@ -4,19 +4,19 @@ title: Getting Started
 
 # Getting Started
 
-If you want to stand up an instance of the reference implementation right away, the fastest path is the [BareMetal Assembly Project](/docs/direct-project-stock/) for the Java platform. It contains instructions for installing components and services using configuration presents to enable rapid deployment.
+If you want to stand up an instance of the reference implementation right away, the fastest path is the Java platform's [BareMetal Assembly Project](/docs/direct-project-stock/). It provides instructions for installing the components and services using configuration presets, so you can deploy quickly without configuring everything by hand.
 
-To build all components and services from source instead of using a prebuilt package, follow the instructions [here](https://github.com/DirectProjectJavaRI/direct-ri-build).
+To build all components and services from source instead of using a prebuilt package, follow the [build instructions in the direct-ri-build repository](https://github.com/DirectProjectJavaRI/direct-ri-build).
 
 ## Understanding the Modular Components
 
-If you'd rather understand how the reference implementation's components fit together before diving in, start with the module list below. The reference implementation follows a modular design for easy reuse and extensibility.
+The reference implementation follows a modular design, so its components can be reused, replaced, or extended independently rather than treated as one monolithic system. If you'd rather understand how the pieces fit together before diving in, start with the module list below:
 
 ### Java Components
 
-* [Security And Trust Agent](/docs/agent/)
-* [Gateway](/docs/gateway/)
-* [Message Monitoring](/docs/direct-msg-monitor/)
-* [Policy Enablement](/docs/direct-policy/)
-* [DNS Services](/docs/dns/)
-* [BareMetal Assembly Project](/docs/direct-project-stock/)
+* [Security And Trust Agent](/docs/agent/) — resolves certificates and enforces trust between Direct-compliant systems
+* [Gateway](/docs/gateway/) — bridges Direct messages between edge protocols (such as SMTP/POP or XDR) and the systems that send and receive them
+* [Message Monitoring](/docs/direct-msg-monitor/) — tracks message delivery and correlates delivery and failure notifications for auditing and troubleshooting
+* [Policy Enablement](/docs/direct-policy/) — a policy engine that works alongside the Security And Trust Agent to enforce security and trust policies
+* [DNS Services](/docs/dns/) — manages the DNS records used to discover certificates and endpoints for Direct exchange
+* [BareMetal Assembly Project](/docs/direct-project-stock/) — packages the components above into a deployable stack, using configuration presets for common deployment scenarios

docs/overview.md

@@ -4,12 +4,12 @@ title: Overview
 
 # Overview
 
-The reference implementation is an open source, pre-assembled implementation of the Direct specifications, available in both .Net and Java. A subproject called BareMetal provides everything needed to procure the reference implementation and stand up a HISP from scratch using only the reference implementation's assemblies.
+The reference implementation is an open-source, pre-assembled implementation of the Direct specifications — the standards behind Direct Secure Messaging, a secure, email-like way for healthcare organizations to exchange health information — available for both .NET and Java. A subproject called BareMetal packages everything you need to stand up a Health Information Service Provider (HISP) from scratch, using only the reference implementation's prebuilt components.
 
-The reference implementation is a fully working model, but it's still just a model. Think of it like a reference board in embedded hardware or robotics: a cookie-cutter design with a standard set of modules, inputs, and outputs. It isn't meant to be the final product — it's tweaked, extended with custom modules, or trimmed down until it becomes a customized board that fits your solution.
+The reference implementation is a fully working model, but it's still just a model. Think of it like a reference board in embedded hardware or robotics: a cookie-cutter design with a standard set of modules, inputs, and outputs. It isn't meant to be the final product. Instead, you tweak it, extend it with custom modules, or trim it down until it becomes a customized board that fits your solution.
 
-The same is true for Direct. The reference implementation ships with a standard deployment model and a set of software components — the security and trust agent, the messaging gateway, a certificate store, and a simple web or command-line configuration tool. It does not, however, meet the requirements of an industry-class production system: high availability, failover, scalability, and disaster recovery. It also supports only the XDR and POP/SMTP edge protocols; other edge clients and workflows may need additional protocols such as REST or SOAP, along with custom authentication and authorization modules.
+The same is true for Direct. The reference implementation ships with a standard deployment model and a set of software components — the Security and Trust Agent, the Gateway, a certificate store, and a simple web or command-line configuration tool. However, it doesn't meet the requirements of an industry-class production system: high availability, failover, scalability, and disaster recovery. It also supports only two "edge protocols" — XDR and POP/SMTP — the protocols a HISP uses to connect with the applications and systems around it, as opposed to the protocol HISPs use to exchange messages directly with one another. Other edge clients and workflows may need additional protocols, such as REST or SOAP, along with custom authentication and authorization modules.
 
-Nor does the reference implementation meet the policy requirements set by various governance agencies. For example, its private certificate store doesn't meet auditing requirements for access to private keys, and its audit subsystem doesn't write events to a storage mechanism with proper access controls. These areas are intentionally stubbed out so you can plug in custom implementations of the reference interfaces and modules to meet them. Becoming a fully compliant HISP — meeting industry best practices, certificate policies, and required operational procedures — takes additional investment in infrastructure and software development.
+The reference implementation also doesn't meet the policy requirements set by various governance agencies. For example, its private certificate store doesn't meet auditing requirements for access to private keys, and its audit subsystem doesn't write events to a storage mechanism with proper access controls. These areas are intentionally left as minimal placeholder implementations — a practice known as "stubbing out" — so you can plug in your own, compliant implementations of the reference interfaces and modules. Becoming a fully compliant HISP — meeting industry best practices, certificate policies, and required operational procedures — takes additional investment in infrastructure and software development.
 
 Ready to stand up an instance or explore the individual components? Head over to [Getting Started](/getting-started).