Skip to main content

Design principles

To turn its vision a reality, Holium has few but strong design principles:

  • Data-first approach – Data is and will increasingly be at the heart of our best AI and decision-making. Only if it is backed by the most appropriate tools may we make the most of it. That is why data deserves a framework fully dedicated to its manipulation, freed from event handling and their side effects. In Holium, data is treated as a first-class citizen, and functions that manipulate it are pure functions which strictly ingest and transform data.
  • Unified approach – Data and assets used for their transformation are adequate and sufficient to represent themselves. The Holium framework never introduces any element dependent on an owner nor a location, but in the end only relies on data self-description. This is the best way to achieve a vision in which data is described solely in terms of its content and relations to other data, never to external metadata.

These design principles translate to and are complemented by development principles:

  • Free and open protocol – It can be transformative to move towards a model where what matters is no longer who has the data, but what we do with it. To enable such a shift, how we do it should not be restrained. That is why Holium fully subscribes to the FOSS principles, and supports the development of a protocol rather than locked-in platforms.
  • Modular – Holium adopts a layered architecture with a clear division of concerns. The protocol is primarily made, at its core, by minimal future-proof specifications on how to represent data and transformations, how they are connected and how to uniquely identify these components. On top of this technologically neutral core, additional layers should easily interconnect and provide features they are liable for: orchestration, logging, tracing, monitoring, security and compliance, discovery, economic incentive,…
  • Unified – Unifying representations and uses with a protocol is generally a priori not in the hand of its architects. They will not decide if a protocol ultimately fosters unification, but its design can help. That is why Holium always promotes content-based and deterministic identifiers, keeping in good sight a future of Web3-enabled data manipulations and trustless frameworks.
  • Data-as-code – Manipulating data at scale requires elements of rigor, so that the development of the framework should always ensure its consistency with the DaC principles.
  • Think big – The best chances of designing a future-proof solution will only be met by, at relevant times, thinking big. Some primary design consideration de facto chronologically places Holium in the present and the future. Therefore, in situations of choice, too much effort should not be put on enforcing compatibility with obsolete technologies, and guiding principles should always favor compatibility with Web3-native components.