Note:64 Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption for Internet Coordination Systems

Abstract

This document describes a design pattern for Internet coordination systems whose purpose is to provide shared technical reference points without creating a continuing authority above the participants who run the system. It defines three linked principles: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption.

Under this model, the Initial Specification defines only the deterministic, locally verifiable rules required for uniqueness, interoperability, shared safety, and security. After the Initial Specification, future changes are not approved by a central body. They are adopted, ignored, forked, or abandoned by participants running code.

Non-adoption is not a violation. A participant that does not adopt a later change remains in its existing compatibility set. A participant that emits state not valid under the deterministic rules accepted by another participant may be locally ignored by that participant. The effect is compatibility selection, fork, isolation, or selective interoperation, not institutional punishment.

This document does not define a wire protocol. It specifies a Best Current Practice for the design of protocols, registries, identifier systems, and coordination mechanisms that must not become permanent governance institutions.

1. Introduction

Many Internet systems begin with a narrow technical purpose: to allow independent actors to interoperate by sharing a common reference point, identifier space, validation rule, or registry-like record. Over time, such systems often accumulate authority that was not required for initial interoperability.

This usually happens in three steps.

First, future questions are placed into the founding layer before they are technically necessary.

Second, choices that should be made by participants running their own systems become dependent on recognition, interpretation, or status decisions by a continuing body.

Third, publication, registration, recommendation, or procedural approval is treated as sufficient to create operational obligation, even where participants have not adopted the change in running systems.

The result is a brittle system. A technical reference layer becomes a governance layer. A recordkeeper becomes a gatekeeper. A coordination artifact becomes a source of future control.

This document proposes a different design discipline:

– Minimum Initial Specification: specify only the deterministic common rules required for baseline interoperability, uniqueness, shared safety, and security.
– Localized Future Decision: after the Initial Specification, keep future choices with participants running code. A participant may adopt, refuse, fork, disconnect, or interoperate selectively. No participant can alter the interoperability of other participants that continue to run mutually compatible rules.
– Voluntary Adoption: make later change real only through implementation, operation, validation, and adoption by participants running code.

These principles are related. A system that specifies too much at the beginning pre-loads future control into the common layer. A system that leaves a continuing recognition layer allows authority to reappear after deployment. A system that treats publication as reality converts documentation into command.

The design intuition is simple: validity must be determined by deterministic rules that participants can verify locally. A participant may adopt a later change, refuse it, fork, disconnect, or interoperate selectively. It may at most remove itself from a compatibility set. It cannot, by refusing a change, break the interoperability of other participants that continue to run mutually compatible code.

This is the same general lesson visible in systems such as Bitcoin: consensus rules are enforced by those who run validation code, not by an institution standing above them.

2. Scope

This document applies to Internet coordination systems, including but not limited to shared registries, identifier systems, naming and numbering frameworks, protocol-extension mechanisms, proof-of-control systems, portability systems, and other architectures in which independent actors rely on a common technical reference point.

This document does not argue against common rules. It argues that common rules should be deterministic, minimal, locally verifiable, and limited to what the system actually needs in order to run.

This document does not require a blockchain, distributed ledger, or any specific technology. It requires a design property: participants should be able to determine validity by applying the Initial Specification locally, without asking a standing authority for permission or status.

3. Conventions and Definitions

3.1. Requirements Language

The capitalized requirement terms in this document are to be interpreted in the sense defined by BCP 14, specifically RFC 2119 and RFC 8174.

3.2. Terminology

Initial Specification:
The set of rules, data structures, formats, invariants, validation procedures, and transition rules required for first deployment of a system.

Common Layer:
The minimum shared rule set or reference structure required for independent participants to interoperate. The common layer is not an institution. It is the technical substance that participants implement and verify.

Deterministic Validation Rule:
A rule that allows a participant to decide, by local computation or local verification, whether a state, record, transition, assertion, or message is valid under a specified rule set.

Global Invariant:
A property that must remain common within a compatibility set in order to preserve uniqueness, baseline interoperability, shared safety, or security.

Participant:
An operator, implementation, node, network, organization, or other actor that runs, verifies, deploys, or relies on the system.

Compatibility Set:
A group of participants whose implemented validation rules allow them to interoperate. A later change may create a new compatibility set if some participants adopt it and others do not.

Adoption:
Actual implementation, deployment, validation, and use by participants running the system.

Non-Adoption:
A participant’s choice not to implement or use a proposed change. Non-adoption does not create invalid status. It only means the participant has not joined the compatibility set created by that change.

Local Rejection:
A participant’s local decision to ignore, reject, or not interoperate with a state, message, record, or transition that is invalid or incompatible under the validation rules it runs.

Fork:
A divergence in validation rules or operational practice that creates two or more compatibility sets.

Coordination Artifact:
A document, registry entry, recommendation, implementation note, profile, reference implementation, or other artifact that helps participants coordinate. A coordination artifact does not create binding operational reality unless participants adopt it in running systems.

4. Problem Statement

Designers often try to reduce future uncertainty by writing too much into the founding layer or by leaving a continuing body to interpret future questions. This appears prudent. It is often dangerous.

Over-specification at the founding layer has three costs.

First, it moves future choices into a common layer where change is harder and where capture has greater effect.

Second, it creates ambiguity between technical validity and institutional recognition.

Third, it encourages a body that maintains records, publishes documents, or convenes participants to treat those acts as authority over future reality.

The same problem appears after deployment. If a system requires a continuing body to approve change, determine status, or interpret ordinary operation, the system has created a post-founding control layer. That layer may begin as administration. It can become governance. It can then become a choke point.

The design goal of this document is not better institutional discretion. The design goal is to avoid the need for that discretion.

A well-designed Internet coordination system should define deterministic, locally verifiable validity rules at the start; should leave non-invariant choices outside the common layer; and should allow later changes to become real only when participants voluntarily adopt them in running systems.

5. Principle 1: Minimum Initial Specification

5.1. Statement

An Initial Specification SHOULD define only the minimum deterministic common rules required for baseline interoperability, uniqueness, shared safety, and security.

5.2. Requirements

A design using this principle:

1. MUST identify its Global Invariants explicitly.
2. MUST define deterministic validation rules for each Global Invariant.
3. MUST NOT place a rule in the Initial Specification unless the rule is required to preserve a stated Global Invariant or to enable first deployment.
4. MUST separate validation rules from policy preferences, business arrangements, institutional roles, governance aspirations, and discretionary judgment.
5. MUST allow participants to verify ordinary validity locally without asking any institution, registry, committee, policy body, or other authority.
6. SHOULD define data structures, signatures, proofs, state-transition rules, conflict rules, or other mechanisms necessary for local verification.
7. SHOULD define extension signalling, versioning, compatibility labelling, or fork identification where future variation is foreseeable.
8. MUST ensure that required coordination artifacts are portable, auditable, reproducible, and replaceable.
9. SHOULD prefer objective machine-verifiable conditions over subjective merit judgment.
10. MUST NOT make future institutional recognition the only path by which a valid state can be known, recorded, or used.

5.3. Design Implications

Minimum Initial Specification does not mean vague specification. It means strict specification of only what must be common.

A system still needs enough common structure to run. The discipline is to distinguish between:

– what must be common for uniqueness, interoperability, shared safety, and security; and
– what can remain outside the common layer because it concerns operator preference, business practice, deployment timing, or later adoption choice.

A design that cannot state its Global Invariants and deterministic validation rules clearly should assume that it has specified too much discretion and too little verifiable substance.

6. Principle 2: Localized Future Decision

6.1. Statement

After the Initial Specification, Future Decisions SHOULD remain local to participants running code. A Future Decision becomes effective only for the compatibility set whose participants adopt it. No continuing authority is required to approve it, and non-adoption does not create invalid status.

6.2. Requirements

A design using this principle:

1. MUST NOT require participants to obtain permission from an incumbent institution, registry, committee, board, policy body, or other authority for choices that do not alter the deterministic validation rules of the compatibility set they participate in.
2. MUST NOT create a standing body whose recognition is the only path by which a later change can become operationally real.
3. MUST distinguish validity under the Initial Specification from compatibility with a later optional change.
4. MUST NOT treat non-adoption of a later change as invalidity.
5. MUST allow participants to remain in an existing compatibility set when they do not adopt a later change.
6. MUST allow participants to join a new compatibility set by adopting new validation rules or operational profiles.
7. MUST allow participants to locally reject states, records, transitions, or messages that are invalid or incompatible under the validation rules they run.
8. MUST NOT authorize any institution, registry, committee, policy body, or other actor to declare a participant invalid merely because it refused a later change.
9. SHOULD make forks, versions, profiles, or compatibility sets explicit so that participants know which rules they are running and which other participants they can interoperate with.
10. SHOULD avoid any design in which an incumbent recordkeeper can prevent otherwise valid participants from continuing to interoperate.

6.3. Design Implications

Localized Future Decision does not mean that a central authority allocates future decisions to local actors. It means the system is designed so that, after the Initial Specification, ordinary future choices do not need such allocation.

The Initial Specification does the limiting work in advance. It defines the minimum invariants required for uniqueness, interoperability, shared safety, and security. Everything else remains outside the common layer.

Future change is not approved centrally. It is adopted, ignored, forked, or abandoned by participants running code.

A participant that refuses a change may remain outside the compatibility set created by that change. It may disconnect itself from others. It may continue in an older compatibility set. It may fork. It may interoperate selectively. But it cannot break the interoperability of other participants who continue to run mutually compatible rules.

The effect of invalid or incompatible state is local rejection, not punishment. No one needs to decide that a participant is in bad standing. A participant running compatible validation rules simply does not accept the invalid or incompatible state.

7. Principle 3: Voluntary Adoption

7.1. Statement

Changes in an Internet coordination system SHOULD become operationally real through implementation, validation, deployment, and adoption by participants, not through publication or declaration alone.

7.2. Requirements

A design using this principle:

1. MUST NOT treat publication, registration, recommendation, meeting approval, or procedural approval as sufficient to create universal operational obligation.
2. MUST allow new rules, extensions, profiles, or procedures to be deployed incrementally by participants that choose to run them.
3. MUST allow participants to refuse a later change without acquiring invalid status, so long as their own state transitions satisfy the deterministic validation rules of their compatibility set.
4. MUST allow participants to continue using an older compatibility set where the Initial Specification permits such continuity.
5. MUST allow participants running one compatibility set to locally reject or ignore state from another compatibility set where the rules are incompatible.
6. SHOULD define adoption paths for major changes, including version signalling, compatibility labelling, transition guidance, and test vectors.
7. SHOULD define refusal paths for major changes, including how non-adopting participants continue operation, identify their compatibility set, and avoid ambiguous interoperation.
8. MUST ensure that required coordination artifacts can be exited, ported, mirrored, reimplemented, or replaced without impossible transition cost.
9. SHOULD have registries, records, recommendations, and coordination artifacts describe adopted reality rather than declare unadopted future reality into existence.
10. MUST avoid designing a system in which the only way for a change to become real is prior recognition by an incumbent body.

7.3. Design Implications

Voluntary Adoption is the operational test of whether a change is useful, tolerable, and compatible with real deployment.

A proposal is not reality. A recommendation is not reality. A registry update is not reality. A document is not reality. Reality appears when participants implement, validate, deploy, and rely on the change.

Non-adoption creates no status of violation. It creates only a fact: the participant has not joined the compatibility set created by the change.

This does not eliminate standards processes, registries, documentation, or review. It limits their claim. They may help participants coordinate. They may publish reference material. They may describe adoption. They may recommend. They may not, by declaration alone, make unadopted future reality binding on participants who do not run it.

8. Relationship Among the Three Principles

The three principles are mutually reinforcing and are not effective in isolation.

Minimum Initial Specification ensures that the common layer contains deterministic validation rules rather than discretionary authority.

Localized Future Decision ensures that future choices remain with participants running code rather than being recaptured by a central approval layer.

Voluntary Adoption ensures that later change must survive contact with implementation and use.

A system that adopts only one or two of these principles may reproduce the same centralization by other means.

– Minimum Initial Specification without Localized Future Decision may still allow authority to accumulate after deployment.
– Localized Future Decision without Minimum Initial Specification may produce ambiguity, because participants cannot locally determine validity.
– Voluntary Adoption without deterministic validation may produce confusion, because participants cannot distinguish compatible variation from invalid state.
– Deterministic validation without exit, portability, or replaceability may still produce lock-in if the recordkeeping artifacts become impossible to leave.

Together, the principles produce a system in which the common layer is thin, validity is locally verifiable, future change is voluntary, and no standing institution is needed to decide ordinary operation.

9. Recommended Design Pattern

9.1. Deterministic Common Layer

The common layer SHOULD be limited to:

– stable identifier semantics;
– deterministic validity rules;
– conflict-resolution rules necessary to preserve uniqueness;
– wire-level or protocol-level interoperability requirements;
– shared security invariants;
– proof-of-control mechanisms, where necessary;
– portable and auditable record formats, where records are necessary;
– extension signalling and compatibility-set identification.

The common layer SHOULD NOT contain:

– business-model rules;
– pricing rules;
– regional political preferences;
– eligibility ideology unrelated to technical invariants;
– discretionary enforcement powers;
– subjective merit assessments;
– institutional mission expansion;
– any rule whose primary function is to preserve the authority of an incumbent body.

9.2. Operator Decision Surface

The following SHOULD remain outside the common layer unless they directly alter a stated Global Invariant:

– deployment timing;
– commercial use;
– customer geography;
– leasing, financing, or transfer arrangements;
– local eligibility preference;
– operational sequencing;
– routing practice not required for shared validity;
– business model;
– organizational structure;
– voluntary migration timing;
– optional profiles or extensions.

Participants MAY adopt different choices in these areas. Those choices may produce different compatibility sets, business relationships, peering arrangements, or operational communities. They do not create invalidity unless they violate deterministic validation rules in a compatibility set.

9.3. Adoption Loop

Where feasible, the preferred order for material system change is:

1. proposal;
2. implementation;
3. test vectors or deterministic verification method;
4. limited deployment by willing participants;
5. observation of interoperability and security effects;
6. compatibility-set labelling;
7. documentation or recommendation describing adopted reality.

A coordination artifact SHOULD follow adoption rather than attempt to preempt it.

9.4. Exit, Fork, and Portability

A conforming design SHOULD treat exit, fork, and portability as normal design requirements rather than failures.

The system SHOULD define how a participant can:

– continue in an older compatibility set;
– adopt a newer compatibility set;
– fork into a different compatibility set;
– port records, identifiers, proofs, or operational state;
– verify the validity of records without relying on an incumbent recordkeeper;
– interoperate selectively where compatibility permits.

A system that cannot be exited or forked without destroying valid operation has probably hidden governance power inside its recordkeeping function.

10. Applicability and Limits

This design pattern is particularly applicable where:

– the system is multi-actor and multi-jurisdictional;
– independent deployment matters;
– the coordination layer is intended to remain thin;
– future variation is likely but cannot be predicted in detail;
– lock-in would create governance risk;
– validity can be made deterministic or locally verifiable.

It may be less directly applicable where:

– a single administrative domain is the intended architecture;
– strong real-time coupling requires uniform behavior at all times;
– life-safety concerns require immediate global uniformity;
– validity cannot be locally verified by any practical mechanism.

Even in such cases, designers SHOULD still minimize the common layer and avoid discretionary future control wherever possible.

11. Non-Goals

This document does not:

– prohibit all coordination;
– prohibit all shared registries;
– require blockchain or distributed ledger technology;
– guarantee consensus;
– guarantee political neutrality;
– require all participants to adopt every later change;
– treat refusal to adopt as invalidity;
– legitimize incompatible local behavior while claiming compatibility;
– eliminate the need for security-critical common rules.

12. Security Considerations

A thinner coordination layer can reduce capture risk, lower the blast radius of institutional error, and improve replaceability. However, increased local discretion can also create inconsistent security posture, downgrade paths, fragmentation pressure, ambiguous compatibility claims, and unsafe forks.

Designers applying this document MUST therefore specify security invariants explicitly. In particular:

– authentication and authorization requirements that are required for shared validity MUST be deterministic and locally verifiable;
– version negotiation and extension handling MUST avoid silent downgrade where security is affected;
– refusal, fork, and replacement paths MUST be analyzed for abuse and denial-of-service risk;
– compatibility labels SHOULD be clear enough to prevent accidental interoperation across incompatible rule sets;
– local variation MUST NOT be allowed to falsely claim compatibility with a rule set it does not satisfy.

The existence of security exceptions does not justify a general permission layer. It justifies only deterministic security rules necessary to preserve the stated Global Invariants.

13. IANA Considerations

This document has no IANA actions.

14. References

14.1. Normative References

– RFC 2119 — Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119.
– RFC 8174 — Leiba, B., Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words, BCP 14, RFC 8174.

14.2. Informative References

– RFC 6709 — Carpenter, B. and B. Aboba, Design Considerations for Protocol Extensions, RFC 6709.
– RFC 7282 — Resnick, P., On Consensus and Humming in the IETF, RFC 7282.

Appendix A. Design Checklist

A design that claims conformance to this document SHOULD be able to answer the following questions clearly:

1. What are the Global Invariants?
2. Which deterministic validation rules preserve those Global Invariants?
3. Which rules in the Initial Specification are strictly necessary for first deployment?
4. Which future questions are intentionally left outside the common layer?
5. Which future choices can be made by participants without altering the compatibility set they are in?
6. How does a participant adopt a later change?
7. How does a participant refuse a later change without being assigned invalid status?
8. How are compatibility sets labelled or discovered?
9. How does local rejection work when state is invalid or incompatible under the rules a participant runs?
10. What is the fork path?
11. What is the portability path?
12. What is the exit path from any required coordination artifact?
13. Can participants verify ordinary validity without relying on an incumbent recordkeeper?
14. Do records and coordination artifacts describe adopted reality, or do they attempt to declare unadopted future reality into existence?
15. Has the system minimized the number of decisions embedded in the common layer?
16. Has the system avoided any continuing authority that determines ordinary participant status?

## Author’s Address

H. Lu
[TBD]