MethodLayerMap my method

MethodLayer field guide · Methodology design

How to build a training methodology.

A training methodology is the decision system underneath the workouts: what the coach believes, what evidence matters, how context changes the plan, where exceptions apply, and who owns the final decision.

The goal is not to automate every judgment. The goal is to make the method explicit enough that it can be taught, tested, explained, supported by software, and improved deliberately.

01

Define the training philosophy

Write down the few beliefs that should remain true across athletes, seasons, and tools. These are principles—not detailed workout prescriptions.

02

Identify the decisions the method governs

List the recurring decisions a coach makes: progress, hold, reduce, substitute, recover, reassess, communicate, or escalate for expert review.

03

Define the inputs

Separate athlete goals, training history, readiness, adherence, subjective feedback, schedule constraints, event timing, provider data, and other context.

04

Turn heuristics into explicit rules

Document what combination of inputs changes a decision. Include thresholds, confidence, missing-data behavior, and what evidence must be visible.

05

Document exceptions and safeguards

Capture where the rule should stop, where a human must intervene, and what the system must never infer.

06

Build representative scenarios

Create easy, borderline, conflicting, and unusual cases. Ask the expert what they would do before comparing the answer with the formalized method.

07

Reconcile disagreements

If the method produces a different result than the expert, determine whether the rule is wrong, an exception is undocumented, or the input model is incomplete.

08

Version the methodology

Publish an explicit version, owner, effective date, rule set, templates, and change history. Do not silently overwrite the method.

09

Operationalize after validation

Connect methodology to workflows, software, integrations, and AI assistance once its decision logic and human authority are clear.

Example structure

Reasoning should survive execution.

Principles
  ↓
Stages / pillars
  ↓
Inputs & evidence
  ↓
Decision rules
  ↓
Exceptions & safeguards
  ↓
Proposal + rationale
  ↓
Expert approval
  ↓
Outcome & feedback
  ↓
Methodology revision

What software changes

A methodology becomes more valuable when its reasoning survives execution.

See the Methodology Studio