I. Sources, rights, and corrections

A technical reference is useful when a reader can find the claim, identify the applicable source, and understand the limit of what it establishes. Prefer primary documentation for product interfaces, specifications, and commands. Keep a document title, owner, revision/date when available, section/page, access date, and a short paraphrase beside a consequential fact.

A source record

Claim ID and affected chapter/lesson:
Exact statement being supported:
Source title and owner:
URL, revision/date, section/page:
Access date:
Short paraphrase with units/conditions:
Status: documented / inferred / tested / unresolved
Remaining applicability question:

The same URL can support one claim and leave another unresolved. A board guide may describe a connector while a chip datasheet describes electrical limits. A test report establishes a particular observed run. Do not collapse these into one broad label such as verified hardware.

The book links primary sources near technical claims. The project hardware reference, dependency manifest, and requirements keep exact source decisions close to the code that depends on them. When a source changes, inspect the affected claim and its tests before updating the project.

Asset and code provenance

Original diagrams explain relationships; they are not screenshots of application actions. Screenshots must record genuine learner surfaces, preserve source images, and carry captions derived from their actual pixels. Constructed examples and seeded faults are labeled as such. If a live agent behaves differently from a saved instructional response, keep the actual response and adapt the explanation rather than changing the displayed answer.

Record each asset's creator/source, purpose, applicable license or permission, source path/hash, derivative path, caption/alternative text, and review status. Preserve third-party notices with dependencies. Public distribution decisions belong to the release's rights statement; an author's private teaching bundle does not automatically assign a license to every third-party item it references.

For narration, preserve the final spoken text and provider/voice provenance with actual usage records. Captions and transcripts must match the final audio, including editorial changes. A script can be ready for recording while the narrated lesson remains incomplete. Keep those statuses separate in the release evidence.

Report an erratum

An effective correction report identifies edition, chapter/lesson, location, current text or behavior, expected correction, supporting source or reproducer, and impact. Remove credentials and unrelated private material from the report. Do not send a full project archive when a small permitted excerpt explains the issue.

Example: “In the named edition, the recovery example describes the 28.0 entry boundary, but the supplied fault tag changes clearing at 27.0. The actual diff and test identify the clear-equality case. Update the explanation and affected narration; the source fix itself is unchanged.” This separates the content error from the program behavior.

Maintain the edition

Keep a change log with version/date, affected artifacts, reason, and validation repeated. A corrected prose label may need link/layout review; a changed source requirement may need tests, replay, cross-build, screenshots, and narration updates. Repeat checks because their inputs changed or a concern remains, not simply because an edition number changed.

The final verification report should distinguish content completeness, software checks, optional physical results, privacy/rights review, accessibility/layout, media synchronization, reference-LMS behavior, and human learner feedback. Agent walkthroughs are useful technical evidence but should not be described as human learner trials. A private release can be complete within its stated scope while later public publication and destination-specific administration remain separate work.