Start with the ambiguity
An instruction such as prefer durable businesses sounds clear until two reviewers apply it. One may mean stable revenue; another may mean customer retention or low financing needs. Asking a model to choose silently creates a strategy that the user may never have intended.
Use a hypothetical principle: require improving operating performance. Before turning it into a rule, ask which metric, reporting basis, comparison period, publication cutoff, and exception policy apply. These are design decisions. There is no universal threshold implied by the phrase.
Write a reviewable rule card
Create a card with the original wording and the proposed interpretation side by side. State what information would make the rule pass, fail, or remain unknown. Keep the evidence locator close enough that a reviewer can inspect the exact reported measure.
- Purpose: what concern does the principle address?
- Definition: which reported or calculated value is being tested?
- Availability: which source must have been public before the decision time?
- Missing data: pause, request evidence, or use a separately approved fallback?
- Approval: which version and interpretation did the person accept?
Test the interpretation with counterexamples
For the invented operating-performance rule, construct three cases. In the first, the chosen metric improves on the chosen basis. In the second, only an adjusted metric improves. In the third, the comparable period is absent. Write the expected handling before asking an agent to run the cases.
If the output disagrees with the expected handling, investigate the definition or implementation. Do not edit the expectation merely because the model sounds persuasive. A revised rule should get a new version and a recorded reason. This exercise tests interpretability and consistency, not whether the rule earns money.
Make approval specific
Approval should refer to the actual version, data assumptions, and known omissions. A person accepting a paragraph is not automatically authorizing every later interpretation or real-world action. Changes to the source basis, fallback, or execution authority deserve another review.
OWASP recommends human oversight for sensitive actions and permission controls outside the model. The practical connection here is narrow: a natural-language instruction to ask first is weaker than a workflow that actually blocks an unauthorized action. This article does not assess any external trading integration.
Apply the method in Thesis Lab
In the current beta, begin with the principles conversation, inspect the current understanding and Unknowns, and approve/save a version before reviewing its behavior. Compare the saved interpretation with your original language. Supported simulations still have a bounded data and execution scope; approving a strategy does not turn every sentence into a tested program.
Method, sources, and limits
The rule-card exercise is an original hypothetical design method. OWASP guidance and the Thesis Lab beta release were checked on 26 October 2026. The examples are not proposed investment thresholds. Human approval can expose ambiguity but does not guarantee correctness, safety, or future returns.
Sources & checking dates
Primary references and the product release used for this guide. A source supports the claim attributed to it; it does not endorse Thesis Lab or validate an example's investment outcome.
- OWASP: LLM Prompt Injection Prevention ↗Checked 2026-10-26
- Thesis Lab beta release, checked 2026-10-26 ↗Checked 2026-10-26
Educational examples are hypothetical unless explicitly identified as a dated source observation. Product details can change after the update date.