[Issue #18] Updates answers to spec design questions (#44)

Fixes typos in the following ADRs:
- v0.1.0 models and routes
- Monetary fields

Author: widal001

website/src/content/docs/decisions/adr/0007-initial-models-and-routes.md

@@ -22,7 +22,7 @@ We'll limit the scope of the v0.1.0 protocol to the models and routes needed to
   - Lays the foundation for expansion in subsequent versions.
 - **Negative consequences**
   - Will require future updates to accommodate additional models and operations.
-  - Could limit initial functionality for specific advanced use cases, such as post-award reporting.
+  - Doesn't (yet) support key features like applications and reporting.
   - May be harder to make changes once platforms have started adopting the protocol.
 
 ### Decision drivers
@@ -39,12 +39,12 @@ We'll limit the scope of the v0.1.0 protocol to the models and routes needed to
 1. **Base types:** Includes essential reusable fields such as currency, GeoJSON, and custom fields.
 2. **Grant opportunity models:** Models describing the metadata for grant opportunities.
 3. **Individuals and organizations:** Basic models for describing grantors and grant seekers.
-4. **Application forms and submissions:** Models describing application processes and submission structures.
+4. **Application forms and submissions:** Models describing application forms and submissions.
 5. **Grant awards and reporting:** Models for tracking awarded grants and reporting requirements.
 
 #### Operations
 
-1. Searching and viewing opportunities\*\*
+1. Searching and viewing opportunities
 2. Saving or subscribing to opportunities
 3. Managing organization membership
 4. Filling out and submitting applications
@@ -90,7 +90,7 @@ Also include models and routes needed to support filling out and submitting appl
 - **Cons**:
   - Increases implementation complexity.
   - Application processes can vary significantly by platform and grant.
-  - Might be hard to land on a common standard in time for v0.1.0
+  - Might be hard to align on a common standard in time for v0.1.0.
 
 ### Option 4: Also support post-award reporting
 

website/src/content/docs/decisions/adr/0009-monetary-fields.md

@@ -64,7 +64,7 @@ Here's an example of that format:
 
 ### Option 1: Floating point
 
-Monetary values are represented as strings with fixed decimal points (e.g., `1234.56` for $1234.56).
+Monetary values are represented as a floating point number (e.g., `1234.56` for $1234.56).
 
 - **Pros**
   - Human-readable and easier for API consumers to debug.
@@ -76,13 +76,13 @@ Monetary values are represented as strings with fixed decimal points (e.g., `123
 
 ### Option 2: Decimal string
 
-Monetary values are represented as strings with fixed decimal points (e.g., `"1234.56"` for $1234.56).
+Monetary values are represented as a string-formatted decimal value (e.g., `"1234.56"` for $1234.56).
 
 - **Pros**
   - Human-readable and easier for API consumers to debug.
   - No conversion required for display or consumer-facing applications.
   - Suitable for currencies with non-standard subunits (e.g., cryptocurrencies).
-  - Commonly used format for monetary values, e.g. PayPal, ApplePay, etc.
+  - Commonly used format for monetary values, e.g., PayPal, Apple Pay, Google Pay, etc.
 - **Cons**
   - Vulnerable to floating-point precision issues if parsed into floating-point numbers.
   - Parsing and validation of string inputs are more complex than integers.
@@ -97,7 +97,7 @@ Monetary values are represented as integers in the smallest unit of the currency
   - Ideal for aggregation, sorting, and other arithmetic operations.
   - Compact representation (smaller payloads compared to string decimals).
   - Consistent format across implementations.
-  - Commonly used format for monetary values, e.g. Stripe, Square.
+  - Commonly used format for monetary values, e.g., Stripe, Square, etc.
 - **Cons**
   - Less human-readable than string representations.
   - Requires explicit documentation of smallest unit conventions (e.g., cents for USD, yen has no subunit).