Fix Acrolinx validation errors

Author: ecfan

articles/logic-apps/rules-engine/build-fact-creators-retrievers.md

@@ -68,7 +68,7 @@ You can design your fact retriever with the required application-specific logic
 
 1. Specify the logic to refresh or assert new long-term fact instances into the engine.
 
-   The engine uses the initially asserted and consequently cached values on subsequent execution cycles until those values are updated.
+   The engine uses the initially asserted and cached values on subsequent execution cycles until those values are updated.
 
 The fact retriever implementation returns an object that is analogous to a token that the retriever can use with the **factsHandleIn** object to determine whether to update existing facts or assert new facts. When a ruleset version calls the fact retriever for the first time, the **factsHandleIn** object is always set to null, but takes on the return object's value after the fact retriever completes execution.
 
@@ -121,11 +121,11 @@ To include the following capabilities, write your own code implementation:
 
 - Determine when to update the long-term facts.
 
-- Track which rules engine instance uses which long-term facts.
+- Track whichever rules engine instance uses whichever long-term facts.
 
 ## Specify a fact retriever for a ruleset
 
-To set up fact retriever for your rulet version, you can either [set the Fact Retriever property in the Microsoft Rules Composer](perform-advanced-ruleset-tasks.md#set-up-fact-retriever), or write your own code as shown in the following example, which uses a class named "MyFactRetriever" in the assembly named "MyAssembly":
+To set up fact retriever for your ruleset version, you can either [set the Fact Retriever property in the Microsoft Rules Composer](perform-advanced-ruleset-tasks.md#set-up-fact-retriever), or write your own code as shown in the following example, which uses a class named "MyFactRetriever" in the assembly named "MyAssembly":
 
 ```csharp
 RuleEngineComponentConfiguration fr = new RuleEngineComponentConfiguration("MyAssembly", "MyFactRetriever");

articles/logic-apps/rules-engine/create-manage-vocabularies.md

@@ -112,7 +112,7 @@ After you add definitions to a vocabulary version, you can create a new empty vo
 
 1. Open the new vocabulary version's shortcut menu, and select **Save**.
 
-You can now copy vocabulary definitions from other vocabulary versions and paste them into the new version.
+You can now copy vocabulary definitions from other vocabulary versions, and paste them into the new version.
 
 ## Rename a vocabulary
 

articles/logic-apps/rules-engine/perform-advanced-ruleset-tasks.md

@@ -54,7 +54,7 @@ After you add rules to a ruleset version, you can create a new empty ruleset ver
 
 1. Open the new ruleset version's shortcut menu, and select **Save**.
 
-You can now copy rules from other rulest versions versions and paste them into the new version.
+You can now copy rules from other rulset versions, and paste them into the new version.
 
 ## Pass fact types to a ruleset
 

articles/logic-apps/rules-engine/rules-engine-optimization.md

@@ -167,7 +167,7 @@ When the **Fact1** fact, which has a value of 1, is asserted into the engine, bo
 
 ### Priority
 
-By default, all rules are set to 0 as the priority for execution. However, you can change this priority on each individual rule. The priority can range to either side of 0 with larger numbers having higher priority. Tjhe engine executes actions from highest priority to lowest priority.
+By default, all rules are set to 0 as the priority for execution. However, you can change this priority on each individual rule. The priority can range to either side of 0 with larger numbers having higher priority. The engine executes actions from highest priority to lowest priority.
 
 The following example shows how priority affects the order execution for rules:
 
@@ -251,7 +251,7 @@ The following list provides possible workarounds for this problem:
 
 - Develop a helper component that performs the **OR** operations and returns a Boolean value, and then use the component in the rule.
 
-- Split the rule into multiple rules and have the rules check for a flag set by a previously executed rule, or use an object that is asserted by a previously executed rule, for example:
+- Split the rule into multiple rules and have the rules check for a flag set by a previously executed rule, or use an object that a previously executed rule asserted, for example:
 
   - **Rule 1**: `IF (a == 1 OR a == 3) THEN b = true`
 

articles/logic-apps/rules-engine/test-rulesets.md

@@ -98,7 +98,7 @@ The following table describes the information in this entry:
 |------|-------------|
 | **Rule Engine Instance Identifier** | A unique identifier for the **RuleEngine** instance that provides the execution environment for the rule firing. |
 | **Ruleset Name** | The name of the ruleset. |
-| **Operation** | There following operation types can occur in a fact activity: <br><br>- **Assert**: A fact is addeded to working memory. **Note**: If the type for an asserted fact doesn't match any of the types used in the ruleset, the Assert operation shows the error "**Assert – Fact Unrecognized**". <br><br>- **Update**: A fact is updated by a rule and then must be reasserted into the engine for reevaluation, based on the new data and state. <br><br>- **Retract**: A fact is removed from working memory. |
+| **Operation** | The following operation types can occur in a fact activity: <br><br>- **Assert**: A fact is added to working memory. **Note**: If the type for an asserted fact doesn't match any of the types used in the ruleset, the **Assert** function shows the error "**Assert – Fact Unrecognized**". <br><br>- **Update**: A rule updates a fact, which must then be reasserted into the engine for reevaluation, based on the new data and state. <br><br>- **Retract**: A fact is removed from working memory. |
 | **Object Type** | The fact type for a particular activity: - **TypedXmlDocument** <br><br>Assertions are shown for both parent and child **TypedXmlDocument** instances. |
 | **Object Instance Identifier** | The unique instance ID for the fact reference. |
 
@@ -160,7 +160,7 @@ Conflict Resolution Criteria: 10
 
 ## Update function
 
-This example shows a sample "InventoryCheck" rule and a "Ship" rule in a sample ruleset named "Order". When the rule is first checked, the condition associated with the "Ship" rule evaluates to **False**. However, when the "InventoryCheck" rule fires, the **InventoryAvailable** field on the **Order** is changed, and the **Update** command is issued to the engine for the "Order object", causing reevaluation for the "Ship" rule. This time, the condition evaluates to **True**, and the "Ship" rule fires.
+This example shows a sample "InventoryCheck" rule and a "Ship" rule in a sample ruleset named "Order." When the rule is first checked, the condition associated with the "Ship" rule evaluates to **False**. However, when the "InventoryCheck" rule fires, the **InventoryAvailable** field on the **Order** is changed, and the **Update** command is issued to the engine for the "Order object", causing reevaluation for the "Ship" rule. This time, the condition evaluates to **True**, and the "Ship" rule fires.
 
 > [!NOTE]
 >