Publication policy
Sources should make an explanation stronger—and correctable.
Published lessons retain inspected references and a last-reviewed date, so readers can inspect the evidence without interrupting the explanation.
Source hierarchy
Codewise prefers standards, specifications, and official documentation for technical claims. Security-sensitive and provider-specific claims are checked against authoritative documentation. Supporting references are used when they add an especially clear explanation.
Open “References & further reading” at the end of any article to see its numbered source titles, organizations, direct links, and useful explanatory notes. The list is collapsed on screen to keep the lesson readable. Every published lesson still retains inspected source metadata—including access dates, source type, and primary-source status—for validation and later freshness reviews. Publication dates are recorded only when verified.
What the dates mean
publishedAt is the date an article first became part of the public curriculum. lastReviewed is the most recent date its technical explanation and relevant references received a substantive review. It is not updated automatically to make an article appear fresh.
Facts, models, and analysis
Articles distinguish verified technical facts from simplified mental models and architecture-dependent examples. “May,” “commonly,” and “depending on the architecture” are intentional signals.
Corrections
Confirmed factual errors will be corrected in the affected article, with enough context to understand a material change. A public correction channel will be added after the repository is confirmed. Until then, no inactive issue link or invented contact address is presented.