From 4c59c162116e088c86dc184a7169562080267271 Mon Sep 17 00:00:00 2001 From: MakerJanSky <137431968+MakerJanSky@users.noreply.github.com> Date: Mon, 27 Oct 2025 12:29:21 -0400 Subject: [PATCH 1/3] Correct tags --- Sky Atlas/Sky Atlas.html | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/Sky Atlas/Sky Atlas.html b/Sky Atlas/Sky Atlas.html index 54d716b..dbb8608 100644 --- a/Sky Atlas/Sky Atlas.html +++ b/Sky Atlas/Sky Atlas.html @@ -6802,7 +6802,7 @@

Sections & Primary Docs

If the Agent has an Operational Executor Agent then this responsibility is shared by Operational GovOps and the Operational Facilitator.

@@ -6813,7 +6813,7 @@

Sections & Primary Docs

Review By Core GovOps Core - The documents herein define the process for review of Agent Artifacts for their compliance with the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact. + The documents herein define the process for review of Agent Artifacts for their compliance with the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact. @@ -6821,7 +6821,7 @@

Sections & Primary Docs

Core GovOps Initiatives Review Of Agent Artifact Core - Core GovOps may review an Agent Artifact for its compliance with the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact at any time. This review may either be initiated by Core GovOps in response to an issue that has arisen or be conducted as part of a regular review process established by Core GovOps. + Core GovOps may review an Agent Artifact for its compliance with the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact at any time. This review may either be initiated by Core GovOps in response to an issue that has arisen or be conducted as part of a regular review process established by Core GovOps. @@ -6829,7 +6829,7 @@

Sections & Primary Docs

Core GovOps Shares Initial Findings With Agent Core - If Core GovOps identifies deficiencies in an Agent Artifact relative to the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact, Core GovOps shares those findings with the Agent and its Operational Executor Agent, if applicable. + If Core GovOps identifies deficiencies in an Agent Artifact relative to the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact, Core GovOps shares those findings with the Agent and its Operational Executor Agent, if applicable. @@ -6853,7 +6853,7 @@

Sections & Primary Docs

Remediation By Agent Core - The Agent must submit a Root Edit Proposal to update its Artifact to address the deficiencies identified in the final set of findings (see A.1.14 - Publication Of Final Findings By Core GovOps). If the Agent does not, Core GovOps may propose an Atlas Edit Proposal to directly modify the Agent Artifact to address the deficiencies. + The Agent must submit a Root Edit Proposal to update its Artifact to address the deficiencies identified in the final set of findings (see A.1.14 - Publication Of Final Findings By Core GovOps). If the Agent does not, Core GovOps may propose an Atlas Edit Proposal to directly modify the Agent Artifact to address the deficiencies. @@ -6869,7 +6869,7 @@

Sections & Primary Docs

Penalties Core - Penalties for an Agent failing to meet the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact will be specified in a future iteration of the Atlas. + Penalties for an Agent failing to meet the requirements specified in A.1.14 - Responsibility To Maintain Agent Artifact will be specified in a future iteration of the Atlas. @@ -6885,7 +6885,7 @@

Sections & Primary Docs

Process For Carrying Out Changes Core - Updates to Agent Artifacts to conform to changes in specifications may either be carried out by each Agent (see A.1.14 - Changes By Agents) or carried out directly by Core GovOps (see A.1.14 - Changes By Core GovOps). If Core GovOps chooses to directly carry out the changes, it must communicate this directly to the affected Agents before submitting an Atlas Edit Proposal. Otherwise the process for changes carried out by Agents applies. + Updates to Agent Artifacts to conform to changes in specifications may either be carried out by each Agent (see A.1.14 - Changes By Agents) or carried out directly by Core GovOps (see A.1.14 - Changes By Core GovOps). If Core GovOps chooses to directly carry out the changes, it must communicate this directly to the affected Agents before submitting an Atlas Edit Proposal. Otherwise the process for changes carried out by Agents applies. @@ -8579,7 +8579,7 @@

Sections & Primary Docs

Limitations On Usage Of Root Edit Primitive Prior To Tokens Being Publicly Held Core - Until the tokens of a Prime Agent are Publicly Held, as defined in A.2.4 - Publicly Held Definition, the Root Edit Primitive will not be operational. Instead, if a Prime Agent wishes to edit its Agent Artifact, it must use the customary Atlas Edit Proposal processes specified in the Sky Core Atlas at A.1.11 - A2 - Weekly Governance Cycle - Atlas Edit Weekly Cycle or A.1.12 - A2 - Monthly Governance Cycle - Atlas Edit Monthly Cycle. The process for Prime Agents to use the Atlas Edit Proposal process is further specified in A.2.4 - Atlas Edit Proposal Process For Prime Agents. + Until the tokens of a Prime Agent are Publicly Held, as defined in A.2.4 - Publicly Held Definition, the Root Edit Primitive will not be operational. Instead, if a Prime Agent wishes to edit its Agent Artifact, it must use the customary Atlas Edit Proposal processes specified in the Sky Core Atlas at A.1.11 - A2 - Weekly Governance Cycle - Atlas Edit Weekly Cycle or A.1.12 - A2 - Monthly Governance Cycle - Atlas Edit Monthly Cycle. The process for Prime Agents to use the Atlas Edit Proposal process is further specified in A.2.4 - Atlas Edit Proposal Process For Prime Agents. @@ -8602,7 +8602,7 @@

Sections & Primary Docs

Atlas Edit Proposal Process For Prime Agents Core - Prime Agents that do not have an operational Root Edit Primitive must work with Core GovOps to use the Atlas Edit Weekly Cycle (see A.1.11 - A2 - Weekly Governance Cycle - Atlas Edit Weekly Cycle) process to update their Agent Artifacts, as specified in the documents herein. + Prime Agents that do not have an operational Root Edit Primitive must work with Core GovOps to use the Atlas Edit Weekly Cycle (see A.1.11 - A2 - Weekly Governance Cycle - Atlas Edit Weekly Cycle) process to update their Agent Artifacts, as specified in the documents herein. @@ -14601,7 +14601,7 @@

Sections & Primary Docs

Subsequent Allocation Mechanism Core - After the initial cash grant (see A.2.10 - Initial Allocation Mechanism) but before the SPK or GROVE token is decentralized enough to allow meaningful governance by token holders, the respective founding teams may propose subsequent cash grants to their Prime Foundations. Sky must consent to each subsequent cash grant via approving the Sky Atlas modification. + After the initial cash grant (see A.2.10 - Initial Allocation Mechanism) but before the SPK or GROVE token is decentralized enough to allow meaningful governance by token holders, the respective founding teams may propose subsequent cash grants to their Prime Foundations. Sky must consent to each subsequent cash grant via approving the Sky Atlas modification. @@ -14617,7 +14617,7 @@

Sections & Primary Docs

Genesis Capital Backstop Core - Each genesis capital allocation is subject to the Genesis Capital Backstop (see A.3.9 - Genesis Capital Backstop). + Each genesis capital allocation is subject to the Genesis Capital Backstop (see A.3.9 - Genesis Capital Backstop). @@ -18085,7 +18085,7 @@

Sections & Primary Docs

Calculate Risk Weighted Assets Core - Credit RWA, Market RWA, Counterparty Credit Risk RWA, and Credit Valuation Adjustment RWA are calculated by multiplying the Exposure At Default (see A.3.3 - Calculate Exposure At Default Including Credit Risk Mitigation) by the applicable Risk Weights (see A.3.3 - Determine Risk Weights). + Credit RWA, Market RWA, Counterparty Credit Risk RWA, and Credit Valuation Adjustment RWA are calculated by multiplying the Exposure At Default (see A.3.3 - Calculate Exposure At Default Including Credit Risk Mitigation) by the applicable Risk Weights (see A.3.3 - Determine Risk Weights). @@ -18101,7 +18101,7 @@

Sections & Primary Docs

Apply Leverage Adjustment Core - The fifth step is to adjust the Aggregate RWA specified in A.3.3 - Aggregate Risk Weighted Assets for leverage (see CRE99.128-133). + The fifth step is to adjust the Aggregate RWA specified in A.3.3 - Aggregate Risk Weighted Assets for leverage (see CRE99.128-133). @@ -18109,7 +18109,7 @@

Sections & Primary Docs

Determine Required Risk Capital Core - The final step is to multiply the adjusted Aggregate RWA specified in A.3.3 - Apply Leverage Adjustment by an 8% capital ratio to arrive at Instance Financial RRC. + The final step is to multiply the adjusted Aggregate RWA specified in A.3.3 - Apply Leverage Adjustment by an 8% capital ratio to arrive at Instance Financial RRC. @@ -21655,7 +21655,7 @@

Sections & Primary Docs

Genesis Capital Backstop - Implementation Core -

In the near term, transfers are made through Executive Votes and may be made through Emergency Spells (see A.1.9 - A4 - Sky Core Governance Security - Emergency Spells) as part of the Emergency Response System (see A.1.8 - A1 - Emergency Response System - Emergency Response)

A solution must be developed to allow these transfers to be accomplished on an automated basis without waiting for the GSM Pause Delay (see A.1.9 - A2 - Sky Core Governance Security - Governance Security Delay Requirements).

. +

In the near term, transfers are made through Executive Votes and may be made through Emergency Spells (see A.1.9 - A4 - Sky Core Governance Security - Emergency Spells) as part of the Emergency Response System (see A.1.8 - A1 - Emergency Response System - Emergency Response)

A solution must be developed to allow these transfers to be accomplished on an automated basis without waiting for the GSM Pause Delay (see A.1.9 - A2 - Sky Core Governance Security - Governance Security Delay Requirements).

. @@ -21671,7 +21671,7 @@

Sections & Primary Docs

Genesis Capital Backstop - Genesis Agent Capital Shortfalls Core - Transfers of capital from Genesis Agents may cause capital shortfalls for Genesis Agents under the Risk Framework (see A.3.3). Sky will work in good faith with such Agents to waive penalties for a reasonable period of time to allow the Agents to rebuild their capital. + Transfers of capital from Genesis Agents may cause capital shortfalls for Genesis Agents under the Risk Framework (see A.3.3). Sky will work in good faith with such Agents to waive penalties for a reasonable period of time to allow the Agents to rebuild their capital. From d2c0e5ce74c564caff429d1fe4d61d895f4b96cf Mon Sep 17 00:00:00 2001 From: MakerJanSky <137431968+MakerJanSky@users.noreply.github.com> Date: Tue, 28 Oct 2025 13:59:14 -0400 Subject: [PATCH 2/3] Fixing punctuation --- Sky Atlas/Sky Atlas.html | 150 +++++++++++++++++++-------------------- 1 file changed, 75 insertions(+), 75 deletions(-) diff --git a/Sky Atlas/Sky Atlas.html b/Sky Atlas/Sky Atlas.html index dbb8608..74f1101 100644 --- a/Sky Atlas/Sky Atlas.html +++ b/Sky Atlas/Sky Atlas.html @@ -467,7 +467,7 @@

Articles

Risk Capital Article - Prime Agents who invest capital from Sky’s Collateral Portfolio using the Allocation System Primitive must hold Risk Capital to protect Sky from potential losses on these investments. This Article sets forth the framework governing Risk Capital. + Prime Agents who invest capital from Sky's Collateral Portfolio using the Allocation System Primitive must hold Risk Capital to protect Sky from potential losses on these investments. This Article sets forth the framework governing Risk Capital. @@ -1675,7 +1675,7 @@

Sections & Primary Docs

  1. the Aligned Delegates ranked as Ranked Delegate on a daily basis;
  2. the budget to be deposited into each Aligned Delegate's AD Buffer, which is modified pursuant to voting and communication metrics;
    3. -
  3. the balance of each Aligned Delegate’s AD Buffer; and
    4. +
  4. the balance of each Aligned Delegate's AD Buffer; and
  5. the amount to be paid out to each Aligned Delegate.Once calculated by the Core Facilitator, AD payouts are bundled into the next Executive Vote.
@@ -1694,7 +1694,7 @@

Sections & Primary Docs

Aligned Delegates - Budget And Participation Requirements - Payout Limitations For ADs Triggering Atlas Edit Weekly Cycle Proposals Core - If an AD has triggered an Atlas Edit Weekly Cycle Proposal pursuant to A.1.11 - Weekly Governance Cycle - Atlas Edit Weekly Cycle - Triggering Requirement, no payouts may be made that would reduce their AD Buffer below one (1) month’s worth of the budget specified in A.1.5 - Aligned Delegates - Budget And Participation Requirements - Budget Amount For Ranked Delegate Slots until the Proposal has been voted on or rejected by the Core Facilitator for misalignment. + If an AD has triggered an Atlas Edit Weekly Cycle Proposal pursuant to A.1.11 - Weekly Governance Cycle - Atlas Edit Weekly Cycle - Triggering Requirement, no payouts may be made that would reduce their AD Buffer below one (1) month's worth of the budget specified in A.1.5 - Aligned Delegates - Budget And Participation Requirements - Budget Amount For Ranked Delegate Slots until the Proposal has been voted on or rejected by the Core Facilitator for misalignment. @@ -1718,7 +1718,7 @@

Sections & Primary Docs

Aligned Delegates - Budget And Participation Requirements - Voting-Activity Metrics Section -

The budget stream allocated to a Ranked Delegate (RD) is modified based on their voting-activity metrics over the past six (6) months. This budget modification takes into account the overall participation of the Ranked Delegate in all votes they are eligible to cast as an Aligned Delegate (AD).

If an RD participates in less than 95% of all eligible votes within the last six (6) months, their RD budget stream is reduced. The reduction is applied on a proportional linear scale: for every percentage point below 95% voting activity, the RD’s budget is reduced correspondingly.

Should an RD’s voting activity fall to 75% of all eligible votes within the last six (6) months, they become completely ineligible to receive RD income. Their RD rank, and the budget eligibility associated with that rank, is transferred to the next highest-ranking AD, as determined by total amount of SKY delegated to their Delegate Contract.

+

The budget stream allocated to a Ranked Delegate (RD) is modified based on their voting-activity metrics over the past six (6) months. This budget modification takes into account the overall participation of the Ranked Delegate in all votes they are eligible to cast as an Aligned Delegate (AD).

If an RD participates in less than 95% of all eligible votes within the last six (6) months, their RD budget stream is reduced. The reduction is applied on a proportional linear scale: for every percentage point below 95% voting activity, the RD's budget is reduced correspondingly.

Should an RD's voting activity fall to 75% of all eligible votes within the last six (6) months, they become completely ineligible to receive RD income. Their RD rank, and the budget eligibility associated with that rank, is transferred to the next highest-ranking AD, as determined by total amount of SKY delegated to their Delegate Contract.

@@ -1726,7 +1726,7 @@

Sections & Primary Docs

Aligned Delegates - Budget And Participation Requirements - Voting-Communication Metrics Section -

The budget stream allocated to a Ranked Delegate (RD) is modified based on their voting-communication metrics over the past six (6) months. An AD is required to provide an explanation for each vote they participate in. This budget modification takes into account the Ranked Delegate’s fulfillment of this voting-communication requirement in all votes they are eligible to cast as an Aligned Delegate (AD).

If an RD provides the required voting-communication on less than 95% of all eligible votes within the last six (6) months, their RD budget stream is reduced. The reduction is applied on a proportional linear scale: for every percentage point below 95% voting-communication activity, the RD’s budget is reduced correspondingly.

Should an RD’s voting-communication activity fall to 75% of all eligible votes within the last six (6) months, they become completely ineligible to receive RD income. Their RD rank, and the budget eligibility associated with that rank, is transferred to the next highest-ranking AD, as determined by total amount of SKY delegated to their Delegate Contract.

+

The budget stream allocated to a Ranked Delegate (RD) is modified based on their voting-communication metrics over the past six (6) months. An AD is required to provide an explanation for each vote they participate in. This budget modification takes into account the Ranked Delegate's fulfillment of this voting-communication requirement in all votes they are eligible to cast as an Aligned Delegate (AD).

If an RD provides the required voting-communication on less than 95% of all eligible votes within the last six (6) months, their RD budget stream is reduced. The reduction is applied on a proportional linear scale: for every percentage point below 95% voting-communication activity, the RD's budget is reduced correspondingly.

Should an RD's voting-communication activity fall to 75% of all eligible votes within the last six (6) months, they become completely ineligible to receive RD income. Their RD rank, and the budget eligibility associated with that rank, is transferred to the next highest-ranking AD, as determined by total amount of SKY delegated to their Delegate Contract.

@@ -1742,7 +1742,7 @@

Sections & Primary Docs

Aligned Delegates - Budget And Participation Requirements - Signal Account Requirement Core -

RDs are required to maintain an active Signal account to facilitate communications related to emergency / urgent situations. This requirement applies regardless of whether an RD has been appointed to the Emergency Response Group. See A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. RDs must provide their Signal username to the Core Facilitator.

The Core Facilitator is responsible for maintaining an internal registry of RDs’ Signal accounts. Because the ranked RDs are continually changing, the Core Facilitator must ensure that the internal registry is maintained on a frequent basis. The Core Facilitator must check the active status of the RDs’ Signal accounts by sending test messages and confirming the RDs’ timely response; this must be done regularly, on a schedule known only to the Core Facilitator. If an RD fails to timely respond to the test messages, the Core Facilitator must remove them from RD status.

+

RDs are required to maintain an active Signal account to facilitate communications related to emergency / urgent situations. This requirement applies regardless of whether an RD has been appointed to the Emergency Response Group. See A.1.8 - Emergency Response System - Emergency Response - Emergency Response Signal Group. RDs must provide their Signal username to the Core Facilitator.

The Core Facilitator is responsible for maintaining an internal registry of RDs' Signal accounts. Because the ranked RDs are continually changing, the Core Facilitator must ensure that the internal registry is maintained on a frequent basis. The Core Facilitator must check the active status of the RDs' Signal accounts by sending test messages and confirming the RDs' timely response; this must be done regularly, on a schedule known only to the Core Facilitator. If an RD fails to timely respond to the test messages, the Core Facilitator must remove them from RD status.

@@ -1942,7 +1942,7 @@

Sections & Primary Docs

Emergency Response System - Emergency Response - Definition Of Emergency Situations Core -

An emergency situation is any situation that would require immediate intervention to prevent initiation of Emergency Shutdown, severe peg divergence, or harm to members and users of the Ecosystem.

Pursuant to A.0.1 - Atlas Preamble - General Provisions - Facilitators’ Broad Discretionary Capacity, the Facilitators have broad discretion to apply the emergency-situation processes defined in A.1.8 - A1 - Emergency Response System - Emergency Response to urgent situations. Urgent situations are defined as any situation that involves a time-sensitive matter that would need an expedited governance process, where following a standard governance cycle would be too slow, risk a larger problem, or constitute an important missed opportunity.

+

An emergency situation is any situation that would require immediate intervention to prevent initiation of Emergency Shutdown, severe peg divergence, or harm to members and users of the Ecosystem.

Pursuant to A.0.1 - Atlas Preamble - General Provisions - Facilitators' Broad Discretionary Capacity, the Facilitators have broad discretion to apply the emergency-situation processes defined in A.1.8 - A1 - Emergency Response System - Emergency Response to urgent situations. Urgent situations are defined as any situation that involves a time-sensitive matter that would need an expedited governance process, where following a standard governance cycle would be too slow, risk a larger problem, or constitute an important missed opportunity.

@@ -1969,7 +1969,7 @@

Sections & Primary Docs

The membership of the Emergency Response Group is defined as Active Data in A.1.8 - Emergency Response Group Current Membership.

The Active Data is updated as follows:

@@ -2044,7 +2044,7 @@

Sections & Primary Docs

Emergency Response System - Emergency Response - Changes To Approved Emergency Contact Mechanisms Core - The Governance Facilitators may recommend changing the approved emergency contact mechanism specified in A.1.8 - Emergency Response System - Emergency Response - Approved Emergency Contact Mechanisms, but they must do so in consultation with the Protocol Security Workstream Lead. The Governance Facilitators’ recommendation is subject to a poll through the Operational Weekly Governance Cycle. + The Governance Facilitators may recommend changing the approved emergency contact mechanism specified in A.1.8 - Emergency Response System - Emergency Response - Approved Emergency Contact Mechanisms, but they must do so in consultation with the Protocol Security Workstream Lead. The Governance Facilitators' recommendation is subject to a poll through the Operational Weekly Governance Cycle. @@ -2056,9 +2056,9 @@

Sections & Primary Docs

- A.1.8 - Emergency Response System - Emergency Response - Facilitators’ Roles And Responsibilities + A.1.8 - Emergency Response System - Emergency Response - Facilitators' Roles And Responsibilities - Emergency Response System - Emergency Response - Facilitators’ Roles And Responsibilities + Emergency Response System - Emergency Response - Facilitators' Roles And Responsibilities Core

The Support Facilitators are empowered to declare an emergency situation, in consultation with the responsible Facilitator of the impacted Scope(s) and any relevant Scope Advisor(s).

After an emergency situation has been declared, the Support or Governance Facilitators are responsible for coordinating emergency-situation processes to ensure they are civil, consistently applied and aligned. The Governance Facilitators are responsible for publishing Polls and Executive Votes.

Any participant in the Sky Ecosystem, including Ecosystem Actors, Aligned Delegates or other community members, can request that the Support Facilitators declare an emergency. The Support Facilitators are granted broad discretion in handling such requests.

@@ -2162,7 +2162,7 @@

Sections & Primary Docs

Emergency Response System - Emergency Response - Accountability Measures for Ecosystem Actor Individuals And Teams Core -

For Ecosystem Actors appointed to the Emergency Response Group, fulfilling the responsibilities of this role is as critical to their overall performance evaluation as their customary deliverables.

The Support Facilitators and Protocol Security Workstream Lead are required to document all instances of Emergency Response Group Members’ failure to meet emergency-preparedness requirements. Given their domain expertise and proximity to each emergency situation, the Support Facilitators and Protocol Security Workstream Lead are granted the discretion to evaluate emergency-preparedness deficiencies. Generally, they are required to take swift action to address non-negligible emergency-preparedness deficiencies in the following manner.

If the deficient Emergency Response Group Member is an Ecosystem Actor individual, the individual should be removed from the Group.

If the deficient Emergency Response Group Member is part of an Ecosystem Actor team, the specific member who has failed to meet requirements should be removed from the Group.

If different Emergency Response Group Members from the same Ecosystem Actor team consistently fail to meet requirements, the Ecosystem Actor team as a whole should be removed from the Group.

The removal of a Member from the Group is done at the discretion of the Support Facilitators and the Protocol Security Workstream Lead. However, the Support Facilitators and Protocol Security Workstream Lead may not proceed with removal unless it is supported with clear documentation. Such documentation must be made available to all Emergency Response Group Members for review.

When an Ecosystem Actor is removed from the Emergency Response Group for deficient performance, the Support Facilitators must transparently announce this action via a post to the Sky Forum. Further, the removal must be incorporated into the evaluation of the Ecosystem Actor’s overall performance.

The Support Facilitators has the discretion to decide if documentation supporting the removal should be retained internally or publicly shared on the Forum (with redactions, if needed).

+

For Ecosystem Actors appointed to the Emergency Response Group, fulfilling the responsibilities of this role is as critical to their overall performance evaluation as their customary deliverables.

The Support Facilitators and Protocol Security Workstream Lead are required to document all instances of Emergency Response Group Members' failure to meet emergency-preparedness requirements. Given their domain expertise and proximity to each emergency situation, the Support Facilitators and Protocol Security Workstream Lead are granted the discretion to evaluate emergency-preparedness deficiencies. Generally, they are required to take swift action to address non-negligible emergency-preparedness deficiencies in the following manner.

If the deficient Emergency Response Group Member is an Ecosystem Actor individual, the individual should be removed from the Group.

If the deficient Emergency Response Group Member is part of an Ecosystem Actor team, the specific member who has failed to meet requirements should be removed from the Group.

If different Emergency Response Group Members from the same Ecosystem Actor team consistently fail to meet requirements, the Ecosystem Actor team as a whole should be removed from the Group.

The removal of a Member from the Group is done at the discretion of the Support Facilitators and the Protocol Security Workstream Lead. However, the Support Facilitators and Protocol Security Workstream Lead may not proceed with removal unless it is supported with clear documentation. Such documentation must be made available to all Emergency Response Group Members for review.

When an Ecosystem Actor is removed from the Emergency Response Group for deficient performance, the Support Facilitators must transparently announce this action via a post to the Sky Forum. Further, the removal must be incorporated into the evaluation of the Ecosystem Actor's overall performance.

The Support Facilitators has the discretion to decide if documentation supporting the removal should be retained internally or publicly shared on the Forum (with redactions, if needed).

@@ -2170,7 +2170,7 @@

Sections & Primary Docs

Emergency Response System - Emergency Response - Accountability Measures For Alignment Conservers Core -

For an Alignment Conserver who has been appointed to the Emergency Response Group, the requirements of this role become as critical to the assessment of their overall performance as their customary obligations.

The Support Facilitators and Protocol Security Workstream Lead are required to document all instances of Emergency Response Group Members’ failure to meet emergency-preparedness requirements. Given their domain expertise and proximity to each emergency situation, the Support Facilitators and Protocol Security Workstream Lead are granted the discretion to evaluate emergency-preparedness deficiencies. Generally, they are required to take swift action to address non-negligible emergency-preparedness deficiencies in the following manner.

Where the deficient Member is an Alignment Conserver, that Member should be derecognized pursuant to A.1.4 - Alignment Conservers - Accountability And Misalignment Handling - Adjudication Process.

Where the deficient Alignment Conserver is the Support Facilitators, the Protocol Security Workstream Lead and a majority of active Scope Facilitators must reach consensus in order to initiate a derecognition proceeding against the Support Facilitators. Once this threshold is met, the procedure defined in A.1.4 - Alignment Conservers - Accountability And Misalignment Handling - Adjudication Process should be followed. In the interim, other Scope Facilitators must step in temporarily to coordinate emergency response.

The initiation of derecognition is done at the discretion of the Support Facilitators (or other Scope Facilitator) and the Protocol Security Workstream Lead. However, the Support Facilitators and Protocol Security Workstream Lead may not proceed with removal unless it is supported with clear documentation. Such documentation must be made available to all Emergency Response Group Members for review.

When an Alignment Conserver is removed from the Emergency Response Group and derecognized for deficient performance, the Governance Facilitators must transparently announce this action pursuant to A.1.4 - Alignment Conservers - Accountability And Misalignment Handling - Derecognition Notice.

The Support Facilitators have the discretion to decide if documentation supporting the Alignment Conserver’s derecognition and removal should be retained internally or publicly shared on the Forum (with redactions, if needed).

+

For an Alignment Conserver who has been appointed to the Emergency Response Group, the requirements of this role become as critical to the assessment of their overall performance as their customary obligations.

The Support Facilitators and Protocol Security Workstream Lead are required to document all instances of Emergency Response Group Members' failure to meet emergency-preparedness requirements. Given their domain expertise and proximity to each emergency situation, the Support Facilitators and Protocol Security Workstream Lead are granted the discretion to evaluate emergency-preparedness deficiencies. Generally, they are required to take swift action to address non-negligible emergency-preparedness deficiencies in the following manner.

Where the deficient Member is an Alignment Conserver, that Member should be derecognized pursuant to A.1.4 - Alignment Conservers - Accountability And Misalignment Handling - Adjudication Process.

Where the deficient Alignment Conserver is the Support Facilitators, the Protocol Security Workstream Lead and a majority of active Scope Facilitators must reach consensus in order to initiate a derecognition proceeding against the Support Facilitators. Once this threshold is met, the procedure defined in A.1.4 - Alignment Conservers - Accountability And Misalignment Handling - Adjudication Process should be followed. In the interim, other Scope Facilitators must step in temporarily to coordinate emergency response.

The initiation of derecognition is done at the discretion of the Support Facilitators (or other Scope Facilitator) and the Protocol Security Workstream Lead. However, the Support Facilitators and Protocol Security Workstream Lead may not proceed with removal unless it is supported with clear documentation. Such documentation must be made available to all Emergency Response Group Members for review.

When an Alignment Conserver is removed from the Emergency Response Group and derecognized for deficient performance, the Governance Facilitators must transparently announce this action pursuant to A.1.4 - Alignment Conservers - Accountability And Misalignment Handling - Derecognition Notice.

The Support Facilitators have the discretion to decide if documentation supporting the Alignment Conserver's derecognition and removal should be retained internally or publicly shared on the Forum (with redactions, if needed).

@@ -5344,7 +5344,7 @@

Sections & Primary Docs

Sky Core Governance Security - Emergency Spells - Emergency Spells Definition Core - Emergency Spells are expedited ad hoc spells that, while typically compliant with all customary quality-assurance processes, do not adhere to the normal spell cadence. Emergency Spells solve the root issue of an emergency / urgent situation impacting the Protocol and are used when a rapid response time is needed. The Support and Governance Facilitators are responsible for managing the use of Emergency Spells pursuant to A.1.8 - Emergency Response System - Emergency Response - Facilitators’s Roles And Responsibilities and A.1.8 - Emergency Response System - Emergency Response - Known And Uncontentious Remedies. + Emergency Spells are expedited ad hoc spells that, while typically compliant with all customary quality-assurance processes, do not adhere to the normal spell cadence. Emergency Spells solve the root issue of an emergency / urgent situation impacting the Protocol and are used when a rapid response time is needed. The Support and Governance Facilitators are responsible for managing the use of Emergency Spells pursuant to A.1.8 - Emergency Response System - Emergency Response - Facilitators's Roles And Responsibilities and A.1.8 - Emergency Response System - Emergency Response - Known And Uncontentious Remedies. @@ -5360,7 +5360,7 @@

Sections & Primary Docs

Sky Core Governance Security - Emergency Spells - Standby Spells Definition Core -

Sky Protocol uses circuit-breakers to mitigate undesired scenarios, which circuit-breakers are called MOM contracts. MOM contracts must first be triggered through a spell, after which they bypass the GSM Pause Delay and can immediately act on the Protocol. See A.1.9 - Sky Core Governance Security - Governance Security Delay Requirements - Exceptions.

In emergency scenarios, time is a scarce resource. Therefore, Standby Spells are used in validated emergency scenarios to trigger a MOM contract. In an emergency situation, spell teams can then focus on crafting an ad hoc Emergency Spell to solve the root cause of an issue, if appropriate. Due to Standby Spells, it is no longer necessary in an emergency for spell teams to spend time crafting and reviewing a spell whose sole purpose is to trigger a mitigation of the issue, i.e., the MOM contract.

Standby Spells open new attack vectors that must be mitigated pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs’ Role In Standby Spells.

+

Sky Protocol uses circuit-breakers to mitigate undesired scenarios, which circuit-breakers are called MOM contracts. MOM contracts must first be triggered through a spell, after which they bypass the GSM Pause Delay and can immediately act on the Protocol. See A.1.9 - Sky Core Governance Security - Governance Security Delay Requirements - Exceptions.

In emergency scenarios, time is a scarce resource. Therefore, Standby Spells are used in validated emergency scenarios to trigger a MOM contract. In an emergency situation, spell teams can then focus on crafting an ad hoc Emergency Spell to solve the root cause of an issue, if appropriate. Due to Standby Spells, it is no longer necessary in an emergency for spell teams to spend time crafting and reviewing a spell whose sole purpose is to trigger a mitigation of the issue, i.e., the MOM contract.

Standby Spells open new attack vectors that must be mitigated pursuant to A.1.9 - Sky Core Governance Security - Emergency Spells - ADs' Role In Standby Spells.

@@ -5500,9 +5500,9 @@

Sections & Primary Docs

- A.1.9 - Sky Core Governance Security - Emergency Spells - Support Scope Facilitators’ Role In Standby Spells + A.1.9 - Sky Core Governance Security - Emergency Spells - Support Scope Facilitators' Role In Standby Spells - Sky Core Governance Security - Emergency Spells - Support Scope Facilitators’ Role In Standby Spells + Sky Core Governance Security - Emergency Spells - Support Scope Facilitators' Role In Standby Spells Core The role of the Support Facilitators in the Standby Spell process is as follows: