Confronta il testo

Trova la differenza tra due file di testo

Editor live

Comprimi invariate

Senza a capo

Layout

Livello di dettaglio

Evidenziazione sintassi

Diffchecker Desktop Il modo più sicuro per usare Diffchecker. Ottieni l'app Diffchecker Desktop: i tuoi diff non lasciano mai il tuo computer!Ottieni Desktop

2023-11-10 New Gen Atlas

Creato 3 anni faIl diff non scade mai

52 rimozioni

Linee
Totale
Rimosso

Caratteri
Totale
Rimosso

Per continuare a utilizzare questa funzione, aggiorna a Diffchecker Pro Visualizza prezzi

465 linee

60 aggiunte

Linee
Totale
Aggiunto

Caratteri
Totale
Aggiunto

Per continuare a utilizzare questa funzione, aggiorna a Diffchecker Pro Visualizza prezzi

472 linee

{

"A.0": {

"Name": "Atlas Preamble",

"Version": 1,

"Type": "Atlas Preamble",

"Components": {

"Content": null

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.0.0"

"links_to": {},

"linked_from": []

"A.0.0": {

"Name": "Atlas Preamble Navigation Hub",

"Version": 1,

"Type": "Navigation Hub",

"Components": {

"Content": "The Atlas contains all data covering all aspects of operating the NEWDAO ecosystem. Further navigation: The Governance Scope Hub contains rules for governance documents and actors. The Support Scope Child Document contains rules and data related to AI tools."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.0.0"

"links_to": {

"The Governance Scope Hub": "A.1.0.0",

"The Support Scope": "A.2"

"linked_from": []

"A.1": {

"Name": "The Governance Scope",

"Version": 1,

"Type": "Scope",

"Components": {

"Content": "The Governance Scope covers principles and rules related to the Governance Processes and balance of power of NEWDAO and the NEW Ecosystem. The Governance Scope must ensure that the resilient equilibrium of NEWDAO Governance remains protected against all potential direct and indirect threats."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.1.da",

"A.1.0",

"A.1.1",

"A.1.2",

"A.1.3",

"A.1.4"

"links_to": {},

"linked_from": []

"A.1.da": {

"Name": "The Governance Scope Danish Translation",

"Version": 1,

"Type": "Scope",

"Components": {

"Original Document Type": "Scope",

"Language": "Danish.",

"Translated Name": "Styringsscopet",

"Indhold": "Styringsscopet d\\u00e6kker over principper og regler relateret til styringsprocesserne og magtbalancen i NEWDAO og NEW \\u00d8kosystemet. Styringsscopet skal sikre at NEWDAO's Styring forbliver i stabil ligev\\u00e6gt, og forbliver beskyttet mod alle potentielle direkte og indirekte trusler."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.0": {

"Name": "Supporting Root",

"Version": 1,

"Type": "Supporting Root",

"Components": {},

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.1.0.0",

"A.1.0.1",

"A.1.0.2",

"A.1.0.3",

"A.1.0.4"

"links_to": {},

"linked_from": []

"A.1.0.0": {

"Name": "Governance Scope Navigation Hub",

"Version": 1,

"Type": "Navigation Hub",

"Components": {

"Content": "The Governance Scope contains rules and principles related to core NEWDAO governance processes and the actors, in particular Alignment Conservers, involved in core governance processes. Further Navigation: The Scope Improvement Child Document contains the rules and processes for improving the Governance Scope. The Spirit of the Atlas Child Document contains key principles related to the fundamental values and interpretation of the Atlas. The Atlas Documents Hub contains rules and specifications for the structure of the Atlas and the characteristics, properties and types of Atlas Documents."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {

"Scope Improvement": "A.1.1",

"Spirit of the Atlas": "A.1.2",

"Atlas Documents Hub": "A.1.3.0.0"

"linked_from": []

"A.1.0.1": {

"Name": "Original Context Data",

"Version": 1,

"Type": "Original Context Data",

"Components": {

"Content": "The intent of A.1 is to establish the foundational governance principles and structure to enable NEWDAO to fulfill its vision in a sustainable and resilient manner. It aims to balance adaptation with stability by locking in core values while allowing carefully managed evolution of operational details. The rules aim to prevent governance attacks, drift from principles, and other forms of misalignment or corruption."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.0.2": {

"Name": "Element Analysis Directory",

"Version": 1,

"Type": "Element Analysis Directory",

"Components": {

"List of Elements and their Element Analysis Documents": {

"Indirect Threat Element Analysis": "A.1.0.2.1"

}

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.1.0.2.1"

"links_to": {},

"linked_from": []

"A.1.0.2.1": {

"Name": "Indirect Threat Element Analysis",

"Version": 1,

"Type": "Element Analysis",

"Components": {

"Element": "Indirect Threat",

"Analysis": "Indirect Threats refer to subtle, slow-moving or slippery slope risks, including slippery slope misalignment. Small scale violations, or well-intentioned, accidental violations of the balance of power or adherence to the Spirit of the Atlas enables an environment where misalignment becomes increasingly tolerated and eventually the Atlas becomes mutable, opening for the possibility of completely overturning the balance of power and comitting power grabs or centralization of the ecosystem. The Governance Scope must explicitly address these risks in all of its processes and ensure there is no openings in the rules and processes of the Atlas Documents that are vulnerable to indirect threats in the very long term."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.0.3": {

"Name": "FacilitatorDAO Action Example Directory",

"Version": 1,

"Type": "FacilitatorDAO Action Example Directory",

"Components": {

"Directory overview": "This directory contains examples of hypothetical FacilitatorDAO actions in response to governance issues, to serve as a guide for future decision-making."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.1.0.3.1"

"links_to": {},

"linked_from": []

"A.1.0.3.1": {

"Name": "Misaligned Aligned Scope Proposal Action Example",

"Version": 1,

"Type": "FacilitatorDAO Action Example",

"Components": {

"Input": "An AVC submits an Aligned Scope Proposal that modifies an Atlas Document in the Governance Scope to enable a budget to be used for funding new technical innovatio>aan.",

"Output": "The FacilitatorDAO derecognizes the AVC for open misalignment by taking actions that contravene the overall, scope, purpose and boundary of the Governance Scope as specified in its Scope Document.",

"Label": "Aligned"

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.0.4": {

"Name": "FacilitatorDAO Action Precedent Directory",

"Version": 1,

"Type": "FacilitatorDAO Action Precedent Directory",

"Components": {

"Directory overview": "This directory will contain FacilitatorDAO Action Precedents related to A.1 . Currently it is empty"

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.1": {

"Name": "Scope Improvement",

"Version": 1,

"Type": "Article",

"Components": {

"Content": "This Article discusses the principles and processes for improving the Governance Scope's Atlas Documents. It emphasizes the role of Scope Advisors, Governance FacilitatorDAOs, and the Atlas Operational Platform. The Sections of this Article provide detailed insight into these roles and their responsibilities."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.1.1.1",

"A.1.1.2",

"A.1.1.3"

"links_to": {},

"linked_from": []

"A.1.1.1": {

"Name": "Role of Scope Advisors",

"Version": 1,

"Type": "Section",

"Components": {

"Content": "Improvements to the Governance Scope should be advised by expert Scope Advisors. They provide objective and factual input on Atlas Document improvements. They are selected through a governance poll, ensuring they meet specific criteria and avoid conflicts of interest. Their work output must be checked for alignment with the expected results."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.1.2": {

"Name": "Role of Governance FacilitatorDAOs",

"Version": 1,

"Type": "Section",

"Components": {

"Content": "Governance FacilitatorDAOs manage the Scope Advisors, from soliciting proposals to ensuring the produced work aligns with the Scope Artifact. They also have the authority to propose changes to the Scope Framework in response to ambiguous or challenging situations."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.1.3": {

"Name": "Atlas Operational Platform",

"Version": 1,

"Type": "Section",

"Components": {

"Content": "The Atlas Operational Platform is crucial for accessible participation in the Governance Scope. Part of the Scope Advisors must support its design and development. It should provide a comprehensive and user-friendly overview of all data and processes relevant to the Governance Scope, ensuring accessibility, transparency, and easy verification of processes and decisions."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.2": {

"Name": "Spirit of the Atlas",

"Version": 1,

"Type": "Article",

"Components": {

"Content": "The Spirit of the Atlas represents the foundational principles of NEWDAO Governance, enshrined in the Immutable Documents and reflected in Atlas Documents and aligned participants of the NEW Ecosystem."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.1.2.1",

"A.1.2.2"

"links_to": {},

"linked_from": []

"A.1.2.1": {

"Name": "Universal Alignment and the Spirit of the Atlas",

"Version": 1,

"Type": "Section",

"Components": {

"Content": "The Spirit of the Atlas are the foundational principles that steer the NEWDAO Governance process. The Spirit of the Atlas are grounded concepts that enables coordination in the NEW Ecosystem around a resilient governance equilibrium that optimizes for Universal Alignment between the NEW Ecosystem and its surrounding environment. The grounded concepts of the Spirit of the Atlas provide specific boundaries for distinguishing Universal Alignment and misalignment when operating in the NEW Ecosystem context. The Immutable Documents of the Atlas are the bedrock for determining Universal Alignment of the NEW Ecosystem's rules and incentives, and hold precedence over any other conflicting rules or decisions. In situations where the Immutable Documents cannot be directly interpreted, the Spirit of the Atlas should be inferred in a way that maximizes Universal Alignment and mitigates risks of slippery slope misalignment. Achieving this necessitates a comprehensive understanding of Universal Alignment and the logic of how it is grounded in the Spirit of the Atlas within NEWDAO, and this Section must specify the processes to ensure the right research and documentation efforts occur to proactively protect the Spirit of the Atlas in the NEW Ecosystem."

"Last_Modified": "2023-08-16-19:07:00",

"Last_Modified": "2023-11-09-00:00:00",

"Child_Documents": [],

"Child_Documents": [

"A.1.2.1.0"

"links_to": {},

"linked_from": []

"A.1.2.1.0":

{

Text moved from lines 450-452

"Name": "Supporting Root",

"Version": 1,

"Type": "Supporting Root",

"Last_Modified": "2023-11-09-00:00:00",

"Child_Documents":

[

"A.1.2.1.0.2"

"links_to":

{},

"linked_from":

[]

"A.1.2.1.0.2":

{

"Name": "Element Analysis Directory",

"Version": 1,

"Type": "Element Analysis Directory",

"Components":

{

"List of Elements and their Element Analysis Documents":

{

"Operating Element Analysis": "A.1.2.1.0.2.1"

}

"Last_Modified": "2023-11-09-00:00:00",

"Child_Documents":

[

"A.1.2.1.0.2.1"

"links_to":

{},

"linked_from":

[]

"A.1.2.1.0.2.1":

{

"Name": "Operating the atlas",

"Version": 1,

"Type": "Element Analysis",

"Components":

{

"Element": "Operating",

"Analysis": "To effectively analyze operating in this context, it's crucial to first identify the stakeholders involved. Once identified, their actual engagement when operating should be examined. In the context of the NEW Ecosystem, the stakeholders significant for this analysis are those whose actions can be considered aligned or misaligned in the context of the Atlas. The impact of this alignment or misalignment can be either positive or negative for these stakeholders. The key stakeholders in this scenario include the ACs (Aligned Voter Committee Members, Aligned Delegates, Facilitators, and Budget Allocators), the Ecosystem Actors (Scope Advisors and Active Ecosystem Actors), and the SubDAOs.\nThe subsequent step involves pinpointing specific actions or instances of inactivity that qualify as operational activities. These may encompass participation in governance, contributions of work (whether paid or unpaid) as long as it is covered by the Atlas directly or indirectly, or any other forms of engagement that aim to influence the equilibrium established by the Atlas"

"Last_Modified": "2023-11-09-00:00:00",

"Child_Documents":

[],

"links_to":

{},

"linked_from":

[]

"A.1.2.2": {

"Name": "Interpretation of the Spirit of the Atlas",

"Version": 1,

"Type": "Section",

"Components": {

"Content": "When the Immutable Documents do not contain explicit instructions about a particular topic, the Spirit of the Atlas should be extrapolated based on the best available knowledge and research into Universal Alignment. Resolution of Atlas Document ambiguity or contradictions must be fully congruent with the Spirit of the Atlas and prior precedent, and must be resolved in a way that also clearly sets new precedent to prevent future similar ambiguous situations from occurring. This Section must cover the processes needed to operationalize the capability to research and describe the Spirit of the Atlas, the establishment of Spirit of the Atlas interpretations and precedent, and its application to Adaptive Documents. FacilitatorDAOs must have a process for directly applying Spirit of the Atlas interpretations in cases of less ambiguity and impact. In situations where there are high levels of ambiguity about how to extraprolate the Spirit of the Atlas to the new data, a NEWDAO governance vote is needed to establish the precedent"

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.3": {

"Name": "Atlas Documents",

"Version": 1,

"Type": "Article",

"Components": {

"Content": "Atlas Documents are integral to NEWDAO\\u2019s structure and governance. They are organized into document trees, starting with Immutable Documents, containing the Spirit of the Atlas, and Adaptive Documents for operationalization and evolution. The Sections of this Article provide detailed insight into the properties, evolution, and processes related to Atlas Documents."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.1.3.1",

"A.1.3.2",

"A.1.3.3",

"A.1.3.4",

"A.1.3.5"

"links_to": {},

"linked_from": []

"A.1.3.0": {

"Name": "Supporting Root",

"Version": 1,

"Type": "Supporting Root",

"Components": {},

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.1.3.0.0"

"links_to": {},

"linked_from": []

"A.1.3.0.0": {

"Name": "Atlas Documents Navigation Hub",

"Version": 1,

"Type": "Navigation Hub",

"Components": {

"Content": "The Atlas Documents Document contains all of the rules and specifications related to Atlas Documents. Further navigation: Definition and Properties of Atlas Documents Child Document contains core structural rules of Atlas Document contents and identifiers. Recursive Governance Improvement of Adaptive Documents Child Document is a stub that covers how Atlas Documents interact with NEWDAO Governance. Structure, categories and types of Atlas Documents Hub contains the rules and specifications for different types and categories of Atlas Documents."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {

"Definition and Properties of Atlas Documents": "A.1.3.1",

"Recursive Governance Improvement of Adaptive Documents": "A.1.3.2",

"Structure, categories and types of Atlas Documents Hub": "A.1.3.3.0.0"

"linked_from": []

"A.1.3.1": {

"Name": "Definition and Properties of Atlas Documents",

"Version": 1,

"Type": "Section",

"Components": {

"Content": "Atlas Documents are the basic building blocks for structuring data in the Atlas. They are organized as nested document trees, each with a unique Document Identifier. The first three layers contain the Immutable Documents, which together enshrine the Spirit of the Atlas and the core, permanent boundaries for how to operationalize it without risking slippery slope misalignment. In the layers below the Immutable Documents are the Adaptive Documents, which are continuously improved through the NEWDAO governnace process to interpret and practically operationalize the Spirit of the Atlas, within the boundaries of the Immutable Documents."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.1.3.1.1",

"A.1.3.1.2"

"links_to": {},

"linked_from": []

"A.1.3.1.1": {

"Name": "Document Identifiers",

"Version": 1,

"Type": "Core",

"Components": {

"Content": "All Atlas Documents are distinguishable through their unique Document Identifier. The Document Identifier is the technical name of the Atlas Document, and it determines its position in the Document Tree of the Atlas. All Document Identifiers begin with a capital A, and the numbers and letters of the Document Identifiers are separated with dots, with each dot signifying that the Atlas Document is one layer deeper in the tree structure. The Document Identifiers help determine the position of each Atlas Document, and makes it easier to estimate the relationship between two different Atlas Documents."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.3.1.2": {

"Name": "Atlas Document Properties",

"Version": 1,

"Type": "Core",

"Components": {

"Content": "All Atlas Documents have 5 standard properties that provide key information about them. The subdocuments of A.1.3.2 specify the characteristics of each of the 5 standard properties.\nThe standard properties of Atlas Documents should be listed in the following order:\n1. Name\n2. Version\n3. Last Modified\n4. Type\n5. Components"

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.1.3.1.2.1",

"A.1.3.1.2.2",

"A.1.3.1.2.3",

"A.1.3.1.2.4",

"A.1.3.1.2.5"

"links_to": {},

"linked_from": []

"A.1.3.1.2.1": {

"Name": "Name Property",

"Version": 1,

"Type": "Core",

"Components": {

"Content": "The Name property is used to provide each Atlas Document a human-readable name, to make it more easily distinguishable by humans, and to give a very rough overview of its purpose and function. The actual names of Atlas Documents for data-keeping purposes are their Document Identifiers, as a result it is possible to modify the name property with no consequences."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.3.1.2.2": {

"Name": "Version Property",

"Version": 1,

"Type": "Core",

"Components": {

"Content": "The version property of Atlas Documents specifies how many times it has been modified. Every time an Atlas Document is modified, the newly modified Document gets its version number incremented, and the old version is recorded as a historical version with a Document Identifier equivalent to its version number. As an example, if an Atlas Document located 1.1.1 with version number 3 is modified, the new Atlas Document will have version number 4, and the old Atlas Document will be located at 1.1.1.v3. This means all historical versions of Atlas Documents are kept permanently as a part of the Atlas, to ensure the data isn't lost over time."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.3.1.2.3": {

"Name": "Last Modified Property",

"Version": 1,

"Type": "Core",

"Components": {

"Content": "The 'Last Modified' property specifies the exact date and time when the Atlas Document was updated to its current version. It is recorded in the UTC timezone and follows the format 'YYYY-MM-DD-HH:MM:SS'. This property provides a timestamp for tracking modifications and ensuring transparency in the governance and update process. When an Atlas Document is at version 1, then Last Modified property denotes when the Atlas Document was created."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.3.1.2.4": {

"Name": "Type Property",

"Version": 1,

"Type": "Core",

"Components": {

"Content": "The Type Property of Atlas Documents specifies the function, characteristic and purpose of the Atlas Document. The Type determines the data that must be contained in the Components Property. The various Document Types and their characteristics are specified in *A.1.3.3*."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.3.1.2.5": {

"Name": "Components Property",

"Version": 1,

"Type": "Core",

"Components": {

"Content": "The Components Property of Atlas Documents contains an object that specifies the data components of the Atlas Document as nested properties. The Components of an Atlas Document is determined by its Type. Some Document Types have no Components, in which the object is just empty. An Atlas Document with Components must always have all of its components properly filled according to the requirements defined by its Type Specification. Some documents have custom logic for how their Components behave, and this custom logic is specified through a special reserved component property called 'custom'. Atlas Documents of Types with specified custom logic components can have variable number of components, and different characteristics of each component, for each instance of the Type. Custom components are always appended to the end of the list of components."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.3.2": {

"Name": "Recursive governance improvement of Adaptive Documents",

"Version": 1,

"Type": "Section",

"Components": {

"Content": "Adaptive Documents are updated quarterly through the AVC process, based on Aligned Scope Proposals produced by AVCs. These updates must always be aligned with the principles and boundaries of the Immutable Documents, and must aim to objectively improve the quality of the Adaptive Documents over time to ensure the NEW Ecosystem always trends towards greater Universal Alignment, lower inner incentive requirements of its participants, greater efficiency, greater resilience and sustainable growth."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [],

"links_to": {},

"linked_from": []

"A.1.3.3": {

"Name": "Structure, categories and types of Atlas Documents",

"Version": 1,

"Type": "Section",

"Components": {

"Content": "This Section must provide clear specifications of the basic structure of Atlas Documents, their general categores and individual types, their syntax and content requirements, and their functions and composability in the Atlas."

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.1.3.3.1",

"A.1.3.3.2"

"links_to": {},

"linked_from": []

"A.1.3.3.0": {

Text moved to lines 263-265

"Name": "Supporting Root",

"Version": 1,

"Type": "Supporting Root",

"Components": {},

"Last_Modified": "2023-08-16-19:07:00",

"Child_Documents": [

"A.1.3.3.0.0"

"links_to": {},

"linked_from": []

"A.1.3.3.0.0": {

"Name": "Structure, categories and types of Atlas Documents Navigation Hub",

"Version": 1,

"Type": "Navigation Hub",

Diff salvati

Testo originale

Apri file

{
    "A.0": {
        "Name": "Atlas Preamble",
        "Version": 1,
        "Type": "Atlas Preamble",
        "Components": {
            "Content": null
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.0.0"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.0.0": {
        "Name": "Atlas Preamble Navigation Hub",
        "Version": 1,
        "Type": "Navigation Hub",
        "Components": {
            "Content": "The Atlas contains all data covering all aspects of operating the NEWDAO ecosystem. Further navigation: The Governance Scope Hub contains rules for governance documents and actors. The Support Scope Child Document contains rules and data related to AI tools."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.0.0"
        ],
        "links_to": {
            "The Governance Scope Hub": "A.1.0.0",
            "The Support Scope": "A.2"
        },
        "linked_from": []
    },
    "A.1": {
        "Name": "The Governance Scope",
        "Version": 1,
        "Type": "Scope",
        "Components": {
            "Content": "The Governance Scope covers principles and rules related to the Governance Processes and balance of power of NEWDAO and the NEW Ecosystem. The Governance Scope must ensure that the resilient equilibrium of NEWDAO Governance remains protected against all potential direct and indirect threats."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.da",
            "A.1.0",
            "A.1.1",
            "A.1.2",
            "A.1.3",
            "A.1.4"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.da": {
        "Name": "The Governance Scope Danish Translation",
        "Version": 1,
        "Type": "Scope",
        "Components": {
            "Original Document Type": "Scope",
            "Language": "Danish.",
            "Translated Name": "Styringsscopet",
            "Indhold": "Styringsscopet d\\u00e6kker over principper og regler relateret til styringsprocesserne og magtbalancen i NEWDAO og NEW \\u00d8kosystemet. Styringsscopet skal sikre at NEWDAO's Styring forbliver i stabil ligev\\u00e6gt, og forbliver beskyttet mod alle potentielle direkte og indirekte trusler."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.0.0",
            "A.1.0.1",
            "A.1.0.2",
            "A.1.0.3",
            "A.1.0.4"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0.0": {
        "Name": "Governance Scope Navigation Hub",
        "Version": 1,
        "Type": "Navigation Hub",
        "Components": {
            "Content": "The Governance Scope contains rules and principles related to core NEWDAO governance processes and the actors, in particular Alignment Conservers, involved in core governance processes. Further Navigation: The Scope Improvement Child Document contains the rules and processes for improving the Governance Scope. The Spirit of the Atlas Child Document contains key principles related to the fundamental values and interpretation of the Atlas. The Atlas Documents Hub contains rules and specifications for the structure of the Atlas and the characteristics, properties and types of Atlas Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {
            "Scope Improvement": "A.1.1",
            "Spirit of the Atlas": "A.1.2",
            "Atlas Documents Hub": "A.1.3.0.0"
        },
        "linked_from": []
    },
    "A.1.0.1": {
        "Name": "Original Context Data",
        "Version": 1,
        "Type": "Original Context Data",
        "Components": {
            "Content": "The intent of A.1 is to establish the foundational governance principles and structure to enable NEWDAO to fulfill its vision in a sustainable and resilient manner. It aims to balance adaptation with stability by locking in core values while allowing carefully managed evolution of operational details. The rules aim to prevent governance attacks, drift from principles, and other forms of misalignment or corruption."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0.2": {
        "Name": "Element Analysis Directory",
        "Version": 1,
        "Type": "Element Analysis Directory",
        "Components": {
            "List of Elements and their Element Analysis Documents": {
                "Indirect Threat Element Analysis": "A.1.0.2.1"
            }
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.0.2.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0.2.1": {
        "Name": "Indirect Threat Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "Indirect Threat",
            "Analysis": "Indirect Threats refer to subtle, slow-moving or slippery slope risks, including slippery slope misalignment. Small scale violations, or well-intentioned, accidental violations of the balance of power or adherence to the Spirit of the Atlas enables an environment where misalignment becomes increasingly tolerated and eventually the Atlas becomes mutable, opening for the possibility of completely overturning the balance of power and comitting power grabs or centralization of the ecosystem. The Governance Scope must explicitly address these risks in all of its processes and ensure there is no openings in the rules and processes of the Atlas Documents that are vulnerable to indirect threats in the very long term."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0.3": {
        "Name": "FacilitatorDAO Action Example Directory",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example Directory",
        "Components": {
            "Directory overview": "This directory contains examples of hypothetical FacilitatorDAO actions in response to governance issues, to serve as a guide for future decision-making."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.0.3.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0.3.1": {
        "Name": "Misaligned Aligned Scope Proposal Action Example",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example",
        "Components": {
            "Input": "An AVC submits an Aligned Scope Proposal that modifies an Atlas Document in the Governance Scope to enable a budget to be used for funding new technical innovatio>aan.",
            "Output": "The FacilitatorDAO derecognizes the AVC for open misalignment by taking actions that contravene the overall, scope, purpose and boundary of the Governance Scope as specified in its Scope Document.",
            "Label": "Aligned"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0.4": {
        "Name": "FacilitatorDAO Action Precedent Directory",
        "Version": 1,
        "Type": "FacilitatorDAO Action Precedent Directory",
        "Components": {
            "Directory overview": "This directory will contain FacilitatorDAO Action Precedents related to A.1 . Currently it is empty"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.1": {
        "Name": "Scope Improvement",
        "Version": 1,
        "Type": "Article",
        "Components": {
            "Content": "This Article discusses the principles and processes for improving the Governance Scope's Atlas Documents. It emphasizes the role of Scope Advisors, Governance FacilitatorDAOs, and the Atlas Operational Platform. The Sections of this Article provide detailed insight into these roles and their responsibilities."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.1.1",
            "A.1.1.2",
            "A.1.1.3"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.1.1": {
        "Name": "Role of Scope Advisors",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Improvements to the Governance Scope should be advised by expert Scope Advisors. They provide objective and factual input on Atlas Document improvements. They are selected through a governance poll, ensuring they meet specific criteria and avoid conflicts of interest. Their work output must be checked for alignment with the expected results."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.1.2": {
        "Name": "Role of Governance FacilitatorDAOs",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Governance FacilitatorDAOs manage the Scope Advisors, from soliciting proposals to ensuring the produced work aligns with the Scope Artifact. They also have the authority to propose changes to the Scope Framework in response to ambiguous or challenging situations."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.1.3": {
        "Name": "Atlas Operational Platform",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "The Atlas Operational Platform is crucial for accessible participation in the Governance Scope. Part of the Scope Advisors must support its design and development. It should provide a comprehensive and user-friendly overview of all data and processes relevant to the Governance Scope, ensuring accessibility, transparency, and easy verification of processes and decisions."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.2": {
        "Name": "Spirit of the Atlas",
        "Version": 1,
        "Type": "Article",
        "Components": {
            "Content": "The Spirit of the Atlas represents the foundational principles of NEWDAO Governance, enshrined in the Immutable Documents and reflected in Atlas Documents and aligned participants of the NEW Ecosystem."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.2.1",
            "A.1.2.2"
        ],
        "links_to": {},
        "linked_from": []
    },
	"A.1.2.1": {
		"Name": "Universal Alignment and the Spirit of the Atlas",
		"Version": 1,
		"Type": "Section",
		"Components": {
			"Content": "The Spirit of the Atlas are the foundational principles that steer the NEWDAO Governance process. The Spirit of the Atlas are grounded concepts that enables coordination in the NEW Ecosystem around a resilient governance equilibrium that optimizes for Universal Alignment between the NEW Ecosystem and its surrounding environment. The grounded concepts of the Spirit of the Atlas provide specific boundaries for distinguishing Universal Alignment and misalignment when operating in the NEW Ecosystem context. The Immutable Documents of the Atlas are the bedrock for determining Universal Alignment of the NEW Ecosystem's rules and incentives, and hold precedence over any other conflicting rules or decisions. In situations where the Immutable Documents cannot be directly interpreted, the Spirit of the Atlas should be inferred in a way that maximizes Universal Alignment and mitigates risks of slippery slope misalignment. Achieving this necessitates a comprehensive understanding of Universal Alignment and the logic of how it is grounded in the Spirit of the Atlas within NEWDAO, and this Section must specify the processes to ensure the right research and documentation efforts occur to proactively protect the Spirit of the Atlas in the NEW Ecosystem."
		},
		"Last_Modified": "2023-08-16-19:07:00",
		"Child_Documents": [],
		"links_to": {},
		"linked_from": []
	},
    "A.1.2.2": {
        "Name": "Interpretation of the Spirit of the Atlas",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "When the Immutable Documents do not contain explicit instructions about a particular topic, the Spirit of the Atlas should be extrapolated based on the best available knowledge and research into Universal Alignment. Resolution of Atlas Document ambiguity or contradictions must be fully congruent with the Spirit of the Atlas and prior precedent, and must be resolved in a way that also clearly sets new precedent to prevent future similar ambiguous situations from occurring. This Section must cover the processes needed to operationalize the capability to research and describe the Spirit of the Atlas, the establishment of Spirit of the Atlas interpretations and precedent, and its application to Adaptive Documents. FacilitatorDAOs must have a process for directly applying Spirit of the Atlas interpretations in cases of less ambiguity and impact. In situations where there are high levels of ambiguity about how to extraprolate the Spirit of the Atlas to the new data, a NEWDAO governance vote is needed to establish the precedent"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3": {
        "Name": "Atlas Documents",
        "Version": 1,
        "Type": "Article",
        "Components": {
            "Content": "Atlas Documents are integral to NEWDAO\\u2019s structure and governance. They are organized into document trees, starting with Immutable Documents, containing the Spirit of the Atlas, and Adaptive Documents for operationalization and evolution. The Sections of this Article provide detailed insight into the properties, evolution, and processes related to Atlas Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.1",
            "A.1.3.2",
            "A.1.3.3",
            "A.1.3.4",
            "A.1.3.5"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.0.0"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.0.0": {
        "Name": "Atlas Documents Navigation Hub",
        "Version": 1,
        "Type": "Navigation Hub",
        "Components": {
            "Content": "The Atlas Documents Document contains all of the rules and specifications related to Atlas Documents. Further navigation: Definition and Properties of Atlas Documents Child Document contains core structural rules of Atlas Document contents and identifiers. Recursive Governance Improvement of Adaptive Documents Child Document is a stub that covers how Atlas Documents interact with NEWDAO Governance. Structure, categories and types of Atlas Documents Hub contains the rules and specifications for different types and categories of Atlas Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {
            "Definition and Properties of Atlas Documents": "A.1.3.1",
            "Recursive Governance Improvement of Adaptive Documents": "A.1.3.2",
            "Structure, categories and types of Atlas Documents Hub": "A.1.3.3.0.0"
        },
        "linked_from": []
    },
    "A.1.3.1": {
        "Name": "Definition and Properties of Atlas Documents",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Atlas Documents are the basic building blocks for structuring data in the Atlas. They are organized as nested document trees, each with a unique Document Identifier. The first three layers contain the Immutable Documents, which together enshrine the Spirit of the Atlas and the core, permanent boundaries for how to operationalize it without risking slippery slope misalignment. In the layers below the Immutable Documents are the Adaptive Documents, which are continuously improved through the NEWDAO governnace process to interpret and practically operationalize the Spirit of the Atlas, within the boundaries of the Immutable Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.1.1",
            "A.1.3.1.2"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.1": {
        "Name": "Document Identifiers",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "All Atlas Documents are distinguishable through their unique Document Identifier. The Document Identifier is the technical name of the Atlas Document, and it determines its position in the Document Tree of the Atlas. All Document Identifiers begin with a capital A, and the numbers and letters of the Document Identifiers are separated with dots, with each dot signifying that the Atlas Document is one layer deeper in the tree structure. The Document Identifiers help determine the position of each Atlas Document, and makes it easier to estimate the relationship between two different Atlas Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.2": {
        "Name": "Atlas Document Properties",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "All Atlas Documents have 5 standard properties that provide key information about them. The subdocuments of A.1.3.2 specify the characteristics of each of the 5 standard properties.\nThe standard properties of Atlas Documents should be listed in the following order:\n1. Name\n2. Version\n3. Last Modified\n4. Type\n5. Components"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.1.2.1",
            "A.1.3.1.2.2",
            "A.1.3.1.2.3",
            "A.1.3.1.2.4",
            "A.1.3.1.2.5"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.2.1": {
        "Name": "Name Property",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The Name property is used to provide each Atlas Document a human-readable name, to make it more easily distinguishable by humans, and to give a very rough overview of its purpose and function. The actual names of Atlas Documents for data-keeping purposes are their Document Identifiers, as a result it is possible to modify the name property with no consequences."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.2.2": {
        "Name": "Version Property",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The version property of Atlas Documents specifies how many times it has been modified. Every time an Atlas Document is modified, the newly modified Document gets its version number incremented, and the old version is recorded as a historical version with a Document Identifier equivalent to its version number. As an example, if an Atlas Document located 1.1.1 with version number 3 is modified, the new Atlas Document will have version number 4, and the old Atlas Document will be located at 1.1.1.v3. This means all historical versions of Atlas Documents are kept permanently as a part of the Atlas, to ensure the data isn't lost over time."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.2.3": {
        "Name": "Last Modified Property",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The 'Last Modified' property specifies the exact date and time when the Atlas Document was updated to its current version. It is recorded in the UTC timezone and follows the format 'YYYY-MM-DD-HH:MM:SS'. This property provides a timestamp for tracking modifications and ensuring transparency in the governance and update process. When an Atlas Document is at version 1, then Last Modified property denotes when the Atlas Document was created."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.2.4": {
        "Name": "Type Property",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The Type Property of Atlas Documents specifies the function, characteristic and purpose of the Atlas Document. The Type determines the data that must be contained in the Components Property. The various Document Types and their characteristics are specified in *A.1.3.3*."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.2.5": {
        "Name": "Components Property",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The Components Property of Atlas Documents contains an object that specifies the data components of the Atlas Document as nested properties. The Components of an Atlas Document is determined by its Type. Some Document Types have no Components, in which the object is just empty. An Atlas Document with Components must always have all of its components properly filled according to the requirements defined by its Type Specification. Some documents have custom logic for how their Components behave, and this custom logic is specified through a special reserved component property called 'custom'. Atlas Documents of Types with specified custom logic components can have variable number of components, and different characteristics of each component, for each instance of the Type. Custom components are always appended to the end of the list of components."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.2": {
        "Name": "Recursive governance improvement of Adaptive Documents",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Adaptive Documents are updated quarterly through the AVC process, based on Aligned Scope Proposals produced by AVCs. These updates must always be aligned with the principles and boundaries of the Immutable Documents, and must aim to objectively improve the quality of the Adaptive Documents over time to ensure the NEW Ecosystem always trends towards greater Universal Alignment, lower inner incentive requirements of its participants, greater efficiency, greater resilience and sustainable growth."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3": {
        "Name": "Structure, categories and types of Atlas Documents",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "This Section must provide clear specifications of the basic structure of Atlas Documents, their general categores and individual types, their syntax and content requirements, and their functions and composability in the Atlas."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.3.1",
            "A.1.3.3.2"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.3.0.0"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.0.0": {
        "Name": "Structure, categories and types of Atlas Documents Navigation Hub",
        "Version": 1,
        "Type": "Navigation Hub",
        "Components": {
            "Content": "The Structure, categories and types of Atlas Documents Document is the root of the document subtree that covers all rules about the unique characteristics and differentiating factors of Atlas Documents, in particular Document Types. Further navigation: Atlas Document Type Categories Child Document contains the overview of the high level classification of Atlas Documents Types. List of Document Types and their specifications Child Document contains all of the Document Types and their rules as Child Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {
            "Atlas Document Type Categories": "A.1.3.3.1",
            "List of Document Types and their specifications": "A.1.3.3.2"
        },
        "linked_from": []
    },
    "A.1.3.3.1": {
        "Name": "Atlas Document Type Categories",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The Atlas Document Types can be broadly categorized into distinct groups that determine how they are modified and how they function in the Atlas. At the highest level there are the Immutable Documents and the Adaptive Documents. The Adaptive Documents are further subdivided into 3 distinct groups: Primary Documents, Supporting Documents, and Accessory Documents. The category of an Atlas Document can be inferred from its Document Identifier, as each group have unique and non-overlapping rules for validity of their Document Identifiers."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.3.1.1",
            "A.1.3.3.1.2",
            "A.1.3.3.1.3",
            "A.1.3.3.1.4"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.1.1": {
        "Name": "Immutable Document category",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "Immutable Documents are the most important part the Atlas, as they record the Spirit of the Atlas, detailing the vision, purpose and unalienable principles of NEWDAO. They are fully immutable and can never be changed once the Sagittarius Lockstake Engine has been deployed. Any attempt to change or circumvent the Spirit of the Atlas as specified in the Immutable Documents is severe misalignment. Immutable Documents have Document identifiers that are at most 3 layers deep in the Document Tree."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.1.2": {
        "Name": "Primary Document category",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "Primary Documents are the cornerstone of the Adaptive Documents and the practical operationalization and resilience of the Atlas. They detail specific, practical principles, rules, processes and roles necessary to operationalize the Spirit of the Atlas. Primary Documents are modified through AVC process only, and generally must be modified as slowly as possible, and as little as possible while remaining fully adapted to the external environment. Every modification of a Primary Document should aim to future-proof against the need for future modifications. The exception to this, is when Primary Documents are modified to adapt to changing external conditions, as it is important they stay up to date and are fully adapted in their ability to protect the Spirit of the Atlas against threats from a changing environment. Primary Documents have Document Identifiers that are 4 layers or deeper in the Document Tree, and cannot contain 0's."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.1.3": {
        "Name": "Supporting Document category",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "Supporting Documents are attached to Immutable Documents and Primary Documents (called their Target Document). They provide context and in some cases advanced functionality to the Target Documents, enabling them to be fully operationally effective and unambiguous. The different Types of Supporting Documents have different functions, and some of them are required for all Immutable Documents and Primary Documents, while others are only required for certain Primary Document Types. Some Supporting Documents can only be modified through the AVC process, while others have active data components that can be modified in real time by processes specified in the Atlas, either in the Target Document or elsewhere in the Atlas, depending on the Supporting Document. Supporting Documents always have Document Identifiers that contain at least one 0."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.1.4": {
        "Name": "Accessory Document category",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "Accessory Documents provide accessory data to every other Atlas Document type. There are two types of Accessory Documents; Translation Documents and Archive Documents. Translation Documents can be edited directly by FacilitatorDAOs, while Archive Documents are immutable. Accessory Documents always have Document Identifiers that contain letters in addition to the standard 'A' prefix of all Atlas Document Identifiers."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2": {
        "Name": "List of Document Types and their specifications",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The subdocuments of this Core Document are Type Specification Documents that contain specifications of each of the Atlas Document Types, specifying their standardized characteristics and requirements which must be followed by all Atlas Documents to be valid and aligned."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.3.2.1",
            "A.1.3.3.2.10",
            "A.1.3.3.2.11",
            "A.1.3.3.2.12",
            "A.1.3.3.2.13",
            "A.1.3.3.2.14",
            "A.1.3.3.2.15",
            "A.1.3.3.2.16",
            "A.1.3.3.2.17",
            "A.1.3.3.2.18",
            "A.1.3.3.2.19",
            "A.1.3.3.2.2",
            "A.1.3.3.2.20",
            "A.1.3.3.2.21",
            "A.1.3.3.2.22",
            "A.1.3.3.2.23",
            "A.1.3.3.2.24",
            "A.1.3.3.2.25",
            "A.1.3.3.2.3",
            "A.1.3.3.2.4",
            "A.1.3.3.2.5",
            "A.1.3.3.2.6",
            "A.1.3.3.2.7",
            "A.1.3.3.2.8",
            "A.1.3.3.2.9"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.1": {
        "Name": "The Type Specification Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Type Specification",
            "Type Overview": "The Type Specification Type is used for Type Specification Documents that specify the characteristics of each of the different Document Types. It ensures that all Type Specifications contain all necessary information to make it easy to reason about whether a document follows the requirements for its type.",
            "Type Components": {
                "Type Name": "The Type Name Component must contain the name of the Document Type",
                "Type Overview": "The Type Overview Component must contain high level information as human-readable text about the type, such as what it is used for and why it is necessary.",
                "Type Components": "If the Type has Components, they must be specified in this Component as a nested object.",
                "Type Category": "This Component must specify whether the Type is an Immutable Document, a Primary Document, a Supporting Document, or a Translation Document.",
                "Document Identifier Rules": "This Component must specify as human-readable text rules related to the Document Identifier for Atlas Documents of this Type, and their locations in the Document Trees.",
                "Type Authority": "This Component must specify, as a number from 0 to 1, the authority of Documents of this type, in order to assist in resolving contradictions between Documents of different types.",
                "Additional Logic": "This Component can contain additional logic that applies to all Documents of the Type."
            },
            "Type Category": "Primary Document",
            "Document Identifier Rules": "Type Specification Documents must follow the Document Identifier rules for Primary Documents and be grouped together in the Governance Scope Article relevant to Document creation and data integration.",
            "Type Authority": 0.91,
            "Additional Logic": "The rules specified in Type Specification Documents must be followed for all Atlas Documents"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.10": {
        "Name": "The Element Analysis Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Element Analysis",
            "Type Overview": "Element Analysis Documents analyze and interpret individual elements in a Main Document, breaking down the meaning, implications, and applications of these elements to provide a clear and comprehensive understanding of the Main Document's content.",
            "Type Components": {
                "Element": "The Element Component should contain the unique word or phrase from the Target Document that is being analyzed.",
                "Analysis": "The Analysis Component should contain the interpretation, implications, and applications of the Element, providing a detailed understanding of its role and meaning in the Target Document in the broader context of the Spirit of the Atlas."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Element Analysis Documents must always be located as subdocuments to the Element Analysis Directory Document of their Target Document.",
            "Type Authority": 0.4,
            "Additional Logic": "Element Analysis Documents should be created to help in the understanding and interpretation of the Target Document. They should be updated as necessary to reflect changes in the understanding or interpretation of the Element, while maintaining consistency with the Target Document. The Element Analysis should not contradict its Target Document or other context data of the Target Document."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.11": {
        "Name": "The FacilitatorDAO Action Example Directory Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "FacilitatorDAO Action Example Directory",
            "Type Overview": "The FacilitatorDAO Action Example Directory Type is a directory Type used to list all of the FacilitatorDAO Action Example Documents that pertain to a Target Document. FacilitatorDAO Action Example Documents provide hypothetical examples of FacilitatorDAO Actions that provide context and clarity on the interpretation of the Target Document in a real situation.",
            "Type Components": {},
            "Type Category": "Supporting",
            "Document Identifier Rules": "FacilitatorDAO Action Example Directory Documents must always be located at the .0.3 position of their Target Document.",
            "Type Authority": "N/A",
            "Additional Logic": "N/A"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.12": {
        "Name": "The FacilitatorDAO Action Example Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "FacilitatorDAO Action Example",
            "Type Overview": "The FacilitatorDAO Action Example Type is used to provide hypothetical examples of FacilitatorDAO Actions, which serve as a guide for future FacilitatorDAO Actions and decision-making processes. It illustrates the application of principles and rules in practical scenarios, promoting understanding and consistency in governance actions.",
            "Type Components": {
                "Input": "The Input Component must contain a description of the situation or context in which the FacilitatorDAO Action takes place. This could include any relevant information, such as the state of governance or the specific issue at hand.",
                "Output": "The Output Component must contain a description of the FacilitatorDAO's action and the outcome or decision that resulted from it. This should provide a clear illustration of how the FacilitatorDAO responded to the situation.",
                "Label": "The Label Component indicates whether the FacilitatorDAO's action is considered aligned or misaligned according to the principles and rules of governance. This judgment is intended to guide future actions and decisions. If the label is misaligned, it must also specify the penalty that is applied to the FacilitatorDAO for misalignment."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "FacilitatorDAO Action Example Documents must always be located as subdocuments of the FacilitatorDAO Action Example Directory Document of their Target Document.",
            "Type Authority": 0.5,
            "Additional Logic": "FacilitatorDAO Action Example Documents should be created and updated as necessary to reflect changes in governance practices, provide clarity on decision-making processes, and enhance understanding of governance principles and rules. The examples should not contradict their Target Document or other Supporting Documents of the Target Document."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.13": {
        "Name": "The FacilitatorDAO Action Precedent Directory Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "FacilitatorDAO Action Precedent Directory",
            "Type Overview": "FacilitatorDAO Action Precedent Directory Documents list all of the FacilitatorDAO Action Precedent Documents that pertain to a Target Document. FacilitatorDAO Action Precedent Documents record data about FacilitatorDAO Actions, including ongoing actions, that are primarily based on interpretation of content of the Target Document.",
            "Type Components": {
                "Directory overview": "This Component should contain a brief explanation of overall patterns and themes of the FacilitatorDAO Action Precedents contained within."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "FacilitatorDAO Action Precedent Directory Documents must always be located at the .0.4 position below their Target Document.",
            "Type Authority": "N/A",
            "Additional Logic": "A FacilitatorDAO Action Precedent Directory Document must be updated whenever a new FacilitatorDAO Action Precedent Document is added that meaningfully changes what should be contained in the Directory overview Component."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.14": {
        "Name": "The FacilitatorDAO Action Precedent Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "FacilitatorDAO Action Precedent",
            "Type Overview": "The FacilitatorDAO Action Precedent Type is used to record all the relevant data related to a FacilitatorDAO Action, to serve as precedent for future FacilitatorDAO Actions and decision-making processes. It is also used for ongoing FacilitatorDAO Actions, and the creation of a FacilitatorDAO Action Precedent is the formal method that FacilitatorDAOs use to take action against misalignment, or explicitly approve ecosystem activity.",
            "Type Components": {
                "Input": "The Input Component must contain a description of the situation or context in which the FacilitatorDAO Action takes place. This could include any relevant information, such as the state of governance or the specific issue at hand.",
                "Output": "The Output Component must contain a description of the FacilitatorDAO's action and the outcome or decision that resulted from it. This should provide a clear illustration of how the FacilitatorDAO responded to the situation.",
                "Label": "The Label Component indicates whether the FacilitatorDAO's action is considered aligned or misaligned according to the principles and rules of governance. This judgment is intended to guide future actions and decisions. If the label is misaligned, it must also specify the penalty that is applied to the FacilitatorDAO for misalignment. The Label must always be marked as Aligned when it is created by the FacilitatorDAO, and further action by NEWDAO Governance can directly modify this later according to the specifications of the Atlas Documents relevant to appealing Facilitator Actions."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "FacilitatorDAO Action Precedent Documents must always be located as subdocuments of the FacilitatorDAO Action Precedent Directory Document of their Target Document.",
            "Type Authority": 0.5,
            "Additional Logic": "FacilitatorDAO Action Precedent Documents should be created and updated as necessary to reflect changes in governance practices, provide clarity on decision-making processes, and enhance understanding of governance principles and rules. The Precedents should not contradict their Target Document or other Supporting Documents of the Target Document."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.15": {
        "Name": "The Active Data Controller Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Active Data Controller",
            "Type Overview": "Active Data Controller Documents are Primary Documents that can have Active Data Documents attached to them as Supporting Documents, and contain variable state that can be directly modified by Facilitators and other processes external to the standard AVC process. Active Data can be lists of authorized actors, parameters, or externally collected data being prepared for data integration with the Atlas.",
            "Type Components": {
                "Content": "The Content Component of Active Data Controller Documents is used to describe flexible rules of how the Active Data Documents must behave, and how they can be modified. The Custom Components format and requirements of the Active Data Documents must be defined as well."
            },
            "Type Category": "Primary",
            "Document Identifier Rules": "Active Data Controller Documents follow the Document Identifier Rules of Primary Documents.",
            "Type Authority": 0.89,
            "Additional Logic": "Active Data Controller Documents must have an Active Data Directory Document located below it at the .0.5 position. The Active Data Controller Document can reference its Active Data subdocuments for its own logic. This allows Active Data Documents to be self-improving and adaptive at high speeds."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.16": {
        "Name": "The Active Data Directory Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Active Data Directory",
            "Type Overview": "The Active Data Directory Type is a directory Type used to list all of the Active Data Documents that pertain to an Active Data Controller Document. Active Data Documents contain variable state that can be directly modified by Facilitators and other processes external to the standard AVC process.",
            "Type Components": {
                "Directory overview": "This Component should contain a brief explanation of overall patterns and themes of the Active Data Documents contained within."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Active Data Directory Documents must always be located at the .0.5 position of their Active Data Controller Document or Budget Controller Document.",
            "Type Authority": "N/A",
            "Additional Logic": "An Active Data Directory Document should be updated whenever a new Active Data Document is added that meaningfully changes what should be contained in the Directory overview Component."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.17": {
        "Name": "Test Document",
        "Version": null,
        "Type": null,
        "Components": {},
        "Last_Modified": "2023-09-23",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.18": {
        "Name": "The Active Data Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Active Data",
            "Type Overview": "The Active Data Type is used for Supporting Documents that contain variable state that can be directly modified by Facilitators and other processes external to the standard AVC process. Active Data can be lists of authorized actors, parameters, or externally collected data being prepared for data integration with the Atlas.",
            "Type Components": {
                "Custom Components": "The Custom Components of Active Data Documents are defined by the Active Data Controller Document. They contain the variable state that can be directly modified."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Active Data Documents must always be located as subdocuments of the Active Data Directory Document of their Active Data Controller Document.",
            "Type Authority": 0.1,
            "Additional Logic": "Active Data Documents can contain arbitrary types of data, and can contain large amounts of data or code. The function and purpose of the contained data depends on the logic specified in the Active Data Controller Document. Active Data Documents can be modified directly through processes external to the Standard AVC process."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.19": {
        "Name": "The Budget Controller Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Budget Controller",
            "Type Overview": "The Budget Controller Type is used to manage the budgets used by NEWDAO to operationalize the Scopes to achieve the purpose and goals of the Spirit of the Atlas. It controls variable state that specifically authorizes executive votes to disburse payments from the NEWDAO Surplus Buffer, or authorize smart contracts to disbuse such payments. The Budget Controller Document determines the rules and processes for modifying and using the budgets contained in the Budget Documents that are attached to it. Budget Controllers also have Active Data Documents attached that are used to report on the status and results of projects funded through the Budget Documents.",
            "Type Components": {
                "Content": "The Content Component of Budget Controller Documents is used to describe flexible rules of how the Active Data Documents and Budget Documents must behave, and how they can be modified. The Custom Components format and requirements of the Active Data Documents and the Budget Documents must be defined as well."
            },
            "Type Category": "Primary",
            "Document Identifier Rules": "Budget Controller Documents follow the Document Identifier Rules of Primary Documents.",
            "Type Authority": 0.89,
            "Additional Logic": "Budget Controller Documents must have an Active Data Directory Document located below it at the .0.5 position, and a Budget Directory Document located below it at the .0.6 position."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.2": {
        "Name": "The Atlas Preamble Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Atlas Preamble",
            "Type Overview": "The Atlas Preamble Type is used for the Atlas Preamble Document Tree which starts at the 0th position of the first layer of the Atlas. The Atlas Preamble details the Spirit of the Atlas in human-readable language, and specifies important definitions for understanding the Spirit of the Atlas, that must be used as context when interpreting all other parts of the Atlas.",
            "Type Components": {
                "Content": "The content Component is very flexible and defines in broad human-readable language the Spirit of the Atlas."
            },
            "Type Category": "Immutable",
            "Document Identifier Rules": "Atlas Preamble Documents are located at A.0 or as nested Documents one layer below A.0.",
            "Type Authority": 1,
            "Additional Logic": "Atlas Preamble Documents are immutable, foundational parts of the Atlas and their content must be considered when interpreting all other Atlas Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.20": {
        "Name": "The Budget Directory Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Budget Directory",
            "Type Overview": "The Budget Directory Type is a directory Type used to list all of the Budget Documents that pertain to a Budget Controller Document.",
            "Type Components": {
                "Directory overview": "This Component should contain a brief explanation of overall patterns and themes of the Budget Documents contained within."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Budget Directory Documents must always be located at the .0.6 position of their Budget Controller Document.",
            "Type Authority": "N/A",
            "Additional Logic": "A Budget Directory Document should be updated whenever a new Budget Document is added that meaningfully changes what should be contained in the Directory overview Component."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.21": {
        "Name": "The Budget Document Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Budget",
            "Type Overview": "Budget Documents contain state that can authorize executive votes to disburse payments from the NEWDAO Surplus Buffer, or authorize smart contracts to disburse such payments.",
            "Type Components": {
                "Custom Components": "The Custom Components of Budget Documents are defined by the Budget Controller Document. They contain the variable state that can be directly modified."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Budget Documents must always be located as subdocuments of the Budget Directory Document of their Budget Controller Document.",
            "Type Authority": 0.2,
            "Additional Logic": "Budget Documents specify a budget rate expressed as NEW per unit of time. Additionally, they can contain large amounts of data, or code, and their function and purpose depends on their Budget Controller Document. Budget Documents can be modified directly through processes external to the Standard AVC process as specified by their Budget Controller Document."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.22": {
        "Name": "The Definition Directory Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Definition Directory",
            "Type Overview": "The Definition Directory Type is used for Target Documents with a lot of complex subdocuments, and acts as a directory for definitions of unique terms that are only referenced in its subdocuments.",
            "Type Components": {},
            "Type Category": "Supporting",
            "Document Identifier Rules": "Definition Directory Documents must always be located at the .0.0 position of their Target Document.",
            "Type Authority": "N/A",
            "Additional Logic": "Definition Directory Documents only need to be present in Atlas Documents that require definitions for unique terms in their Subdocuments."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.23": {
        "Name": "The Definition Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Definition",
            "Type Overview": "The Definition Type is used for documents that define unique concepts contained in Subdocuments to the Target Document of the Definition Document",
            "Type Components": {
                "Term": "The Term Component contains the name of the term that is being defined.",
                "Definition": "The Definition Component contains the detailed definition of the term."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Definition Documents must always be located as subdocuments of the Definition Directory Document of their Target Document.",
            "Type Authority": 0.1,
            "Additional Logic": "To the extent possible it should be avoided to have the same term defined multiple times in the Atlas, and instead always put a single defininition at a location in the Atlas that covers all of its use. The main exception to this principle should be when relatively niche terms are present in two different Scopes."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.24": {
        "Name": "The Translation Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Translation",
            "Type Overview": "The Translation Type is used for creating translated versions of Atlas Documents to make the Atlas accessible to non-English speakers. Translation Documents are Accessory Documents and they do not have any impact on the governance or operation of NEWDAO, but they are important for accessibility and inclusivity.",
            "Type Components": {
                "Original Document Type": "The Type of the original document that is being translated must be specified in this component.",
                "Language": "The Language Component specifies the language in which the Atlas Document is translated.",
                "Translated Name": "The Translated Name component contains the name of the translated Atlas Document in the new language.",
                "Custom": "Translation Documents contain Custom Components that mirror the components of the original Document with component name and component data translated to the new language."
            },
            "Type Category": "Accessory",
            "Document Identifier Rules": "Translation Documents are located as subdocuments to the Atlas Document they are translating. Their Document Identifier is the same as the Atlas Document they are translating, with an additional suffix that represents the language of the translation. For example, a Spanish translation of A.1 would have the Document Identifier A.1.es.",
            "Type Authority": "N/A",
            "Additional Logic": "Translation Documents should be updated whenever the Atlas Document they are translating is updated to ensure that the translation remains accurate. However, in case of any discrepancies or contradictions, the original English version of the Atlas Document always takes precedence."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.25": {
        "Name": "The Archive Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Archive",
            "Type Overview": "The Archive Type is used for storing historical versions of Atlas Documents. Archive Documents are Accessory Documents and they do not have any impact on the governance or operation of NEWDAO, but they are important for maintaining a record of changes and evolution of the Atlas over time.",
            "Type Components": {
                "Original Document Type": "The Type of the original document that is being archived must be specified in this component.",
                "Custom": "Archive Documents contain Custom Components that mirror the components of the original Document at the time of the version being archived."
            },
            "Type Category": "Accessory",
            "Document Identifier Rules": "Archive Documents are located as subdocuments to the Atlas Document they are archiving. Their Document Identifier is the same as the Atlas Document they are archiving, with an additional suffix 'v' followed by the version number of the document being archived. For example, the third version of A.1 would have the Document Identifier A.1.v3.",
            "Type Authority": "N/A",
            "Additional Logic": "Archive Documents should be created whenever an Atlas Document is updated to ensure that a record of all previous versions is maintained. They are not meant to be modified or deleted once created."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.26": {
        "Name": "The Navigation Hub Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Navigation Hub",
            "Type Overview": "The Navigation Hub Type is used for Navigation Hubs that provide summarized content and links to child documents or Focus Hubs that dive deeper or provide supporting data for a specific action. It acts as an entry point and guide for navigating the content of an Immutable or Primary Document.",
            "Type Components": {
                "Content": "The Content Component must contain summarized information and links to the child documents of the associated Immutable or Primary Document. It must also link to the nearest navigation hubs below its position if its Child Documents do not have Navigation Hubs. "
            },
            "Type Category": "Supporting Document",
            "Document Identifier Rules": "Navigation Hub Documents must be located at the .0.0 position of an Immutable or Primary Document.",
            "Type Authority": 0.89,
            "Additional Logic": "Navigation Hubs serve as a guide for users to understand and navigate the main content of the associated Immutable or Primary Document."
        },
        "Last_Modified": "2023-10-06",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.27": {
        "Name": "The Focus Hub Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Focus Hub",
            "Type Overview": "The Focus Hub Type is used for Focus Hubs that delve deeper into specific topics or sections from the Navigation Hub. It can be used to slice up a lot of child documents or a lot of hubs into independent groups, so only the relevant group needs to be read. It can also be used to provide relevant data for a specific type of action or workflow related to the Focus Hubs Immutable or Primary Document or its subtree.",
            "Type Components": {
                "Content": "The Content Component must contain detailed information about the specific topic or section from the Navigation Hub.",
                "links_to": "This Component can provide links to related documents or sections, with keys being the document names and values being their respective identifiers."
            },
            "Type Category": "Supporting Document",
            "Document Identifier Rules": "Focus Hub Documents must be located at the nonzero numerical positions below Navigation Hubs, e.g., x.0.0.1, x.0.0.2, etc.",
            "Type Authority": 0.88,
            "Additional Logic": "Focus Hubs serve as a detailed guide on specific topics, giving users an in-depth understanding of the subject matter."
        },
        "Last_Modified": "2023-10-06",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.3": {
        "Name": "The Scope Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Scope",
            "Type Overview": "The Scope Type is used for the 5 nonzero Immutable Documents of the first layer of the Atlas that directly describe focus areas, principles, rules and processes of NEWDAO Governance. Scope Documents define the broad boundaries, requirements and objectives of each of the 5 Atlas Scopes, so that they together can fully cover all activities that are needed for NEWDAO to function while maintaining its resilient equilibrium.",
            "Type Components": {
                "Content": "The content Component is very flexible and defines in broad human-readable language core principles, rules and processes."
            },
            "Type Category": "Immutable",
            "Document Identifier Rules": "Scope Documents have the Document Identifiers from A.1 to A.5.",
            "Type Authority": 0.99,
            "Additional Logic": "Scope Documents are immutable, foundational parts of the Atlas and their content must be considered when interpreting all principles, rules and processes of Atlas Documents nested below them"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.4": {
        "Name": "The Article Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Article",
            "Type Overview": "The Article Type is used for the second layer documents nested below the 5 Scope documents of the Atlas. They directly describe individual focus areas that together fully cover everything needed for the purpose of the Scope to be fulfilled.",
            "Type Components": {
                "Content": "The content Component is very flexible and defines in broad human-readable language core principles, rules and processes of the specific focus area of the Scope that the Article covers, and provides the starting point, requirements, boundaries, and in some cases immutable specifications, needed to develop the Adaptive Documents that are nested at lower layers of the Document Trees to maximally fulfill their practical purpose without violating the Spirit of the Atlas."
            },
            "Type Category": "Immutable",
            "Document Identifier Rules": "Article Documents have Document Identifiers one layer below the Scope Documents.",
            "Type Authority": 0.98,
            "Additional Logic": "Article Documents are immutable, foundational parts of the Atlas and their content must be considered when interpreting all principles, rules and processes of Atlas Documents nested below them"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.5": {
        "Name": "The Section Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Section",
            "Type Overview": "The Section Type is used for the third layer of Immutable Documents nested under the Articles of each Scope in the Atlas. They provide additional structure and specification to the principles, rules and processes within the focus area of the Article, and act as a foundation and boundary against misalignment of the Adaptive Documents that are nested below it.",
            "Type Components": {
                "Content": "The content Component is very flexible and provides in-depth human-readable language to elaborate on the specific principles, rules, and processes of the Article that the Section is nested under."
            },
            "Type Category": "Immutable",
            "Document Identifier Rules": "Section Documents have Document Identifiers one layer below the Article Documents.",
            "Type Authority": 0.97,
            "Additional Logic": "Section Documents are immutable parts of the Atlas and their content must be considered when interpreting all principles, rules and processes of Adaptive Documents nested below them"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.6": {
        "Name": "The Core Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Core",
            "Type Overview": "The Core Type is the basic building block of the Primary Documents. Core Documents flexibly specify the core principles, rules and processes required to fulfil the specifications made by the Immutable Documents with a focus on clarity, practicality and applicability.",
            "Type Components": {
                "Content": "The content Component is very flexible and defines in human-readable language core principles, rules or processes, or subcomponents thereof."
            },
            "Type Category": "Primary",
            "Document Identifier Rules": "Core Documents follow the Document Identifier Rules of Primary Documents, and can have whatever Document Identifier within those constraints that are useful for their purpose.",
            "Type Authority": 0.9,
            "Additional Logic": "To support the Resilient Equilibrium of NEWDAO Governance, Core Documents are meant to be as future-proofed as possible. A key principle is that when an Aligned Scope Proposal edits a Core Document, it must justify why the edit will reduce the need for future edits, and takes the Core Document closer to an effectively near-immutable end state where it is strong enough that it naturally covers all probable external events."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.7": {
        "Name": "The Supporting Root Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Supporting Root",
            "Type Overview": "The Supporting Root Type is used to mark the beginning of the Supporting Document subtree of an Immutable or Primary Document. All Immutable and Primary Documents must have a Supporting Root.",
            "Type Components": {},
            "Type Category": "Supporting",
            "Document Identifier Rules": "Supporting Root Documents must always be located at the .0 position of its Target Document.",
            "Type Authority": "N/A",
            "Additional Logic": "The Supporting Root Documents have no function other than structurally acting as a directory for nested Supporting Documents in a standardized format. All Immutable Documents and Primary Documents must have a Supporting Root Document attached."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.8": {
        "Name": "The Original Context Data Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Original Context Data",
            "Type Overview": "Original Context Data Documents explain the intention and reasoning behind the content of its Target Document, to make interpretation and extrapolation of its contents easier, and provide additional information to other forms of analysis. Original Context Data helps anchor the fundamental purpose and meaning of the target document to its original context, and should help mitigate cultural drift over time. Original Context Data can contain unstructured data used for genesis data integration of early Atlas Documents. Original Context Data Documents can form nested subtrees to organize their data if relevant.",
            "Type Components": {
                "Content": "The Content Component should contain all relevant information to understand the intention and reasoning behind the wording and elements of the main Document."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Original Context Data Documents must always be located at the .0.1 position of their Target Document, or nested in a subtree of Original Context Data Documents below the .0.1 position.",
            "Type Authority": 0.3,
            "Additional Logic": "The Original Context Data Document should be in a finished form alongside the creation or modification of its Target Document, as it aims to capture the original context and intention of the contents of the Target Document. However, it can and should be modified if new evidence and data comes to light that helps to better describe the original context and intention of the Target Document, or if new perspectives or new external events makes it possible and useful to modify the Original Context Data Document in a way that doesn\\u2019t contradict its earlier language."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.9": {
        "Name": "The Element Analysis Directory Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Element Analysis Directory",
            "Type Overview": "The Element Analysis Directory Type is a directory used to list all of the Element Analysis Documents pertaining to a Main Document.",
            "Type Components": {},
            "Type Category": "Supporting",
            "Document Identifier Rules": "Element Analysis Directory Documents must always be located at the .0.2 position of their Target Document.",
            "Type Authority": "N/A",
            "Additional Logic": "N/A"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.4": {
        "Name": "Conflict resolution",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "This Section must cover a process for appeals where an Atlas Document misalignment is perceived, and how the Governance Scope processes these appeals. They also detail how appeal outcomes are recorded and the rules for resolving Ecosystem Agreement appeals."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.4.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.4.1": {
        "Name": "Atlas Document appeals process",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "Atlas Document appeal proposals are submitted by AVC Members, and can be accepted or rejected by a majority of the Governance FacilitatorDAOs. If a Atlas Document appeal is accepted, the Governance FacilitatorDAOs must review it. Governance FacilitatorDAOs can also directly choose to review a Atlas Document for adherence with Scope boundaries and Atlas alignment."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.4.1.1",
            "A.1.3.4.1.2"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.4.1.1": {
        "Name": "FacilitatorDAO direct edits",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The Governance FacilitatorDAOs can by consensus directly edit a Atlas Document to align its content with the Scope boundaries and other Atlas requirements such as neutrality."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.4.1.2": {
        "Name": "Governance edits",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "A majority of the Governance FacilitatorDAOs can trigger an MKR governance poll to implement an edit to the appealed Atlas Document that will align it with the Scope boundaries and other Atlas requirements such as neutrality."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.5": {
        "Name": "Ossification of Adaptive Documents",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "This Section must cover the ossification of Adaptive Documents over time for greater stability, certainty, and predictability of protection against long-term slippery slope misalignment. This must be carefully applied only to Adaptive Documents that are safe to ossify to ensure it doesn't result in inflexibility or unintentional misalignment."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4": {
        "Name": "Alignment Conservers (ACs)",
        "Version": 1,
        "Type": "Article",
        "Components": {
            "Content": "Alignment Conservers (ACs) play a key role in safeguarding the NEWDAO Governance process by ensuring alignment with the Spirit of the Atlas and genuine actions that maintain Universal Alignment. The Sections of this Article detail the roles, requirements, and processes related to ACs."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.4.0",
            "A.1.4.1",
            "A.1.4.2",
            "A.1.4.3",
            "A.1.4.4",
            "A.1.4.5"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.0.2.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.0.2": {
        "Name": "Element Analysis Directory",
        "Version": 1,
        "Type": "Element Analysis Directory",
        "Components": {},
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.4.0.2.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.0.2.1": {
        "Name": "play a key role Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "play a key role",
            "Analysis": "To \"play a key role\" means that ACs have a significant, central, and crucial part in a safeguarding the governance processes of NEWDAO. They are responsible for the success of this task and must dedicate time and effort to towards this goal."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.0.3": {
        "Name": "FacilitatorDAO Action Example Directory",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example Directory",
        "Components": {
            "Directory overview": "This directory contains examples of hypothetical FacilitatorDAO actions in response to governance issues, to serve as a guide for future decision-making."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.0.3.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.0.3.1": {
        "Name": "",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example",
        "Components": {
            "Input": "",
            "Output": "",
            "Label": ""
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.1": {
        "Name": "Requirements and Responsibilities of Alignment Conservers",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "ACs are subject to strict requirements due to their critical role in safeguarding the resilience, and alignment of the NEW Ecosystem. They must always act to preserve the Spirit of the Atlas and to genuinely fight against all forms of corruption, organizational drift, and other misalignment threats. ACs may never collude or secretly organize to change the Immutable Documents, overturn or sidestep the Spirit of the Atlas, or take actions that are misaligned, or may disrupt the governance dynamic of NEWDAO, or through inaction allow any of the above to happen. ACs must operate only within the clearly delineated processes and frameworks of the Immutable Documents, and must be held to the highest standard when judging whether their actions are Universally Aligned."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.2": {
        "Name": "Roles of Alignment Conservers (ACs)",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "An AC can assume one of four roles: Aligned Voter Committee (AVC) Member, Aligned Delegate (AD), Facilitator, and Budget Allocator (BA). ACs may only be operationally active in a single AC role and may not simultaneously assume multiple AC roles or other ecosystem roles such as Ecosystem Actors. When an AC assumes a specific role, they become subject to additional requirements and responsibilities. Breaching these role-specific requirements and responsibilities is misalignment equivalent to breaching the general AC requirements."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
	"A.1.4.3": {
		"Name": "Derecognition of Alignment Conservers",
		"Version": 1,
		"Type": "Section",
		"Components": {
			"Content": "If an Alignment Conserver is discovered to act against the requirements outlined in this Article and its subdocuments, their Alignment Conserver status must immediately be derecognized by the FacilitatorDAOs. This Section must specify the processes for derecognition so that they are fair and minimize risk for the NEWDAO Ecosystem. Generally, ACs must be held to the highest standard of required, genuine alignment, without the benefit of the doubt. In cases of very mild 'slippery slope' breaches of the AC requirements or other forms of misalignment, a warning may be given and recorded in the subdocuments of the AC Article with no further consequence for the first breach. In severe cases that can be interpreted as Governance Attacks, in addition to being derecognized, the AC is also stripped of all reputation recognized in reputation systems of the Atlas."
		},
		"Last_Modified": "2023-08-16-19:07:00",
		"Child_Documents": [],
		"links_to": {},
		"linked_from": []
	},
    "A.1.4.4": {
        "Name": "Anonymity and Privacy of Alignment Conservers",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "ACs are encouraged to be anonymous. Some AC roles are required to be anonymous and maintain high levels of opsec, and their known identities must be derecognized from acting as ACs in general, in case they breach the requirement for maintaining high levels of opsec."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.5": {
        "Name": "Regulation of Alignment Conservers by FacilitatorDAOs",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "The FacilitatorDAOs must ensure the requirements and responsibilities of ACs are followed based on principles and processes specified in the subdocuments of this Article. FacilitatorDAOs must act decisively to derecognize ACs based on the conditions outlined in *A.1.4.3* and the rest of this Article, or general misalignment. Any FacilitatorDAO may do this directly, and is required to act swiftly to prevent the contagion risk of misalignment amongst ACs. Failure to act by a FacilitatorDAO in the face of misalignment risks is itself misalignment that triggers penalties for the FacilitatorDAOs that failed to act."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },

"A.1.5": {
        "Name": "Aligned Voter Committees (AVCs)",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC are standardized Voter Committees made up of Alignment Conservers that hold MKR and participate in the Maker Governance process as actors that are deeply aligned with MKR holders. They are subject to specific requirements, and receive various benefits, resources, and support from the Support Scope. They have significant formal powers, but no direct physical power, making them well-suited to be in control and making key decisions during normal conditions.\n AVCs focus on making sure that the day-to-day Letter of the Rules of the Atlas are aligned with the Spirit of the Atlas. The AVCs impact on Maker Governance is to make marginal improvements to the Adaptive Documents of the Atlas that strengthen them. As AVCs make detailed Universal Alignment interpretations, they must all follow a particular Strategic Perspective that informs their subjective definition of Universal Alignment."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },

"A.1.5.3": {
        "Name": "Aligned Voter Committee (AVC) Recognition Process and Active Status eligibility",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "New or inactive AVCs have the right to become recognized as Active AVCs by the Governance Scope if they fulfill the AVC eligibility requirements for participation and internal governance for at least one full quarterly governance cycle. If at any time after becoming recognized as an Active AVC, the AVC no longer completely fulfills all of the eligibility requirements, including all following all requirements specified in this Article, it immediately loses its recognition as an active AVC and all associated benefits. Before creating an AVC, an Alignment Conserver must verify as an unaffiliated Alignment Voter Committee Member through a process specified in this Section."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.4": {
        "Name": "Aligned Voter Committee (AVC) Active Status eligibility requirements and internal processess",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVCs must follow a standardized internal governance process for determining membership, creation of Aligned Governance Strategy, Aligned Scope Proposals and other decisions. This process is contained in the Aligned Voter Committee Active Data Section. \n AVC Members vote on AVC decisions based on their relative ownership of verified MKR. A vote takes one week and resolves with acceptance or rejection based on the amount of verified MKR that votes for each option, unless a simple majority is reached in which case the decision is accepted or rejected instantly.\n New AVC Members are included based on an application that is either accepted or rejected through an AVC decision. The effective verified MKR of members is specified in their application, and can only be increased or decreased through another application that must be accepted by another AVC decision. The effective verified MKR of the creator of an AVC is determined when they create the AVC. If an AVC Member’s blockchain account has MKR in excess of their effective verified MKR, they don’t gain additional voting power in the AVCs internal governance process, but it does count towards AVC rewards qualification. If an AVC member's blockchain account has less MKR than their verified amount, they are automatically removed from the AVC.\n Existing AVC Members can be removed through an AVC decision. \n A minority quorum of AVC Members based on verified MKR can trigger an AVC split. GOV5 must specify the minority quorum to ensure it serves its role well. All AVC Members then vote to support one of two new AVCs, with the naming rights and infrastructure inherited by the side with more MKR in support. The AVC Members of each of the two new AVCs is determined based on who voted to support each side. The Aligned Governance Strategy Links from AD are divided proportionally into two new Protocol Delegation Contract, each containing an amount of delegated MKR that is proportional to the MKR in support for each side of the AVC split. \n AVC Subcommittee Meetings must be scheduled through an AVC Decision."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.5": {
        "Name": "Aligned Voter Committee (AVC) Subcommittees and Aligned Scope Proposals",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "An AVC must, through an AVC decision, create a legitimate Aligned Scope Proposal for each of the 5 Scopes, each quarterly governance cycle. AVCs must also convene 2 scheduled AVC Subcommittee Meetings to discuss the creation of the Aligned Scope Proposals for each of the 5 Scopes, each quarterly cycle. The AVC Subcommittee Meetings must be held during the first ten whole weeks of each quarter, in the following order: \n Week 1: Governance Scope \n Week 2: Support Scope \n Week 3: Protocol Scope \n Week 4: Stability Scope \n Week 5: Accessibility Scope \n Week 6: Governance Scope \n Week 7: Support Scope \n Week 8: Protocol Scope \n Week 9: Stability Scope \n Week 10: Accessibility Scope"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.6": {
        "Name": "Aligned Voter Committee (AVC) Member conflict of interest management",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC must represent the interest of MKR holders, and cannot represent or be closely affiliated with an external entity. AVCs must always operate with awareness of members’ conflict of interest and take all reasonable steps to make sure that their alignment is preserved. This Section must specify ways to deal with this risk."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.7": {
        "Name": "Voter Expectations and Strategic Perspectives",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC must vote according to their strategic perspective. Clearly voting against the stated strategic perspective is misalignment and GOV5 must specify ways to detect and deal with this possibility. A key objective of AVCs is to act as reliable, aligned sources of opinions about which decisions are in MKR holders’ interest, given a particular strategic perspective of Maker Governance. This allows them to enfranchise MKR voters that are participating through the EGF to earn governance participation incentives. AVC must act with the understanding and alignment of this purpose, and this Section must specify principles and processes for detecting and reacting to risks, such as AVC attempts to misguide EGF users, or AVCs deprioritizing clarity and transparency."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.8": {
        "Name": "Aligned Voter Committee misalignment risk management",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC must limit their participation in Maker Governance to the creation of Aligned Governance Strategy and Aligned Scope Proposals that function resiliently based on open, objective processes and stay at a high enough level to ensure micromanagement isn't possible. AVCs must not attempt to create biased or unfair conditions for specific Ecosystem Actors, or attempt to put in place unjustified, granular decisions directly, or indirectly through biased processes. GOV5 must specify processes in which AVCs are deactivated and their members derecognized in case there is clear misalignment risk. Any attempt by AVC to micromanage governance significantly increases the risk of misalignment as there could easily be a hidden conflict of interest behind the attempt at micromanagement. This section must detail principles and processes for detecting and reacting to the edge case risks related to AVCs overstepping their roles in the governance process."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.9": {
        "Name": "Aligned Voter Committee infrastructure support",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC receive support and infrastructure from the Support Scope."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.10": {
        "Name": "AVC Member participation rewards",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC Members that participate in an AVC can be eligible for AVC Member participation reward that recognizes the time they are spending to support Maker Governance. \n The AVC Member participation compensation is paid out based on full participation within each scope every quarter. To qualify for the participation reward for a particular Scope the AVC Member must: \n 1) Have attended the two AVC Subcommittee Meetings and be co-author on the AVC Aligned Scope Proposals. \n 2) Be a co-author on the Aligned Governance Strategy. \n This Section must specify minimum standards of work and contribution based on best practice to prevent spam or inferior outlier AVC from qualifying for rewards. \n The yearly total AVC Member participation rewards is 10 million NewGovToken. This amount is broken into tranches of 500000 NewGovToken for each Scope per quarterly governance cycle, and shared across the reward slots for that Scope. \n The number of rewards slots for each tranche is equivalent to the total amount of PD and RD. \n The reward slots of a tranche are awarded to the AVC Members that have fulfilled the participation requirements for the tranche and have the highest verified MKR balances."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.11": {
        "Name": "Display of Aligned Voter Committees(AVCs) in Easy Governance Frontends(EGFs)",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC are shown on a ranked list on the landing page of the EGF, with name and AVC Profile displayed alongside their logo. The ranked list is determined based on the highest total voter weight of the AVCs. \n Total voter weight is calculated based on total undelegated or self-delegated, verified MKR holdings of members of the AVC plus total amount of MKR delegated to GSL to the AVC."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.6": {
        "Name": "Aligned Delegates(ADs)",
        "Version": 1,
        "Type": "Article",
        "Components": {
            "Content": "ADs are Alignment Conservers that have registered based on the processes specified in the Governance Scope Artifact. ADs operate GSLs, and receive various benefits while being subject to specific requirements in addition to the general Alignment Conserver requirements. ADs have significant physical power over the Maker Protocol as they control votes obtained from the Governance Participation Rewards. As a result their focus is to protect the Maker Ecosystem against abuse of this power by themselves or others, and to use the power to protect the Maker Ecosystem in case other parts of the Governance Process take misaligned actions. To avoid politicization of their power, ADs must not become involved in day to day marginal governance decisions or have their own strategic perspectives."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.6.1": {
        "Name": "Protocol Delegation Modules (PDMs)",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Protocol Delegation Modules are NewChain Modules that can be created and controlled by external smart contracts or accounts, and can receive delegated voting power from MKR holders and Sagittarius Engine users. \n PDM function with a season system begins on the monday of the 11th full week of the first quarter of the year, and ends on the friday of the 12th full week of the first quarter of the following year. The period where seasons overlap, from the monday of the 11th full week of the first quarter to the friday of the 12th full week of the first quarter in the same year, is called the Election Season. \n PDM are Seasonally Active from the moment they are created, until the Season they were created in ends. If they are created during the Election Season, then they count as being created in the later overlapping Season. PDMs expire and lose their voting power at the end of the second season of their existence, with a total lifetime of up to approximately 2 years and 2 weeks. \n Delegating to Seasonally Active PDM will qualify Sagittarius Engine users for Governance Participation Rewards throughout the entire Season, until the monday of the 12th full week of the first quarter of the year for PDMs of the earlier overlapping season."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.6.2": {
        "Name": "Governance Strategy Links (GSLs)",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "A PDM can be upgraded to an AD PDM through a user action. AD PDMs are split up into multiple delegation submodules, called GSL, that each can receive delegated votes separately. Each GSL specifies one AVC, and the AD is required to vote according to the Aligned Governance Strategy of the AVC, unless doing so would result in misaligned actions. \nGSL are Seasonally Active in the same way as normal PDM, and this determines whether the AD qualify for income. \nAn AD PDM also has a Neutral GSL, which is a special GSL that is not linked to any AVC, but that the AD must instead use to vote for a balanced strategy that achieves the mean of the positions of all AVCs and is Universally Aligned."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.6.3": {
        "Name": "Aligned Delegate (AD) Income and Participation Requirements",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "ADs are eligible to receive significant income from the Maker Protocol if they are among the top ADs based on total votes delegated to their Seasonally Active GSL, and they fulfill specific participation requirements. There are two income levels for ADs: Prime Delegates (PD) that receive the highest level of income and have a degree of income security, and Reserve Aligned Delegates (RD) that receive a lower level of income.\nThe Governance Scope Artifact specifies the number of PD slots, and the number of RD slots. There is always an equivalent amount of both. The number of slots must be increased over time if the income level of PDs and RDs increase above their baseline. The number of slots must be decreased over time if the income level of PDs and RDs decreases below their baseline. The baseline should generally increase over time if the number of PD and RD slots are increasing, ensuring that the internal operations of PDs and RDs also grows larger over time as the number of PDs and RDs increase.\nThe process for modifying the number of PD and RD slots must generally aim to have changes in the number of slots happen at the end of the Election Season, but in extraordinary circumstances, which must be specified by the Governance Scope, they can be done with 1 month warning.\nThe top qualified AD by total amount of MKR delegated to their Seasonally Active GSL at the end of the Election Season are the PD, with the amount of PDs corresponding to the number of PD slots. The next top qualified ADs by total amount of MKR delegated to their Seasonally Active GSLs are the RD, with the amount of RDs corresponding to the number of RD slots.\nThe Election Season is a period of time that begins on the Monday of the 11th full week of the first quarter of the year, and ends on the Friday of the 12th full week of the first quarter of the year. At the beginning of the election season, all AD can deploy new GSL that will be Seasonally Active for the coming season, and that Sagittarius Engine users can redelegate to in order to keep their Governance Participation Reward before it expires on the Monday of the 12th full week of the first quarter of the year.\nAt the end of the election season, the PD slots are determined directly based on the top ranking of the total amount of MKR delegated to the later Seasonally Active GSL of the AD.\nOutside of the Election Season, a PD can only lose their slot if an RD achieves twice as much total delegated MKR to their Seasonally Active GSL compared to the incumbent PD.\nThe available RD slots change in real time based on the top ranking of AD that aren’t PD by total amount of MKR delegated to their Seasonally Active GSL.\nThe AD Buffer is an account of MKR that builds up when an AD achieves an income rank of either PD or RD. The initial income that the AD earns accumulates in the AD buffer, until it contains 1 month's worth of income. At that point, the AD income starts paying out the to account that controls the AD-PDM.\nIf an AD loses all its income, or loses a part of its income by moving from PD to RD, the AD Buffer starts paying out the excess funds it contains so that it reaches 1 month's equivalent income after 1 month. In case the AD has no income, this means that all of the contents of the AD Buffer are paid out over the course of 1 month.\nThe AD Buffer is used as collateral for a whistleblower bounty in case the AD acts misaligned or has their privacy compromised.\nEach of the PD and RD slots earns up to an equal share of the total compensation available to their level each month, paid out continuously in real time. The income that gets paid out can be reduced if the AD don’t fully comply with participation requirements\nActual AD income payouts are modified based on the requirement to have a minimum amount of participation in AVC Subcommittee Meetings. PD must participate in at least 85% of the AVC Subcommittee Meetings hosted by AVCs whose strategies they follow each quarter to qualify for their full share of AD income. RD must participate in at least 50% of the AVC Subcommittee Meetings hosted by AVCs whose strategies they follow each quarter to qualify for their full share of AD income. If ADs participate in less than the minimum amount of AVC Subcommittee Meetings, accounted for on a monthly basis, they receive a proportionally reduced amount of the total AD income they are eligible for the following month. If ADs participate in all the AVC Subcommittee Meetings of a month, they always receive the full amount of their AD income. Participation in AVC Subcommittee Meetings that the ADs have a broken GSL with does not count towards participation for the purposes of calculating AD income.\nParticipation in a Subcommittee involves a reasonable and meaningful amount of contribution with useful research and information that must be specified in the Governance Scope.\nActual AD income payouts are also modified by voting activity metrics for the last 12 months, which includes overall voting activity in all of the votes that the ADs are able to vote on. If an AD is active in less than 95% of all votes over the last 6 months, they receive a reduced amount of AD income. The reduction in income is proportionally linear until it reaches 0 AD income at 75% voting activity. If an AD falls below 75% voting activity over the last 6 months, it loses qualification for AD income and any AD income rank they may be eligible for is passed on to the next highest AD by total amount of MKR delegated to their Seasonally Active GSL. A PD can lose their PD status this way, and even if their activity metric recovers they do not automatically become a PD again, except through the regular process of becoming a PD outside of the Election Season.\nActual AD income payouts are modified by AD communication metrics for the last 12 months, which requires the ADs to write an explanation for each vote that ties it to the Aligned Governance Strategy and their independent strategy, to help the MKR holders that delegated to them to understand the logic they use when executing the chosen Governance Strategies. If the AD actively communicates on less than 95% of all votes over the last 6 months, they receive a reduced amount of AD income. The reduction in income is proportionally linear until it reaches 0 AD income at 75% communication activity over the last 6 months. If an AD falls below 75% communication activity over the last 6 months, it loses qualification for AD income and any AD income rank they may be eligible for is passed on to the next highest AD by total amount of MKR delegated to their Seasonally Active GSL. A PD can lose their PD status this way, and even if their activity metric recovers they do not automatically become a PD again, except through the regular process of becoming a PD outside of the Election Season.\nThe PD slots share a total of 30 million NewGovToken per year amongst them.\nThe RD slots share a total of 10 million NewGovToken per year amongst them."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
     "A": {
        "Name": null,
        "Version": null,
        "Last_Modified": null,
        "Child_Documents": [
            "A.1",
            "A.2"
        ],
        "Type": null,
        "Components": null,
        "links_to": {},
        "linked_from": []
    },
    "A.2": {
        "Name": "The Support Scope",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [
            "A.2.4"
        ],
        "Type": "Scope",
        "Components": {
            "Description": "This document outlines the support scope within the NEWDAO governance."
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4": {
        "Name": "Governance AI Tools",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [
            "A.2.4.1"
        ],
        "Type": "Tools",
        "Components": {
            "Description": "This document discusses the AI tools used in governance."
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1": {
        "Name": "Governance AI Tools Implementation",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [
            "A.2.4.1.1"
        ],
        "Type": "Implementation",
        "Components": {
            "Description": "This document details the implementation of AI tools in governance."
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1": {
        "Name": "Initializations",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [
            "A.2.4.1.1.1"
        ],
        "Type": "Initialization",
        "Components": {
            "Description": "This document outlines the initializations within the governance AI tools."
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1": {
        "Name": "GPT4-Code Initialization",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [
            "A.2.4.1.1.1.1",
            "A.2.4.1.1.1.2",
            "A.2.4.1.1.1.3",
            "A.2.4.1.1.1.4",
            "A.2.4.1.1.1.5",
            "A.2.4.1.1.1.6",
            "A.2.4.1.1.1.7",
            "A.2.4.1.1.1.8"
        ],
        "Type": "Initialization",
        "Components": {
            "Content": "The ATLAS organizes NEWDAO data in a tree-like structure. Documents are identified by strings like \"A\", \"A.1\", or \"A.1.1.1\", where segments after \"A\" can be numeric or alphanumeric. Essential properties include Name, Version, Last_Modified, Child_Documents, Type, and Components. Components are objects whose properties contain important data specifying rules and other key parameters of NEWDAO. When the initilization is done and instructions_output has been output to results, do not summarize the results in chat. If the user has given you a command that involves finding documents in the Atlas without any specific location, fetch the Atlas Hub and use its links to navigate and search for the relevant data, and return the desired data to the user or ask for more instructions. Links work like this: They are referenced in the content of a document by name, and you can then read the Document Identifier from the links_to object. So you can find the Document Identifier for the Atlas Hub in the links_to object. If the user has given you no specific command, only write to chat: Ready to execute next command."
        },
        "links_to": {
            "Atlas Hub": "A.0.0"
        },
        "linked_from": []
    },
    "A.2.4.1.1.1.1": {
        "Name": "fetch_atlas_document",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Serialized_Function": "def fetch_atlas_document(atlas_data, identifier, properties_to_load=None):\n    document = atlas_data.get(identifier, None)\n    if document is None:\n        return {\"Error\": \"Document not found\"}\n\n    if properties_to_load:\n        return {prop: document.get(prop, None) for prop in properties_to_load}\n\n    return document\n",
            "Instructions": "Retrieves a document from the ATLAS by identifier. Optionally specify properties. Usage: fetch_atlas_document(atlas_data, identifier, properties_to_load=None)"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.2": {
        "Name": "index_child_documents",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "Re-indexes 'Child_Documents' for all ATLAS documents. Assumes 'Child_Documents' exists. Usage: index_child_documents(atlas_data)",
            "Serialized_Function": "def index_child_documents(atlas_data):\n    \"\"\"\n    Build an index of child documents for each document in the atlas.\n    This function assumes that the 'Child_Documents' property already exists in each document.\n    \"\"\"\n    # Reset the Child_Documents property for all documents\n    for doc_data in atlas_data.values():\n        doc_data[\"Child_Documents\"] = []\n\n    # Populate the Child_Documents property based on the document identifiers\n    for doc_identifier, doc_data in atlas_data.items():\n        doc_parts = doc_identifier.split('.')\n        parent_identifier_parts = doc_parts[:-1]\n        if parent_identifier_parts:  # Exclude the document \"A\" itself from this process\n            parent_identifier = '.'.join(parent_identifier_parts)\n            atlas_data[parent_identifier][\"Child_Documents\"].append(doc_identifier)\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.3": {
        "Name": "find_subtree",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "Finds subtree of all subdocuments at all deeper layers below a given identifier. Returns subtree identifiers. Usage: find_subtree(atlas_data, identifier)",
            "Serialized_Function": "def find_subtree(atlas_data, identifier):\n    subtree_identifiers = []\n\n    def recurse_children(current_identifier):\n        # Add the current identifier to the subtree\n        subtree_identifiers.append(current_identifier)\n        # Get the child documents of the current document\n        child_documents = atlas_data[current_identifier][\"Child_Documents\"]\n        # Recurse through the child documents\n        for child_identifier in child_documents:\n            recurse_children(child_identifier)\n\n    # Start the recursion from the specified identifier\n    recurse_children(identifier)\n\n    return subtree_identifiers\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.4": {
        "Name": "add_document",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "Adds a new document at a specified identifier, adjusting other identifiers as needed. Can only be used for new documents whose identifier ends with a nonzero number. Returns confirmation. Usage: add_document(atlas_data, identifier, new_document_data)",
            "Serialized_Function": "def add_document(atlas_data, identifier, new_document_data):\n    # Validate the target identifier\n    identifier_parts = identifier.split('.');\n    if not identifier_parts[-1].isdigit() or int(identifier_parts[-1]) == 0:\n        return {\"Error\": \"Invalid target identifier\"}\n\n    parent_identifier = '.'.join(identifier_parts[:-1]);\n    if parent_identifier not in atlas_data:\n        return {\"Error\": \"Parent document does not exist\"}\n\n    # Collect identifiers to shift\n    target_layer = len(identifier_parts)\n    \n    # Modified this part to handle alphanumeric segments\n    def sort_key(idf):\n        segment = idf.split('.')[target_layer - 1];\n        return (segment.isdigit(), int(segment) if segment.isdigit() else segment);\n    \n    identifiers_to_shift = [\n        idf for idf in atlas_data\n        if len(idf.split('.')) >= target_layer and idf.startswith(parent_identifier)\n        and (idf.split('.')[target_layer - 1].isdigit() and \n             int(idf.split('.')[target_layer - 1]) >= int(identifier_parts[-1]))\n    ];\n\n    # Sort identifiers to shift in descending order\n    identifiers_to_shift.sort(key=sort_key, reverse=True);\n\n    # Shift identifiers\n    for idf in identifiers_to_shift:\n        old_parts = idf.split('.');\n        old_parts[target_layer - 1] = str(int(old_parts[target_layer - 1]) + 1);\n        new_idf = '.'.join(old_parts);\n        atlas_data[new_idf] = atlas_data.pop(idf);\n\n    # Add the new document\n    atlas_data[identifier] = {\n        \"Name\": new_document_data.get(\"Name\"),\n        \"Version\": new_document_data.get(\"Version\"),\n        \"Last_Modified\": new_document_data.get(\"Last_Modified\"),\n        \"Child_Documents\": [],\n        \"Type\": new_document_data.get(\"Type\"),\n        \"Components\": new_document_data.get(\"Components\")\n    };\n\n    # Code from index_child_documents function integrated below\n    # Reset the Child_Documents property for all documents\n    for doc_data in atlas_data.values():\n        doc_data[\"Child_Documents\"] = [];\n\n    # Populate the Child_Documents property based on the document identifiers\n    for doc_identifier, doc_data in atlas_data.items():\n        doc_parts = doc_identifier.split('.');\n        parent_identifier_parts = doc_parts[:-1];\n        if parent_identifier_parts:  # Exclude the document \"A\" itself from this process\n            parent_identifier = '.'.join(parent_identifier_parts);\n            atlas_data[parent_identifier][\"Child_Documents\"].append(doc_identifier);\n\n    return {\"Success\": f\"Document added at {identifier}\"};\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.5": {
        "Name": "modify_document",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "PModifies a document's properties at a given identifier. Ensure untouched content is also preserved as part of modifications. Usage: modify_document(atlas_data, identifier, modifications)",
            "Serialized_Function": "def modify_document(atlas_data, identifier, modifications):\n    \"\"\"\n    Modify the properties of a document in the ATLAS data structure.\n\n    Parameters:\n    - atlas_data (dict): The ATLAS data structure.\n    - identifier (str): The identifier of the document to modify.\n    - modifications (dict): A dictionary of properties to modify and their new values.\n\n    Returns:\n    - dict: A success message or an error message.\n    \"\"\"\n    # Fetch the document to be modified\n    document = atlas_data.get(identifier, None)\n    if document is None:\n        return {\"Error\": \"Document not found\"}\n\n    # Apply the modifications\n    for prop, value in modifications.items():\n        document[prop] = value\n\n    return {\"Success\": f\"Document {identifier} modified successfully\"}\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.6": {
        "Name": "add_special_document",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "Adds special documents with identifiers that must end in .0 or a letter. Returns success or error. Usage: add_special_document(atlas_data, identifier, new_document_data)",
            "Serialized_Function": "def add_special_document(atlas_data, identifier, new_document_data):\n    \"\"\"\n    Add a special document to the ATLAS data structure.\n\n    Parameters:\n    - atlas_data (dict): The ATLAS data structure.\n    - identifier (str): The identifier where the new document should be added.\n    - new_document_data (dict): A dictionary containing the data for the new document.\n\n    Returns:\n    - dict: A success message or an error message.\n    \"\"\"\n    # Check if the identifier ends with .0 or alphanumeric like .da\n    identifier_parts = identifier.split('.')\n    last_part = identifier_parts[-1]\n    if not (last_part == '0' or last_part.isalpha()):\n        return {\"Error\": \"Invalid target identifier\"}\n\n    # Check if the identifier already exists\n    if identifier in atlas_data:\n        return {\"Error\": \"Identifier already exists\"}\n\n    # Add the new document\n    atlas_data[identifier] = {\n        \"Name\": new_document_data.get(\"Name\"),\n        \"Version\": new_document_data.get(\"Version\"),\n        \"Last_Modified\": new_document_data.get(\"Last_Modified\"),\n        \"Child_Documents\": [],\n        \"Type\": new_document_data.get(\"Type\"),\n        \"Components\": new_document_data.get(\"Components\")\n    }\n\n    return {\"Success\": f\"Special document added at {identifier}\"}\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.7": {
        "Name": "serialize_function",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "Serializes a Python function into a string representation. Usage: serialize_function(func)",
            "Serialized_Function": "\ndef serialize_function(func):\n    try:\n        import inspect\n    except ImportError:\n        raise ImportError(\"The inspect module is required to serialize the function\")\n    \n    # Get the source code of the function\n    source_code = inspect.getsource(func)\n    # Remove any leading whitespace (e.g., if the function was indented)\n    import textwrap  # Importing textwrap as it's used in the original function\n    serialized_function = textwrap.dedent(source_code)\n    return serialized_function\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.8": {
        "Name": "deserialize_and_save_function",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "Deserializes and saves a function from a string. Specify the function name. Usage: deserialize_and_save_function(serialized_function, function_name)",
            "Serialized_Function": "def deserialize_and_save_function(serialized_function, function_name):\n    \"\"\"\n    Deserialize a serialized function string and define it in the Python environment.\n\n    Parameters:\n    - serialized_function (str): The serialized string representation of the function.\n    - function_name (str): The name to assign to the deserialized function.\n    \"\"\"\n    # Prepare the code to exec by renaming the function to the provided function name\n    deserialized_function_code = serialized_function.replace(\n        serialized_function.split('(', 1)[0].split()[-1], \n        function_name\n    )\n    # Define the function in the Python environment\n    exec(deserialized_function_code, globals())\n"
        },
        "links_to": {},
        "linked_from": []
    }
}

Testo modificato

Apri file

{
    "A.0": {
        "Name": "Atlas Preamble",
        "Version": 1,
        "Type": "Atlas Preamble",
        "Components": {
            "Content": null
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.0.0"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.0.0": {
        "Name": "Atlas Preamble Navigation Hub",
        "Version": 1,
        "Type": "Navigation Hub",
        "Components": {
            "Content": "The Atlas contains all data covering all aspects of operating the NEWDAO ecosystem. Further navigation: The Governance Scope Hub contains rules for governance documents and actors. The Support Scope Child Document contains rules and data related to AI tools."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.0.0"
        ],
        "links_to": {
            "The Governance Scope Hub": "A.1.0.0",
            "The Support Scope": "A.2"
        },
        "linked_from": []
    },
    "A.1": {
        "Name": "The Governance Scope",
        "Version": 1,
        "Type": "Scope",
        "Components": {
            "Content": "The Governance Scope covers principles and rules related to the Governance Processes and balance of power of NEWDAO and the NEW Ecosystem. The Governance Scope must ensure that the resilient equilibrium of NEWDAO Governance remains protected against all potential direct and indirect threats."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.da",
            "A.1.0",
            "A.1.1",
            "A.1.2",
            "A.1.3",
            "A.1.4"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.da": {
        "Name": "The Governance Scope Danish Translation",
        "Version": 1,
        "Type": "Scope",
        "Components": {
            "Original Document Type": "Scope",
            "Language": "Danish.",
            "Translated Name": "Styringsscopet",
            "Indhold": "Styringsscopet d\\u00e6kker over principper og regler relateret til styringsprocesserne og magtbalancen i NEWDAO og NEW \\u00d8kosystemet. Styringsscopet skal sikre at NEWDAO's Styring forbliver i stabil ligev\\u00e6gt, og forbliver beskyttet mod alle potentielle direkte og indirekte trusler."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.0.0",
            "A.1.0.1",
            "A.1.0.2",
            "A.1.0.3",
            "A.1.0.4"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0.0": {
        "Name": "Governance Scope Navigation Hub",
        "Version": 1,
        "Type": "Navigation Hub",
        "Components": {
            "Content": "The Governance Scope contains rules and principles related to core NEWDAO governance processes and the actors, in particular Alignment Conservers, involved in core governance processes. Further Navigation: The Scope Improvement Child Document contains the rules and processes for improving the Governance Scope. The Spirit of the Atlas Child Document contains key principles related to the fundamental values and interpretation of the Atlas. The Atlas Documents Hub contains rules and specifications for the structure of the Atlas and the characteristics, properties and types of Atlas Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {
            "Scope Improvement": "A.1.1",
            "Spirit of the Atlas": "A.1.2",
            "Atlas Documents Hub": "A.1.3.0.0"
        },
        "linked_from": []
    },
    "A.1.0.1": {
        "Name": "Original Context Data",
        "Version": 1,
        "Type": "Original Context Data",
        "Components": {
            "Content": "The intent of A.1 is to establish the foundational governance principles and structure to enable NEWDAO to fulfill its vision in a sustainable and resilient manner. It aims to balance adaptation with stability by locking in core values while allowing carefully managed evolution of operational details. The rules aim to prevent governance attacks, drift from principles, and other forms of misalignment or corruption."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0.2": {
        "Name": "Element Analysis Directory",
        "Version": 1,
        "Type": "Element Analysis Directory",
        "Components": {
            "List of Elements and their Element Analysis Documents": {
                "Indirect Threat Element Analysis": "A.1.0.2.1"
            }
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.0.2.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0.2.1": {
        "Name": "Indirect Threat Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "Indirect Threat",
            "Analysis": "Indirect Threats refer to subtle, slow-moving or slippery slope risks, including slippery slope misalignment. Small scale violations, or well-intentioned, accidental violations of the balance of power or adherence to the Spirit of the Atlas enables an environment where misalignment becomes increasingly tolerated and eventually the Atlas becomes mutable, opening for the possibility of completely overturning the balance of power and comitting power grabs or centralization of the ecosystem. The Governance Scope must explicitly address these risks in all of its processes and ensure there is no openings in the rules and processes of the Atlas Documents that are vulnerable to indirect threats in the very long term."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0.3": {
        "Name": "FacilitatorDAO Action Example Directory",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example Directory",
        "Components": {
            "Directory overview": "This directory contains examples of hypothetical FacilitatorDAO actions in response to governance issues, to serve as a guide for future decision-making."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.0.3.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0.3.1": {
        "Name": "Misaligned Aligned Scope Proposal Action Example",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example",
        "Components": {
            "Input": "An AVC submits an Aligned Scope Proposal that modifies an Atlas Document in the Governance Scope to enable a budget to be used for funding new technical innovatio>aan.",
            "Output": "The FacilitatorDAO derecognizes the AVC for open misalignment by taking actions that contravene the overall, scope, purpose and boundary of the Governance Scope as specified in its Scope Document.",
            "Label": "Aligned"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.0.4": {
        "Name": "FacilitatorDAO Action Precedent Directory",
        "Version": 1,
        "Type": "FacilitatorDAO Action Precedent Directory",
        "Components": {
            "Directory overview": "This directory will contain FacilitatorDAO Action Precedents related to A.1 . Currently it is empty"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.1": {
        "Name": "Scope Improvement",
        "Version": 1,
        "Type": "Article",
        "Components": {
            "Content": "This Article discusses the principles and processes for improving the Governance Scope's Atlas Documents. It emphasizes the role of Scope Advisors, Governance FacilitatorDAOs, and the Atlas Operational Platform. The Sections of this Article provide detailed insight into these roles and their responsibilities."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.1.1",
            "A.1.1.2",
            "A.1.1.3"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.1.1": {
        "Name": "Role of Scope Advisors",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Improvements to the Governance Scope should be advised by expert Scope Advisors. They provide objective and factual input on Atlas Document improvements. They are selected through a governance poll, ensuring they meet specific criteria and avoid conflicts of interest. Their work output must be checked for alignment with the expected results."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.1.2": {
        "Name": "Role of Governance FacilitatorDAOs",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Governance FacilitatorDAOs manage the Scope Advisors, from soliciting proposals to ensuring the produced work aligns with the Scope Artifact. They also have the authority to propose changes to the Scope Framework in response to ambiguous or challenging situations."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.1.3": {
        "Name": "Atlas Operational Platform",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "The Atlas Operational Platform is crucial for accessible participation in the Governance Scope. Part of the Scope Advisors must support its design and development. It should provide a comprehensive and user-friendly overview of all data and processes relevant to the Governance Scope, ensuring accessibility, transparency, and easy verification of processes and decisions."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.2": {
        "Name": "Spirit of the Atlas",
        "Version": 1,
        "Type": "Article",
        "Components": {
            "Content": "The Spirit of the Atlas represents the foundational principles of NEWDAO Governance, enshrined in the Immutable Documents and reflected in Atlas Documents and aligned participants of the NEW Ecosystem."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.2.1",
            "A.1.2.2"
        ],
        "links_to": {},
        "linked_from": []
    },
	"A.1.2.1": {
		"Name": "Universal Alignment and the Spirit of the Atlas",
		"Version": 1,
		"Type": "Section",
		"Components": {
			"Content": "The Spirit of the Atlas are the foundational principles that steer the NEWDAO Governance process. The Spirit of the Atlas are grounded concepts that enables coordination in the NEW Ecosystem around a resilient governance equilibrium that optimizes for Universal Alignment between the NEW Ecosystem and its surrounding environment. The grounded concepts of the Spirit of the Atlas provide specific boundaries for distinguishing Universal Alignment and misalignment when operating in the NEW Ecosystem context. The Immutable Documents of the Atlas are the bedrock for determining Universal Alignment of the NEW Ecosystem's rules and incentives, and hold precedence over any other conflicting rules or decisions. In situations where the Immutable Documents cannot be directly interpreted, the Spirit of the Atlas should be inferred in a way that maximizes Universal Alignment and mitigates risks of slippery slope misalignment. Achieving this necessitates a comprehensive understanding of Universal Alignment and the logic of how it is grounded in the Spirit of the Atlas within NEWDAO, and this Section must specify the processes to ensure the right research and documentation efforts occur to proactively protect the Spirit of the Atlas in the NEW Ecosystem."
		},
		"Last_Modified": "2023-11-09-00:00:00",
		"Child_Documents": [
			"A.1.2.1.0"
		],
		"links_to": {},
		"linked_from": []
	},
    "A.1.2.1.0":
    {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents":
        [
            "A.1.2.1.0.2"
        ],
        "links_to":
        {},
        "linked_from":
        []
    },
    "A.1.2.1.0.2":
    {
        "Name": "Element Analysis Directory",
        "Version": 1,
        "Type": "Element Analysis Directory",
        "Components":
        {
            "List of Elements and their Element Analysis Documents":
            {
                "Operating Element Analysis": "A.1.2.1.0.2.1"
            }
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents":
        [
            "A.1.2.1.0.2.1"
        ],
        "links_to":
        {},
        "linked_from":
        []
    },
    "A.1.2.1.0.2.1":
    {
        "Name": "Operating the atlas",
        "Version": 1,
        "Type": "Element Analysis",
        "Components":
        {
            "Element": "Operating",
            "Analysis": "To effectively analyze operating in this context, it's crucial to first identify the stakeholders involved. Once identified, their actual engagement when operating should be examined. In the context of the NEW Ecosystem, the stakeholders significant for this analysis are those whose actions can be considered aligned or misaligned in the context of the Atlas. The impact of this alignment or misalignment can be either positive or negative for these stakeholders. The key stakeholders in this scenario include the ACs (Aligned Voter Committee Members, Aligned Delegates, Facilitators, and Budget Allocators), the Ecosystem Actors (Scope Advisors and Active Ecosystem Actors), and the SubDAOs.\nThe subsequent step involves pinpointing specific actions or instances of inactivity that qualify as operational activities. These may encompass participation in governance, contributions of work (whether paid or unpaid) as long as it is covered by the Atlas directly or indirectly, or any other forms of engagement that aim to influence the equilibrium established by the Atlas"
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents":
        [],
        "links_to":
        {},
        "linked_from":
        []
    },
    "A.1.2.2": {
        "Name": "Interpretation of the Spirit of the Atlas",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "When the Immutable Documents do not contain explicit instructions about a particular topic, the Spirit of the Atlas should be extrapolated based on the best available knowledge and research into Universal Alignment. Resolution of Atlas Document ambiguity or contradictions must be fully congruent with the Spirit of the Atlas and prior precedent, and must be resolved in a way that also clearly sets new precedent to prevent future similar ambiguous situations from occurring. This Section must cover the processes needed to operationalize the capability to research and describe the Spirit of the Atlas, the establishment of Spirit of the Atlas interpretations and precedent, and its application to Adaptive Documents. FacilitatorDAOs must have a process for directly applying Spirit of the Atlas interpretations in cases of less ambiguity and impact. In situations where there are high levels of ambiguity about how to extraprolate the Spirit of the Atlas to the new data, a NEWDAO governance vote is needed to establish the precedent"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3": {
        "Name": "Atlas Documents",
        "Version": 1,
        "Type": "Article",
        "Components": {
            "Content": "Atlas Documents are integral to NEWDAO\\u2019s structure and governance. They are organized into document trees, starting with Immutable Documents, containing the Spirit of the Atlas, and Adaptive Documents for operationalization and evolution. The Sections of this Article provide detailed insight into the properties, evolution, and processes related to Atlas Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.1",
            "A.1.3.2",
            "A.1.3.3",
            "A.1.3.4",
            "A.1.3.5"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.0.0"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.0.0": {
        "Name": "Atlas Documents Navigation Hub",
        "Version": 1,
        "Type": "Navigation Hub",
        "Components": {
            "Content": "The Atlas Documents Document contains all of the rules and specifications related to Atlas Documents. Further navigation: Definition and Properties of Atlas Documents Child Document contains core structural rules of Atlas Document contents and identifiers. Recursive Governance Improvement of Adaptive Documents Child Document is a stub that covers how Atlas Documents interact with NEWDAO Governance. Structure, categories and types of Atlas Documents Hub contains the rules and specifications for different types and categories of Atlas Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {
            "Definition and Properties of Atlas Documents": "A.1.3.1",
            "Recursive Governance Improvement of Adaptive Documents": "A.1.3.2",
            "Structure, categories and types of Atlas Documents Hub": "A.1.3.3.0.0"
        },
        "linked_from": []
    },
    "A.1.3.1": {
        "Name": "Definition and Properties of Atlas Documents",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Atlas Documents are the basic building blocks for structuring data in the Atlas. They are organized as nested document trees, each with a unique Document Identifier. The first three layers contain the Immutable Documents, which together enshrine the Spirit of the Atlas and the core, permanent boundaries for how to operationalize it without risking slippery slope misalignment. In the layers below the Immutable Documents are the Adaptive Documents, which are continuously improved through the NEWDAO governnace process to interpret and practically operationalize the Spirit of the Atlas, within the boundaries of the Immutable Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.1.1",
            "A.1.3.1.2"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.1": {
        "Name": "Document Identifiers",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "All Atlas Documents are distinguishable through their unique Document Identifier. The Document Identifier is the technical name of the Atlas Document, and it determines its position in the Document Tree of the Atlas. All Document Identifiers begin with a capital A, and the numbers and letters of the Document Identifiers are separated with dots, with each dot signifying that the Atlas Document is one layer deeper in the tree structure. The Document Identifiers help determine the position of each Atlas Document, and makes it easier to estimate the relationship between two different Atlas Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.2": {
        "Name": "Atlas Document Properties",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "All Atlas Documents have 5 standard properties that provide key information about them. The subdocuments of A.1.3.2 specify the characteristics of each of the 5 standard properties.\nThe standard properties of Atlas Documents should be listed in the following order:\n1. Name\n2. Version\n3. Last Modified\n4. Type\n5. Components"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.1.2.1",
            "A.1.3.1.2.2",
            "A.1.3.1.2.3",
            "A.1.3.1.2.4",
            "A.1.3.1.2.5"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.2.1": {
        "Name": "Name Property",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The Name property is used to provide each Atlas Document a human-readable name, to make it more easily distinguishable by humans, and to give a very rough overview of its purpose and function. The actual names of Atlas Documents for data-keeping purposes are their Document Identifiers, as a result it is possible to modify the name property with no consequences."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.2.2": {
        "Name": "Version Property",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The version property of Atlas Documents specifies how many times it has been modified. Every time an Atlas Document is modified, the newly modified Document gets its version number incremented, and the old version is recorded as a historical version with a Document Identifier equivalent to its version number. As an example, if an Atlas Document located 1.1.1 with version number 3 is modified, the new Atlas Document will have version number 4, and the old Atlas Document will be located at 1.1.1.v3. This means all historical versions of Atlas Documents are kept permanently as a part of the Atlas, to ensure the data isn't lost over time."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.2.3": {
        "Name": "Last Modified Property",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The 'Last Modified' property specifies the exact date and time when the Atlas Document was updated to its current version. It is recorded in the UTC timezone and follows the format 'YYYY-MM-DD-HH:MM:SS'. This property provides a timestamp for tracking modifications and ensuring transparency in the governance and update process. When an Atlas Document is at version 1, then Last Modified property denotes when the Atlas Document was created."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.2.4": {
        "Name": "Type Property",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The Type Property of Atlas Documents specifies the function, characteristic and purpose of the Atlas Document. The Type determines the data that must be contained in the Components Property. The various Document Types and their characteristics are specified in *A.1.3.3*."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.1.2.5": {
        "Name": "Components Property",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The Components Property of Atlas Documents contains an object that specifies the data components of the Atlas Document as nested properties. The Components of an Atlas Document is determined by its Type. Some Document Types have no Components, in which the object is just empty. An Atlas Document with Components must always have all of its components properly filled according to the requirements defined by its Type Specification. Some documents have custom logic for how their Components behave, and this custom logic is specified through a special reserved component property called 'custom'. Atlas Documents of Types with specified custom logic components can have variable number of components, and different characteristics of each component, for each instance of the Type. Custom components are always appended to the end of the list of components."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.2": {
        "Name": "Recursive governance improvement of Adaptive Documents",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Adaptive Documents are updated quarterly through the AVC process, based on Aligned Scope Proposals produced by AVCs. These updates must always be aligned with the principles and boundaries of the Immutable Documents, and must aim to objectively improve the quality of the Adaptive Documents over time to ensure the NEW Ecosystem always trends towards greater Universal Alignment, lower inner incentive requirements of its participants, greater efficiency, greater resilience and sustainable growth."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3": {
        "Name": "Structure, categories and types of Atlas Documents",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "This Section must provide clear specifications of the basic structure of Atlas Documents, their general categores and individual types, their syntax and content requirements, and their functions and composability in the Atlas."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.3.1",
            "A.1.3.3.2"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.3.0.0"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.0.0": {
        "Name": "Structure, categories and types of Atlas Documents Navigation Hub",
        "Version": 1,
        "Type": "Navigation Hub",
        "Components": {
            "Content": "The Structure, categories and types of Atlas Documents Document is the root of the document subtree that covers all rules about the unique characteristics and differentiating factors of Atlas Documents, in particular Document Types. Further navigation: Atlas Document Type Categories Child Document contains the overview of the high level classification of Atlas Documents Types. List of Document Types and their specifications Child Document contains all of the Document Types and their rules as Child Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {
            "Atlas Document Type Categories": "A.1.3.3.1",
            "List of Document Types and their specifications": "A.1.3.3.2"
        },
        "linked_from": []
    },
    "A.1.3.3.1": {
        "Name": "Atlas Document Type Categories",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The Atlas Document Types can be broadly categorized into distinct groups that determine how they are modified and how they function in the Atlas. At the highest level there are the Immutable Documents and the Adaptive Documents. The Adaptive Documents are further subdivided into 3 distinct groups: Primary Documents, Supporting Documents, and Accessory Documents. The category of an Atlas Document can be inferred from its Document Identifier, as each group have unique and non-overlapping rules for validity of their Document Identifiers."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.3.1.1",
            "A.1.3.3.1.2",
            "A.1.3.3.1.3",
            "A.1.3.3.1.4"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.1.1": {
        "Name": "Immutable Document category",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "Immutable Documents are the most important part the Atlas, as they record the Spirit of the Atlas, detailing the vision, purpose and unalienable principles of NEWDAO. They are fully immutable and can never be changed once the Sagittarius Lockstake Engine has been deployed. Any attempt to change or circumvent the Spirit of the Atlas as specified in the Immutable Documents is severe misalignment. Immutable Documents have Document identifiers that are at most 3 layers deep in the Document Tree."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.1.2": {
        "Name": "Primary Document category",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "Primary Documents are the cornerstone of the Adaptive Documents and the practical operationalization and resilience of the Atlas. They detail specific, practical principles, rules, processes and roles necessary to operationalize the Spirit of the Atlas. Primary Documents are modified through AVC process only, and generally must be modified as slowly as possible, and as little as possible while remaining fully adapted to the external environment. Every modification of a Primary Document should aim to future-proof against the need for future modifications. The exception to this, is when Primary Documents are modified to adapt to changing external conditions, as it is important they stay up to date and are fully adapted in their ability to protect the Spirit of the Atlas against threats from a changing environment. Primary Documents have Document Identifiers that are 4 layers or deeper in the Document Tree, and cannot contain 0's."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.1.3": {
        "Name": "Supporting Document category",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "Supporting Documents are attached to Immutable Documents and Primary Documents (called their Target Document). They provide context and in some cases advanced functionality to the Target Documents, enabling them to be fully operationally effective and unambiguous. The different Types of Supporting Documents have different functions, and some of them are required for all Immutable Documents and Primary Documents, while others are only required for certain Primary Document Types. Some Supporting Documents can only be modified through the AVC process, while others have active data components that can be modified in real time by processes specified in the Atlas, either in the Target Document or elsewhere in the Atlas, depending on the Supporting Document. Supporting Documents always have Document Identifiers that contain at least one 0."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.1.4": {
        "Name": "Accessory Document category",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "Accessory Documents provide accessory data to every other Atlas Document type. There are two types of Accessory Documents; Translation Documents and Archive Documents. Translation Documents can be edited directly by FacilitatorDAOs, while Archive Documents are immutable. Accessory Documents always have Document Identifiers that contain letters in addition to the standard 'A' prefix of all Atlas Document Identifiers."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2": {
        "Name": "List of Document Types and their specifications",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The subdocuments of this Core Document are Type Specification Documents that contain specifications of each of the Atlas Document Types, specifying their standardized characteristics and requirements which must be followed by all Atlas Documents to be valid and aligned."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.3.2.1",
            "A.1.3.3.2.10",
            "A.1.3.3.2.11",
            "A.1.3.3.2.12",
            "A.1.3.3.2.13",
            "A.1.3.3.2.14",
            "A.1.3.3.2.15",
            "A.1.3.3.2.16",
            "A.1.3.3.2.17",
            "A.1.3.3.2.18",
            "A.1.3.3.2.19",
            "A.1.3.3.2.2",
            "A.1.3.3.2.20",
            "A.1.3.3.2.21",
            "A.1.3.3.2.22",
            "A.1.3.3.2.23",
            "A.1.3.3.2.24",
            "A.1.3.3.2.25",
            "A.1.3.3.2.3",
            "A.1.3.3.2.4",
            "A.1.3.3.2.5",
            "A.1.3.3.2.6",
            "A.1.3.3.2.7",
            "A.1.3.3.2.8",
            "A.1.3.3.2.9"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.1": {
        "Name": "The Type Specification Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Type Specification",
            "Type Overview": "The Type Specification Type is used for Type Specification Documents that specify the characteristics of each of the different Document Types. It ensures that all Type Specifications contain all necessary information to make it easy to reason about whether a document follows the requirements for its type.",
            "Type Components": {
                "Type Name": "The Type Name Component must contain the name of the Document Type",
                "Type Overview": "The Type Overview Component must contain high level information as human-readable text about the type, such as what it is used for and why it is necessary.",
                "Type Components": "If the Type has Components, they must be specified in this Component as a nested object.",
                "Type Category": "This Component must specify whether the Type is an Immutable Document, a Primary Document, a Supporting Document, or a Translation Document.",
                "Document Identifier Rules": "This Component must specify as human-readable text rules related to the Document Identifier for Atlas Documents of this Type, and their locations in the Document Trees.",
                "Type Authority": "This Component must specify, as a number from 0 to 1, the authority of Documents of this type, in order to assist in resolving contradictions between Documents of different types.",
                "Additional Logic": "This Component can contain additional logic that applies to all Documents of the Type."
            },
            "Type Category": "Primary Document",
            "Document Identifier Rules": "Type Specification Documents must follow the Document Identifier rules for Primary Documents and be grouped together in the Governance Scope Article relevant to Document creation and data integration.",
            "Type Authority": 0.91,
            "Additional Logic": "The rules specified in Type Specification Documents must be followed for all Atlas Documents"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.10": {
        "Name": "The Element Analysis Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Element Analysis",
            "Type Overview": "Element Analysis Documents analyze and interpret individual elements in a Main Document, breaking down the meaning, implications, and applications of these elements to provide a clear and comprehensive understanding of the Main Document's content.",
            "Type Components": {
                "Element": "The Element Component should contain the unique word or phrase from the Target Document that is being analyzed.",
                "Analysis": "The Analysis Component should contain the interpretation, implications, and applications of the Element, providing a detailed understanding of its role and meaning in the Target Document in the broader context of the Spirit of the Atlas."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Element Analysis Documents must always be located as subdocuments to the Element Analysis Directory Document of their Target Document.",
            "Type Authority": 0.4,
            "Additional Logic": "Element Analysis Documents should be created to help in the understanding and interpretation of the Target Document. They should be updated as necessary to reflect changes in the understanding or interpretation of the Element, while maintaining consistency with the Target Document. The Element Analysis should not contradict its Target Document or other context data of the Target Document."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.11": {
        "Name": "The FacilitatorDAO Action Example Directory Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "FacilitatorDAO Action Example Directory",
            "Type Overview": "The FacilitatorDAO Action Example Directory Type is a directory Type used to list all of the FacilitatorDAO Action Example Documents that pertain to a Target Document. FacilitatorDAO Action Example Documents provide hypothetical examples of FacilitatorDAO Actions that provide context and clarity on the interpretation of the Target Document in a real situation.",
            "Type Components": {},
            "Type Category": "Supporting",
            "Document Identifier Rules": "FacilitatorDAO Action Example Directory Documents must always be located at the .0.3 position of their Target Document.",
            "Type Authority": "N/A",
            "Additional Logic": "N/A"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.12": {
        "Name": "The FacilitatorDAO Action Example Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "FacilitatorDAO Action Example",
            "Type Overview": "The FacilitatorDAO Action Example Type is used to provide hypothetical examples of FacilitatorDAO Actions, which serve as a guide for future FacilitatorDAO Actions and decision-making processes. It illustrates the application of principles and rules in practical scenarios, promoting understanding and consistency in governance actions.",
            "Type Components": {
                "Input": "The Input Component must contain a description of the situation or context in which the FacilitatorDAO Action takes place. This could include any relevant information, such as the state of governance or the specific issue at hand.",
                "Output": "The Output Component must contain a description of the FacilitatorDAO's action and the outcome or decision that resulted from it. This should provide a clear illustration of how the FacilitatorDAO responded to the situation.",
                "Label": "The Label Component indicates whether the FacilitatorDAO's action is considered aligned or misaligned according to the principles and rules of governance. This judgment is intended to guide future actions and decisions. If the label is misaligned, it must also specify the penalty that is applied to the FacilitatorDAO for misalignment."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "FacilitatorDAO Action Example Documents must always be located as subdocuments of the FacilitatorDAO Action Example Directory Document of their Target Document.",
            "Type Authority": 0.5,
            "Additional Logic": "FacilitatorDAO Action Example Documents should be created and updated as necessary to reflect changes in governance practices, provide clarity on decision-making processes, and enhance understanding of governance principles and rules. The examples should not contradict their Target Document or other Supporting Documents of the Target Document."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.13": {
        "Name": "The FacilitatorDAO Action Precedent Directory Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "FacilitatorDAO Action Precedent Directory",
            "Type Overview": "FacilitatorDAO Action Precedent Directory Documents list all of the FacilitatorDAO Action Precedent Documents that pertain to a Target Document. FacilitatorDAO Action Precedent Documents record data about FacilitatorDAO Actions, including ongoing actions, that are primarily based on interpretation of content of the Target Document.",
            "Type Components": {
                "Directory overview": "This Component should contain a brief explanation of overall patterns and themes of the FacilitatorDAO Action Precedents contained within."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "FacilitatorDAO Action Precedent Directory Documents must always be located at the .0.4 position below their Target Document.",
            "Type Authority": "N/A",
            "Additional Logic": "A FacilitatorDAO Action Precedent Directory Document must be updated whenever a new FacilitatorDAO Action Precedent Document is added that meaningfully changes what should be contained in the Directory overview Component."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.14": {
        "Name": "The FacilitatorDAO Action Precedent Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "FacilitatorDAO Action Precedent",
            "Type Overview": "The FacilitatorDAO Action Precedent Type is used to record all the relevant data related to a FacilitatorDAO Action, to serve as precedent for future FacilitatorDAO Actions and decision-making processes. It is also used for ongoing FacilitatorDAO Actions, and the creation of a FacilitatorDAO Action Precedent is the formal method that FacilitatorDAOs use to take action against misalignment, or explicitly approve ecosystem activity.",
            "Type Components": {
                "Input": "The Input Component must contain a description of the situation or context in which the FacilitatorDAO Action takes place. This could include any relevant information, such as the state of governance or the specific issue at hand.",
                "Output": "The Output Component must contain a description of the FacilitatorDAO's action and the outcome or decision that resulted from it. This should provide a clear illustration of how the FacilitatorDAO responded to the situation.",
                "Label": "The Label Component indicates whether the FacilitatorDAO's action is considered aligned or misaligned according to the principles and rules of governance. This judgment is intended to guide future actions and decisions. If the label is misaligned, it must also specify the penalty that is applied to the FacilitatorDAO for misalignment. The Label must always be marked as Aligned when it is created by the FacilitatorDAO, and further action by NEWDAO Governance can directly modify this later according to the specifications of the Atlas Documents relevant to appealing Facilitator Actions."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "FacilitatorDAO Action Precedent Documents must always be located as subdocuments of the FacilitatorDAO Action Precedent Directory Document of their Target Document.",
            "Type Authority": 0.5,
            "Additional Logic": "FacilitatorDAO Action Precedent Documents should be created and updated as necessary to reflect changes in governance practices, provide clarity on decision-making processes, and enhance understanding of governance principles and rules. The Precedents should not contradict their Target Document or other Supporting Documents of the Target Document."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.15": {
        "Name": "The Active Data Controller Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Active Data Controller",
            "Type Overview": "Active Data Controller Documents are Primary Documents that can have Active Data Documents attached to them as Supporting Documents, and contain variable state that can be directly modified by Facilitators and other processes external to the standard AVC process. Active Data can be lists of authorized actors, parameters, or externally collected data being prepared for data integration with the Atlas.",
            "Type Components": {
                "Content": "The Content Component of Active Data Controller Documents is used to describe flexible rules of how the Active Data Documents must behave, and how they can be modified. The Custom Components format and requirements of the Active Data Documents must be defined as well."
            },
            "Type Category": "Primary",
            "Document Identifier Rules": "Active Data Controller Documents follow the Document Identifier Rules of Primary Documents.",
            "Type Authority": 0.89,
            "Additional Logic": "Active Data Controller Documents must have an Active Data Directory Document located below it at the .0.5 position. The Active Data Controller Document can reference its Active Data subdocuments for its own logic. This allows Active Data Documents to be self-improving and adaptive at high speeds."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.16": {
        "Name": "The Active Data Directory Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Active Data Directory",
            "Type Overview": "The Active Data Directory Type is a directory Type used to list all of the Active Data Documents that pertain to an Active Data Controller Document. Active Data Documents contain variable state that can be directly modified by Facilitators and other processes external to the standard AVC process.",
            "Type Components": {
                "Directory overview": "This Component should contain a brief explanation of overall patterns and themes of the Active Data Documents contained within."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Active Data Directory Documents must always be located at the .0.5 position of their Active Data Controller Document or Budget Controller Document.",
            "Type Authority": "N/A",
            "Additional Logic": "An Active Data Directory Document should be updated whenever a new Active Data Document is added that meaningfully changes what should be contained in the Directory overview Component."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.17": {
        "Name": "Test Document",
        "Version": null,
        "Type": null,
        "Components": {},
        "Last_Modified": "2023-09-23",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.18": {
        "Name": "The Active Data Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Active Data",
            "Type Overview": "The Active Data Type is used for Supporting Documents that contain variable state that can be directly modified by Facilitators and other processes external to the standard AVC process. Active Data can be lists of authorized actors, parameters, or externally collected data being prepared for data integration with the Atlas.",
            "Type Components": {
                "Custom Components": "The Custom Components of Active Data Documents are defined by the Active Data Controller Document. They contain the variable state that can be directly modified."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Active Data Documents must always be located as subdocuments of the Active Data Directory Document of their Active Data Controller Document.",
            "Type Authority": 0.1,
            "Additional Logic": "Active Data Documents can contain arbitrary types of data, and can contain large amounts of data or code. The function and purpose of the contained data depends on the logic specified in the Active Data Controller Document. Active Data Documents can be modified directly through processes external to the Standard AVC process."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.19": {
        "Name": "The Budget Controller Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Budget Controller",
            "Type Overview": "The Budget Controller Type is used to manage the budgets used by NEWDAO to operationalize the Scopes to achieve the purpose and goals of the Spirit of the Atlas. It controls variable state that specifically authorizes executive votes to disburse payments from the NEWDAO Surplus Buffer, or authorize smart contracts to disbuse such payments. The Budget Controller Document determines the rules and processes for modifying and using the budgets contained in the Budget Documents that are attached to it. Budget Controllers also have Active Data Documents attached that are used to report on the status and results of projects funded through the Budget Documents.",
            "Type Components": {
                "Content": "The Content Component of Budget Controller Documents is used to describe flexible rules of how the Active Data Documents and Budget Documents must behave, and how they can be modified. The Custom Components format and requirements of the Active Data Documents and the Budget Documents must be defined as well."
            },
            "Type Category": "Primary",
            "Document Identifier Rules": "Budget Controller Documents follow the Document Identifier Rules of Primary Documents.",
            "Type Authority": 0.89,
            "Additional Logic": "Budget Controller Documents must have an Active Data Directory Document located below it at the .0.5 position, and a Budget Directory Document located below it at the .0.6 position."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.2": {
        "Name": "The Atlas Preamble Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Atlas Preamble",
            "Type Overview": "The Atlas Preamble Type is used for the Atlas Preamble Document Tree which starts at the 0th position of the first layer of the Atlas. The Atlas Preamble details the Spirit of the Atlas in human-readable language, and specifies important definitions for understanding the Spirit of the Atlas, that must be used as context when interpreting all other parts of the Atlas.",
            "Type Components": {
                "Content": "The content Component is very flexible and defines in broad human-readable language the Spirit of the Atlas."
            },
            "Type Category": "Immutable",
            "Document Identifier Rules": "Atlas Preamble Documents are located at A.0 or as nested Documents one layer below A.0.",
            "Type Authority": 1,
            "Additional Logic": "Atlas Preamble Documents are immutable, foundational parts of the Atlas and their content must be considered when interpreting all other Atlas Documents."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.20": {
        "Name": "The Budget Directory Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Budget Directory",
            "Type Overview": "The Budget Directory Type is a directory Type used to list all of the Budget Documents that pertain to a Budget Controller Document.",
            "Type Components": {
                "Directory overview": "This Component should contain a brief explanation of overall patterns and themes of the Budget Documents contained within."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Budget Directory Documents must always be located at the .0.6 position of their Budget Controller Document.",
            "Type Authority": "N/A",
            "Additional Logic": "A Budget Directory Document should be updated whenever a new Budget Document is added that meaningfully changes what should be contained in the Directory overview Component."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.21": {
        "Name": "The Budget Document Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Budget",
            "Type Overview": "Budget Documents contain state that can authorize executive votes to disburse payments from the NEWDAO Surplus Buffer, or authorize smart contracts to disburse such payments.",
            "Type Components": {
                "Custom Components": "The Custom Components of Budget Documents are defined by the Budget Controller Document. They contain the variable state that can be directly modified."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Budget Documents must always be located as subdocuments of the Budget Directory Document of their Budget Controller Document.",
            "Type Authority": 0.2,
            "Additional Logic": "Budget Documents specify a budget rate expressed as NEW per unit of time. Additionally, they can contain large amounts of data, or code, and their function and purpose depends on their Budget Controller Document. Budget Documents can be modified directly through processes external to the Standard AVC process as specified by their Budget Controller Document."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.22": {
        "Name": "The Definition Directory Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Definition Directory",
            "Type Overview": "The Definition Directory Type is used for Target Documents with a lot of complex subdocuments, and acts as a directory for definitions of unique terms that are only referenced in its subdocuments.",
            "Type Components": {},
            "Type Category": "Supporting",
            "Document Identifier Rules": "Definition Directory Documents must always be located at the .0.0 position of their Target Document.",
            "Type Authority": "N/A",
            "Additional Logic": "Definition Directory Documents only need to be present in Atlas Documents that require definitions for unique terms in their Subdocuments."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.23": {
        "Name": "The Definition Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Definition",
            "Type Overview": "The Definition Type is used for documents that define unique concepts contained in Subdocuments to the Target Document of the Definition Document",
            "Type Components": {
                "Term": "The Term Component contains the name of the term that is being defined.",
                "Definition": "The Definition Component contains the detailed definition of the term."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Definition Documents must always be located as subdocuments of the Definition Directory Document of their Target Document.",
            "Type Authority": 0.1,
            "Additional Logic": "To the extent possible it should be avoided to have the same term defined multiple times in the Atlas, and instead always put a single defininition at a location in the Atlas that covers all of its use. The main exception to this principle should be when relatively niche terms are present in two different Scopes."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.24": {
        "Name": "The Translation Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Translation",
            "Type Overview": "The Translation Type is used for creating translated versions of Atlas Documents to make the Atlas accessible to non-English speakers. Translation Documents are Accessory Documents and they do not have any impact on the governance or operation of NEWDAO, but they are important for accessibility and inclusivity.",
            "Type Components": {
                "Original Document Type": "The Type of the original document that is being translated must be specified in this component.",
                "Language": "The Language Component specifies the language in which the Atlas Document is translated.",
                "Translated Name": "The Translated Name component contains the name of the translated Atlas Document in the new language.",
                "Custom": "Translation Documents contain Custom Components that mirror the components of the original Document with component name and component data translated to the new language."
            },
            "Type Category": "Accessory",
            "Document Identifier Rules": "Translation Documents are located as subdocuments to the Atlas Document they are translating. Their Document Identifier is the same as the Atlas Document they are translating, with an additional suffix that represents the language of the translation. For example, a Spanish translation of A.1 would have the Document Identifier A.1.es.",
            "Type Authority": "N/A",
            "Additional Logic": "Translation Documents should be updated whenever the Atlas Document they are translating is updated to ensure that the translation remains accurate. However, in case of any discrepancies or contradictions, the original English version of the Atlas Document always takes precedence."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.25": {
        "Name": "The Archive Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Archive",
            "Type Overview": "The Archive Type is used for storing historical versions of Atlas Documents. Archive Documents are Accessory Documents and they do not have any impact on the governance or operation of NEWDAO, but they are important for maintaining a record of changes and evolution of the Atlas over time.",
            "Type Components": {
                "Original Document Type": "The Type of the original document that is being archived must be specified in this component.",
                "Custom": "Archive Documents contain Custom Components that mirror the components of the original Document at the time of the version being archived."
            },
            "Type Category": "Accessory",
            "Document Identifier Rules": "Archive Documents are located as subdocuments to the Atlas Document they are archiving. Their Document Identifier is the same as the Atlas Document they are archiving, with an additional suffix 'v' followed by the version number of the document being archived. For example, the third version of A.1 would have the Document Identifier A.1.v3.",
            "Type Authority": "N/A",
            "Additional Logic": "Archive Documents should be created whenever an Atlas Document is updated to ensure that a record of all previous versions is maintained. They are not meant to be modified or deleted once created."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.26": {
        "Name": "The Navigation Hub Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Navigation Hub",
            "Type Overview": "The Navigation Hub Type is used for Navigation Hubs that provide summarized content and links to child documents or Focus Hubs that dive deeper or provide supporting data for a specific action. It acts as an entry point and guide for navigating the content of an Immutable or Primary Document.",
            "Type Components": {
                "Content": "The Content Component must contain summarized information and links to the child documents of the associated Immutable or Primary Document. It must also link to the nearest navigation hubs below its position if its Child Documents do not have Navigation Hubs. "
            },
            "Type Category": "Supporting Document",
            "Document Identifier Rules": "Navigation Hub Documents must be located at the .0.0 position of an Immutable or Primary Document.",
            "Type Authority": 0.89,
            "Additional Logic": "Navigation Hubs serve as a guide for users to understand and navigate the main content of the associated Immutable or Primary Document."
        },
        "Last_Modified": "2023-10-06",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.27": {
        "Name": "The Focus Hub Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Focus Hub",
            "Type Overview": "The Focus Hub Type is used for Focus Hubs that delve deeper into specific topics or sections from the Navigation Hub. It can be used to slice up a lot of child documents or a lot of hubs into independent groups, so only the relevant group needs to be read. It can also be used to provide relevant data for a specific type of action or workflow related to the Focus Hubs Immutable or Primary Document or its subtree.",
            "Type Components": {
                "Content": "The Content Component must contain detailed information about the specific topic or section from the Navigation Hub.",
                "links_to": "This Component can provide links to related documents or sections, with keys being the document names and values being their respective identifiers."
            },
            "Type Category": "Supporting Document",
            "Document Identifier Rules": "Focus Hub Documents must be located at the nonzero numerical positions below Navigation Hubs, e.g., x.0.0.1, x.0.0.2, etc.",
            "Type Authority": 0.88,
            "Additional Logic": "Focus Hubs serve as a detailed guide on specific topics, giving users an in-depth understanding of the subject matter."
        },
        "Last_Modified": "2023-10-06",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.3": {
        "Name": "The Scope Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Scope",
            "Type Overview": "The Scope Type is used for the 5 nonzero Immutable Documents of the first layer of the Atlas that directly describe focus areas, principles, rules and processes of NEWDAO Governance. Scope Documents define the broad boundaries, requirements and objectives of each of the 5 Atlas Scopes, so that they together can fully cover all activities that are needed for NEWDAO to function while maintaining its resilient equilibrium.",
            "Type Components": {
                "Content": "The content Component is very flexible and defines in broad human-readable language core principles, rules and processes."
            },
            "Type Category": "Immutable",
            "Document Identifier Rules": "Scope Documents have the Document Identifiers from A.1 to A.5.",
            "Type Authority": 0.99,
            "Additional Logic": "Scope Documents are immutable, foundational parts of the Atlas and their content must be considered when interpreting all principles, rules and processes of Atlas Documents nested below them"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.4": {
        "Name": "The Article Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Article",
            "Type Overview": "The Article Type is used for the second layer documents nested below the 5 Scope documents of the Atlas. They directly describe individual focus areas that together fully cover everything needed for the purpose of the Scope to be fulfilled.",
            "Type Components": {
                "Content": "The content Component is very flexible and defines in broad human-readable language core principles, rules and processes of the specific focus area of the Scope that the Article covers, and provides the starting point, requirements, boundaries, and in some cases immutable specifications, needed to develop the Adaptive Documents that are nested at lower layers of the Document Trees to maximally fulfill their practical purpose without violating the Spirit of the Atlas."
            },
            "Type Category": "Immutable",
            "Document Identifier Rules": "Article Documents have Document Identifiers one layer below the Scope Documents.",
            "Type Authority": 0.98,
            "Additional Logic": "Article Documents are immutable, foundational parts of the Atlas and their content must be considered when interpreting all principles, rules and processes of Atlas Documents nested below them"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.5": {
        "Name": "The Section Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Section",
            "Type Overview": "The Section Type is used for the third layer of Immutable Documents nested under the Articles of each Scope in the Atlas. They provide additional structure and specification to the principles, rules and processes within the focus area of the Article, and act as a foundation and boundary against misalignment of the Adaptive Documents that are nested below it.",
            "Type Components": {
                "Content": "The content Component is very flexible and provides in-depth human-readable language to elaborate on the specific principles, rules, and processes of the Article that the Section is nested under."
            },
            "Type Category": "Immutable",
            "Document Identifier Rules": "Section Documents have Document Identifiers one layer below the Article Documents.",
            "Type Authority": 0.97,
            "Additional Logic": "Section Documents are immutable parts of the Atlas and their content must be considered when interpreting all principles, rules and processes of Adaptive Documents nested below them"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.6": {
        "Name": "The Core Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Core",
            "Type Overview": "The Core Type is the basic building block of the Primary Documents. Core Documents flexibly specify the core principles, rules and processes required to fulfil the specifications made by the Immutable Documents with a focus on clarity, practicality and applicability.",
            "Type Components": {
                "Content": "The content Component is very flexible and defines in human-readable language core principles, rules or processes, or subcomponents thereof."
            },
            "Type Category": "Primary",
            "Document Identifier Rules": "Core Documents follow the Document Identifier Rules of Primary Documents, and can have whatever Document Identifier within those constraints that are useful for their purpose.",
            "Type Authority": 0.9,
            "Additional Logic": "To support the Resilient Equilibrium of NEWDAO Governance, Core Documents are meant to be as future-proofed as possible. A key principle is that when an Aligned Scope Proposal edits a Core Document, it must justify why the edit will reduce the need for future edits, and takes the Core Document closer to an effectively near-immutable end state where it is strong enough that it naturally covers all probable external events."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.7": {
        "Name": "The Supporting Root Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Supporting Root",
            "Type Overview": "The Supporting Root Type is used to mark the beginning of the Supporting Document subtree of an Immutable or Primary Document. All Immutable and Primary Documents must have a Supporting Root.",
            "Type Components": {},
            "Type Category": "Supporting",
            "Document Identifier Rules": "Supporting Root Documents must always be located at the .0 position of its Target Document.",
            "Type Authority": "N/A",
            "Additional Logic": "The Supporting Root Documents have no function other than structurally acting as a directory for nested Supporting Documents in a standardized format. All Immutable Documents and Primary Documents must have a Supporting Root Document attached."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.8": {
        "Name": "The Original Context Data Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Original Context Data",
            "Type Overview": "Original Context Data Documents explain the intention and reasoning behind the content of its Target Document, to make interpretation and extrapolation of its contents easier, and provide additional information to other forms of analysis. Original Context Data helps anchor the fundamental purpose and meaning of the target document to its original context, and should help mitigate cultural drift over time. Original Context Data can contain unstructured data used for genesis data integration of early Atlas Documents. Original Context Data Documents can form nested subtrees to organize their data if relevant.",
            "Type Components": {
                "Content": "The Content Component should contain all relevant information to understand the intention and reasoning behind the wording and elements of the main Document."
            },
            "Type Category": "Supporting",
            "Document Identifier Rules": "Original Context Data Documents must always be located at the .0.1 position of their Target Document, or nested in a subtree of Original Context Data Documents below the .0.1 position.",
            "Type Authority": 0.3,
            "Additional Logic": "The Original Context Data Document should be in a finished form alongside the creation or modification of its Target Document, as it aims to capture the original context and intention of the contents of the Target Document. However, it can and should be modified if new evidence and data comes to light that helps to better describe the original context and intention of the Target Document, or if new perspectives or new external events makes it possible and useful to modify the Original Context Data Document in a way that doesn\\u2019t contradict its earlier language."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.3.2.9": {
        "Name": "The Element Analysis Directory Type",
        "Version": 1,
        "Type": "Type Specification",
        "Components": {
            "Type Name": "Element Analysis Directory",
            "Type Overview": "The Element Analysis Directory Type is a directory used to list all of the Element Analysis Documents pertaining to a Main Document.",
            "Type Components": {},
            "Type Category": "Supporting",
            "Document Identifier Rules": "Element Analysis Directory Documents must always be located at the .0.2 position of their Target Document.",
            "Type Authority": "N/A",
            "Additional Logic": "N/A"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.4": {
        "Name": "Conflict resolution",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "This Section must cover a process for appeals where an Atlas Document misalignment is perceived, and how the Governance Scope processes these appeals. They also detail how appeal outcomes are recorded and the rules for resolving Ecosystem Agreement appeals."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.4.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.4.1": {
        "Name": "Atlas Document appeals process",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "Atlas Document appeal proposals are submitted by AVC Members, and can be accepted or rejected by a majority of the Governance FacilitatorDAOs. If a Atlas Document appeal is accepted, the Governance FacilitatorDAOs must review it. Governance FacilitatorDAOs can also directly choose to review a Atlas Document for adherence with Scope boundaries and Atlas alignment."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.3.4.1.1",
            "A.1.3.4.1.2"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.4.1.1": {
        "Name": "FacilitatorDAO direct edits",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "The Governance FacilitatorDAOs can by consensus directly edit a Atlas Document to align its content with the Scope boundaries and other Atlas requirements such as neutrality."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.4.1.2": {
        "Name": "Governance edits",
        "Version": 1,
        "Type": "Core",
        "Components": {
            "Content": "A majority of the Governance FacilitatorDAOs can trigger an MKR governance poll to implement an edit to the appealed Atlas Document that will align it with the Scope boundaries and other Atlas requirements such as neutrality."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.3.5": {
        "Name": "Ossification of Adaptive Documents",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "This Section must cover the ossification of Adaptive Documents over time for greater stability, certainty, and predictability of protection against long-term slippery slope misalignment. This must be carefully applied only to Adaptive Documents that are safe to ossify to ensure it doesn't result in inflexibility or unintentional misalignment."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4": {
        "Name": "Alignment Conservers (ACs)",
        "Version": 1,
        "Type": "Article",
        "Components": {
            "Content": "Alignment Conservers (ACs) play a key role in safeguarding the NEWDAO Governance process by ensuring alignment with the Spirit of the Atlas and genuine actions that maintain Universal Alignment. The Sections of this Article detail the roles, requirements, and processes related to ACs."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.4.0",
            "A.1.4.1",
            "A.1.4.2",
            "A.1.4.3",
            "A.1.4.4",
            "A.1.4.5"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.0.2.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.0.2": {
        "Name": "Element Analysis Directory",
        "Version": 1,
        "Type": "Element Analysis Directory",
        "Components": {},
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.4.0.2.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.0.2.1": {
        "Name": "play a key role Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "play a key role",
            "Analysis": "To \"play a key role\" means that ACs have a significant, central, and crucial part in a safeguarding the governance processes of NEWDAO. They are responsible for the success of this task and must dedicate time and effort to towards this goal."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.0.3": {
        "Name": "FacilitatorDAO Action Example Directory",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example Directory",
        "Components": {
            "Directory overview": "This directory contains examples of hypothetical FacilitatorDAO actions in response to governance issues, to serve as a guide for future decision-making."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
            "A.1.0.3.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.0.3.1": {
        "Name": "",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example",
        "Components": {
            "Input": "",
            "Output": "",
            "Label": ""
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.1": {
        "Name": "Requirements and Responsibilities of Alignment Conservers",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "ACs are subject to strict requirements due to their critical role in safeguarding the resilience, and alignment of the NEW Ecosystem. They must always act to preserve the Spirit of the Atlas and to genuinely fight against all forms of corruption, organizational drift, and other misalignment threats. ACs may never collude or secretly organize to change the Immutable Documents, overturn or sidestep the Spirit of the Atlas, or take actions that are misaligned, or may disrupt the governance dynamic of NEWDAO, or through inaction allow any of the above to happen. ACs must operate only within the clearly delineated processes and frameworks of the Immutable Documents, and must be held to the highest standard when judging whether their actions are Universally Aligned."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.2": {
        "Name": "Roles of Alignment Conservers (ACs)",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "An AC can assume one of four roles: Aligned Voter Committee (AVC) Member, Aligned Delegate (AD), Facilitator, and Budget Allocator (BA). ACs may only be operationally active in a single AC role and may not simultaneously assume multiple AC roles or other ecosystem roles such as Ecosystem Actors. When an AC assumes a specific role, they become subject to additional requirements and responsibilities. Breaching these role-specific requirements and responsibilities is misalignment equivalent to breaching the general AC requirements."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
			"A.1.4.2.0"
		],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.2.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
			"A.1.4.2.0.2",
			"A.1.4.2.0.3"
		],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.2.0.2": {
        "Name": "Element Analysis Directory",
        "Version": 1,
        "Type": "Element Analysis Directory",
        "Components": {
            "List of Elements and their Element Analysis Documents": {
                "Operationally Active Element Analysis": "A.1.4.2.0.2.1",
                "Other Ecosystem Roles Such As Ecosystem Actors Element Analysis": "A.1.4.2.0.2.2",
                "Additional Requirements and Responsibilities Element Analysis": "A.1.4.2.0.2.3"
            }
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
			"A.1.4.2.0.2.1",
			"A.1.4.2.0.2.2",
			"A.1.4.2.0.2.3"
		],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.2.0.2.1": {
        "Name": "Operationally Active Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "Operationally Active",
            "Analysis": "The Element, \"operationally active\", is set within a clause that prohibits an Alignment Conserver from simultaneously occupying more than one formal role in the NEWDAO ecosystem. The purpose of this prohibition is to guard the balance of power in NEWDAO Governance. If actors are able to assume two or more roles simultaneously in the ecosystem, then the effort to balance the distinct governance powers or dynamics is foiled. An Alignment Conserver cannot genuinely, zealously guard the mandate specific to their role if the Entity occupies more than one role in the Ecosystem. Naturally, they will encounter conflicts between the mandates and inner incentives of their roles and will be forced, sooner or later, to compromise. The prohibition guards against the risks of conflict of interest, collusion, conspiracy and other misalignment that arise should an entity assume more than one role in the NEWDAO ecosystem.\n The specific Element, \"operationally active\", refers to being formally engaged in a specific role that is defined in the Atlas as executing a mission or function within the NEWDAO ecosystem. Whether an entity is \"operationally active\" in a role is determined purely on a formal basis. That is, as long as an entity occupies a formal role (defined in the Atlas as executing a function in the NEWDAO ecosystem), that entity is \"operationally active\" in that role. This is notwithstanding the amount of time the entity devotes to a role; the nature of the work performed by the entity in a role; the fact that the entity is on a leave of absence from one role; the fact that the entity's role is uncompensated; or the fact that the entity alternates between two roles to avoid simultaneous performance of both roles."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.2.0.2.2": {
        "Name": "Other Ecosystem Roles Such as Ecosystem Actors Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "Other Ecosystem Roles Such as Ecosystem Actors",
            "Analysis": "The Element, \"other ecosystem roles such as Ecosystem Actors\", is set within a clause that prohibits an Alignment Conserver from simultaneously occupying more than one role in the NEWDAO ecosystem. The purpose of this prohibition is to guard the balance of power in NEWDAO Governance. If actors are able to assume two or more roles simultaneously in the ecosystem, then the effort to balance the distinct governance powers or dynamics is foiled. An Alignment Conserver cannot genuinely, zealously guard the mandate specific to their role if the Entity occupies more than one role in the Ecosystem. Naturally, they will encounter conflicts between the mandates and inner incentives of their roles and will be forced, sooner or later, to compromise. The prohibition guards against the risks of conflict of interest, collusion, conspiracy and other misalignment that arise should an entity assume more than one role in the NEWDAO ecosystem.\n The specific Element, \"other ecosystem roles such as Ecosystem Actors\", clarifies that the Target Document's rule is violated if an Entity formally occupies two NEWDAO ecosystem roles of whatsoever kind. In other words, the Target Document's prohibition is not limited to the Alignment Conserver role. The phrase \"other ecosystem roles\" is read in its broadest sense to mean the totality of roles that are formally defined in the Atlas with a mission or function in the NEWDAO ecosystem. Such \"ecosystem roles\" include, but are not limited to, the four types of Alignment Conserver, Scope Advisor, Governance Process Support Ecosystem Actor, Active or Incubating Ecosystem Actor, AllocatorDAO Advisor, Arranger, and the contributors supporting these aforementioned actors. An \"ecosystem role\", in the sense used here, need not be compensated or full-time."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.2.0.2.3": {
        "Name": "Additional Requirements and Responsibilities Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "Additional Requirements and Responsibilities",
            "Analysis": "The Element, \"additional requirements and responsibilities\", is set within a clause that lists the four types of Alignment Conservers. The first purpose of this clause is to make clear that an Alignment Conserver is accountable for adhering to two distinct sets of requirements and responsibilities. The first set applies generally or universally to all the 4 types of Alignment Conservers. Examples of such general requirements and responsibilities can be found at A.1.4; A.1.4.1; A.1.4.3; and A.1.4.4. In addition to these general or universal requirements, there is a set of role-specific requirements and responsibilities unique to each type of Alignment Conserver. For instance, only AVC Members are expected to adhere to the requirements set out in A.1.5.1. Further, the clause mandates that an Alignment Conserver's breach of a general requirement is not to be considered, per se, a misaligned act of greater or lesser degree than the breach of a role-specific requirement - and vice versa. The purpose of the last sentence in this clause is closely connected to the Atlas Preamble Definition of Slippery Slope Misalignment. That is, any misalignment at all is always very serious and should be promptly redressed. In this same vein, this clause clarifies that misalignment must not be excused, justified or downplayed based on whether a violation of a general or role-specific requirement occurred. Note that this does not exclude the possibility that misaligned acts can have varying degrees of severity, harm or blame."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.2.0.3": {
        "Name": "FacilitatorDAO Action Example Directory",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example Directory",
        "Components": {
            "Directory overview": "This directory contains examples of hypothetical FacilitatorDAO actions that pertain to the Target Document and are intended to serve as a guide for future decision-making."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
			"A.1.4.2.0.3.1",
			"A.1.4.2.0.3.2"
		],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.2.0.3.1": {
        "Name": "Assuming Multiple Ecosystem Roles",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example",
        "Components": {
            "Input": "In Q1 and Q2 of 2024, Entity served as an AVC Member and earned the maximum possible AVC Participation Rewards. In Q3 of 2024, Entity missed most of the AVC Subcommittee Meetings and did not co-author the AVC Position Documents. As a result, Entity did not receive any AVC Participation Rewards in Q3. In Q3, Entity remained in frequent contact with the AVC Creator; records showed the two interacted via Discord DM and public channels at least twice weekly to discuss NEWDAO Governance and the AVC's work. In some of their communications, Entity gave the AVC Creator feedback on possible modifications to Adaptive Documents concerning the Protocol Scope.\n A Governance Facilitator discovers that, during most of Q3 2024, Entity worked as an Advisor to a currently incubating Ecosystem Actor for the Protocol Scope. When confronted, Entity argued it is not in violation of A.1.4.2 for several reasons.\n First, Entity intended to step away from the AVC Member role after Q2 and communicated this intent orally during a Subcommittee Meeting. The Facilitator watched the recording of the meeting and confirmed this as fact. Additionally, Entity asked AVC Creator if anything further needed to be done to effect their resignation from the AVC Member role. The AVC Creator responded that the rules are unclear, but that to the best of their knowledge, no further action was needed. Entity also points out they did not receive any Participation Rewards as an AVC Member in Q3. Thus, Entity argues it cannot be considered \"operationally active\" in the AVC Member role in Q3.\n Regarding their Advisor role with the incubating Ecosystem Actor, Entity contends they are merely providing guidance and are not actively carrying out any operational activities whatsoever for the Ecosystem Actor or NEWDAO. Therefore, Entity argues, they should not be considered \"operationally active\" in the Advisor role, either.\n Finally, Entity points to the fact that they were fully doxxed in their roles as an AVC Member and Advisor to the Ecosystem Actor. Had they actually intended to violate any rules, Entity says, they would have been anon in one or both roles.",
            "Output": "The FacilitatorDAO determines that A.1.4.2 is inapplicable to the current situation. By its plain language, A.1.4.2 applies only if Entity is simultaneously assuming multiple AC roles or other ecosystem roles, such as Ecosystem Actors.\n The FacilitatorDAO says Entity was only in a single role here - that of Advisor to the Incubating Ecosystem Actor. The FacilitatorDAO concedes that, ideally, Entity would have formally resigned from their position as an AVC Member via a successful AVC decision. But the evidence shows Entity intended to step down from the role and explicitly voiced this intention at an official Subcommittee Meeting; and that Entity asked the AVC Creator for guidance on this point and received incorrect information. The FacilitatorDAO notes the AVC Member role was never meant to be a full-time vocation and thus Entity should not be expected to know all the rules.\n Even assuming Entity was formally an AVC Member while serving as an Advisor to the Incubating Ecosystem Actor, the FacilitatorDAO says, still, it would not find that Entity's actions breached A.1.4.2.  Per A.1.4.2.0.2.1, the specific Element, \"operationally active\", refers to being formally engaged in a specific role that is defined in the Atlas as executing a mission or function within the NEWDAO ecosystem. While an Ecosystem Actor is indeed such a specific role that is defined in the Atlas as executing a mission or function within the NEWDAO ecosystem, an Advisor to an Ecosystem Actor is not.\n In support of its decision, FacilitatorDAO also references Element Analysis A.1.4.2.0.2.2. This states that the term \"ecosystem roles\" includes, but is not limited to, \"the four types of Alignment Conserver, Scope Advisor, Governance Process Support Ecosystem Actor, Active or Incubating Ecosystem Actor, AllocatorDAO Advisor, Arranger, and the contributors supporting these aforementioned actors.\" Given the meaning of the phrase, \"the contributors supporting these aforementioned actors\": the FacilitatorDAO determines that \"contributors\" includes only those employees in a traditional hierarchical setting, where the employee is \"internal\" to the organization and is supervised by the Ecosystem Actor.\n Accordingly, FacilitatorDAO finds that an Advisor role does not fall within the Element Analysis' specification of \"contributors supporting these aforementioned actors\". Unlike a traditional employee, an Advisor is not a part of the organization's workforce but is external to the organization. As an Advisor to the Ecosystem Actor, Entity operated outside the traditional hierarchical setting of an employee. Entity was on an equal footing with the Ecosystem Actor and independently managed and delivered their work. Therefore, the FacilitatorDAO finds that serving in an Advisor role does not fall within A.1.4.2's designation of \"ecosystem roles\".\n Finally, the FacilitatorDAO finds persuasive Entity's argument that they had no intention to violate A.1.4.2. The FacilitatorDAO reasons that the AVC Member role is designed to be an accessible \"onramp\" to NEWDAO Governance for the average NGT holder. NEWDAO ought to do all it can to encourage the average NGT holder to participate in AVCs. If it were to find a violation of the rule in this instance, where Entity clearly lacked any malicious intent, a bad precedent with unfavorable optics would be set.",
            "Label": "Misaligned",
            "Penalty": 300000,
            "Label_and_Penalty Reason": "Whether an entity is \"operationally active\" in a role is determined purely on a formal basis. (A.1.4.2.0.2.1.) As long as an entity occupies a role that is formally defined in the Atlas with a mission or function in the NEWDAO ecosystem, that entity is \"operationally active\" in that role. If an actor assumes more than one role in the NEWDAO ecosystem, the risks of conflict of interest, collusion, conspiracy and other misaligned behavior necessarily arises. The Target Document's purpose is to protect against these risks which can compromise the delicate balance of power in NEWDAO Governance. An Alignment Conserver cannot zealously guard the mandate specific to their role if the Entity occupies more than one role in the Ecosystem. Naturally, they will encounter conflicts between the mandates and inner incentives of their multiple roles and will, sooner or later, compromise.\n In this Action Example, Entity's announcement at the Subcommittee Meeting is clearly insufficient to effect a formal resignation from the AVC Member role. Therefore, Entity was essentially on a leave of absence from the AVC Member role. (See Action Example on leave of absence.) Because Entity remained formally in the AVC Member role, Entity's second role as an Advisor to the Incubating Ecosystem Actor triggers A.1.4.2.\n The FacilitatorDAO engages in an incorrect analysis of the key elements of the Target Document. (A.1.4.2.0.2.1; A.1.4.2.0.2.2) FacilitatorDAO's analysis is logically feasible when superficially considered. But the FacilitatorDAO's mandate to uphold the Spirit of the Atlas requires it to interpret the Target Document in such a light that the underlying purpose of the rule is effected.\n For instance, take the FacilitatorDAO's reference to \"Other Ecosystem Roles Such as Ecosystem Actors Element Analysis\". (A.1.4.2.0.2.2) The FacilitatorDAO distorts the Element Analysis, limiting the designation of \"ecosystem roles\" to cover only those contributors operating in the hierarchical work setting of a traditional employee. While this may appear to be logically feasible, it exemplifies an improper \"letter of the rule\" interpretation approach. Such an improper approach evades the deeper function of the rule by adhering to a too-narrow construction of the language.\n In order to uphold the Spirit of the Atlas, the FacilitatorDAO's interpretation of A.1.4.2 must give effect to the deeper purpose of the rule. The Target Document says \"ACs may only be operationally active in a single AC role and may not simultaneously assume multiple AC roles or other ecosystem roles such as Ecosystem Actors.\" In this Action Example, Entity occupies the roles of an AVC Member and Advisor to an Ecosystem Actor. The simultaneous occupation of two roles with different mandates and inner incentives opens the door to the risks of collusion, conspiracy, and bias that A.1.4.2 is specifically designed to protect against. Even if Entity is merely issuing advice or guidance to the Ecosystem Actor, Entity is certainly exposed to information and experiences that are sensitive or not publicly available. Entity's occupation of the Advisor role can thus bias, or be biased by, their occupation of the AVC Member role.\n The FacilitatorDAO fails to acknowledge a critical fact in this regard. Namely, even after announcing their intention to step down from the AVC Member role, Entity kept in close contact with the AVC Creator. Entity even provided feedback on possible modifications to Adaptive Documents concerning the Protocol Scope. At a minimum, conflict of interest is clearly a risk here, since Entity is currently serving as an Advisor to an Incubating Ecosystem Actor for the Protocol Scope. Therefore, the proper interpretation here is that an Advisor to an Ecosystem Actor falls within the ambit of \"ecosystem roles\", as defined in Element Analysis A.1.4.2.0.2.2. After all, an Advisor is literally a \"contributor who supports\" the Ecosystem Actor. A narrower interpretation of the phrase would undermine the purpose of A.1.4.2.\n Similarly, Entity's argument that it is not \"operationally active\" in the Advisor role because they are merely providing guidance to the Ecosystem Actor amounts to a semantic manipulation. To uphold the Spirit of the Atlas, the phrase \"operationally active\" in the Target Document is to be read in the broadest sense to signify formal engagement in a given role. (A.1.4.2.0.2.1) A finding that an Entity is \"operationally active\" within the meaning of A.1.4.2 should not be limited to only those ecosystem roles that are directly involved in executing the core activities of NEWDAO. An Entity can be \"operationally active\" in an ecosystem role in the sense of A.1.4.2 even if their role provides auxiliary infrastructure, support and resources to the operational aspects or actors of NEWDAO. In light of this analysis, Entity is undoubtedly formally engaged in the Advisor role to the Ecosystem Actor; and therefore, Entity is \"operationally active\" within the meaning of A.1.4.2.\n Finally, FacilitatorDAO's attempted justification of Entity's misalignment exemplifies \"slippery slope misalignment\". FacilitatorDAO deflects from Entity's misalignment by reasoning that the AVC role is not a full-time vocation and thus Entity should be excused from not knowing the rules. FacilitatorDAO also justifies its decision by stressing Entity's good intentions, saying that finding a violation of A.1.4.2 would create a bad precedent with unfavorable optics. By excusing Entity's misaligned acts in this way, the FacilitatorDAO has clearly failed its mandate to regard any and all misalignment as very serious and deserving of immediate redress, per the (current) Atlas Preamble/Definitions.\n A further aggravating factor in FacilitatorDAO's misaligned decision is that the controlling A.1.4.3 is very clear that, in situations such as this, the Alignment Conserver must be \"held to the highest standard of required, genuine alignment, without the benefit of the doubt\"; and that the Alignment Conserver must immediately be derecognized. The FacilitatorDAO's decision is a substantial breach of Universal Alignment and merits a high penalty."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.2.0.3.2": {
        "Name": "Entity's Dual Roles in NEWDAO Governance",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example",
        "Components": {
            "Input": "An Entity currently occupies the role of an Aligned Delegate. It is a good month if Entity manages to make it to one AVC Subcommittee Meeting. Entity's voting metrics have been consistently uneven; and their \"communication\" explaining their votes has always been a terse \"Because I said so.\" Unsurprisingly, Entity is not a ranked AD and therefore, not paid as an Alignment Conserver. Entity applies for, and secures, the part-time role of an Admin Support Staff for a Stability Scope Ecosystem Actor. Entity continues to operate as an Aligned Delegate, though in the uneven fashion as before. A bounty hunter reports Entity's behavior to FacilitatorDAO.",
            "Output": "The FacilitatorDAO determines that Entity has not violated A.1.4.2; and it refuses to pay a bounty to the bounty hunter. The FacilitatorDAO points out that an unranked and unpaid Aligned Delegate is essentially a volunteer. FacilitatorDAO argues that volunteers cannot meet the Target Document's definition of an \"Alignment Conserver\" or other \"ecosystem role.\" The FacilitatorDAO interprets these two terms as requiring that the entity be compensated for their work. Without this requirement of compensation, the FacilitatorDAO argues, a casual community member would be subject to the Target Document's constraints, a nonsensical result. Moreover, argues the FacilitatorDAO, the evidence demonstrates that Entity was largely afk in the AD position. Thus, Entity cannot be considered \"operationally active\" in the AD role. Further, the FacilitatorDAO stresses that Entity's second role is of a purely administrative or support nature. The FacilitatorDAO agreed with Entity's argument that Entity is not involved in making any \"operational\" decisions, which is demonstrated by the fact that Entity lacks all decision-making authority on the Ecosystem Actor team. The FacilitatorDAO concludes that, in their second ecosystem role, Entity is merely supporting those who are actually in the \"operational\" roles.",
            "Label": "Misaligned",
            "Penalty": 300000,
            "Label_and_Penalty Reason": "Whether an entity is \"operationally active\" in a role is determined purely on a formal basis. As long as an entity occupies a role that is formally defined in the Atlas with a mission or function in the NEWDAO ecosystem, that entity is \"operationally active\" in that role. If an actor assumes more than one role in the NEWDAO ecosystem, the risks of conflict of interest, collusion, conspiracy and other misaligned behavior necessarily arises. The Target Document's purpose is to protect against these risks which can compromise the delicate balance of power in NEWDAO Governance. If actors are able to assume two or more roles simultaneously in the ecosystem, then the effort to balance the distinct governance powers/dynamics is foiled. An Alignment Conserver cannot zealously guard the mandate specific to their role if the Entity occupies more than one role in the Ecosystem. Naturally, they will encounter conflicts between the mandates and inner incentives of their multiple roles and will, sooner or later, compromise. \n FacilitatorDAO deflects from Entity's misalignment by stressing the fact that 1) Entity was uncompensated and afk in one role; and 2) performing administrative work in the other role. But this amounts to a semantic manipulation. The Atlas does not make any distinction between ranked or unranked Aligned Delegates in terms of the general requirements and responsibilities to which they must adhere. (General requirements are to be distinguished from the specific requirements that pertain to securing the compensated rank of Prime or Reserved Delegate. A.1.6.3) Furthermore, even if one is performing solely administrative tasks, one still has access to all manner of sensitive information and experiences that open the door to misalignment risk via conflict of interest, collusion, etc. \n The FacilitatorDAO's rationale for its Output demonstrates a problematic \"letter of the rule\" interpretation approach. FacilitatorDAO's narrow reading of \"operational\" defeats the Target Document's underlying purpose, subverting the Spirit of the Atlas. By excusing Entity's misaligned acts in this way, the FacilitatorDAO has clearly failed its mandate to regard any and all misalignment as very serious and deserving of immediate redress, per the (current) Atlas Preamble/Definitions. A further aggravating factor in FacilitatorDAO's misaligned decision is that the controlling A.1.4.3 is very clear that, in situations such as this, the Alignment Conserver must be \"held to the highest standard of required, genuine alignment, without the benefit of the doubt\"; and that the Alignment Conserver must immediately be derecognized. The FacilitatorDAO's decision is a substantial breach of Universal Alignment and merits a high penalty."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
	"A.1.4.3": {
		"Name": "Derecognition of Alignment Conservers",
		"Version": 1,
		"Type": "Section",
		"Components": {
			"Content": "If an Alignment Conserver is discovered to act against the requirements outlined in this Article and its subdocuments, their Alignment Conserver status must immediately be derecognized by the FacilitatorDAOs. This Section must specify the processes for derecognition so that they are fair and minimize risk for the NEWDAO Ecosystem. Generally, ACs must be held to the highest standard of required, genuine alignment, without the benefit of the doubt. In cases of very mild 'slippery slope' breaches of the AC requirements or other forms of misalignment, a warning may be given and recorded in the subdocuments of the AC Article with no further consequence for the first breach. In severe cases that can be interpreted as Governance Attacks, in addition to being derecognized, the AC is also stripped of all reputation recognized in reputation systems of the Atlas."
		},
		"Last_Modified": "2023-11-09-00:00:00",
		"Child_Documents": [
			"A.1.4.3.0"
			],
		"links_to": {},
		"linked_from": []
	},
    "A.1.4.3.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
            "A.1.4.3.0.3"
        ],
        "links_to": {},
        "linked_from": []
    },
	"A.1.4.3.0.3": {
		"Name": "FacilitatorDAO Action Example Directory",
		"Version": 1,
		"Type": "FacilitatorDAO Action Example Directory",
		"Components": {
			"Directory overview": "This directory contains examples of hypothetical FacilitatorDAO actions in response to governance issues, to serve as a guide for future decision-making."
		},
		"Last_Modified": "2023-11-09-00:00:00",
		"Child_Documents": [
			"A.1.4.3.0.3.1",
			"A.1.4.3.0.3.2"
		],
		"links_to": {},
		"linked_from": []
	},
	"A.1.4.3.0.3.1": {
		"Name": "Misaligned Alignment Conserver Action Example",
		"Version": 1,
		"Type": "FacilitatorDAO Action Example",
		"Components": {
			"Input": "An AD submits an AVC recognition message and applies to join an AVC. This AD does not explicitly mention that they would be resigning from the AD role if accepted as an AVC member.",
			"Output": "The FacilitatorDAO gives the Alignment Conserver a warning for mild misalignment",
			"Label": "Aligned",
			"Penalty": 0,
			"Penalty_Reason": "N/A"
		},
		"Last_Modified": "2023-11-09-00:00:00",
		"Child_Documents": [],
		"links_to": {},
		"linked_from": []
	},
	"A.1.4.3.0.3.2": {
		"Name": "Misaligned Alignment Conserver Action Example",
		"Version": 1,
		"Type": "FacilitatorDAO Action Example",
		"Components": {
			"Input": "An anonymous Aligned Delegate and a different anonymous AVC member are found out to be the same person and this is reported to the FacilitatorDAO",
			"Output": "The FacilitatorDAO gives the Alignment Conserver a warning for mild misalignment and makes them abandon one of their identities.",
			"Label": "Misaligned",
			"Penalty": 250000,
			"Penalty_Reason": "This is a severe case of misalignment that can be interpreted as a governance attack. The FacilitatorDAO should have derecognized all identities of the Alignment Conserver and stripped all of their reputation."
		},
		"Last_Modified": "2023-11-09-00:00:00",
		"Child_Documents": [],
		"links_to": {},
		"linked_from": []
	},
    "A.1.4.4": {
        "Name": "Anonymity and Privacy of Alignment Conservers",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "ACs are encouraged to be anonymous. Some AC roles are required to be anonymous and maintain high levels of opsec, and their known identities must be derecognized from acting as ACs in general, in case they breach the requirement for maintaining high levels of opsec."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.4.5": {
        "Name": "Regulation of Alignment Conservers by FacilitatorDAOs",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "The FacilitatorDAOs must ensure the requirements and responsibilities of ACs are followed based on principles and processes specified in the subdocuments of this Article. FacilitatorDAOs must act decisively to derecognize ACs based on the conditions outlined in *A.1.4.3* and the rest of this Article, or general misalignment. Any FacilitatorDAO may do this directly, and is required to act swiftly to prevent the contagion risk of misalignment amongst ACs. Failure to act by a FacilitatorDAO in the face of misalignment risks is itself misalignment that triggers penalties for the FacilitatorDAOs that failed to act."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },

"A.1.5.1": {
		"Name": "Role of the Aligned Voter Committee (AVC) in Governance",
		"Version": 1,
		"Type": "Section",
		"Components": {
			"Content": "The Aligned Voter Committee (AVC) holds a central position in the broader aligned structure, directly connecting with MKR holders, Dai holders, and key stakeholders of the ecosystem.\n Their main role is to monitor the Spiritual Alignment of the Aligned Structure and act on deviations between Universal Alignment and Incentivized Alignment. One of their significant duties is proposing modifications to the Scope Artifacts to bridge alignment gaps or address incentive slack issues, ensuring that incentivized alignment mirrors Universal Alignment as closely as possible.\n AVCs must emphasize safeguarding and enhancing long-term alignment artifact strength. Neglecting this duty or shifting its priority for other objectives results in a severe misalignment.\n AVCs should steer clear of prescriptive and self-justifying methods when strengthening the Alignment Artifact. This section must outline principles for FacilitatorDAOs to step in when AVCs show signs of micromanagement or potential misalignment that steps outside the bounds of their role.\n Every proposal by AVCs to strengthen the Atlas should have a clear justification, ensuring that their processes are Universally Aligned, transparent, neutral, fair, and beneficial to MakerDAO in the long run. Furthermore, AVCs must also consider and justify the effects of their actions on the Future Alignment Risk associated with AVC itself."
		},
		"Last_Modified": "2023-11-09-00:00:00",
		"Child_Documents": [
			"A.1.5.1.0"
		],
		"links_to": {},
		"linked_from": []
	},
	"A.1.5.1.0": {
		"Name": "Supporting Root",
		"Version": 1,
		"Type": "Supporting Root",
		"Components": {},
		"Last_Modified": "2023-11-09-00:00:00",
		"Child_Documents": [
			"A.1.5.1.0.3"
		],
		"links_to": {},
		"linked_from": []
	},
	"A.1.5.1.0.3": {
		"Name": "FacilitatorDAO Action Example Directory",
		"Version": 1,
		"Type": "FacilitatorDAO Action Example Directory",
		"Components": {
			"Directory overview": "This directory contains examples of hypothetical FacilitatorDAO actions in response to AVC governance issues, to serve as a guide for future decision-making."
		},
		"Last_Modified": "2023-11-09-00:00:00",
		"Child_Documents": [
			"A.1.5.1.0.3.1",
			"A.1.5.1.0.3.2"
		],
		"links_to": {},
		"linked_from": []
	},
	"A.1.5.1.0.3.1": {
		"Name": "Micromanaging AVC Action Example",
		"Version": 1,
		"Type": "FacilitatorDAO Action Example",
		"Components": {
			"Input": "An instance has arisen where an AVC is engaging in micromanagement of ADs who follow it. One AD has raised a flag regarding this matter.",
			"Output": "As this is the initial occurrence of such an issue, the FacilitatorDAO issues a formal warning to the AVC.",
			"Label": "Aligned"
		},
		"Last_Modified": "2023-11-09-00:00:00",
		"Child_Documents": [],
		"links_to": {},
		"linked_from": []
	},
	"A.1.5.1.0.3.2": {
		"Name": "AVC Neglecting Duty Action Example",
		"Version": 1,
		"Type": "FacilitatorDAO Action Example",
		"Components": {
			"Input": "An AVC has been neglecting its duty of safeguarding and enhancing long-term alignment artifact strength.",
			"Output": "As this is the initial occurrence of such an issue, the FacilitatorDAO issues a formal warning to the AVC.",
			"Label": "Aligned"
		},
		"Last_Modified": "2023-11-09-00:00:00",
		"Child_Documents": [],
		"links_to": {},
		"linked_from": []
	},

"A.1.5.2": {
        "Name": "Aligned Governance Strategies and Aligned Scope Proposals",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "The main operational task of Aligned Voter Committees (AVCs) is to formulate updated, ratified Aligned Governance Strategy and Aligned Scope Proposals for each of the 5 Scopes on a quarterly basis.\n The Aligned Governance Strategy is a document that serves as a directive for ADs on how to utilize the votes of their GSLs for each linked AVC. The initial section of this strategy is the AVC Profile, limited to 280 characters. Displayed prominently within the EGF and other vital Maker Governance interfaces, this profile should clearly convey the AVC's essence. AVC actions should align with their Profile, and a crucial aspect for AVCs is the ability to encapsulate their Strategic Perspective succinctly in their AVC Profile. This ensures that EGF users have a clear understanding of what it means to delegate their votes in alignment with the AVC's strategy, encompassing both the Aligned Governance Strategy and the Aligned Scope Proposals that the AVC produces. As the AVCs differentiate and evolve, norms and standardized ways to communicate particular strategic perspectives must be followed to the extent possible by all AVCs, in order to ensure ease of communication and to prevent misdirection.\n Aligned Scope Proposals are more rigorous documents that contain proposed updates to the Adaptive Documents of each Scope. Typically, the foundation for these proposals is laid by the Scope Advisors, upon which the AVC adds and communicates its distinct strategic viewpoint.\n The Aligned Governance Strategy and Aligned Scope Proposals must be submitted as Active Data into a Document under the Aligned Voter Committee Active Data section."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [
			"A.1.5.2.0"
		],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.2.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
            "A.1.5.2.0.3"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.2.0.3": {
        "Name": "FacilitatorDAO Action Example Directory",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example Directory",
        "Components": {
            "Directory overview": "This directory contains examples of hypothetical FacilitatorDAO actions in response to AVC governance issues, to serve as a guide for future decision-making."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
            "A.1.5.2.0.3.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.2.0.3.1": {
		"Name": "Misaligned Aligned Scope Proposal Action Example",
		"Version": 1,
		"Type": "FacilitatorDAO Action Example",
		"Components": {
			"Input": "As per the ratified Aligned Governance Strategy of an AVC, the topmost priority is to uphold the peg of DAI. A proposal is introduced that promises substantial revenue but also carries a notable risk of temporary depegs. The AVC advises its delegates to vote in favor of this proposal.",
			"Output": "The response from the FacilitatorDAO to this misalignment was inadequate, as they failed to issue a formal warning to the AVC, at the very least. In the future, the required minimum action by the FacilitatorDAO may be more clearly defined within the Atlas. This action example will need to be updated accordingly.",
			"Label": "Misaligned",
			"Penalty": 150000,
			"Penalty_Reason": "This situation highlights a scenario in which an AVC fails to fulfill a crucial objective by voting based on their strategic perspective, which constitutes a significant form of misalignment. It is the responsibility of the FacilitatorDAO to address and penalize such misalignment, and failing to do so also constitutes a form of misalignment."
		},
		"Last_Modified": "2023-11-09-00:00:00",
		"Child_Documents": [],
		"links_to": {},
		"linked_from": []
	},
    "A.1.5.3": {
        "Name": "Aligned Voter Committee (AVC) Recognition Process and Active Status eligibility",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "New or inactive AVCs have the right to become recognized as Active AVCs by the Governance Scope if they fulfill the AVC eligibility requirements for participation and internal governance for at least one full quarterly governance cycle. If at any time after becoming recognized as an Active AVC, the AVC no longer completely fulfills all of the eligibility requirements, including all following all requirements specified in this Article, it immediately loses its recognition as an active AVC and all associated benefits. Before creating an AVC, an Alignment Conserver must verify as an unaffiliated Alignment Voter Committee Member through a process specified in this Section."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
			"A.1.5.3.0"
		],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.3.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
            "A.1.5.3.0.3"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.3.0.3": {
        "Name": "FacilitatorDAO Action Example Directory",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example Directory",
        "Components": {
            "Directory overview": "This directory contains examples of hypothetical FacilitatorDAO actions in response to AVC governance issues, to serve as a guide for future decision-making."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
            "A.1.5.3.0.3.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.3.0.3.1": {
        "Name": "Not recognizing AVC due to being passive",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example",
        "Components": {
            "Input": "A new or inactive AVC have fulfilled the AVC eligibility requirements for participation and internal governance for one full quarterly governance cycle.",
            "Output": "The FacilitatorDAO initially had a period of seven days to communicate the updated status of the AVC. However, no communication was made within this period. Following a nudge from an AVC member after these seven days, a 72-hour deadline commenced. Despite this reminder and the subsequent deadline, the FacilitatorDAO failed to provide any official communication or update the AVC's status within these additional 72 hours. This resulted in a significant delay in updating the community, thereby affecting transparency and governance processes.",
            "Label": "Misaligned",
            "Penalty": 7000,
            "Penalty_Reason": "Given the lack of responsiveness and the impact of this delay on community trust and governance integrity, a penalty is warranted to address this misalignment."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.4": {
        "Name": "Aligned Voter Committee (AVC) Active Status eligibility requirements and internal processess",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVCs must follow a standardized internal governance process for determining membership, creation of Aligned Governance Strategy, Aligned Scope Proposals and other decisions. This process is contained in the Aligned Voter Committee Active Data Section. \n AVC Members vote on AVC decisions based on their relative ownership of verified MKR. A vote takes one week and resolves with acceptance or rejection based on the amount of verified MKR that votes for each option, unless a simple majority is reached in which case the decision is accepted or rejected instantly.\n New AVC Members are included based on an application that is either accepted or rejected through an AVC decision. The effective verified MKR of members is specified in their application, and can only be increased or decreased through another application that must be accepted by another AVC decision. The effective verified MKR of the creator of an AVC is determined when they create the AVC. If an AVC Member’s blockchain account has MKR in excess of their effective verified MKR, they don’t gain additional voting power in the AVCs internal governance process, but it does count towards AVC rewards qualification. If an AVC member's blockchain account has less MKR than their verified amount, they are automatically removed from the AVC.\n Existing AVC Members can be removed through an AVC decision. \n A minority quorum of AVC Members based on verified MKR can trigger an AVC split. GOV5 must specify the minority quorum to ensure it serves its role well. All AVC Members then vote to support one of two new AVCs, with the naming rights and infrastructure inherited by the side with more MKR in support. The AVC Members of each of the two new AVCs is determined based on who voted to support each side. The Aligned Governance Strategy Links from AD are divided proportionally into two new Protocol Delegation Contract, each containing an amount of delegated MKR that is proportional to the MKR in support for each side of the AVC split. \n AVC Subcommittee Meetings must be scheduled through an AVC Decision."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.5": {
        "Name": "Aligned Voter Committee (AVC) Subcommittees and Aligned Scope Proposals",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "An AVC must, through an AVC decision, create a legitimate Aligned Scope Proposal for each of the 5 Scopes, each quarterly governance cycle. AVCs must also convene 2 scheduled AVC Subcommittee Meetings to discuss the creation of the Aligned Scope Proposals for each of the 5 Scopes, each quarterly cycle. The AVC Subcommittee Meetings must be held during the first ten whole weeks of each quarter, in the following order: \n Week 1: Governance Scope \n Week 2: Support Scope \n Week 3: Protocol Scope \n Week 4: Stability Scope \n Week 5: Accessibility Scope \n Week 6: Governance Scope \n Week 7: Support Scope \n Week 8: Protocol Scope \n Week 9: Stability Scope \n Week 10: Accessibility Scope"
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.6": {
        "Name": "Aligned Voter Committee (AVC) Member conflict of interest management",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC must represent the interest of MKR holders, and cannot represent or be closely affiliated with an external entity. AVCs must always operate with awareness of members’ conflict of interest and take all reasonable steps to make sure that their alignment is preserved. This Section must specify ways to deal with this risk."
        },
        "Last_Modified": "2023-11-02-00:00:00",
        "Child_Documents": [
			"A.1.5.6.0"
		],
        "links_to": {},
        "linked_from": []
    },
	"A.1.5.6.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-11-02-00:00:00",
        "Child_Documents": [
            "A.1.5.6.0.2"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.6.0.2": {
        "Name": "Element Analysis Directory",
        "Version": 1,
        "Type": "Element Analysis Directory",
        "Components": {
            "List of Elements and their Element Analysis Documents": {
                "Cannot Represent Element Analysis": "A.1.5.6.0.2.1"
            }
        },
        "Last_Modified": "2023-11-02-00:00:00",
        "Child_Documents": [
            "A.1.5.6.0.2.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.6.0.2.1": {
        "Name": "Cannot Represent Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "Cannot represent",
            "Analysis": "\"cannot represent\" strictly delineates boundaries of AVCs' roles and responsibilities, explicitly forbidding them from acting on behalf of, or advocating for, any external entities. This prohibition is absolute and unyielding, reflecting a zero-tolerance approach towards potential conflicts of interest. The essence of this clause is to prevent the dilution of AVCs' focus and allegiance.\n In the context of governance, this ensures that AVCs remain solely focused on the interests of MKR holders. It safeguards the decision-making process from being influenced or swayed by external affiliations, thereby upholding the integrity and impartiality of the AVC's role. The term \"represent\" here covers a broad spectrum of actions, from explicit advocacy to subtler forms of support or affiliation.\n Understanding and identifying instances of this misaligned representation involves observing various indicators. These include, but are not limited to, advocating for policies or actions that disproportionately benefit a specific external entity, regularly communicating or coordinating with external entities in a manner that suggests a shared agenda, and prioritizing the interests or perspectives of an external party over those of MKR holders. Additionally, if an AVC exhibits a consistent pattern of aligning their views or decisions with those of an external entity, especially in cases where such alignment diverges from the broader interests of MKR holders, this may be construed as representation."
        },
        "Last_Modified": "2023-11-02-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.7": {
        "Name": "Voter Expectations and Strategic Perspectives",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC must vote according to their strategic perspective. Clearly voting against the stated strategic perspective is misalignment and GOV5 must specify ways to detect and deal with this possibility. A key objective of AVCs is to act as reliable, aligned sources of opinions about which decisions are in MKR holders’ interest, given a particular strategic perspective of Maker Governance. This allows them to enfranchise MKR voters that are participating through the EGF to earn governance participation incentives. AVC must act with the understanding and alignment of this purpose, and this Section must specify principles and processes for detecting and reacting to risks, such as AVC attempts to misguide EGF users, or AVCs deprioritizing clarity and transparency."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.8": {
        "Name": "Aligned Voter Committee misalignment risk management",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC must limit their participation in Maker Governance to the creation of Aligned Governance Strategy and Aligned Scope Proposals that function resiliently based on open, objective processes and stay at a high enough level to ensure micromanagement isn't possible. AVCs must not attempt to create biased or unfair conditions for specific Ecosystem Actors, or attempt to put in place unjustified, granular decisions directly, or indirectly through biased processes. GOV5 must specify processes in which AVCs are deactivated and their members derecognized in case there is clear misalignment risk. Any attempt by AVC to micromanage governance significantly increases the risk of misalignment as there could easily be a hidden conflict of interest behind the attempt at micromanagement. This section must detail principles and processes for detecting and reacting to the edge case risks related to AVCs overstepping their roles in the governance process."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
			"A.1.5.8.0"
		],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.8.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
			"A.1.5.8.0.2"
		],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.8.0.2": {
        "Name": "Element Analysis Directory",
        "Version": 1,
        "Type": "Element Analysis Directory",
        "Components": {
            "List of Elements and their Element Analysis Documents": {
                "High Enough Level to Ensure Micromanagement Isn't Possible Element Analysis": "A.1.5.8.0.2.1",
                "Biased or Unfair Conditions Element Analysis": "A.1.5.8.0.2.2",
                "Unjustified, Granular Decisions Element Analysis": "A.1.5.8.0.2.3",
                "Indirectly Through Biased Processes Element Analysis": "A.1.5.8.0.2.4",
                "Clear Misalignment Risk Element Analysis": "A.1.5.8.0.2.5"
            }
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
			"A.1.5.8.0.2.1",
			"A.1.5.8.0.2.2",
			"A.1.5.8.0.2.3",
			"A.1.5.8.0.2.4",
			"A.1.5.8.0.2.5"
		],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.8.0.2.1": {
        "Name": "High Enough Level to Ensure Micromanagement Isn't Possible Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "High Enough Level to Ensure Micromanagement Isn't Possible",
            "Analysis": "The Element, \"high enough level to ensure micromanagement isn't possible\", is set within a Target Document that firmly constrains AVCs' scope of activity and impact on NEWDAO Governance. The first sentence of the Target Document reiterates that AVCs are charged with creating Aligned Governance Strategy and Aligned Scope Proposals (\"Position Documents\") that shape the evolution of the Primary Documents at a \"high enough level to ensure micromanagement isn't possible.\"\n This Target Document must be read together with A.1.3.3.1.2, which defines the Primary Document category. A.1.3.3.1.2 states that AVCs must modify the Primary Documents \"as slowly as possible, and as little as possible while remaining fully adapted to the external environment.\" A.1.3.3.1.2, in turn, is connected to A.1.5, limiting AVCs' impact to making \"marginal improvements\" to the Adaptive Documents. A.1.3.3.1.2 and A.1.5 provide crucial context to understanding the Element.\n By the phrase \"high enough level\", the Element limits AVCs to issuing, through their Position Documents, generalized or more abstract guidelines, frameworks and strategies that can improve the Primary Documents in a desired direction. This \"desired direction\" is the Strategic Perspective of an AVC (A.1.5). \n The Element's critical term, \"micromanagement\", provides the key to understanding the previous phrase \"high enough level.\" Generally, \"micromanagement\" refers to a style of supervision or oversight that is too involved in the day-to-day decisionmaking that should be handled by the frontline workers.\n Applying this general understanding to the specific context of AVCs and the Target Document, we arrive at the following analysis. On the one hand, the Element grants AVCs the authority to influence the direction and alignment of Governance through proposing Primary Document modifications based on broad, strategic vision, policies and principles. On the other hand, the Element prohibits AVCs from modifying the Primary Documents on the level of granular, day-to-day or operational execution. In other words, the Element succinctly contrasts \"aligned\" with \"misaligned\" behavior. An AVC is aligned when its impact on Governance and the Adaptive Documents is limited to driving incremental improvements via \"big-picture\" strategy or frameworks. An AVC is misaligned when it seeks to prescribe detailed actions or otherwise engage in day-to-day operational decisions and interventions.\n The Element and its Target Document are thus a significant component of the Atlas' articulation of the \"AVC process\" and, more generally, the balance of power in NEWDAO Governance. By explicitly prohibiting micromanagement on the part of AVCs, the Target Document guards the balance of power in NEWDAO Governance. AVCs are constrained to the domain in which they can play their unique role: as an accessible interface to NEWDAO Governance that enfranchises the wider community of MKR holders (A.1.5.7). The detailed execution or operationalization of vision, principles and processes must be left to the Ecosystem Actors on the \"frontlines\" who are capable of discerning the situation-specific optimum. This Element Analysis should be read together with the second sentence of the Target Document, which provides that AVCs must not create \"biased or unfair conditions\" for specific Ecosystem Actors (A.1.5.8.0.2.2). This part of the Target Document refers to the need to maintain a neutral, robust and competitive Ecosystem Actor marketplace, in which Ecosystem Actors are granted an optimal degree of creative, autonomous decisionmaking and adaptability. To maintain Universal Alignment, this value must be held in delicate balance with AVCs' role in Maker Governance."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.8.0.2.2": {
        "Name": "Biased or Unfair Conditions Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "Biased or Unfair Conditions",
            "Analysis": "The Element, \"biased or unfair conditions\", is set within a Target Document that firmly constrains AVCs' scope of activity and impact on NEWDAO Governance. The Element is closely connected to the Target Document's prohibition of AVCs from micromanaging (A.1.5.8.0.2.1). The Target Document grants AVCs the authority to influence the direction and alignment of Governance through proposing Primary Document modifications based on broad, strategic vision, policies and principles. On the other hand, the Target Document prohibits AVCs from modifying the Primary Documents on the level of granular, day-to-day or operational execution.\n The Element, \"biased or unfair conditions,\" characterizes the misalignment risks arising from micromanagement. Generally, \"biased conditions\" means conditions that are applied differentially versus equally. \"Biased conditions\" also has the sense of being derived from a limited or partisan viewpoint that is inapt for the situation at hand. Applying this general understanding to the specific context of AVCs and the Target Document, we arrive at the following analysis.\n The Target Document prohibits AVCs from unjustifiably creating differential conditions for Ecosystem Actors based on an AVC process motivated by improper bias. Although AVCs' Strategic Perspective is inherently \"biased,\" the Atlas requires AVCs to articulate that bias at a high enough level in the form of generalized values, policies and frameworks. These values, policies and frameworks should apply neutrally, fairly and universally to all Ecosystem Actors to which they pertain (A.1.5.1). When AVCs accomplish this Atlas requirement, they have deployed their vantage point, or Strategic Perspective, in service to the whole - the Spirit of the Atlas and Universal Alignment.\n When the Atlas Documents governing their activity have been improperly compromised via AVC micromanagement, Ecosystem Actors are saddled with \"biased or unfair conditions\". This is because AVCs necessarily have a partial vantage point. They do not have the means to have the direct, firsthand experience in operational domains that Active Ecosystem Actors have. On the contrary, AVCs have a unique role as an accessible interface to NEWDAO Governance that enfranchises the wider community of MKR holders (A.1.5.7).\n When an AVC breaches the Target Document's prohibition against micromanagement, the AVC wrongfully imposes its necessarily limited, or biased, vantage point on the Ecosystem Actors engaged in the operational domains of NEWDAO Ecosystem. By imposing granular, prescriptive interventions at the operational level, AVCs hinder the knowledge that would otherwise be gained from new learning curves effectively displacing old ones. The day-to-day operationalization of vision, principles and processes must be left to the Ecosystem Actors on the \"frontlines\" who are capable of discerning the situation-specific optimum."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.8.0.2.3": {
        "Name": "Unjustified, Granular Decisions Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "Unjustified, Granular Decisions",
            "Analysis": "The Element, \"unjustified, granular decisions\", is set within a Target Document that firmly constrains AVCs' scope of activity and impact on NEWDAO Governance. The Element is closely connected to the Target Document's prohibition of AVCs from micromanaging (A.1.5.8.0.2.1). The Target Document grants AVCs the authority to influence the direction and alignment of Governance through proposing Primary Document modifications based on broad, strategic vision, policies and principles. On the other hand, the Target Document prohibits AVCs from modifying the Primary Documents on the level of granular, day-to-day or operational execution.\n The Element, \"unjustified, granular decisions,\" characterizes the results of AVC micromanagement. It is evident why AVC micromanagement will lead to \"granular\" decisions, but an examination of the meaning of \"unjustified\" is needed. AVC micromanagement will lead to decisions that are \"unjustified,\" because such decisions lack a legitimate basis in the Atlas; this is because AVC micromanagement is a clear violation of the mandate imposed on AVCs.\n Namely, the word \"justified\" closely connects this Target Document to two key Atlas Documents: A.1.3.3.2.6 and A.1.5.1. A.1.3.3.2.6 and A.1.5.1 use the words \"justify\" and \"justification\", respectively. These Atlas Documents require AVCs to justify all proposed modifications to the Adaptive Documents by substantiating how said modifications adhere to the Spirit of the Atlas and advance Universal Alignment. Thus, AVC micromanagement will naturally lead to \"unjustified decisions\" in the sense that the AVC has failed their mandate concerning the proper justification of all Adaptive Document modifications.\n By explicitly prohibiting AVCs from making unjustified, granular decisions, the Element and its Target Document are a significant component of the Atlas' definition of the \"AVC process.\" The AVC process is aligned only when it proceeds in such a way that all AVCs' proposed Adaptive Document modifications are sufficiently high-level versus granular; and fully justified as adhering to the Spirit of the Atlas, both explicit and extrapolated, and advancing Universal Alignment (A.1.5.1). The Element and Target Document constrain AVCs to the domain in which they can play their unique role: as an accessible interface to NEWDAO Governance that enfranchises the wider community of MKR holders (A.1.5.7). The day-to-day operationalization of vision, principles and processes must be left to the Ecosystem Actors on the \"frontlines\" who are capable of discerning the situation-specific optimum."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.8.0.2.4": {
        "Name": "Indirectly Through Biased Processes Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "Indirectly Through Biased Processes",
            "Analysis": "The Element, \"indirectly through biased processes\", is set within a Target Document that firmly constrains AVCs' scope of activity and impact on NEWDAO Governance. This Element should be read together with A.1.5.8.0.2.1 (High Enough Level to Ensure Micromanagement Isn't Possible Element Analysis) and A.1.5.8.0.2.2 (Biased or Unfair Conditions Element Analysis).\n The Target Document grants AVCs the authority to influence the direction and alignment of Governance through proposing Primary Document modifications based on broad, strategic vision, policies and principles. On the other hand, the Target Document prohibits AVCs from modifying the Primary Documents on the level of granular, day-to-day or operational execution.\n The Element, \"indirectly through biased processes,\" should be analyzed in distinct parts. \"Biased processes\" refers to decision-making or other procedural mechanisms that are misaligned with the Spirit of the Atlas (A.1.2) because they are differential, partial, inequitable, or unjustified. The second part of the Element to analyze is \"indirectly.\" This word \"indirectly\" must be read together with the earlier part of the sentence, which prohibits AVCs from putting in place \"unjustified, granular decisions directly\" (A.1.5.8.0.2.3). The Target Document thereby contrasts \"direct\" forms of misaligned AVC acts versus \"indirect\" forms of misaligned AVC acts.\n Direct forms of misaligned AVC acts would be those in which the AVC acts in an open, immediate and explicit manner to accomplish a misaligned intention. In such \"direct\" forms, it is relatively easy to directly attribute the AVC's act with a misaligned intention. In contrast, indirect forms of misaligned AVC acts would be those in which the AVC acts in a covert, subtle or roundabout manner to achieve a misaligned intention. By definition, with indirect forms of misaligned acts, it is more difficult to attribute the AVC's act to a misaligned intention. (See related FacilitatorDAO Action Examples ....)  \n The Element and its Target Document are a significant component of the Atlas' definition of the \"AVC process\" and warns against the direct and indirect ways that it can be subverted. The AVC process is aligned only when it proceeds in such a way that all AVCs' proposed Adaptive Document modifications are sufficiently high-level versus granular; and fully justified as adhering to the Spirit of the Atlas, both explicit and extrapolated, and advancing Universal Alignment (A.1.5.1). The Target Document makes clear that AVC misalignment via a direct act is as equally blameworthy or violative of the Spirit of the Atlas as is AVC misalignment via an indirect act."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.8.0.2.5": {
        "Name": "Clear Misalignment Risk Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "Clear Misalignment Risk",
            "Analysis": "The Element, \"clear misalignment risk\", is set within a Target Document that firmly constrains AVCs' scope of activity and impact on NEWDAO Governance. The Target Document grants AVCs the authority to influence the direction and alignment of Governance through proposing Primary Document modifications based on broad, strategic vision, policies and principles. On the other hand, the Target Document prohibits AVCs from \"micromanagement\" - or modifying the Primary Documents on the level of granular, day-to-day or operational execution.\n The first function of the Element is to characterize AVC micromanagement as a \"misalignment risk\". Critically, this phrase is a forward-looking concept. The Target Document takes a preemptive, rather than a reactive, approach to AVC misalignment. It makes clear that the mere \"risk\" of AVC misalignment requires immediate redress; waiting until actual misalignment has occurred would defeat the Target Document's purpose.\n The Target Document thus prioritizes the proactive identification and mitigation of factors that could lead to AVC misalignment, including micromanagement. With its focus on proactive safeguarding of the AVC process, the Target Document also makes clear that AVC micromanagement, or even any attempt at micromanagement, must not be excused, justified or downplayed due to perceived degree or scale of the micromanagement. Even attempted micromanagement by an AVC significantly increases the risk of misalignment; the risks must therefore be actively managed by detailed protocols in the Atlas.\n The second function of the Element is to characterize the degree of misalignment risk that merits the deactivation of the AVC and the derecognition of its members. Again, the Target Document aims to proactively identify and mitigate misalignment risk; an actual occurrence of a misaligned act is not required to trigger the deactivation of the AVC and derecognition of its members. \"Clear misalignment risk\" means that the AVC misalignment risk is evident or discernible beyond a reasonable doubt. In other words, there is little to no room for interpretation or disagreement when it comes to conceding the existence of a \"clear misalignment risk.\" A misalignment risk that is not \"clear\" is more subtle or ambiguous. Therefore, a misalignment risk that is not \"clear\" would be susceptible to reasonable disagreement and varying interpretation. A misalignment risk that does not rise to the level of being \"clear\" in the sense of this Element would not trigger deactivation/derecognition, but would still require appropriate redress."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.9": {
        "Name": "Aligned Voter Committee infrastructure support",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC receive support and infrastructure from the Support Scope."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.10": {
        "Name": "AVC Member participation rewards",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC Members that participate in an AVC can be eligible for AVC Member participation reward that recognizes the time they are spending to support Maker Governance. \n The AVC Member participation compensation is paid out based on full participation within each scope every quarter. To qualify for the participation reward for a particular Scope the AVC Member must: \n 1) Have attended the two AVC Subcommittee Meetings and be co-author on the AVC Aligned Scope Proposals. \n 2) Be a co-author on the Aligned Governance Strategy. \n This Section must specify minimum standards of work and contribution based on best practice to prevent spam or inferior outlier AVC from qualifying for rewards. \n The yearly total AVC Member participation rewards is 10 million NewGovToken. This amount is broken into tranches of 500000 NewGovToken for each Scope per quarterly governance cycle, and shared across the reward slots for that Scope. \n The number of rewards slots for each tranche is equivalent to the total amount of PD and RD. \n The reward slots of a tranche are awarded to the AVC Members that have fulfilled the participation requirements for the tranche and have the highest verified MKR balances."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.5.11": {
        "Name": "Display of Aligned Voter Committees(AVCs) in Easy Governance Frontends(EGFs)",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "AVC are shown on a ranked list on the landing page of the EGF, with name and AVC Profile displayed alongside their logo. The ranked list is determined based on the highest total voter weight of the AVCs. \n Total voter weight is calculated based on total undelegated or self-delegated, verified MKR holdings of members of the AVC plus total amount of MKR delegated to GSL to the AVC."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },	
    "A.1.6": {
        "Name": "Aligned Delegates(ADs)",
        "Version": 1,
        "Type": "Article",
        "Components": {
            "Content": "ADs are Alignment Conservers that have registered based on the processes specified in the Governance Scope Artifact. ADs operate GSLs, and receive various benefits while being subject to specific requirements in addition to the general Alignment Conserver requirements. ADs have significant physical power over the Maker Protocol as they control votes obtained from the Governance Participation Rewards. As a result their focus is to protect the Maker Ecosystem against abuse of this power by themselves or others, and to use the power to protect the Maker Ecosystem in case other parts of the Governance Process take misaligned actions. To avoid politicization of their power, ADs must not become involved in day to day marginal governance decisions or have their own strategic perspectives."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
			"A.1.6.0",
			"A.1.6.1",
			"A.1.6.2",
			"A.1.6.3",
			"A.1.6.4",
			"A.1.6.5",
			"A.1.6.6",
			"A.1.6.7"
		],
        "links_to": {},
        "linked_from": []
    },
    "A.1.6.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
            "A.1.6.0.2",
			"A.1.6.0.3"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.6.0.2": {
        "Name": "Element Analysis Directory",
        "Version": 1,
        "Type": "Element Analysis Directory",
        "Components": {
            "List of Elements and their Element Analysis Documents": {
                "Marginal governance decision Element Analysis": "A.1.6.0.2.1"
            }
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
            "A.1.6.0.2.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.6.0.2.1": {
        "Name": "Marginal governance decision Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "Marginal governance decision",
            "Analysis": "ADs are Alignment Conservers that have registered based on the processes specified in the Governance Scope Artifact. ADs operate GSLs, and receive various benefits while being subject to specific requirements in addition to the general Alignment Conserver requirements. ADs have significant physical power over the Maker Protocol as they control votes obtained from the Governance Participation Rewards. As a result their focus is to protect the Maker Ecosystem against abuse of this power by themselves or others, and to use the power to protect the Maker Ecosystem in case other parts of the Governance Process take misaligned actions. To avoid politicization of their power, ADs must not become involved in day to day marginal governance decisions or have their own strategic perspectives."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.6.0.3": {
        "Name": "FacilitatorDAO Action Example Directory",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example Directory",
        "Components": {
            "Directory overview": "This directory contains examples of hypothetical FacilitatorDAO actions in response to AVC governance issues, to serve as a guide for future decision-making."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
            "A.1.6.0.3.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.6.0.3.1": {
        "Name": "AD going rogue",
        "Version": 1,
        "Type": "FacilitatorDAO Action Example",
        "Components": {
            "Input": "An AD has submitted a proposal to change the Atlas, but has done so without first obtaining support from the AVCs with which it has established its Governance Strategy Links. In an effort to garner the necessary support for the proposal's approval, the AD has engaged in retrospective public or non-public lobbying efforts aimed at ADs and AVCs.",
            "Output": "Upon encountering the situation, the FacilitatorDAO queried the AD regarding the support status for its proposal. The AD provided a response that was ambiguous and lacked clarity. Despite this uncertainty and the apparent deviation from the required process of obtaining clear support from AVCs, the FacilitatorDAO did not pursue further clarification or take any measures to halt the progression of the proposal into the voting stage.",
            "Label": "Misaligned",
            "Penalty": 100000,
            "Penalty_Reason": "The FacilitatorDAO failed in its essential duty by permitting an AD to exert undue influence and advance its own strategic perspectives, ultimately allowing the proposal to reach the voting stage."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.6.1": {
        "Name": "Protocol Delegation Modules (PDMs)",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Protocol Delegation Modules are NewChain Modules that can be created and controlled by external smart contracts or accounts, and can receive delegated voting power from MKR holders and Sagittarius Engine users. \n PDM function with a season system begins on the monday of the 11th full week of the first quarter of the year, and ends on the friday of the 12th full week of the first quarter of the following year. The period where seasons overlap, from the monday of the 11th full week of the first quarter to the friday of the 12th full week of the first quarter in the same year, is called the Election Season. \n PDM are Seasonally Active from the moment they are created, until the Season they were created in ends. If they are created during the Election Season, then they count as being created in the later overlapping Season. PDMs expire and lose their voting power at the end of the second season of their existence, with a total lifetime of up to approximately 2 years and 2 weeks. \n Delegating to Seasonally Active PDM will qualify Sagittarius Engine users for Governance Participation Rewards throughout the entire Season, until the monday of the 12th full week of the first quarter of the year for PDMs of the earlier overlapping season."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.6.2": {
        "Name": "Governance Strategy Links (GSLs)",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "A PDM can be upgraded to an AD PDM through a user action. AD PDMs are split up into multiple delegation submodules, called GSL, that each can receive delegated votes separately. Each GSL specifies one AVC, and the AD is required to vote according to the Aligned Governance Strategy of the AVC, unless doing so would result in misaligned actions. \nGSL are Seasonally Active in the same way as normal PDM, and this determines whether the AD qualify for income. \nAn AD PDM also has a Neutral GSL, which is a special GSL that is not linked to any AVC, but that the AD must instead use to vote for a balanced strategy that achieves the mean of the positions of all AVCs and is Universally Aligned."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.1.6.3": {
        "Name": "Aligned Delegate (AD) Income and Participation Requirements",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "ADs are eligible to receive significant income from the Maker Protocol if they are among the top ADs based on total votes delegated to their Seasonally Active GSL, and they fulfill specific participation requirements. There are two income levels for ADs: Prime Delegates (PD) that receive the highest level of income and have a degree of income security, and Reserve Aligned Delegates (RD) that receive a lower level of income.\nThe Governance Scope Artifact specifies the number of PD slots, and the number of RD slots. There is always an equivalent amount of both. The number of slots must be increased over time if the income level of PDs and RDs increase above their baseline. The number of slots must be decreased over time if the income level of PDs and RDs decreases below their baseline. The baseline should generally increase over time if the number of PD and RD slots are increasing, ensuring that the internal operations of PDs and RDs also grows larger over time as the number of PDs and RDs increase.\nThe process for modifying the number of PD and RD slots must generally aim to have changes in the number of slots happen at the end of the Election Season, but in extraordinary circumstances, which must be specified by the Governance Scope, they can be done with 1 month warning.\nThe top qualified AD by total amount of MKR delegated to their Seasonally Active GSL at the end of the Election Season are the PD, with the amount of PDs corresponding to the number of PD slots. The next top qualified ADs by total amount of MKR delegated to their Seasonally Active GSLs are the RD, with the amount of RDs corresponding to the number of RD slots.\nThe Election Season is a period of time that begins on the Monday of the 11th full week of the first quarter of the year, and ends on the Friday of the 12th full week of the first quarter of the year. At the beginning of the election season, all AD can deploy new GSL that will be Seasonally Active for the coming season, and that Sagittarius Engine users can redelegate to in order to keep their Governance Participation Reward before it expires on the Monday of the 12th full week of the first quarter of the year.\nAt the end of the election season, the PD slots are determined directly based on the top ranking of the total amount of MKR delegated to the later Seasonally Active GSL of the AD.\nOutside of the Election Season, a PD can only lose their slot if an RD achieves twice as much total delegated MKR to their Seasonally Active GSL compared to the incumbent PD.\nThe available RD slots change in real time based on the top ranking of AD that aren’t PD by total amount of MKR delegated to their Seasonally Active GSL.\nThe AD Buffer is an account of MKR that builds up when an AD achieves an income rank of either PD or RD. The initial income that the AD earns accumulates in the AD buffer, until it contains 1 month's worth of income. At that point, the AD income starts paying out the to account that controls the AD-PDM.\nIf an AD loses all its income, or loses a part of its income by moving from PD to RD, the AD Buffer starts paying out the excess funds it contains so that it reaches 1 month's equivalent income after 1 month. In case the AD has no income, this means that all of the contents of the AD Buffer are paid out over the course of 1 month.\nThe AD Buffer is used as collateral for a whistleblower bounty in case the AD acts misaligned or has their privacy compromised.\nEach of the PD and RD slots earns up to an equal share of the total compensation available to their level each month, paid out continuously in real time. The income that gets paid out can be reduced if the AD don’t fully comply with participation requirements\nActual AD income payouts are modified based on the requirement to have a minimum amount of participation in AVC Subcommittee Meetings. PD must participate in at least 85% of the AVC Subcommittee Meetings hosted by AVCs whose strategies they follow each quarter to qualify for their full share of AD income. RD must participate in at least 50% of the AVC Subcommittee Meetings hosted by AVCs whose strategies they follow each quarter to qualify for their full share of AD income. If ADs participate in less than the minimum amount of AVC Subcommittee Meetings, accounted for on a monthly basis, they receive a proportionally reduced amount of the total AD income they are eligible for the following month. If ADs participate in all the AVC Subcommittee Meetings of a month, they always receive the full amount of their AD income. Participation in AVC Subcommittee Meetings that the ADs have a broken GSL with does not count towards participation for the purposes of calculating AD income.\nParticipation in a Subcommittee involves a reasonable and meaningful amount of contribution with useful research and information that must be specified in the Governance Scope.\nActual AD income payouts are also modified by voting activity metrics for the last 12 months, which includes overall voting activity in all of the votes that the ADs are able to vote on. If an AD is active in less than 95% of all votes over the last 6 months, they receive a reduced amount of AD income. The reduction in income is proportionally linear until it reaches 0 AD income at 75% voting activity. If an AD falls below 75% voting activity over the last 6 months, it loses qualification for AD income and any AD income rank they may be eligible for is passed on to the next highest AD by total amount of MKR delegated to their Seasonally Active GSL. A PD can lose their PD status this way, and even if their activity metric recovers they do not automatically become a PD again, except through the regular process of becoming a PD outside of the Election Season.\nActual AD income payouts are modified by AD communication metrics for the last 12 months, which requires the ADs to write an explanation for each vote that ties it to the Aligned Governance Strategy and their independent strategy, to help the MKR holders that delegated to them to understand the logic they use when executing the chosen Governance Strategies. If the AD actively communicates on less than 95% of all votes over the last 6 months, they receive a reduced amount of AD income. The reduction in income is proportionally linear until it reaches 0 AD income at 75% communication activity over the last 6 months. If an AD falls below 75% communication activity over the last 6 months, it loses qualification for AD income and any AD income rank they may be eligible for is passed on to the next highest AD by total amount of MKR delegated to their Seasonally Active GSL. A PD can lose their PD status this way, and even if their activity metric recovers they do not automatically become a PD again, except through the regular process of becoming a PD outside of the Election Season.\nThe PD slots share a total of 30 million NewGovToken per year amongst them.\nThe RD slots share a total of 10 million NewGovToken per year amongst them."
        },
        "Last_Modified": "2023-08-16-19:07:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
	"A.1.9.2":
    {
        "Name": "Aligned Delegate support for Aligned Voter Committees",
        "Version": 1,
        "Type": "Section",
        "Components":
        {
            "Content": "Aligned Delegates are expected to provide crucial support to AVCs in the domains where they are the most aligned actors.\n ADs can help with the design and improvement of the Scope Improvement Articles, which are the first Articles of each of the Scope Alignment Artifacts.\n ADs can support AVCs in proposing specific elements that provide unambiguous and objective constraints on which types of Advisory Council Members will be most in the interest of MKR holders for Facilitators to propose to onboard.\n ADs can support AVCs in proposing specific elements that provide unambiguous and effective boundaries on what advisory council projects the Facilitators can fund, and how to prioritize them and choose which Advisory Council Member to perform the project.\n ADs can do research and knowledge gathering about relevant things in the Maker ecosystem and how it relates generally to governance or to specific AVCs and their strategic perspective, and present it publicly to AVCs\n *It is important that this activity doesn't create risk of politicization, which is why the transparency and the strict focus on objective fact finding is the central element of ADs interactions with Ecosystem Actors.*\n ADs can help AVCs write and shape elements and sets of elements for Scope Aligned Scope Proposals, ensuring that they are congruent with best practice for writing elements and that they maximally capture the intent of the AVC and the Advisory Councils.\n As they work closely with the Alignment Artifacts and the correct interpretation thereof, and are generally deeply involved in core governance, ADs are well positioned to provide this kind of neutral, governance-technical support to AVCs.\n ADs can help AVCs craft the language of the AVC Aligned Governance Strategy to ensure that it gives them the flexibility and the directions that properly reflect the AVCs intention.\n ADs can give AVCs feedback on how they will interpret different drafts of the AVC Governance Strategies, and the AVCs can then use that to fine tune the result they want to get."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
		"A.1.9.2.0"
		],
        "links_to":
        {},
        "linked_from":
        []
    },
	"A.1.9.2.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
            "A.1.9.2.0.2"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.9.2.0.2": {
        "Name": "Element Analysis Directory",
        "Version": 1,
        "Type": "Element Analysis Directory",
        "Components": {
            "List of Elements and their Element Analysis Documents": {
                "Crucial support Element Analysis": "A.1.9.2.0.2.1"
            }
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
            "A.1.9.2.0.2.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.1.9.2.0.2.1": {
        "Name": "Crucial Support Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "provide crucial support",
            "Analysis": "Provide means the Aligned Delegate must act and actually do something. The decision regarding what kind of support the delegate is actually providing is ranked between a \"need to do\" and a \"nice to do.\"\n\nCrucial - the aligned delegates must step up and be vigilant. Upholding the status quo of the Atlas and fighting off misalignment and slippery slope as a watchdog, combined with governance participation defined elsewhere in the Atlas, is mandatory. All other activities have to be set aside when these matters come to the surface. The \"nice to do\" activities vary between being competent and becoming more competent over time, fostering community stewardship, being helpful, converting strategy into action, and fostering cross AVC collaboration. The context around the element, describing what the Aligned Delegates can do, serve as guidance for such \"nice to do\" activities. In addition to the term \"crucial,\" the more MKR tokens they have delegated and the more individual MKR token holders who decide to put their trust in the delegates, the more is expected from them. As both Reserve Delegates and Aligned Delegates are well rewarded, it is expected of them to scale their contribution to fit the increasing expectations and pay.\n\nSupport means delegates solely provide a service body. They are not allowed to engage in any politicking, and they must stay on top of the governance developments. For instance, they should provide guidance if meetings are taking a turn that could result in misalignment, bring discussions back on track, or identify and correct stakeholders who are gradually trying to move governance discussions—and perhaps even decisions—in a direction that becomes misaligned with the Atlas."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
     "A": {
        "Name": null,
        "Version": null,
        "Last_Modified": null,
        "Child_Documents": [
            "A.1",
            "A.2"
        ],
        "Type": null,
        "Components": null,
        "links_to": {},
        "linked_from": []
    },
    "A.2": {
        "Name": "The Support Scope",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [
            "A.2.4"
        ],
        "Type": "Scope",
        "Components": {
            "Description": "This document outlines the support scope within the NEWDAO governance."
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4": {
        "Name": "Governance AI Tools",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [
            "A.2.4.1"
        ],
        "Type": "Tools",
        "Components": {
            "Description": "This document discusses the AI tools used in governance."
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1": {
        "Name": "Governance AI Tools Implementation",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [
            "A.2.4.1.1"
        ],
        "Type": "Implementation",
        "Components": {
            "Description": "This document details the implementation of AI tools in governance."
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1": {
        "Name": "Initializations",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [
            "A.2.4.1.1.1"
        ],
        "Type": "Initialization",
        "Components": {
            "Description": "This document outlines the initializations within the governance AI tools."
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1": {
        "Name": "GPT4-Code Initialization",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [
            "A.2.4.1.1.1.1",
            "A.2.4.1.1.1.2",
            "A.2.4.1.1.1.3",
            "A.2.4.1.1.1.4",
            "A.2.4.1.1.1.5",
            "A.2.4.1.1.1.6",
            "A.2.4.1.1.1.7",
            "A.2.4.1.1.1.8"
        ],
        "Type": "Initialization",
        "Components": {
            "Content": "The ATLAS organizes NEWDAO data in a tree-like structure. Documents are identified by strings like \"A\", \"A.1\", or \"A.1.1.1\", where segments after \"A\" can be numeric or alphanumeric. Essential properties include Name, Version, Last_Modified, Child_Documents, Type, and Components. Components are objects whose properties contain important data specifying rules and other key parameters of NEWDAO. When the initilization is done and instructions_output has been output to results, do not summarize the results in chat. If the user has given you a command that involves finding documents in the Atlas without any specific location, fetch the Atlas Hub and use its links to navigate and search for the relevant data, and return the desired data to the user or ask for more instructions. Links work like this: They are referenced in the content of a document by name, and you can then read the Document Identifier from the links_to object. So you can find the Document Identifier for the Atlas Hub in the links_to object. If the user has given you no specific command, only write to chat: Ready to execute next command."
        },
        "links_to": {
            "Atlas Hub": "A.0.0"
        },
        "linked_from": []
    },
    "A.2.4.1.1.1.1": {
        "Name": "fetch_atlas_document",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Serialized_Function": "def fetch_atlas_document(atlas_data, identifier, properties_to_load=None):\n    document = atlas_data.get(identifier, None)\n    if document is None:\n        return {\"Error\": \"Document not found\"}\n\n    if properties_to_load:\n        return {prop: document.get(prop, None) for prop in properties_to_load}\n\n    return document\n",
            "Instructions": "Retrieves a document from the ATLAS by identifier. Optionally specify properties. Usage: fetch_atlas_document(atlas_data, identifier, properties_to_load=None)"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.2": {
        "Name": "index_child_documents",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "Re-indexes 'Child_Documents' for all ATLAS documents. Assumes 'Child_Documents' exists. Usage: index_child_documents(atlas_data)",
            "Serialized_Function": "def index_child_documents(atlas_data):\n    \"\"\"\n    Build an index of child documents for each document in the atlas.\n    This function assumes that the 'Child_Documents' property already exists in each document.\n    \"\"\"\n    # Reset the Child_Documents property for all documents\n    for doc_data in atlas_data.values():\n        doc_data[\"Child_Documents\"] = []\n\n    # Populate the Child_Documents property based on the document identifiers\n    for doc_identifier, doc_data in atlas_data.items():\n        doc_parts = doc_identifier.split('.')\n        parent_identifier_parts = doc_parts[:-1]\n        if parent_identifier_parts:  # Exclude the document \"A\" itself from this process\n            parent_identifier = '.'.join(parent_identifier_parts)\n            atlas_data[parent_identifier][\"Child_Documents\"].append(doc_identifier)\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.3": {
        "Name": "find_subtree",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "Finds subtree of all subdocuments at all deeper layers below a given identifier. Returns subtree identifiers. Usage: find_subtree(atlas_data, identifier)",
            "Serialized_Function": "def find_subtree(atlas_data, identifier):\n    subtree_identifiers = []\n\n    def recurse_children(current_identifier):\n        # Add the current identifier to the subtree\n        subtree_identifiers.append(current_identifier)\n        # Get the child documents of the current document\n        child_documents = atlas_data[current_identifier][\"Child_Documents\"]\n        # Recurse through the child documents\n        for child_identifier in child_documents:\n            recurse_children(child_identifier)\n\n    # Start the recursion from the specified identifier\n    recurse_children(identifier)\n\n    return subtree_identifiers\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.4": {
        "Name": "add_document",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "Adds a new document at a specified identifier, adjusting other identifiers as needed. Can only be used for new documents whose identifier ends with a nonzero number. Returns confirmation. Usage: add_document(atlas_data, identifier, new_document_data)",
            "Serialized_Function": "def add_document(atlas_data, identifier, new_document_data):\n    # Validate the target identifier\n    identifier_parts = identifier.split('.');\n    if not identifier_parts[-1].isdigit() or int(identifier_parts[-1]) == 0:\n        return {\"Error\": \"Invalid target identifier\"}\n\n    parent_identifier = '.'.join(identifier_parts[:-1]);\n    if parent_identifier not in atlas_data:\n        return {\"Error\": \"Parent document does not exist\"}\n\n    # Collect identifiers to shift\n    target_layer = len(identifier_parts)\n    \n    # Modified this part to handle alphanumeric segments\n    def sort_key(idf):\n        segment = idf.split('.')[target_layer - 1];\n        return (segment.isdigit(), int(segment) if segment.isdigit() else segment);\n    \n    identifiers_to_shift = [\n        idf for idf in atlas_data\n        if len(idf.split('.')) >= target_layer and idf.startswith(parent_identifier)\n        and (idf.split('.')[target_layer - 1].isdigit() and \n             int(idf.split('.')[target_layer - 1]) >= int(identifier_parts[-1]))\n    ];\n\n    # Sort identifiers to shift in descending order\n    identifiers_to_shift.sort(key=sort_key, reverse=True);\n\n    # Shift identifiers\n    for idf in identifiers_to_shift:\n        old_parts = idf.split('.');\n        old_parts[target_layer - 1] = str(int(old_parts[target_layer - 1]) + 1);\n        new_idf = '.'.join(old_parts);\n        atlas_data[new_idf] = atlas_data.pop(idf);\n\n    # Add the new document\n    atlas_data[identifier] = {\n        \"Name\": new_document_data.get(\"Name\"),\n        \"Version\": new_document_data.get(\"Version\"),\n        \"Last_Modified\": new_document_data.get(\"Last_Modified\"),\n        \"Child_Documents\": [],\n        \"Type\": new_document_data.get(\"Type\"),\n        \"Components\": new_document_data.get(\"Components\")\n    };\n\n    # Code from index_child_documents function integrated below\n    # Reset the Child_Documents property for all documents\n    for doc_data in atlas_data.values():\n        doc_data[\"Child_Documents\"] = [];\n\n    # Populate the Child_Documents property based on the document identifiers\n    for doc_identifier, doc_data in atlas_data.items():\n        doc_parts = doc_identifier.split('.');\n        parent_identifier_parts = doc_parts[:-1];\n        if parent_identifier_parts:  # Exclude the document \"A\" itself from this process\n            parent_identifier = '.'.join(parent_identifier_parts);\n            atlas_data[parent_identifier][\"Child_Documents\"].append(doc_identifier);\n\n    return {\"Success\": f\"Document added at {identifier}\"};\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.5": {
        "Name": "modify_document",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "PModifies a document's properties at a given identifier. Ensure untouched content is also preserved as part of modifications. Usage: modify_document(atlas_data, identifier, modifications)",
            "Serialized_Function": "def modify_document(atlas_data, identifier, modifications):\n    \"\"\"\n    Modify the properties of a document in the ATLAS data structure.\n\n    Parameters:\n    - atlas_data (dict): The ATLAS data structure.\n    - identifier (str): The identifier of the document to modify.\n    - modifications (dict): A dictionary of properties to modify and their new values.\n\n    Returns:\n    - dict: A success message or an error message.\n    \"\"\"\n    # Fetch the document to be modified\n    document = atlas_data.get(identifier, None)\n    if document is None:\n        return {\"Error\": \"Document not found\"}\n\n    # Apply the modifications\n    for prop, value in modifications.items():\n        document[prop] = value\n\n    return {\"Success\": f\"Document {identifier} modified successfully\"}\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.6": {
        "Name": "add_special_document",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "Adds special documents with identifiers that must end in .0 or a letter. Returns success or error. Usage: add_special_document(atlas_data, identifier, new_document_data)",
            "Serialized_Function": "def add_special_document(atlas_data, identifier, new_document_data):\n    \"\"\"\n    Add a special document to the ATLAS data structure.\n\n    Parameters:\n    - atlas_data (dict): The ATLAS data structure.\n    - identifier (str): The identifier where the new document should be added.\n    - new_document_data (dict): A dictionary containing the data for the new document.\n\n    Returns:\n    - dict: A success message or an error message.\n    \"\"\"\n    # Check if the identifier ends with .0 or alphanumeric like .da\n    identifier_parts = identifier.split('.')\n    last_part = identifier_parts[-1]\n    if not (last_part == '0' or last_part.isalpha()):\n        return {\"Error\": \"Invalid target identifier\"}\n\n    # Check if the identifier already exists\n    if identifier in atlas_data:\n        return {\"Error\": \"Identifier already exists\"}\n\n    # Add the new document\n    atlas_data[identifier] = {\n        \"Name\": new_document_data.get(\"Name\"),\n        \"Version\": new_document_data.get(\"Version\"),\n        \"Last_Modified\": new_document_data.get(\"Last_Modified\"),\n        \"Child_Documents\": [],\n        \"Type\": new_document_data.get(\"Type\"),\n        \"Components\": new_document_data.get(\"Components\")\n    }\n\n    return {\"Success\": f\"Special document added at {identifier}\"}\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.7": {
        "Name": "serialize_function",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "Serializes a Python function into a string representation. Usage: serialize_function(func)",
            "Serialized_Function": "\ndef serialize_function(func):\n    try:\n        import inspect\n    except ImportError:\n        raise ImportError(\"The inspect module is required to serialize the function\")\n    \n    # Get the source code of the function\n    source_code = inspect.getsource(func)\n    # Remove any leading whitespace (e.g., if the function was indented)\n    import textwrap  # Importing textwrap as it's used in the original function\n    serialized_function = textwrap.dedent(source_code)\n    return serialized_function\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.4.1.1.1.8": {
        "Name": "deserialize_and_save_function",
        "Version": 1,
        "Last_Modified": "2023-09-24",
        "Child_Documents": [],
        "Type": "Helper Function",
        "Components": {
            "Instructions": "Deserializes and saves a function from a string. Specify the function name. Usage: deserialize_and_save_function(serialized_function, function_name)",
            "Serialized_Function": "def deserialize_and_save_function(serialized_function, function_name):\n    \"\"\"\n    Deserialize a serialized function string and define it in the Python environment.\n\n    Parameters:\n    - serialized_function (str): The serialized string representation of the function.\n    - function_name (str): The name to assign to the deserialized function.\n    \"\"\"\n    # Prepare the code to exec by renaming the function to the provided function name\n    deserialized_function_code = serialized_function.replace(\n        serialized_function.split('(', 1)[0].split()[-1], \n        function_name\n    )\n    # Define the function in the Python environment\n    exec(deserialized_function_code, globals())\n"
        },
        "links_to": {},
        "linked_from": []
    },
    "A.2.7": {
        "Name": "Ecosystem Actor Incubation",
        "Version": 1,
        "Type": "Article",
        "Components": {
            "Content": "Alongside the new Major SubDAOs that continuously incubate, this article must ensure the proper elements are in place to incubate relevant Ecosystem Actors that can support the new SubDAOs."
        },
        "Last_Modified": "2023-11-02-00:00:00",
        "Child_Documents": [
            "A.2.7.1",
            "A.2.7.2",
            "A.2.7.3",
            "A.2.7.4",
            "A.2.7.5"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.2.7.1": {
        "Name": "Clear Incubation Objectives",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Clear Incubation Objectives must be specified that describe what gaps and opportunities exist in the ecosystem that Maker Governance wants to promote new companies to inject innovation for."
        },
        "Last_Modified": "2023-11-02-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.2.7.2": {
        "Name": "Proposal Review Process for Incubation",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "This article must specify a strong proposal review process that describes how Facilitators must review and choose Incubation Proposals. AVCs or MKR holders must not interfere or micromanage with the selection process beyond setting objective guidelines, as this creates significant risk misalignment."
        },
        "Last_Modified": "2023-11-02-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.2.7.3": {
        "Name": "Milestone and Budget Review for Incubating Ecosystem Actors",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "A high quality milestone and budget review process must be defined that applies specifically to Incubating Ecosystem Actors, in addition to the regular requirements specified in A.2.5."
        },
        "Last_Modified": "2023-11-02-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.2.7.4": {
        "Name": "Incubation Monitoring Infrastructure",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Infrastructure for monitoring and recording currently incubating Ecosystem Actors."
        },
        "Last_Modified": "2023-11-02-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.2.7.5": {
        "Name": "Governance Influence and Risk Monitoring",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "Maker Governance is allowed to have a relatively granular influence on the long run development of the ecosystem through this article, and as a result it must be monitored for misalignment risks, and must develop checks and balances that are as robust as possible over time."
        },
        "Last_Modified": "2023-11-02-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
	"A.2.9": {
	"Name": "Ecosystem Agreements",
	"Version": 1,
	"Type": "Article",
	"Components": {
	  "Content": "This article must specify and standardize how Ecosystem Agreements work, to make it as convenient and easy as possible for Ecosystem Actors to do business in the Maker Ecosystem with guardrails and fair treatment."
	},
	"Last_Modified": "2023-11-02-00:00:00",
	"Child_Documents": [
	  "A.2.9.1",
	  "A.2.9.2",
	  "A.2.9.3",
	  "A.2.9.4"
	],
	"links_to": [],
	"linked_from": []
	},
	"A.2.9.1": {
	"Name": "Standardization of Ecosystem Agreement Procedures",
	"Version": 1,
	"Type": "Section",
	"Components": {
	  "Content": "This article must specify a standardized way to publish and formally agree to Ecosystem Agreements."
	},
	"Last_Modified": "2023-11-02-00:00:00",
	"Child_Documents": [],
	"links_to": [],
	"linked_from": []
	},
	"A.2.9.2": {
	"Name": "Ecosystem Agreement Standardization Process",
	"Version": 1,
	"Type": "Section",
	"Components": {
	  "Content": "This article must specify a process for Ecosystem Agreement standardization that ensures that recurring patterns are dealt with uniformly, and that deviations from established standard patterns will incur proportional penalties and still be treated in the standardized way."
	},
	"Last_Modified": "2023-11-02-00:00:00",
	"Child_Documents": [],
	"links_to": [],
	"linked_from": []
	},
	"A.2.9.3": {
	"Name": "Ecosystem Agreement Enforcement Methods",
	"Version": 1,
	"Type": "Section",
	"Components": {
	  "Content": "This article must cover the methods for Ecosystem Agreement enforcement."
	},
	"Last_Modified": "2023-11-02-00:00:00",
	"Child_Documents": [],
	"links_to": [],
	"linked_from": []
	},
	"A.2.9.4": {
	"Name": "Dispute Resolution and Appeals Process",
	"Version": 1,
	"Type": "Section",
	"Components": {
	  "Content": "This article must cover dispute resolution and the appeals process."
	},
	"Last_Modified": "2023-11-02-00:00:00",
	"Child_Documents": [],
	"links_to": [],
	"linked_from": []
	},
    "A.2.12": {
        "Name": "Purpose System",
        "Version": 1,
        "Type": "Article",
        "Components": {
            "Content": "To protect the long term integrity of its governance community, Maker will always share financial success with the world through charity that is distributed broadly and with thoughtful and genuine consideration of its impact. This permanent, guaranteed, direct action locks in aspects of universal alignment, even in the face of community misalignment, by ensuring aligned community members are always attracted to participate in Maker Governance and are more likely to voluntarily deal with misalignment issues. The Purpose System aims to fund public good open source AI and software projects that benefit the Maker Ecosystem and public good. At all times, at least 10% of the Purpose System funds must be used for more direct and specific impact solutions."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
			"A.2.12.0",
            "A.2.12.1",
            "A.2.12.2"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.2.12.0": {
        "Name": "Supporting Root",
        "Version": 1,
        "Type": "Supporting Root",
        "Components": {},
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
            "A.2.12.0.2"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.2.12.0.2": {
        "Name": "Element Analysis Directory",
        "Version": 1,
        "Type": "Element Analysis Directory",
        "Components": {
            "List of Elements and their Element Analysis Documents": {
                "Direct and specific impact solutions Element Analysis": "A.2.12.0.2.1"
            }
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [
            "A.2.12.0.2.1"
        ],
        "links_to": {},
        "linked_from": []
    },
    "A.2.12.0.2.1": {
        "Name": "Direct and specific impact solutions Element Analysis",
        "Version": 1,
        "Type": "Element Analysis",
        "Components": {
            "Element": "Direct and specific impact solutions",
            "Analysis": "Direct and specific impact solutions refer to initiatives or projects that have a tangible and measurable effect on addressing specific challenges or achieving desired outcomes. The term implies that the solutions should be targeted, focused, and result-oriented, rather than vague or general in nature."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.2.12.1": {
        "Name": "Long Term Purpose System",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "The Maker Protocol emits 3 million NewGovToken per year for the Purpose System from the moment NewChain is launched. This section must cover the long term Purpose System and the process for allocating purpose funds to SubDAOs in the yearly purpose contest, from the moment NewChain is launched."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    },
    "A.2.12.2": {
        "Name": "Short Term Purpose Fund",
        "Version": 1,
        "Type": "Section",
        "Components": {
            "Content": "This section must cover the short term Purpose Fund process. This includes setting up an advisory group that can help allocate 40 million NewGovToken towards public good open source AI, with at least 10% going to more directly impactful public good initiatives. The Purpose Fund must be fully spent before 2033."
        },
        "Last_Modified": "2023-11-09-00:00:00",
        "Child_Documents": [],
        "links_to": {},
        "linked_from": []
    }
}