When writing documentation or implementing algorithm/data-structure logic, make the semantics unambiguous: state the defining invariants/behavior, keep each section aligned to its exact step in the workflow, and avoid language-level ambiguity that can change correctness.

Apply as follows:

• Define invariants clearly: for data structures, explicitly state the property the structure maintains (e.g., heap parent/child ordering) and the precise rule for relationships (e.g., array parent/child indices).
• Include operational behavior & complexity: document the expected time complexity for the key operations (peek vs insert/delete for heaps, etc.).
• Align section scope to the pipeline: if the topic is a multi-step process (e.g., vector search), ensure each subsection covers the correct step (indexing/storage first; then query embedding and similarity search).
• Eliminate correctness-impacting semantic ambiguity in code: when equality or type-dependent logic matters (common in algorithm implementations), use strict comparisons to prevent unintended coercion.

Example (language semantics that affect algorithm correctness):

// Prefer strict equality to avoid coercion-based bugs in comparisons.
if (candidate === target) {
  // correct: value and type must match
}

Use this standard to guide review checklists for algorithm docs and implementations so contributors don’t accidentally change meaning while only “rephrasing” or reorganizing content.