Promotion grants permission — it never issues an instruction.

What promotion means

Permission to move up, conditional on everything else agreeing.

Promotion in the tier engine means permission to move into higher deployment tiers — larger pool budgets, more aggressive posture, expanded capital utilization inside the seven-tier allocator. What it explicitly does not mean is automatic risk increase. The permission is granted by the structural layer and remains subject to gate caps, daily tactical conditions, open-exposure capacity, and the operator's own read of whether the cycle's opportunities warrant it. A promotion-allowed state with mediocre setups on offer should produce exactly as much deployment as the setups justify, which may be none at all.

The ratchet failure

Reading permission as instruction builds a one-way risk machine.

An operator who treats every promotion as a directive deploys maximum authorized risk in every favorable state and only reduces when forced. The resulting profile is asymmetric in the worst direction: risk expands automatically on good structure and contracts only under gate compression, so the account is always at its ceiling entering any adverse stretch. This is precisely the sequencing that turns ordinary drawdowns into deep ones — maximum exposure at the top of every local peak, by policy. The permission framing exists to break the ratchet: authorization is a raised ceiling, and ceilings are for headroom, not for pressing against.

The asymmetry in the language

Restrictions bind; permissions don't.

The system's vocabulary is deliberately asymmetric, and reading it correctly resolves most confusion about what's mandatory. Caps, vetoes, suppression, and gate ceilings are binding — they remove options, and no amount of conviction restores them. Promotion, permission, and authorization are permissive — they add options the operator may decline freely. Nothing in MARS ever obliges deployment. The system can always require you to risk less; it can never require you to risk more. That asymmetry is what makes the framework safe to follow literally: obeying every binding constraint and declining every permission is a valid, if conservative, way to operate the entire system.

• Binding language: cap, veto, ceiling, suppression, lock. These remove options permanently for the cycle.
• Permissive language: promotion, permission, authorized, allowed. These offer options you may decline.
• Deploying below authorization needs no justification and no log entry. Deploying above it is an override.

Where discretion legitimately reduces

Declining authorized risk is a first-class decision.

There's a specific gap the permission framing keeps open, and it matters: the system's authorization is computed from account state and aggregate evidence, not from this cycle's actual opportunities. The engine cannot see that the week's setups are marginal, that the volatility context is awkward, or that the operator is executing poorly right now. Those observations belong to discretion, and discretion's legitimate response is to deploy less than authorized. The reverse — deploying more than authorized because the setups look exceptional — is the override path, which requires a logged reason and carries its own scrutiny. Down is free; up is documented.

The key idea

A permission system stays governable; an obligation system gets abandoned.

Systems that mandate deployment eventually collide with an operator who can see a reason not to, and the collision is resolved by ignoring the system. Framing every expansion as permission avoids the collision entirely — the operator can always comply while deploying nothing. What remains binding is only ever the protective direction, which is the direction operators are least inclined to enforce on themselves and most need enforced. That's the whole trade, and it's why the wording is worth being pedantic about.