Set the goal before planning an AION2 class build

State the situation, participation mode, and success condition this plan should address. If the job cannot be explained in one sentence, the configuration choices are unlikely to be comparable.

• Content context: what kind of activity the plan must handle.
• Constraints: time, execution load, connection environment, and available resources.
• Success condition: consistency, recovery, speed, or group contribution.

Give each layer one question so a single ranking cannot replace the analysis.

1. 01

   Role objective

   What this character must accomplish in the chosen context.

2. 02

   Core loop

   A repeatable sequence that remains usable under pressure.

3. 03

   Survival and recovery

   How the plan recovers from errors and which limits cannot be ignored.

4. 04

   Resource choices

   Where limited resources can materially change the success rate.

5. 05

   Validation log

   Record the version, date, test context, and observed result.

Results from different goals, equipment baselines, or execution levels should not be placed side by side. Hold the test context and decision rule constant, then change one main variable.

When evidence is incomplete, record unknown fields and assumptions. Do not hide uncertainty behind numbers that merely look precise.

After an update, check whether the objective changed before touching the loop or resource choices. Revise a recommendation only when new evidence changes the conclusion, and record why.

Keep the activity, test date, alternatives, and uncertain parts with the build so each change can be retested without rebuilding the entire plan.