# TEA Platform (Phase 3 Planning)

:::success
**Previous Phases**

- Phase 1: Original prototyping and research.
- Carried out with REG (Nick and Markus) to support work with the Ministry of Justice.
- Mike Katell and I developed a framework for them, which they're currently implementing and developing: https://github.com/alan-turing-institute/safed-assurance
- David Leslie and I wrote a journal article on the general methodology and framework: https://link.springer.com/article/10.1007/s43681-022-00178-0
- Phase 2: Development of tool and methodology in context of health and healthcare.
- Originally in context of Mental Healthcare (TAS Hub funded project): https://www.turing.ac.uk/sites/default/files/2022-11/final-report.pdf
- Then, in context of Health and Healthcare (TEA-DH funded project).
:::

### Ideas, Features, and Questions

Below are the features and research avenues I wanted to explore over the next 6 months:

1. Public gallery to share assurance cases and receive community feedback
- GSN compatible dialogue
- Add ability to have accessible case study summary to accompany the assurance case (reuse existing interface developed for Turing Commons)
- Use to showcase projects of TRIC-DT (Kalle)
- Use to showcase projects of DT Hub (Sophie)
- Use to showcase argument patterns of SSAFE-D Principles (Chris)
2. Is JSON the right file format for the assurance cases?
- SACM metamodel standard proposes XMI (see reasons below).
- I had originally considered XML instead of JSON, but went with the latter because more complex schema validation (e.g. relationships between elements in a graph) was not originally a priority when prototyping the tool... so much for avoiding technical debt 🤦‍♂️
- Steffen (KCL) had thoughts on this as well. I would suggest we speak with the data wrangling team and Steffen as a priority.
3. Explore desirability/feasibility of GSN/SACM functionality for TEA platform (e.g. with decorators and metamodel support)
- What tools (open- and closed-source) are currently available for safety cases (e.g. [d-Case Editor](https://github.com/d-case/d-case_editor), [ASCE](https://www.adelard.com/asce/))?
- What gaps exist in current standards and tooling landscape that the TEA platform addresses?
- I expect that accessibility and simplicity will be the main one, based on the original research I did into this. For instance, the SACM metamodel standard is off-putting to non-technical (safety case) experts to say the least: https://www.omg.org/spec/SACM/2.2/PDF However, I wasn't systematic with my original research, so it could be nice to have something we can put on the website (e.g. a comparison blog post of sorts).
- Possible opportunity to build impact by linking GSN community, DT Hub community, and local councils (e.g. Greater London Authority, LOTI) alongside Jen, Shakir, and Ibrahim
- Malvika may also be interested because of links to NASA (e.g. [AdvoCATE tooling](https://ntrs.nasa.gov/citations/20220009664))
- However, safety case standards are *complicated* (see AdvoCATE user guidance above), and present barriers to non-technical stakeholder engagement. Goal of TEA platform is to be a FAIR tool.
4. Explore integration of LLMs into TEA platform
- Have a fine-tuned instance of LLaMa (or some other open-source model) that can be used as a reflective/deliberative aid.
- What training data would be used?
- Would this be ethical in itself? Here, I'm working on a talk and workshop plan to do some public engagement (another good, and possibly high impact, RAM activity). I'll share it with you at some point, and you will see why I've been playing with AutoGen studio.
5. Integrate project pages documentation into TEA platform (i.e. away from separate static site generator)
- Enable ability for tooltips to pull through relevant data to show inside of case builder (e.g. definitions of elements, video tutorials)
6. Work with AI Standards Hub and Turing Way teams to integrate content from respective sites
- API for standards hub database, that allows users to see relevant standards (filtered by types and domains) -- work with Shakir to achieve this.
- Reference TTW content in TEA platform guidance.

:::info
**What is XMI?**

🚧 *(ChatGPT Answer)*

XMI (XML Metadata Interchange) documents are a standard way of exchanging metadata information via XML (Extensible Markup Language). Developed by the Object Management Group (OMG), XMI is primarily used in the field of software engineering and systems modeling. It plays a crucial role in the interoperability between different tools and platforms, especially in the context of model-driven engineering. Key aspects of XMI include:

1. **Standard Format for Metadata**: XMI provides a standardized format for representing metadata, such as UML (Unified Modeling Language) models, in XML. This standardization is vital for sharing models between different tools and platforms.
2. **Model Serialization**: XMI allows complex models (like UML diagrams or other modeling languages) to be serialized into XML. This means models created in one tool can be saved as an XMI file and then opened or further processed in another tool.
3. **Interoperability**: By offering a common format for different modeling tools, XMI enhances interoperability. This is essential in environments where different tools are used for various stages of software development or systems engineering.
4. **Versioning and Extensibility**: XMI supports versioning and is extensible, allowing it to adapt to new versions of modeling languages and standards.
5. **Widespread Adoption**: Many modeling tools and software engineering platforms support XMI, making it a widely adopted standard in the industry.

---

*Kalle addition (further ChatGPT):*

While JSON offers simplicity, human readability, and ease of use with web technologies, XMI’s strengths lie in its depth, interoperability with modeling tools, and suitability for representing complex data and relationships. **Choosing between XMI and JSON would depend on the specific needs of the TEA platform users, including the complexity of the assurance cases, the tools they are using, and the requirements for interoperability and long-term maintenance of the assurance documentation**.

**Interoperability with Modeling Tools**: XMI is designed to work seamlessly with UML modeling tools, making it an ideal format for exporting assurance cases that may need to be visualized or further developed in a range of software engineering and design tools. This interoperability allows for a broader adoption and easier integration into existing workflows, especially in environments where UML is a standard.

**Richer Semantic Representation**: XMI provides a richer set of semantics for representing data, beyond the key-value pairs of JSON. This means that assurance cases, which often involve complex relationships and dependencies, can be more accurately and expressively modeled. The ability to represent these nuances is critical for the detailed analysis and review processes assurance cases undergo.

**Standardization and Documentation**: As part of the Object Management Group (OMG) standards, XMI comes with strong documentation and widespread support within the engineering and IT communities. This standardization ensures that the format is stable, well-understood, and likely to be supported by tools and systems for the long term, reducing the risk of obsolescence or compatibility issues.

**Enhanced for Complex Structures**: Assurance cases, particularly those involving intricate arguments or a large body of evidence, can benefit from XMI’s capability to accurately model complex structures and hierarchies. This is due to XMI’s roots in UML, which is designed to handle the complexity inherent in software and systems engineering projects.

**Better Versioning and Evolution Tracking**: XMI's structure and support for modeling semantics make it well-suited for tracking changes and versions over time, an essential feature for assurance cases as they evolve. This ability to track the evolution of an assurance case within the same file format can facilitate audits, revisions, and compliance checks.

:::

---

## Steffen <> TEA dev team meeting on Feb 8

Steffen working in the DT space
- works with simulation, reusable modelling environment
- assurance cases hooked into the simulations? "Is this the right smulation model to build?"
- got speaking to Chris that way
- we can do better than working with JSON

Structured argument but not GSN (a simplified format) for that.

Let's look at this as language
- expectation on what's *inside* a file: there's a language.
- 1. SACM/GSN aren't very deep inside of it (core concepts) -> What is it that you fundamentally do differently from these languages? How do they look/feel v. set of concepts they capture.
- more interested in here: different in the set of concepts that you support compared to SACM/GSN.
- 2. The tooling provided: JSON is low-bar end. You can through schemas and check them. Cross-referencing and checking for uniqueness is difficult in JSON. Is that a problem?
- I can help you make it easier.

Chris context:
- first phase: rapid prototyping for engaging with ministry of justice. ethical framework and they wanted a tool to put together platform. (2 REG members)
- audience new to assurance cases.
- less expressive/more accessible structure to argument pattern. (didn't think then we needed all that GSN has)
- engaging/testing with MoJ
- (I wasn't even aware of SACM or at the level of scaling things up)
- second phase
- not development of platform, but methodology
- then also moved roles, and Kalle joined.
- pointed out all the mistakes that I had made
- third phase (now)
- new source of funding to address some of those mistakes
- I want to maintain value (from beginning): an accessible form of argument-based assurance
- Ibrahim + Shakir have worked in GSN. Difference now between us and GSN isn't huge -- lots superficial, presentation-level changes:
- top-level normative goal (ethical principle)
- property claims (GSN calls subgoals)
- context (same as GSN)
- strategy (same as GSN?)
- evidence (GSN calls solutions)
- no justifications + assumptions (because context kind of covers it)
- we don't have:
- some extensions to GSN:
- HCI PDRA will look into methodological/communicative aspect of GSN, there's an extension
- modularity, another extension of interest
- still want to maintain easy/accessible approach. GSN isn't complicated but it's probably a lot harder for folks who haven't been exposed to it before.
- this is where community matters a lot... Experts in argument-based assurance is NOT who we have.
- we need to do some user mapping here. (could there be an "Advanced option" where users can choose what level they can engage with the platform)
- chose Mermaid to render diagrams
- controlled way of building them
- easy package to implement in React
- causing headaches now
- JSON largely as a way to communicate between Postgres and Mermaid to create structure
- better schema
- YAML-defined schema?

### Steffen
- convo on slightly wrong level
- steer away from JSON/XML/XMI/YAML/whatever else, towards a quick 1-on-1 on languages: what makes a language (a computer language) and relate it back to what I have heard you say about assurance -- gives us terminology to hone in on what you want, need, and what's worth exploring a bit more
- Syntax / semantics
- *syntax*: what can I say in the language?
- maybe syntax should be though of as "Abstract syntax" and "concrete syntax"
- *Abstract syntax*: the set of concepts in the language, doesn't worry about what they look like... Really just what can I say in the language, what concepts can be connected together?
- *Concrete syntax*: How does the user read it, write it?
- *semantics*: what do these symbols mean?
- will always be defined for the abstract syntax (languages are built that way)
- GSN/SACM
- Abstract syntax = SACM (little bit on sematics, but mostly just a metamodel = concepts and relationships between them) -- only concrete syntax in there is XMI (never meant to be used by humans but concrete rendering of the concepts)
- JSON/Postgres = concrete syntax
- Schema is the abstract syntax
- When talking about accessibility: are you talking about abstract or concrete syntax?
- Chris: Both and others. But helpful with shared vocabulary. Upskilling/tutorials bring more people into assurance ecosystem. Reducing core elements. Making engagement more diverse and inclusive. *Also*: FAIR principles. But also having everything public on GitHub, and make sure that shared/created assurance cases are interoperable. *Also*: Broader societal accessibility definitions.
- Question: When we talk about something expressed in a language like this, I tend to call them "models." An assurance case is a model. What's the primary format you store and manipulate those? Derive other presentations? Is this the right format for what you're trying to do with this? Cross-referencing things, most relevant to the primary format, only secondary to other formats.
- Multiple goals -- available in abstract syntax. OMG would call it metamodel. Set of classes with references between them. (Typescript is good to think about)
- What's the primary format here? Editor reminds me of a "projectional approach" = user edits directly an instance of the abstract syntax, and gets rendered a representation of the concrete syntax.
- C: reason for projectional approach - we didn't want the user to have to know all the relationships required etc. Rather than have a pop-up, we wanted to have a dynamic representation in the interface, where they only have the ability to create a. Textual-based approach might be good for users who KNOW what they are.
- S: One tool that might be interesting to look at / look at videos around is [JetBrain's MPS](https://www.jetbrains.com/mps/). Archetypical projectional editing tool. Any graphical editors are by definition projectional. Another tool called Gentlemen, takes these things and puts them on the web. Freeon, developed in the Netherlands. JavaScript library for diagrams called [BlueFish](https://bluefish.openoffice.nl/index.html). The GLSB also.
- S: You can say: I will provide concurrent projections. You can have different concrete syntaxes of the same abstract syntax, where one user just does the diagram. Because the ABSTRACT SYNTAX IS THE IMPORTANT THING, the graph syntax is defined there, and you make sure that the connection works there.
- Metadata might become a language construct in this sense.

---


TODO: Connect to Steffen about SACM (Acme tool, research prototype?)

TODO: Metadata (see "metadata" above) story
- TODO: Chris, can you write that all down