The technical-paper lane is where the corpus stops speaking in one unified protocol narrative and starts speaking in bounded deep dives. These files matter because they explain why one subsystem, one liability rule, or one incentive mechanism should be read more narrowly than a marketing summary would suggest.
What Companion Papers Are For
Companion papers should answer one of three needs:
| Need | What a good companion paper adds |
|---|---|
| Boundary precision | It shows exactly where protocol truth ends and service, issuer, or operator responsibility begins |
| Deeper object model | It names the objects, receipts, commitments, or policies that a shorter paper can only mention briefly |
| Narrower non-claims | It explains what the architecture must not promise even when the direction is strategically important |
That is why these papers are valuable. They make the broad corpus safer to reuse by removing ambiguity rather than by adding volume.
Read By Topic, Not By Curiosity
| Topic | Best companion file | What to carry forward |
|---|---|---|
| Offline fraud and conflict-triggered accountability | Linked Liability Whitepaper | Liability stays hidden in the honest path and activates only under proven conflict |
| External custody, trust tiers, and cross-chain semantics | Cross-Chain Integration Whitepaper | Z00Z privately moves rights, not the external asset itself |
| Policy-shaped value, vouchers, and object-local rules | Assets, Rights, And Vouchers Whitepaper and Smart Cash | Bounded meaning should live in spendable objects, not by default in public contract state |
| Private useful-work rewards | Proof-of-Useful-Work Whitepaper | Evaluation, authorization, and payout must stay separable |
| Agent and machine economies | Agentic Offline Economy Whitepaper | Spendable capability objects widen the model beyond cash, but remain maturity-sensitive |
| Governance and AI review safety | DAO Whitepaper | AI evaluation can be useful only when treasury execution remains separately controlled |
This structure is deliberate. It keeps readers from treating every technical paper as a general-purpose system overview. Most of them are strongest when read as one bounded answer to one bounded question.
What These Papers Usually Prove
A technical companion paper is rarely the place to look for broad “what is Z00Z” language. It is usually the place to look for:
- object boundaries;
- trust-tier disclosure;
- replay or accountability semantics;
- review and payout separation;
- stronger non-claims than the headline corpus can carry in one pass.
That also means companion papers are where you should go before writing any sentence that sounds stronger than “the architecture points this way.” If the wording still feels too strong after you read the companion paper, it probably is too strong.
Current Best-Fit Reading Paths
Two reading paths cover most serious research tasks.
| You are trying to evaluate… | Read in this order |
|---|---|
| Protocol shape plus one sensitive extension | Main Whitepaper -> one companion paper -> Corpus Terminology And Abbreviations Reference |
| Scenario fit plus constraints | Use Cases Whitepaper -> one companion paper -> Privacy Threat Model And Metrics |
For example, a page about private external-asset rights should not rely only on the use-cases paper. It should also pass through Cross-Chain Integration Whitepaper, because that is the paper that explicitly separates private internal reassignment from outside custody, reserves, and redemption honesty.
What Technical Depth Does Not Mean
Technical depth does not automatically mean stronger maturity. Some of these papers are deeper precisely because they are still defining future-safe boundaries. Proof-of-Useful-Work Whitepaper, for example, is detailed because reward evaluation is risky, not because the full evaluator market is already live. Agentic Offline Economy Whitepaper is detailed because the future right families need disciplined naming, not because every agent-commerce path is already deployed.
That is the recurring pattern:
- more detail often means more caution, not more finality;
- object-model clarity does not equal full runtime closure;
- a sharper diagram is not itself evidence of a live production surface.
Safe Output From This Page
After you read a companion paper, you should be able to answer three things clearly:
- What is the narrow question this paper owns?
- Which part of the answer is repo-backed enough for present-tense language?
- Which part of the answer is still bounded by issuer, service, governance, or future implementation work?
If you cannot answer those three questions, keep the wording softer. That is especially important for use-case and benchmark pages, where strong technical phrasing can otherwise drift into overclaiming.
Companion Groups By Technical Question
| Technical question | Read first | Then read | Why this order matters |
|---|---|---|---|
| How does offline or delayed execution stay accountable? | Main-Whitepaper.md sections 5 and 9 |
Linked-Liability.md sections 3-7 |
The main paper defines delayed ownership posture; the liability paper controls fraud-case reveal, bonds, compensation, and exculpability. |
| How do bounded policies differ from a private VM? | Assets-Rights-Vauchers.md sections 3, 5, 6, and 7 |
Smart-Cash.md sections 4-10 |
The object paper defines asset, voucher, and right boundaries; the smart-cash paper controls state-machine and non-VM language. |
| How can outside value move privately inside Z00Z? | Main-Whitepaper.md section 7 |
Cross-Chain-Integration.md sections 3-8 and Legal-Architecture.md sections 13-14 |
Protocol settlement and external custody are separate claims; legal and issuer responsibility must remain visible. |
| How strong is the privacy claim? | Main-Whitepaper.md section 6 |
Privacy-Threat-Model.md sections 3-10 and OnionNet.md sections 5-8 |
Settlement privacy, transport privacy, wallet UX, ingress, and egress are different surfaces. |
| How should useful work be evaluated and paid? | Proof-of-Useful-Work.md sections 5-8 |
DAO.md sections 7-9 and Tokenomics.md section 6 |
Work evidence, governance authorization, and treasury budget limits are coupled but not identical. |
| How should post-quantum migration be discussed? | Post-Quantum-Migration.md sections 4-9 |
Privacy-Threat-Model.md section 10 |
Suite transition language needs evidence gates and must not imply finished migration unless implementation evidence exists. |
Prerequisites Before Deep Reading
The technical paper set assumes that the reader already understands wallet-local possession, checkpointed settlement, and protocol-versus-service separation. Without those prerequisites, a reader can easily misread a companion paper as a separate architecture. For example, the cross-chain paper is not a bridge-product promise. It is an integration boundary over external custody and internal private rights. The smart-cash paper is not a claim that every object executes arbitrary hidden code. It is a bounded policy model around object-local rules, wallet or service state machines, and settlement evidence. The DAO and PoUW papers are not a treasury marketing layer. They are control surfaces for proposal lanes, evidence review, reward authorization, and abuse resistance.
When writing docs from a technical paper, keep the prerequisites visible. A page should say what the reader should understand first, which source owns the current term, and which maturity caveat applies. This is especially important for specialist pages because they carry the highest risk of overclaiming. A technically impressive diagram can still be wrong if it erases custody, legal, privacy, or implementation boundaries.
Output Discipline For Writers
A technical-paper summary should produce one of three outputs: a safe present-tense statement, a target-architecture statement, or an explicit open question. It should not produce vague confidence. If a paper defines a mechanism but the repo does not yet expose deterministic local evidence, call it a corpus-defined mechanism or target direction. If a paper defines a boundary that depends on an issuer, custodian, evaluator, model registry, or wallet profile, keep that role in the sentence. If a paper defines a forbidden claim, preserve the prohibition in the docs instead of paraphrasing around it.
This discipline is what keeps technical pages from becoming a parallel specification layer. The companion paper owns the technical question; the docs page owns navigation, compression, and reader safety.
Read Next
Read Source Authority Map for claim ownership, HJMT for storage-root thinking, and Verification Orchestrator before turning a companion-paper claim into an implementation assertion.
Evidence and Further Reading
- Linked Liability Whitepaper sections 3-7 are the companion source for hidden accountability, fraud proofs, lock registries, and bounded post-fraud reveal.
- Cross-Chain Integration Whitepaper sections 3-8 are the companion source for lockers, trust tiers,
BridgeInTxandBridgeOutTx, and the difference between internal transfer and external redemption. - Smart Cash sections 4-10 and Assets, Rights, And Vouchers Whitepaper sections 3-9 are the key sources for object-local policy, vouchers, rights, and the distinction between final cash and conditional value.
- Proof-of-Useful-Work Whitepaper sections 5-8, Agentic Offline Economy Whitepaper sections 3-8, and DAO Whitepaper sections 7-11 explain why reward systems, agent rights, and AI review surfaces must stay more tightly bounded than a generic “programmable economy” story implies.
- Privacy Threat Model And Metrics sections 3-10, OnionNet Whitepaper sections 5-9, Post-Quantum Migration Whitepaper sections 4-13, Tokenomics and Incentives Whitepaper sections 4-10, and Legal Architecture Whitepaper sections 4-17 complete the companion authority set for privacy, transport, cryptographic migration, economics, and public-claim boundaries.