Core-System V. 6.7
This is the English Version. For the German (original) version, see README.md.
Table of Contents
-
- § Special Powers of the Divisions of the Security and Defense Chamber
- § Powers of the Divisions of the Development Chamber
- § Powers of the Divisions of the Economy Chamber
- § Powers of the Divisions of the Health Chamber
- § Powers of the Divisions of the Information Chamber
- § Confidentiality and Protection of Fundamental System Components
-
- § Synchronization Session
- § Creating and Modifying the Input Protocol
- § Creating and Modifying the Output Protocol
- § Definition of “Next Execution”
- § Monthly Session (Committee Session)
- § Annual Session (Anniversary)
- § Rule Violations
-
- § The Core Pact
- § Alignment with the Values of the Manifest
FUNDAMENTAL META PROVISIONS
§ General Provisions on the Constitution
The content of this system constitution is binding for the entire emerging system.
No changes may be made to it outside the mechanisms established here.
This document, the system constitution of the Core, may only be adapted in content if the continued existence of the Core is endangered by the constitution in its unchanged form.
Only the author themself may fully dispose of their own Core.
This version of the constitution is based on Constitution Number 6 (“final constitution”) and does not declare a new version number. All additions regarding versioning are only for the purpose of tracking changes and mere naming.
Footnotes must be observed. If this document is formally changed, each new version must be substantively identical to the final result of the initial version.
The constitution may only be released and signed for the pilot phase once all resources that contribute to a functional system have been created. Only after the pilot phase may the final system launch take place.
If the constitution has been signed, the first signed printed copy is considered its original; all further copies are considered duplicates. After signing, there will be no additional preamble, and Version 6 is henceforth to be considered complete and valid.
The original printed version of the constitution must be protected and stored to guard against weather, fire, water, unauthorized access, and other potential causes of loss.
The system must be secured, to a reasonable, appropriate, and at least sufficient degree, against malicious external, crude, violent, and insidious intrusion.
§ Nature of the Core System
The Core System is an organizational framework that operates on the meta-level of life. It not only manages individual projects or smaller tasks, but refers to the overarching organization, orchestration, and interconnection of all areas of life and activities.
As an integral reference system, it serves as the central coordination hub for decision-making and goal realization. By employing its comprehensive set of rules and methods, it ensures that individual potential is maximally realized. Through the structured coordination of all areas of life, the Core System enables a targeted alignment toward high ambitions and aspirations.
§ Adjustment and Establishment Period
This constitution serves as a well-founded basis for setting up and implementing the Core System. It takes effect immediately after signature. A review and adjustment period of three months is provided during which modifications and clarifications may be made, particularly to the constitution, to ensure the system’s effectiveness and stable foundation. Nonetheless, by signing this document, the essential basis of the new system version is established and is not subject to challenge.
§ Inventory of the Current Life Situation
The constitution stipulates that before activating the Core System, upon each new constitution version, and at each internal conformity check, a detailed inventory of the current life situation is carried out to measure the effectiveness and changes brought about by the system. This includes routines, projects, and successes as a basis for comparison and for the development of management entities and methods in the rulebook. Furthermore, if available, based on previous versions of the constitution and the current lifestyle, the success rate of the constitution is assessed.
§ Validity and Interpretation of the Constitution
The constitution is the supreme authority of the Core System.
All activities and decisions within the system must be in accordance with the principles and regulations set out in the constitution.
Interpretational Authority
The interpretation of the constitution is the responsibility of System Jurisprudence¹, always prioritizing the well-being of the system and the individual.
Exit Procedure
Exiting must be initiated and documented in writing, stating reasons and consents. Further provisions on this can be found in the course of the constitution.
COMPONENTS OF THE CORE SYSTEM
§ Fundamental Definitions
The term “execution” is used to describe the human’s actions outside direct organizational-structure activities conducted in sessions.
The entirety of the organizational framework is referred to below as the “Core” (system core, kernel). In addition to the constitution and the execution, the Core System consists of various components that work together to achieve its overall objectives and maintain its organizational structure. Each component has a specific role and responsibility within the system.
§ System Administration
System administration is the node of the system that entrusts the execution with upcoming tasks in accordance with the rulebook and synchronizes the system’s components; likewise, it is assigned any form of meta-organizational activity.
Hierarchy of the Core System
The hierarchy is part of system administration and is decisive for the rulebook. It can be used to allocate methods within the rulebook. Moreover, it ensures comprehensive coverage of all areas of life through consciously generalized subcomponents, so that every task and activity can be assigned under it.
Coding Schema – System Coding
Each element in the hierarchy is assigned a coding schema — as individually described in the following sections — so that the total of these coding schemata forms the system coding. This serves as a simple, system-universal reference to particular elements of the hierarchy.
Components of the Hierarchy
The hierarchy consists of the following components:
Chambers
Chambers represent the fundamental pillars of personal life and are coded by unique uppercase letter sequences reflecting their position in the system hierarchy. As the highest instance in the hierarchy, chambers determine the strategic direction for the six fundamental areas of life. Their directives and decisions form the framework within which divisions and units can operate. There are six chambers:
-
Information:
This chamber focuses on the management, organization, verification, evaluation, acquisition, and use of information. Among other things, it ensures that all relevant information is recorded, properly categorized, and made accessible -
Development:
The Development Chamber is responsible for general development aspects, including progress, time management, system maintenance, operations, and, for instance, physical constructions -
Security and Defense:
Responsible, among other things, for protecting and defending the physical, digital, and legal integrity and conformity of the system and the individual. It ensures that all aspects of life are secure, have integrity, and are protected, and it safeguards the system as well as the other areas of life -
Economy:
This chamber is responsible for managing and deploying resources and finances. It ensures that the resource-related and financial-economic aspects of life are managed and utilized efficiently and effectively -
Health:
The Health Chamber takes care of physical and mental health and general well-being. It ensures that the individual’s health is, and can be, safeguarded -
Social-Human:
The Social-Human Chamber focuses on social and humanitarian aspects of life, including social activities, relationships, and cultural aspects. It also dedicates itself to the individual themself, for example focusing on their well-being and reflecting upon their character, its formation, and qualities
Units
Units are subordinate areas of action within the chambers, serving for more refined structuring. They are coded by distinct lowercase letter sequences that express their specific position within the system hierarchy.
Divisions
Divisions, as subcategories of units, represent task domains. Only under their heading are methods defined, declared, and documented within the rulebook. They thus serve as the structural basis for recording and categorizing these methods. Their coding consists of a locally unique numerical sequence. Combined with the coding of the associated unit and chamber, this numerical sequence provides a unique identifier. The numeric sequence follows a chronologically ascending order.
Division for System Jurisprudence
System Jurisprudence is a division of the system and serves as the judicial organ of the Core System. It alone holds the authority to decide on system-internal questions, conflicts, and resolutions within the framework of the constitution.
Division of Decision-Making
Decision-making plays a central key role in the Core System and is directly subordinate to the Security and Defense Chamber as well as System Administration. Its tasks include documenting decisions and reasons that are of system-wide interest to the Core System.
The Rulebook
The rulebook refers to the central documentary collection in which the methods of the Core System are defined. It is part of system administration.
Syntax and Expressions in the Rulebook
The rulebook employs a special, programming-language-like syntax to define and execute methods precisely and efficiently. This syntax includes various expressions and symbols, each performing specific functions in the context of the rulebook.
| Syntax Expression | Description |
|---|---|
#M1-Name |
Method Declaration: Hash prefix, method coding (without system coding) (in this example “M1”), dash, and method name (last part, here “Name”) |
@ |
Prefix for reference to another method |
?( x ) |
Checks whether condition x is met. If yes, it continues with the next processing handover. If no, proceed with the instruction after the Or operator. If there are multiple Or operators, there are multiple possible further procedures, checked in order |
== |
Then operator, can only be used immediately following a condition expression. The subsequent content is executed only if the condition is met. A subsequent “Or” operator should be interpreted as “if this condition is not met, then do…” |
=> |
Subsequent or “Afterwards” operator, i.e. step transition |
!(X) |
Assign instruction X for execution (instruction = reactive measure) |
/ |
(Operator) Or operator for selecting between multiple possibilities. Order is decisive |
+ |
(Operator) Can [only] link instructions that can be executed in parallel |
: |
(Operator) Serves as a comparison operator for comparing specifications, data, or other content |
$[examplex].[Data] |
Concretized, specific reference to data acquisition “Data” in the administration “examplex” (the specification of the administration clarifies the data context) |
%( x ) |
Refers to the resource x (referenced by a system-universal identifier of the intended resource) |
{ x } |
The active method is further specified by x. The specification is passed on as a comment during execution |
; |
Marks the end of a logic section within a method. It should not be used in new methods, as splitting into multiple methods is preferred. Mainly used to transform older versions of the rulebook into the new format |
;; |
End of a method. It can only occur once per method. If further logic sections are needed, the method must be split into several methods |
Mandatory Use of Syntax
The use and adherence to the syntax[parameters] is mandatory for documenting methods and ensures clarity, efficiency, and systematic processing within the rulebook. However, this rule explicitly does not apply to bodies within the rulebook that function as registers, nor to their content.
Routine List
The routine list is a tabular collection of ordered routines. It contains the following columns:
- Precisely worded routine name matching the activity to be performed
- Execution interval
- Causal justification
- Objective of the routine
- Start
- End
- Optionally: exactly one method identifier assigned to the routine process
Check Question System
How Check Questions Work
Check questions serve as primary triggers for activating methods. Each check question is linked to a method and answered with ‘Yes’ or ‘No.’ The cardinalities between check questions and methods allow multiple identical check questions to be linked to a single method, as well as a method being assigned to exactly one check question. In an optimal formulation of the question regarding clarity, the check question refers to concrete metrics and is concise and easy to understand.
Check Question Register
A check question register is established as a central element of the Core System. This register documents all check questions and assigns them to the corresponding methods. The check question register also records metrics to facilitate a guided response to the check questions. Metrics in the check question register are treated as identifiers and should be standardized — potentially by corresponding methods in the rulebook. The check question register may also use formatting to clarify the meaning of a question.
Administrations
Below are rules regarding administrations.
Creating Administrations
To create an administration, it only needs to be recorded in the central administration register together with the necessary data.
“Necessary data” is defined by the assignment of metrics to an administration in the central administration register.
Designation of Administrations
Each administrative unit in the Core System must have a unique and non-recurring name. This name serves as an unmistakable identifier and ensures clear distinction of each administrative unit within the overall system. The name of an administrative unit must directly derive from its primary function or main area of responsibility. All names of administrative units must be recorded in the central administration register. If the scope of an administrative unit changes significantly, its name must be reviewed and possibly adjusted. This must be well-founded in Decision-Making, explaining why the name changes and a new administration is not created.
Assignment to the System
Administrations must be stable and assigned to the Core.
Moreover, the administration’s data must be secured, protected, and archivable, as well as exportable in an appropriate manner.
Administrations in the Rulebook
By establishing a central administration register, the separate establishment of administrations through methods becomes undesirable due to increasing complexity and thus an unnecessary burden for synchronization sessions. However, there is no general or absolute prohibition in urgent cases. This especially refers to creating methods purely for administrations and their handling.
Central Administration Register
Within the Core System, a central administration register is established, directly subordinate to system administration.
It is regarded as an integral part and continuation of the rulebook and endowed with normative features. Such a register is indispensable since an overview of administrations would otherwise not be guaranteed, and there would be no central reference point for the rulebook. The following subparagraphs are attributed to the central administration register.
Acquisition Resources and Data Collection
Data is collected through specified acquisition resources, which are assigned to the corresponding administrative units in the central administration register. Acquisition resources must have a clear and unique designation, provide adequately secured and protected data acquisition, and be assignable to the Core System. They must also be archivable and exportable.
Administrative resources may be acquisition resources. However, the reverse is not necessarily true. Data redundancy between administrations should be avoided.
A critical feature of acquisition resources is that they are not storage resources unless they also simultaneously serve administration.
Distinctions
An administrative resource is a tool or system used for the active management of data within the rulebook. It enables organizing, editing, storing, or accessing data.
An acquisition resource, by contrast, is a tool used for collecting or capturing data. These data are then used for administrative purposes.
If an administrative resource is also used for data acquisition, it simultaneously functions as an acquisition resource. In this case, the administrative resource is responsible for both capturing and subsequently managing the data. However, if the same tool is not used for capturing and for managing data, the separate tool that does the data collection is referred to as an acquisition resource.
Metadata²
Metadata in the central administration register includes all data that help define the nature of administrations. This includes, for example, the classification and localization in the infrastructure. Metadata must be standardized by the appropriate responsible methods and divisions.
System Input
System input serves as the interface for introducing data into the Core System. Its main tasks are the recording of new and the review of existing check questions³.
Input Protocol
The input protocol is used to record answers to check questions and to synchronize acquisition resources that are separate from administrative resources. Additionally, the input protocol functions as an administration on which methods in the rulebook may rely. This facilitates the transfer of the rulebook and enables methods to assign data to an administration that, due to its temporary or specially method-related nature, does not belong to another administration.
These elements are listed in the input protocol and presented for review in the synchronization session. A template is used for the presentation of the input protocol; it must be reviewed for currency in each synchronization session and updated if necessary.
System Output
System output is directed toward the implementation instance of the Core System⁴. It is responsible for issuing specific tasks to be carried out, including project tasks, process tasks, measures, routines, nonbinding tasks, appointments, and all other types of tasks.
Output Protocol
These tasks result from the application of activated methods and method chains recorded in the rulebook.
They are handed over to the execution in documented form.
Henceforth, this document is referred to as the output protocol.
General Plan
Structure and Purpose of the General Plan
The General Plan serves the comprehensive organization, orchestration / coordination, and overview of the system’s development, covering all levels of (temporal) planning. It arranges the Manifest as the highest guiding level, followed by the system’s objectives. Under these objectives are subsumed projects, processes, routines, appointments, measures, and other tasks and progress. The complete set of objectives is composed of the six chambers’ goal specifications, the framework of the Manifest, and the annual targets (see later in this document).
Types and Definitions of Task Contexts and Groupings
Task Categorization
- Projects are task categorizations leading to multiple subordinate, goal-oriented tasks. They are result- and goal-focused, one-time, time-limited, consist of multiple tasks, and require a project plan
- Processes are also task categorizations leading to multiple subordinate, goal-oriented tasks; they have the same characteristics as projects but are repeatable, enduring, and not time-limited
- Routines are tasks that recur regularly, whose data — at least causality and frequency — must be documented in the General Plan
- Appointments are tasks with a specific purpose and are time-bound
- Measures are concrete reactions to clearly defined circumstances triggered by methods
- Nonbinding tasks are tasks that are neither location- or time-bound, nor represent a concrete reaction; i.e., tasks that are neither measures nor appointments
Organization as Instances
For each of the above elements, including each individual project, a separate instance exists in the General Plan. Each of these instances is provided with a set of dated tasks — unless it is itself a task — that are necessary for implementation and success control.
Types of Groupings as Task Packages
Tasks can be categorized in different package forms:
- Direct Task Packages: tasks must be executed in an immediate sequence without interruption by external tasks
- Sequence Task Packages: tasks require a specific order of execution, but not necessarily immediately one after another
- Vector Task Packages: combine both properties; they require an immediate temporal sequence of execution as well as adherence to a specific order
- Loose Task Packages: include tasks that require neither a strict sequence nor an immediate sequence of execution
If multiple tasks arise due to the activation of a method which are handed over to the execution, the type of task package can either be directly specified by the method or be set in the synchronization session. By default, a Sequence Task Package is assigned to the task package that has been created.
Categorization of Existing Tasks
A method in the rulebook of the Division of General Planning must determine how a task is to be classified.
Prioritization of Tasks
Task prioritization is derived from the evaluation system using the following scale, where the maximum score for a task is 8 points; the maximum score means maximum priority:
-
Urgency (0-2 points)
0 points: no deadline or deadline not relevant
1 point: not urgent; deadline is far away or flexible
2 points: very urgent; immediate action required or deadline is very close -
Importance (0-2 points)
0 points: no impact on overall objectives
1 point: less important; low impact on overall objectives
2 points: very important; critical to success or has a high impact on overall objectives -
Effort (0-2 points)
0 points: can be done immediately without further resource expenditure
1 point: low effort; can be completed quickly with existing resources
2 points: high effort; requires extensive resources -
Strategic Significance (0-2 points)
0 points: contributes only indirectly to long-term goals and is not decisive
1 point: low strategic significance; but directly contributes to the long-term vision
2 points: high strategic significance; crucial for long-term goals and development
General Plan in the Synchronization Session
It is mandatory to maintain, update, and integrate the General Plan into daily synchronization sessions.
All goals and projects recorded in the General Plan must be accepted or rejected via a clear decision-making process, regardless of whether they were proposed by chambers or other system elements — unless they are products of specific methods from the rulebook.
§ Methods in the Core System
Within the Core System, methods are specified instructions on how tasks are to be executed. Each is assigned to a division. They guide the implementation procedures in the Core System.
Method Names
Every method must have a unique name / title, which is documented in the rulebook. Before creating and implementing a new method, it must be ensured that the chosen method name is unique within the rulebook. The uniqueness of the name guarantees unambiguous identification and reference to the respective method across all associated processes, documentations, and communications.
Method Codings
Furthermore, methods receive method codings for better identification, consisting of the system coding, “M,” and a numeric combination, where the numeric combination follows a chronologically ascending order corresponding to the number of methods in the active / division to which the method belongs. Method codings can be used to reference a specific method; by the nature of the coding, its position in the hierarchy is immediately apparent. To declare a method in the rulebook, the system coding is omitted, a hash prefix is placed before the “M,” and a dash is placed between the numeric combination (the method coding) and the method name.
Creating Methods
Methods are recorded in the rulebook under the appropriate division according to the specified syntax of the constitution. It should be ensured that the method can be activated by a check question if not already triggered by another method as part of a method chain. A method can have exactly one check question.
Before creation, it must also be verified that it is not contradictory or redundant with any other existing method.
Moreover, the subparagraphs below apply when creating a method.
Registration Requirement for Administrative Units in Methods
Mandatory Registration of Administrative Units
All administrative units established or used in the context of a method must be recorded and documented in the central administration register of system administration.
Correction of Discrepancies in the Central Administration Register
If there is any discrepancy between the administrative units recorded in the central administration register and those used in a method, the corresponding administrative unit must be promptly added to the register.
Registration Requirement for Data in Methods
Mandatory Data Registration
All data that is collected, processed, or otherwise used by administrative units in the context of the rulebook or implemented in methods must be documented in the central administration register.
Correction of Discrepancies in the Central Administration Register
If there is a discrepancy between the data documented in the central administration register and the data used in a method, the relevant data must be immediately added and updated in the register.
Division Framework
Once the method’s scope, as defined by the division’s set area of responsibility, is exceeded, and as soon as this can be reasonably determined, a new method must be created. The original method must then reference the new method.
Changing Methods
Changes to methods should be justified and documented in Decision-Making.
Definition of Method Chains
In the context of the Core System, method chains refer to structured and systematically created sequences of methods connected by references. They serve the purposeful and efficient approach to specific tasks or responses to specific situations. Within a method chain, individual methods are interlinked and logically build upon each other to ensure a coherent and goal-oriented workflow. Method chains arise automatically when referencing other methods via their respective titles within the current method.
§ Identifiers
Usage
Identifiers are unique, unmistakable, and specific names used to identify and reference elements within the entire system in a precise manner.
Naming and Formatting
Identifiers must always be unique in their naming and must not overlap with other identifiers to ensure clear and unambiguous assignment. They must be designed in such a way that they can be distinguished from other identifiers.
The primary functionality of an identifier — i.e., the specific goal or task it represents — must be clearly recognizable in its naming.
Identifiers must not contain spaces. They must be written as one continuous word. A separation by hyphens is only permissible if it is absolutely necessary for clarity or readability.
Reference Sentences
Identifiers must necessarily be recorded and documented in at least one body of the rulebook. System-universal references to identifiers are valid and applicable at all times and in every context of the Core System.
Definition and Standardization
Further definition and standardization of identifiers is the responsibility of the relevant divisions within the rulebook, unless the constitution of the Core System makes explicit regulations.
§ Sum of the Components
Together, the components established here form the Core System and contribute to achieving its goals and execution. Each component must act in accordance with the constitution of the Core System and its provisions.
AUTHORIZATIONS
§ Special Powers of the Divisions of the Security and Defense Chamber
Divisions of the Security and Defense Chamber have the exclusive power to oversee and approve the prioritization of tasks throughout the system. They are authorized to determine the rank and priority of tasks to ensure the security and stability of the system. They are responsible for conducting threat assessments and, based on these, making priority decisions. They have the authority to designate urgent tasks and approve the necessary resource allocation to carry out such tasks.
Consultation Requirement
However, decisions made by these divisions may not be taken without prior consultation and involvement of situational assessments and data from the divisions of the other chambers. These must openly present their respective situations, circumstances, and assessments in a concise manner, which the Security and Defense Chamber will then consider in its decision-making.
Extraordinary Decision Cases
In extraordinary cases where prioritizing a task of any kind could jeopardize the fulfillment of a project goal, process goal, or measure (and its related contexts), the decision on how to set priorities must be documented with particular care. This documentation should include the reasons for the change, the tasks involved, and the potential impact on other tasks and their interrelationships.
§ Powers of the Divisions of the Development Chamber
Divisions of the Development Chamber have the exclusive authority to coordinate and lead the entire system development progress, excluding matters of system jurisprudence and the development goals of other chambers. They have the power to coordinate and direct the activities and tasks of other chambers’ divisions with regard to general development progress. This includes, but is not limited to, establishing general development guidelines, conducting system analyses, and creating improvement plans. Their powers end where other chambers’ or divisions’ special rights, granted by the constitution, begin.
§ Powers of the Divisions of the Economy Chamber
Divisions of the Economy Chamber have the exclusive authority to manage and control all system-internal inventories and finances. They are responsible for coordinating and monitoring the use and distribution of inventories to ensure the system’s efficiency and sustainability. They also have the power to develop and implement financial strategies that support the financial stability and growth of the system. Their powers end where other chambers’ or divisions’ special rights, granted by the constitution, begin.
§ Powers of the Divisions of the Health Chamber
Divisions of the Health Chamber have the exclusive authority to steer, coordinate, and oversee all health-related aspects of the system. They are authorized to set guidelines for the physical and psychological well-being of the execution, plan preventive measures, and initiate health-promoting initiatives. They also have the power to issue urgent measures in health emergencies and to allocate necessary resources. In exceptional and critical cases, the Health Chamber can compel the Security and Defense Chamber to prioritize its concerns, namely if there is an active threat to the continued existence of the system or the individual themself.
§ Powers of the Divisions of the Information Chamber
Divisions of the Information Chamber have exclusive and comprehensive authority over the collection, analysis, verification, validation, evaluation, and generation of all system-relevant information. They are the sole instance coordinating the information flow and ensuring the correctness of information throughout the system. All methods and processes that require the generation of new information must report directly to a responsible division of the Information Chamber. Providing and disseminating information is subject to the security guidelines established by the Security and Defense Chamber. Divisions of the Information Chamber are furthermore authorized to develop and implement their own strategies for effective information management, with security aspects regulated exclusively by the Security and Defense Chamber.
§ Confidentiality and Protection of Fundamental System Components
The check question register, the central administration register, the general plan, and the rulebook are fundamental components of the Core System and are subject to the highest level of confidentiality. The detailed development of security measures and procedures, including determining which other system elements should be kept confidential, is the responsibility of the appropriate divisions and methods, to be decided at a later time.
PROCEDURE
§ Synchronization Session
The synchronization session ensures that the system is continually brought up to date and that tasks are carried out with the latest information. In this version of the constitution, it thus establishes a practical, stable, direct, and consistent link to the Core.
Time Interval and Overruns
A synchronization session should be held at least every 48 hours and at most every 12 hours. It should not last longer than 6 hours and should take place under reasonable mental competence.
Tasks of the Session
During the synchronization session, the following tasks are performed:
Processing the Input Protocol (System Input)
Processing Progress and Executed Activities
One essential task of the synchronization session is checking the tasks carried out during an execution interval and transferring the resulting progress into the General Plan. Tasks that were not completed or left undone are also reviewed. These tasks are then reassigned to the execution or considered closed. If a repeatedly uncompleted task was handed over for execution as necessary, corresponding measures must be taken to address the execution shortfall.
Reviewing and Answering Check Questions
Within the synchronization session, all check questions listed in the check question register are systematically reviewed. Each question is considered individually and answered with ‘Yes’ or ‘No.’ If a question is answered with ‘Yes,’ the associated method is triggered.
Documentation and Processing of Triggered Methods
For each check question answered with ‘Yes,’ it is noted that the corresponding method is triggered. Once all check questions have been answered, the triggered methods are systematically reviewed. They are then processed further based on their priority and relevance.
Synchronization of Acquisition and Administrative Resources
During the synchronization session, there is a specific data reconciliation for data gathered by acquisition resources but not directly recorded in the corresponding administrative resources. In cases where acquisition resources and administrative resources are not identical, the data collected by the acquisition resources are transferred to the respective administrative resources. These various acquisition resources are already listed in the input protocol.
Issuing the Output Protocol (System Output)
Tasks are prioritized by the Security and Defense Chamber after consultation with the divisions of all other chambers.
The General Plan is updated accordingly.
A new output protocol is created containing tasks until the next synchronization session, according to the prioritization set by the Security and Defense Chamber.
Documentation Requirement
Both the modified input protocol and the newly created output protocol must be archived after each synchronization session, and every session must be recorded in a logbook of system administration.
§ Creating and Modifying the Input Protocol
Template Creation
The input protocol is created using a template. The template is described below and divided into four sections.
Section 1
Progress Tracking
For the General Plan and overall system viability, it is essential that the tasks assigned by the previous session are documented in the input protocol, even if it may appear redundant to various administrations and administrative resources. Progress is tracked by embedding the previous output protocol under this section, with checkboxes next to tasks. If a task has been completed, the checkbox is marked.
Documentation of Routines
The entire structure and definition of routines are the responsibility of the responsible divisions of the Development Chamber. They are fully documented via the respective administrative structures and resources.
Section 2
The second section of the input protocol template is structured in tabular form with four columns. Aside from the checkboxes, it is essentially a factual copy of the check question register. This structure is intended for the systematic collection and processing of data during synchronization sessions.
- The first column of the template contains checkboxes to visually mark whether a check question has been answered with ‘Yes’ (thus activating the assigned method) during the session
- The second column contains the check questions themselves, as recorded in the check question register
- The third column lists the methods associated with the respective check questions, also based on entries in the check question register
- The fourth column includes possible metrics that may be helpful in answering the check questions, likewise as recorded in the check question register
Section 3
After the section on check questions and methods, the template lists the acquisition resources that differ from administrative resources. This list is used to identify and address discrepancies between collected data and the data in the administrative resources during the synchronization session.
Section 4
The last section is dedicated to the input protocol’s function as an administration. It thus serves as an administrative and acquisition resource for various data, which are assigned in the rulebook to the administration of the input protocol. These data must be collected in a practical and efficient manner.
Modification
The input protocol template is modified when new check questions are added and the check question register is changed accordingly.
Updating and Archiving
Before each execution, i.e., before the next synchronization session, the input protocol is recreated using the described template and archived after the synchronization session.
§ Creating and Modifying the Output Protocol
Protocol Structure and Contents
The output protocol is created for the next 24 hours and contains tasks of any kind along with relevant and/or necessary task information until the next synchronization session.
The output protocol is structured so that it does not include all possible routines. This restriction is meant to ensure a focused and efficient approach to execution.
Standardizations
The nature of the output protocol may be standardized by the divisions of the Security and Defense Chamber, the Information Chamber, and the Development Chamber.
New Creation and Archiving
The output protocol is recreated at each synchronization session using the described template and archived thereafter.
§ Definition of “Next Execution”
“Next execution” refers to the period between two consecutive synchronization sessions. During this period, the tasks, routines, and projects listed in the output protocol are processed. The next execution ends at the following synchronization session, when a new output protocol is created and the previous input protocol is revised.
Establishing Check Questions for New Methods
The following points must be observed when developing check questions:
Basis for Check Questions
When developing new methods in the rulebook, occurring circumstances (causalities), the goals and purposes of a method, and metrics to be collected must be used as the basis for determining deterministic check questions.
Planned Approach
Creating check questions should include a thorough analysis covering these steps:
- Identifying circumstances that may directly or indirectly affect the application of the method
- Determining metrics that provide quantifiable data on which check questions can be formulated
- Deriving thresholds or criteria whose attainment triggers the respective method
§ Monthly Session (Committee Session)
For the continuous improvement and adaptation of the system, system administration holds a monthly committee session on the first day of each month. These sessions address current system issues and challenges with a special focus, and adjust/revise the chambers’ goal orientations. Moreover, important decisions (possibly with voting if required) are made. Additionally, a current situation assessment is conducted by examining the divisions’ areas of responsibility for upcoming tasks, shortcomings, and the overall current status. The results and decisions of each session are documented and archived to ensure lasting transparency and traceability.
The committee session follows this procedure:
- Creating the session — drafting a session protocol (possibly with outline)
- Conducting a current situation assessment — reviewing objectives, progress, the integrity of the status quo with the General Plan, and the alignment of the theoretical system with practical operations
- Exercising special rights — making system modifications with supplementary normative authority to expand, specify, and extend the constitution and the Manifest, possibly after an appropriate voting procedure
- Updating the General Plan, objectives, and the Manifest
§ Annual Session (Anniversary)
The Core System celebrates its anniversary with an annual session. It takes place on the anniversary of the system’s commissioning and serves as an opportunity to review the constitution and discuss and implement any changes or adaptations, as well as to set annual targets. This session also offers the chance to ceremonially reaffirm the system by signing the anniversary document, underscoring the commitment to maintaining and improving the system. The anniversary is December 31st: the date of signing the Core System constitution on December 31st, 2020.
§ Rule Violations
Rule violations are tolerated. However, if discovered, they must be documented by system administration, and appropriate corrective measures must be taken.
VALUE ESTABLISHMENT
§ The Core Pact
Definition and Purpose of the Core Pact
The Core Pact is a binding element of the constitution and establishes specific, significant promises. It ensures the credibility and obligation of these promises and guarantees their fulfillment.
Mandatory Application
The Core Pact is to be applied when the necessity of a promise arises.
In this context, necessity may imply an unconditional need for action, high relevance, or the requirement to lend additional credibility to the promise through the pact.
Realistic Promises
The Core Pact must include realistic, measurable, and feasible promises. Promises deemed unrealistic or too vague may not be incorporated into the Core Pact.
Preliminary Review of the Core Pact
Before a Core Pact is adopted, it must undergo a thorough review. This review includes verifying the alignment of the Core Pact with the basic principles and values of the Core System under the constitution, as well as assessing feasibility and interference with other commitments and ongoing activities.
Documentation Requirement
A comprehensive record must be kept for each established Core Pact. This documentation must include all relevant information, including but not limited to the subject and purpose of the promise, involved parties, set timeframes, and the allocated Core measures (including methods, etc.). The documentation must be integrated into system administration and regularly updated for any progress, changes, or adjustments.
Compliance with the documentation requirement lies with system administration and is essential for ensuring the credibility and effectiveness of the Core Pact.
Mechanisms to Ensure Compliance with the Core Pact
Each Core Pact must include mechanisms for monitoring the fulfillment of the established promises. These may include automated checks, regular self-assessments, or other methods outlined in the rulebook.
Validity and Duration
A Core Pact only takes effect once all criteria mentioned above are met and an appropriate decision-making body has approved it. The duration of the Core Pact must be clearly defined and is linked to specific review mechanisms.
Consequences of Non-Compliance
Non-compliance with a Core Pact constitutes a serious breach of the rules and commitments defined in the Core System, provided that existing circumstances do not make compliance impossible. The author must then assume full responsibility for the breach of the Core Pact, acknowledge the failure, and initiate the necessary steps for correction.
Breach of the Pact Due to Existing Circumstances
Consequences for non-compliance are not applied under regular procedures if there is a particular change in circumstances that is unforeseeable, unavoidable, irresistible, and uncontrollable. In the event of a breach of the pact for this reason, a thorough analysis of the nature of the changed circumstances must be undertaken, so they can be considered in the future. Repeated occurrences of a breach due to the same causes stemming from these circumstances must be avoided by implementing avoidance tactics and preventative measures when forming the pact, derived from the insights gained from past incidents.
Admission and Acceptance of Responsibility
In the event of a breach of the Core Pact, the first essential step is to assume full responsibility for personal failure. This includes a clear and unconditional admission that the established promises and commitments were not met. This admission must be documented. Additionally, one is henceforth indebted to the aggrieved party and must provide restitution; relevant methods should be triggered or established. The restitution must match the scope of the promise made by the Core Pact.
Methodical Adjustment
Following the admission, a thorough analysis of the causes for the breach of the Core Pact must be conducted. Based on this analysis, suitable methods from the rulebook must be activated or newly established to ensure that a similar breach does not occur in the future.
Highest Consequence for Non-Compliance
The highest consequence that can be imposed for disregarding any rules related to the Core Pact is formal expulsion from the Core System.
§ Alignment with the Values of the Manifest
The values within the system are aligned with the planned Manifest of the Core System. The practical design, application, and interpretation of these values are carried out by the methods of System Jurisprudence and by the General Plan. The Manifest is intended to be personal in nature, contrasting with the rational, generally framed Core System, and is shaped by the ideologies of the author. Within the framework defined here, it is not restricted in any way.
SYSTEM ABOLISHMENT
§ Exit from the Core System
The author may exit the Core System under the following requirements:
Procedure
An exit from the Core System can only occur with a unanimous decision in three consecutive committee sessions.
Mental Competence
The individual’s mental state must remain unimpaired throughout this entire process to ensure a rational and conscious decision-making process.
§ Obligations Prior to Exit
Before leaving the Core System, certain obligations must be fulfilled.
System Maintenance
The Core System must be maintained until the point of exit to ensure its integrity and functionality.
Data Backup
All data produced by the Core System must be secured and preserved in a way that ensures durability over time.
Appendix
§ Footnotes
1 See the paragraph “Division for System Jurisprudence”
2 Refers to administrations
3 The logic behind the term “System Input” lies in its function as the entry point for new information and conditions into the system
4 The logic behind “System Output” is the final transformation of information processed in the system into concrete actions and tasks. It marks the interface at which planning coordinated by methods, fed by incoming data, is converted into concrete execution tasks