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): ```js // 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.