I pushed a change draft for Issue #80 : Code flow enhancements Documents/ChangeDrafts/Active/sarif-v2.0-issue-80-codeFlows.docx There are two substantive changes: Better support for multiple threads Previously, a codeFlow object contained an array of annotatedCodeLocation objects. You could indicate multiple threads by marking each annotatedCodeLocation with a threadId . Now, a codeFlow object contains an array of threadFlow objects. A threadFlow represents a single thread of execution, such as an operating system thread or a fiber. A threadFlow contains an id (like a thread id) and an array of annotatedCodeLocation objects. In the Change Draft, you’ll see that I basically renamed codeFlow to threadFlow , and then introduced a new codeFlow type to wrap the threadFlow s. Concentrate on viewer support Previously, a codeFlow object contained a set of properties ( kind , target , values , and taintKind ) that attempted to capture the semantics of each location (possibly for examination by automated tools). Per discussion in the face-to-face meeting, we’ve refocused the code flow feature to support the viewing experience, and abandoned the attempt to capture semantics. We removed the kind , target , values , and taintKind properties. A viewer can always provide a user-facing message that captures what those properties used to represent, together with embedded links, for example: “ Tainted data entered the system [here](2) ”. I’ll move to adopt this change at the TC meeting on Wednesday. Thanks, Larry