Fix various minor typos throughout the documentation

customization/custom-data.md

@@ -26,6 +26,6 @@ While __data.customData__ affords users extensive freedom in including custom co
 
 * Are there existing Eiffel events and/or event members able to express the information? Using the standard vocabulary and syntax should always be the first option.
 * If your use case lacks support in the standard Eiffel vocabulary, there's a chance this is actually a general use case which deserves such support. Create an [Issue](https://github.com/eiffel-community/eiffel/issues) about it! It is always better to design a common solution than to implement multiple local adaptations.
-* Users defining __data.customData__ members are responsible for them and any compatibility issues. Special considerations or support from standard Eiffel events or syntax can not be expected, unless the custom syntax is proposed to and accepted into the standard Eiffel vocabulary (and consequently is no longer custom).
+* Users defining __data.customData__ members are responsible for them and any compatibility issues. Special considerations or support from standard Eiffel events or syntax cannot be expected, unless the custom syntax is proposed to and accepted into the standard Eiffel vocabulary (and consequently is no longer custom).
 
 The [event design guidelines](../eiffel-syntax-and-usage/event-design-guidelines.md) shall be observed with regards to key and value naming conventions.

customization/custom-events.md

@@ -24,4 +24,4 @@ That being said, users are free to send custom complementary events in parallel
 * Use [Issues](https://github.com/eiffel-community/eiffel/issues) and [Pull requests](https://github.com/eiffel-community/eiffel/pulls) to stay in touch with the community to discuss why and how you define custom events. Others may find them useful, too!
 * Follow the [event design guidelines](../eiffel-syntax-and-usage/event-design-guidelines.md).
 * Consider whether your need can be addressed by __data.customData__.
-* Users defining custom events are responsible for them and any compatibility issues. Special considerations or support from standard Eiffel events can not be expected, unless the custom events are proposed to and accepted into the standard Eiffel vocabulary (and consequently are no longer custom).
+* Users defining custom events are responsible for them and any compatibility issues. Special considerations or support from standard Eiffel events cannot be expected, unless the custom events are proposed to and accepted into the standard Eiffel vocabulary (and consequently are no longer custom).

definitions/EiffelConfidenceLevelModifiedEvent/1.0.0.yml

@@ -18,7 +18,7 @@ _abbrev: CLM
 _description: |-
   The EiffelConfidenceLevelModifiedEvent declares that an entity has achieved (or failed to achieve) a certain level of confidence, or in a broader sense to annotate it as being applicable or relevant to a certain case (e.g. fit for release to a certain customer segment or having passed certain criteria. This is particularly useful for promoting various engineering artifacts, such as product revisions, through the continuous integration and delivery pipeline.
 
-  Confidence levels may operate at high or low levels of abstraction - ranging from "smokeTestsOk" to "releasable" or "released" - and they may group other confidence levels of lower abstraction levels. They may also be general or very niched, e.g. "releasable" or "reseabableToCustomerX". Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
+  Confidence levels may operate at high or low levels of abstraction - ranging from "smokeTestsOk" to "releasable" or "released" - and they may group other confidence levels of lower abstraction levels. They may also be general or very niched, e.g. "releasable" or "releasableToCustomerX". Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
 type: object
 properties:
   meta:

definitions/EiffelConfidenceLevelModifiedEvent/1.1.0.yml

@@ -18,7 +18,7 @@ _abbrev: CLM
 _description: |-
   The EiffelConfidenceLevelModifiedEvent declares that an entity has achieved (or failed to achieve) a certain level of confidence, or in a broader sense to annotate it as being applicable or relevant to a certain case (e.g. fit for release to a certain customer segment or having passed certain criteria). This is particularly useful for promoting various engineering artifacts, such as product revisions, through the continuous integration and delivery pipeline.
 
-  Confidence levels may operate at high or low levels of abstraction - ranging from "smokeTestsOk" to "releasable" or "released" - and they may group other confidence levels of lower abstraction levels. They may also be general or very niched, e.g. "releasable" or "reseabableToCustomerX". Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
+  Confidence levels may operate at high or low levels of abstraction - ranging from "smokeTestsOk" to "releasable" or "released" - and they may group other confidence levels of lower abstraction levels. They may also be general or very niched, e.g. "releasable" or "releasableToCustomerX". Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
 type: object
 properties:
   meta:

definitions/EiffelConfidenceLevelModifiedEvent/2.0.0.yml

@@ -18,7 +18,7 @@ _abbrev: CLM
 _description: |-
   The EiffelConfidenceLevelModifiedEvent declares that an entity has achieved (or failed to achieve) a certain level of confidence, or in a broader sense to annotate it as being applicable or relevant to a certain case (e.g. fit for release to a certain customer segment or having passed certain criteria). This is particularly useful for promoting various engineering artifacts, such as product revisions, through the continuous integration and delivery pipeline.
 
-  Confidence levels may operate at high or low levels of abstraction - ranging from "smokeTestsOk" to "releasable" or "released" - and they may group other confidence levels of lower abstraction levels. They may also be general or very niched, e.g. "releasable" or "reseabableToCustomerX". Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
+  Confidence levels may operate at high or low levels of abstraction - ranging from "smokeTestsOk" to "releasable" or "released" - and they may group other confidence levels of lower abstraction levels. They may also be general or very niched, e.g. "releasable" or "releasableToCustomerX". Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
 type: object
 properties:
   meta:

definitions/EiffelConfidenceLevelModifiedEvent/3.0.0.yml

@@ -18,7 +18,7 @@ _abbrev: CLM
 _description: |-
   The EiffelConfidenceLevelModifiedEvent declares that an entity has achieved (or failed to achieve) a certain level of confidence, or in a broader sense to annotate it as being applicable or relevant to a certain case (e.g. fit for release to a certain customer segment or having passed certain criteria). This is particularly useful for promoting various engineering artifacts, such as product revisions, through the continuous integration and delivery pipeline.
 
-  Confidence levels may operate at high or low levels of abstraction - ranging from "smokeTestsOk" to "releasable" or "released" - and they may group other confidence levels of lower abstraction levels. They may also be general or very niched, e.g. "releasable" or "reseabableToCustomerX". Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
+  Confidence levels may operate at high or low levels of abstraction - ranging from "smokeTestsOk" to "releasable" or "released" - and they may group other confidence levels of lower abstraction levels. They may also be general or very niched, e.g. "releasable" or "releasableToCustomerX". Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
 type: object
 properties:
   meta:

definitions/EiffelConfidenceLevelModifiedEvent/3.1.0.yml

@@ -18,7 +18,7 @@ _abbrev: CLM
 _description: |-
   The EiffelConfidenceLevelModifiedEvent declares that an entity has achieved (or failed to achieve) a certain level of confidence, or in a broader sense to annotate it as being applicable or relevant to a certain case (e.g. fit for release to a certain customer segment or having passed certain criteria). This is particularly useful for promoting various engineering artifacts, such as product revisions, through the continuous integration and delivery pipeline.
 
-  Confidence levels may operate at high or low levels of abstraction - ranging from "smokeTestsOk" to "releasable" or "released" - and they may group other confidence levels of lower abstraction levels. They may also be general or very niched, e.g. "releasable" or "reseabableToCustomerX". Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
+  Confidence levels may operate at high or low levels of abstraction - ranging from "smokeTestsOk" to "releasable" or "released" - and they may group other confidence levels of lower abstraction levels. They may also be general or very niched, e.g. "releasable" or "releasableToCustomerX". Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
 type: object
 properties:
   meta:

definitions/EiffelConfidenceLevelModifiedEvent/3.2.0.yml

@@ -18,7 +18,7 @@ _abbrev: CLM
 _description: |-
   The EiffelConfidenceLevelModifiedEvent declares that an entity has achieved (or failed to achieve) a certain level of confidence, or in a broader sense to annotate it as being applicable or relevant to a certain case (e.g. fit for release to a certain customer segment or having passed certain criteria). This is particularly useful for promoting various engineering artifacts, such as product revisions, through the continuous integration and delivery pipeline.
 
-  Confidence levels may operate at high or low levels of abstraction - ranging from "smokeTestsOk" to "releasable" or "released" - and they may group other confidence levels of lower abstraction levels. They may also be general or very niched, e.g. "releasable" or "reseabableToCustomerX". Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
+  Confidence levels may operate at high or low levels of abstraction - ranging from "smokeTestsOk" to "releasable" or "released" - and they may group other confidence levels of lower abstraction levels. They may also be general or very niched, e.g. "releasable" or "releasableToCustomerX". Confidence levels frequently figure in automated delivery interfaces within a tiered system context: lower level tiers issue an agreed confidence level signaling that a new version is ready for integration in a higher level tier.
 type: object
 properties:
   meta:

definitions/EiffelSourceChangeCreatedEvent/2.0.0.yml

@@ -217,7 +217,7 @@ _links:
     description: Identifies an issue which was previously resolved,
       but that this SCC claims it has made changes to warrant removing
       the resolved status. For example, if an issue "Feature X" was
-      resolved, but this SCC removed the implmentation that led to
+      resolved, but this SCC removed the implementation that led to
       "Feature X" being resolved, that issue should no longer be considered
       resolved.
     required: false

definitions/EiffelSourceChangeCreatedEvent/4.0.0.yml

@@ -217,7 +217,7 @@ _links:
     description: Identifies an issue which was previously resolved,
       but that this SCC claims it has made changes to warrant removing
       the resolved status. For example, if an issue "Feature X" was
-      resolved, but this SCC removed the implmentation that led to
+      resolved, but this SCC removed the implementation that led to
       "Feature X" being resolved, that issue should no longer be considered
       resolved.
     required: false

definitions/EiffelSourceChangeCreatedEvent/4.1.0.yml

@@ -217,7 +217,7 @@ _links:
     description: Identifies an issue which was previously resolved,
       but that this SCC claims it has made changes to warrant removing
       the resolved status. For example, if an issue "Feature X" was
-      resolved, but this SCC removed the implmentation that led to
+      resolved, but this SCC removed the implementation that led to
       "Feature X" being resolved, that issue should no longer be considered
       resolved.
     required: false

definitions/EiffelTestExecutionRecipeCollectionCreatedEvent/1.0.0.yml

@@ -91,7 +91,7 @@ properties:
                     _description: A UUID identifying the unique execution.
                       Note that this is different from the id of a
                       test case, in two ways. First, a test case is
-                      a (presumably) persistnent entity, whereas an
+                      a (presumably) persistent entity, whereas an
                       execution is transient in nature. Second, a test
                       case may be executed any number of times in any
                       given recipe collection.

definitions/EiffelTestExecutionRecipeCollectionCreatedEvent/2.0.0.yml

@@ -91,7 +91,7 @@ properties:
                     _description: A UUID identifying the unique execution.
                       Note that this is different from the id of a
                       test case, in two ways. First, a test case is
-                      a (presumably) persistnent entity, whereas an
+                      a (presumably) persistent entity, whereas an
                       execution is transient in nature. Second, a test
                       case may be executed any number of times in any
                       given recipe collection.

definitions/EiffelTestExecutionRecipeCollectionCreatedEvent/2.1.0.yml

@@ -91,7 +91,7 @@ properties:
                     _description: A UUID identifying the unique execution.
                       Note that this is different from the id of a
                       test case, in two ways. First, a test case is
-                      a (presumably) persistnent entity, whereas an
+                      a (presumably) persistent entity, whereas an
                       execution is transient in nature. Second, a test
                       case may be executed any number of times in any
                       given recipe collection.

definitions/EiffelTestExecutionRecipeCollectionCreatedEvent/3.0.0.yml

@@ -91,7 +91,7 @@ properties:
                     _description: A UUID identifying the unique execution.
                       Note that this is different from the id of a
                       test case, in two ways. First, a test case is
-                      a (presumably) persistnent entity, whereas an
+                      a (presumably) persistent entity, whereas an
                       execution is transient in nature. Second, a test
                       case may be executed any number of times in any
                       given recipe collection.

definitions/EiffelTestExecutionRecipeCollectionCreatedEvent/4.0.0.yml

@@ -91,7 +91,7 @@ properties:
                     _description: A UUID identifying the unique execution.
                       Note that this is different from the id of a
                       test case, in two ways. First, a test case is
-                      a (presumably) persistnent entity, whereas an
+                      a (presumably) persistent entity, whereas an
                       execution is transient in nature. Second, a test
                       case may be executed any number of times in any
                       given recipe collection.

definitions/EiffelTestExecutionRecipeCollectionCreatedEvent/4.1.0.yml

@@ -91,7 +91,7 @@ properties:
                     _description: A UUID identifying the unique execution.
                       Note that this is different from the id of a
                       test case, in two ways. First, a test case is
-                      a (presumably) persistnent entity, whereas an
+                      a (presumably) persistent entity, whereas an
                       execution is transient in nature. Second, a test
                       case may be executed any number of times in any
                       given recipe collection.

definitions/EiffelTestExecutionRecipeCollectionCreatedEvent/4.1.1.yml

@@ -91,7 +91,7 @@ properties:
                     _description: A UUID identifying the unique execution.
                       Note that this is different from the id of a
                       test case, in two ways. First, a test case is
-                      a (presumably) persistnent entity, whereas an
+                      a (presumably) persistent entity, whereas an
                       execution is transient in nature. Second, a test
                       case may be executed any number of times in any
                       given recipe collection.

definitions/EiffelTestExecutionRecipeCollectionCreatedEvent/4.2.0.yml

@@ -91,7 +91,7 @@ properties:
                     _description: A UUID identifying the unique execution.
                       Note that this is different from the id of a
                       test case, in two ways. First, a test case is
-                      a (presumably) persistnent entity, whereas an
+                      a (presumably) persistent entity, whereas an
                       execution is transient in nature. Second, a test
                       case may be executed any number of times in any
                       given recipe collection.

definitions/EiffelTestExecutionRecipeCollectionCreatedEvent/4.3.0.yml

@@ -91,7 +91,7 @@ properties:
                     _description: A UUID identifying the unique execution.
                       Note that this is different from the id of a
                       test case, in two ways. First, a test case is
-                      a (presumably) persistnent entity, whereas an
+                      a (presumably) persistent entity, whereas an
                       execution is transient in nature. Second, a test
                       case may be executed any number of times in any
                       given recipe collection.