“It worked” is an observation without much context. A month later, it is difficult to tell what worked, why it mattered, or which setting made the difference.
A useful lab note leaves enough breadcrumbs to repeat the experiment and challenge its explanation.
Start with one question
For the trust-boundary simulation, the question is: what changes when an application checks whether a proposed action belongs to the user’s authorized task?
That question is deliberately smaller than “can we stop prompt injection?” The simulation contains a deterministic action proposal and a simplified permission rule. It does not run an LLM or measure the reliability of a real defense.
Record the setup
Write down the application version, fixture, relevant settings, and starting state. Use invented data in an isolated environment. If an experiment uses an external platform, record the permitted scope and applicable publication rules before beginning.
For this browser simulation, the setup has two inputs: the retrieved document and the permission-check toggle. No credentials or external services are involved.
Separate observation from interpretation
A compact notebook template:
Question:
Environment and version:
Input fixture:
Control being changed:
Expected outcome:
Observed outcome:
Possible explanation:
Limitations:
Next experiment:An observation might be: “With the permission check enabled, the simulated send_message proposal is denied.” The interpretation is that this example rule stops the out-of-scope action. It is not evidence that real models will always propose the same action or that every relevant tool is protected.
Change one thing at a time
Keep the input document fixed and toggle only the permission check. Then keep the permission check enabled and switch to the ordinary document. This gives you a small comparison you can actually explain.
If both the document and the policy change in the same run, a different result becomes harder to attribute.
End with a better question
The next experiment could add a second permitted action or a more specific resource rule. Would the policy distinguish reading a public note from reading a private one? What if the requested recipient changes after approval?
A good notebook does not need to sound conclusive. Its job is to preserve what happened, state what remains unknown, and make the next experiment easier to design.