docs: fomatting changes

Author: Sandy-at-Tazama

Product/configuration-management.md

@@ -10,7 +10,7 @@
     - [Rule configuration metadata](#rule-configuration-metadata)
     - [The configuration object - parameters](#the-configuration-object---parameters)
     - [The configuration object - exit conditions](#the-configuration-object---exit-conditions)
-      - [The `.err` condition](#the-err-condition)
+      - [The `".err"` condition](#the-err-condition)
     - [The configuration object - rule results](#the-configuration-object---rule-results)
       - [Rule results - banded results](#rule-results---banded-results)
       - [Rule results - cased results](#rule-results---cased-results)
@@ -199,7 +199,7 @@ If a rule processor does not use any parameters, the parameters object may eithe
 
 A rule processor's exit conditions ensure that a rule processor is always able to produce a result, even if the rule processor is unable to reach a definitive, deterministic outcome. Exit conditions account for non-deterministic exceptions in the rule processor's behavior. The exit conditions are coded into the rule processor and each exit condition must be provided in the configuration for the rule processor to deliver a successful outcome. If any of the exit conditions are missing, the rule processor will still deliver a result, but it will be error outcome complaining about the missing exit condition related to the specific exit condition code.
 
-By convention, exit condition codes are prefaced with an 'x' to differentiate them from regular rule results that have no prefix.
+By convention, exit condition codes are prefaced with an "x" to differentiate them from regular rule results that have no prefix.
 
 From a configuration perspective, the only real purpose for including the exit conditions in the configuration file is to accommodate implementation-specific and user-defined descriptions for the exit conditions, and, in a future release, accommodate multi-language support.
 
@@ -240,14 +240,14 @@ Each exit condition contains the same attributes:
 
 | **Attribute** | **Description** |
 | --- | --- |
-| `subRuleRef` | Every rule processor is capable of reporting a number of different outcomes, but only a single outcome from the complete set is ultimately delivered to the typology processor. Each outcome is defined by a unique sub-rule reference identifier to differentiate the delivered outcome from the others and also to allow the typology processor to apply a unique weighting to that specific outcome.<br><br> By convention, the exit condition sub-rule references are prefaced with an 'x'. |
+| `subRuleRef` | Every rule processor is capable of reporting a number of different outcomes, but only a single outcome from the complete set is ultimately delivered to the typology processor. Each outcome is defined by a unique sub-rule reference identifier to differentiate the delivered outcome from the others and also to allow the typology processor to apply a unique weighting to that specific outcome.<br><br> By convention, the exit condition sub-rule references are prefaced with an "x". |
 | `reason` | The reason provides a human-readable description of the result that accompanies the rule result to the eventual over-all evaluation result. Reason descriptions will be refined during future enhancements[^1] |
 
-#### The `.err` condition
+#### The `".err"` condition
 
 All rule processors are encoded with an error condition outcome that accounts for exceptions that do not fall into any of the exit conditions above, or the rule results below. These error conditions reflect a fatal error that occurred during the execution of the rule processor, such as, for example, if the database is inaccessible or if some expected data dependency had not been met due to an error during data ingestion or transformation.
 
-Rule processor error conditions are too numerous and diverse to explicitly define, and their definition is not required for the rule configuration anyway. The error conditions are handled exclusively in the rule code; however the error condition outcome will still be produced as a rule result to ensure continuity and end-to-end robustness in the system. If an error occurs, a rule processor will deliver a rule result with a very unique `.err` sub-rule reference and with a specific reason that describes the error. In rare instances, where an error condition was not anticipated during development, the reason might be a generic `Unhandled rule result outcome` message.
+Rule processor error conditions are too numerous and diverse to explicitly define, and their definition is not required for the rule configuration anyway. The error conditions are handled exclusively in the rule code; however the error condition outcome will still be produced as a rule result to ensure continuity and end-to-end robustness in the system. If an error occurs, a rule processor will deliver a rule result with a very unique `".err"` sub-rule reference and with a specific reason that describes the error. In rare instances, where an error condition was not anticipated during development, the reason might be a generic `Unhandled rule result outcome` message.
 
 ### The configuration object - rule results
 
@@ -263,7 +263,7 @@ While the parameters and exit conditions may be optional for a specific rule pro
 
 The rule processor's core purpose is to produce a definitive deterministic result based on its programmed behavioral analysis of historical data. The rule configuration defines the bands or values for which rule results can be provided.
 
-> [!WARNING] It is extremely important that the configuration of a rule processor does not leave any gaps in the results, whether banded or cased. Every possible outcome of a rule result must be accounted for, otherwise the rule processor may deliver a result that the typology processor cannot interpret. In the event that a rule processor result misses the configured results, the rule processor will issue an error (`.err`) result with a reason description of `Value provided undefined, so cannot determine rule outcome`.
+> [!WARNING] It is extremely important that the configuration of a rule processor does not leave any gaps in the results, whether banded or cased. Every possible outcome of a rule result must be accounted for, otherwise the rule processor may deliver a result that the typology processor cannot interpret. In the event that a rule processor result misses the configured results, the rule processor will issue an error (`".err"`) result with a reason description of `Value provided undefined, so cannot determine rule outcome`.
 
 #### Rule results - banded results
 
@@ -443,13 +443,13 @@ The `wghts` object is an array that contains the sub-rule references and the ass
 
 ***Every. Possible. Outcome.***
 
-All the possible outcomes from the rule processors are encapsulated in each rule's configuration, with the exception of the `.err` outcome that is not listed in the rule configuration because the conditions and descriptions are built into the rule processor itself. When composing the typology configuration, the user must remember to include the `.err` outcome, but the rest of the rule results (exit conditions and banded/cased results) can be directly reconciled with the elements in the `rules` object.
+All the possible outcomes from the rule processors are encapsulated in each rule's configuration, with the exception of the `".err"` outcome that is not listed in the rule configuration because the conditions and descriptions are built into the rule processor itself. When composing the typology configuration, the user must remember to include the `".err"` outcome, but the rest of the rule results (exit conditions and banded/cased results) can be directly reconciled with the elements in the `rules` object.
 
 **What does "every possible outcome" mean?**
 
 A rule processor must always produce a result, and only ever a single result from a number of possible results. The rule result will always fall into one of the following categories: error, exit or band/case. Results across all the categories are mutually exclusive and there can be only one result regardless of the category. Results are uniquely identified via the `subRuleRef` attribute:
 
-*   ".err" is reserved for the error condition, of which there will only ever be one;
+*   `".err"` is reserved for the error condition, of which there will only ever be one;
 
 *   exit conditions are prefaced with an ".x" and there may be many;
 

Product/event-director.md

@@ -97,7 +97,7 @@ The pruned network sub-map will accompany the transaction message to the rule pr
 
 ### 2.4. De-duplicate Rules
 
-A single rule could be used to evaluate more than one typology. One of the primary advantages and reasons for the config-driven approach is to be able to minimize the number of times that a specific rule has to be executed. To achieve this objective, the Event Director will draft a list of all the rules in the network map and then eliminate duplicate rules from the list (the 'Highlander' principle).
+A single rule could be used to evaluate more than one typology. One of the primary advantages and reasons for the config-driven approach is to be able to minimize the number of times that a specific rule has to be executed. To achieve this objective, the Event Director will draft a list of all the rules in the network map and then eliminate duplicate rules from the list (the "Highlander" principle).
 
 Each rule in the network map can be uniquely described by the combination of the following attributes:
 

Product/transaction-monitoring-service-api.md

@@ -34,7 +34,7 @@ The TMS API implements ISO 20022 message formats to facilitate Payment Initiatio
 
 ISO20022 is traditionally an XML-based standard, but Tazama has implemented an abridged JSON message format to minimize the message payload to increase the performance and reduce bandwidth requirements.
 
-For more information on Tazama’s ISO 20022 implemented, see the [ISO20022 and Tazama](../Knowledge-Articles/iso20022-and-tazama.md) page.
+For more information on Tazama's ISO 20022 implemented, see the [ISO20022 and Tazama](../Knowledge-Articles/iso20022-and-tazama.md) page.
 
 The TMS API ingests transaction messages in real-time through the TMS API. The intention is to evaluate each transaction as they are performed, before they are sent to their destinations, to give Tazama an opportunity to evaluate the transaction before completion and to allow a transaction to be blocked.
 

README.md

@@ -43,7 +43,7 @@ By assessing the transfer to the fraudsters, it is possible to identify more hig
 
 If the Fraudster recipient was the customer being monitored it is likely they will receive the funds, and quickly move it to the next person in their money laundering chain. This would be captured in a Layering Typology which would include age of the account or dormant account suddenly becoming active instead of age of the participant.
 
-In the creation of a typology, it is worth highlighting that our phishing example can also create a false positive when a grandparent sends a large sum for an important life event to one of their grandchildren. Previously gifts had been sent via the parents and as such no historical financial relationship had been established. It is important that an understanding of the customers in a given FSP is developed, as finding the balance of low false positives and managing the activity of fraudsters 'testing the boundaries' are critical to the success of an implementation.
+In the creation of a typology, it is worth highlighting that our phishing example can also create a false positive when a grandparent sends a large sum for an important life event to one of their grandchildren. Previously gifts had been sent via the parents and as such no historical financial relationship had been established. It is important that an understanding of the customers in a given FSP is developed, as finding the balance of low false positives and managing the activity of fraudsters "testing the boundaries" are critical to the success of an implementation.
 
 <div style="text-align: right"><a href="#top">Top</a></div>
 
@@ -118,7 +118,7 @@ If a suspicious transaction is identified, there are a number of actions that ca
  - **Moderate** - an investigation alert to a case management systems can be created once the evaluation of all the typologies are complete;
  - **Low** - the transaction will pass without intervention, but the evaluation outcome will be stored for future retrieval.
 
-The typology score is evaluated against an 'interdiction' threshold to determine if the client system should be instructed to block a transaction 'in flight'. The Event Flow rule processor can be configured to override the interdiction outcome for a typology for a specific account or entity. 
+The typology score is evaluated against an "interdiction" threshold to determine if the client system should be instructed to block a transaction "in flight". The Event Flow rule processor can be configured to override the interdiction outcome for a typology for a specific account or entity. 
 
 Further information on the role of the Typology Processor is available on the [Typology Processing](/Product/typology-processing.md) page.