WHAT IS A TTP?
Tactics, Techniques, and Procedures (TTPs) are the doctrinal building blocks of military action. They describe how forces operate — not what they are (that is ORBAT) or where they go (that is planning). A TTP is specific, repeatable, validated, and owned. This guide assumes zero prior knowledge and builds from first principles across all warfighting domains.
🔗 FM 7-0 · AJP-3.2 · NATO AAP-06 · Joint Pub 1-02 · USSOCOM JTTP
The Three Levels — Defined and Differentiated
T — TACTIC
Definition: A tactic is the employment and ordered arrangement of forces in relation to each other. It describes what action a unit takes to accomplish a task — the broad approach chosen from available options. Tactics are selected by commanders and may change between missions based on enemy, terrain, and conditions.
Characteristics: Broad. Intent-driven. Flexible. Commander-selected. Cannot be memorised as a single sequence — they are adaptive frameworks.
Example: "Conduct a flanking attack on the enemy's right to fix his reserves while the main effort penetrates the centre." This is a tactic — it describes the concept of the action, not the detailed steps.
ORBAT Link: Tactics are executed by the units identified in the ORBAT. The BCT, division, or corps in your ORBAT employs a tactic. The tactic cannot exist without knowing which forces are available.
T — TECHNIQUE
Definition: A technique is a non-prescriptive way or method used to perform a mission, function, or task. It describes how an action is performed within the latitude given by a tactic. Multiple valid techniques may exist for a single tactic.
Characteristics: Specific. Task-focused. Adaptable within bounds. Unit-level. Not mandatory — commanders may select among valid alternatives.
Example: "The company establishes a base of fire with two platoons at 400m range while the third platoon conducts a wide envelopment using dead ground." This is a technique — it describes the specific method of executing the flanking tactic.
ORBAT Link: Techniques are executed by the specific companies and platoons listed in the ORBAT's task organisation. The technique's feasibility depends on the unit's equipment (e.g. M2A3 Bradley vs BTR-82A changes applicable techniques fundamentally).
P — PROCEDURE
Definition: A procedure is a standard, detailed sequence of actions that must be followed to perform a task safely and consistently. It describes the exact steps, in order, required to execute an action. Procedures are mandatory — deviation requires explicit authorisation.
Characteristics: Prescriptive. Step-by-step. Mandatory sequence. Individual or team level. Often checklist-based. Repeatable with identical outcome.
Example: "Step 1: Team Leader signals FREEZE. Step 2: All personnel halt and assume the lowest available cover. Step 3: Team Leader identifies threat and confirms sector. Step 4: Radio operator sends contact report on primary net…" This is a procedure — the exact sequence for reacting to contact.
ORBAT Link: Procedures are executed by individual soldiers or teams at the lowest echelons of the ORBAT. A change in organic equipment (e.g. replacing SINCGARS with a new radio) requires a procedure update — identical capability does not mean identical procedure.
What is NOT a TTP
⚠️ CRITICAL DISAMBIGUATION
Misclassifying doctrine as a TTP — or vice versa — is a common and consequential error. TTPs must be validated. Calling unvalidated guidance a "TTP" implies a standard that has not been established. The table and examples below clarify the boundaries.
✗ NOT A TTP — DOCTRINE / PRINCIPLE
"Mass fires on the decisive point." — This is a principle of war (Mass), not a TTP. It provides no specific method, no sequence, no measurable outcome. Principles guide judgment; TTPs guide action.
✗ NOT A TTP — COMMANDER'S GUIDANCE / FRAGO
"1st Platoon will conduct a feint at grid 542318 at H-30." — This is an order for a specific operation, not a repeatable TTP. Orders are single-use; TTPs are reusable across missions and units.
✗ NOT A TTP — ANECDOTE / LESSON LEARNED
"In Fallujah 2004, 1/8 Marines found it effective to…" — This is a lesson learned or anecdote. It becomes a candidate TTP only after it is generalised, written, validated, and adopted. Before that, it is an observation.
✗ NOT A TTP — RULE OF ENGAGEMENT (ROE)
"Positive identification required before engagement." — This is an ROE. It governs authority to act, not how to act. ROE set the legal/political boundary; TTPs operate within that boundary.
✗ NOT A TTP — EQUIPMENT SPECIFICATION / TECHNICAL DATA
"The AN/PRC-152 operates on 30–512 MHz with 5W output." — This is a technical specification. The TTP associated with this radio describes how to use it in a given operational context, not its technical parameters.
✗ NOT A TTP — STRATEGY OR OPERATIONAL CONCEPT
"Multi-Domain Operations require exploiting windows of superiority across all five domains simultaneously." — This is an operational concept (MDO). Concepts generate TTPs; they are not TTPs themselves.
The Hierarchy: How TTPs Nest
TTP HIERARCHY IN CONTEXT
TTPs sit between doctrine and individual action. The chain is: National Strategy → Policy → Doctrine → Concepts → TTPs → Drills → Individual Actions. Each level constrains the next. TTPs must be consistent with doctrine; they must also be feasible for the individual to execute. A TTP that is doctrinally sound but physically impossible for a degraded unit is a bad TTP.
| Level | Tactic | Technique | Procedure |
|---|---|---|---|
| Question answered | WHAT to do | HOW to do it | EXACT steps in order |
| Commander latitude | High — selects from options | Medium — selects among valid alternatives | None — mandatory sequence |
| Typical echelon | Company to Corps | Platoon to Brigade | Individual to Squad |
| Adaptable in execution? | Yes — mission variables drive | Yes — within bounds of tactic | No — deviation requires authority |
| Documentation format | Concept / narrative + diagram | Method description + conditions | Numbered checklist / SOP |
| Validated by | SME consensus + exercise | SME consensus + simulation | Simulation + repetition metrics |
| ORBAT dependency | Force mix and echelon | Specific unit equipment | Individual's organic kit |
| Change frequency | Low — years between major changes | Medium — months to years | High — tied to equipment/threat cycles |
📚 Doctrinal References: FM 7-0 Train to Win in a Complex World · ADP 3-0 Operations · AJP-3 Allied Joint Doctrine for the Conduct of Operations · NATO AAP-06 Glossary of Terms · JP 1-02 DoD Dictionary · USSOCOM JTTP Series · USMC MCWP 5-10 Marine Corps Planning Process
ANATOMY OF A TTP
Every TTP must contain a mandatory core of information to be usable, and an optional extended body to maximise its utility. The anatomy below defines each field, explains why it exists, and shows how it connects to the validation plan. A TTP without a validation plan is an untested assumption — not doctrine.
🔗 FM 7-0 · NATO STANAG 2895 · USSOCOM TTP Format Standard
Mandatory Core Fields
🔢 TTP IDENTIFIER
Unique alphanumeric ID. Format: [DOMAIN]-[TYPE]-[SEQUENCE]-[VERSION]. Example: LND-TAC-0042-v2. Enables unambiguous cross-referencing between TTPs, ORBAT nodes, and validation records. Must be assigned at submission.
📝 TITLE
Clear, imperative-voice noun phrase. Max 80 characters. Example: "Platoon Flanking Attack Using Fire and Movement". Avoid vague titles like "Manoeuvre TTP" — the title must uniquely identify the TTP without further context.
🏷 TYPE CLASSIFICATION
Mandatory selection: Tactic / Technique / Procedure. Must also select Level (Strategic / Operational / Tactical / Sub-tactical). A single document may not span more than two adjacent levels — if it does, split it.
🌐 DOMAIN
Primary warfighting domain: Land / Maritime / Air / Space / Cyber / EW / SOF / Joint / Information. If multi-domain, list primary + secondary domains. Domain determines which validation authorities are appropriate.
🎯 TASK
The specific military task this TTP enables, referenced to a task list (e.g. METL, UJTL). Format: "Conduct [verb] [object] [conditions]". Example: "Conduct a hasty breach of a minefield under direct fire." Task anchors the TTP to measurable training objectives.
📋 CONDITIONS
The METT-TC/OAKOC conditions under which this TTP applies. Includes: threat type, terrain, visibility, friendly force capability, time constraints. A TTP valid in open desert may be invalid in dense urban terrain — conditions define the scope.
✅ STANDARDS
Measurable criteria for successful execution. Must be quantified where possible. Example: "Element reaches assault position within 4 minutes without fratricide, maintaining 360° security." Standards are the basis for validation pass/fail criteria.
💡 RATIONALE
Why this TTP exists. What problem it solves. What operational context drove its development. References the threat, the gap in current doctrine, or the lesson learned that motivated it. The rationale must be defensible independently of the TTP's content.
📌 STEPS / DESCRIPTION
The core content. For Tactics: narrative + diagram. For Techniques: method description with conditions and constraints. For Procedures: numbered sequential steps with decision points. Must be written at the literacy level of the executing echelon.
⚠️ HAZARDS & FRATRICIDE RISK
Mandatory safety assessment. Identifies risk to own forces, adjacent units, and non-combatants. Risk level (Low/Medium/High/Extreme) and required mitigations. A TTP that omits this field cannot be approved.
🗓 VALIDATION PLAN REFERENCE
Mandatory link to the TTP's validation plan record. A TTP submitted without a validation plan is automatically assigned DRAFT status and cannot be distributed. See the Validation section for plan format.
👤 PROPONENT / OWNER
The unit, organisation, or branch responsible for maintaining this TTP. Includes: primary author, review authority, date of next mandatory review. Ownership prevents TTPs from becoming orphaned as organisations change.
Optional Extended Fields
WHEN TO USE OPTIONAL FIELDS
Optional fields add analytical depth and interoperability value. They are strongly recommended for any TTP that will be shared beyond the originating unit, used in coalition operations, or submitted for NATO standardisation. They are mandatory for TTPs at the Operational level and above.
🔗 PREREQUISITE TTPs
List of TTP IDs that must be mastered before this TTP can be executed. Enables sequenced training programmes and reveals dependency chains in the TTP library.
🔄 RELATED TTPs
TTPs that address adjacent tasks, alternative approaches, or directly complement this TTP. Enables cross-referencing during planning and training design.
🎖 ECHELON APPLICABILITY
Specific echelons that can execute this TTP (from TOE/UE). Prevents misapplication — a Brigade-level tactic applied at Company level without adaptation is a planning error.
🌍 COALITION APPLICABILITY
Whether the TTP is shareable with coalition partners (REL TO [nations]), and any interoperability constraints. Relevant for NOFORN, REL TO 5EYES, NATO UNCLASSIFIED etc.
📡 C2 / COMMS REQUIREMENTS
Specific communications architecture required. Frequency bands, encryption, data links, and alternative if primary fails. Essential for cyber/EW TTPs and joint/coalition operations.
🔧 EQUIPMENT REQUIREMENTS
Specific platforms, systems, or tools needed. Distinguishes between organic equipment (always available) and supported equipment (OPCON/TACON). Validates feasibility against ORBAT.
📊 TRAINING RESOURCE ESTIMATE
Time, cost, and resources needed to train a unit to standard. Includes: minimum repetitions to reach proficiency, live-fire vs simulation training split, estimated instructor hours.
🎯 HISTORICAL VALIDATION
References to historical operations where this TTP was employed, with outcomes. Not a substitute for formal validation, but supports the rationale and speeds SME consensus.
🔒 CLASSIFICATION
Security classification level and handling caveat. UNCLASSIFIED TTPs can be widely distributed; CLASSIFIED TTPs require a parallel unclassified summary for training use.
TTP Status Lifecycle
📝
DRAFT
Submitted, not yet reviewed. Validation plan required.
→
🔍
UNDER REVIEW
SME review panel convened. Validation in progress.
→
✅
VALIDATED
Validation complete. Approved for distribution and training.
→
🔴
SUPERSEDED
Replaced by newer version or withdrawn. Archive only.
DOMAIN-SPECIFIC TTP STRUCTURES
TTPs differ fundamentally across warfighting domains. What constitutes a "procedure" in Land warfare (a step-by-step drill) differs from a cyber "procedure" (a scripted tool execution sequence) or a Space "procedure" (a satellite tasking checklist). This section maps TTP characteristics, aggregation levels, and examples across all recognised domains.
🔗 AJP-3 · JP 3-12 Cyberspace · JP 3-14 Space · ATP 3-06 Urban · AFDP 3-3 Counter-Air
Land Domain TTPs
LAND TTP CHARACTERISTICS
Land TTPs are the most mature corpus — decades of formalised doctrine across NATO, US, Russian, and Israeli schools. They range from individual reaction drills (pure Procedures) to corps-level manoeuvre concepts (Tactics). Land TTPs are heavily ORBAT-dependent: the equipment organic to the unit fundamentally determines which techniques are valid.| TTP Example | Type | Echelon | Validation Method | Key Condition |
|---|---|---|---|---|
| Frontal attack to fix while flanking | TACTIC | Company–Battalion | SME + Exercise | 2:1 superiority min, clear flanks |
| Bounding overwatch (alternate) | TECHNIQUE | Platoon–Company | SME + Simulation | Open terrain, ≥2 elements |
| React to contact — far ambush | PROCEDURE | Squad–Platoon | Repetition metrics | Contact >300m, dismounted |
| Hasty breach of wire obstacle | PROCEDURE | Squad–Section | SME + Sim + RPA | Bangalore torpedo available |
| Combined arms assault (ABCT) | TACTIC | Battalion–Brigade | SME + Exercise (BCTP) | Tank-Mech ratio ≥1:1 |
| Urban CQB room clearance | PROCEDURE | Fire Team–Squad | RPA + Simulation | Confined space, dismounted |
| RSTA screen employment | TECHNIQUE | Brigade–Division | SME consensus | SBCT / Stryker organic scouts |
| Counter-UAS low-echelon defence | TECHNIQUE | Company–Battalion | Sim + SME | Class 1–3 UAS threat, SHORAD organic |
UKRAINE LESSONS — EMERGING LAND TTPs (2022–2025)
Combat in Ukraine is generating new TTP requirements at a pace that outstrips formal validation cycles. Key emergent areas: (1) FPV drone employment and counter-FPV; (2) EW-resilient communications (frequency-hopping, StarLink integration); (3) Small unit dispersal to defeat MLRS/Lancet loitering munition targeting; (4) Drone-directed artillery (zero-adjustment fire). These are in DRAFT status pending formal validation but are already being trained. Source: RUSI Frontline reports 2022–2024.Maritime Domain TTPs
MARITIME TTP CHARACTERISTICS
Maritime TTPs operate across surface, subsurface, and littoral environments. They are platform-specific (a DDG tactic differs from an SSN tactic) but also multi-platform (CSG tactics integrate all surface/subsurface/air assets). NATO ATP-1 series is the primary maritime TTP corpus.| TTP Example | Type | Platform/Echelon | Validation | Key Condition |
|---|---|---|---|---|
| CSG layered air defence employment | TACTIC | Strike Group | SME + COMPUTEX | CVN + ≥2 DDG, AEGIS BMD |
| SSN approach to firing position | TECHNIQUE | Submarine | SME + Sim | Classified — passive sonar environment |
| UNREP (VERTREP) procedure | PROCEDURE | Ship pair | Repetition + SME | Sea state ≤3, ≥10kt SOA |
| MCM route survey — shallow water | TECHNIQUE | MCM vessel pair | SME + Sim + RPA | Depth <40m, mine threat confirmed |
| Amphibious assault wave sequencing | TACTIC | ARG/MEU | SME + Exercise (JTFEX) | LCAC/LCU + helo assets, PLDR |
| Anti-submarine barrier patrol | TECHNIQUE | SNMG + MPA | SME + COMPUTEX | SSN + MPA + sonobuoy coverage |
Air Domain TTPs
AIR TTP CHARACTERISTICS
Air TTPs are highly classified due to their direct link to platform capabilities and vulnerabilities. The unclassified corpus (AFTTP series, AJP-3.3) provides framework; classified annexes contain specific employment parameters. Air TTPs are extremely platform-specific — an F-22A tactic is not transferable to an F-35A without significant revision due to differing sensor fusion architectures.| TTP Example | Type | Platform | Validation | Key Condition |
|---|---|---|---|---|
| SEAD package execution | TACTIC | Mixed package (F-16CJ + EA-18G) | SME + Red Flag Exercise | SA-10/S-400 threat, AWACS support |
| BVR engagement — 4th gen | TECHNIQUE | F-15C/Typhoon | SME + sim (ACMI) | AIM-120 + radar lock, no chaff/flare |
| Tanker hook-up procedure (probe/drogue) | PROCEDURE | Receiver aircraft | Repetition + SME | Day VMC, speed/altitude bracket |
| CAS — 9-line JTAC call for fire | PROCEDURE | Any CAS platform | SME + RPA + Sim | JTAC present, positive ID, ROE clear |
| Strike package formation management | TECHNIQUE | 4-ship package | SME + ACMI | ECM on, radio comms EMCON plan |
| Helicopter NVG confined area landing | PROCEDURE | UH-60M/CH-47F | Repetition + SME + Sim | NVG, LZ recce complete, abort criteria set |
Space Domain TTPs
SPACE TTP CHARACTERISTICS
Space TTPs are the newest and least standardised corpus. Many are classified. Key categories: satellite tasking, orbital manoeuvre, space domain awareness (SDA), space support to joint operations, and defensive/offensive space control. Validation by simulation is dominant because live execution is expensive and has strategic consequences.| TTP Example | Type | Asset/Echelon | Validation | Key Condition |
|---|---|---|---|---|
| Satellite tasking prioritisation (JFC support) | TACTIC | Delta/JFSCC | SME + Sim (Schriever Wargame) | Multi-theatre demand, limited revisit windows |
| EO satellite tasking for time-sensitive target | TECHNIQUE | Delta 2 / ISR squadron | SME + Sim | Cloud cover <30%, target within sensor FOV |
| GPS jamming mitigation procedure | PROCEDURE | Individual platform | Sim + RPA | M-code receiver, alternative PNT available |
| SATCOM link continuity — comm degraded | PROCEDURE | Ground terminal operator | SME + Sim | Primary band jammed, alternate freq plan loaded |
| SDA reporting — RSO conjunction alert | PROCEDURE | 18th Space Control Sqn | SME consensus | Conjunction probability >1:1000, manoeuvrable asset |
Cyber & Electronic Warfare TTPs
CYBER/EW TTP CHARACTERISTICS
Cyber and EW TTPs are heavily classified and subject to rapid obsolescence as adversary systems change. The concepts below are unclassified framework-level. Validation by simulation (cyber ranges, EW emitter testbeds) is dominant. SME panels must include both cyber and domain experts — a purely technical validation without operational context produces unsound TTPs.| TTP Example | Type | Echelon | Validation | Key Condition |
|---|---|---|---|---|
| EW spectrum denial to support manoeuvre | TACTIC | Brigade–Division | SME + Exercise | EW BN organic, target comms identified |
| Direction-finding + geolocation of emitter | TECHNIQUE | MI Coy–Bn | SME + Sim | ≥3 collection platforms, 3D baseline |
| CREW system activation sequence | PROCEDURE | Vehicle crew | Repetition + SME | RCIED threat confirmed, CREW installed |
| Defensive cyberspace — incident response | PROCEDURE | CPT team | Sim (cyber range) + SME | Network intrusion detected, authority granted |
| Offensive cyber effects integration with fires | TACTIC | JTF / CEMA cell | SME + Sim (classified) | Cyber effects authority (Title 10/50), deconfliction |
Special Operations Forces TTPs
SOF TTP CHARACTERISTICS
SOF TTPs are among the most classified in the military TTP corpus. Only unclassified framework-level content is presented here. SOF TTPs are characterised by small-team execution, high adaptability, and mission-specific tailoring. Validation by Role-Play Analysis (RPA) and tabletop simulation is common because live exercise execution is resource-intensive and may compromise OPSEC.| TTP Example | Type | Echelon | Validation | Key Condition |
|---|---|---|---|---|
| Unconventional warfare network development | TACTIC | ODA / ODB | SME + RPA + historical | Permissive HN government or resistance willing |
| Direct action — sequential room clearance | PROCEDURE | Assault team | RPA + Repetition | Night / NVG, breacher organic, HVT location fixed |
| Maritime infiltration — CRRC beach landing | TECHNIQUE | SEAL platoon | SME + Sim + RPA | Sea state ≤2, CRRC × 2, surf zone recce |
| Special Reconnaissance static OP | TECHNIQUE | ODA / SEAL pair | SME + RPA | Covert insertion, observation window ≥72 hr |
| Sensitive site exploitation (SSE) | PROCEDURE | ODA / assault element | SME + RPA | Site secured, TECHINT teams available, time limit set |
Joint & Information Domain TTPs
JOINT TTP CHARACTERISTICS
Joint TTPs coordinate effects across service components. They are inherently more complex to validate because they require representatives from multiple services and often multiple nations. The Information domain (MISO, PSYOP, OPSEC, deception) is increasingly recognised as a distinct TTP domain requiring its own validation methodology.| TTP Example | Type | Echelon | Validation | Key Condition |
|---|---|---|---|---|
| Joint fires integration (JFIRE) | TECHNIQUE | JTAC / FSO / JFACC | SME + Exercise (JFIRES) | JTAC qualified, FSCL established, positive ID |
| MISO product approval and dissemination | PROCEDURE | JPOTF | SME + RPA | Approval authority delegated, target audience analysis complete |
| Deception operation (MILDEC) planning | TACTIC | JTF / Component | SME + RPA (wargame) | Deception story coherent, feedback indicators defined |
| OPSEC survey and countermeasure | PROCEDURE | Any HQ | SME consensus | Pre-operation, OPSEC officer assigned |
| Multi-domain synchronisation in CAOC | TACTIC | CAOC / JAOC | SME + Exercise (Austere Challenge) | All domain components represented, ATO integrated |
TTP LIBRARY
The library aggregates all submitted and validated TTPs. Filter by domain, type, validation method, or status. Click any card to expand the full TTP record. New TTPs are submitted via the Submit tab. The library is the authoritative reference for training planning and operational TTP selection.
0
TOTAL TTPs
0
VALIDATED
0
DRAFT
0
UNDER REVIEW
SUBMIT A TTP
Use this form to register a new TTP. Required fields are marked ★. Optional fields are marked [opt]. All submitted TTPs enter DRAFT status and must have a validation plan attached before advancing to review. The form enforces TTP classification rules — it will alert you if you attempt to mix echelon levels inappropriately.
VALIDATION METHODS
A TTP without validation is an untested assumption. Validation is the process by which a TTP is tested against measurable criteria to determine if it achieves the stated standards under the stated conditions. Three formal validation methods are recognised: SME Consensus, Simulation, and Role-Play Analysis. Each has defined strengths, limitations, and requirements. Combination validation is preferred for Tactical and above.
🔗 FM 7-0 Train to Win · TRADOC Reg 350-70 · RAND Arroyo Validation Methodology · NATO STANAG 2895
⭐ SME CONSENSUS
Expert practitioners with direct domain experience review and ratify the TTP against their collective operational knowledge. The oldest and most widely accepted validation method. Authority derives from the combined credibility of the panel.
🎮 SIMULATION
The TTP is executed in a controlled synthetic environment — live exercise, computer simulation, or hardware-in-the-loop — and outcomes measured against the standards. The only method that generates quantitative performance data at scale.
🎭 ROLE-PLAY ANALYSIS
Structured scenario-based analysis where participants play roles within the TTP's context — tabletop exercise, command post exercise, or force-on-force roleplay — with SME adjudication of outcomes. Bridges pure expert opinion and full simulation.
SME Consensus — Full Reference
WHEN SME CONSENSUS IS THE PRIMARY METHOD
SME consensus is the baseline method for all TTPs. It is the only method that captures tacit knowledge — the things experienced operators know but cannot be derived from data alone. It is particularly powerful for Tactics (broad approaches) and Techniques where the conditions cannot be fully replicated in simulation. Its limitation is subjectivity: expert panels can reach incorrect consensus, especially if SME selection is insufficiently diverse.⭐ PANEL COMPOSITION REQUIREMENTS▶
- Minimum 3 SMEs with direct operational experience at the TTP's echelon and domain. Peer review by non-practitioners is insufficient.
- Diversity requirement: Panel must represent at least two different units/organisations to prevent groupthink. A panel of 3 SMEs from the same battalion is weaker than 3 from different units.
- Currency requirement: SME experience must be within the past 5 years for rapidly changing domains (Cyber, EW, SOF), or within the past 10 years for slower-changing domains (general land warfare principles).
- Conflict of interest check: SMEs who authored the TTP may participate but must declare their involvement. They may not serve as voting members for their own TTP.
- Adversary expertise: At least one SME should have expertise in the adversary TTPs that this TTP is designed to counter or exploit.
- Domain specialist plus generalist: At least one SME should be a domain specialist (e.g. SF CQB expert for a SOF procedure) and one a broader operations generalist to check for second-order effects.
⭐ CONSENSUS PROCESS — STEP BY STEP▶
| Step | Action | Output | Timeframe |
|---|---|---|---|
| 1. Panel Convening | SME panel constituted; roles assigned; TTP distributed for independent pre-read | Panel membership list + pre-read receipt | D-14 to D-7 |
| 2. Independent Review | Each SME reviews TTP against their experience independently, without group influence | Individual comment sheets | D-7 to D-1 |
| 3. Structured Discussion | Facilitated panel meeting. Each section of TTP discussed against validation criteria. Delphi rounds if needed to resolve disagreement. | Minutes + resolution record | D0 (1–3 days) |
| 4. Consensus Vote | Formal vote per validation criteria. Record individual votes and reasoning. | Voting record with rationale | End of D0 session |
| 5. Minority Report | Any dissenting SME may append a minority report. Minority report is included in the TTP record. | Minority report (if applicable) | D0 + 3 days |
| 6. Validation Certificate | Panel chair signs validation certificate. TTP advances to VALIDATED status. | Signed validation certificate | D0 + 5 days |
| 7. Review Schedule | Set mandatory review date (typically 2–3 years, or sooner if threat/equipment changes) | Review date in TTP record | At certificate signing |
⭐ COMMON SME VALIDATION FAILURES▶
- Seniority bias: The most senior SME dominates discussion, suppressing valid dissent from junior practitioners with more recent experience. Mitigation: anonymous initial voting rounds.
- Availability bias: Panel over-indexes on recent high-profile cases (e.g. a specific battle). Mitigation: require SMEs to reference at least 3 independent examples.
- Author's authority: TTP author explains the TTP during the review, inadvertently advocating rather than submitting to independent review. Mitigation: written submission only for independent review phase.
- Missing dissent handling: Panel reaches consensus but dissenter withdraws their objection under social pressure rather than genuine persuasion. Mitigation: structured written dissent process, not open vote.
- Inappropriate SME selection: SMEs selected for availability rather than expertise. A logistics colonel validating a CQB procedure. Mitigation: mandatory experience criteria in panel charter.
Simulation Validation — Full Reference
WHEN SIMULATION IS THE PRIMARY METHOD
Simulation is the preferred primary method for Procedures and Techniques where outcomes can be quantified and the conditions can be replicated synthetically. It generates statistically valid performance data across many runs — something impossible in live exercises. Its limitation is fidelity: no simulation fully captures the human factors, equipment variability, and environmental complexity of real operations. Simulation findings must always be qualified by their fidelity limitations.🎮 SIMULATION TYPES & APPROPRIATE USE▶
| Simulation Type | Best For | Systems (examples) | Fidelity Level | Cost Level |
|---|---|---|---|---|
| Live exercise (field) | Procedures requiring physical execution; highest fidelity human factors | Field training exercise (FTX), JRTC/NTC rotation | Highest | Very High |
| Virtual / constructive simulation | Tactics and Techniques at echelon; large-scale force interactions | OneSAF, JCATS, VBS4, AFSIM, EADSIM | High | Medium |
| Hardware-in-the-loop (HWIL) | Procedures using specific equipment; sensor/weapon system procedures | Platform-specific test rigs | Very High (for systems) | High |
| Air combat manoeuvring instrumentation (ACMI) | Air-to-air tactics and techniques; BVR/WVR engagement procedures | TACTS/ACMI range (Nellis, Decimomannu) | High | High |
| Cyber range | Cyber procedures; EW frequency management; network defence | National Cyber Range, classified equivalents | High (for cyber) | Medium |
| Tabletop / wargame simulation | Tactics at operational level; strategic-level procedures | Matrix-style wargames, Connexus, MAP-HT | Low–Medium | Low |
| Agent-based model | Large-scale emergent behaviour; system-of-systems interaction | MANA, NetLogo, PYTHAGORAS | Variable | Low–Medium |
🎮 STATISTICAL VALIDITY REQUIREMENTS▶
- Minimum runs: At least 30 independent runs per scenario variant to achieve basic statistical validity. For stochastic simulations, 100+ runs are preferred.
- Variable isolation: Test one TTP change at a time. If multiple TTPs are tested simultaneously, attribution of outcomes becomes impossible.
- Baseline comparison: Always run a baseline scenario (TTP not implemented / current practice) against the candidate TTP. The comparison is what validates improvement.
- Scenario variants: Test across at least 3 scenario variants representing the range of conditions in which the TTP claims to be valid. A TTP valid in one scenario but failing in others is conditionally valid only.
- Monte Carlo sensitivity: Vary key parameters (threat capability, weather, attrition rates) within realistic bounds to assess TTP robustness. A TTP that passes only under best-case conditions is fragile.
- Report confidence intervals: All metrics must be reported with confidence intervals, not point estimates. "TTP achieves 85% success rate (CI 78–92%, n=50)" is valid; "TTP achieves 85% success" is not.
Role-Play Analysis — Full Reference
WHEN RPA IS THE PRIMARY METHOD
Role-Play Analysis (RPA) occupies the space between SME consensus (expert opinion) and full simulation (quantitative data). It is particularly effective for: SOF TTPs where live execution is OPSEC-sensitive; procedures involving human judgement and decision-making that simulation cannot replicate; TTPs that require testing against an active adversary (red team); and Tactics requiring command-post-level C2 exercise to validate.🎭 RPA FORMATS COMPARED▶
| RPA Format | Description | Ideal TTP Type | Min Participants | Duration |
|---|---|---|---|---|
| Structured TTX | Scenario-driven table discussion; participants respond to injects as they would in real operations | Tactics / Techniques | 6–12 | 4–8 hours |
| Command Post Exercise (CPX) | Full C2 element exercises without troops; communications and orders flow tested | Tactics (Company+) | 10–30 | 2–5 days |
| Seminar wargame | Facilitated structured discussion with formal turns and adjudication | Tactics (Operational) | 8–20 | 1–3 days |
| Force-on-force roleplay | BLUFOR vs OPFOR teams play out TTP with active opposition; realistic adversary response | All types | 8–16 | 4–16 hours |
| Red Team analysis | Independent adversary-perspective team attempts to defeat / exploit the TTP | Procedures / Techniques | 3–6 (red team) | 1–3 days |
| JTAC / aircrew verbal simulation | Voice-only call-for-fire / CAS procedures rehearsed without aircraft | SOF / Air CAS procedures | 2–4 | 1–4 hours |
🎭 SCENARIO INJECT DESIGN PRINCIPLES▶
- Test every decision point: Map the TTP's decision nodes and design one inject per decision point. If the TTP has no explicit decision points, add them — every TTP has implicit ones.
- Include failure injects: At least 30% of injects should represent conditions where the TTP is expected to fail or require adaptation. If participants can't identify failure modes, the TTP is incomplete.
- Adversary agency: OPFOR injects must represent intelligent, adaptive adversary responses — not passive targets. An adversary who does not react to the TTP being employed is not a valid test.
- Information degradation: Include injects representing comms failure, intelligence gaps, and fratricide risk. TTPs that only work under perfect information are operationally fragile.
- Time pressure: Inject time constraints that approximate real operational tempo. TTPs validated in unlimited time conditions may fail under operational pressure.
- After-action capture: Every inject response must be documented with the reasoning behind decisions. This is the analytical basis for the validation finding.
Method Selection Matrix
SELECTING THE RIGHT VALIDATION METHOD
Use this matrix to determine the appropriate validation method(s) for a given TTP. The matrix considers TTP type, echelon, domain, and classification. Green = primary method, Yellow = secondary/supplemental, Grey = not applicable.| TTP Type / Characteristic | SME Consensus | Simulation | Role-Play Analysis | Recommended Combination |
|---|---|---|---|---|
| Tactic (Company–Corps) | PRIMARY | SUPPLEMENTAL | SUPPLEMENTAL | SME + RPA (CPX) |
| Technique (Platoon–Brigade) | SUPPLEMENTAL | PRIMARY | SUPPLEMENTAL | SME + Simulation |
| Procedure (Individual–Squad) | SUPPLEMENTAL | PRIMARY | SUPPLEMENTAL | Simulation + Repetition metrics |
| SOF TTP (any type) | PRIMARY | LIMITED | PRIMARY | SME + RPA (OPSEC-sensitive) |
| Cyber / EW TTP | SUPPLEMENTAL | PRIMARY | SUPPLEMENTAL | Simulation (cyber range) + SME |
| Space Domain TTP | PRIMARY | PRIMARY | N/A (mostly) | SME + Sim (Schriever WG) |
| Joint / Multi-Domain TTP | PRIMARY | SUPPLEMENTAL | PRIMARY | SME + RPA (joint exercise) |
| Information Domain TTP | PRIMARY | LIMITED | PRIMARY | SME + RPA (red team) |
| Classified TTP (SECRET+) | PRIMARY | LIMITED | PRIMARY | SME + RPA (closed environment) |
| Coalition / NATO TTP | PRIMARY (multi-nation panel) | SUPPLEMENTAL | PRIMARY (LIVEX) | Multi-nation SME + Exercise |
| High-Risk / Fratricide-Prone | SUPPLEMENTAL | PRIMARY | PRIMARY | ALL THREE METHODS REQUIRED |
| Emergent / Rapid-Cycle (combat) | PRIMARY (accelerated) | TIME-LIMITED | If time allows | Accelerated SME (AAR-based) |
TTP AGGREGATION
TTP aggregation is the process of combining, reconciling, and analysing TTPs across multiple domains, echelons, and units to identify patterns, gaps, conflicts, and doctrine candidates. It is the bridge between individual TTP submissions and the institutional knowledge base. Aggregation reveals what is known, what is assumed, and where validation gaps exist.
🔗 FM 7-0 · TRADOC Reg 350-70 · Lessons Learned Programme (CALL) · NATO LLRep
Aggregation by Level
INDIVIDUAL / FIRE TEAM AGGREGATION
At this level, TTPs are Procedures. Aggregation identifies where different units are training the same procedure differently, revealing a lack of standardisation that becomes a fratricide risk in combined operations. The primary aggregation output is a baseline standard.| Aggregation Goal | Method | Output | Responsible Authority |
|---|---|---|---|
| Standardise common drills across units | Compare procedure steps across submitting units; identify deviations | Standard Operating Procedure (SOP) | Training and Doctrine Command (TRADOC) / School of Infantry |
| Identify training gaps | Map procedures to METL tasks; identify tasks with no validated procedure | Training gap analysis | Unit S3/G3 |
| Capture combat lessons | AAR-based procedure capture from deployed units; rapid aggregation cycle | Lessons Learned report → TTP candidate | Center for Army Lessons Learned (CALL) |
| Update for new equipment | Identify all procedures dependent on replaced equipment; trigger mandatory update | Updated procedure + change record | Proponent school / TRADOC |
UNIT LEVEL AGGREGATION (COY–BN)
At company and battalion level, aggregation integrates Procedures into Techniques and validates that the techniques used by sub-units are mutually compatible. The key risk at this level is technique conflict — two platoons using incompatible techniques that cause fratricide or coordination failure.| Aggregation Goal | Method | Output |
|---|---|---|
| Technique compatibility check | Matrix subordinate unit techniques against each other; identify deconfliction requirements | Technique compatibility matrix + deconfliction SOP |
| Combined arms integration | Validate that infantry, armour, and fire support techniques are synchronised at key events (breach, exploitation) | Combined arms technique document |
| Training programme design | Map validated techniques to training events; sequence from individual through collective | Unit collective training plan |
| ORBAT-TTP alignment | Validate that techniques are feasible given the unit's equipment as listed in ORBAT. Update when ORBAT changes. | ORBAT-referenced TTP validity matrix |
FORMATION LEVEL AGGREGATION (BDE–DIV)
At brigade and division, aggregation integrates Techniques into Tactics and validates that the tactical approaches of subordinate units support the commander's intent. Tactic conflicts at this level are operational failures — a brigade tactic that contradicts division concept of operations produces confusion and fratricide.| Aggregation Goal | Method | Output |
|---|---|---|
| Tactic synchronisation with operational concept | Map BCT tactics to division CONOPS; validate logical coherence | Tactic coherence assessment |
| Fire support integration | Validate that fires TTPs at BCT level are synchronised with DIVARTY HIMARS/MLRS employment TTPs | Fire support integration matrix |
| CSS TTP alignment | Validate that manoeuvre TTPs do not exceed sustainment TTPs' capacity (fuel, ammo, CASEVAC) | CSS feasibility assessment per TTP |
| Cross-domain enabler integration | Map aviation, EW, cyber, and space TTPs as enablers to manoeuvre TTPs; validate synchronisation timing | Multi-domain TTP synchronisation matrix |
OPERATIONAL LEVEL AGGREGATION (CORPS+)
At corps and above, TTPs become concepts — the building blocks of operational art. Aggregation at this level identifies doctrine candidates: TTPs that have been independently validated by multiple subordinate formations and are ready for elevation to standing doctrine.| Aggregation Goal | Method | Output |
|---|---|---|
| Doctrine candidate identification | Identify TTPs validated by ≥3 independent formations; nominate for doctrinal publication | Doctrine nomination package |
| Multi-corps TTP deconfliction | Compare TTPs of corps adjacent to each other; identify boundary and coordination TTP conflicts | Corps boundary TTP standard |
| Campaign sustainability analysis | Analyse whether TTP combinations are sustainable over extended campaign (logistics, personnel, equipment cycle) | Campaign TTP sustainability assessment |
| Theatre-wide EW/Cyber TTP integration | Synchronise cyber and EW TTPs across components to avoid mutual interference | Theatre electromagnetic warfare deconfliction matrix |
JOINT / THEATRE AGGREGATION
At joint level, TTPs from multiple services must be integrated. The primary challenge is interoperability: an Army TTP for joint fires must be compatible with Navy and Air Force TTPs for the same task. NATO TTPs must be compatible with national TTPs. This level produces STANAG candidates and Joint Publication updates.| Aggregation Goal | Method | Output |
|---|---|---|
| Service TTP interoperability validation | Cross-service SME panel reviews comparable TTPs; identifies integration failures | Joint TTP integration assessment |
| NATO STANAG candidate development | Multi-nation SME review of aligned national TTPs; develop common standard | STANAG Proposal (NSPA submission) |
| Joint Publication update nomination | Map validated joint TTPs to relevant JP; identify outdated guidance | JP update package (submitted to JCIDS) |
| Coalition TTP library development | Aggregate TTPs from coalition nations; identify compatible vs conflicting approaches | Coalition TTP compatibility matrix + REL TO distribution list |
CROSS-DOMAIN AGGREGATION
Cross-domain aggregation is the newest and most complex form — identifying where TTPs from different domains must be synchronised to produce multi-domain effects. This is the core analytical requirement of MDO doctrine. A land TTP that relies on GPS (Space TTP) and encrypted comms (Cyber TTP) must be aggregated with those enabling TTPs to reveal its true dependencies and fragility.| Cross-Domain Pair | Integration Challenge | Aggregation Output |
|---|---|---|
| Land + Space | Land TTPs assuming GPS, SATCOM, or imagery must be validated against degraded space scenarios | GPS-denied fallback procedures for each GPS-dependent TTP |
| Land + Cyber | Manoeuvre TTPs assuming digital C2 (FBCB2, ATAK) must have offline/manual fallbacks validated | Degraded comms alternatives for all digital-C2-dependent TTPs |
| Air + Cyber/EW | Air TTPs assume radar, datalink, and AWACS — all EW-vulnerable. GPS jamming affects precision munitions TTPs. | EW-degraded variants of all air TTPs involving datalinks or GPS |
| Maritime + Space | CSG TTPs assume SATCOM and GPS navigation. Anti-access scenarios include space denial. | EMCON + GPS-denied navigation procedures as TTP companions |
| SOF + Information | SOF TTPs create information effects (both deliberate and inadvertent). OPSEC TTPs must be paired. | OPSEC companion TTP for every SOF operational TTP |
| All Domains + EW | Every domain's TTPs have EW-vulnerable components. Cross-domain aggregation reveals EW dependency map. | Theatre-wide EW vulnerability assessment by TTP dependency |
🎮 AGENT-BASED TTP VALIDATION SIMULATOR
Runs a real agent-based model at 20× speed. BLUFOR and OPFOR units are instantiated with positions, movement orders, engagement ranges, morale, and C2 links derived from the TTP type and scenario. Each tick agents sense, decide, and act. The canvas renders live. Multiple runs produce statistically valid results with confidence intervals.
🔗 Agent-based model · Lanchester attrition · C2 disruption · Faster-than-realtime · Canvas 2D · Reproducible seed
⚙️ SETUP
📊 LIVE METRICS
Tick / Time—
BLUFOR alive—
OPFOR alive—
Casualties (B/O)—
Objective—
C2 intact—
Run—
AWAITING SIMULATION
Select a TTP and press RUN
📋 ENGAGEMENT LOG
No events yet.
📖 TTP GLOSSARY
Key terms used in TTP documentation, validation, and doctrine. Cross-referenced with the ORBAT Guide glossary where terms overlap. Definitions follow FM 7-0, NATO AAP-06, and JP 1-02 unless otherwise noted.
🔗 FM 7-0 · NATO AAP-06 · JP 1-02 · ADP 3-0 · TRADOC Reg 350-70
A
Accreditation
The formal process by which a simulation or model is certified as sufficiently representative of reality for a specific purpose. A simulation used for TTP validation must be accredited for that TTP's domain and echelon before its results can count as formal validation.
After-Action Review (AAR)
A structured review conducted after an operation, exercise, or training event to identify what worked, what did not, and why. AARs are a primary source of TTP candidates — lessons from AARs enter the TTP pipeline through the submission process.
Adjudication
In Role-Play Analysis, the process by which SME adjudicators determine the outcome of player decisions against scenario injects. Adjudication must be rule-based (predefined outcomes) or structured consensus (panel vote) — arbitrary adjudication invalidates RPA results.
Aggregation Level
The echelon at which multiple TTPs are combined and analysed for compatibility, gaps, and doctrine candidacy. Five levels: Individual/Team, Unit (Coy–Bn), Formation (Bde–Div), Operational (Corps+), and Joint/Theatre. Cross-domain aggregation is a sixth dimension cutting across all levels.
B
Baseline Scenario
In simulation validation, the control run representing current practice without the candidate TTP applied. Comparison of the baseline to TTP-enabled runs provides the performance delta that justifies the TTP. Without a baseline, simulation results cannot demonstrate improvement.
Battle Drill
A collective task that requires immediate response without a deliberate decision-making process. Battle drills are a subset of Procedures — they are Procedures trained to the level of automatic execution. A procedure becomes a battle drill only after sufficient repetition. Example: React to Contact, Break Contact, Enter/Clear a Room.
C
Conditions (TTP field)
The operational and environmental circumstances under which a TTP is valid. Must be explicitly stated and bounded — a TTP without defined conditions implicitly claims universal applicability, which is almost never true. Conditions define the scope of the TTP's validity certificate.
Confidence Interval (CI)
A range of values within which the true population parameter falls with a specified probability (e.g. 95% CI). Simulation validation results must be reported with confidence intervals. A result of "85% success rate (95% CI: 78–92%)" is valid; "85% success rate" without a CI is statistically incomplete.
Concept (vs TTP)
A concept describes what a future force should be able to do and how; a TTP describes how a current force performs a specific task. Concepts (e.g. MDO) generate TTP requirements; they are not themselves TTPs. Concepts precede and inform TTPs in the doctrine development cycle.
D
Delphi Method
A structured communication technique used in SME consensus validation where experts respond to questions in rounds, with anonymous feedback from earlier rounds shared before subsequent rounds. Reduces groupthink and anchoring effects. Preferred over single-round expert polling for high-stakes TTP validation.
Doctrine
Fundamental principles by which military forces guide their actions in support of national objectives. Doctrine is prescriptive at the broad level; TTPs are doctrine's operational implementation. Doctrine changes rarely; TTPs change more frequently. A TTP that contradicts doctrine is invalid unless doctrine is the error (in which case, escalate).
F
Fidelity (Simulation)
The degree to which a simulation accurately represents real-world conditions. High fidelity = realistic representation; low fidelity = abstract approximation. Fidelity must match the TTP's sensitivity to the variables being simulated. A procedure dependent on human factors requires high-fidelity simulation; a strategic-level tactic may be adequately tested in lower fidelity.
Fratricide Risk Assessment
Mandatory analysis of a TTP's potential to cause unintended casualties to friendly forces or non-combatants. Must be included in every TTP submission. Risk levels: Low (controls in place, low probability), Medium (possible without specific mitigation), High (likely without extensive controls), Extreme (TTP not approved without redesign).
L
Lesson Learned vs TTP
A lesson learned is an observation from a specific event. A TTP is a generalised, validated, repeatable method. A lesson learned becomes a TTP candidate after: (1) generalisation beyond the specific event, (2) a proponent is assigned, (3) a validation plan is developed. Most lessons learned never become TTPs — only those with broad applicability and validated effectiveness qualify.
M
METT-TC / OAKOC
Mission, Enemy, Terrain and weather, Troops available, Time, Civil considerations (METT-TC) — the US Army's analytical framework. Observation/fields of fire, Avenues of approach, Key terrain, Obstacles, Cover and concealment (OAKOC) — the terrain analysis subset. Both frameworks inform the Conditions field of a TTP and determine when a TTP is applicable.
Multi-Domain Operations (MDO)
US Army concept for operations that create and exploit temporary windows of superiority across all domains simultaneously. MDO generates a requirement for cross-domain TTP aggregation — ensuring that TTPs from different domains are synchronised rather than independent. A key output of MDO implementation is the Multi-Domain Task Force (MDTF) ORBAT structure.
O
ORBAT ↔ TTP Relationship
The ORBAT defines WHAT forces are available (structure, equipment, strength). TTPs define HOW those forces operate. A TTP is only valid if the forces executing it match the conditions defined in the TTP. When the ORBAT changes (new equipment, cross-attachment, degradation), affected TTPs must be reviewed and potentially revised. The ORBAT Guide and TTPs Guide are companion documents for this reason.
P
Proponent
The organisation assigned primary responsibility for developing, maintaining, and updating a TTP. The proponent is accountable for: keeping the TTP current, scheduling mandatory reviews, managing the validation process, and withdrawing obsolete versions. A TTP without a proponent is an orphan — it will become stale and potentially dangerous.
R
Red Team
An independent group that challenges plans, assumptions, and TTPs from an adversarial perspective. Red teams in TTP validation attempt to exploit, defeat, or circumvent the TTP being validated. A TTP that cannot withstand red team scrutiny requires revision before validation. Red teaming is particularly valuable for cyber, EW, and deception TTPs.
S
Standard (TTP field)
The measurable criteria for successful TTP execution. Must be quantified where possible. Standards are the basis for validation pass/fail determination and for training assessment. A standard must be: specific, measurable, achievable, relevant, and time-bound (SMART). Example: "Element contacts radio net within 90 seconds of task initiation with correct brevity code."
STANAG (Standardisation Agreement)
NATO agreement establishing standards for procedures, communications, equipment, and operations. TTPs that have been validated by multiple NATO nations and are of broad alliance applicability may be nominated for STANAG status. STANAG-level TTPs become mandatory for signatory nations — the highest form of TTP institutionalisation.
T
Tactic — Definition
The employment and ordered arrangement of forces in relation to each other. A tactic answers WHAT action to take. It is the broadest and most flexible of the three TTP levels. Tactics are selected by commanders based on the situation — they are not memorised sequences. A tactic changes when the enemy, terrain, or mission changes. See Foundation tab for full disambiguation.
Technique — Definition
A non-prescriptive way or method used to perform a mission, function, or task. A technique answers HOW to do it. Multiple valid techniques may exist for a single task or tactic. Techniques have conditions — they are valid only when their preconditions are met. They are adaptable within the bounds of the tactic. See Foundation tab for full disambiguation.
TTP Identifier (SIDC-style)
The unique alphanumeric code assigned to each TTP at submission. Format in this system: [DOMAIN CODE]-[TYPE CODE]-[4-digit SEQUENCE]-[VERSION]. Example: LND-TAC-0042-v2 = Land domain, Tactic, sequence 42, version 2. Analogous to the Symbol Identification Code (SIDC) in military symbology — enables unambiguous machine-readable cross-referencing.
V
Validation
The process of testing a TTP against measurable criteria under defined conditions to determine if it achieves the stated standards. Validation is not approval — it is evidence-based determination of effectiveness. Three methods: SME Consensus, Simulation, Role-Play Analysis. All TTPs in this system require a validation plan before advancing from DRAFT status.
Verification vs Validation
Often confused: Verification asks "Did we build it right?" (Does the TTP do what it claims?). Validation asks "Did we build the right thing?" (Does doing what it claims actually achieve the operational objective?). A TTP can be correctly written (verified) but operationally unsound (not validated). Both are required — verification is internal consistency check; validation is operational effectiveness test.
🕸 TTP DEPENDENCY GRAPH
Interactive network showing prerequisite chains, technique dependencies, and compound TTP packages. Nodes are colour-coded by type. Drag to pan, scroll to zoom. Click any node for the full TTP record. Arrows point from prerequisite → dependent — mastering the source TTP is required before the target can be executed.
Tactic
Technique
Procedure
Validated
Under Review
Draft
READING THE GRAPH
Arrows: direction of dependency (A → B means A must be mastered before B). Node size: number of dependents (larger = more TTPs depend on this one — high-priority training item). Edge thickness: strength of dependency (thick = direct prerequisite, thin = related/recommended). Click any node to open its full record.
📈 VALIDATION SCORE DASHBOARD
Each TTP receives a composite Validation Health Score (0–100) computed across six weighted dimensions. The score is not a pass/fail — it measures the robustness and currency of the validation evidence. Low scores flag TTPs requiring re-validation, proponent reassignment, or review scheduling before operational use.
—
AVG SCORE
0
STRONG (≥75)
0
ADEQUATE (50–74)
0
WEAK (<50)
SCORE DIMENSIONS (weighted)
| Dimension | Weight | What it measures | Max points |
|---|---|---|---|
| Validation method quality | 30% | Number and type of validation methods used; combination bonus | 30 |
| Validation currency | 20% | Time since last validation or review (decays over 3 years) | 20 |
| Threat model recency | 15% | Whether conditions reference current threat environment | 15 |
| Documentation completeness | 15% | Mandatory fields populated, optional fields present | 15 |
| Hazard assessment | 10% | Fratricide risk explicitly assessed and mitigated | 10 |
| Proponent assignment | 10% | Responsible owner identified; review schedule set | 10 |
🔗 ORBAT ↔ TTP CROSS-REFERENCE
Select a unit type or echelon from the ORBAT tree and instantly see: which TTPs are valid for that unit's organic equipment, which TTPs require specific assets from that node, and which TTPs degrade or fail if that unit is below strength or cross-attached. This is the operational bridge between the ORBAT Guide and the TTP library.
🔗 Companion: orbat-guide.html · FM 3-0 · ADP 3-0 · ORBAT unit types
SELECT UNIT / ECHELON FROM ORBAT
Select a unit or echelon to see linked TTPs.
⚡ TTP CONFLICT DETECTOR
Automatically scans the TTP library for pairs that share incompatible characteristics: conflicting frequencies, mutually exclusive conditions, simultaneous time-window claims, opposing fratricide risk profiles, or contradictory echelon assumptions. Critical for combined arms synchronisation. Run the scan whenever new TTPs are added.
Run a scan to detect conflicts across the TTP library.