## 3 Proposed Model: ABCDE Method and Integration with SSI Concepts
### Some Explicative Diagrams  
All data necessary for implementing the logic that manages the passage of content from one area of the CDE to another--and, therefore, the overcoming of the so-called gates--are stored on-chain. A given model passes from one area to the next one only if it passes appropriate checks, the so-called coordination levels CLs, and only if it passes appropriate verifications, the so-called verification levels VLs. After these checks, reports are drawn up with the results of the analyses, and an approval status is assigned to the model. So the approval status allows (or disallows) the passage of the model to the next area of the CDE. In particular, each model is subjected to verification VL1 if it is in the work-in-progress directory, VL2 if it is in the shared directory, and finally, VL3 if it is in the published directory. Regarding the coordination analysis, typically, the information specifications are required in order to carry out a periodic activity of coordination of the models. Only the subject responsible for a given model can modify that model according to the results of the verification and coordination procedures and according to any requests by the appointing party and/or other stakeholders. A given model is completed if it has passed through all levels of coordination and verification with approval status A0. The proposed application assumes that the subject responsible for a given model's version makes a blockchain transaction to ask the smart contract for passage to the next area when he/she believes that all the contractual constraints have been satisfied and the model has been modified according to all requests by the stakeholders involved in the design process. The smart contract, by querying its data structure, decides if the model's version can or cannot pass to next area. All the versions of a given model and all other information, such as information exchange type documents, are stored in plain text in the CDE, while their hashes are stored in the blockchain, so the transparency of all the design activities is guaranteed. Note that all of the assumptions for the proposed dApp can be customized to create a coherent dApp with the requirements that have to be realized for a specific commission. Figures 2 and 3 show the UMLclass diagram and the UML use-case diagram, respectively, of the smart contract proposed in this work. Note that the use cases in this figure are for the user stories listed above, and many of them also correspond to the methods for the smart contract (see the methods listed for the stereotypical <<contract>> CDEdataNotarization in Figure 2). In the following, let us give a description of a typical workflow that can be implemented using the proposed dApp. A flow similar to that proposed by [PERSON] et al. [7], who implemented a framework in Hyperledger Fabric, was followed. Unlike [7], the proposed article's goal was to notarize the information flow in a CDE and not that to implement a distributed CDE, as [PERSON] et al. did. Figure 4 shows the UML sequence diagram for this workflow. Figure 3: UML use-case diagram. Figure 4: UML sequence diagram. An architect creates the first version of a BIM model, which has been registered in the system by an administrator with the unique identifier DC-0010-INF-M2-D. A version of the model DC-0010-INF-M2-D-0001 is loaded into the system by the architect (message 1 in the sequence diagram) and is placed in the work-in-progress area identified with S0/WIP. (Note that for the stereotypical <<enumeration>> stateInCDE, <<enumeration>> approvalState and <<enumeration>> suitableFor, the smart contract manages the states of several instances of information in the four areas of a CDE. See footnote 8.)