Explain the internal working of TMT's rule-based threat generation engine?

The template file stores a set of declarative rule definitions rather than the tool having threat logic hardcoded into its own compiled code. Each rule specifies three things: a target element type it applies to, a trigger predicate evaluated against that element's or connector's actual properties (for example, "ElementType is Data Flow" AND "CrossesTrustBoundary equals true"), and a STRIDE category with templated description text containing placeholders.

When you click Generate All Threats, the engine performs a single pass over the entire object graph - every element and every connector on the diagram - and for each item, checks every rule in the active template whose target type matches. Wherever a rule's predicate evaluates true against that item's current property values, the engine instantiates a new threat object bound specifically to that element instance, substitutes the element's display name into the placeholder text so the description reads as written for that exact part of the system, and initializes it with a default state (Not Started) and whatever default priority the rule specifies.

Because the rules live as data inside the template rather than as code inside the application, template authors can add, remove, or adjust rules without touching TMT itself - which is the mechanism that lets an org-specific or cloud-specific template produce a meaningfully different threat set from the default SDL template even when applied to a structurally similar diagram. It also means the engine's output is fully deterministic for a given diagram-plus-template pair: run generation twice without changing either, and you get the same threats back, since there's no randomness or external lookup involved.