This document provides structural guidance for developing the governance framework around execution-time, intent-derived authority. It is intended as a reference for all contributors to the governance design process – not as the governance framework itself, but as a set of principles, constraints, and architectural decisions that should inform its development.

1. Design Orientation

1.1 Govern the system being proposed, not the system being replaced

Identity-based governance is built around permission grants, access reviews, role definitions, and audit trails that assume durable authority. The proposed framework assumes ephemeral, assembled, probabilistic authority. Every governance element should be tested against that difference. If a section could appear unchanged in a traditional IAM governance document, it has likely not gone far enough.

1.2 The governance framework is a protocol specification, not a policy document

Because the framework is designed for open commons adoption across disparate networks and implementations, governance should function like a protocol specification with governance principles – comparable to how the IETF structures RFCs. The goal is interoperability and trust, not uniformity. Implementations will vary. The governance framework defines what must be true for those implementations to trust each other.

1.3 Separate governance of the framework from governance through the framework

These are two distinct concerns and should be treated as such throughout the document.

Governance of the framework addresses how the system itself is managed: who sets constraints, how the inference model is trained and validated, how updates are introduced, and who has oversight of the framework’s evolution.

Governance through the framework addresses what the system does operationally: evaluating intent, applying constraints, making authorization decisions at execution time.

Conflating these produces a document that tries to be both a constitution and an operating manual. Maintain them as distinct layers.

2. Core Design Constraint: Trust Handoff Between Disparate Networks

The non-negotiable center of the governance framework is enabling trust handoff between networks running independent implementations. If two networks cannot establish mutual trust in each other’s authority decisions, the system fragments into islands and loses the network effect that makes it viable as infrastructure.

Every element in the governance framework should be evaluated against one question:

Does this element affect whether two independent implementations can trust each other’s authorization decisions?

If yes, it belongs in the mandatory core. If it supports better outcomes but does not break interoperability, it belongs in recommended guidance. If it is implementation-specific optimization, it belongs in advisory guidance.

3. Requirement Classification: MUST / SHOULD / MAY

Borrowing from RFC 2119 conventions, governance elements should be classified by their impact on interoperability and trust integrity.

3.1 MUST (Invariant Across All Implementations)

These elements are mandatory. Without them, trust handoff between disparate networks breaks, or the security properties of the model are compromised.

Authority function structure. Authority is derived from actor, intent, context, and constraints evaluated at execution time. Not because every implementation needs the same inference model, but because both sides of a trust handoff need to know what class of evaluation produced the decision.

Ephemeral authority. Authority exists only at the moment of evaluation. It is not durable and not reusable. If any implementation allows persistent authority tokens, it breaks the security model for every network that trusts its decisions. This property cannot be optional without undermining the entire architecture.

Inference pipeline integrity assurance. Two networks do not need to use the same PQC implementation, but each must be able to verify that the other’s inference pipeline has not been tampered with. This is where the cryptographic trust boundary lives.

Common constraint vocabulary. Not identical constraints, but a shared language for expressing them. Without this, one network’s authorization decision is semantically opaque to another. Networks do not need the same rules. They need to be able to read each other’s rules.

Decision confidence signaling. Each authorization decision must include a standardized confidence representation that can be interpreted across networks. Trust handoff requires not only the outcome of a decision, but the system’s confidence in that outcome.

3.2 SHOULD (Recommended but Implementation-Flexible)

These elements improve outcomes but do not break interoperability if implemented differently.

Inference model architecture. Different implementations may use different AI approaches for the selective retention layer. As long as the output meets trust handoff requirements, the internal mechanism is an implementation decision.

Telemetry and context fusion approach. Different environments will have different signal sources. A defense network and a commercial SaaS platform will not have the same behavioral inputs. The governance framework should define what categories of context are expected, not which specific signals are required.

Explainability standards. The appropriate level of decision auditability will differ across deployment contexts. Defense deployments and consumer applications have different requirements. A baseline expectation should exist that some level of decision reasoning is available at the trust boundary, but the depth and format remain implementation decisions.

3.3 MAY (Advisory, Context-Dependent)

These elements are fully at the discretion of the implementing network.

Constraint definitions. Each network defines its own acceptable intent patterns and behavioral boundaries. The governance framework provides the grammar, not the dictionary.

Hardware trust implementations. TPM, secure enclaves, attestation mechanisms – these will vary by environment. The requirement is that hardware-backed trust exists, not which specific mechanism is used.

Internal evaluation thresholds. How aggressive or permissive a given network’s intent inference is should be a local policy decision, as long as the trust handoff communicates the confidence level of the decision to the receiving network.

4. Trust Handoff Protocol

This is the critical interoperability mechanism – the equivalent of the TCP handshake for this framework. The protocol must enable two networks to establish the following:

Compliance verification. The other network’s authority decision was produced by an implementation that meets the MUST requirements defined in the governance framework.

Temporal integrity. The decision is current and ephemeral – it has not been replayed from a prior evaluation cycle.

Pipeline integrity. The inference pipeline that produced the decision had cryptographic integrity at the time of evaluation.

Revocation and isolation mechanisms. The protocol must support the ability to revoke trust in a peer network and isolate its decisions from the broader system when integrity cannot be assured.

Semantic interoperability. The constraint vocabulary used in the decision is mutually intelligible, even if the specific constraints differ.

If the trust handoff protocol is designed correctly, everything else can flex. Implementations can innovate, optimize, and adapt to context without breaking the ecosystem. This is the mechanism that enables the open commons property – a shared trust layer that no one controls but everyone can build on.

4.1 Decision Resolution Model

The governance framework must define how conflicts between inferred intent, contextual signals, and constraints are resolved.

At minimum, implementations must specify:

• Precedence hierarchy (e.g., constraints > context > intent)
• Conflict-handling behavior (block, constrain, escalate)
• Conditions under which ambiguity results in denial vs. restriction

5. Document Architecture: Three-Tier Structure

The governance framework document itself should be organized in three tiers to serve the full range of implementation contexts and the expected adoption sequence (constrained domains → academic formalization → regulated enterprise → commercial abstraction).

Tier 1: Principles

The philosophical and architectural foundation. These do not change.

This tier establishes: authority is ephemeral, governance is continuous, enforcement is inline, intent is inferred rather than declared, and authority is assembled from multiple signals rather than issued from a central source.

Tier 1 is the layer that a new contributor reads first to understand what this framework is and why it exists. It should be concise enough to fit on a single page while being precise enough to prevent misinterpretation.

Tier 2: Protocol Requirements

The MUST / SHOULD / MAY specifications that enable interoperability. This tier evolves through a standards process as implementations mature and edge cases emerge.

Tier 2 is where the trust handoff protocol lives. It is the layer that two independent implementers reference to ensure their systems can establish mutual trust. It is also the layer that regulatory and compliance reviewers will focus on.

This tier should be versioned explicitly. Changes to MUST requirements represent breaking changes and should be treated with the same rigor as a major protocol revision.

Tier 3: Implementation Guidance

Practical advice for building compliant systems in specific contexts. This is where flexibility lives and where the broader community contributes most actively.

Tier 3 is expected to be the largest section over time, as different deployment contexts (defense, critical infrastructure, healthcare, financial services, commercial SaaS, consumer applications) generate their own implementation patterns and best practices.

This tier does not require the same consensus process as Tier 2. It can grow organically as implementations proliferate, as long as the guidance does not contradict Tier 1 principles or Tier 2 requirements.

6. Governance Challenges Unique to This Architecture

6.1 Governing a system that is intentionally not fully observable

The BVSR-based variation process is designed to be large enough that adversaries cannot map it. This also means the people governing the system cannot fully map the variation space. This is a feature for security and a challenge for accountability. The governance model must provide meaningful oversight without requiring full deterministic visibility into the variation process. This is genuinely novel territory – most governance frameworks assume the governed system is at least theoretically fully observable.

6.2 Auditability of probabilistic decisions

Traditional audit models expect deterministic traceability: a specific identity was granted a specific permission, and that permission was exercised at a specific time. In a probabilistic, intent-derived system, the audit trail looks different. The governance framework needs to define what constitutes a sufficient audit record when the decision process is probabilistic. This affects regulatory compliance, legal liability, and dispute resolution.

6.3 Constraint language design

Traditional governance writes policies in terms of permissions (who can do what). This framework requires governance vocabulary built around acceptable intent patterns, behavioral boundaries, and contextual fitness thresholds. The constraint language should be developed before policy documents are written in it. If governance drafting begins using traditional policy language, the framework will drift back toward identity-based thinking through linguistic inertia.

6.4 Stewardship model

If the framework exists in open commons and is not controlled by any single entity, the governance framework itself needs a stewardship model – a defined process for how the framework evolves, who can propose changes to Tier 1 and Tier 2 elements, and how consensus is reached. Historical models include the Linux Foundation, the IETF, the W3C, and the Apache Software Foundation. Each has different tradeoffs around speed, inclusivity, and capture resistance. The stewardship model should be defined early, even if provisionally, because it shapes how potential collaborators evaluate whether to invest their time and expertise.

6.5 Minimum observability contract

While the variation space is intentionally not fully observable, the governance framework must define a minimum set of observable artifacts required for:

• Auditability
• Trust verification
• Dispute resolution

This defines what must be visible even when the full inference process is not.

6.6 Degradation and fallback behavior

The framework must define expected system behavior under reduced confidence or degraded inputs. This includes:

• Confidence thresholds for action
• Fallback constraints
• Escalation pathways

6.7 Second- and Third-Order Human/Organizational Impact

The intent-derived authority framework is designed as infrastructure, not as a behavioral intervention. Nevertheless, once deployed at scale it will produce second- and third-order effects on human judgment, organizational resilience, and the conditions under which people develop interpretive capacity.

Positive effects (second-order) When calibrated correctly, the framework actively hedges the judgment-density erosion described in Judgment as an Asset Class. By requiring proportionate, context-aware evaluation at the moment of action, it preserves developmental friction in irreversible decisions rather than abstracting it away. This maintains formation pathways for emerging leaders and distributes interpretive capacity more widely than static permission models. Over time it encourages intrinsic motivation (trajectory and contextual fitness) over extrinsic rule compliance, aligning organizational behavior with the “be better than yesterday” principle without relying on reward/punishment signals.

Risk vectors (third-order) If the inference pipeline becomes too performant or opaque, the opposite occurs: humans increasingly accept high-confidence outputs without interrogation, accelerating the very judgment-density collapse the asset-class framework warns against. Concentration risk simply migrates upward—from key individuals to the PQC-AI integrity layer itself—creating a new class of load-bearing dependencies. At the extreme, the system could inadvertently treat people as pure datapoints whose agency is optimized rather than honored, compressing the very human formation the framework exists to protect.

Governance-level mitigation These outcomes are not inevitable; they are governed. The trust-handoff protocol (Section 4) and MUST requirements (Section 3.1) already demand explainability, confidence signaling, and pipeline integrity—precisely the controls that keep the inference layer from becoming an unaccountable oracle. Tier 3 implementation guidance must explicitly protect formation pathways: calibrated friction for irreversible decisions, deliberate exposure to ambiguity for developing leaders, and systematic risk retirement so that tacit knowledge does not ossify. The stewardship model (Section 6.4) should treat preservation of distributed judgment density as a first-order design invariant, not a secondary outcome.

In short, the framework does not merely govern autonomous actors; it shapes the conditions under which humans remain the primary authors of their own trajectories. Governance that treats judgment as a real asset class—accumulating, degrading, concentrating, and hedgeable—ensures the system amplifies human capacity rather than quietly replacing it. This is the highest-order responsibility the governance framework carries.

7. Cross-Cutting Considerations

7.1 Adoption sequence awareness

The governance framework must accommodate four distinct adoption phases without requiring a rewrite at each transition: constrained domains (defense, critical infrastructure), academic formalization, regulated enterprise adoption, and commercial abstraction. The three-tier document architecture supports this by keeping Tier 1 stable across all phases while allowing Tier 3 to expand as new deployment contexts emerge.

7.2 Regulatory alignment

Different jurisdictions and industries have different regulatory requirements for authorization, audit, and accountability. The governance framework should be designed so that regulatory compliance is achievable at the implementation level (Tier 3) without requiring modifications to the core protocol (Tier 2). If a regulatory requirement would force a change to a MUST element, that signals a design problem in the framework, not a compliance problem in the implementation.

7.3 Adversarial governance considerations

The governance framework should account for the possibility that adversaries will attempt to influence the governance process itself – proposing changes to MUST requirements that weaken the security model, contributing implementation guidance that introduces exploitable patterns, or capturing the stewardship process. The stewardship model should include safeguards against governance-level attacks, not just system-level attacks.

7.4 Drift detection

The framework must account for non-adversarial drift in:

• Constraint definitions
• Behavioral baselines
• Inference models

Mechanisms should exist to detect when system behavior deviates from intended governance boundaries over time.

8. Development Sequence Recommendation

The following sequence is recommended for governance framework development. Earlier items create foundations that later items depend on.

First: Tier 1 principles. Establish the invariant foundation. This is the shortest section but takes the longest to get right, because errors here propagate through everything that follows.

Second: Constraint vocabulary. Define the language before writing policy in it. This prevents linguistic drift toward identity-based governance patterns.

Third: Trust handoff protocol specification. This is the core interoperability mechanism. Until it exists, implementations cannot establish mutual trust, and the network effect that drives adoption cannot begin.

Fourth: MUST requirements (Tier 2 core). Define the mandatory elements that all implementations must satisfy. These should be as minimal as possible while still ensuring that trust handoff works and security properties hold.

Fifth: SHOULD and MAY guidance (Tier 2 extended). Fill in recommended practices and advisory guidance. This can evolve iteratively as implementation experience accumulates.

Sixth: Tier 3 implementation guidance. Begin with the first target deployment context (likely constrained domains or academic research environments) and expand as adoption progresses.

Seventh: Stewardship model. Formalize the process for framework evolution. This can begin as a provisional structure and mature alongside the framework itself, but it should exist in some form before the framework reaches external adoption.

---

See the Open Commons Statement