Examples are useful only when they tell the truth about maturity. A Z00Z example can teach a current docs-repo workflow, illustrate a target protocol concept, or simulate a future flow. It should not blend those categories into one impressive but misleading tutorial. Builders should always know whether they are running current code, reading a conceptual walk-through, or following a scenario that still needs implementation.

The current repository supports documentation examples through content/docs, the Markdown renderer, local configuration, and npm run verify. It does not ship a protocol node, production RPC, WASM wallet, settlement engine, or useful-work evaluator. Future examples must keep that boundary visible.

What Counts as a Real Example

A real example has four properties:

• It states its maturity: current repo, target architecture, simulation, or future implementation.
• It names concrete files, commands, or source documents that support the tutorial.
• It has an expected outcome that a reader can verify locally or conceptually.
• It avoids implying authority that the demonstrated surface does not have.

For this repository, a current-code example might show how docs frontmatter is loaded, how Markdown content is rendered, how Mermaid diagrams are enabled, or how npm run verify checks lint, search coverage, and build. A target protocol example might explain how a payment request would move from wallet intent to publication and settlement, but it must label any unimplemented step as target architecture.

Tutorial Composition Flow

The flow starts with scenario selection, not code snippets. The Use Cases paper and appendix B help select examples that exercise important architectural families: wallet-local possession, rights mobility, selective disclosure, policy-bound objects, services, and delayed settlement. A good tutorial suite should cover diverse risk surfaces rather than repeating one easy success path.

Current Repository Examples

Current repo examples should use only files and commands that exist. Good examples include:

• Editing a docs page under content/docs and verifying it with npm run verify.
• Checking a docs page’s YAML frontmatter against the content loader’s expected fields.
• Demonstrating that config/content-pipeline.yaml enables Markdown features such as Mermaid diagrams while HTML scripts remain controlled.
• Using src/lib/content/docs.ts as the source anchor for docs loading and navigation behavior.
• Explaining that src/app/api/dev/content-version/route.ts is a development content helper, not a public protocol API.

These examples should be precise about what they prove. A passing build proves the website builds. It does not prove protocol settlement. A content-version response proves a dev helper exists. It does not prove network status. A Mermaid diagram proves rendering support. It does not prove the depicted system is implemented.

Target Protocol Examples

Target examples can still be valuable. They should be written like design scenarios, not runnable claims. A target wallet example might show the sequence from receiver material to package preparation, publication, watcher status, and settlement maturity. A target storage example might show a key, path, leaf, proof, and root relationship. A target useful-work example might show work evidence, fact consensus, value consensus, reward authorization, and appeal.

Each target step should link to source material in the whitepaper corpus and state what implementation surface is missing. For example: “This step is target architecture until a rollup-node module exposes package intake and tests.” That sentence is more useful than pretending a command exists.

Target examples should also include failure branches. A tutorial that never shows invalid proof, missing data availability, replay, privacy over-disclosure, or unsupported maturity teaches the wrong lessons. Boundary failures are where builders learn the protocol.

Scenario-Based Structure

Use this structure for new tutorials:

1. Scenario and maturity label.
2. Source links from content/whitepapers and local repo files.
3. Actors and roles.
4. Current repo steps, if any.
5. Target architecture steps, if any.
6. Expected evidence.
7. Failure branch.
8. Privacy or authority boundary check.
9. Verification command or conceptual review gate.
10. Read-next links.

This structure prevents examples from becoming isolated snippets. It makes the reader see why the example exists, which authority it uses, and what they can verify.

Source Claim Discipline

Every tutorial step should connect to a source. Local repo steps connect to local files. Protocol steps connect to whitepaper sections. External standards, when used, connect to official specs. If a step has no source, it should either be removed or marked as an open design proposal.

The Main Whitepaper’s current-versus-target framing is the maturity anchor. Use it to keep examples honest. The Use Cases paper is the scenario anchor. Use it to choose examples that cover real product and protocol value rather than only the easiest narrative.

Example Types to Avoid

Avoid examples that:

• Create fake CLI commands for protocol components not present in the repo.
• Treat website APIs as settlement APIs.
• Use generic “mock success” data without naming what is mocked.
• Skip privacy-sensitive fields in wallet, support, or disclosure flows.
• Present soft confirmation as final settlement.
• Collapse useful-work evidence, value judgment, and reward authorization into one service response.
• Use a diagram as proof that implementation exists.

These examples may look friendly, but they create concept drift and make later implementation harder.

Example Review Checklist

Before publishing a tutorial, review it with the same questions a builder will ask while copying it:

• Which files or commands can I run today?
• Which steps are conceptual only?
• Which whitepaper sections justify the protocol terms?
• Which output proves the step succeeded?
• Which privacy or authority boundary could be misunderstood?
• Which failure branch should I test before trusting the happy path?

If a tutorial cannot answer those questions, it needs more structure. The fix is usually not more prose; it is clearer maturity labeling and tighter evidence links. For current-code examples, the expected output should be a command result, file change, build result, or rendered docs behavior. For target architecture examples, the expected output should be a conceptual artifact such as a package, proof reference, maturity label, or evidence record, with the implementation gap stated directly.

Maintaining Examples

Examples need maintenance as the repo changes. When a local path changes, update the tutorial instead of leaving a stale command. When a target component becomes implemented, replace conceptual wording with source-linked implementation wording. When an implementation is removed or postponed, downgrade the example back to target architecture. Do not keep old examples because they read well; keep only examples that point to current evidence.

Phase 002 closeout should also scan examples for accidental overclaims. The highest-risk phrases are “run the node,” “call the protocol API,” “open the WASM wallet,” “settled,” “final,” “verified,” and “private by default.” Each phrase is acceptable only when the example names the authority and evidence behind it.

Reader-Friendly Formatting

User-friendly examples should be explicit without being noisy. Start with a short goal, show prerequisites, label current versus target steps, then show expected evidence. Use diagrams when they clarify boundaries, not as decoration. Keep long command blocks limited to commands that actually exist. For target flows, prefer structured pseudo-steps over fake terminal output.

Good examples also explain what not to conclude. After a docs build example, say that the build proves website integrity, not protocol settlement. After a target payment flow, say which components are missing locally. That negative space prevents the tutorial from becoming misleading. It also keeps future implementation tickets smaller, clearer, and easier to verify against the original source claim. Readers should never have to infer maturity.

Read Next

• Simulator for scenario validation and failure branches.
• API Reference for current and future API layer boundaries.
• Verification And Tests for local gates and review loops.

Evidence and Further Reading

Use the source bullets below as an audit checklist, not decoration: when reusing this page, preserve the named section scope, the responsible actor, and the split between live repository evidence, target architecture, and open design work.

• Use Cases Whitepaper section 3 and appendix B for use-case selection, scenario families, and scoring guidance.
• Main Whitepaper section 12 for current versus target architecture framing.
• content/docs for current docs examples and content pages.
• src/lib/content/docs.ts and src/lib/content/markdown.ts for the current docs loading and Markdown rendering surfaces.
• package.json and scripts/verify.sh for local verification commands.