This document outlines the different deliverables and how they need to be execute the process of research → development in an optimal way.

Research Phase

Technical Spec

The primary objective of the Research Phase is to publish and review the Technical Spec (ie the Notion document).

• This is the source of truth and the most important document of all. Of some key protocols, they will even be converted into RFC documents (by another team).
• It needs to be up-to-date.

Proof of Concepts and Simulations (optional, if required)

As a part of the research itself, as part of the process to achieve the Technical Spec, the team may deem necessary to implement proofs of concept or simulations.

• Proof of Concepts are meant as an exploratory programming tool, to reach conclusions on specific questions about the design itself. They should be practical, and target answering these questions in the most effective way.
• The repo for PoCs is: https://github.com/logos-co/nomos-pocs
• Simulations are a more focused on obtaining data used directly in research. These generally work better for complex systems that need to be understood at a fundamental level.
• The repo for Simulations is: https://github.com/logos-co/nomos-simulations

<aside> 💡 Be aware of building both simulations and PoCs with specific purposes in mind. The risk of blowing up complexity in both is high, we want to hit the sweet spot between a too idealized model and an over engineered one.

</aside>

Executable Specs (optional, for clarity)

Optionally, we may want to add Executable Specs.

• The Technical Spec can be sometimes accompanied by Executable Specs of key aspects of the protocol.
• Most importantly, Executable Specs are not exploratory code. They are written after Technical Specs are clear.
• The purpose of this is one and only one: to clarify specific algorithms and/or protocols that are complex and we must ensure that they are correctly expressed. This needs to be done in a minimalistic way and prioritize readability.
• Think of this almost as pseudocode for the Technical Spec, which ideally is embedded in the Technical spec.
• A good property of executable specs is to have a few well-defined test cases.