# Information volatility vs. the determinism mechanics

[Overlays Capture Architecture](https://oca.colossi.network/) consists of capture base (head) and overlays (heavy tail). The term head an tail comes from the concept of object destructuring (i.e. https://elixir-lang.org/getting-started/pattern-matching.html) and essentially means there is one head and a potentially infinite number of elements in the tail. The former is a list of human meaningful attribute names that express properties or characteristics of observables. The latter brings context by enriching them with additional metadata. The ingredients of the heavy tail (overlays) are bound to their head by using the unique identifier of the head (its digest), the product of the one-way hash function. Hash functions have the deterministic characteristic that means, for given input, they always return the same output. For example, for given input "abc" and using the blake2 hash function, the output is always the `5qnr9eFS5vFAd5gFaHzyrV5nQI9b/du99O6F1cLgn54=`.

$ echo "abc" | openssl dgst -binary -blake2s256 | openssl base64 -A
5qnr9eFS5vFAd5gFaHzyrV5nQI9b/du99O6F1cLgn54=

Such characteristic enables the use such products as identifiers. To give an example, there is a `parent<->child` relationship between two objects and the identifier of the parent is `digest(parent) = FDqGuc96GMxgREtwY+0QxrkxUl0idXTww4PZCRN0KMY=`. The child is in posession of the identifier of the parent and, therefore, is able to uniquely identify the parent by checking whether the `digest(parent)` matches what she knows.

In terms of OCA, any object that participates in the system, whether it is a capture base or overlay, is uniquely identified by calculating the digest. Furthermore, all overlays additionally include the digest of the capture base, because they constitute a unidirectional relationship, where the capture base is the "parent". Any set of one capture base and multiple overlays constitute a whole that can be identifiable as `digest(whole)`. By the "whole", we use the term OCA Bundle. Mechanically, these properties makes the whole system deterministic which means that for any `digest(whole)` we can uniquely identify the list of ingredients included in it. This operation is irreversible, that is, we cannot "deconstruct it" and find out the list of ingredients solely from the `digest(whole)`. However, what we can do is to find out what ingredients were used by performing the assertion `"0oY0+xYIgTeCvV5rJVpqRKrVmVkmT6vM+y0HI19bohk=" === digest(ing1+ing2+ing3)`. If such assertion passes, we say that the integrity of the object `ing1+ing2+ing3` has not been tampered with. This is the determinism mechanics.

Ingredients can be somehow thought of as a physical, tangible objects that have weight, dimensions, color etc, effectively making them uniquely identifiable by the human senses. In the digital space the equivalent of unique identification is the digest of a digital information. Digests, however, do care solely about the list of bytes of an information, not what such information represents. To give an example, `digest(www.example.com) = siOoRRdDu6CGAXAf6ZP+YxJAmnsZr82CvudIgpL8oM0=`, but it doesn't mean such digest uniquely identifies the whole content of the `www.example.com`. Such digest is solely the product of the hash function and therefore solely relies on the list of bytes of `www.example.com` and that's it.

The head (capture base) or heavy tail (overlays) of OCA may include information that anchors to an external datasource, i.e., `www.example.com`. They furthermore may refer to a "common knowledge", i.e., an ISO standard (ISO 8601 for datetime for example), that exist outside and are uncontrollable in the sense that we cannot easily refer to these resources via their digests. We cannot simply do `digest(ISO 8601)`, because it doesn't reflect to what is the content of `ISO 8601`, but solely what is the digest of an information represented as chain of characters that is `ISO 8601`. Such property is desired in the OCA system, because it protects from **information volatility**. Information volatility is natural consequence of an information evolution over time. For example WEB pages change, standards may change etc. While it is unlikely for ISO 8601 to change, there are standards that do change, building standards for example.

The OCA system is mechanically deterministic but lacks contextual determinism. The latter gives the full picture. An imprint of a snapshot at given point in time, however, due to the overall complexity it is not achievable. Effectively, it means information of the whole world would need to be deterministic.

While mechanical determinism is sufficient in most cases, it has implicit consequences on the overall architecture. One consequence is using the `ISO 8601` standard for representing date-time and relying on potentially volatile information. The system implicitly depends on it and makes precedent to further extensions, enabling more injection of volatility and making it even more unstable. The same problem is the consequence of introducing the transformation overlays that rely on external datasources (databases, WEB resources, etc) to enrich the system. While enrichments empowers the system, in the case of external datasources they need resolvers to actually benefit out of these enrichments. In most cases OCA core system cannot assist in such operations, because it is not the responsibility of the OCA core to have proper support for any external datasource that exist.

To keep the OCA system consistent and coherent over time, we must rethink the usage of potentially volatile information that is already in use in some cases! To prevent further injections, we must isolate what can be potentially volatile and what is constant over time. Such distinction guarantees the core stays immune to any unpredictable change over time. The most reasonable approach to the system is to extend it with an additional component that enables scripting. Scripts are add-ons to the core and allow to separate the responsibilities clearly. They also enrich the whole system, enabling integration with the volatile resources but under control. Such an approach effectively separates the core and adds potential for add-ons that can be used in many ways, i.e., to resolve additional information from external (volatile) data sources or conduct verification of an attribute that the core doesn't support. Scripts evolve over time, as the volatile information evolves. Since scripts become part of the system, they can benefit from the determinism mechanics, that is, `digest(script) = bBIyAEBhgwK1iACN1zYqTCbR4+5TXBS+B9V5B19N/28=`. Scripts are then included in OCA Bundle (fully or via their digests), enriched with metadata that defines when to run them. OCA core provides the component to run them.