Protocol Boundaries
How to interpret PVERSE docs: what the protocol guarantees, what policy controls, what mechanics compute, and what infrastructure executes.
Overview
PVERSE documentation is written in layers. Each lane has a different job, and mixing them causes misunderstandings. A mechanic can be misread as a promise, an operational plan can be misread as a guarantee, or a policy can be misread as an immutable protocol rule.
This page defines the boundary between protocol guarantees, administrative policy, game mechanics, and infrastructure execution. Treat it as the reading grammar for every other page in the docs set.
Scope
This page defines the interpretive boundary model used across the PVERSE documentation system.
- what counts as a protocol guarantee versus a policy decision
- how mechanics differ from infrastructure execution
- how SSOT separates meaning from numeric parameters
- how forward-only interpretation prevents silent category drift
Core Model
PVERSE docs are organized by role, not by surface appearance. Some pages define guarantees. Some pages define admin-controlled policy. Some pages define deterministic world mechanics. Some pages define execution infrastructure. This boundary model exists so readers do not mistake implementation detail for protocol truth.
- protocol guarantees belong to the Whitepaper layer and are intended to remain stable and non-retroactive
- policy belongs to Foundation, Market, or other admin-governed operational layers and may evolve forward-only
- mechanics define deterministic computations given rules and SSOT parameters
- infrastructure executes and enforces but does not define economics or guarantees by itself
Operational Behavior
In practice, this page should be used whenever a reader is unsure how strongly to interpret a statement. Before treating any sentence as immutable truth, the reader should classify it: guarantee, policy, mechanic, or infrastructure behavior. That one habit prevents most misreads across the docs.
Under future expansions or lane growth, this boundary model remains the anchor. New docs may appear, but they should still fit into the same interpretive structure so meaning stays stable even as execution and policy evolve.
Constraints
- not every statement inside docs is a guarantee; many are descriptive, operational, or forward-only policy statements
- numeric values such as tables, thresholds, success rates, fees, and cooldowns belong to SSOT, not to narrative guarantee text
- UI, operational timing, and service uptime are almost always implementation or policy surfaces rather than protocol invariants
- if a statement concerns chain settlement, supply, allocation, or non-retroactive truth boundaries, it should be traced back to the Whitepaper or explicit guarantee source
Integrity Considerations
Classification itself is part of documentation integrity. If readers cannot distinguish stable guarantees from forward-only policy or from game mechanics, then every other page becomes easier to misinterpret. This page exists to stop that collapse before it spreads across the rest of the docs.
- stable meaning depends on clear category boundaries
- SSOT prevents numeric drift from contaminating conceptual docs
- forward-only interpretation protects trust by preventing silent category changes
System Layer Model
PVERSE is documented using the following boundary model:
- World & Principles — intent and constraints, useful for human interpretation but not automatically enforceable
- Protocol Layer (Whitepaper) — guarantees and invariants, closest to immutable system truth
- Policy Layer (Foundation / Market Policy) — administrative decisions and forward-only operational change
- Mechanics Layer (Game Lane) — deterministic computations, inputs to outputs under SSOT-defined parameters
- Infrastructure Layer — services, daemons, storage, monitoring, and enforcement execution
- Reference Layer — definitions, maps, summaries, and FAQs that clarify meaning rather than define new guarantees
Protocol Layer
The protocol layer defines what the system claims as guarantees. These are the statements that should remain stable, non-retroactive, and auditable through public or forward-only records.
- supply and allocation structures
- settlement and finality posture
- invariants and non-negotiable constraints
Policy Layer
The policy layer defines administrative decisions: how participation is administered, when trading is enabled, what restrictions apply, and how operational phases are executed. Policy may evolve, but changes must be forward-only and logged.
Mechanics Layer
The mechanics layer defines deterministic computations. It answers: given inputs and active SSOT parameters, what is the output? Mechanics do not define protocol guarantees by themselves.
Infrastructure Layer
Infrastructure is the execution layer: services, daemons, storage, monitoring, and operational runbooks. It enforces policy and runs mechanics, but it does not define economics or guarantees on its own.
Reference Layer
Reference pages support navigation and interpretation: glossaries, maps, FAQs, and summary pages. They should help explain meaning, not create new guarantees or silently redefine behavior.
Guarantee Boundary
A protocol guarantee is a statement intended to be stable and non-retroactive. In PVERSE, a guarantee usually satisfies most of the following:
- immutability intent — it should not change retroactively
- enforcement — enforced by ledger, contract logic, or forward-only records
- documented origin — defined in Whitepaper or explicitly marked as a guarantee
- auditability — verifiable through public records, contract state, or forward-only evidence
SSOT Boundary
PVERSE uses an SSOT model to separate numbers from meaning. If a rule contains numeric parameters, those numbers belong in SSOT rather than in narrative guarantee text.
Docs describe meaning. SSOT defines numbers. Code enforces transitions.
Examples of SSOT-owned values include:
- prices, fees, and thresholds
- success rates and distributions
- EXP tables and progression curves
- caps, limits, and cooldowns
Forward-only Interpretation
PVERSE documentation follows a forward-only approach: history is preserved and changes are appended. This prevents silent meaning drift and improves auditability.
- no silent rewrite of prior meaning
- changes appear in changelogs or version notes
- status pages may summarize the current snapshot, but they must not erase history
Common Misinterpretations
Gameplay vs Protocol
Incorrect: “Mining success rate is guaranteed.”
Correct: Mining success rate is a mechanic. It may change by SSOT updates and should be treated as game balance, not a protocol promise.
Market Activation vs Protocol
Incorrect: “Trading activation timing is part of the protocol.”
Correct: Trading activation is a policy decision. It is documented and executed forward-only, but it is not itself a protocol invariant.
Infrastructure vs Guarantee
Incorrect: “Payment engine behavior defines token rules.”
Correct: The payment engine is infrastructure. It enforces policy and records events, but token economics are defined elsewhere.
Boundary Checklist
Use this checklist to classify any statement you read in PVERSE docs:
- Is it immutable by intent?
- Is it enforced by ledger, contract logic, or forward-only records?
- Is it defined in the Whitepaper or explicitly marked as a guarantee?
If most answers are yes, treat it as Protocol.
Otherwise classify it as Policy, Mechanics, or Infrastructure.
Future Expansion
This page may expand over time as the docs system adds more lanes or more explicit guarantee markers. Even as the documentation tree grows, this page should remain the canonical interpretation guide for how to classify and read every statement across PVERSE docs.
Summary
- protocol guarantees, policy decisions, mechanics, and infrastructure execution are separate categories and should not be read interchangeably
- Whitepaper defines guarantees, Foundation defines admin policy, Game Lane defines deterministic mechanics, and Infrastructure executes
- SSOT owns numeric values, while docs own meaning and boundaries
- forward-only interpretation prevents silent category drift and preserves reader trust