What the method owns
Each method should own its own research logic and output shape. That means the method itself is responsible for how it retrieves, normalises, synthesises, and assembles its result.
- Method-specific retrieval.
- Method-specific normalization.
- Method-specific synthesis.
- Method-specific output assembly.
What the method should not own
Methods should not carry hidden project assumptions. If the project changes, the method should stay strong because it is reading system context instead of leaning on hardcoded examples.
- No hardcoded industries like banking or fleet unless the project genuinely is that.
- No fixed competitors, users, or workflows inside the processor.
- Project content should come from the system context, not from embedded fallback examples.
What a good run looks like
A good method run is grounded, method-correct, and specific to the current project. It should reflect the evidence that exists now rather than producing something generic that only looks complete on the surface.
The output should reflect the actual project, its users, and the evidence available in the workspace.
The report should use evidence and method-specific logic instead of placeholders or generic filler.
The method should stay strong even if the project category changes, because it is reading live context rather than reusing stale assumptions.
Use this page as a quality bar
When you run a method in Flowlytics, the goal is not simply to reach a completed state. The goal is to get output that is decision-ready, evidence-backed, and clearly tied to the project you are working on now.