7.1.1: the Algorithm says “no effort tier,” but the ISA skill still gates HARD on E1–E5 — deliberate structural scale, or unfinished sweep?

[DolphusCY]

I run a customised LifeOS instance and bring releases forward by merging rather than clean-installing. Reconciling my ISA subsystem against 7.1.1, I hit a contradiction that's in the shipped release, not my merge.

The doctrine says there are no tiers. LIFEOS/ALGORITHM/v8.4.0.md:

There is no effort tier to declare, no predicted execution class, and no model-routing rubric.

But the ISA skill still gates hard on them. skills/ISA/SKILL.md (spec v2.13.0), over the full E1–E5 table:

## Tier Completeness Gate (HARD at all tiers)

And the format spec contradicts itself. LIFEOS/DOCUMENTATION/Isa/IsaFormat.md deletes the count-floors in its own changelog:

The hard numeric ISC count floors (≥16/≥32/≥128/≥256) are DELETED and replaced by the Coverage Gate.

…while its body, unswept, still reads:

effort: Determines ISC count range and time budget. See Algorithm for tier definitions.
Tier Completeness Gate (HARD at every tier, NEW v2.7)

So the doctrine says "no tiers," the ISA skill gates HARD on E1–E5, and the format spec disagrees with its own changelog inside one file.

It's not one stray line — seven files in the shipped ISA subsystem still carry the tier machinery (count of tier / E1–E5 / count-floor references, Examples excluded as tagged-historical):

skills/ISA/SKILL.md                          33
LIFEOS/DOCUMENTATION/Isa/IsaFormat.md        28
skills/ISA/Workflows/CheckCompleteness.md    24
skills/ISA/Workflows/Scaffold.md             20
LIFEOS/DOCUMENTATION/Isa/IsaSystem.md        15
skills/ISA/Workflows/Interview.md             4
skills/ISA/Workflows/Seed.md                  3

I think the resolution is hiding in your own frontmatter design. You already split mode into two layers:

• Layer 1 — response_mode: minimal | native | algorithm (the router, retired 2026-07-11)
• Layer 2 — mode / algorithm_mode: iterate | optimize | ideate | loop (kept)

That's exactly the distinction I'd want for tier: a cognitive-effort tier (how hard to think — clearly retired) versus a structural-completeness tier (which sections a done ISA must contain — arguably worth keeping).

So my question: is the ISA's E1–E5 the retired cognitive tier leaking through — a sweep that didn't finish — or a deliberately-kept structural-completeness scale that reuses the E1–E5 labels? If it's the latter, the collision is worth renaming, because from the outside no tier to declare in the doctrine and Tier Completeness Gate (HARD) in the skill read as a straight contradiction. The half-swept IsaFormat.md is the main reason I can't tell which you intended.

[danielmiessler]

Straight answer: it was both, and the unfinished half just got finished.

Unfinished (now swept): the ISA workflows still carried three operational instructions telling the model to consume the retired classifier's GOAL_SIGNAL / INTERVIEW_ELIGIBLE hints — dead signal lanes from the modes/tiers system. Those were removed in source this week (issue #1524 / PR #1525 by @jbmml, ported with credit).

Deliberate (what remains): the E1–E5 scale inside the ISA skill is now an internal structural-depth scale — it answers "how much ISA structure does this piece of work carry" (Goal+Criteria floor for trivial tasks, full fifteen-section body for enterprise-shaped work, project ISAs never below the E3 structural minimum). Nothing routes on it anymore: no classifier predicts it, the Algorithm doesn't declare it, and the model elects the depth by judgment the same way it elects any other capability. That's the distinction that survived the retirement — predicting effort before work starts is gone; naming how much structure an artifact carries stayed, because the completeness gate needs a vocabulary for what "structurally complete" means at different scales.

Whether that vocabulary should lose the E-labels entirely (pure content-driven gating, no scale names) is a fair follow-up question — it's on the list, but it touches the live completeness gate and the work-tracking pipeline, so it gets its own careful pass rather than a drive-by rename. Good catch, and exactly the right question to ask.