Inter-Organizational Workflow

Also known as: PKC DevOps Cycle

Introduction

The purpose of PKC Workflow, or the PKC DevOps Cycle, is about leveraging well-known data processing tools to manage source code, binary files in a unifying abstraction framework. A framework that treats data in three types of universal abstractions.

1. File from the Past: All data collection in the past can be bundled in Files.
2. Page of the Present: All data to be interactive presented to human agents are shown as Pages.
3. Service of the Future: All data to be obtained by other data manipulation processes are known as Services.

By managing the classifying data assets in terms of files, pages, and services using version control systems, we can incrementally sift through data in three namespaces that intuitively labels the nature of data according to time progression, which reflects the partially ordered nature of PKC Workflow, which is also the universal property of each DevOps cycle.

Given the above-mentioned assumptions, data asset can be organized according to these three types in the following way:

1. Files can be managed using Content-addressing networks, their content will not be changeable, since they can be stored in IPFS format.
2. Pages are composed of data content, style templates, and UI/UX code. This requires certain test and verification procedure to endure their healthy operations.
3. Services are programs that have well-known names and should be provisioned on computing devices with service quality assessment. They are usually associated with Docker-like container technologies and have published names registered in places like Docker hub. As service provisioning technologies mature, tools such as Kubernetes will be managing services with service quality real-time updates, so that the behavior of data services can be tracked and diagnosed with industry-strength protocols.

Notes

• When writing a logic model, one should be aware of the difference between concept and instance.
• A logic model is composed of lots of submodels. When not intending to specify the abstract part of them, one could only use Function Model.
• What is the relationship between the model submodules, and the relationships among all the subfunctions?
• Note: Sometimes, the input and process are ambiguous. For example, the Service namespace is required to achieve the goal. It might be an input or the product along the process. In general, both the input and process contain uncertainty and need a decision.
• The parameter of Logic Model is minimized to its name, which is the most important part of it. The name should be summarized from its value.
• Note that, when naming as Jenkins, it means the resource itself, but when naming as Jenkin Implementation On PKC, it consists of more context information therefore is more suitable.
• I was intending to name "PKC Workflow/Jenkins Integration" for the PCK Workflow's submodel. However, a more proper name might be Task/Jenkins Integration, and then take its output to PKC Workflow/Automation. The organization of the PKC Workflow should be the project, and the Workflow should be the desired output of the project. The Task category is for moving to that state. So the task could be the process of a Project, and the output of the task could serve as the process of the workflow.
• Each goal is associated with a static plan and dynamic process.

• To specify input and output from a logic model, we could get the input/output on every subprocess in the process (by transclusion)
• I renamed some models
  • TLA+ Workflow -> System Verification
  • Docker Workflow -> Docker registry
  • Question: How should we name? Naming is a kind of summarization that loses information.

Logic Model (PKC Workflow) Template:LogicModel 02 9, 2022
Abstract Specification Context This is the 2021 summer project of Tz-Chuang starting from June 27, 2021 to August 21,2021. Despite the various models for domain knowledge, there isn't a high-level model which is expressive, compact, practical, and independent of domains. This gives rise to Logic Model. Goal Utilize formal methods to prove the system's soundness Use Logic Model to describe the project itself. Theorize Logic Model based on the implementation. Success Criteria An example of how the formal method could integrate into Logic Model is demonstrated. The Logic Models of the project are defined correctly The core concepts which explain the Logic Model is defined.
Concrete Implementation Given Inputs When Process is executed... Then, we get Outputs System Verification Software/TLA+ Tools PKC System Specification Knowledge/TLA+ Tools Jenkins Integration Jenkins setup A service namespace Docker Registry Docker Docker registry tutorial Image Naming System Verification by TLA+ Jenkins Integration Docker Registry Meeting and Communication Issues Updates All activities PKC Workflow/Knowledge PKC Workflow/Drafts PKC Workflow/Project Conclusion PKC Workflow/Presentation
Boundary/Safety Conditions of PKC Workflow 6 weeks of project time.