A Systems Engineer's Virtual Assistant (SEVA) is a novel attempt to bridge the gap between Natural Language Processing (NLP), Knowledge Base (KB) Construction research, and NASA's Systems Engineering domain. In this work, we propose the design of an explainable, human-in-the-loop, and interactive personal assistant system. The assistant will help a Systems Engineer in their daily work environment through complex information management and high-level questionanswering to augment their problem-solving abilities. We describe the fundamental characteristics of the assistant by understanding operational, functional, and system requirements from Systems Engineers and NASA's Systems Engineering Handbook. The assistant is designed to act as a workbench to manage dynamic information about projects and analyze hypothetical scenarios. It is also designed to make logical inferences and perform temporal reasoning by handling domain information and information related to schedule and resources. In addition, the system learns new information over time by interacting with its user and can perform case-based reasoning from previous experiences. The knowledge base design describes a novel hybrid approach to build a domainindependent common-sense framework with which domainspecific engineers can attune it and build their projects. Using these specific objectives and constraints, the architecture of a personal assistant is proposed. Main contributions of this design paper are Systems Engineering (SE) domain analysis, a survey of existing research, preliminary experiments using the state-of-the-art systems to explore the feasibility, a proposal of a complete architecture with component level detail, and identification of areas that require further research and development.
Intelligent personal assistants have drawn attention in recent years due to their ubiquitous nature of making human lives easier. However, practical use of such personal assistants by individual scientists or engineers, such as those at NASA, is still very limited due to the risk-averse nature of engineering projects, users’ steep learning curves in studying the unnecessary details of a new system, and the assistant’s inability to capture the relevant complexity of the domain. In addition, explainability of answers plays a key role in such AI systems where trust in the answers is paramount. It is a dream for most scientists and engineers to have a personal assistant who takes care of the tedious book-keeping aspects and assists them in creative problem solving. Systems Engineers (SE) deal with large amounts of information in their everyday work. Their role in technical project planning requires handling this information and keeping track of diverse requirements, changing variables, resources, and schedules. This extensive information assimilation is both tedious and error-prone. The ability of SEs could be greatly enhanced by a system that could handle such tasks. SEVA is being developed with this goal in mind: to assist SEs and enhance their problem-solving abilities by keeping track of the large amounts of information of a NASA specific project and using the information to answer queries from the user.
NASA’s state-of-the-art approach to computer-aided
Systems Engineering projects is Model Based Systems
Engineering (MBSE). It is a model-centric approach which
supports all phases of SDLC (System Development Life Cycle)
with which SEs can design their large scale projects. Two
key problems that MBSE tackle are collaboration of
different domains and conversion of documents to digital
models. MBSE also has a similar goal in mind as SEVA: to
facilitate understanding, aid decision-making, examine
hypothetical scenarios, and explain, control, and predict events
On the other end of the learning curve are popular
intelligent assistants such as Siri providing proactive assistance on
a very specific set of contextual tasks such as calling a friend,
sending a message, or making a dinner reservation. These
assistants are not knowledge systems which can assist a user
in complex tasks such as engineering projects or disease
diagnosis. There is little reason for such assistants to
maintain large scale ontologies. For example, the rather small
and active ontology maintained by Siri is sufficient enough
to aid its task-based design
The Cyc project tried to perform human-like reasoning
by building a comprehensive system with common-sense
knowledge such as “water makes things wet”, “plants die
eventually”, etc
The MIT Programmer’s Apprentice Project
SEVA has 3 main categories of questions from which its external interface requirements are based from: 1) Relational, 2) Recall, and 3) Hypothetical. Relational questions determine the existence of links between entities. In ontological terminology, links are verbs/predicates that connect subjects and objects. The answer can be ‘Yes’, ‘No’, or ‘Unknown’. For example, questions such as “Is Neon a noble gas?” or “Can Aerogel capture a Niacin molecule moving at 5km/s?” fall into this category. Recall, the next type, determines what entity another entity is linked to. For example, questions such as “What is the total mass of the spacecraft?” or “When is the vibration test for the flight Main Electronics Box?” fall into this category. Hypothetical questions are “what-if” scenarios. For example, questions such as “What will be the mass of Instrument X if component C is removed?”.
Apart from direct recall of information and storage, four major capabilities of this virtual assistant are defined based on the various scenarios encountered by an SE: A) perform reasoning tasks, B) handle temporal (time-related) information, C) answer hypothetical (what-if) questions, and D) learn from “experience”.
An ontology describes concepts, properties, and
relationships in formal languages such as first-order logic,
description logic, or horn clauses. Using reasoning skills on its
ontology, SEVA will be able to create new, indirect, or derived
information that are dependent on the existing knowledge.
Primary form of reasoning is related to the idea of
taxonomic or is-a relationship between two concepts
SEVA handles three categories of time: 1) time-tagging information, 2) processing time-related information, and 3) knowledge of tense. Every information in the assistant’s knowledge base has to be time-tagged. This helps the assistant in answering questions such as “What was the mass of the nephelometer instrument three days ago?” or “When was the test schedule changed for the second stage cryocooler?”. The primary objective of time-tagging is to help the engineer to temporarily track the change log history of all elements of a project or task. Alternatively, processing time-related information simply means to understand temporal information in a sentence such as 06:23:43 for time, 07/11/2018 for date, and to understand intervals of time such as ‘three hours ago’ or ‘due in 5 hours’. Understanding tense is an obvious capability necessary to perform the above two tasks, which means to know grammatical terms such as is, was, ago, had, initial, etc.
In hypothetical mode, an SE can ask ‘what if’ questions. By entering the hypothetical mode, the user can temporarily modify the information in the knowledge base. ‘Whatif’ questions such as “What is the Technology Readiness Level(TRL) of instrument X, if it has been to space?” are a combination of two tasks: 1) perform temporary updates on the knowledge base and 2) ask questions as usual. In the example, the knowledge base will be temporarily updated with a new information: fInstrument X has been to spaceg. The SE then asks the question fWhat is the TRL of instrument X?g After exiting this mode, the knowledge base will be restored to its original form without the temporary updates. Hypothetical mode helps the SE in decision-making, design support, and in analyzing various scenarios or hypothetical models.
Two reasons for unsuccessful querying are 1) the entities or concepts in the question are unknown to SEVA and 2) entities are known but there is not enough information to answer the question. In the first case, SEVA asks the SE a series of questions to better understand the original question and to fill the knowledge base with necessary information to answer the question. For example, when the SE asks “What is the mass of Neon?” and SEVA’s knowledge base has no information about ‘Neon’, it will respond by inquiring “What is Neon?”. The second case is a logical problem that applies to relational questions where the ontology is missing the predicate link. Assume that the entities ‘mass’ and ‘neon’ are in SEVA’s knowledge base. Suppose the SE asks “What is the mass of instrument X?” SEVA understands every entity in the question but has no link connecting them. There are two ways to provide the unknown information: 1) help the system to derive the answer by creating a logical case through interaction (eg: “mass of an instrument is the sum of its components”) or 2) provide the answer directly (eg: “mass of instrument X is 5kg”). This type of user-assistant interaction constitutes an ‘Experience’ and can be used if similar cases appear in future question-answering sessions. A key aspect of SEVA’s architecture is that an ‘Experience’ is context-driven; it is a function of questions, statements, and rules or logic from the user. The type of learning we aim to provide SEVA with is case-based contextual awareness.
SEVA takes input from various sources including operations manuals and projects. In this work, we restrict to Natural Language text as input. Other types of inputs are left as future work. There are 4 types of interaction types in SEVA: 1) information given to the assistant that undergoes natural language processing and subsequently added to its knowledge base, 2) basic user commands to enter and exit hypothetical mode, undo an operation, etc., 3) a successful query where the assistant responds with an answer, and 4) an unsuccessful query (due to unknown concepts) which is tackled by using interactive dialogues and case-based reasoning from experience.
Creating a Common-Sense AI is an important and
challenging task in AI research today. Several research have
explored this topic, inspiring ones being projects such as
Mosaic Common Sense Knowledge Graphs and Reasoning
Based on the defined operations concept, primary functional requirements are derived - ability to 1) Ingest information as text, 2) Store information in an ontology, 3) Perform reasoning on the ontology, 4) Respond to interactive queries, 5) Enter hypothetical mode, 6) Understand time and schedule, 7) Manage a Dynamic Ontology, 8) Save specific interactions as ‘Experience’, 9) Connect knowledge base with endowed models outside the system.
Requirements 1-8 will be described along with experiments in the upcoming sections. 9 is outside the scope of this paper, and for this purpose, we define three generic components: 1) Monitor, 2) Logicker, and 3) Inter-Module Communication Protocol. ‘Monitor’ encompasses methodologies that can oversee, monitor, and assist in debugging the rest of the architecture. It acts as the central link between the system and the endowed models located outside. Architectural components for SEVA are depicted in Figure 2.
Inter-module Communication Protocol (ICP) in Figure 2 depicts the underlying API (Application Program Interface), the methodology by which each module will communicate with one another. For example, it addresses the type and the format in which the NLP module should produce output in order to pass it to the ontology module.
The endowed models represent knowledge that are not innate to SEVA. The design does not aim to include all possible knowledge but rather to have the ability to access any outside knowledge when needed. Monitor encompasses a special component called ‘Logicker’ that makes this knowledge transfer possible. This means that SEVA may not know how to solve ‘orbital mechanics’ or ‘flight dynamics’ problems until 1) an experience occurs, 2) the user teaches it or 3) it endows the knowledge base with an orbital mechanics or flight dynamics module through Logicker. It is key to separate such functionalities from essential capabilities such as elementary math functions (arithmetic, logic, or relational operations) which will be included in SEVA’s fundamental capability.
The architecture based on the aforementioned functional requirements is shown in Figure 1. Individual components and experiments will be described in the following sections.
NATURAL LANGUAGE PROCESSING (NLP Module) The NLP module converts raw text into information that can be represented in the form of an ontology. The NLP functions are divided into 4 tasks: 1) analyze the linguistic structure of the domain, 2) extract entities and relations, 3) extract contextual rules, and 4) interact with the ontology to perform entity linking and verb normalization.
Triple extraction or relation extraction is a well known
AI technique to populate knowledge bases. In recent years,
Open Information Extraction (Open IE) has received
significant attention as compared to traditional IE systems due
to the ability to extract domain independent triples on a
large scale. In addition, extractions are learned by using
hand-crafted rules or automatically created training data
without using any annotated treebanks. Extractors such as
AI2 Open IE or Open IE 4.x
Question-Answer Types: QA pairs are collected from domain experts to understand the type of questions and answers that matter for individual systems engineers throughout a mission’s life cycle. For an elementary knowledge represented as a [subject-predicate-object] triple, we categorize questions as follows: 1. [S-P-?]: [subject-predicate-?] questions that are looking for objects in sentences. Example: ‘What is the mass of STI?’ 2. [S-?-O]: [subject-?-object] questions that have Yes/No answers showing whether there exists the given predicate link between the subject and the object. Example: ‘Is STI an instrument?’ Refer to Table 2 to see sample SE questions about SEVA Testing Instrument (STI).
Assumptions on Grammatical Constructs: We assume that the SE text is free of grammatical errors and that engineers converse with the system in grammatically correct STI, an instrument, has a 2500 pixel CCD detector STI is an instrument with a TRL value of 5 STI is scheduled for acoustic testing on July 3, 2015 from 2:00PM to 6:00PM.
Stanford Open IE (“STI” “has” “2500 pixel CCD detector”) incomplete/ missing information: “STI is an instrument” (“STI” “is” “instrument”) (“STI” “is instrument with” “TRL value of 5”) (“instrument” “is with” “TRL value of 5”) (“STI” “is instrument with” “TRL value”) produced 13 triples (“STI” “is” “scheduled”) (“STI” “is scheduled for” X) X = various combinations of remaining sentence
ClausIE
(“STI” “is” “an
instrument”)
(“STI” “has” “a 2500
pixel CCD detector”)
(“STI” “is” “an
instrument with a TRL value of
5”)
(“STI” “is” “an
instrument”)
(“STI” “is scheduled”
“for acoustic testing on
July 3 2015 from 2:00
PM”)
AI2 Open IE (STI; has; a 2500 pixel CCD detector) (STI; [is]; an instrument) (STI; has; CCD detector) (STI; is-a; instrument) (CCD detector; property; 2500 pixel) has(STI; is; an instrument with a TRL value of 5) (STI; is an instrument with; a TRL value) (STI; is; instrument) (instrument; has-property; TRL value) (TRL value; has-value; 5) (STI; is scheduled; for acoustic testing) incomplete/ missing information: “on July 3, 2015 from 2:00PM to 6:00PM” (STI; is; scheduled) (scheduled; for; testing) (testing; has-property; acoustic) (testing; has-value; 3 2015 July) (scheduled; from; 2:00 PM) (scheduled; to; 6:00 PM)] English. We analyze the grammatical constructs of SE text from the handbook (2017) and domain expert. We expect that engineering manuals, in general, are less likely to use pronouns such as I, YOU, HE, SHE, WE, YOU, WHO, and their object pronouns. However, pronouns such as IT, ITS, THERE, THAT, THEY, THESE, THOSE, ONE, ONES, ITSELF, WHAT, and WHICH are prevalent. Coreference resolution, associating these pronouns to its subject/object, is an essential task of the NLP module. However, we do not address this task in the evaluation and is left as future work. In a sentence, we focus on nouns, verbs, adjectives, and adverbials to study the phrase structure of the SE text. Our evaluation consists of only simple independent sentences in SE domain.
SEVA Targeted Open Information Extractor (TOIE) extracts simple essential relations from SE Text. A Systems Engineer was tasked with constructing a set of project specific sentences. The context in which these sentences are produced are instrument descriptions and instrument development meetings. Compound sentences are broken down and complex sentences are excluded. Our data set includes only independent sentences that do not require co-reference resolution. A snippet is shown in Table 3.
STI is SEVA Test Instrument. STI, an instrument, has a 2500 pixel CCD detector. STI has a length of 200 cm. STI is an instrument with a TRL value of 5. The spacecraft shall provide a direct Earth entry capability for 11500 m/s. The system shall have a 1.4 factor of safety. STI is scheduled for acoustic testing on July 3, 2015 from 2:00PM to 6:00PM.
The relations extracted are of type: fis a, transitive
verb, has property, has valueg. This is implemented
by pattern matching on the dependency tree produced by
the Stanford dependency parser, phrase chunking, and
occasionally splitting at prepositions. Apart from subjects
(nsubj) and objects (dobj), the algorithm primarily focuses
on a subset of universal dependencies: case, nmod,
compound, amod
Basic dependencies produced by Stanford CoreNLP
Results & Research Challenge: Although powerful for large scale extractions, Table 1 shows that the extractions produced by the state-of-the-art systems can be noisy, incomplete, and need to be granularized in order to be put to practical knowledge base construction. Stanford Open IE uses distant supervision to train a classifier that generate clauses and uses hand-crafted patterns to produce triples. The extractor performed well at breaking down triples but sometimes produced triples in large quantities including noisy and incomplete ones. ClausIE uses hand-crafted rules for both clause generation and clause-type detection. The extractor often produced correct results. However, minimality of triples was the biggest concern. Open IE 4.x uses bootstrapping approach and training data to learn patterns. This system maintained a good balance between the number of extractions, minimality, correctness, and completeness. The task identified for future research is to extract high accuracy targeted triples on a large scale that are granular enough to be used to populate a knowledge base using the SE in the loop. This will make use the existing systems in addition to SEVA’s internal extraction methodology.
Open IE can be customized to the SE domain by
identifying the linguistic structure of the domain language which
can be accompanied by tasks such as parts-of-speech
tagging and semantic role labeling. A sentence represented
using a constituency parser, such as
We define three types of input informantion that is represented by SEVA’s knowledge base: 1. Project Specific Knowledge, 2. Common-Sense knowledge, and 3. Relational knowledge. Project specific knowledge comes from the engineer, meetings, and project documents. CommonSense knowledge comes from the SE Handbook and other trusted sources. Relational knowledge consists of relational phrases, verbs, and their axiomatic relationships. This is closely connected to the ABox, TBox, and RBox knowledge population which will be described in the ontology section. Various sources of knowledge in SEVA are shown Figure 4.
For successful ontological reasoning, the relations and the
axioms in the ontology need to be well defined. For
example, automatically constructing axiomatic relationships
such as inverse-of (eg: partOf hasComponent )
requires semantic understanding of words and phrases.
Currently, these axiomatic relationships are constructed
manually in the ontology. In this context, our future work will
focus on using WordNet
Extracting rules in desirable forms such as horn clauses
or description logic from text or triples is another
essential NLP task for Ontological reasoning. Currently, rules
are added manually using Semantic Web Rule Language
(SWRL)
Assertion Box (ABox) Terminology Box (TBox) Spacecraft(DiscoveryShuttle) Conduit Pipe implies that “Discovery Shuttle is an implies “same-as” relationship instance of Spacecraft” MassSpectrometer v Spectrometer partOf(StarTracker, DiscoveryShut- implies “sub-class” relationship tle)) implies that “StarTracker is a part of Discovery Shuttle”
Relational Box (RBox) partOf partOf v partOf represents transitive property of the role partOf hasComponent represents inverse property of two roles
SEVA gives special consideration for time entities as they
are significant in scheduling and maintaining a dynamic
knowledge base with temporal reasoning. The result of
passing the sentences “STI is scheduled for acoustic testing on
July 3, 2015 from 2:00PM to 6:00PM. The instrument is
scheduled for vibration testing on July 3, 2015 at 4:30PM
for 3 hours.” to the off-the-shelf 7-class Stanford Named
Entity Tagger
KNOWLEDGE BASE (ONTOLOGY Module) With the help of the NLP module, the ontology module links the subjects and objects identified to the concepts and instances already present in the ontology. Relations are created by normalizing the verbs to its root form. For our baseline, we choose a Semantic Web based approach to building SEVA’s ontology. This provides extensibility and access to vast knowledge of information. Usage of resources such as DBpedia will be replaced with a SE specific common-sense ontology in the future.
Semantic Web and Web Ontology Language
(OWL)
The idea of semantic web framework is to establish a
common representation of data on the web that can be used
universally. SEVA uses OWL 2’s built-in set of specifications
called Resource Description Framework (RDF)
Knowledge created in the ABox is instantiations of concepts in the TBox or relations between already constructed instances. This is typically received from project specific documents. On the other hand, TBox consists of concepts and their relationships. This knowledge is received from both project specific documents as well as guidelines, SE Handbook, and common-sense knowledge. RBox focuses on axiomatic relationships between relations and is responsible for ontological reasoning along with is-a relationships. This information cannot be found in documents and need to be constructed automatically or manually. This verboriented knowledge is considered common-sense knowledge which is constructed specifically for the SE domain.
Next, we describe a representation example that shows the complexity of our knowledge base construction and population process. Consider a seemingly simple example “STI has high angular resolution”. SEVA-TOIE produces two triples [(‘STI’, ‘has’, ‘angular resolution’), (‘angular resolution’, ‘has-property’, ‘high’)].
Knowledge Base Construction: This phase gives context
by constructing the TBox concepts and relations, and
necessary instantiations in the ABox. This needs to be performed
prior to passing the aforementioned example sentence. The
knowledge “STI is an instrument” or Instrument(STI) must
pre-exist along with the concept of “angular resolution”
such that the entities can be linked.
Knowledge Base Population: This phase populates the
ABox. When there are only predefined named entities and
relations in the TBox, this step can be generally replaced
by the methodologies of Named Entity Recognition
customizing to the domain and Relation Extraction from
templates and by training a model
SEVA’s ontology is divided into Base ontology and Custom ontology. Custom ontology consists of domain specific concepts and instantiations, mostly the TBox and ABox axioms. Instrument(STI) and partOf(MassSpectrometerMS81Z,STI) fall in to custom ontology. Population of a custom ontology is easily performed as long as a solid base ontology is available. This means that if a framework of concepts and relations is available, their instances and relations can be added without any ambiguity. Base ontology contains the essential ingredients or building blocks for a common-sense ontology upon which a SE can build their customized ontology. It consists of basic axioms and rules that govern the ontology. It predominantly describes relationships and properties of predicates or RBox axioms such as partOf partOf v partOf representing transitive property or partOf hasComponent describing inverse relationship. It also contains the TBox and ABox information that are common-sense knowledge such as SE guidelines, synonyms, and abbreviations. Example: Conduit Tube and isAbbreviationFor(SLS, SpaceLaunchSystem).
Research Challenge identified for this step is to automatically construct the base ontology. A challenging aspect of this step, in order to have an explainable system, is to define what constitutes the input for the base ontology. Using the massive information available on the web is neither a scalable nor a trustable solution. Using the NASA SE Handbooks is a good first step. However, common-sense science and math knowledge is assumed which needs to be learned as a prerequisite. Essentially, we need to scale and define what common-sense knowledge is for the SE domain and identify the sources such that the knowledge is complete and scoped for a personal assistant’s knowledge base.
SEs deals with constantly changing information including
project specifications, time, events, and schedule. New
information will need to be added and old information will need
to be updated. Ontology consistency needs to be checked
on each update. Multiple versions of the ontology need to be
maintained in order to perform temporal reasoning,
scheduling, and undo operation. SEVA is designed as a dynamic
work bench for the SE. Guidelines for a dynamic ontology
is presented in works such as
Recent developments in Knowledge Graph
Identification research by jointly performing Entity Resolution, Node
Labelling, and Link Prediction while enforcing
ontological constraints in works such as
The primary function of this module is to perform
inference on the ontology. TBox inferences include subsumption,
consistency, satisfiability, equivalence, and disjoint
checking. Whereas ABox inferences include instance checking
and retrieval
The choices can be evaluated only after the dynamic nature of the knowledge base is addressed. For the baseline implementation in OWL and Protege, we use off-the-shelf Pellet reasoner.
Open/Close World Assumption & Explainability
If something is not known to be true, an open-world
assumption (OWA) assumes incomplete information, and thus the
assistant responds with “I don’t know” as the answer, while
a closed-world assumption (CWA) assumes complete
information, thus the assistant responding with “false” as the
answer. Formal definitions of these two assumptions can be
found in
For every NASA Engineer who deals with mission critical information, their personal assistant needs to be highly trustable in its information assimilation task. Completeness of the knowledge base and the type of assumptions mentioned above play an important role in explaining how the assistant came to an answer. Probability of any answer should be ideally one and the system should be able to show the reasoning steps by which the answer is obtained.
SEVA adopts the knowledge-based paradigm
Querying on an ontology link which consists of SubjectPredicate-Object can be of two forms: a) asking for the object and b) asking for the predicate. Possible responses with an Open World assumption can be a) an answer which is contextually correct according to SEVA, b) a logical conversation with the user to understand the missing link or predicate, or c) an interaction or instructions to the user to teach SEVA about a missing concept.
Capturing Experience is a process by which the assistant is taught logically how to arrive at the conclusion or can be viewed as an algorithm being taught to the assistant for case-based reasoning. It can use an existing algorithm to solve a similarly appearing problem with the guidance of the SE. The following scenario represents the “Unknown due to OWA” answer type where SEVA linguistically understands the question being asked, however does not poses enough information to answer it. It then interacts with the user to learn logic. The conversation between the user and SEVA shows an example of how an experience is captured into a case. User: Can Aerogel capture a Niacin molecule moving at 3km=s? SEVA: “I don’t know” User: Start a rule.
SEVA: Enter the necessary conditions.
User: Depth of Aerogel times density of Aerogel divided by density of niacin molecule should be greater than 8mm. Speed of niacin molecule should be less than 5km=s. SEVA: Rule Saved! No, Aerogel cannot capture a niacin molecule moving at 3km=s.
Through such an interactive session, SEVA lets user
create custom rules. Creating contextual awareness is done
through identifying structure of queries and applying
casebased reasoning such as in
CONCLUSION AND FUTURE WORK This work introduced SEVA - a vision of a Systems Engineer’s personal assistant. It described SEVA’s architectural design - the big picture, motivation, and its technical plausibility. SEVA is a single-user system designed to assist SEs in their day-to-day activities. The work designed the architecture for a framework with specific goals and constraints within the context of a NASA SE who deals with risk-averse complex engineering projects. SEVA makes it easier for the SE to focus on the creative problem solving by taking care of all the tedious book-keeping and potentially error-prone information assimilation. SEVA is a trustable and explainable system with a domain independent SE framework that grows by human-in-the-loop learning and becomes user-specific or domain-specific over time. The work discussed how SEVA performs natural language processing, information management, reasoning, learning, and question-answering. We described what SEVA is and what it is not, as well as the tools with which such an implementation is feasible and the areas that require further research and development.
We designed the overall architecture and implemented a baseline Open Information Extractor and a Knowledge Base Module for SEVA. Several sub-components are provided with high-level descriptions including the research challenges and implementation directions. Detailed implementation and technical evaluation of these modules are currently in progress and are left as future work.
Although SEVA is designed for a SE, the idea is extensible to all domains where personal assistants (ones which can grow alongside the user) are needed. Thus, extending the idea to other domains is a future direction. Interconnectedness of different domains and different engineers add complexity to any project. We envision multiple SEVAs each belonging to a specific engineer filling the gap of information assimilation and distributed coordination. Application of assistants in such collaborative settings is another area of future work.