An AI operating loop: from evidence to checked work

The same small loop should connect a customer problem to a checked result: observe, decide, prepare, review, act within authority, verify, and learn.

Conceptual illustration. It does not show the Pineapple interface or a measured result.

Each step leaves a useful record for the next person or AI run. If there is nothing meaningful to do, record the reason and stop.

1. Observe a specific problem

Collect only the evidence needed for the task. Check the date, source, and customer context. A repeated error event is not automatically several affected people; an unrecorded action is not automatically something a customer failed to do.

Pineapple already has reports, customer-journey reviews, and a shared findings log. Those remain the starting points.

2. Decide what would help

Name the customer, the blocked step, and the result that would count as progress. Inspect existing pages, tickets, and tools. Select an update, a new piece of work, a request for more evidence, or no action.

Choose one owner and a review date. For an experiment, record the expected change and a condition that would make you stop before seeing the result.

3. Prepare something reviewable

Write the explanation, reproduce the bug, or prepare the proposed change. Separate what is observed from what is inferred. Where a product task is described, check that the actual product supports the steps.

At this stage, “draft saved” means a real draft exists. It says nothing about publication or customer success.

4. Review and act within authority

Check factual support, privacy, usability, and the exact permission required. An approval belongs to the reviewed action and version. Material changes to the content, destination, scope, or spend need another check.

Keep the work ready while approval is pending. Do not substitute a different live action to get around the boundary.

5. Verify what happened

Read back the saved result. For publication, visit the public page and check the content, links, and visibility. For a customer outcome, inspect the actual journey or the appropriate evidence source.

If an external request times out, check whether it succeeded before trying again. A retry must not create a second message, duplicate page, or second charge.

6. Learn without rewriting history

Append the result, failures, corrections, and next decision. Keep canceled and inconclusive experiments visible in their original register. Update a reusable instruction only when the lesson applies beyond one case.

Actual example: a domain FAQ

On 18 October we checked the pricing FAQ against Pineapple's domain guide and maintained support facts. The pricing answer could be read as including a purchased domain; the guide separates registration from connection. We prepared one replacement answer for the existing pricing page, kept the connection guide as the detailed reference, and left publication off.

Read the complete case and actual draft, then use the same inputs and prompt. This example proves draft preparation and checking. It does not prove fewer support requests or a successful domain connection.

Use the weekly review template to keep the decision and result together.

Updated 19 October 2026.