Replace mutual with mutable in communicate-facts

docs/modules/patterns/pages/communicate-facts.adoc

@@ -23,10 +23,10 @@ _Choose immutable event streams over mutable state_
 
 Mutable state is not stable throughout time. It always represents the current/latest value and evolves through destructive in-place updates that overwrite the previous value. The essence of the problem is that mutable state treats the concepts of _value_ and _identity_ as the same thing. An identity can’t be allowed to evolve without changing the value it currently represents, forcing us to safeguard it with mutexes and the likes. 
 
-Concurrent updates to mutable state are a notorious source of data corruption. While there exist well-established techniques and algorithms for safe handling of updates to shared mutual state, they bring two major downsides. The complexity of these algorithms is easy to get wrong, especially as code evolves, and they require a certain level of coordination that places an upper bound on performance and scalability. Due to the destructive nature of updates to mutable state, mistakes can easily lead to corruption and loss of data that are expensive to detect and recover from.
+Concurrent updates to mutable state are a notorious source of data corruption. While there exist well-established techniques and algorithms for safe handling of updates to shared mutable state, they bring two major downsides. The complexity of these algorithms is easy to get wrong, especially as code evolves, and they require a certain level of coordination that places an upper bound on performance and scalability. Due to the destructive nature of updates to mutable state, mistakes can easily lead to corruption and loss of data that are expensive to detect and recover from.
 
 Instead, rely on immutable state—values representing _facts_—which can be shared safely as local or distributed _events_ without worrying about corrupt or inconsistent data, or guarding it with transactions or locks. 
 
 A fact is immutable and represents something that has already happened sometime in the past, something that can not be changed or retracted. It is a stable value that you can reason about and trust, indefinitely. After all, we can’t change the past, even if we sometimes wish that we could. Knowledge is cumulative and occurs either by receiving new facts or by deriving new facts from existing facts. Invalidation of existing knowledge is done by adding new facts to the system that refute existing facts. Facts are never deleted, only made irrelevant for current knowledge.
 
-Facts are best shared by publishing them as _events_ through the component’s _event stream_ where they can be subscribed to and consumed by others—components, databases, or subsystems—serving as a medium for communication, integration, and replication. _Facts_ stored as _events_ in an https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying[_event log] https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying[{tab}, window="new tab"], in their causal order, can represent the full history of a component’s state changes through time (e.g. using the https://martinfowler.com/eaaDev/EventSourcing.html[Event Sourcing] https://martinfowler.com/eaaDev/EventSourcing.html[{tab}, window="new tab"] pattern) while serving reads safely from memory (called https://martinfowler.com/bliki/MemoryImage.html[Memory Image] https://martinfowler.com/bliki/MemoryImage.html[{tab}, window="new tab"]).
+Facts are best shared by publishing them as _events_ through the component’s _event stream_ where they can be subscribed to and consumed by others—components, databases, or subsystems—serving as a medium for communication, integration, and replication. _Facts_ stored as _events_ in an https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying[_event log_] https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying[{tab}, window="new tab"], in their causal order, can represent the full history of a component’s state changes through time (e.g. using the https://martinfowler.com/eaaDev/EventSourcing.html[Event Sourcing] https://martinfowler.com/eaaDev/EventSourcing.html[{tab}, window="new tab"] pattern) while serving reads safely from memory (called https://martinfowler.com/bliki/MemoryImage.html[Memory Image] https://martinfowler.com/bliki/MemoryImage.html[{tab}, window="new tab"]).