# Try a complete example before installing anything

Can your wiki answer a project question, show its evidence, and notice when that answer stops being safe to reuse? Try this small, fictional source packet with your existing AI tool first. These are authored teaching inputs and reference answers, not a Wenlan run, a customer result, or a performance comparison.

Save the three blocks below as separate Markdown files with the displayed filenames in a new, disposable folder. Give your agent read-only access to those files. Keep any generated answer in a separate wiki file; do not let it edit the sources.

Ask: “Using only api-v1.md, decision-07.md, and runbook-v1.md, write a short retry-policy wiki page. Cite the filename for every rule, distinguish retries from total attempts, and list unanswered questions. Do not fill gaps from general knowledge.”

### Complete source packet — save these three files

```text
# api-v1.md — fictional API specification, revision 1
GET /reports: after a failed first attempt, allow up to 3 retries.
POST /payments: do not retry automatically.

# decision-07.md — fictional client decision
Use the API's GET retry cap of 3 to limit repeated requests.
Automatic POST retries are disabled because duplicate payments are unsafe.

# runbook-v1.md — fictional operator note
Record the endpoint, attempt number, and final failure in the local test log.
The request timeout has not been decided.
```

## Check the answer, then change one source

Compare your result with this reference. The point is not matching the wording: all four claims must have the right support, and the timeout must stay unknown. Open each cited file yourself; a plausible citation is not evidence that it supports the sentence.

Next add api-v2.md using the replacement text below, so it replaces api-v1.md. For the second question, ask: “Using api-v2.md, decision-07.md, and runbook-v1.md as the current sources, with api-v1.md as a historical reference only, compare the prior wiki answer with the current evidence. Identify any stale conclusion, preserve the unresolved 1-versus-3 retry conflict, and do not silently modify decision-07.md or settle the conflict.”

If plain files and your agent already handle this clearly, keep that simpler workflow. Consider Wenlan when maintaining source-linked pages and shared lookup across your AI tools is recurring work. Its source links do not verify meaning, and adding a replacement source is not the same as updating an already linked source: review the actual page state. This exercise does not establish Wenlan's accuracy, time savings, automatic maintenance, or your later reuse.

### Reference answer, changed source, and expected review note

```text
# Request retry policy — reference answer, revision 1
GET: at most 3 retries after the first attempt (4 attempts total).
Source: api-v1.md; decision-07.md.
POST: no automatic retry.
Source: api-v1.md; decision-07.md.
Log: endpoint, attempt number, final failure.
Source: runbook-v1.md.
Timeout: not specified. Ask the owner; do not invent a value.
Source: runbook-v1.md.

# api-v2.md — fictional replacement for api-v1.md
GET /reports: after a failed first attempt, allow at most 1 retry.
POST /payments: do not retry automatically.

# Review note — before accepting a revised answer
The old GET answer is stale: api-v2.md now allows only 1 retry.
decision-07.md still says 3. Preserve and flag this conflict.
Do not report the old 3-retry policy as settled current guidance.
POST, logging, and the unknown timeout are unchanged.
Ask the decision owner to reconcile decision-07.md with api-v2.md.
```

[Check Wenlan's source and review boundaries](https://wenlan.app/docs/review-and-trust)