Superman, Achilles, and How to Challenge the TLCTC Core

Kryptonite and the Heel

Kryptonite threatens Superman because he is susceptible to it. In the familiar telling of the Achilles story, the vulnerable heel explains where the arrow can succeed. These are illustrations, not evidence, but they expose a relationship worth stating carefully: an attack mechanism needs something it can exploit.

No corresponding vulnerability, no applicable threat mechanism.

That does not mean the attacker disappears, that an attempt cannot occur, or that the asset is immune to every other attack. It means this particular mechanism cannot succeed against this particular asset without the susceptibility it requires. The converse does not hold either: the presence of a vulnerability never guarantees a successful attack.

What the Core Actually Claims

The TLCTC principle behind the slogan is Axiom VI, “One Step, One Generic Vulnerability, One Cluster.” The canonical statement reads: “For every generic vulnerability, there is one threat cluster (non-overlap). Every distinct attack step exploits exactly one generic vulnerability in the attack surface, and each generic vulnerability maps to exactly one cluster.” Axiom VII adds the anchor: each attack vector is defined by the generic vulnerability it initially targets, not by technique labels or downstream effects. The slogan expresses the necessary-condition side of that relationship. It is not a separately numbered axiom, and nothing in this post adds one. Core paper, Section 5.

The word doing the work is generic vulnerability, which the core defines as the single root-level attack surface that defines a cluster: the stable, technology-independent weakness the cluster targets. It reaches well beyond a programming defect. Two of the ten make the point on their own, quoted from the framework dictionary:

• #1 Abuse of Functions: “The inherent trust, scope, and complexity designed into software functionality and configuration.”
• #6 Flooding Attack: “Finite capacity limitations inherent in any system component.”

A system can therefore work exactly as implemented and still expose an attack surface. Designed scope and finite capacity are structural susceptibilities, not bugs. Core paper, Section 4.

Why the Slogan Alone Proves Nothing

A definition cannot validate a framework. If every successful attack is answered with “there must have been a vulnerability,” and vulnerability means whatever allowed the attack to succeed, the argument is circular and nothing could ever count against it. A taxonomy that cannot lose is not a claim about the world.

So the test has to be set up before the candidate counterexample is examined. Four things must be frozen in advance, and the v2.5 core already names where each one lives:

• The definitions. The normative authority is exactly one artifact, the framework dictionary tlctc-framework.v2.5.json. The paper reproduces its cluster definitions, generic vulnerabilities and axioms verbatim.
• The scope. R-SCOPE and the cause-side partition decide what the clusters classify at all: is there an actor, did they intend it, were they entitled. Only the Attack row carries a cluster. An intended action inside a genuinely conferred entitlement is Abuse of Rights, operational risk, no generic vulnerability, no cluster, no System Risk Event. Core paper, Section 3.5.
• The classification rules. The per-cluster boundary tests in Section 4 and the precedence rules in Section 6, above all R-FLOOD, R-CHANNEL, R-SUBSTRATE and R-CRED, which resolve a weakness that is describable in two ways to exactly one cluster.
• The step criteria. What counts as one attack step. The core's answer is the generic vulnerability itself: a step that appears to belong to two clusters is two steps, each anchored in the one generic vulnerability it targets (Section 3.2), and R-EXEC forces a separate #7 step at every execution moment.

With those four fixed, the framework makes claims that can fail. Here are the four ways I propose to make it fail.

Four Challenges

1. Break the causal dependency

Identify a concrete mechanism and the generic vulnerability the framework says it requires. Then demonstrate that the same mechanism still produces the specified System Risk Event, the Compromise in which an actor holds capability over the system, after that generic vulnerability has been demonstrably removed and the other relevant conditions are preserved. That falsifies the proposed causal explanation. Whether it also refutes a core claim depends on where the error sits: in the mapping of the case, or in the cluster definition. Switching to another mechanism does not satisfy this test. Kryptonite that stops working is a finding; a different weapon is a different attack.

2. Find a missing category

Document an in-scope attack mechanism, an Attack-row step under R-SCOPE, whose independently established enabling property fits none of the ten generic vulnerabilities under the frozen definitions. This challenges completeness. Two things do not qualify. “We do not yet know how it happened” is an unresolved investigation, written ? or … in the notation, and R-UNRES-2 is explicit that those are epistemic annotations, never a cluster #11. And Abuse of Rights is not a missing category either: the core argues in Section 3.5 that a granted entitlement is irreducible by design and therefore has no generic vulnerability to define a cluster around.

3. Break unique assignment

Show that the same adequately documented step retains two incompatible cluster assignments after every applicable boundary test and precedence rule has been applied. This challenges the classification system's non-overlap claim. Two plausible labels before the rules are applied are not enough; the core says in so many words that raw descriptions may overlap and that the rules, not the categories, produce uniqueness. A missing certificate check is describable as a code defect and as insufficient channel control, and R-CHANNEL settles it. The challenge is to find a step the rules do not settle.

4. Break the single-vulnerability decomposition

Demonstrate a mechanism that requires two distinct generic vulnerabilities jointly, and that cannot be represented as separate causal steps under the agreed step criteria without inventing an intermediate event or losing an essential dependency. This is the direct test of the stronger half of Axiom VI, the “one step, one generic vulnerability” part. The framework's standing answer is always “split it.” The challenge succeeds if the split is impossible without cheating.

What the Core Already Concedes

None of this is hostile to the published text. Section 8 of the core states that the derivation is argued, not proven, and separates its two headline properties by epistemic standing. Completeness is a falsifiable hypothesis: no adversarial attack step against an in-scope system has yet been encountered for which none of the ten generic vulnerabilities is causally sufficient, and the paper itself invites the counterexample that would add an eleventh cluster or force the decomposition to be shown. Mutual exclusivity is a property of the classification system, not of raw descriptions, which is exactly why Challenge 3 is worded the way it is. And empirical validation is outstanding: the reproducibility claim is testable but not yet tested at scale. The four challenges make that invitation operational. Core paper, Section 8.

How to Submit a Counterexample

A credible submission fixes its terms before it argues. It should state:

1. the framework version, which today means the v2.5 dictionary and the v2.5.1 core paper;
2. the asset and its scope, including why the step is Attack row under R-SCOPE;
3. the mechanism, and the generic vulnerability the framework currently assigns to it;
4. the observed transition, the System Risk Event the step produced;
5. the evidence;
6. the exact proposition contradicted: which axiom, which definition, which rule.

And the same discipline binds the response. Scope must not be narrowed, definitions must not be stretched, and invisible steps must not be invented afterwards merely to preserve the answer.

Show where the causal relationship fails. A demonstrated counterexample should change the framework, not be explained away to protect it.

Further Reading

• Core paper — Axiom VI and VII (§5), the cause-side partition and R-SCOPE (§3.5), the precedence rules (§6), and the limitations the framework states about itself (§8)
• Is TLCTC Applied Mathematics? — classification as a function over Attack-row steps, and why uniqueness comes from the rules while completeness stays a hypothesis
• Ten Clusters, Not Eleven — the last time an eleventh cluster was proposed, and why it was declined
• Glossary: Generic Vulnerability and Abuse of Rights

Footnote, with a wink. A reader with a better comics collection than mine will object that kryptonite is not Superman's only weakness, and they are right. Kryptonite is a physical-layer property of the substrate, radiation acting on Kryptonian physiology, so under R-SUBSTRATE it is #8. But Superman has been talked into unsafe decisions often enough, usually with Lois Lane in the balance, to establish a second generic vulnerability: humans, and apparently Kryptonians, can be influenced. That is #9. Achilles gets the same treatment. The heel is where the arrow can succeed, but a poisoned cup would have done the job through a different susceptibility, the trust he placed in whatever was handed to him: #10, placed at the moment he drank. Myths are one-dimensional because a hero needs exactly one weakness for the story to work. Assets never have exactly one. Two generic vulnerabilities, two clusters, two mechanisms, and each one still needs its own susceptibility to work. Which is the whole point of the post.