The behavior was observed in a loopback service, local binary, local adapter, smoke path, fixture, or developer workflow.
Use when: Use for first-success docs, local quickstarts, alpha tutorials, local CLI examples, local route references, and diagnostic workflows.
Required evidence: Name the command, route, binary, configuration, fixture, environment, and expected output that reviewers can re-run or inspect.
Does not prove: Does not prove deployment posture, shared storage, restart behavior outside the named path, failure handling, multi-node behavior, or customer support coverage.
A write or record is retained by a named storage path, persistence mode, WAL, segment bundle, queue state, or adapter behavior under stated assumptions.
Use when: Use only when the docs name the product surface, storage mode, data path, acknowledgement point, restart or recovery condition, and evidence owner.
Required evidence: Attach source, route, config, test, fixture, or runbook evidence for the persistence path and the specific failure or restart condition covered.
Does not prove: Does not prove availability outcomes, broad recovery behavior, topology-independent retention, or stronger product support without operations review.
The docs can point to a named commit point before acknowledgement, such as a local WAL append, segment publication step, queue-state mutation, or product-specific acceptance rule.
Use when: Use when a page needs to explain acknowledgement order, commit sequence, record visibility, cursor movement, queue mutation, or publication sequencing.
Required evidence: Name the route or handler, the commit point, the acknowledgement condition, visibility expectations, replay or recovery assumptions, and negative cases.
Does not prove: Does not prove quorum behavior, cross-site outcomes, visible reads in another component, or a general durability claim unless those facts are separately reviewed.
Evidence shows data, messages, frames, or records copied, applied, or validated across a named source and target under a stated topology or proof slice.
Use when: Use for selected replication-status routes, target-apply routes, local replicated modes, protocol-frame evidence, or topology-specific validation notes.
Required evidence: Attach source and target identity, topology, transport, failure boundary, apply or acknowledgement rule, test output, and operations reviewer acceptance.
Does not prove: Does not prove failover, disaster recovery, support coverage, customer-owned storage publication, or every topology the product may later support.
A contract, fixture, SDK surface, schema, planned route, validation command, or product direction exists, but the complete customer-facing runtime is not live.
Use when: Use for roadmap-adjacent concepts, route shapes, schema models, SDK entry points, compatibility fixtures, and product direction that reviewers may discuss safely.
Required evidence: Name the contract, fixture, schema, prototype, design note, accepted gap, or backlog item and keep the owning maturity label visible.
Does not prove: Does not prove runtime support, customer availability, operational readiness, or compatibility with external clients until runtime evidence exists.
The claim touches sensitive product behavior or reviewer-owned risk and must not be strengthened until evidence and signoff are attached.
Use when: Use for durability, availability, security, compliance, support, scale, performance, identity, failover, cross-product, or customer-commitment language.
Required evidence: Attach evidence records, known limits, owner review, required claim labels, and product, operations, security, legal, support, privacy, or docs QA acceptance as applicable.
Does not prove: Does not approve the claim by itself. It is a hold state that tells readers and reviewers what must happen before promotion.
