Trading Execution Errors: A Complete Taxonomy

A trading execution error is a planned-versus-actual mismatch on one specific decision — entry, sizing, management, exit, re-entry, or cutoff — or a qualified setup the plan called for that was never taken at all. It is a narrower question than “was this a good trade,” and a narrower question than the four-way strategy/risk/execution/behavior split in trading mistakes: this taxonomy stays inside the execution layer and organizes it into seven specific error types, each with its own evidence requirement and its own common false positive.

This article is the parent reference for that layer. Measuring execution quality owns the aligned/deviated/unclassified scorecard and rate math; exit-quality diagnosis and the hesitation diagnostic each own a fully worked-out state machine for one specific error type. What none of them provides is a single place that names all seven error types side by side, with the false positive that makes each one easy to misclassify.

What counts as an execution error?

An execution error requires three things, in this order: a written, active standard for that specific decision point; an eligible decision — an actual opportunity for the standard to be followed or violated; and sufficient contemporaneous evidence to compare the planned action with the observed one. Absent any of the three, the case is unclassified, not an error.

This definition deliberately excludes outcome. A wrong-side order that turns profitable is still an execution error; a correctly sized, correctly timed entry that loses is not one. Grading execution by P&L is the single most common failure mode across every error type in this taxonomy, covered in detail below.

Planned versus actual: the evidence contract

Every error type in this taxonomy reduces to the same comparison: what the plan specified for that decision point, against what was actually done, using only information that existed at the time. Two records make that comparison possible:

Record	What it must contain
Planned action	The specific rule, condition, or range that applied — not a general intention
Actual action	What was submitted or done, with a timestamp where sequence matters

A rule stated in general terms (“don’t oversize”) cannot produce a real comparison; a rule specific enough to check later (“risk 0.5% of account equity, size derived from the stop distance”) can. Where the planned side of this record does not exist, every error type below resolves to unclassified rather than aligned or deviated — an absent standard is not evidence of compliance.

The seven execution error types

Each row below is a distinct decision point with its own eligibility condition. A single trade can touch several rows; classify each one separately rather than assigning the whole trade one label.

Error type	What it is	Evidence needed	Common false positive
Entry error	An order submitted before the setup’s predefined conditions were satisfied, or with the wrong instrument, side, or order mechanics relative to the intended entry decision	Setup criteria, condition timestamps, instrument, side, and order details	A correctly timed entry delayed by platform or network latency can look like a late or early entry from timestamps alone; check execution latency before classifying
Sizing error	The initial position quantity or initial planned risk exposure differs from the amount the plan specified for that entry	Planned risk percentage, invalidation distance, planned initial size, actual initial size	A separately predefined scale-in or scale-out leg changes exposure later but is not an initial sizing error or management deviation merely because it changes size
Management error	A post-entry adjustment to exposure, stops, targets, or another in-trade variable before the final exit that matches neither the baseline rule nor a written exception	Baseline management rule, predefined exceptions, actual adjustments with timestamps	A written volatility-based stop adjustment looks identical to an unplanned tightening unless the formula and its trigger were recorded in advance
Exit error	The position-closing action does not match the baseline rule or a predefined exception	Baseline exit rule, predefined exceptions, actual exit action	Covered in full by the five-state model in exit-quality diagnosis; do not re-derive a simplified version here
Re-entry error	A new entry after a stop-out or exit that does not meet a written reset condition	Re-entry rule, prior exit record, condition at re-entry	A second entry under a genuinely met reset condition looks like impulsive re-entry from the outside but is a planned exception, not a deviation
Cutoff / boundary error	A new entry after an active session cutoff, daily-loss limit, or trade-count boundary	Boundary definition, timestamp of the new entry relative to the boundary	Continuing to manage an already-open position past a cutoff is not a boundary error unless the written rule required flattening open positions at that boundary
Omission error	A setup the plan’s criteria classified as qualified, which the plan called for taking, that was never entered	Qualification record, entry window, absence of an order	A setup correctly held pending unmet criteria, or correctly skipped under an active boundary, is not an omission error; see the cause check below

Exit and omission errors have full standalone diagnostics elsewhere in this corpus because each resolves into more than a binary aligned/deviated call. The other five resolve against a single written standard and are covered here at the depth they require. To keep the rows mutually intelligible, classify the initial quantity under sizing; classify only post-entry exposure changes under management. A scale-in leg defined before entry remains part of the plan, not a management deviation.

Classify the cause before judging alignment

A planned-versus-actual mismatch is the classification: what action occurred relative to the rule. Why it happened is the cause, which can be analyzed only after the planned-versus-actual comparison. The financial result is the outcome, a separate field that never determines execution classification. Collapsing these layers produces the same error twice: an evidence-based override gets treated the same as a pressure-driven deviation, and a legitimate exception gets treated the same as drift.

Apply this cause check to any of the seven error types once a mismatch is confirmed:

Matches a predefined exception — not a deviation; it is a planned branch of the same rule set.
Departs from the rule because of a new, verifiable, decision-relevant fact recorded at the time — an evidence-based override; log it for prospective rule review, not as a pressure finding.
Departs from the rule tracking an observable pressure state (unrealized gain, fear of giving back profit, discomfort with a boundary) with no new information — a pressure-changed deviation.
Insufficient evidence to tell 2 from 3 — unclassified. Do not force a cause onto a mismatch the record cannot support.

This is the same cause structure exit-quality diagnosis applies specifically to exits; here it generalizes to any of the seven rows above. For omission errors specifically, the hesitation diagnostic runs a five-question version of this same check and separates a hesitation-caused miss from three other causes that resemble it: a setup that never fully qualified, a rule-based pass, and a discretionary decline.

Worked example: one session across five execution decision types

A trader’s plan for a single session specifies: enter only after a defined volume-confirmation trigger; risk 0.5% of account equity per trade with size derived from a recorded stop distance; no new entries after 11:00; and a re-entry requires price to reset below a stated reference level after any stop-out.

09:14 — Entry 1. The volume trigger fires at 09:14; the order is submitted at 09:14 with size matching the 0.5% risk calculation. Entry and sizing: aligned.
09:41 — Stop-out and re-entry. Entry 1 is stopped out. At 09:44 the trader re-enters the same instrument; price has not reset below the stated reference level, and no new decision-changing fact is recorded. Re-entry: deviation, cause = pressure-changed (tracking the discomfort of the recent loss, not new information).
10:52 — Entry 3. The volume trigger fires again at 10:50. The trader waits, rechecks the same already-confirmed volume reading twice more with no new evidence, and the position is not entered before the setup’s window closes at 10:58. Omission: the setup was qualified and the plan called for it; running the hesitation diagnostic against the record — qualified, no active boundary yet, no conscious decline, no new fact, repeated rechecking — resolves this as a hesitation-caused miss.
11:15 — Entry attempt. A new setup qualifies at 11:14, after the 11:00 cutoff. No order is submitted. Cutoff: not an error — the boundary functioned as written, and correctly declining a new entry past it is not a mismatch to classify.

The four events produce five taxonomy-row classifications: aligned entry, aligned initial sizing, a pressure-changed re-entry deviation, a hesitation-caused omission, and an aligned cutoff decision. The session therefore contains two actual deviations or omissions, two aligned decisions, and one correctly functioning boundary—not five errors. Recording the rows separately preserves which decision needs review without implying that every row touched is itself an error.

Measure error rates without denominator leakage

Six of the seven rows are trade- or decision-based: the denominator is eligible, classifiable decisions of that specific type, exactly as measuring execution quality defines it. Feed each row of this taxonomy into that scorecard as its own rule/decision-type line rather than collapsing several error types into one general “execution” rate.

Omission errors need a different denominator, because no trade exists to count. The comparable rate is opportunity-based, not trade-based:

omission rate
= eligible qualified setups the plan called for that were not entered
/ all eligible qualified setups the plan called for taking

A setup that never qualified, or that was correctly blocked by an active boundary, is structurally ineligible for this denominator — it was never an opportunity the plan called for taking. Mixing an opportunity-based omission rate with a trade-based rate from the other six rows in one combined “execution score” produces a number with two different denominators hiding inside it; report them separately.

Common false-positive patterns across the taxonomy

Treating an evidence-based override as a pressure deviation, or the reverse

Both look identical from the outside — the rule was not followed. Only the presence of a new, verifiable, decision-relevant fact recorded at the time separates them. Absent that record, the case is unclassified, not automatically pressure-changed.

Treating a correctly-declined boundary as a missed opportunity

A cutoff, daily-loss limit, or unqualified setup that the process correctly respected is not an omission error. Reviewing it as a missed trade — “I would have caught that move” — is exactly the pattern that erodes a working boundary over time.

Letting the outcome decide the classification

A profitable re-entry deviation is still a deviation; a losing aligned entry is still aligned. This applies identically across all seven rows and is the single most common way a taxonomy like this gets misapplied in practice.

Collapsing several error types into one trade-level label

One trade can contain an aligned entry, a correct size, a pressure-changed management deviation, and an aligned exit. A single “good trade” or “bad trade” label for that trade destroys the information about which specific decision needs review.

Link each error type to a bounded intervention

Error type	Where the deeper diagnosis lives
Entry, sizing, management, re-entry, cutoff	Measuring execution quality scorecard, one row per type
Exit	Exit-quality diagnosis, full five-state model
Omission	Hesitation diagnostic, when hesitation is a plausible cause
Financial association of any confirmed deviation	Cost of rule-breaking
Choosing which recurring error to address first across types	Trading mistakes classification, then prioritize by recurrence and materiality

A single classified instance rarely justifies redesigning the process. Use a recurring pattern in one row of this taxonomy — not one occurrence — to decide where to intervene.

Where Costante fits

Costante’s session planning and self-defined guardrails capture the written standard each row in this taxonomy depends on; low-friction trade and behavioral logging preserves the planned and actual action at the decision point; and structured review, discipline trends, and repeated-drift detection make it easier to see which specific row is degrading rather than reading one combined score.

Costante does not classify an execution error automatically, does not determine which cause applies to a specific mismatch, does not set entry, sizing, or exit rules, and does not connect to a broker, execute orders, or verify compliance. The trader defines every standard in this taxonomy and remains responsible for applying the cause check to their own record.

Frequently asked questions

Is every losing trade an execution error?

No. A trade can match every planned entry, size, management, and exit rule and still lose, because trading outcomes are uncertain even when the process is followed exactly. Execution error is a planned-versus-actual comparison, never a result-based one.

Can a winning trade contain an execution error?

Yes. A wrong-side order, an oversized position, or an unplanned management change can all produce a profit. The profit is recorded as a separate outcome field; the mismatch is recorded as its own classification regardless of how the trade closed.

How is an execution error different from a trading mistake?

Execution is one of four categories in the broader trading mistakes classification, alongside strategy, risk, and behavior. This taxonomy is the zoomed-in reference for the execution category specifically, split into the seven decision points where a planned-versus-actual mismatch can occur.

Does one execution error prove a recurring problem?

No. A single classified instance is one data point. Group comparable decisions by error type, rule version, and context before treating a pattern as established, and review during scheduled analysis rather than in the same pressured moment that produced the mismatch.

What if no written rule existed for a decision point?

That decision point is unclassified for that trade, not aligned or deviated. An absent standard cannot be compared against an action; the repair is writing the missing rule prospectively, not inferring one after the fact to classify a past decision.

Costante provides educational workflow tools, not financial advice. Trading involves risk.

For the broader process framework around execution quality, see trading discipline.