Configuration and genesis are related, but they are not the same authority surface. This website repository has real configuration files under config/. Those files control documentation behavior, theme choices, content pipeline features, and site metadata. They do not define protocol genesis state, launch supply, validator sets, treasury powers, settlement roots, or governance authority.

Future Z00Z protocol implementation will need genesis parameters. This page explains how builders should separate current docs-repo configuration from target protocol genesis, and how to avoid maturity claims that make a website config file sound like a network launch artifact.

Current Repo Configuration

The live local configuration surface includes:

• config/site.yaml for brand label, title suffix, site description, default theme, code theme, and public metadata.
• config/content-pipeline.yaml for Markdown, HTML, alert, tab, Mermaid, collapsible, diagram, syntax, and sanitization behavior.
• config/themes.yaml for named visual themes and theme-specific values.
• package.json for executable project scripts such as npm run lint, npm run build, npm run verify, and development server commands.
• scripts/verify.sh for the local verification wrapper.

These files are authoritative for the website. If config/content-pipeline.yaml allows Mermaid diagrams, that is a real docs rendering capability. If config/site.yaml sets the default theme, that is a real site behavior. If package.json defines npm run verify, that is the local command surface. None of those facts imply that a protocol network has launched.

What Website Config Can Prove

Website config can prove how the docs site is intended to render and verify content. It can prove that Markdown features are enabled, HTML sanitization is configured, local routes load from content/docs, and the site can build under Next.js. It can also prove that the public docs use a specific brand label and content layout.

Website config cannot prove a circulating supply, genesis allocation, treasury balance, validator set, DA adapter, chain ID, fee schedule, token emission curve, bridge registry, or governance quorum. If a future page needs those values, it should point to the real protocol config or genesis file after it exists. Until then, the page should say “target parameter,” “future genesis input,” or “not defined by this repository.”

This distinction is not pedantic. Genesis values are consensus and governance facts. Website values are presentation and local build facts. Mixing them can create public overclaims and later migration risk.

Protocol Genesis Concepts

A protocol genesis artifact normally defines the starting state and constraints from which all later state transitions derive. For Z00Z, future genesis parameters may include network identity, initial roots, object domains, supported cryptographic suites, initial supply, allocation categories, vesting rules, treasury controls, validator or operator bootstrap information, protocol version, data availability assumptions, governance bootstrap rules, and feature activation gates.

The Main Whitepaper section on current contracts versus target architecture is the correct maturity frame. It distinguishes what is described as a target architecture from what exists as implementation. A genesis document should do the same. It should not bury consensus-impacting values in application config or docs frontmatter.

Protocol genesis also needs validation. A builder should expect schema checks, domain checks, supply conservation checks, allocation checks, duplicate-key checks, cryptographic-suite checks, and deterministic root derivation tests. Those tests would be protocol tests, not website build tests.

Allocation and Economic Constraints

The Tokenomics paper gives the economic context: genesis supply, allocation, vesting, circulation, and phased rollout need explicit handling. A docs site may summarize those concepts, but it should not invent exact launch numbers or treat illustrative values as final policy. A future genesis artifact must bind economic values to evidence, review, and governance acceptance.

Allocation constraints should be machine-checkable. Examples include total supply consistency, category caps, vesting schedules, unlock timing, treasury reservation rules, and restrictions on early transfer. If useful-work rewards or treasury programs exist at launch, genesis should identify which parts are active, which are gated, and which require later governance.

Phased rollout matters because a network can intentionally launch with only a subset of target capabilities. Documentation should say which features are available at genesis, which are testnet-only, which are governance-gated, and which remain research. That language protects builders from assuming every whitepaper concept is live on day one.

Governance Gates

The DAO paper describes what can be specified now, recommended launch order, and future expansion. Governance gates should define who can change which parameters, under what process, with what delay, and with what audit evidence. Examples include activating new proof systems, changing treasury policy, adjusting useful-work evaluation rules, adding bridge adapters, or upgrading protocol serialization.

Governance should not be implemented accidentally through website deployment. Changing config/site.yaml should not change protocol supply. Changing a docs page should not activate a cryptographic suite. A future governance process may publish documentation, but the documentation is the record or explanation, not the authority itself.

Builder Rules

Use these rules when adding configuration or genesis material:

• Name current website files only for behavior they actually control.
• Keep protocol genesis values in a future protocol-owned artifact, not docs frontmatter.
• Mark illustrative launch parameters as illustrative until accepted by the protocol governance process.
• Keep allocation math reproducible and testable.
• Treat governance gates as authority boundaries, not website content sections.
• Include migration paths for parameters that may change after launch.
• Keep user-facing docs synchronized with implementation evidence, not ahead of it.

Schema and Review Expectations

Website configuration should stay human-readable and easy to review, but it still needs structure. config/site.yaml should remain about site identity and presentation. config/content-pipeline.yaml should remain about content rendering and sanitization behavior. config/themes.yaml should remain about visual themes. If a value starts affecting protocol claims, it belongs in a different authority surface.

Future genesis configuration should have a schema, deterministic parsing, and tests. Review should verify unknown fields, duplicate keys, unsupported versions, invalid allocations, impossible vesting schedules, unsupported cryptographic suites, and inconsistent governance gates. It should also verify that the canonical genesis artifact can derive the expected starting root or state commitment. Those tests cannot be substituted with a docs build.

Documentation Anti-Drift

Docs should avoid phrases such as “configured in this repo” when the value is a future network parameter. Use “documented in the corpus,” “target genesis parameter,” or “not currently defined by this website repository.” If a future protocol config file is added, update the docs to point to that file directly. Until then, config/ means website configuration in this repository.

This anti-drift rule also applies to examples. A tutorial may show how to edit a theme, but that does not teach protocol governance. A tutorial may show how to enable Mermaid rendering, but that does not activate DA support. Keep examples inside the authority of the files they actually touch.

Launch Readiness Signals

A future launch-readiness checklist should not be inferred from this website. It should require protocol genesis schema validation, allocation review, cryptographic-suite review, operator bootstrap review, governance approval, security testing, recovery planning, and public communication review. Website readiness can be one item on that checklist because users need accurate docs, but it is not a substitute for network launch evidence.

If launch parameters are still unsettled, docs should say so directly. A placeholder value is safer when labeled as a placeholder than when hidden in a table that looks final. Builders can work with honest uncertainty; they cannot reliably work with accidental finality. That rule applies to every launch-facing table.

Read Next

• API Reference for current website routes and future protocol API layers.
• Verification And Tests for what local npm run verify proves and does not prove.
• Runtime Services for service boundaries around protocol launch.

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.

• config/site.yaml, config/content-pipeline.yaml, and config/themes.yaml for the current website configuration surface.
• package.json and scripts/verify.sh for the current command and local gate surface.
• Main Whitepaper section 12 for current versus target architecture framing.
• Tokenomics and Incentives Whitepaper sections 4 and 10 for genesis allocation and phased rollout concepts.
• DAO Whitepaper section 11 for governance launch order and future expansion framing.