SOG Appendix

Logic Models as Multi-Level Hoare Triples Logic models describe the chains of causes and effects leading to an outcome. While many logic models use a four-step process (Input, Activities, Output, and Outcomes/Impacts), logic models can be turned into concise (one page) document, listing the abstract goal statements in a triple, called: Context -> Actionable Goal -> Success Criteria, and another triple called Input -> Process -> Output. This is structurally identical to a Hoare Triple, which consists of three things:

Pre-Condition   →   Command   →   Post-Condition

A logic model is shown in the following example:

Logic Model (Smart Contract) Template:LogicModel 12 8, 2022
Abstract Specification Context Smart Contract is a piece of program that would guarantee transparency and non-corruptibility of its execution logic. For scalable deployment, blockchain technologies and infrastructures are often required to guarantee data security. Goal Manage human readable contract description, source code of the Smart Contracts, and execution trace data all in a unifying system, namely PKC. Success Criteria Assign timestamps to all data assets using blockchain infrastructures. Make at least 3 copies of data backups. Allow 1 hour cycle time to backup all data.
Concrete Implementation Given Inputs When Process is executed... Then, we get Outputs A set of stakeholders that are identified through Externally Owned Accounts. An interface to create Smart Contracts. An interface to enter data to each of the created Smart Contracts. A running instance of PKC that hosts all execution of the Smart Contracts. An Ethereum-based blockchain to support the time-stamping services. A growing list of Smart Contracts viewable through web browsers A web browser-based navigation user interface to view the execution trace of each contract A growing history of data assets.
Boundary/Safety Conditions of Smart Contract The running instance of PKC fails completely. The supporting blockchain fails.

A logic model can also be considered as a macro-structure, which can be condensed into a higher order triple: Abstract Specification → Execution Plan → Boundary Conditions From a Correct by Design viewpoint, it is necessary to convert all structures into a Hoare Triple. Therefore, one can use the same data structure to organize all causal relations into temporally-ordered data elements. The consistent format allows convenient verification and version control of these three types of information containers, and can be executed and validated using humans or machines. The idea of a logic model being composed of a multi-level Hoare Triple can be illustrated as follows:

The box marked Hash-Code contains two Hoare Triples. The left one is the Context→Goal→Success Criteria triple. The right one is the Inputs→Process→Outputs triple. It is the intention in the diagram to show that there could be many implementation approaches to satisfy abstract specification. Therefore, the diagram has many other entries for Inputs→Process→Outputs Hoare Triples. The overall logic model as a “Ricardian Contract” is shown on the top of the above diagram as a collection of Human Readable Text. Hash-Code entables bundled data and a piece of Smart Contract code that can be executed by machines “reliably.” The operation of such a “Ricardian Contract” would generate execution logs, and its anomaly or conditions that might break in any known or unknown cause can be captured as a “Boundary Condition of Logic Model” and stored in a common data structure, similar to the notion of exception capture in modern programming languages. The three kinds of Hoare Triple, including the last one that is the “higher level” Hoare Triple, treating “Boundary Conditions” as a Postcondition, is a nested data structure that allows many different pieces of content knowledge to be composed of different instances of textual descriptions, executable code, and data type descriptions. This provides a mechanism to store and capture all kinds of enforcement mechanisms, which therefore can serve as a generic data container for information. The numbers that marks these boxes, 4, 1, 7 for Context→Goal→Success Criteria,

and 5, 2, 6 for Inputs→Process→Outputs, can be found in the following Venn diagram:

Each of the numbers represents a “Namespace” that covers a different area of interpretive interest. The goal of this Venn Diagram is to help classify content knowledge in categorized namespaces that each lead to appropriate interpretive actions, so that knowledge content can be managed in a consistent manner, using appropriate computational or human interpretation approaches. Also important to note is that a logic model/logic frame is a tool that is being used by many government agencies to express the intent and expected outcomes of government-sponsored programs. This short explanatory text and diagrams hope to present a path to organize traditional pen/paper content of the model to a computable medium that can be captured directly in tools such as MediaWiki. In fact, the first screenshot of the logic model is an implementation of a logic model template in MediaWiki. In other words, the notion of using a logic model in a relational/hypertext oriented data storage is already feasible. With a proper set of tools, such as using Blockchain and Smart Contract to assign trustworthy timestamps and unique hash code to a Smart Contract, one can make information and contract execution globally transparent in ways that traditional logic models cannot do. It will be a very pragmatic and powerful tool for governmental project management and control, since it will help easily track all kinds of changes in the logic model with access and links to many other kinds of digitized data content. In other words, logic models can serve as a human-machine front end to the full stack of Technology Stack for Building Trust (Tech for Trust).