This post was rejected for the following reason(s):
This is an automated rejection. No LLM generated, heavily assisted/co-written, or otherwise reliant work. An LLM-detection service flagged your post as >50% likely to be written by an LLM. We've been having a wave of LLM written or co-written work that doesn't meet our quality standards. LessWrong has fairly specific standards, and your first LessWrong post is sort of like the application to a college. It should be optimized for demonstrating that you can think clearly without AI assistance.
So, we reject all LLM generated posts from new users. We also reject work that falls into some categories that are difficult to evaluate that typically turn out to not make much sense, which LLMs frequently steer people toward.*
"English is my second language, I'm using this to translate"
If English is your second language and you were using LLMs to help you translate, try writing the post yourself in your native language and using a different (preferably non-LLM) translation software to translate it directly.
"What if I think this was a mistake?"
For users who get flagged as potentially LLM but think it was a mistake, if all 3 of the following criteria are true, you can message us on Intercom or at team@lesswrong.com and ask for reconsideration.
you wrote this yourself (not using LLMs to help you write it)
you did not chat extensively with LLMs to help you generate the ideas. (using it briefly the way you'd use a search engine is fine. But, if you're treating it more like a coauthor or test subject, we will not reconsider your post)
your post is not about AI consciousness/recursion/emergence, or novel interpretations of physics.
If any of those are false, sorry, we will not accept your post.
* (examples of work we don't evaluate because it's too time costly: case studies of LLM sentience, emergence, recursion, novel physics interpretations, or AI alignment strategies that you developed in tandem with an AI coauthor – AIs may seem quite smart but they aren't actually a good judge of the quality of novel ideas.)
This document presents an initial conceptual proposal. The architecture described here is not a final technical model and does not claim exhaustive precision in operational details.
The content emerged from a structural intuition about international coordination in advanced AI. The formal elaboration was expanded with the assistance of AI tools to turn that intuition into a comprehensible technical structure.
The author does not claim full technical mastery over all the layers described in this document; it is a conceptual framework designed to be analyzed, criticized, refined, and, if useful, integrated by specialized teams.
Contact: [kedileyg@gmail.com]
0. EXECUTIVE SUMMARY
This document presents the complete specification of an institutional infrastructure designed to enable safe coordination between countries in the development and operation of advanced AI systems, even under conditions of structural distrust, technological competition, and absence of external political guarantees.
The infrastructure establishes:
formal mechanisms for verifiability;
institutional state machines;
standardized critical flows (pseudo-APIs);
reusable operational patterns;
structural barriers against hegemony;
systematic protection of sensitive content;
institutional incentives that make cooperation more advantageous than unilateral racing.
The document consolidates vision, architecture, institutional engineering, and operational patterns into a technically rigorous format, suitable for analysis by government teams, research institutes, technical committees, and international governance structures.
Scope Note — Nature of the Document
This document presents the core architectural concept of a possible international infrastructure for safe coordination in advanced AI. It describes structural principles, institutional modules, and operational relationships at a conceptual level.
It is not a treaty, not a legal model, not a diplomatic proposal, and not a final operational specification. Political, legal, and practical implementation aspects belong to later phases led by multidisciplinary teams.
The goal here is to formalize the architectural foundation that such teams may use, adapt, or expand.
1. INTRODUCTION
1.1 Technical Context
At the conceptual level adopted in this document, the development of advanced AI takes place in an environment characterized by:
information asymmetry between countries;
strategic uncertainty about others’ capabilities;
lack of independent verification;
globally interdependent risks;
strong incentives for unilateral acceleration.
The infrastructure specified here is designed to operate precisely in scenarios where there is no political trust, but where the absence of coordination increases systemic risk. It replaces bilateral trust with verifiable institutional mechanisms.
1.2 Structural Coordination Problem
The absence of safe coordination arises from factors that cannot be resolved by traditional treaties:
Observation asymmetry: countries cannot reliably verify others’ capabilities, intentions, or internal safety measures.
Lack of independent verification mechanisms: non-auditable commitments are structurally unstable.
Strong competitive incentives: technological racing shrinks the space for prudence.
Risk of hegemony: fear of dominating or being dominated undermines multilateral agreements.
Lack of neutral governance: traditional structures are perceived as capturable.
Insufficient political trust: non-scalable, volatile, and inadequate for highly sensitive systems.
The infrastructure responds to this problem through structural, not political, mechanisms.
Complementary note: The political, legal, and diplomatic dynamics that influence these coordination failures are not addressed in this document. Here we describe only the conceptual architecture capable of handling such failures when implemented by future real-world structures.
1.3 Institutional Motivation — Premium Version
Technical excerpt (uniformized): “The infrastructure operates as an institutional mechanism designed to enable safe coordination between countries under conditions of persistent distrust, by articulating verifiability, risk control, and operational symmetry through integrated modules.”
Structuring context: “The conceptual motivation is to reduce coordination failures that arise when countries lack mechanisms for mutual trust but need to avoid competitive dynamics in advanced AI.”
1.4 Institutional Role
The infrastructure performs specific functions:
Neutral institutional intermediary for cooperation in higher-risk AI.
Verification mechanism with continuous and on-demand audits.
High-risk coordination system with controlled Subspaces of Functioning (SF).
Provider of structural anti-hegemony, preventing power concentration.
Automated state matrix (MCAS) for operational predictability.
Platform for emergent cooperation, generating positive incentives.
1.5 Negative Scope (uniformized)
Technical excerpt: “The negative scope excludes elements external to the architecture, including policy recommendations, diplomatic strategies, multilateral negotiations, or any governance mechanism not described in the system’s formal modules.”
Context: “This separation prevents interpretations that would extrapolate the technical character of the document.”
1.6 Document Structure (uniformized)
Technical excerpt: “The infrastructure stabilizes institutional interactions by structuring continuous verifiability, defined operational limits, and automatic responses to risk signals emitted by the core modules.”
Context: “The formulation is meant to ensure that cooperation remains operationally safer than unilateral competition.”
2. OVERALL ARCHITECTURE OF THE INFRASTRUCTURE
At the conceptual level, the architecture is organized into six main modules:
NGE — Structural Norms and Governance
IC — Central Infrastructure
MVA — Verification and Audit Mechanism
MCAS — Participation State Matrix
SF/CS — Subspaces of Functioning and Cooperative Vaults
MFS — Operational Metrics and Signaling
Each module operates under the invariants I1–I6: Symmetry, Anti-Hegemony, Architecture-Based Trust, Internal Transparency, Continuous Self-Verification, and Cooperation as Emergent Property.
2.1 Conceptual Layers
2.1.1 NGE — Structural Rules Layer
Defines:
immutable axioms (NGE-Constante);
evolvable parameters (NGE-Evolutivo);
jurisdiction scope (NGE-Jurisdição).
NGE is the normative source for all modules.
2.1.2 IC — Central Coordination Layer
Functions:
global event logging;
execution of rules defined by NGE;
orchestration of critical flows;
exposure of symmetric interfaces to all countries.
IC does not interpret rules; it simply applies them.
2.1.3 MVA — Verification and Audit Layer
Performs:
continuous checks;
on-demand audits;
analysis and synthesis of evidence;
emission of risk signals.
2.1.4 MCAS — Institutional States Layer
Defines and manages automatic transitions between:
Candidate
Active
Under Observation
Restricted
Suspended
Expelled
Former Participant
MCAS translates operational signals into institutional permissions.
2.1.5 SF/CS — Secure Execution Environments
SFs represent controlled environments with low, medium, or high risk.
Cooperative Vaults (CS) store sensitive artifacts, with the possibility of being locked under exception.
2.3.1 Boundaries between IC, MVA, and NGE-Jurisdiction
Element
Permissions and Restrictions
IC — Internal exposure
Makes available events, logs, and records as defined by NGE to participating countries.
IC — External exposure
Does not release raw data; only aggregated metrics authorized by NGE-Jurisdiction.
MVA — Allowed access
Full access to structured logs and authorized proofs.
MVA — Blocked access
No access to sensitive raw content stored in CS.
NGE-Jurisdiction
Defines what is inside IC, and what can be audited or exposed.
3. STRUCTURAL INVARIANTS (I1–I6)
The invariants are immutable principles that govern the entire system. They define limits, mandatory behaviors, and institutional properties that no module may violate.
3.1 I1 — Structural Symmetry Between Countries
Definition All participating countries must have structurally symmetric access to rules, interfaces, permissions, and institutional mechanisms. There are no privileged routes.
Purpose To prevent capture, power concentration, and operational differences that would compromise predictability or structural trust.
SF/CS: only proofs leave; raw content remains enclosed.
MFS: only aggregated metrics are exposed.
3.5 I5 — Continuous Self-Verification
Definition The infrastructure must verify itself permanently, with no structural blind spots.
Purpose To detect incidents quickly and avoid silent erosion of institutional security.
Applications
NGE: defines rhythms and minimum verification requirements.
IC: all relevant events are logged.
MVA: time-based, event-based, and volume-based checks.
MCAS: automatic, responsive transitions.
SF/CS: dense or moderate logging depending on risk level.
MFS: continuous signaling.
3.6 I6 — Cooperation as Emergent Property
Definition The architecture must structurally make cooperation more advantageous than unilateral competition.
Purpose To generate stability and predictability even under mutual distrust.
Applications
NGE: aligned institutional incentives.
IC: internal operational benefits.
MVA: lower risk for cooperative actors.
MCAS: states reward compliant behavior.
SF/CS: cooperative projects become more productive.
MFS: metrics make the value of cooperation explicit.
4. PSEUDO-APIs FOR CRITICAL FLOWS
The pseudo-APIs, described conceptually, formalize essential flows between modules. No new concepts are introduced — they simply systematize already defined processes.
4.1 SubmitAdhesionRequest
Purpose To request formal entry into the Central Infrastructure.
Inputs
CountryID
JustificationSummary
InitialCapabilitiesProfile
CommitmentToNGEConstante
Preconditions
Country is in the External Cooperation Environment (AEC) or currently “non-participant”.
Jurisdiction allows submission.
Process
IC registers the request.
MCAS validates basic criteria.
MVA performs minimal checks.
NGE applies adhesion rules.
Outputs
APPROVED → State set to “Active” and slot created.
REJECTED → Formal refusal.
4.2 RequestAudit
Purpose To request an institutional audit within the defined jurisdiction.
Inputs
RequesterCountryID
AuditScope
AuditReason
Preconditions
Country is not in state “Expelled”.
Scope is allowed by jurisdiction.
Process
IC registers the request.
MVA defines the effective scope.
MVA collects evidence.
Standardized analysis.
Report generation.
Outputs
AuditReportID
FindingsSummary
RiskSignals
4.3 ProposeNGEChange
Purpose To propose a change in parameters of NGE-Evolutivo.
Inputs
ProposerCountryID(s)
ParameterID
CurrentValue
ProposedValue
Rationale
ImpactAssessment
Preconditions
Parameter belongs to NGE-Evolutivo.
Proposing country(ies) are in a compatible MCAS state.
Process
IC registers the proposal.
MVA checks for invariant violations.
NGE conducts the decision process.
IC records the outcome.
Outputs
APPROVED
REJECTED (with formal justification)
4.4 CreateSFAndCooperativeVault
Purpose To create a Subspace of Functioning and its associated Cooperative Vault.
Inputs
InitiatingCountries[]
RiskLevel
ProjectPurpose
ExpectedDuration
VerificationRequirements
Preconditions
All countries are in compatible MCAS states.
Requested risk level is allowed.
Process
IC registers the proposal.
MCAS checks participant states.
MVA evaluates minimum verification requirements.
NGE confirms the scope.
IC creates the SF and CS.
Outputs
SF_ID
CS_ID
OperationalPolicyID
5. INSTITUTIONAL STATE MACHINES
Each state machine formalizes the institutional behavior of a module. They define possible states, transition conditions, and operational effects. None of these machines create rules; they only implement what has been defined in NGE, MVA, and IC.
5.1 MCAS — Participation State Matrix
MCAS translates verification signals and institutional events into formal states that define permissions.
5.1.1 Formal States
Candidate
Active
Under Observation
Restricted
Suspended
Expelled
Former Participant
5.1.2 Technical Description of States
State
Technical Description
Candidate
Country has applied and is awaiting validation and minimal checks.
Active
Full participation; full access to critical flows as allowed by NGE.
Under Observation
Moderate risk signals; conditioned access.
Restricted
Serious violation; reduced access; requires proofs of remediation.
Report produced with ID, summary, and risk signals.
Completed – Rejected
Request invalid or impossible to execute within jurisdiction.
5.2.3 Transition Table
Current State
Event
New State
Module
(None)
RequestAudit received
Created
IC
Created
Scope defined
In Scoping
MVA
In Scoping
Collection authorized
In Execution
MVA
In Execution
Processing completed
In Validation
MVA
In Validation
Report generated
Completed
MVA
Created–In Validation
Request infeasible
Completed – Rejected
MVA
5.2.4 Structural Role
The audit machine guarantees:
continuous verifiability;
integrity of evidence;
protection against misuse of the infrastructure;
uniform execution regardless of political climate.
5.3 SF — Subspace of Functioning Life Cycle
5.3.1 Formal States
In Creation
Active
In Shutdown
Archived
5.3.2 State Descriptions
State
Description
In Creation
Initial configuration after institutional approval.
Active
Operation according to defined risk level and requirements.
In Shutdown
Activities completed; shutdown audit is triggered.
Archived
Life cycle finished; records preserved in IC.
5.3.3 Transition Table
Current State
Event
New State
Module
(None)
CreateSF approved
In Creation
IC
In Creation
Configuration validated
Active
IC
Active
Planned termination
In Shutdown
IC/MVA
In Shutdown
Final audit completed
Archived
MVA/IC
5.3.4 Structural Role
The SF machine ensures:
controlled initialization of sensitive environments;
operation under verifiability;
mandatory final audit;
full traceability of the institutional life cycle.
5.4 CS — Cooperative Vault Life Cycle
5.4.1 Formal States
Active
Locked Under Exception
Closed
5.4.2 State Descriptions
State
Description
Active
Normal operation for sensitive artifacts under dense verifiability.
Locked Under Exception
Access suspended due to incident detected by MVA.
Closed
Planned finalization or closure after an exception.
5.4.3 Transition Table
Current State
Event
New State
Module
(None)
Creation tied to SF
Active
IC
Active
Critical situation
Locked Under Exception
MVA
Locked Under Exception
NGE decision
Active / Closed
NGE
Active
Normal closure
Closed
IC/MVA
5.4.4 Structural Role
The cooperative vault:
imposes immediate containment of incidents;
protects sensitive artifacts;
functions as an automated institutional defense mechanism;
implements exception policies defined in NGE.
6. OPERATIONAL PATTERNS (A, B, C)
The Patterns are reusable operational models for three classes of interaction between countries:
low/medium-risk cooperation (Pattern A),
high-risk sensitive projects (Pattern B),
response to critical incidents (Pattern C).
Each Pattern specifies objective, components used, typical flow, minimum parameters, and risks/observations, following a uniform template.
6.1 PATTERN A — Shared Research Agreement
6.1.1 Objective
To execute low or medium-risk cooperation with moderate verifiability and essential institutional control requirements.
6.1.2 Components Used
Module
Function
NGE
General rules applicable to the project.
IC
Flow registration and orchestration.
MVA
Moderate checks and on-demand audits.
MCAS
Control of participant permissions.
SF Low/Medium
Operational environment.
Individual/Simple CS
Basic storage.
MFS
Recording cooperation metrics.
6.1.3 Typical Flow
Proposal and initial validation by IC.
Creation of an SF compatible with the risk level.
Execution with moderate logging.
On-demand audits (MVA).
Metrics consolidation (MFS).
Institutional closure and archiving.
6.1.4 Minimum Parameters
Parameter
Value
Logging
Moderate
Audits
Periodic
Proofs
Key operations
MCAS States
Active / Observation
6.1.5 Risks / Observations (final uniformized)
“Moderate verifiability limits real-time anomaly detection and reduces the granularity of institutional control.”
6.2 PATTERN B — High-Risk Project in Cooperative Vault
6.2.1 Objective
To operate sensitive projects with maximum verifiability and strict artifact protection mechanisms.
6.2.2 Components Used
Module
Function
NGE
Specific rules for high risk.
IC
Creation of High-Risk SF and Cooperative CS; logging.
MVA
Frequent checks and continuous proofs of conformity.
MCAS
Participation restricted to fully reliable states.
High-Risk SF
Restricted operational environment.
Cooperative CS
Sensitive storage with exception locking.
MFS
Recording impact metrics.
6.2.3 Typical Flow
Proposal and validation by NGE/MVA.
Creation of High-Risk SF and Cooperative CS by IC.
Execution under dense logging.
Continuous conformity proofs (MVA).
Institutional responses to incidents.
Closure or continuation as decided by NGE.
6.2.4 Minimum Parameters
Parameter
Value
Logging
Dense
Audits
Frequent
Proofs
Every critical cycle
MCAS States
Active only
6.2.5 Risks / Observations (final uniformized)
“Operation at high risk depends on the effectiveness of continuous verification mechanisms and may be affected by temporary logging failures or audit latency.”
6.3 PATTERN C — Response to Critical Incident
6.3.1 Objective
To respond to critical events with predictable institutional transitions, stabilizing the system while risks are analyzed and mitigated.
6.3.2 Components Used
Module
Function
IC
Incident logging and activation of exception flows.
MVA
Detection, audit, escalation, and risk signaling.
MCAS
Automatic state adjustments.
NGE
Definition of exceptional policies.
SF/CS
Operational locking.
MFS
Impact recording.
6.3.3 Typical Flow
Initial detection by MVA or critical event.
Institutional alert emission.
Locking of affected SF and CS.
Automatic state adjustments in MCAS.
NGE deliberation for exceptional measures.
Stabilization and final logging by IC.
6.3.4 Minimum Parameters
Parameter
Value
Response time
Short
Logging
Complete
Audits
Mandatory post-incident
6.3.5 Risks / Observations (final uniformized)
“Response to critical incidents requires adequate intervention time from NGE; delays may prolong operational restrictions.”
7. INSTITUTIONAL CONSIDERATIONS
This section presents institutional considerations derived from invariants I1–I6. They belong exclusively to the architecture’s conceptual level. Diplomatic, legal, or concrete operational aspects are not treated here and will be defined in later layers by specialists.
The considerations below describe only the structural limits of the architectural core.
7.1 Structural Limits (uniformized)
Technical excerpt: “Structural limits derive directly from invariants I1–I6 and define constraints on symmetry, verifiability, data exposure, risk, and the decision-making capacity of operational modules.”
Context: “The function of these limits is to prevent isolated or asymmetric initiatives from compromising institutional stability.”
7.2 Operational Constraints
They derive from:
verifiability requirements;
the need for continuous logging;
protection of sensitive content;
exception policies defined by NGE.
7.3 Structural Dependencies
The infrastructure depends on:
risk signals from MVA;
correct execution by IC;
predictability from MCAS;
coherence of SF/CS;
consolidated metrics from MFS.
7.4 Residual Risks (uniformized)
Technical excerpt: “Residual risks include operational latency, temporary technical divergences, and dependence on IC for maintaining verifiability and flow integrity.”
This glossary defines institutional terms used in the infrastructure. The definitions are strictly technical and do not add new mechanisms.
NGE — Structural Norms and Governance Set of rules, axioms, and parameters that define the macro-institutional behavior of the infrastructure. Includes NGE-Constante (immutable), NGE-Evolutivo (adjustable under strict criteria), and NGE-Jurisdição (scope of what may be exposed or audited).
IC — Central Infrastructure Module responsible for recording events, implementing NGE rules, orchestrating critical flows, and maintaining operational symmetry among countries.
MVA — Verification and Audit Mechanism Subsystem responsible for continuous and on-demand audits, evidence validation, risk signaling, and institutional compliance analysis.
MCAS — Participation State Matrix Institutional mechanism that defines and manages formal states of participating countries (Candidate, Active, Under Observation, Restricted, Suspended, Expelled, Former Participant).
SF — Subspace of Functioning Regulated execution environment for cooperative projects, classified by risk levels (low, medium, high), with specific verifiability requirements.
CS — Cooperative Vault Institutional repository for sensitive artifacts. May operate in Active mode or be Locked Under Exception.
MFS — Operational Metrics and Signaling Layer responsible for consolidating internal metrics and producing aggregated signals for institutional assessment.
AEC — External Cooperation Environment International context outside the infrastructure. Has no access to internal logs, raw data, or sensitive content.
Low/Medium/High Risk Classification used by NGE and MVA to determine minimum verifiability, logging, and audit requirements in SFs and CSs.
Risk Signal Event categorized by MVA indicating instability, atypical behavior, or potential operational incident.
Moderate/Dense/Complete Logging Logging levels required by Patterns or risk levels. They determine the granularity and frequency of traceability.
Locked Under Exception State in which a CS or SF has operations suspended in response to a critical event detected by MVA.
Proofs of Conformity Verifiable evidence (not raw content) used by MVA to audit institutional and operational behavior.
The annexes are optional and may or may not accompany the delivered version of the document. They do not create new content — they only illustrate or exemplify structures already formalized.
Below are recommended annexes that can be included depending on the technical audience.
9.1 Transition Diagram — MCAS
Candidate → Active
Candidate → Candidate/External (REJECTED)
Active → Under Observation
Under Observation → Active
Under Observation → Restricted/Suspended
Restricted → Under Observation/Active
Suspended → Expelled
Suspended → Under Observation
All except Expelled → Former Participant
Expelled → Expelled (terminal)
9.2 Audit Diagram — MVA
Created → In Scoping → In Execution → In Validation → Completed
Created / In Scoping / In Execution / In Validation → Completed – Rejected
9.3 SF Life Cycle
In Creation → Active → In Shutdown → Archived
9.4 CS Life Cycle
Active → Locked Under Exception → Active / Closed
Active → Closed
9.5 Mini Precedence Table — Critical Incident
Order
Event
Responsible Module
Structural Outcome
1
Anomaly detection
MVA
Risk signal generation
2
Incident registration
IC
Formal log
3
Alert emission
MVA
MCAS/NGE notification
4
SF/CS locking
SF/CS
Operational interruption
5
State update
MCAS
Observation/Restricted/Suspended
6
Structural deliberation
NGE
Exceptional policies
9.X Future Specialization Layers
The architecture presented in this document constitutes the conceptual core of the infrastructure. Full implementation requires additional layers that lie outside the current scope.
Later layers, to be developed by multidisciplinary teams, include:
Legal layer: alignment with national and international legal systems;
Diplomatic layer: processes for adhesion, representation, and review;
Operational layer: technical protocols, audit standards, and cryptographic mechanisms;
Political layer: incentives, multilateral agreements, and institutional legitimacy.
These layers use the present core as a base but require their own processes and expertise.
AUTHOR’S LIMITATION STATEMENT
The conceptual formulation in this document was built on principles of coordination, symmetry, and institutional verifiability.
However, the author does not claim full technical expertise in the cryptographic, legal, or operational domains that would be necessary for practical implementation of this architecture.
This document should be read as an initial structural core — a “seed” architecture — whose purpose is to open space for serious technical analysis, not to replace the work of specialized teams that might expand it.
The proposal is offered as a contribution to international debate and as a starting point for reflection and the development of real-world solutions.
10. CLOSING OF THE DOCUMENT
This document consolidates:
the technical vision of the infrastructure;
the definition of its modules;
institutional foundations (I1–I6);
formalized critical flows;
state machines;
operational patterns;
functional boundaries;
institutional tables;
standardized terminology.
It provides countries, technical teams, and researchers with a clear operational basis to understand, analyze, and potentially implement the proposed infrastructure — without adding political, strategic, or diplomatic interpretations.
All descriptions presented here derive exclusively from the institutional behavior defined by modules NGE, IC, MVA, MCAS, SF/CS, and MFS.
This is a conceptual document submitted for review. If it falls within scope, I kindly request consideration for cross-posting on the AI Alignment Forum.