Data infrastructure makes public artifacts usable. It indexes references, stores retrievable evidence, powers status views, supports explorers, archives public records, and helps operators debug failures. It does not define settlement truth. A database row, search index, dashboard card, or archive object is useful only when its source, maturity, and authority boundary are clear.

The network family needs this page because data surfaces can look more certain than they are. An explorer may show a checkpoint. An indexer may show a DA reference. A support package may include an evidence export. None of those surfaces should imply private wallet meaning or final settlement unless the underlying source supports that claim.

Data Layers and Authority Labels

The index and status view are not above the checkpoint in authority. They are read models over evidence.

Public Data and Private Meaning

Public data can include publication records, DA references, checkpoint artifacts, validator verdict references, anchor records, aggregate status, and watcher alerts. Private meaning can include wallet labels, receiver context, policy text, recovery state, support notes, and user intent. Data infrastructure should not collapse those categories.

An indexer might know that a commitment exists. It may not know the user’s private description of that commitment. A status page might know that a batch is available. It may not know whether the user’s private policy context makes a claim useful. A support export might prove one fact. It should not reveal the whole wallet.

Indexing

Indexes should be derived from source artifacts. A good index records the source file, publication record, DA reference, checkpoint ID, timestamp, and maturity. It should also record what it does not know. If an index stores derived labels, those labels should be recomputable or explicitly marked as UI classification.

Indexes can drift. DA data can become temporarily unavailable. A checkpoint can be challenged. A watcher alert can be superseded. Indexers should preserve source and update history so status pages can explain changes instead of silently rewriting public memory.

Evidence Packages

Evidence packages are bounded bundles for verification, support, dispute, or status. They should include the minimum data needed: references, commitments, redacted logs, proof identifiers, maturity labels, and source links. They should avoid full wallet exports, raw private payloads, or broad telemetry.

Cross-chain integration increases the need for explicit evidence packaging. External systems may provide locks, receipts, bridge references, or lifecycle signals. Z00Z data infrastructure can carry those references, but the external system’s evidence should not be treated as Z00Z settlement by itself.

Archives

Archives preserve historical public evidence. They are not a substitute for current validation. An archived DA record may show what was published. It does not prove that the current state is mature unless the checkpoint and challenge rules say so. Archive retention should be balanced with privacy. Public artifacts may be public, but derived analytics can still create risk.

Privacy-Safe Display

Privacy-safe display starts with source limitation. Show public artifacts, aggregate health, maturity labels, checkpoint references, and evidence links. Do not show wallet-local labels, user-specific timing, receiver material, support ticket contents, private policy text, or inferred ownership graphs.

Legal architecture matters because public displays can become public claims. If a status surface says “valid,” “compliant,” “owned,” or “final,” it should have source-backed authority. Safer labels are often “published,” “available,” “observed,” “under challenge,” or “checkpointed.”

Current Repository Boundary

This repo has content data infrastructure for the website: Markdown files, frontmatter, content loaders, search coverage, and build output. It does not ship protocol indexers, archives, or explorer databases. This page documents target network data infrastructure and should be updated only when real code and tests exist.

Indexer Review Questions

An indexer should answer five questions for every record. What source artifact created this record? Which maturity label applies? Which fields are derived and which are directly observed? Which privacy class applies? Which downstream surface is allowed to display it? If any answer is missing, the index can still store raw source data for internal debugging, but public display should be blocked or narrowed.

Reviewers should also ask whether the index can be rebuilt. If a public status view depends on an indexer, the indexer should be derivable from source artifacts or documented as a cache with limitations. A non-rebuildable private database is a dangerous authority substitute because users cannot distinguish source truth from indexer memory.

Evidence Package Structure

Use a consistent evidence package shape: source, artifact ID, maturity, timestamp, data reference, validation state, privacy class, display policy, and redaction notes. A package for support can include scoped disclosure pointers. A package for public status should include only public or redacted fields. A package for protocol review can include stronger evidence, but access should be controlled.

This structure helps with cross-chain data. External lifecycle records can be attached as references without being flattened into Z00Z truth. If an external adapter fails, the package can say which source failed and which maturity label must be downgraded.

Data Retention

Retention is a product and privacy decision. Public checkpoint references may need long retention. Raw logs, lookup traces, support attachments, and per-user timing should have short and justified retention. If data is retained for audits or disputes, the purpose and access path should be explicit.

Retention policy should be part of implementation tests. A docs page can name the expected boundary, but a future indexer should prove deletion, redaction, archival, and export behavior with deterministic tests.

Implementation Readiness

Data infrastructure is implementation-ready when every public field has a source, schema, rebuild path, maturity label, privacy class, and test. If an explorer can show a field, a reviewer should be able to trace it to a source artifact or a documented derived rule. If an index cannot be rebuilt, it should be treated as operator memory, not protocol truth.

Indexers also need migration tests. When schema changes, old records should not silently gain new meanings. A checkpoint reference, DA reference, watcher alert, or anchor status created under one version should remain interpretable under the next version or be explicitly migrated. Hidden migration can turn public history into fiction.

Access Control

Not every data surface is public. Public status can show aggregate maturity and public artifacts. Operator dashboards can show more health detail. Support systems can hold scoped disclosure evidence. Security review can access incident evidence under tighter controls. These tiers should be explicit. A single all-powerful data dashboard is convenient but dangerous.

Data Quality Failures

Data quality failures include stale indexes, duplicate records, wrong maturity labels, missing DA references, incorrect external-source mapping, broken redaction, and cache serving old incident state. Each failure should have an owner and a recovery path. Otherwise users may treat stale display as live truth.

Release Gate

Data infrastructure docs become operational only when schemas, migrations, rebuild commands, redaction tests, cache invalidation tests, and public display tests exist. The release gate should prove that an index can be rebuilt from source evidence and that a privacy-sensitive field cannot accidentally move from restricted storage into a public explorer view.

The gate should include stale-data scenarios. A cache that keeps showing an old checkpoint, old DA health, or old challenge state can mislead users as much as a wrong value. Freshness is part of data quality.

Reader safety note: indexes are read models. They help people find evidence, but they are not the evidence itself. Always preserve a path back to the source artifact and maturity rule. That path is what keeps dashboards from becoming accidental authorities. It also gives support teams a safer way to explain public evidence.

Read Next

• Status And Explorer for public display rules.
• Data Availability for retrievable evidence.
• Checkpoint Anchors for anchor references.

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 section 8 for publication artifacts and public pipeline vocabulary.
• Cross-Chain Integration Whitepaper section 7 for external lifecycle and evidence boundaries.
• Legal Architecture Whitepaper section 8 for public claim and evidence boundary concerns.