SOURCE TITLE

Source identity

Complete every identity field. Record an unknown value explicitly rather than omitting the field.

Captured material

Capture the full context needed to assess each cited decision: mechanism, prerequisites, inputs, parameters and defaults, outputs, examples, exceptions, failure conditions, recovery, and alternatives. Explain which conditions change the result. Depth follows the decision; do not pad to a fixed length.

Attach source-section locators to each evidence group: heading/number, page, table, code symbol, or comment permalink, with its edition. Label quotations, paraphrases, source examples, and locally constructed examples. Preserve negation, uncertainty, dates, units, and the force of requirements. Verify quotations against the retrieved text. A URL or abstract alone is not offline evidence.

Retain permitted complete originals and notices where useful. Add a section guide for large assets. A technical account must convey the relevant facts in original wording without claiming to be a verbatim archive; permission to copy a complete source must be established separately.

Discussion chronology (when applicable)

Record relevant participants, established roles, dates as precisely as exposed, comment permalinks, arguments, replies, corrections, disagreements, unsuccessful attempts, alternatives, and outcomes. Distinguish reported experience from confirmed behavior and proposals from shipped features. An accepted answer is not necessarily consensus; closed status does not establish a closure reason.

Record the thread state and which comments were visible. Explicitly identify collapsed replies, inaccessible activity, unknown dates, and missing permalinks. Never promote a forum command into a verified procedure without separate evidence.

Applicability and limits

Name the applicable OS, architecture, hardware/firmware, tool version, security state, and configuration. Separate historical from current guidance. Explain the implementation/test boundary. Preserve dated conflicting accounts and report contradictions for a separate decision rather than silently replacing older evidence.

Project interpretation

Explain how the evidence supports each linked decision and which alternatives it rules in or out. Keep project policy, inference, and acceptance gates separate from source claims. Link related local records for required mechanisms and dependencies. Do not change project interfaces or technical decisions while expanding a reference.

Omissions and evidence gaps

List omitted sections/assets and explain why they do not affect the decision. Identify missing evidence that does affect it and the claims that remain unverified. A complete original does not imply complete coverage of its dependencies. For failed retrievals record the URL, date, failure, and fallback; do not silently substitute another publisher or revision.

Preservation

For every asset record its filename, retrieval URL/date, revision, capture/decoding/transformation method, and SHA-256. Keep original bytes and notices unmodified; label print-friendly renderings separately. Relative links inside an original retain upstream meaning unless a transformed copy is explicitly identified. Name uncaptured dependencies.

Preserve relied-upon historical revisions under distinct names when upstream changes. Include every record and asset in SHA256SUMS, excluding that checksum file itself. Give each record one primary subject-catalog entry and update SOURCE-INVENTORY.MD with actual coverage and unresolved gaps.

Review offline against every cited claim: can the conditions, counterevidence, and reasoning be recovered without the original URL? Recheck technical details, attribution, quotations, and chronology against the source. Verify local section links, catalog completeness, assets, and licenses, then regenerate checksums and run repository checks. Record substantive corrections and remaining uncertainty; an archive check is not a runtime acceptance test.

Source document