#1380: Address 1.3 candidate release typos

specification/appendix/examples/commitment_discount_flexibility_examples/zero_percent_utilization_without_commitment_discount_flexibility.md

@@ -31,7 +31,7 @@ The above SKU Catalog shows that this service provider only has 1 service that o
 ## Outcome
 
 * 1 recurring, purchase record exists for 1 eligible "Hour" of the no upfront, *commitment discount* and incurs a $1.50 [*BilledCost*](#billedcost).
-* The VM_LARGE *commitment discount* is unused for the correspending [*charge period*](#glossary:chargeperiod) because no VM_LARGE resources are running and incurs a $1.50 [*EffectiveCost*](#effectivecost).
+* The VM_LARGE *commitment discount* is unused for the corresponding [*charge period*](#glossary:chargeperiod) because no VM_LARGE resources are running and incurs a $1.50 [*EffectiveCost*](#effectivecost).
 * 1 hour of on-demand usage is incurred by the VM_MEDIUM resource and incurs a $2.00 *BilledCost* and *EffectiveCost*.
 
 [CSV Example](/specification/data/commitment_discount_flexibility/zero_percent_utilization_without_commitment_discount_flexibility.csv)

specification/appendix/metadata_examples/data_generator_version_changed_example.md

@@ -2,7 +2,7 @@
 
 ## Scenario
 
-ACME specifies the optional metadata property [Data Generator Version](#datageneratorversion) in their [Schema](#schema) object. They made a change to the Cost and Usage [*FOCUS dataset*](#glossary:FOCUS-dataset) they produce that does not adopt a new FOCUS Version, nor does it make a change the included columns, but does impact values in the data. This example illustrates that Data Generator Version changes are independent of column changes, however data generator version changes may include column changes.
+ACME specifies the optional metadata property [Data Generator Version](#datageneratorversion) in their [Schema](#schema) object. They made a change to the Cost and Usage [*FOCUS dataset*](#glossary:FOCUS-dataset) they produce that does not adopt a new FOCUS Version, nor does it make a change to the included columns, but does impact values in the data. This example illustrates that Data Generator Version changes are independent of column changes, however data generator version changes may include column changes.
 
 The data generator creates a new schema object to represent the new schema. The data generator includes both the FOCUS Version and Data Generator Version in the schema object.
 

specification/appendix/metadata_examples/deprecating_columns_example.md

@@ -69,7 +69,7 @@ The updated schema-related metadata could look like this:
                 "DataType": "STRING",
                 "StringMaxLength": 64,
                 "StringEncoding": "UTF-8",
-                "Deprecation": true
+                "Deprecated": true
             }
       ]
 }

specification/appendix/metadata_examples/renaming_columns_example.md

@@ -70,7 +70,7 @@ The updated schema related metadata for the schema where the rename took place c
                 "DataType": "STRING",
                 "StringMaxLength": 64,
                 "StringEncoding": "UTF-8",
-                "Deprecation": true
+                "Deprecated": true
             }
       ]
 }
@@ -136,7 +136,7 @@ The subsequent new schema metadata after the rename could look like this:
                 "DataType": "STRING",
                 "StringMaxLength": 64,
                 "StringEncoding": "UTF-8",
-                "Deprecation": true
+                "Deprecated": true
             }
       ]
 }

specification/appendix/participating_entity_identification.md

@@ -29,7 +29,7 @@ The value for each of these may vary depending on how *resources* or *services*
 | 3.5.1 | Purchase records for SaaS products not running on your cloud infrastructure, purchased via a reseller. Reseller does not issue payable invoices.                               | SaaS Provider                | SaaS Provider  | SaaS Provider                           | SaaS Provider      |
 | 3.5.2 | Usage records for SaaS products not running on your cloud infrastructure, purchased via a reseller. Reseller does not issue payable invoices.                                  | SaaS Provider                | SaaS Provider  | SaaS Provider                           | SaaS Provider      |
 | 3.6.1 | Purchase records for SaaS products that have been white-labeled and sold by a reseller, not running on your cloud infrastructure. Reseller issues payable invoices.            | Reseller                     | Reseller       | Reseller                                | Reseller           |
-| 3.6.2 | Usage records for SaaS products products that have been white-labeled and sold by a reseller, not running on your cloud infrastructure. Reseller issues payable invoices.      | Reseller                     | Reseller       | Reseller                                | Reseller           |
+| 3.6.2 | Usage records for SaaS products that have been white-labeled and sold by a reseller, not running on your cloud infrastructure. Reseller issues payable invoices.      | Reseller                     | Reseller       | Reseller                                | Reseller           |
 | 4.1   | Purchasing SaaS products directly from a SaaS provider, with visibility into the underlying hosting provider.                                                                  | SaaS Provider                | SaaS Provider  | CSP                                     | SaaS Provider      |
 | 4.2   | Purchasing SaaS products directly from a SaaS provider, without visibility into the underlying hosting provider.                                                               | SaaS Provider                | SaaS Provider  | SaaS Provider                           | SaaS Provider      |
 | 4.3.1 | Purchasing SaaS products running on your cloud infrastructure, purchased directly from a SaaS provider (see 4.3.2 for charges related to the underlying cloud infrastructure). | SaaS Provider                | SaaS Provider  |                                      | SaaS Provider      |

specification/appendix/saas_examples/virtual_currency_pricing_model.md

@@ -113,7 +113,7 @@ Additionally, Acme Co offers a modified usage to token ratio for one of their se
 Note the following details in the example dataset:
 
 * Because of the modified rate for Workflow Operations, the PricingCurrencyContractedUnitPrice and PricingCurrencyListUnitPrice are different for this charge. The ContractedUnitPrice is set to $1 and the ListUnitPrice is set to $2.
-* The PricingCurrencyEffectiveCost is 240 tokens for this charge, which is less that example B2 above due to the modified rate.
+* The PricingCurrencyEffectiveCost is 240 tokens for this charge, which is less than example B2 above due to the modified rate.
 * ListCost reflects the cost of the charge at both the list cost of the tokens and the list rate for which the usage consumes tokens.
 
 ## Scenario C: Handling Virtual Currency Usage Overages

specification/datasets/cost_and_usage/columns/allocatedmethoddetails.md

@@ -134,11 +134,11 @@ The `Elements` array contains one or more objects, each of which contains the fo
 }
 ```
 
-NOTE: The above JSON Type Definition (JTD) is an approximation of the expected contents of this column, but it should not be considered normative because it cannot accurately describe the normative requirements (above) for AllocatedMethodDetails. Where there are discrepancies, deference will be given to the normative requirements. For example, [NumericFormat](#numericformat) allows for multiple numeric data types and precisions, but JDT requires both to be specified; other numeric data types and precisions allowable under NumericFormat are considered valid.
+NOTE: The above JSON Type Definition (JTD) is an approximation of the expected contents of this column, but it should not be considered normative because it cannot accurately describe the normative requirements (above) for AllocatedMethodDetails. Where there are discrepancies, deference will be given to the normative requirements. For example, [NumericFormat](#numericformat) allows for multiple numeric data types and precisions, but JTD requires both to be specified; other numeric data types and precisions allowable under NumericFormat are considered valid.
 
 ### Scenario 1: Single "UsageUnit" value used for allocation
 
-When only a single "UsageUnit" is used to calculate the allaction.
+When only a single "UsageUnit" is used to calculate the allocation.
 
 ```json
 {
@@ -152,7 +152,7 @@ When only a single "UsageUnit" is used to calculate the allaction.
 ```
 ### Scenario 2: Multiple "UsageUnit" values used for allocation
 
-When multiple "UsageUnit" values are used to calculate the allaction, another object is added to the "Elements" collection.
+When multiple "UsageUnit" values are used to calculate the allocation, another object is added to the "Elements" collection.
 
 ```json
 {

specification/datasets/cost_and_usage/columns/chargeclass.md

@@ -1,6 +1,6 @@
 # Charge Class
 
-Charge Class indicates whether the [*row*](#glossary:row) represents a correction to a previously invoiced [*billing period*](#glossary:billing-period). Charge Class is commonly used to differentiate [*corrections](#glossary:correction) from regularly incurred [*charges*](#glossary:charge).
+Charge Class indicates whether the [*row*](#glossary:row) represents a correction to a previously invoiced [*billing period*](#glossary:billing-period). Charge Class is commonly used to differentiate [*corrections*](#glossary:correction) from regularly incurred [*charges*](#glossary:charge).
 
 ## Requirements
 

specification/datasets/cost_and_usage/columns/contractapplied.md

@@ -191,7 +191,7 @@ The `Elements` array contains one or more objects, each of which contains the fo
 }
 ```
 
-NOTE: The above JSON Type Definition (JTD) is an approximation of the expected contents of this column, but it should not be considered normative because it cannot accurately describe the normative requirements (above) for ContractApplied. Where there are discrepancies, deference will be given to the normative requirements. For example, [NumericFormat](#numericformat) allows for multiple numeric data types and precisions, but JDT requires both to be specified; other numeric data types and precisions allowable under NumericFormat are considered valid.
+NOTE: The above JSON Type Definition (JTD) is an approximation of the expected contents of this column, but it should not be considered normative because it cannot accurately describe the normative requirements (above) for ContractApplied. Where there are discrepancies, deference will be given to the normative requirements. For example, [NumericFormat](#numericformat) allows for multiple numeric data types and precisions, but JTD requires both to be specified; other numeric data types and precisions allowable under NumericFormat are considered valid.
 
 ## Example Scenarios
 

specification/datasets/cost_and_usage/columns/invoiceid.md

@@ -1,6 +1,6 @@
 # Invoice ID
 
-An Invoice ID is a invoice-issuer-assigned identifier for an invoice encapsulating [*charges*](#glossary:charge) in the corresponding [*billing period*](#glossary:billing-period) for a given [*billing account*](#glossary:billing-account). Invoices are commonly used for scenarios like tracking billing transactions, facilitating payment processes and for performing invoice reconciliation between *charges* and billing periods.
+An Invoice ID is an invoice-issuer-assigned identifier for an invoice encapsulating [*charges*](#glossary:charge) in the corresponding [*billing period*](#glossary:billing-period) for a given [*billing account*](#glossary:billing-account). Invoices are commonly used for scenarios like tracking billing transactions, facilitating payment processes and for performing invoice reconciliation between *charges* and billing periods.
 
 ## Requirements
 

specification/datasets/cost_and_usage/columns/tags.md

@@ -45,7 +45,7 @@ The last two tags illustrate examples from two different, provider-defined tag s
 
 ## Finalized Tags
 
-Within a data generator, tag keys may be associated with multiple values, and potentially defined at different levels within the data generator, such as accounts, folders, [*resource*](#glossary:resource) and other *resource* grouping constructs. When finalizing, *data generator* must reduce these multiple levels of definition to a single value where each key is associated with exactly one value. The method by which this is done and the semantics are up to each data generatorder but must be documented within their respective documentation.
+Within a data generator, tag keys may be associated with multiple values, and potentially defined at different levels within the data generator, such as accounts, folders, [*resource*](#glossary:resource) and other *resource* grouping constructs. When finalizing, *data generator* must reduce these multiple levels of definition to a single value where each key is associated with exactly one value. The method by which this is done and the semantics are up to each data generator but must be documented within their respective documentation.
 
 As an example, let's assume 1 [*sub account*](#glossary:sub-account) exists with 1 virtual machine with the following details, and tag inheritance favors Resources over *Sub Accounts*.
 

specification/metadata/metadata_overview.md

@@ -1,6 +1,6 @@
 # Metadata
 
-The FOCUS specification defines a metadata structure to be supplied by data providers to facilitate practitioners' use of FOCUS data. This metadata includes general information the [*dataset artifact*](#glossary:dataset-artifact).
+The FOCUS specification defines a metadata structure to be supplied by data providers to facilitate practitioners' use of FOCUS data. This metadata includes general information about the [*dataset artifact*](#glossary:dataset-artifact).
 
 The metadata includes the following sections:
 

specification/metadata/recency/dataset_instance_complete.md

@@ -4,7 +4,7 @@ Dataset Instance Complete provides a boolean value to indicate that the dataset
 
 DatasetInstanceComplete adheres to the following requirements:
 
-* DatasetInstanceComplete MUST be present in an object within the [Recency](#recency) collection when the the dataset instance is not a time-series dataset.
+* DatasetInstanceComplete MUST be present in an object within the [Recency](#recency) collection when the dataset instance is not a time-series dataset.
 * DatasetInstanceComplete MUST be of type Boolean.
 * DatasetInstanceComplete MUST NOT be null.
 

specification/metadata/recency/time_sectors/time_sectors_overview.md

@@ -6,7 +6,7 @@ The FOCUS recency metadata's Time Sectors provide a list of time periods and met
 
 TimeSectors adheres to the following requirements:
 
-* TimeSectors MUST be present in an object within the [Recency](#recency) collection when the the associated *FOCUS dataset* is defined as a time series dataset.
+* TimeSectors MUST be present in an object within the [Recency](#recency) collection when the associated *FOCUS dataset* is defined as a time series dataset.
 * TimeSectors MUST be structured as a collection of objects.
 * TimeSectors MUST NOT be null.
 * TimeSectors collection MUST contain at least one object.

specification/overview.md

@@ -94,7 +94,7 @@ Under each column defined in the FOCUS specification, there exists a 'Feature le
 
 Validation tools may be employed to determine conformance of data and implementations per this specification.
 
-The FinOps Foundation maintains a validator called the [FOCUS Validator](https://github.com/finopsfoundation/focus_validator) which it uses for its own conformance assessments and as serves as a reference implementation to support validation activities.
+The FinOps Foundation maintains a validator called the [FOCUS Validator](https://github.com/finopsfoundation/focus_validator) which it uses for its own conformance assessments and serves as a reference implementation to support validation activities.
 
 Other validation tools may be developed and made available by third parties. The FOCUS specification does not mandate the use of any particular tool, nor does it maintain a registry of available validators.
 

specification/spec_abstract.md

@@ -1 +1 @@
-FOCUS is an open specification for billing data. It defines a common schema for billing data, aligns terminology with the FinOps Framework and defines a minimum set of requirements for billing data. The specification provides clear guideline for billing data generators to produce FinOps-serviceable data. The specification enables FinOps practitioners to perform common FinOps capabilities such as chargeback, cost allocation, budgeting and forecasting etc. using a generic set of instructions, regardless of the origin of the FOCUS compatible dataset.
+FOCUS is an open specification for billing data. It defines a common schema for billing data, aligns terminology with the FinOps Framework and defines a minimum set of requirements for billing data. The specification provides clear guidelines for billing data generators to produce FinOps-serviceable data. The specification enables FinOps practitioners to perform common FinOps capabilities such as chargeback, cost allocation, budgeting and forecasting etc. using a generic set of instructions, regardless of the origin of the FOCUS compatible dataset.

specification/supported_features/contract_commitments.md

@@ -2,7 +2,7 @@
 
 ## Description
 
-FOCUS supports the tracking of commitments made via contractual agreements between a service provider and a customer. Each row in the Cost and Usage dataset is associated with one or more unique identifiers representing those contracts and contract commitments, stored in a JSON column called Contract Applied. A richer amount of detail that describes those commitments is carried in a separate Contract Commitment dataset, which can be joined to the Cost and Usage datset to facilitate various queries involving filtering and aggregation.
+FOCUS supports the tracking of commitments made via contractual agreements between a service provider and a customer. Each row in the Cost and Usage dataset is associated with one or more unique identifiers representing those contracts and contract commitments, stored in a JSON column called Contract Applied. A richer amount of detail that describes those commitments is carried in a separate Contract Commitment dataset, which can be joined to the Cost and Usage dataset to facilitate various queries involving filtering and aggregation.
 
 The Contract Applied column contains several FOCUS-defined properties.  For more information, see the definition of Contract Applied [here](#contractapplied).
 

specification/supported_features/cost_and_usage_attribution.md

@@ -2,7 +2,7 @@
 
 ## Description
 
-Many service providers have features that allow Finops practitioners to enrich cost and usage data with metadata, that is addition to service provider defined data, in order to analyze Finops data using organizational, deployment, or other structures. These features may take the form of directly applied metadata or inherited metadata. FOCUS facilitates the inclusion of this metadata at a row level.  
+Many service providers have features that allow FinOps practitioners to enrich cost and usage data with metadata that is in addition to service provider defined data, in order to analyze FinOps data using organizational, deployment, or other structures. These features may take the form of directly applied metadata or inherited metadata. FOCUS facilitates the inclusion of this metadata at a row level.  
 
 ## Directly Dependent Columns
 

supporting_content/datasets/cost_and_usage/columns/chargefrequency.md

@@ -22,7 +22,7 @@ Current values observed in billing data for various scenarios:
 
 ## Example Usecases
 
-- Finops team identify and handle large one-time purchases to avoid (or educate on) large scary spikes in cloud monitoring tools/platforms.
+- FinOps team identify and handle large one-time purchases to avoid (or educate on) large scary spikes in cloud monitoring tools/platforms.
 - Finance teams identify and allocate one-time purchases either by amortization or cost recovery from the right entity.
 - Engineering managers are able to identify usage-based charges to include in their budget or forecasting processes.