Run the loop.

The visitor has supplied demand. The operator still has to decide whether meeting it serves the work. Frequency is a reason to inspect a gap, not an instruction to fill it.

This series began with a small job for the machine. Revision should keep that job in view. Otherwise the importer slowly becomes whatever the latest repeated sequence expects, with more answers to maintain and no clearer question behind them.

A request can stay unsupported#

Suppose the operator wants to understand what follows an offer of a synthetic backup. A broken archive response blocks that observation and deserves repair. A container listing might be unrelated. Read the surrounding exchange before adding it.

If the listing is needed to reach the archive in the intended story, supporting it has a reason. If a fixed sequence requests it regardless of the response, the proposed feature needs a stronger case. “It appears often” does not establish that case.

A good revision can leave a popular request unanswered.

This is how the machine stays coherent as it grows. The operator can explain each supported action in relation to the purpose, and can explain why other actions stop at a consistent boundary. The backlog should preserve those decisions so the same request does not restart the argument every week.

Write the change before making it#

Take a different proposal: move the archive link from a nested page into the importer’s top-level response. That will change who has a chance to see it. Decide what to compare before editing the response.

A short change note is enough to make the reasoning inspectable:

Question: Does the offered archive get requested?
Change: Move its link into the top-level response.
Keep fixed: Filename, archive contents, response behavior.
Exposure: The service sends a response containing the link.
Next action: A request names that archive.
Check: Compare requests among exposed sessions, by revision.
Undo if: The new placement contradicts the service's role.

This note separates making the offer visible from making it attractive. Total requests can rise simply because more sessions receive the link. That is useful if reach was the problem, but it does not show that exposed visitors became more inclined to follow it.

Keep both counts and their definitions. Compare how many sessions received the offer, then what was attempted among those sessions. Where repeated connections may come from the same automation, do not quietly count them as independent people.

Keep a comparison that can disagree#

Changing one detail at a time makes the result easier to read. Preserve the old response and its revision identifier, along with the new one. If feasible, compare versions over the same period under comparable conditions. Record how sessions are assigned and keep a session on one version throughout its exchange.

A lone before-and-after comparison is still useful for maintenance. It is weaker evidence about cause: traffic, availability and collection can change at the same time. Controlled honeypot experiments address that problem by making the comparison part of the design.¹

The practical consequence is simple. Describe a rise after the revision as a rise after the revision until the comparison supports a stronger explanation. Repairing the path in a local replay establishes something firmer: the specific defect no longer occurs in that check.

Set the review point in advance. Repeatedly looking until the new version appears better invites a convenient stopping point. A quiet period can end with “insufficient evidence to choose,” while a clear contradiction can justify undoing the change immediately.

Sometimes keep the old version#

A revision can produce more activity and worse material to read. Moving the archive into every response may attract routine retrievals while making the service look arranged around the bait. That tradeoff belongs in the decision, alongside any rise in requests.

Returning to the earlier version is a legitimate result. So is retaining a repair because it makes the advertised behavior correct, even when there is too little traffic to compare engagement. The reason for keeping it should say which judgment was made.

A honeypot needs a record of its own revisions as much as a record of its visitors. Without that history, the operator sees a changing sequence of actions and forgets that the instrument kept changing too.

Keep the importer’s question, the response revision and the observation boundary together. That lets the next review distinguish a visitor’s changed behavior from a changed opportunity. Part 6 applies the same discipline to a harder question: when a model chooses the next action, is the story what keeps it going?