Node operations describe how a future Z00Z runtime node should be configured, started, monitored, verified, and recovered. This website repository does not ship that node. It has docs, configuration for the website, content loaders, and verification scripts. Operator instructions must therefore separate target node responsibilities from current repo behavior.

A node can help coordinate publication, data availability, validation, checkpoint evidence, watcher handoff, useful-work inputs, and status signals. It should not become a hidden authority that replaces settlement rules, wallet local possession, or governance processes.

Node Operation Loop

The loop is operational. It does not define ownership or finality by itself.

Configuration Posture

Future node configuration should be separated from website configuration. config/site.yaml, config/content-pipeline.yaml, and config/themes.yaml control the docs site. They are not node genesis, operator policy, DA adapter configuration, validator keys, or network launch parameters.

Node config should declare network identity, version, enabled roles, DA adapters, publication policy, validation rules, watcher endpoints, logging policy, privacy settings, and upgrade gates. Any config that affects settlement or rewards should be reviewed as protocol configuration, not as a convenience flag.

Startup

Startup should fail closed. A node should not start as healthy if it cannot load required config, verify network identity, read keys, reach required DA dependencies, initialize replay protection, or identify the protocol version it supports. Partial startup states should be explicit: degraded, read-only, publishing disabled, validation disabled, watcher-only, or maintenance.

Startup logs should avoid secrets. They can show version, role, network, enabled adapters, and health. They should not print private keys, wallet payloads, recovery material, service tokens, or private endpoint lists.

Health and Monitoring

Useful node health includes queue depth, publication latency, DA retrieval success, validation reject classes, checkpoint lag, watcher handoff status, resource usage, and upgrade readiness. These metrics should be aggregated and redacted. Fine-grained per-user timing, wallet identifiers, and route intent are privacy-sensitive and should not become ordinary node metrics.

Operators also need source-linked maturity labels. A node can be up while DA is degraded. A validator can be healthy while a checkpoint is challenged. A status page can lag behind the node. Good operations treat those as distinct health signals.

Verification

Future node verification must be deeper than npm run verify. Website verify checks docs lint, search coverage, and build. Node verification should include package intake tests, DA failure tests, replay tests, validation tests, checkpoint artifact tests, watcher handoff tests, privacy redaction tests, and incident simulation.

The Proof-of-Useful-Work architecture adds another boundary. If the node interacts with work packages or evaluator evidence, tests should separate work fact evidence, value assessment, reward authorization, challenges, and appeals. Node health should not be confused with reward correctness.

DA Failures

DA failure is an operational state, not a reason to pretend data is valid. If the node cannot publish or retrieve required bytes, it should expose the failure class and stop maturity labels from advancing beyond what the evidence supports. Retrying can be useful, but retry loops should not hide unavailability from watchers or operators.

Watcher Alerts and Incidents

Watcher alerts should feed incident routing. An incident can be operational outage, privacy leak, stale anchor, validator conflict, useful-work dispute, data unavailability, or support escalation. Each type needs an owner and an evidence bundle. A node operator should not resolve a governance or liability case through an ad hoc local command unless the protocol explicitly grants that authority.

Logs and Retention

Logs are operational evidence and privacy risk. They should use structured classes, redaction, retention limits, and access control. Logs should preserve enough context to debug DA, validation, and checkpoint issues, but not enough to reconstruct private wallet behavior. If support needs more evidence, it should use scoped disclosure rather than broad log export.

Current Repository Limits

This repository can document the node operation model and verify docs quality. It cannot start a node, publish DA, run validators, or prove checkpoint maturity. Any command that claims to run a Z00Z node should be added only after the implementation exists in the repo and is covered by tests.

Operator Runbook Shape

A future node runbook should be structured around states, not just commands. For each role, define startup prerequisites, healthy state, degraded state, read-only state, maintenance state, incident state, and shutdown state. The runbook should show which metrics prove the state, which alerts fire, and which operator actions are allowed. If an action can affect protocol evidence, it needs stronger review than an action that restarts a dashboard.

Runbooks should also distinguish local repair from protocol escalation. A local operator can rotate logs, restart a process, retry DA publication, or isolate a bad cache when policy allows it. A local operator should not silently change a checkpoint, override a validator verdict, forgive linked-liability evidence, or activate a governance-gated feature. Those actions require protocol-defined authority.

Configuration Review

Node configuration should be reviewed for both correctness and privacy. A reviewer should ask which keys are loaded, which endpoints are public, which logs are retained, which DA adapters are trusted, which watcher destinations receive evidence, and which fields could reveal wallet activity. Configuration should have safe defaults and should make dangerous options visible.

Versioning is part of configuration. A node that accepts a package format, checkpoint schema, DA adapter, or useful-work evidence version should reject unsupported versions deterministically. Silent coercion is an operations risk because it can make two nodes believe they checked the same evidence when they did not.

Incident Evidence

Every incident should produce an evidence bundle. The bundle should include the incident class, first observed time, affected role, source artifact, maturity impact, privacy impact, operator actions, and next review owner. It should not include secrets or full wallet exports. If private evidence is needed, the incident should link to a scoped disclosure process.

This evidence model makes post-mortems useful. Operators can compare DA outages, validation rejects, watcher alerts, and status delays without mixing them into one generic “node down” category.

Deployment Boundaries

A future deployment guide should identify which role the node is running: publication, validation, watcher, DA adapter, status, useful-work support, or a combined local profile. Combined profiles may be convenient for test networks, but they should not erase authority boundaries. A process that runs publication and status together should still label publication receipts differently from status display.

Deployment docs should also distinguish local development from public network operation. A local simulator can use short retention, mock DA, and permissive logging if clearly labeled. A public operator cannot inherit those defaults. Production profiles need stricter privacy, key management, monitoring, retention, and incident review.

Upgrade Handling

Node upgrades can affect schema versions, DA adapters, validation rules, checkpoint maturity, watcher alerts, and public labels. An upgrade runbook should say which changes are local, which require protocol coordination, which need governance, and which require user communication. Upgrades should never silently reinterpret old evidence.

Release Gate

Before node operations become public operator instructions, the docs should link to real implementation evidence: config schema, startup command, health endpoint, validation tests, DA tests, watcher tests, privacy tests, and incident runbook. If any item is missing, the page should remain a target-architecture guide. That gate prevents readers from running imaginary infrastructure.

The release gate should be written into the summary for any future operations plan. It should name the command tested, the role tested, the privacy checks run, and the remaining unsupported roles. That keeps local development instructions from being mistaken for public network guidance.

Reader safety note: an operations page can be practical without being deployable. Until startup, health, privacy, and incident tests exist, the safe operator action is to treat this as a boundary map for future implementation.

Read Next

• Publication Pipeline for actor order.
• Data Availability for failure handling.
• Watchers for alert and evidence boundaries.

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.

• Main Whitepaper sections 8 and 12 for publication architecture and current-versus-target maturity.
• Proof-of-Useful-Work Whitepaper section 4 for useful-work layer separation.
• Privacy Threat Model And Metrics section 10 for validation, telemetry, and simulation expectations.