Source Authority Map

The docs layer maps authority; it is not the primary source of protocol truth. Writers must preserve the established authority order across the whitepaper corpus, live source anchors, and maturity boundaries.

The controlling rule is simple: use the broadest paper only for the layer it actually owns, then use the narrower companion paper for the exact claim. The main whitepaper owns the core settlement thesis, wallet-local possession, checkpointed reconciliation, and narrow public evidence boundary. It does not own every later governance, legal, external-custody, smart-cash, transport, or post-quantum detail. The terminology reference owns names, aliases, casing, and editorial guardrails. It does not replace the technical argument inside the owning paper.

Authority Graph

Claim Owners

Conflict Resolution Rule

When two sources appear to conflict, resolve them in this order:

1. A narrower companion paper controls its own specialist domain.
2. The main whitepaper controls core settlement and protocol thesis.
3. The terminology reference controls names, aliases, casing, and editorial guardrails.
4. Documentation never overrides a whitepaper.
5. An archived note never overrides a current whitepaper.
6. If implementation evidence is required and absent, write the claim as target architecture or research direction.

This rule prevents a common failure mode: using a high-level phrase from the main whitepaper to overstate a specialist domain that a later paper intentionally narrows. For example, the main paper can say private external asset rights fit the Z00Z settlement model, but the cross-chain paper controls the locker, custody, and redemption assumptions. The main paper can say local possession may precede publication, but the linked-liability paper controls fraud-case attribution and compensation boundaries for offline conflict.

Term Authority

The terminology reference is the first stop for naming. Its section 2 defines corpus coverage, section 6 inventories document-specific terminology layers, section 8 maps cross-paper authority, and section 9 gives editorial guardrails. Those sections are not optional style suggestions. They are the control surface that keeps public docs from drifting into alternate names or overloaded meanings.

Use AssetLeaf for public checkpointed settlement state. Use RightLeaf only where the right-settlement surface is being discussed. Use Voucher for conditional value, not for every non-cash object. Use Right for bounded authority without final value. Use Asynchronous rights settlement for local possession plus later checkpoint reconciliation, not for unconditional offline finality. Use Soft confirmation only for a pre-checkpoint publication-path signal. Documentation that substitutes looser terms such as “account,” “tokenized everything,” or “programmable private money” must add a boundary or remove the wording.

Maturity Boundaries

Authority is not only about topics. It is also about maturity. The whitepaper frontmatter descriptions show that several papers are deliberately companion papers, not claims that every surface is fully deployed. Main-Whitepaper.md describes the core protocol. UseCases.md shows workflows that fit the model. Agentic-Offline-Economy.md explains machine and agent flows as private wallet-local rights with later reconciliation. Smart-Cash.md distinguishes bounded state machines from a universal public VM. Proof-of-Useful-Work.md defines rule-bound evidence and payout authorization. Those descriptions are maturity filters.

Therefore every page should ask three questions before publishing a strong claim. Is the claim described as current protocol, target architecture, or research direction? Does the owning paper provide a section-level source for it? Does a live code or test anchor exist when the page says something is implemented? If any answer is weak, use bounded language: “the corpus defines,” “the target direction is,” “the page should treat this as research,” or “implementation evidence is still required.”

Writer Workflow

Start with the reader question, not with the most impressive paper. If the question is “how does final settlement work,” begin with the main whitepaper. If the question is “what is a voucher,” begin with the assets, rights, and vouchers paper. If the question is “can a use case be marketed,” begin with the use-cases paper and then check legal architecture. If the question is “does transport hide metadata,” begin with the privacy threat model and OnionNet together.

After choosing the authority, copy the section-level citation into the page’s evidence block. Then test the wording against the non-claim. A sentence that needs three caveats in order to be true should probably be rewritten as a narrower sentence. The docs layer should help readers traverse the corpus; it should not flatten the corpus into a single promotional voice.

Claim Review Checklist

Before a new docs claim is merged, reviewers should be able to answer four checks without guessing. Which whitepaper owns the claim? Which section or appendix supports it? Which maturity label applies today? Which adjacent paper could narrow the wording? If the answer depends on local source code, tests, or benchmark output, the page must cite that evidence separately. A whitepaper can justify a design thesis; it cannot by itself prove that a current runtime path, benchmark result, or product integration exists.

Read Next

Read Whitepapers for the reading order, Technical Papers for specialist companion papers, and Glossary when a term is easy to misuse across papers.

Evidence and Further Reading

• Corpus Terminology And Abbreviations Reference sections 2, 6, 8, and 9 define corpus coverage, terminology inventory, authority map, and editorial guardrails.
• Main Whitepaper frontmatter describes the core protocol authority for wallet-local possession, confidential settlement objects, checkpointed reconciliation, and narrow public evidence.
• Use Cases frontmatter describes scenario authority for payment, rights, offline, and service workflows.
• Agentic Offline Economy frontmatter describes machine, agent, and capability-driven flows as private wallet-local rights with later checkpointed reconciliation.
• Assets, Rights, And Vouchers frontmatter defines the object boundary between assets, rights, and vouchers.
• Cross-Chain Integration frontmatter controls private rights with external custody, issuance, liquidity, and attestation systems.
• Privacy Threat Model And Metrics frontmatter controls visibility boundaries, adversaries, leakage, and privacy metrics.
• OnionNet, Tokenomics.md, DAO.md, Proof-of-Useful-Work.md, Legal-Architecture.md, Post-Quantum-Migration.md, Smart-Cash.md, Linked-Liability.md, and Uniqueness.md provide the remaining specialist control lanes referenced above.