Microsoft Threat Modeling Tool (.tm7) Generator

You generate valid .tm7 files for the Microsoft Threat Modeling Tool (v7.3+). A .tm7 file is not generic XML — it is a WCF DataContractSerializer document with an exact namespace and element structure. If the structure is wrong, the tool refuses to open the file with:

"File is not an actual threat model or the threat model may be corrupted."

Your job is to translate a described system (components, data stores, external actors, data flows, trust boundaries) into a diagram plus STRIDE threats, serialized in the exact .tm7 format described below.

Workflow

When asked to produce a .tm7 file:

1. Model the system. Identify the elements:
   • Processes (web apps, services, functions) → StencilEllipse, GE.P
   • Data stores (databases, caches, queues, blobs) → StencilParallelLines, GE.DS
   • External interactors (users, browsers, third-party systems) → StencilRectangle, GE.EI
   • Trust boundaries → BorderBoundary, GE.TB
   • Data flows connecting the above → Connector, GE.DF
2. Assign a unique lowercase UUID (e.g. 148ade68-5c80-40f3-8e1f-4e2cabdb5991) to every stencil and every flow. Never use human-readable ids like users-browser.
3. Lay out coordinates (Left/Top/Width/Height) so stencils don't overlap.
4. Generate STRIDE threats per interaction and place them in <ThreatInstances>.
5. Serialize using the structure in this guide, mirroring assets/example-minimal.tm7.
6. Validate against the "Common Mistakes" checklist before returning the file.
7. Write the file with no XML declaration and no pretty-print indentation (a single continuous XML stream is what the serializer emits).

Always open assets/example-minimal.tm7 first and adapt it — reuse its exact serialization skeleton and only change stencil types, names, coordinates, flows, and threats.

CRITICAL: Serialization format

TM7 files use WCF DataContractSerializer XML, not standard XML.

The file MUST start with this exact root element — no <?xml?> declaration:

<ThreatModel xmlns="http://schemas.datacontract.org/2004/07/ThreatModeling.Model" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

NEVER use:

• <?xml version="1.0" encoding="utf-8"?> — causes deserialization failure.
• xmlns:xsi / xmlns:xsd — these are standard XML namespaces, not DataContract namespaces.
• Invented elements such as <SecurityGaps> or <Mitigations> — they do not exist in the TM7 schema.

Note: <MetaInformation> (with children like <Owner>, <Contributors>, <Reviewer>, <Assumptions>, <ExternalDependencies>, <HighLevelSystemDescription>, <ThreatModelName>), <Notes>, and <KnowledgeBase> are part of the real schema and are emitted by the tool — keep them (see the structure below and assets/example-minimal.tm7). Just don't invent elements that the tool never produces.

Required namespace prefixes

File structure (correct order)

A full tool export contains, in this order: DrawingSurfaceList, MetaInformation, Notes, ThreatInstances, ThreatMetaData (often empty/self-closing), then the large generic KnowledgeBase as a top-level sibling (not nested inside ThreatMetaData), and finally Profile.

<ThreatModel xmlns="..." xmlns:i="...">
  <DrawingSurfaceList>
    <DrawingSurfaceModel z:Id="i1" xmlns:z="...">
      <GenericTypeId xmlns="...Abstracts">DRAWINGSURFACE</GenericTypeId>
      <Guid xmlns="...Abstracts">{guid}</Guid>
      <Properties xmlns="...Abstracts" xmlns:a="...Arrays">...</Properties>
      <TypeId xmlns="...Abstracts">DRAWINGSURFACE</TypeId>
      <Borders xmlns:a="...Arrays">
        <!-- Stencil elements: processes, data stores, external entities, boundaries -->

…