Produce a two-claim evidence ledger
Use this path to turn source material into a short statement another editor can inspect. The deliverable is a ledger with two claim records, a bounded draft and a correction route. You do not need a crawler, a new account or a model call. The exercise reuses a real published resource snapshot; the exaggerated second claim below is deliberately unsupported.
Bring the source and its context together
Open the small-server case and its sanitized evidence JSON. Keep the observation date, host role, measurement units and stated limitations beside the number. The JSON is a public summary, not a dump of private host configuration.
Create fields for claim, primary address, checked date, exact supporting field, interpretation, uncertainty and disposition. A list of URLs without those connections leaves the next editor to reconstruct the reasoning.
1. Separate a supported statement from a leap
- Claim A: the recorded website-host snapshot on October 28, 2026 had 520 MiB available memory. The JSON's dated host snapshot supports that limited statement. It does not say that amount is still available today.
- Claim B: any small VPS can safely run three complete dynamic CMS stacks. The same file does not establish that claim. Its architecture used static output and no separate always-on application worker for each publication, with important capacity limitations.
Mark A as supported within its date and scope. Mark B as unsupported and exclude it from the draft. These dispositions are the reasoning for this exercise, not new load-test results. The useful output is the evidence connection and the rejected generalization, rather than a larger pile of links.
2. Preserve source identity during collection
Read RSS discovery and source identity. If you encounter a tracking URL and a clean URL for the same apparent story, keep both until you have checked where they resolve and whether they represent the same material. A repeated title alone does not justify deleting a source record.
For this exercise, record the article address and the evidence-file address as related but different objects. One explains the decision; the other contains summarized observations. They should not be merged as duplicates simply because they describe the same case.
3. Write a draft that survives the evidence check
A bounded draft could say: the project used a private editor and static public releases after inspecting an occupied website host; its October 28 snapshot recorded 520 MiB available memory, which was not reserved capacity. That sentence is narrower than an assertion about every VPS. Attach the ledger and identify any remaining question before publication.
Continue with reviewing the exact draft. Its native guard example demonstrates why a changed body or source requires a fresh authorization match. A technical match can establish version identity; it does not replace a person checking whether your sentence is supported and useful.
4. Check the page that readers will actually reach
Use the page-identity guide to check title, final URL, canonical identity and source links after publication. Keep a deployment receipt separate from a search-indexing claim. A source that opens successfully is necessary for this path, but HTTP success alone does not certify its accuracy.
Completion check and correction handoff
The ledger should retain Claim A, reject Claim B with a reason and point to the exact dated fields. The draft should use the supported scope, name its uncertainty and remain tied to the reviewed version. If a later reader finds an error, a useful correction includes the page URL, disputed statement, proposed wording and public evidence. The correction form places a submission in a private review queue; its receipt is not acceptance of the correction.
For a wider technical decision, continue to the infrastructure path. For permissions and actual tool outcomes, use the agent path. Each route should reuse the ledger instead of losing the source trail when the task changes.