# Addressing information mutability with OCA data structures

Mutable information is information that can change over time without any preemptive notification. OCA structures rely on the immutability of the information, which allows to easily add integrity control to such information because, by nature, it doesn't change. Therefore, immutability becomes a significant characteristic for any system that relies on what has been said because it gives a warranty to the end-consumer as it assures her the information did not change. Consider a telephone game where players pass the information, and the first player passes the information up to the last player. Whispering (as the game assumes) may introduce mistakes, not only mutating the information but also changing its meaning. However, if players also pass the unique identifier of the information that is used to verify its integrity, any mistake made by any player is immediately disclosed.

Since everything in the core of OCA is immutable, thinking of adding potentially mutable information must be very well thought out. The anti-corruption layer (ACL) against mutable information must protect the immutable core. There are some lines of defense to protect immutable information against contamination of mutable information:
- [**convenient for OCA ecystem, but diffcult to achieve**] make mutable information immutable. The most convenient way to achieve it is to make a snapshot of mutable information, effectively making it immutable. Technically, most mutable information that can be beneficial to use with immutable OCA data structures is tree-based (take an ontology as an example). All the nodes can be identified within a tree via object id (OID), that is, the path to reach it from the tree's root through all the predecessors. OCA 1.0 spec brings OCA code tables that can be used precisely for this purpose. OCA code table that is a snapshot of mutable information is, however, immutable. Creating OCA code tables is a transition phase from mutable to immutable data structures.
- [**more flexible, yet protective**] make sure mutable information doesn't affect on immutable information. In other words isolate what's mutable and impose it doesn't change the context created from immutable information. Protect the core OCA that is immutable and make mutable information as additional, third party metadata, i.e., via meta overlay. Such metadata then becomes contextual, ecosystem dependent information, that doesn't need to be resolved by all the consumers. Resolution process refers to potential discovery and/or machine readability (i.e. ability to resolve information from a 3rd party WEB service) of given metadata (i.e. URI of a WEB service), effectively narrowing consumability only to parties that are really interested in it and have capabilities to interact with such WEB service.