V. Protocol
Nexus protocol governance for smart licenses, role keys, entitlements, revocation, audit trails, and machine-readable institutional state.
Summary
This page defines the Protocol layer of Nexus Standardization. If IV. Registry explains where institutional state becomes records-valid, current, historical, correctable, and claim-bounded, then V. Protocol explains how selected recorded states may become machine-readable, enforceable, revocable, auditable, synchronized, and operationally protected across digital, institutional, platform, node, host, and controlled-room environments.
Protocol governance is the technical-governance architecture through which Nexus expresses designated roles, permissions, restrictions, entitlements, validity windows, revocations, smart licenses, role keys, no-bypass rules, audit trails, emergency holds, rollback logic, synchronization events, and protocol-bound correction. It makes governance operational without converting technical systems into hidden governors.
The source text correctly frames Protocol as the technical-governance architecture that expresses and enforces institutional state without replacing lawful authority. It emphasizes smart licenses, role keys, entitlements, no-bypass rules, revocation, audit trails, synchronization, emergency controls, correctionability, and the non-negotiable rule that technical effect must remain subordinate to constitutional truth.
Protocol is therefore not “government by software.”
It is not platform rule.
It is not autonomous code authority.
It is not a substitute for law.
It is not a substitute for governance.
It is not a substitute for Registry.
It is not a substitute for recognition.
It is not a substitute for public authority.
It is not a market infrastructure by default.
Protocol is the bounded technical expression of already-governed state.
Registry records the state.
Ontology defines the meaning.
Status defines what has been earned.
Governance authorizes the role.
Protocol expresses selected effects.
Correction can narrow, suspend, revoke, or reverse them.
In Nexus, code does not rule in place of governance.
Code follows governance.
5.1 Why Protocol Governance Is Necessary
Protocol governance is necessary because Nexus is not only a set of institutions, charters, reports, registries, councils, guilds, and public-good doctrines. It is also a digital, distributed, standards-bearing, AI-native, node-capable, platform-mediated, sovereignty-compatible, and realization-adjacent architecture.
Nexus must operate across:
members;
contributors;
councils;
guilds;
working groups;
domains;
public-safe reports;
Registry records;
Marketplace objects;
Digital Public Goods;
Foundry packages;
Studio workflows;
Academy environments;
public authority learning rooms;
nodes;
hosts;
hubs;
observatories;
national pathways;
regional pathways;
qualified enterprise providers;
sponsors;
strategic backers;
public-good software;
APIs;
AI agents;
dashboards;
data rooms;
role-bearing workspaces;
and eventually machine-assisted control-plane environments.
In such a system, governance cannot remain only textual, social, or procedural.
If governance remains only textual, it becomes difficult to enforce under scale.
If governance remains only social, it becomes vulnerable to informal power.
If governance remains only procedural, it may be bypassed through platform access or technical privilege.
Protocol governance exists to prevent those failures.
It allows Nexus to express certain recorded roles, permissions, restrictions, validity windows, and revocation states in machine-readable and machine-enforceable ways.
It makes governance operational without surrendering governance to code.
5.2 What Protocol Governance Means in Nexus
Within Nexus, protocol governance is the bounded technical-governance architecture through which designated institutional states, role permissions, access rights, restrictions, entitlements, validity windows, revocations, synchronization events, and no-bypass conditions are expressed in machine-readable form under lawful and governance-valid authority.
Protocol governance may include:
smart licenses;
role keys;
entitlement records;
access-control rules;
identity binding;
authorization scopes;
validity periods;
renewal rules;
revocation rules;
suspension logic;
no-bypass controls;
emergency holds;
rollback mechanisms;
audit trails;
synchronization events;
anchoring logic;
protocol-bound correction;
API permissions;
data-room permissions;
platform roles;
workflow signatures;
smart-license manifests;
node or host activation rules;
Studio workflow access rules;
Marketplace object status expressions;
Foundry package release permissions;
and machine-readable status signals.
Protocol governance is therefore not a separate constitutional layer.
It is a technical expression layer.
It does not decide what is true.
It expresses what the valid record says is true, within scope.
5.3 The Protocol Thesis of Nexus
The protocol thesis of Nexus is that a public-good-rooted, standards-bearing, federated, AI-native, and realization-capable architecture can remain trustworthy at scale only if governance-valid states can be expressed as bounded technical effect, while technical effect remains strictly subordinate to constitutional truth, lawful authority, Registry state, role separation, non-execution, and correctionability.
This thesis has several implications.
Technical permissions must follow recorded roles.
Role keys must follow role records.
Smart licenses must follow institutional authority.
Entitlements must follow status.
Platform access must follow governance.
Protocol effect must follow Registry.
Revocation must follow correction.
No-bypass logic must prevent privilege from sidestepping governance.
Audit trails must make technical effect reviewable.
Emergency holds must be powerful enough to protect integrity, but bounded enough not to become hidden rule.
AI and automation must follow controlled meaning and status.
Protocol makes Nexus more enforceable.
Subordination makes Protocol legitimate.
5.4 The Core Principle: Technical Effect Must Remain Subordinate to Constitutional Truth
The central principle of Nexus protocol governance is simple:
Technical effect must remain subordinate to constitutional truth.
This means that a technical permission, platform entitlement, role key, smart license, access token, workflow signature, API permission, or automated control state is never a source of original legitimacy by itself.
A role key does not create office.
A smart license does not create recognition.
A platform entitlement does not create standing.
A dashboard permission does not create public authority.
A node activation does not create sovereignty.
A provider API key does not create qualification unless qualification exists by record.
A Studio workflow permission does not create lawful decision authority.
A Marketplace badge does not create universal approval.
A technical state is valid only to the extent that it reflects an underlying valid state.
The sequence is:
constitutional order;
lawful or governance-valid authority;
ontology and controlled meaning;
status and scope;
Registry record;
protocol expression;
audit;
correction;
revocation where necessary.
If this sequence is reversed, code becomes a hidden sovereign.
Nexus must never allow that.
5.5 Protocol Is Not Autonomous Governance
Protocol governance is not autonomous governance.
It does not decide mission.
It does not amend charters.
It does not establish institutional roles.
It does not appoint council members.
It does not grant recognition independently.
It does not create public authority adoption.
It does not approve providers by itself.
It does not decide finance-readiness by itself.
It does not execute capital.
It does not certify legal compliance.
It does not replace human review where human review is required.
It does not override public law.
Protocol may enforce recorded decisions.
It may prevent unauthorized action.
It may narrow access.
It may revoke outdated permissions.
It may synchronize state.
It may preserve logs.
It may make bypass harder.
It may express governance in technical form.
But it does not originate the authority that it expresses.
That boundary is what makes Protocol safe for public-good, sovereign, institutional, and cross-border use.
5.6 Why Smart Licenses Exist
Smart licenses exist because static permissions are not sufficient for Nexus.
Nexus is dynamic. Roles change. Membership changes. Council terms expire. Provider qualifications narrow. Marketplace listings are updated. Public authority capacities shift. Nodes move from proposed to active, or from active to suspended. Foundry packages move from prototype to release candidate. Studio workflows may be withdrawn. Reports may be superseded. Public-safe states may be corrected. Entitlements may need immediate revocation.
A static credential cannot carry this complexity safely.
A smart license can.
A smart license is a governed technical instrument that expresses a defined permission, role, entitlement, restriction, validity window, condition, renewal requirement, suspension state, or revocation state in machine-readable form, tied to a Registry-bearing institutional state.
A smart license may express:
role authorization;
membership-linked access;
council-room access;
public-safe review access;
Marketplace contributor access;
provider portal permissions;
Foundry workspace permissions;
Studio workflow access;
node environment access;
host permissions;
Academy access;
API access;
data-room restrictions;
time-bound validity;
jurisdictional scope;
domain scope;
object-class scope;
renewal requirement;
suspension;
revocation;
and correction state.
Smart licenses allow Nexus to govern permissions with precision.
5.7 Smart Licenses Are Not Legal Licenses by Default
Smart licenses in Nexus must not be confused with sovereign, regulatory, professional, commercial, or statutory licenses.
A Nexus smart license is an internal protocol-governance instrument.
It may govern system participation, platform access, room access, role-bearing permission, machine-readable workflow authority, data access, smart-contract-style entitlement, or controlled use inside the Nexus architecture.
It does not by itself:
grant regulatory approval;
create professional licensure;
authorize procurement;
authorize public warning;
grant public authority;
approve deployment;
certify legal compliance;
approve securities activity;
underwrite investment;
insure risk;
authorize brokerage;
authorize lending;
create market execution rights;
or override domestic law.
This distinction must be explicit wherever smart-license terminology appears.
The word “license” in this context means bounded protocol permission under Nexus governance.
It does not mean public-law authority unless a separate lawful authority has granted that authority and the smart license merely expresses it within system scope.
5.8 Smart-License Design Requirements
A Nexus smart license should be designed with enough structure to prevent ambiguity.
At minimum, it should identify:
license subject;
license holder;
issuing authority or process;
Registry reference;
role class;
entitlement class;
permission scope;
prohibited uses;
validity start;
validity expiry;
renewal requirements;
suspension triggers;
revocation triggers;
public claims limits;
data handling obligations;
jurisdictional limits where relevant;
host or node limits where relevant;
audit requirements;
correction pathway;
emergency hold applicability;
and protocol synchronization rules.
A smart license without scope is dangerous.
A smart license without expiry may preserve stale power.
A smart license without revocation is weak.
A smart license without Registry reference becomes a parallel truth system.
A smart license without auditability cannot be trusted.
The license must be smart not only in technical design, but in governance design.
5.9 Role Keys as Technical Expressions of Institutional Role
Role keys are technical expressions of institutional role classes and authorized permissions.
They translate recorded role-bearing state into machine-usable control surfaces.
A role key may allow a person, institution, node, host, provider, platform component, API, or controlled workflow to perform a defined class of action inside Nexus.
A role key may enable:
entry into controlled rooms;
access to restricted documents;
contribution to report workspaces;
participation in public-safe review;
use of Studio workflows;
access to node environments;
activation of provider functions;
signing of designated workflow states;
issuance of bounded confirmations;
publication of permitted status labels;
access to Marketplace review tools;
use of Foundry packaging environments;
participation in council workspaces;
or interaction with Registry-linked APIs.
A role key is not merely a password.
It is a protocol expression of a recorded role.
The key follows the role.
The role follows the record.
The record follows the governance-valid process.
5.10 Role Keys Must Not Drift Into Hidden Authority
Role keys can be powerful. For that reason, Nexus must prevent role-key drift.
A person holding a role key does not become a constitutional authority.
A platform administrator managing keys does not become the real governor.
A host managing local access does not own the node.
A technical operator with admin privileges does not control institutional meaning.
A developer maintaining protocol tooling does not define the standard alone.
A provider with integration keys does not become endorsed.
A public authority participant with access does not become adopting authority.
A council workspace key does not create council membership unless the council appointment exists by record.
Role keys are instruments of expressed permission.
They are not sources of original legitimacy.
Nexus must maintain separation among:
institutional authority;
Registry state;
technical administration;
platform access;
role-key issuance;
and public claims.
This prevents technical centrality from becoming governance centrality.
5.11 Identity Binding
Protocol governance requires disciplined identity binding.
Smart licenses and role keys must attach to governed identities, not vague usernames, shared accounts, unverified emails, informal handles, or uncontrolled credentials.
Identity binding should define:
who or what holds the role;
whether the holder is a person, institution, service account, node, host, provider, system, agent, or workflow;
how the identity was verified;
what institution or role it is linked to;
what good-standing or status conditions apply;
what delegation is permitted;
whether delegation is prohibited;
what happens when the identity changes;
what happens on termination;
and how compromise is handled.
Weak identity destroys strong permission models.
A public-good architecture cannot tolerate ambiguity at the point where technical authority is exercised.
Identity in Protocol is not only authentication.
It is role-bearing institutional identity.
5.12 Delegation and Sub-Delegation
Protocol governance must address delegation.
A person or institution may receive a permission and need to delegate a limited operational function. For example, an institution may appoint a staff user to manage a workspace. A host may designate a node operator. A provider may designate technical contacts. A council chair may delegate document administration.
Delegation must be bounded.
A delegated user should not receive broader authority than the delegating record allows.
Sub-delegation should be prohibited unless expressly permitted.
Delegation should be:
recorded;
scoped;
time-bound where appropriate;
revocable;
auditable;
linked to the original authority;
and subject to conflict, confidentiality, data, and claims rules.
Delegation is often where hidden authority enters systems.
Nexus should treat delegation as a protocol-governance matter, not an informal convenience.
5.13 Entitlement Governance
Entitlement governance is one of the major functions of Protocol.
An entitlement is a defined access right, participation right, use right, workflow permission, technical capability, platform permission, data permission, or room entry right granted under a recorded state.
Entitlements may include:
member portal access;
guild workspace access;
council workspace access;
Academy pathway access;
public-safe review access;
controlled publication access;
Studio workflow use;
Foundry workspace use;
Marketplace review access;
provider portal access;
node system access;
host environment access;
data-room access;
API access;
role-key issuance;
smart-license activation;
report drafting permission;
public authority learning room access;
sponsor reporting-room access;
correction workflow access.
Entitlement governance is not merely access security.
It is institutional topology.
A controlled room is part of the structure of Nexus. Who may enter, what they may see, what they may do, and what they may claim must reflect the role and status architecture.
Access is not authority.
But access can create perceived authority.
That is why entitlement governance matters.
5.14 Entitlement Boundaries
Every entitlement should have boundaries.
It should define:
what is permitted;
what is prohibited;
what the user may access;
what the user may not access;
whether the user may read, comment, edit, approve, publish, sign, export, or share;
what data may be downloaded;
what outputs may be generated;
what public claims may be made;
whether AI tools may be used;
whether external tools may be connected;
what expiration applies;
and what revocation conditions apply.
An entitlement to view is not an entitlement to edit.
An entitlement to edit is not an entitlement to approve.
An entitlement to approve is not an entitlement to publish.
An entitlement to publish is not recognition authority unless recognition authority exists.
An entitlement to use a dashboard is not lawful decision authority.
Entitlement boundaries prevent access from becoming control by implication.
5.15 Smart Licenses, Role Keys, and Registry
Protocol depends directly on Registry.
Registry determines what role or state currently exists.
Protocol expresses that state through smart licenses, role keys, entitlements, and control rules where designated.
If Registry changes, Protocol must be capable of changing.
If membership expires, access should narrow.
If a council term ends, council keys should expire.
If a provider is suspended, provider access should be suspended.
If a Marketplace object is deprecated, its listing badge should update.
If a node is downgraded, node functions should reflect the downgrade.
If a report is superseded, publication labels should reflect supersession.
If a public authority capacity is corrected, public-facing labels should update.
If a smart license was misissued, it should be revoked and recorded.
This Registry-to-Protocol synchronization prevents institutional truth and technical truth from diverging.
5.16 Anchoring
Anchoring is the process through which designated state changes, authorizations, records, proofs, or protocol events are durably linked to a trusted record, ledger, log, hash, timestamp, or institutional reference.
Anchoring may support:
proof of issuance;
proof of revocation;
proof of status at a time;
proof of version;
proof of correction;
conformance result integrity;
auditability;
public-safe publication traceability;
role-key lifecycle;
smart-license lifecycle;
API authorization history;
and non-repudiation where appropriate.
Anchoring does not create authority by itself.
It preserves evidence of state.
It helps the system prove that a status or permission existed, changed, or was revoked.
In a validity-by-record architecture, anchoring strengthens memory and auditability.
5.17 Synchronization
Synchronization ensures that Registry state, platform state, protocol state, and entitlement state remain aligned across distributed environments.
Distributed systems drift unless synchronization is designed.
A member may be suspended in one database but still active in a collaboration platform.
A provider may be delisted in Marketplace but still hold API access.
A council member may complete a term but still access council rooms.
A node may be downgraded but still display active status on a map.
A Studio workflow may be withdrawn but remain accessible to users.
Synchronization prevents these contradictions.
Synchronization should include:
state propagation;
event notification;
entitlement updates;
platform label updates;
API permission updates;
smart-license update;
revocation propagation;
rollback where needed;
and audit logging.
Synchronization is how Nexus keeps distributed truth coherent.
5.18 No-Bypass Logic
No-bypass logic is a core protocol principle.
It means that technical systems must not allow actors to sidestep governance, Registry, status, scope, handling discipline, public-safe review, or role boundaries through privileged access, undocumented channels, backdoors, manual overrides, API workarounds, platform administration, or informal exports.
No-bypass logic protects against one of the most common failure modes in hybrid governance systems: the formal rule remains intact on paper while privileged actors quietly circumvent it through technical means.
No-bypass logic should apply to:
publication workflows;
Registry updates;
role-key issuance;
smart-license issuance;
public-safe review;
Marketplace listing changes;
provider status changes;
node activation;
Studio workflow access;
data-room exports;
report approvals;
council records;
conformance badges;
public authority labels;
finance-readable records;
and protocol revocations.
A technical shortcut that bypasses governance is a governance failure.
Nexus must design systems so that the easiest path is also the valid path.
5.19 Platform Administration Is Not Protocol Authority
Nexus requires platform administrators, technical maintainers, system operators, DevOps personnel, security teams, and tool administrators.
But platform administration is not protocol authority.
A platform administrator may maintain the system.
They may not define institutional meaning by convenience.
They may not grant roles outside recorded state.
They may not publish recognition records without authority.
They may not convert a platform label into status.
They may not restore access after revocation without process.
They may not use admin privilege to bypass public-safe review.
They may not export controlled data outside entitlement rules.
Technical administration must remain subordinate to standards, Registry, governance, and protocol rules.
This distinction is crucial because digital ecosystems often become governed by whoever controls the platform.
Nexus must prevent platform administration from becoming hidden constitutional authority.
5.20 Expiry and Renewal
Protocol permissions should expire unless there is a reason for continued validity.
Expiry prevents stale power.
Renewal confirms that the underlying state remains current.
Smart licenses, role keys, entitlements, API access, council workspace access, provider access, Marketplace contributor access, Studio access, node access, and data-room access should all be capable of expiry or periodic renewal where appropriate.
Renewal may require:
current good standing;
current membership;
active role;
current provider status;
active council appointment;
updated conflict disclosure;
updated confidentiality undertaking;
completed training;
public-safe attestation;
cybersecurity review;
Registry confirmation;
or steward approval.
A permission that never expires can outlive its lawful or governance-valid basis.
Expiry and renewal are therefore integrity controls.
5.21 Revocation
Revocation is essential.
A protocol-governance system that can issue permissions but cannot revoke them is structurally unsafe.
Revocation may be required when:
membership ends;
good standing is lost;
a council term ends;
a role is removed;
a provider is suspended;
a Marketplace object is delisted;
a public-safe status is withdrawn;
a report is corrected or superseded;
a node is downgraded;
a host relation ends;
a smart license was misissued;
a key is compromised;
a data breach occurs;
a conflict is undisclosed;
public claims rules are breached;
or emergency hold is triggered.
Revocation should be:
recorded;
time-stamped;
propagated;
auditable;
tied to the underlying reason;
reversible only through proper process where allowed;
and communicated where necessary.
Revocation is not merely a security function.
It is a governance function.
5.22 Suspension, Narrowing, and Conditional Access
Not every problem requires full revocation.
Protocol should support suspension, narrowing, and conditional access.
A user may be temporarily suspended pending review.
A provider may retain access to documentation but lose publication rights.
A member may remain in good-standing review but lose controlled-room access.
A node may retain archival visibility but lose active status.
A Studio workflow may remain accessible to stewards but not public users.
A Marketplace object may remain visible as deprecated but not installable.
A smart license may be narrowed to read-only access.
Conditional access allows proportional response.
It helps Nexus maintain continuity while protecting integrity.
Suspension and narrowing must be recorded and reviewable.
5.23 Emergency Hold
Emergency hold is a controlled mechanism for urgent intervention where integrity, security, public-safe discipline, Registry truth, data protection, or public trust may be at risk.
Emergency hold may apply to:
compromised keys;
suspected unauthorized access;
public-safe publication error;
provider risk;
node integrity issue;
Studio workflow risk;
Marketplace object risk;
data leakage;
public authority mislabeling;
finance-readiness overclaim;
critical platform error;
AI system misclassification;
or protocol-Registry mismatch.
Emergency hold should allow timely action.
But emergency hold must not become unreviewable power.
A mature emergency hold rule should include:
triggering conditions;
authorized emergency holders;
time limit;
scope limit;
logging requirement;
notification where appropriate;
post-action review;
correction pathway;
restoration process;
and abuse prevention.
Emergency control protects integrity only if it remains accountable.
5.24 Rollback
Rollback allows the system to reverse or restore certain protocol states when an error, compromise, misconfiguration, misissued license, incorrect entitlement, or invalid synchronization event occurs.
Rollback may be needed when:
a key was issued incorrectly;
a license was granted to the wrong class;
a Registry update propagated incorrectly;
a provider status was mislabeled;
a Marketplace badge was wrongly displayed;
a node was activated in error;
a Studio workflow was exposed outside scope;
an access-control rule over-permitted users;
or a platform update corrupted state.
Rollback should not erase history.
It should correct effect while preserving audit trail.
A rollback should answer:
what was rolled back;
why;
who authorized it;
what record supports it;
what users were affected;
what claims were impacted;
and what correction notice is required.
Rollback is correctionability in technical form.
5.25 Audit Trails and Technical Traceability
Audit trails are mandatory for serious protocol governance.
Protocol events should be traceable.
Audit trails may cover:
smart-license issuance;
smart-license renewal;
smart-license suspension;
smart-license revocation;
role-key creation;
role-key activation;
role-key use;
entitlement changes;
platform access changes;
Registry-to-Protocol synchronization;
emergency holds;
rollbacks;
publication events;
public-safe approvals;
Marketplace status changes;
provider access changes;
node activation;
Studio workflow access;
API access;
data exports;
correction events.
Auditability supports accountability, investigation, correction, and learning.
It also proves that governance and protocol layers remain aligned.
Audit trails do not need to expose all details publicly. But they must be reviewable by authorized bodies.
5.26 Protocol and Correctionability
Protocol must be correction-capable.
Errors will occur.
A role may be misassigned.
A key may be misissued.
A license may be too broad.
A synchronization event may fail.
A user may retain access after status expiry.
A platform label may not update.
An AI system may misclassify status.
A workflow may permit unauthorized action.
A provider entitlement may survive suspension.
The question is not whether errors are possible. The question is whether Nexus can detect, correct, record, and learn from them.
Protocol correction may include:
key revocation;
license narrowing;
entitlement update;
platform label correction;
Registry correction;
synchronization repair;
audit note;
user notification;
public clarification;
incident review;
emergency hold;
rollback;
and governance escalation.
Correctionability is not embarrassment.
It is trust infrastructure.
5.27 Protocol and Public-Good / Enterprise Stack Separation
Protocol must preserve the public-good / enterprise stack separation.
The public-good stack uses protocol governance to protect standards, Registry, public-safe publication, role purity, Digital Public Goods, Academy, Marketplace classification, and public-good software.
The enterprise and execution stack may use protocol-linked permissions for providers, Marketplace services, Studio integrations, National Consortium Companies, Project SPVs, implementation support, data rooms, and lawful delivery environments.
The two stacks may interact.
They must not collapse.
A provider integration key does not give public-good authority.
A Project SPV data-room permission does not control the public-good rail.
A Marketplace listing permission does not create recognition.
A National Consortium Company platform role does not replace the National Nexus Consortium.
A Studio workflow in an enterprise context does not become public authority action.
Protocol must make stack boundaries enforceable.
Technical convenience must not erode the public-good firewall.
5.28 Protocol and Non-Execution
Protocol governance is non-executing by default.
A smart license does not execute finance.
A role key does not procure.
A platform permission does not regulate.
A dashboard entitlement does not issue public warning.
A provider API key does not approve deployment.
A Marketplace badge does not certify all uses.
A Studio workflow permission does not make a lawful decision.
A node activation does not create public authority operation.
A Project SPV data-room permission does not solicit investment.
Protocol may support lawful execution where separate lawful actors, instruments, and mandates exist.
But protocol itself does not become the execution actor.
This rule protects Nexus from turning technical sophistication into regulated-market or public-authority overreach.
5.29 Protocol and Sovereign Compatibility
Nexus is sovereignty-compatible, not sovereignty-substituting.
Protocol governance must respect the fact that sovereign authority, public authority decisions, domestic lawful basis, public-warning powers, procurement decisions, regulatory judgments, and public-sector operational command remain with lawful authorities.
Smart licenses and role keys may express designated states inside Nexus.
They may support controlled public authority learning.
They may help public authorities access records.
They may help ensure public-safe handling.
They may help enforce boundaries.
But they do not create public authority action.
A public authority may choose to adopt or rely on Nexus outputs through its own lawful process. Protocol may then support controlled access or workflow expression. But the lawful authority remains outside the protocol layer.
This is why Nexus Protocol can be trusted in sovereign environments.
It does not ask law to follow code.
It requires code to follow lawful and governance-valid state.
5.30 Protocol and Public Authority Interfaces
Public authority interfaces require strong protocol discipline.
A public authority participant may be classified as:
learner;
observer;
consultee;
host;
sponsor;
competent authority;