{"organizational alignment":[{"term":"Organizational Alignment","content":"Organizational alignment is a traditional business concept and can be described as the process of implementing strategies and philosophies to ensure that each member of an organization, from entry-level positions to executive managers, shares a common goal and vision for the success of an organization.","nodeId":"4f6fda1e-7450-4065-8095-e93cb10b3a2a","docNo":"A.0.1.1.1","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"ecosystem intelligence":[{"term":"Ecosystem Intelligence","content":"\"Ecosystem Intelligence\" characterizes a decentralized ecosystem as a single entity acting with a greater or lesser amount of intelligence. Ecosystem Intelligence is not merely determined by the sum of the intelligence of each of its constituent parts, but rather the alignment of these parts. Counterintuitively, very intelligent, but spiritually misaligned participants in a decentralized ecosystem will actually lower Ecosystem Intelligence.","nodeId":"5e2e1397-ff87-43ce-a742-e5a68dc89a44","docNo":"A.0.1.1.2","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"aligned structure":[{"term":"Aligned Structure","content":"An aligned structure is a network, ecosystem, entity, or organization that actively employs Alignment Engineering.","nodeId":"fad68392-c852-4102-81fd-2a4037be38f9","docNo":"A.0.1.1.3","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"universal alignment":[{"term":"Universal Alignment","content":"Universal Alignment refers to an actor's holistic understanding of their connection to their environment or context. This enables them to anticipate how their actions influence everything around them, including the second-order effects that impact them in return. This holistic understanding is rooted in the context of human morality, values, and the natural world. An actor who is universally aligned can grasp the intent behind universally aligned rules and identify discrepancies between the technical incentives of rules and their universal purpose. An action that is in opposition to Universal Alignment constitutes misalignment. Preventing misalignment is the fundamental objective of Alignment Engineering and Alignment Artifacts.","nodeId":"9f953b73-566e-4428-a9d2-e179513c3371","docNo":"A.0.1.1.4","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"universal alignment assumption":[{"term":"Universal Alignment Assumption","content":"Universal Alignment is a spectrum, and actors are more or less Universally Aligned.\n\nIn theory, Universal Alignment is absolute, but in practice it cannot be measured deterministically and thus practically will always be subject to debate and changes over time. Alignment Engineering aims to minimize the degree that actors experience their own, and others’, Universal Alignment changing over time.\n\nThe Universal Alignment Assumption holds that the outcomes of Alignment Engineering - namely, the Alignment Artifacts or rules themselves - always have the spirit, or underlying intent, to serve human values and promote the public good within a specific context.","nodeId":"2ea378ee-9b12-4e09-9f42-0c6ec65ef33b","docNo":"A.0.1.1.5","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"alignment artifact strength":[{"term":"Alignment Artifact Strength","content":"The strength of an Alignment Artifact dictates the minimum level of Universal Alignment that an actor must possess in order to take actions that are universally aligned when interacting with the Artifact.\n\nAlignment Artifact Strength is enhanced by ensuring that Ecosystem Intelligence evolves such that each actor’s self-interested incentives correspond as precisely as possible with requirements of Universal Alignment. This alignment minimizes the additional effort, or \"inner incentive\", that an actor must exert to overcome misalignment.\n\nThe stronger an Alignment Artifact, the less inner incentive that an actor need possess to take actions that are universally aligned.","nodeId":"3b712852-26a9-4fb9-8a9a-ebf2332d3efa","docNo":"A.0.1.1.6","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"inner incentive":[{"term":"Inner Incentive","content":"Inner incentive is the second-order incentive that a universally aligned actor uses to counteract the first-order (or self-interested) incentives that exist pre-Alignment Engineering or that arise from a misaligned structure.","nodeId":"102b11a3-9c8c-423e-bd5f-a0988048f11e","docNo":"A.0.1.1.7","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"alignment engineering":[{"term":"Alignment Engineering","content":"Alignment Engineering is a philosophy of organizational design introduced through the Atlas. It aims to anchor internally sustainable Ecosystem Intelligence within Alignment Artifacts that embody recursive trends towards increased Alignment Artifact Strength over time.","nodeId":"3caef1a5-8d59-4a00-846c-fc0f060b3f05","docNo":"A.0.1.1.8","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"letter of the rule vs spirit of the rule":[{"term":"Letter Of The Rule Vs Spirit Of The Rule","content":"The distinction between the \"letter of the rule\" and the \"spirit of the rule\" refers to whether an individual interprets and follows a rule strictly based on its precise wording, or instead also considers its underlying intent or larger purpose. The Universal Alignment Assumption holds that the underlying intent of rules always aims to serve human values and promote public benefit within a given context.\n\nA \"letter of the rule\" interpretation adheres strictly to the rule’s language, often exploiting ambiguities or loopholes to achieve a specific outcome. This approach allows the rule’s exact wording, even if flawed or misaligned with its goals, to dictate the result, particularly if it benefits the interpreter.\n\nA \"spirit of the rule\" interpretation seeks to comprehend the rule’s true purpose and how it contributes to Universal Alignment, while remaining bound by the letter of the rule. When faced with inconsistencies or errors in the rule’s language, this approach appeals to a pre-established method for disabling, disregarding or substituting the rule as needed to prevent outcomes that contradict its intended objective and the greater purpose it serves.\n\nExample:\n\nImagine a large corporation discovers a loophole in the environmental regulation of its jurisdiction that allows them to generate profits by using a specific type of pollutant that isn’t regulated as a greenhouse gas, but is as harmful as regulated greenhouse gasses.\n\nBy exploiting the \"letter of the rule,\" the corporation complies with the regulations on paper but continues to harm the environment and public health in practice.\n\nA universally aligned actor, such as an environmentally conscious competitor, would interpret the regulations based on their \"spirit\" or underlying purpose — protecting the environment and public health. Recognizing that exploiting the loophole contradicts the regulations’ intent, the universally aligned actor would voluntarily choose not to emit the harmful pollutant, even though doing so might be profitable and technically legal. A universally aligned actor would also actively work with the government and other stakeholders to close the loophole and strengthen the regulations to ensure that they effectively serve their intended purpose, and to protect themselves from misaligned competitors.","nodeId":"ff16fd74-3a81-4cac-92b4-1208d4d9f337","docNo":"A.0.1.1.9","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"incentivized alignment":[{"term":"Incentivized Alignment","content":"Incentivized Alignment is the outcome of an actor’s myopic and self-interested following of the letter of the rule with the first-order incentives of an Aligned Structure, but is not likely to be inherently Universally Aligned and lacks Inner Incentive.","nodeId":"2fc27ce9-6f40-4ed5-934c-97189ea5301b","docNo":"A.0.1.1.10","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"misalignment":[{"term":"Misalignment","content":"Misalignment characterizes the state in which an actor does not possess Universal Alignment, or acts in a way that opposes or contradicts Universal Alignment.","nodeId":"60066e0f-3db7-45c7-9664-8120a4fbd38b","docNo":"A.0.1.1.11","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"slippery slope misalignment":[{"term":"Slippery Slope Misalignment","content":"Slippery Slope Misalignment is the shortest path to misalignment where incremental misaligned acts are justified in various ways. These can include ignoring the potential significance and larger impact of acts due to their small scale; the trivial way that misalignment occurs; the good intentions of the actor; or the conviction that the ends justify the means.\n\nUnderstanding Slippery Slope Misalignment means understanding that any misalignment at all is always very serious and, if not dealt with, results in increased risk of disequilibrium and alignment failure. In the context of a decentralized ecosystem such as Sky, this could mean a governance attack or financial collapse.","nodeId":"adf7ccb3-9ef0-43e0-90cc-6eb9d779f9cd","docNo":"A.0.1.1.12","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"scope":[{"term":"Scope","content":"A Scope is a particular focus area of Sky. There are six Scopes:\n\n- The Governance Scope focuses on Alignment Artifact interpretation and balance of powers.\n- The Support Scope focuses on ecosystem support, tools, and activities, including the Sky Primitives.\n- The Stability Scope focuses on financial stability and the core USDS Stablecoin product.\n- The Protocol Scope focuses on technical development, maintenance, and security.\n- The Accessibility Scope focuses on frontends and distribution.\n- The Agent Scope contains all Agent Artifacts.","nodeId":"f30e56f9-da71-44bc-ab3b-9b13348794fe","docNo":"A.0.1.1.13","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"alignment artifact":[{"term":"Alignment Artifact","content":"Alignment Artifacts are outputs of Alignment Engineering, and can be used by universally aligned actors to coordinate to achieve a positive-sum outcome.","nodeId":"551885ea-d851-4b76-afa1-5ea57f724c9a","docNo":"A.0.1.1.14","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"scope alignment artifact (scope artifact)":[{"term":"Scope Alignment Artifact (Scope Artifact)","content":"A Scope Artifact is an Alignment Artifact designed to align the actions and incentives of participants within a specific Scope defined by the Atlas. It provides a framework for decision-making, resource allocation, and governance within the defined Scope.\n\nEach Scope has its own unique set of challenges and objectives that require a tailored approach to alignment.\n\nThe strength of a Scope Alignment Artifact depends on how well it aligns with Universal Alignment principles, as well as how effectively it is communicated and understood by participants within the defined Scope. A strong Scope Artifact can help prevent misalignment and ensure that all participants are working towards a common goal for the benefit of the entire ecosystem.\n\nScope Artifacts must not be changed beyond the Scope boundaries defined by the Atlas; this constitutes Slippery Slope Misalignment.","nodeId":"10cb8335-18e3-466e-9a0a-b076c1719de5","docNo":"A.0.1.1.15","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"the atlas":[{"term":"The Atlas","content":"The Atlas is the foundational set of rules powering Sky Ecosystem. It consists of Immutable Documents and Adaptive Documents. The former enshrine the Spirit of the Atlas and become permanently immutable from the moment the Sky Ecosystem enters the Endgame State. The Adaptive Documents practically operationalize the Spirit of the Atlas and will be continuously improved through the Sky Governance process. The Immutable part of the Atlas ensures the aligned evolution of Sky: it mitigates the potential and actual damage caused by Slippery Slope Misalignment, which erodes the potency of Alignment Engineering over time.","nodeId":"98223867-c60a-4b28-9401-94fc1ed9b4cd","docNo":"A.0.1.1.16","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"alignment conserver (ac)":[{"term":"Alignment Conserver (AC)","content":"Alignment Conservers (ACs) are external entities that play a fundamental role in facilitating and protecting the Sky Governance process by ensuring it occurs according to the processes defined in the Atlas. ACs enable SKY holders to participate in Sky Governance in a manner where it is easy for SKY holders to make the decisions that best benefit their long-term interests as SKY holders, even if SKY holders overall have relatively little alignment.","nodeId":"94a451ce-100c-4ff5-8d53-65953938ecde","docNo":"A.0.1.1.17","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"aligned delegate (ad)":[{"term":"Aligned Delegate (AD)","content":"Aligned Delegates (ADs) are anonymous Alignment Conservers that use Delegate Contracts to enable SKY holders to easily and safely delegate their SKY voting power.\n\nBecause they directly control large amounts of incentivized SKY voting power, ADs are both highly influential and potentially risky actors within the governance framework. The Atlas empowers ADs and other Ecosystem Actors with the tools to derisk ADs’ influence in the ecosystem.\n\nThe primary responsibility of ADs is to use their delegated power to uphold the Spirit of the Atlas and maintain Universal Alignment of the Sky Ecosystem. ADs are subject to strict requirements enforced by the Governance Scope.","nodeId":"8ea04ed4-7075-45e6-b6ed-a52b7506f4a8","docNo":"A.0.1.1.18","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"facilitator":[{"term":"Facilitator","content":"Facilitators are anonymous Alignment Conservers with responsibility over specific Scopes. Facilitators can directly access governance processes and smart contracts to fulfill their responsibilities.","nodeId":"912e0161-3448-470f-9cf6-d1a26d76acab","docNo":"A.0.1.1.19","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"communication channel":[{"term":"Communication Channel","content":"Communication Channels are a critical consideration in the Atlas as they have a significant impact on incentivized alignment.","nodeId":"72e08874-de00-40dd-aa2b-be76ff754902","docNo":"A.0.1.1.20","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"governance scope (gov)":[{"term":"Governance Scope (GOV)","content":"The Governance Scope Alignment Artifact codifies rules that regulate the critical balance-of-power processes defined in the Atlas, and adjudicate on appeals processes related to misalignment in the ecosystem.","nodeId":"72f9b4d1-695b-489c-a060-db0013ba0466","docNo":"A.0.1.1.21","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"support scope (sup)":[{"term":"Support Scope (SUP)","content":"The Support Scope Alignment Artifact codifies rules that regulate various tasks of ecosystem support, including governance process infrastructure and management and Agent ecosystem support.","nodeId":"334492f3-db84-4f8b-9593-93cefe72900a","docNo":"A.0.1.1.22","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"protocol scope (pro)":[{"term":"Protocol Scope (PRO)","content":"The Protocol Scope Alignment Artifact codifies rules related to the core technical Sky protocol.","nodeId":"b24446c1-44d2-408a-9077-d397fa173132","docNo":"A.0.1.1.23","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"stability scope (sta)":[{"term":"Stability Scope (STA)","content":"The Stability Scope Alignment Artifact codifies the rules related to managing the core Stablecoin product, USDS, and supporting factors related to financial stability, such as surplus buffer and decentralized asset reserve.","nodeId":"6a900766-15ff-49b1-bed5-59f58b9c49c7","docNo":"A.0.1.1.24","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"accessibility scope (acc)":[{"term":"Accessibility Scope (ACC)","content":"The Accessibility Scope defines rules related to accessibility and distribution efforts and regulates user-facing frontends.","nodeId":"1109f780-d48a-4712-8106-848952b684a4","docNo":"A.0.1.1.25","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"governance equilibrium":[{"term":"Governance Equilibrium","content":"A Governance Equilibrium is a state in a Decentralized Governance dynamic where the governance process is able to remain decentralized over time with a very high degree of confidence. It requires redundant feedback loops that can counteract the natural incentives that push the governance process towards disequilibrium and centralization.","nodeId":"7e629109-1d84-46da-a986-94036be81e93","docNo":"A.0.1.1.26","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"endgame state":[{"term":"Endgame State","content":"Endgame State is the final technical and alignment engineering state of Sky, in which all aspects of the ecosystem that can be made immutable, have been made immutable. The aim of the Endgame State is to create a highly resilient Governance Equilibrium.","nodeId":"8a57b601-aec4-49dc-bf34-383c63da11de","docNo":"A.0.1.1.27","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"explicit incentives":[{"term":"Explicit Incentives","content":"Explicit Incentives are the first-order incentives that are coded into rules in Alignment Artifacts.","nodeId":"a5a8a3e5-3d79-4c37-acce-4ac34a459cae","docNo":"A.0.1.1.28","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"implicit incentives":[{"term":"Implicit Incentives","content":"Implicit Incentives are the motivations or benefits that an actor can infer based on a ‘letter of the rules’ interpretation of an Alignment Artifact, and an assessment of the likelihood that these rules will be enforced.","nodeId":"2c824e12-3ec1-4007-9294-ef15d25ccdca","docNo":"A.0.1.1.29","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"incentive slack":[{"term":"Incentive Slack","content":"Incentive Slack refers to the discrepancy between the explicit incentives (those clearly defined and communicated) and the implicit incentives (those inferred by actors) within an Aligned Structure. Incentive Slack can arise when coded rules are either not enforced or are too restrictive or impractical, leading to a pattern of bypassing these rules. When Incentive Slack is high, it creates the perception that rules are likely to be ignored, without regard for the spirit of the rules. This results in a significant risk of widespread misalignment. Incentive Slack cannot occur in an Aligned Structure in which actors are universally aligned and actively enforcing the rules.","nodeId":"133c6032-0082-4644-a3d5-87bcf5b30249","docNo":"A.0.1.1.30","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"whole weeks":[{"term":"Whole Weeks","content":"The Atlas defines quarterly and yearly cycles that determine fixed points in time by counting whole weeks from the beginning of a quarter. The first whole week of a quarter is defined as the first week in which all days, beginning with Monday, fall within the quarter. Another definition would be \"the week starting with the first Monday of the quarter.\"","nodeId":"20f8b661-37c0-4d16-9238-d9595bbcb4cf","docNo":"A.0.1.1.31","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"sky staking":[{"term":"SKY Staking","content":"When a user stakes their SKY tokens, they receive Staking Rewards. Staked SKY can be freely unstaked at any time. SKY Staking also allows users to borrow USDS against their SKY at the SKY Borrow Rate.","nodeId":"6a2c7245-8d67-4de0-80af-ce953352e1bb","docNo":"A.0.1.1.32","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"skylink":[{"term":"Skylink","content":"Skylink is the Sky Ecosystem’s multichain solution, connecting USDS, SKY and other Sky Ecosystem tokens from the Ethereum Mainnet to other chains and L2 protocols. Skylink will make all core Sky features available on the chains and L2s it is deployed to, including Native USDS; Native Sky Savings Rate; Native Token Rewards and Native 1:1 conversion between USDC and USDS.","nodeId":"f0de89da-576a-4710-982e-40acf7f065cc","docNo":"A.0.1.1.33","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"target document":[{"term":"Target Document","content":"The term \"Target Document\" refers to the Immutable or Primary Document to which a Supporting Document is attached. Supporting Documents have various functions, including providing expanded definitions of vague or ambiguous terms in their Target Document; and providing hypothetical fact-patterns to illustrate the practical application of their Target Document. See [A.1.2.2.1.3 - Supporting Document Category](e87b6850-3792-495d-9460-0ac069a217e6).","nodeId":"575ab954-d26c-460e-8a11-ebe7f5586dff","docNo":"A.0.1.1.34","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"voting power":[{"term":"Voting Power","content":"\"Voting Power\" denotes the ability of Aligned Delegates to vote on Sky governance decisions on behalf of a SKY holder. SKY holders can delegate their Voting Power to an Aligned Delegate through Delegate Contracts, allowing the Aligned Delegate to vote on their behalf while the SKY holders retain control of their tokens.","nodeId":"44221aff-ad7c-41d3-a861-8a30963054fa","docNo":"A.0.1.1.35","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"stusds":[{"term":"stUSDS","content":"The token used to provide the capital for SKY Staking leverage is called stUSDS. It ensures that all SKY-backed borrowing is funded by segregated risk capital. Users can deposit USDS into a smart contract and receive stUSDS, which can later be converted back to USDS as long as there is unutilized USDS in the stUSDS converter smart contract.","nodeId":"591e1ba4-1f3e-44ac-9f4c-3f5d680f33d4","docNo":"A.0.1.1.36","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"unrewarded usds":[{"term":"Unrewarded USDS","content":"Unrewarded USDS are USDS balances that are not receiving the Sky Savings Rate, Integration Boost or USDS Token Rewards. USDS Token Rewards include both SKY and Agent token rewards.","nodeId":"86977920-c857-4a86-91ac-1a7571137c18","docNo":"A.0.1.1.37","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"sky forum":[{"term":"Sky Forum","content":"The Sky Forum serves as a dedicated platform for governance across the Sky Ecosystem. Community members submit proposals, engage in debate, and align on decisions. Posts are organized by category according to subject matter. For example, proposals or discussions concerning Sky Core must use the \"Sky Core\" category, while those pertaining to Primes must use the Prime category associated with the Agent. Authors should also apply relevant tags to improve discoverability and cross-referencing. The forum is located at [https://forum.skyeco.com/](https://forum.skyeco.com/).","nodeId":"e78e8fbb-0602-4e67-8c44-88b1f0b30704","docNo":"A.0.1.1.38","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"agent":[{"term":"Agent","content":"Agents are first-class economic citizens of Sky that autonomously pursue business opportunities. Each Agent has its own Agent Artifact and token. Initially, the creation of an Agent results in a Proto-Agent, which lacks any specialized role. To gain functionality within the Sky ecosystem, a Proto-Agent must deploy a special Transformation Primitive to transform into a specific Agent sub-type. The Agent sub-types currently defined in the Atlas include 1) Prime Agent and 2) Executor Agent, with the Executor Agent sub-type further divided into Operational Executor Agents and Core Executor Agents.\n\nAlthough Executor Agents are not yet operational, the Atlas nonetheless defines the foundational rules, processes, and governance structures necessary for their eventual activation. In the medium to long term, these Executor Agents will become fully operative and perform an essential function in facilitating the activities of Prime Agents across the Sky ecosystem.","nodeId":"3c18e6a7-95b8-44e9-8da6-1eadf3fdd356","docNo":"A.0.1.1.39","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"agent artifact":[{"term":"Agent Artifact","content":"Agent Artifacts contain all rules, processes, parameters, and knowledge of the Agent. Agent Artifacts must be aligned with, and are fully subordinate to, the Sky Core Atlas.","nodeId":"8d081c1a-6393-4aaf-8914-8959cdf2fee3","docNo":"A.0.1.1.40","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"agent scope":[{"term":"Agent Scope","content":"The Agent Scope codifies all Agent Artifacts.","nodeId":"87dafa99-c36e-4e68-ac19-fccac4b3834d","docNo":"A.0.1.1.41","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"prime agent":[{"term":"Prime Agent","content":"Prime Agents maintain and automate Sky features in new markets, and innovate custom products. Prime Agents are the only Agent type that can access all Sky Primitives; whereas Executor Agents are limited in the Primitives they can access.\n\n- Prime Agents cannot directly operationalize those elements of their strategies that directly interface with the Sky Protocol or shared ecosystem infrastructure. For such protocol-level and ecosystem-critical operations, Prime Agents must rely on Operational Executor Agents for implementation.\n- When a Prime Agent formulates a new initiative, it encodes the relevant instructions and parameters into its Agent Artifact. Insofar as the Prime Agent’s Artifact requires protocol-level interactions, the Operational Executors use the Artifact as a detailed operational blueprint for implementing the Prime Agent’s directives—ensuring consistency with the Atlas and minimizing risk.\n- This ensures a robust division between Prime Agents’ strategic, externally facing activities and the specialized operational activities that directly interface with Sky’s core systems.","nodeId":"a8454271-c090-4084-b022-4430e3def93c","docNo":"A.0.1.1.42","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"executor agent":[{"term":"Executor Agent","content":"Executor Agents (\"Executors\") are specialized Agents that implement those elements of a Prime Agent’s activities that directly interface with the Sky Protocol or shared ecosystem resources, leaving Prime Agents free to focus on strategic, business development, and marketing efforts. There are two Executor sub-types: Core Executor Agents (\"Core Executor Agents\") and Operational Executor Agents (\"Operational Executors\").\n\n- Operational Executor Agents handle the day-to-day execution of those portions of a Prime Agent’s strategies that directly interface with the Sky Protocol, strictly following the instructions laid out in each Prime Agent’s Artifact. Prime Agents cannot be active in the Sky Ecosystem unless they have an active \"Operational Executor Accord\" which codifies their relationship with an Operational Executor. Operational Executors take on the risk of Prime Agents’ outcomes by providing collateralized insurance against losses or liabilities. Operational Executor Agents’ Operational Collateral can also cover losses from negligence or malicious behavior by the Operational Executor in carrying out the Prime Agent’s strategy.\n- Core Executor Agents, on the other hand, oversee the activities of Operational Executors, ensuring that the implementation of Prime Agent strategies aligns with the Atlas.\n- By separating strategy from operations, this division of labor empowers Prime Agents to innovate rapidly and expand their ventures without needing to develop specialized operational expertise, as Operational Executors manage the day-to-day technical implementation under the oversight of Core Executor Agents.","nodeId":"ac514975-66ad-4b43-8f76-42cac5ca599d","docNo":"A.0.1.1.43","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"operational executor agent":[{"term":"Operational Executor Agent","content":"Operational Executor Agents (\"Operational Executors\") are specialized Executor Agents tasked with implementing and verifying those elements of a Prime Agent’s strategy that directly interface with the Sky Protocol or shared ecosystem resources. While Prime Agents autonomously set strategic direction, Operational Executors are responsible for operationalizing those activities that modify on-chain or protocol-level state, relying on the relevant Primitive Configuration Documents in the Agent Artifact.\n\nEach Operational Executor Agent must comprise at least one Facilitator and at least one GovOps actor. Facilitators are responsible for interpreting the Atlas and the Agent Artifact and instructing GovOps actors to carry out the corresponding actions. To ensure accountability and mitigate potential risks, Operational Executor Agents must maintain Operational Collateral, which serves as a guarantee to cover losses or damages resulting from negligence or malicious behavior by either Facilitators or GovOps actors.","nodeId":"23253343-23e3-440f-90c0-43d3437c2098","docNo":"A.0.1.1.44","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"core council executor agent":[{"term":"Core Council Executor Agent","content":"Core Council Executor Agents (\"Core Executor Agents\") are Executor Agents who serve on the Core Council and act as checks on Operational Executor Agents.","nodeId":"2a440474-20d1-4703-a57b-35e0cebb881c","docNo":"A.0.1.1.45","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"core council":[{"term":"Core Council","content":"The Core Council is a group of Executors responsible for operationalizing the protocol at the Sky Core level. It monitors Operational Executor compliance and enforces the Sky Core Atlas. It also oversees Sky Core governance processes, evolves the Risk Framework, monitors Alignment Conservers, and addresses governance disputes. The Council begins with a single seat held by Core Council Executor Agent 1 and will expand over time to multiple elected seats on a rotational basis, targeting up to seven members in the long term.","nodeId":"5a03a0c4-a47a-409c-9b23-52ac93e63d45","docNo":"A.0.1.1.46","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"govops":[{"term":"GovOps","content":"Governance Operations (\"GovOps\") actors are specialized Ecosystem Actors operating within Executor Agent entities. They manage the technical implementation of Prime Agents’ Instances of Sky Primitives by carrying out on-chain/off-chain tasks necessary for Prime Agents’ operational and governance processes. They work in tandem with Executor Facilitators, who interpret the Atlas and the Agent Artifact.","nodeId":"1e73ee4b-823d-406a-af54-223b43bc8e42","docNo":"A.0.1.1.47","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"operational executor govops":[{"term":"Operational Executor GovOps","content":"Operational Executor GovOps (\"Operational GovOps\") actors are GovOps actors that operate within Operational Executor Agents. Operational GovOps play a crucial role in implementing Prime Agent strategies, doing so by executing the technical specifications outlined in Primitive Configuration Documents of Agent Artifacts.","nodeId":"80c7e2e1-a2af-47dd-80c7-aee6823cca91","docNo":"A.0.1.1.48","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"core council govops":[{"term":"Core Council GovOps","content":"Core Council GovOps (\"Core GovOps\") actors are GovOps actors that operate within Core Executor Agents.","nodeId":"e512e890-629f-450f-a14d-a3ea06a369c0","docNo":"A.0.1.1.49","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"operational executor facilitator":[{"term":"Operational Executor Facilitator","content":"Operational Executor Facilitators are Facilitators that interpret Artifacts and the Atlas on behalf of Operational Executor Agents.","nodeId":"2d984fe4-c1d7-4ac3-835b-19f19a3a5505","docNo":"A.0.1.1.50","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"core council executor facilitator":[{"term":"Core Council Executor Facilitator","content":"Core Council Executor Facilitators (\"Core Facilitator\") interpret Artifacts and the Atlas on behalf of Core Executor Agents.","nodeId":"453e9bfb-2776-486d-b451-35742e49e0ab","docNo":"A.0.1.1.51","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"sky primitives":[{"term":"Sky Primitives","content":"Sky Primitives are the core building blocks of the Sky ecosystem, serving as the primary interface between Agents and the Atlas. By providing a standardized set of tools and interfaces, Sky Primitives empower Prime Agents to create, innovate, and evolve the Sky Protocol in a decentralized manner. The Sky Primitives are also used by Executor Agents, which serve as the robust and standardized intermediary layer between Prime Agents and the Sky Protocol.","nodeId":"ae14941a-635e-4022-af4d-2bec2827fbbf","docNo":"A.0.1.1.52","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"conformance":[{"term":"Conformance","content":"Conformance characterizes the state in which a Synome Document accurately operationalizes the principles, rules, and processes specified by the Atlas Documents.","nodeId":"cb66c28b-c05f-4ccc-ad44-f05aacf78b9c","docNo":"A.0.1.1.53","sourceDocNo":"A.0.1.1","sourceContext":"A.0.1 Atlas Preamble"}],"executive sheet":[{"term":"Executive Sheet","content":"The Executive Sheet serves as a planning instrument and documentation for the agreed content of the Spell. It is therefore one of the foundational documents in the Executive Process. Each Spell has a dedicated Executive Sheet. The Governance Point creates a new Executive Sheet for each Executive Vote cycle, listing every executive item intended for inclusion in that cycle along with the provenance of each item. In this way, the Executive Sheet helps ensure transparency and verification in the Executive Process. Past Executive Sheets are preserved in order to provide a record of Executive Votes and their provenance.\n\nThe Executive Sheet (also referred to as the \"exec sheet\" or \"sheet\") is maintained on a large Google Sheets spreadsheet with several tabs. Each Executive Vote has its own tab, whose title is the designated Target Date for each Spell.\n\nThe Executive Sheet provides a publicly visible list of plain-English instructions outlining the executive actions performed in a given Spell. Each executive action is populated in the Executive Sheet under a column and broken down into input actions (high-level actions) and derived actions (resulting from input actions).\n\nThe Executive Sheet is used by several actors in the Executive Process. It is managed and populated by the Governance Point, used by stakeholders, who are required to provide confirmation for proposed executive items, and by the Spell Team. The Executive Sheet is the source of truth for the Spell Crafter who crafts the Spell based on its content. Only the Core Facilitator has write access to the Executive Sheet.","nodeId":"af04619b-5b0b-4762-86de-067550e079b9","docNo":"A.1.10.2.1.1","sourceDocNo":"A.1.10.2.1","sourceContext":"A.1.10.2 Executive Process Definition"}],"target date":[{"term":"Target Date","content":"The Target Date refers to the planned date when the Spell is expected to be made available to be voted on. The Target Date is decided by the Governance Point in collaboration with the Spell Crafter. Spells are usually deployed following a two-week cadence. Normally, the Target Date falls on Thursdays.","nodeId":"2f06dd6a-8664-4916-8f82-5155d703d61a","docNo":"A.1.10.2.1.2","sourceDocNo":"A.1.10.2.1","sourceContext":"A.1.10.2 Executive Process Definition"}],"executive document":[{"term":"Executive Document","content":"The Executive Document (also referred to as the \"Executive Copy,\" \"executive,\" \"Executive Proposal,\" or \"exec doc\") is a formal, plain-English Markdown document that serves as the primary communication tool for presenting the contents of an Executive Vote to the community. Created after the Executive Sheet is finalized, it provides a detailed breakdown of the actions proposed in the Executive Vote. Unlike the Executive Sheet, which organizes actions in a cell-based format, the Executive Document expresses these actions in sentence format for improved readability.\n\nEach Executive Document corresponds to a specific Spell and describes the actions that the Spell will perform if executed. It is a critical tool for ensuring transparency, clarity, and alignment among stakeholders. The document serves as a proposal that can be voted on and either approved or rejected by Sky Governance. The Core Facilitator is responsible for producing and finalizing the Executive Document; and any changes must be made by them.\n\nThe Executive Document is designed to be accessible to both technical and non-technical members of the Sky Ecosystem. It enables Aligned Delegates and SKY holders to understand the actions that will be executed when the Spell is cast. Its contents are publicly visible on the Voting Portal, where Aligned Delegates review it before voting on the Spell. In addition to serving as a reference for voters, the Executive Document also guides the Spell Team in developing and finalizing the Spell, ensuring that the proposed actions are accurately implemented. The contents of the Executive Document are hashed and included within the Spell code to provide an additional layer of verification.","nodeId":"a352b5e8-752e-48f8-a393-cf5df5ae523d","docNo":"A.1.10.2.1.3","sourceDocNo":"A.1.10.2.1","sourceContext":"A.1.10.2 Executive Process Definition"}],"executive vote":[{"term":"Executive Vote","content":"Executive Vote refers to the voting process of approving governance proposals within Sky Governance. These votes are conducted onchain and are used to implement technical changes to the Sky Protocol. For an Executive Vote to be executed, it must accumulate more SKY token support than any other active proposal, including the current leading proposal, ensuring it reflects the highest level of community backing at the time of approval.","nodeId":"c0aea3f8-4ed9-4bd6-928b-f43ccc7d5ecf","docNo":"A.1.10.2.1.4","sourceDocNo":"A.1.10.2.1","sourceContext":"A.1.10.2 Executive Process Definition"}],"sky governance voting portal":[{"term":"Sky Governance Voting Portal","content":"The Voting Portal is the primary user interface where Executive Votes are published and where Aligned Delegates and SKY holders review and vote on proposals. It serves as the canonical location for viewing active and past Executive Votes, associated documentation, and vote tallies. The Voting Portal can be found at [https://vote.sky.money/executive](https://vote.sky.money/executive).","nodeId":"0919d4bd-2050-43dc-a1b9-8cdfdf0cba54","docNo":"A.1.10.2.1.5","sourceDocNo":"A.1.10.2.1","sourceContext":"A.1.10.2 Executive Process Definition"}],"custom spell voting page":[{"term":"Custom Spell Voting Page","content":"The custom Spell voting page is the public interface used to submit, review, and vote on Executive Votes that are not accompanied by a formal Executive Document. It also supports voting on pre-deployed standby Spells by allowing stakeholders to specify target contract addresses and calldata directly. The custom Spell voting page can be found at [https://vote.sky.money/custom-spell](https://vote.sky.money/custom-spell).","nodeId":"7171aa68-668e-49bb-bf00-511cb79eb5e9","docNo":"A.1.10.2.1.6","sourceDocNo":"A.1.10.2.1","sourceContext":"A.1.10.2 Executive Process Definition"}],"spell":[{"term":"Spell","content":"Spell is a term specific to the Sky Protocol. It refers to all technical components of an Executive Vote, encompassing the codebase, code operations, code reviews, and overall code quality. The term \"Spell\" is often used interchangeably with the Executive Vote itself, as it represents the smart contract responsible for enacting changes to the protocol. Spells are categorized as either \"regular\" or \"out-of-schedule.\" Regular Spells adhere to a biweekly cadence, while out-of-schedule Spells are handled with service-level agreements (SLAs) determined on a case-by-case basis.","nodeId":"7d798e34-cdb0-4416-ab11-b5b48ccf61e6","docNo":"A.1.10.2.1.7","sourceDocNo":"A.1.10.2.1","sourceContext":"A.1.10.2 Executive Process Definition"}],"ecosystem spell validation":[{"term":"Ecosystem Spell Validation","content":"Ecosystem Spell Validation (also referred to as \"Spell validation\" or \"validation\") refers to the process of performing a set of checks and high-level review of a specific Spell’s code as it exists on the blockchain (referred to as a \"deployed Spell\"). This process applies only to the deployed Spell and is not as comprehensive as the reviews conducted during the Spell development process by the Spell Reviewers. The purpose of Spell validation is to validate the safety of the current Spell in respect to its security impacts in relation to Sky Protocol smart contracts.","nodeId":"e2bc30b0-1370-44e6-9872-39530ff61d65","docNo":"A.1.10.2.1.8","sourceDocNo":"A.1.10.2.1","sourceContext":"A.1.10.2 Executive Process Definition"}],"spell roster":[{"term":"Spell Roster","content":"Spell Roster refers to the two teams of technical contributors in the Sky Ecosystem, Sidestream and Dewiz. The Spell Team for the Executive Vote is selected from the members of the Spell Roster.","nodeId":"34fb69c2-12db-452c-a773-1d3ed706b993","docNo":"A.1.10.2.1.9","sourceDocNo":"A.1.10.2.1","sourceContext":"A.1.10.2 Executive Process Definition"}],"spell team":[{"term":"Spell Team","content":"Each Executive Vote has a dedicated Spell Team, made up of Spell Crafters and Spell Reviewers. The Spell Team must include one Crafter, who is responsible for crafting the Spells. The Spell Team must also include at least two Reviewers, responsible for reviewing and confirming that the Spells are ready for the Executive Vote, at least one of whom should be a member of a different Ecosystem Actor than the Spell Crafter. A Crafter cannot serve as a Reviewer for the same Spell. The Spell Team is a set of technical contributors working on developing all technical and smart-contract-related aspects of a particular Executive Vote, based on instructions set out by the Governance Point.","nodeId":"202874e5-65f8-4250-bfb1-5122e5656395","docNo":"A.1.10.2.1.10","sourceDocNo":"A.1.10.2.1","sourceContext":"A.1.10.2 Executive Process Definition"}],"spell crafter":[{"term":"Spell Crafter","content":"The Spell Crafter (the Crafter) is the person or entity who parses the written instruction set of a proposed Executive to Solidity code in order to develop the Spell in the first instance. Every addition, modification, or removal of code or content within the Spell must be performed by the Crafter. The designated Spell Crafter must be rotated, such that the same person does not craft the Spells for two consecutive Executive Votes. The Spell Crafter is a member of the Spell Team for a particular Executive Vote.","nodeId":"e007c08a-5fef-42df-a63b-7b4d78b3366f","docNo":"A.1.10.2.1.11","sourceDocNo":"A.1.10.2.1","sourceContext":"A.1.10.2 Executive Process Definition"}],"spell reviewer":[{"term":"Spell Reviewer","content":"The Spell Reviewers (the Reviewers) are the people or entities responsible for reviewing the draft Spell as parsed by the Spell Crafter. The Reviewers are responsible for verifying the Spell, finding issues and catching bugs and mistakes in the Spell, and otherwise ensuring its quality. There is an important delineation between the function of Spell Crafters and Spell Reviewers: the Reviewers may not perform any addition, modification or removal of code or content within the Spell, although they may suggest changes to the Spell Crafter. Spell Reviewers are members of the wider Spell Team for a particular Executive Vote.","nodeId":"8d7a61c4-c1fd-4fbb-bbe9-1c2d6f4f3cdd","docNo":"A.1.10.2.1.12","sourceDocNo":"A.1.10.2.1","sourceContext":"A.1.10.2 Executive Process Definition"}],"definition of weekly poll":[{"term":"Definition Of Weekly Poll","content":"A Weekly Poll (\"Governance Poll\" or \"Poll\") is a non-binding poll that determines the bi-weekly Executive Vote contents. In this context, a non-binding weekly poll refers to the fact that a weekly poll cannot change the system parameters independently; it merely dictates what will be included in the next Executive Vote.\n\nGovernance Polls occur on-chain and are used to measure the sentiment of SKY voters. Polls often run concurrently, allowing voters to participate in any number of them at the same time. Polls may have different formats like Binary Voting, Instant Run-Off Voting, or Approval Voting depending on the topic. The voting period of a given Governance Poll varies; the most common are three (3) and fourteen (14) day periods. Concurrently-posted polls do not necessarily have the same voting periods.","nodeId":"cae731e3-0828-42ce-ae53-259c5c54cb79","docNo":"A.1.11.1.2.1","sourceDocNo":"A.1.11.1.2","sourceContext":"A.1.11.1 Operational Weekly Cycle"}],"definition of executive vote":[{"term":"Definition Of Executive Vote","content":"An Executive Vote (also \"Executive\") is a formalized governance proposal that requires on-chain voting. Through the Executive Vote mechanism, SKY holders steward Sky Governance by voting on Executive proposals that pertain to operations maintaining the Protocol. Executive Votes execute technical changes to the Sky Protocol.\n\nThe Executive Vote occurs approximately every two weeks. Its contents are often determined by weekly Governance Polls that pre-approve the inclusion of proposals in the Executive Vote. However, the Atlas can explicitly authorize proposals to go directly to an Executive Vote.\n\nNote that the terms ‘Executive’ and ‘Spell’ are distinct concepts.\n\nThe term ‘Executive’ or ‘Executive Vote’ is used in all instances where the formal governance vote is being referenced. The term ‘Executive Process’ refers to the end-to-end process of the development of an Executive Vote, in which Facilitators, Spell teams (also referred to collectively as the \"Governance Security Engineering Team\") and other recognized Ecosystem Actors participate.\n\nThe term ‘Spell’ refers to the smart contract that executes the changes to the protocol approved by Sky Governance in an Executive Vote. Generally, when referring to Spell team operations and their technical outcome or product (including code base, code operations, code reviews and code quality), the term ‘Spell’ will be used.\n\nThe term ‘Spell process’ refers to the end-to-end process of developing a Spell, a process in which the Core Facilitator and the current Spell team participate. The term ‘Spell development process’ is a subset of the ‘Spell process’ and pertains solely to the technical development of the Spell by the current Spell team.","nodeId":"8bde129a-49a5-4f68-a82f-9995b86a1aa3","docNo":"A.1.11.1.2.2","sourceDocNo":"A.1.11.1.2","sourceContext":"A.1.11.1 Operational Weekly Cycle"}],"peg stability module":[{"term":"Peg Stability Module","content":"A Peg Stability Module (\"PSM\") allows users to swap a given collateral type directly for Dai or USDS at a fixed rate, rather than borrowing Dai or USDS. The PSM contract was designed with Stablecoin collateral in mind, allowing users to swap other Stablecoins for Dai or USDS at a fixed rate to aid with keeping Dai or USDS pegged to one (1) USD.\n\nA PSM operates similarly to a regular vault type with a zero Stability Fee and a liquidation ratio of 100% that can only be accessed through a user-facing smart contract containing the relevant swap functions. Unlike regular vaults, users of the PSM do not retain ownership of the asset and borrow Dai or USDS. Instead, PSM users swap the asset directly for Dai or USDS.","nodeId":"0082c12d-f1a7-46ff-a4aa-5fe42ece1a4d","docNo":"A.3.3.2.1.1","sourceDocNo":"A.3.3.2.1","sourceContext":"A.3.3.2 Implementation"}],"low risk real world assets":[{"term":"Low Risk Real World Assets","content":"Low Risk RWAs (\"LRR\") are safe, short-term treasury strategies of less than one (1) year duration.","nodeId":"590c645c-8045-4053-9ab1-ea718b62f770","docNo":"A.3.3.2.1.2","sourceDocNo":"A.3.3.2.1","sourceContext":"A.3.3.2 Implementation"}],"cash stablecoins":[{"term":"Cash Stablecoins","content":"Cash Stablecoins are defined as USDC, USDT, and pyUSD.","nodeId":"066a4d9f-13ed-4ac3-a55a-df7bf3429649","docNo":"A.3.3.2.1.3","sourceDocNo":"A.3.3.2.1","sourceContext":"A.3.3.2 Implementation"}],"min definition":[{"term":"Min Definition","content":"The `min` parameter defines the minimum value for rates in basis points that can be set using the Stability Parameter Bounded External Access Module. Each rate parameter added to the SP-BEAM has a specific `min`.","nodeId":"1896350c-5f87-4be5-b32f-f1114dc2c271","docNo":"A.3.7.1.3.1.1","sourceDocNo":"A.3.7.1.3.1","sourceContext":"A.3.7.1.3 Stability Parameter Bounded External Access Module"}],"max definition":[{"term":"Max Definition","content":"The `max` parameter defines the maximum value for rates in basis points that can be set using the Stability Parameter Bounded External Access Module. Each rate parameter added to the SP-BEAM has a specific `max`.","nodeId":"67747090-8545-49b4-95e8-673af9836aa5","docNo":"A.3.7.1.3.1.2","sourceDocNo":"A.3.7.1.3.1","sourceContext":"A.3.7.1.3 Stability Parameter Bounded External Access Module"}],"max technical upper limit":[{"term":"Max Technical Upper Limit","content":"Although the `max` parameter can be set higher, the SP-BEAM cannot be used to set a rate higher than 50% (5,000 basis points) due to technical limitations. Attempts to use the SP-BEAM in this manner will revert. To avoid confusion, `max` should not be set to a value higher than 50% (5,000 basis points).","nodeId":"4e2910c0-fd52-4e18-97e0-2fbd35569070","docNo":"A.3.7.1.3.1.2.1","sourceDocNo":"A.3.7.1.3.1","sourceContext":"A.3.7.1.3 Stability Parameter Bounded External Access Module"}],"step definition":[{"term":"Step Definition","content":"The `step` parameter limits how much the rates can be increased or decreased in a single transaction in basis points, bound by the `tau` parameter. Each rate parameter added to the SP-BEAM has a specific `step`.","nodeId":"bcfac0d1-3d17-46e1-bf88-5a7937816d53","docNo":"A.3.7.1.3.1.3","sourceDocNo":"A.3.7.1.3.1","sourceContext":"A.3.7.1.3 Stability Parameter Bounded External Access Module"}],"tau definition":[{"term":"Tau Definition","content":"The `tau` parameter defines the minimum time interval, in seconds, that must elapse between consecutive uses or operations of the Stability Parameter Bounded External Access Module.\n\nAn SP-BEAM operation may adjust one or more parameters. Once an SP-BEAM operation is executed, the `tau` duration must expire before any subsequent SP-BEAM operation can be performed.","nodeId":"8747effa-1080-4066-89da-4c25121a02ba","docNo":"A.3.7.1.3.1.4","sourceDocNo":"A.3.7.1.3.1","sourceContext":"A.3.7.1.3 Stability Parameter Bounded External Access Module"}],"tau current value":[{"term":"Tau Current Value","content":"The `tau` is currently set to 57,600 seconds (16 hours).","nodeId":"dd9472e5-9796-4aff-a2b1-7a847e008c9b","docNo":"A.3.7.1.3.1.4.1","sourceDocNo":"A.3.7.1.3.1","sourceContext":"A.3.7.1.3 Stability Parameter Bounded External Access Module"}]}