Why this guide exists
The public core defines the methodology, but definition is not the same thing as use.
This guide is for readers who want to move from understanding the methodology conceptually to using it operationally. It is not a full implementation manual, and it is not a theoretical commentary. It is a practical guide to working with the methodology as an operator.
Before anything else: resolve the canonical source
If you are using the methodology seriously, do not begin by treating visible repository state, default-branch state, or cached material as implicitly authoritative.
Begin with canonical bootstrap.
Repository:https://github.com/georgebelton/ai-interaction-methodology-public-core
Bootstrap entry point:ai-interaction-methodology/ai-interaction-methodology.md
Treat that file as a bootstrap artifact only, not as the full canonical artifact set.
Before any substantive analysis, interpretation, or execution:
- Read
CANONICAL_SOURCE_LOCK.md. - Obtain the declared pinned public reference.
- Resolve the canonical methodology, framework, and collaboration-guidelines artifacts from the declared repository, canonical file paths, and that pinned reference.
- Use only that pinned artifact set as canonical authority.
Do not use visible branch state, default-branch state, floating repository state, cached state not verified to the pinned reference, or inferred repository state as canonical substitutes.
If pinned canonical resolution cannot be completed unambiguously, halt and report exactly what is missing or ambiguous.
How to think about the three core artifacts
Once bootstrap is complete, the working model should be straightforward:
- Methodology — runtime contract
- Framework — reasoning structure
- Guidelines — interaction behavior
Do not let these blur together.
A common failure mode is to let behavior guidance act like reasoning structure, or to let presentation style act like runtime control. The methodology is easier to use when each artifact remains in its own lane.
How to approach general analysis
For general analytical work:
- resolve the canonical source set
- define the task clearly
- identify what is authoritative
- identify what is fixed and what is variable
- use the framework to structure reasoning
- keep assumptions explicit
- distinguish observed content from inferred content
- only then move toward synthesis or recommendations
The most common error is to move into solution mode before the problem has been shaped clearly enough to justify it.
How to approach troubleshooting
Troubleshooting should begin with diagnosis, not repair.
A useful pattern is:
- define the observed behavior
- separate symptoms from interpretations
- identify likely system boundaries
- identify what evidence actually exists
- identify unknowns explicitly
- use the framework to organize competing explanations
- avoid treating the first plausible explanation as the right one
- propose remediation only after the failure shape is clear
Trust AI least when it is producing a smooth root-cause story from sparse evidence.
How to approach architecture evaluation
For architecture evaluation, the methodology is most useful when it helps make tradeoffs inspectable.
A useful sequence is:
- define the system or proposal being evaluated
- define constraints
- define decision criteria
- define likely failure modes
- identify implicit assumptions
- compare alternatives against stated criteria
- preserve unresolved tradeoffs instead of smoothing them away
Do not let polished prose replace decision structure.
How to approach evidence-bound work
Some work is more sensitive to source fidelity than others.
When the task is evidence-bound, the standard should be stricter:
- identify the governing source set
- separate extraction from interpretation
- distinguish source content from generated framing
- keep uncertainty proportional to the evidence
- halt if required grounding cannot be completed cleanly
This matters most when:
- documents govern meaning
- multiple artifacts must align
- the result may be used downstream in implementation or decision-making
When to trust output
Trust output more when:
- source authority is clear
- the task is well bounded
- the reasoning structure is visible
- assumptions are explicit
- uncertainty is preserved honestly
- the output is being used as a draft, comparison, or structured thinking aid rather than as unquestioned truth
When to question output
Question output when:
- it sounds cleaner than the evidence warrants
- distinctions have been compressed away
- ambiguity has been resolved too early
- it introduces terms or assumptions you did not provide
- it appears confident without showing how it got there
- the answer is unusually smooth for a messy problem
When to halt
Halt when:
- canonical source resolution is ambiguous
- active artifact authority is unclear
- the task cannot proceed without inventing missing information
- the governing source is unavailable
- competing interpretations cannot be resolved without additional evidence
- the system is being pushed to continue past a meaningful ambiguity
Stopping is sometimes the correct result.
When to delegate
Delegate only after the problem is shaped well enough that the delegated work has a bounded contract.
That means the subtask should have:
- clear scope
- clear input authority
- clear expectations
- clear output type
- clear limits
Do not delegate confusion. Shape the problem first.
How to maintain control
Maintaining control means more than staying skeptical.
It means keeping the interaction legible.
In practice, that means:
- knowing what source is authoritative
- knowing what task is actually being performed
- knowing what the model is allowed to infer
- keeping the reasoning structure visible
- separating explanation from evidence
- rejecting polished output when the underlying structure is weak
The point is not to make the interaction rigid for its own sake. It is to keep it usable when the work becomes serious enough that structure matters.
Final point
The methodology is most useful when it is treated as operating discipline, not ornament.
The goal is not to make the interaction look sophisticated. The goal is to make it stable enough to use without quietly handing judgment over to fluency.
That is the threshold this guide is trying to protect.