• Agreed that Mao will reverse the pull request.
• Johan Sandersson and Vinod to provide examples of how they are using context data in intents
• Flesh out the specs regarding what it means to be context data compliant (Tim Kolecke and WG)

ContextData Examples presentation from Riko - notes and discussion:

• These are hypothetical examples to give an indication of what we can do.

• Not trying to present a proposal for a new standard but an evolution of the existing standard with intention of making it as easy as possible for applications to pass data without having to understand too many concepts.

• In this example you have an instrument with various IDs for that instrument.

• If you think about portfolio we started with an array of instruments but then thought you probably want to think about holding which has a holding/position, which has an instrument type so you add that instrument and add holding to it.

• Ultimately the idea is that if you send an array at top level the relationship between them is never clear so it makes sense to send it in the context of parent object with a specific type that can add metadata about it, for example, in this case the portfolioId can be metadata on this new type which has been constructed from subtypes.

• Riko walked through additional examples of contacts, organisation and RFQ, which is more complex and has more types and properties.
• The proposal is really that at a top level a context is something that must have a type so that it can be routed for intent and for context listeners and optionally it can have a name, as discussed, and a map of identifiers.
• The one addition to support these structures is that below that you can have anything else you want, in the spirit of being less restrictive, but for well known use cases more information should be provided.

Espen presentation - notes and discussion includes:

• If moving away from having an array of mixed types to more complex objects of subtypes how do we ensure that we can do context resolution.
• Walked through an RFQ scenario and different approaches available with a preference for option 2.

The intention is to make a PR that represents the information presented.

Group discussion:

• Ben Gold asked if the point of context is to actually describe each of the entities and what the expected commonality of identifiers are; what is the set of entities that this WG is to actually define?
• Leslie commented that Ben's summary is correct of what has been proposed here but that this was not the original idea of what context was supposed to be, which was supposed to 1) drive intents and each intent takes a parameter which is a context and 2) broadcast context so that apps working on a shared context have it
• Continued discussion between Riko and Leslie regarding what data should be provided and defined in context data. Agreed to take the discussion offline.
• Tim raised the possibility of adding versions in the high level interface of context maybe as an optional string parameter. There had been some discussion on it over the weekend. Riko noted that they had left this out due to its complexity and Nick agreed that it would be better to address versioning once the initial spec is agreed and discuss this across FDC3.
• Johan pointed out that broadcast and intents are two additional use cases. 
• Ben clarified that the group wants a simpler construction of context data and ultimately need to work with financial objects to define the body. Riko agreed and proposed cycling back to them with what had been proposed here today but also pointed out that they are months away from fully defining objects. Rob added that it's important not to create a hard dependency.   
• Tim proposed that the group meet next week to move forward with current momentum and aim for a vote then.
• Tim asked for feedback (objections or acceptance) on the presented proposal. Leslie noted his opposition, stating that a range of formats for an instrument is important. The rest of the group was generally supportive.