# Software Architecture for ML-based Systems: What Exists and What Lies Ahead

Henry Muccini  University of L’Aquila
L’Aquila, Italy
<EMAIL_ADDRESS>Karthik Vaidhyanathan  Gran Sasso Science Institute &
University of L’Aquila
L’Aquila, Italy
<EMAIL_ADDRESS>
###### Abstract

The increasing usage of machine learning (ML) coupled with the software
architectural challenges of the modern era has resulted in two broad research
areas: i) software architecture for ML-based systems, which focuses on
developing architectural techniques for better developing ML-based software
systems, and ii) ML for software architectures, which focuses on developing ML
techniques to better architect traditional software systems. In this work, we
focus on the former side of the spectrum with a goal to highlight the
different architecting practices that exist in the current scenario for
architecting ML-based software systems. We identify four key areas of software
architecture that need the attention of both the ML and software practitioners
to better define a standard set of practices for architecting ML-based
software systems. We base these areas in light of our experience in
architecting an ML-based software system for solving queuing challenges in one
of the largest museums in Italy.

###### Index Terms:

Software Architecture, Machine Learning, Artificial Intelligence, Architecture
Framework, Architecting Process, Self-adaptive Architecting, Architecture
Evolution

##  I Introduction

Modern software systems generate a tremendous amount of data. In fact, we live
in a data-driven world powered by software where we have an abundance of data
generated by different sources like web applications, smartphones, sensors,
etc [1, 2]. A recent article from Forbes quotes that about 2.5 quintillion
bytes of data are created every day. This number is expected to increase
drastically in the years to come [3]. Over the years, with the advancements in
computing infrastructure, these data have been fueled by Artificial
Intelligence (AI), in particular, Machine Learning (ML), to generate
actionable insights [4]. It has further paved the way for developing software
systems and services that power autonomous vehicles, recommendations in
Netflix, search results in Google, etc. As remarked by Andrew Ng, AI is
considered the new electricity and is expected to transform the world just
like electricity did about 100 years ago [5]. Moreover, as per Gartner, around
40% of the world’s organizations are expected to leverage AI in the coming
years [6].

However, the increasing adoption of AI, particularly ML, has given rise to
different challenges associated with development practices, deployments,
ensuring data quality, etc., in addition to the challenges of a traditional
software system. These challenges call for better architecting practices for
addressing the concerns of ML-based software systems [7, 8]. On the one hand,
we have software systems that generate a tremendous amount of data but face
different architectural challenges. Some of those challenges can be solved
using ML [9, 10], and on the other hand, we have ML-based systems that thrive
on data but require better architecting practices. This combination of
challenges in the field of software architecture and ML has resulted in two
broad research areas: i) Software architecture for ML systems. It primarily
focuses on developing architectural techniques for better developing ML
systems; ii) ML for Software architectures, which focuses on developing ML
techniques to better architect software systems. In this work, we focus on the
former side of the spectrum, intending to provide an overview of the different
architecting practices prevalent in the current scenario when building ML-
based software systems. We focus on four key areas of software architecture
and highlight what lies ahead in each of those areas. We base our discussions
in the light of our experience in building an ML-based software system for
solving queuing issues in one of the largest museums in Italy. We believe the
discussions put forward in this work simulate more extensive discussion among
the ML and software architecture research/practitioner community members to
better define practices for architecting ML-based software systems.

##  II Software Architecture and Machine Learning

Ever since Perry and Wolf [11] came up with the seminal work on software
architecture, the field has evolved continuously to cope with the different
computing trends. The role of software architect has also evolved over the
years based on the various advancements in domains (automotive, robotics, IoT,
etc.), the practices/methodologies (waterfall, RUP, Agile, etc.), and type of
applications (monolithic, SOA, microservices, etc.). On the other hand, the
field of machine learning has advanced rapidly with the availability of a
larger amount of data, better computing infrastructure supplemented by the
increasing number of domain experts. This revolution has spanned across the
different software domains, and as the years progress, software systems, by
leveraging ML, are moving from the notion of being another software to more
intelligent software systems. This implies we need architecting practices that
allow modern software architects to handle the nuances of two different
continuously changing worlds. On one side, it is about how to architect a
software system that satisfies all the functional and non-functional
requirements. On the other side, it is about how to handle the different
challenges associated with machine learning. However, even though they co-
exist in one software in the current world, there is a clear division in terms
of the process, stakeholders, concerns, and so on.

Figure 1 shows the high-level view of an ML-based software system and how a
modern software architect perceives such a system. Even though it is one
system, they exist as two big subsystems where on one side (machine learning
subsystem), it is more about data, algorithms, and models. In contrast, on the
other side (software subsystem), it is about components, connectors, and the
interaction between them. The software subsystem makes use of the machine
learning models and continuously produces the data required for the machine
learning subsystem. Further, for each of the subsystems, there are different
stakeholders and their respective concerns. It is then the role of the modern
software architect to coordinate between the two different subsystems with
totally different characteristics, properties, and team dynamics. This
process, however, raises a lot of questions on the different aspects of
architecting, ranging from how the architecting practice can be standardized
to how this setup has resulted in different barriers in the process of
software architecting. In the remainder of the paper, we describe the existing
practices in architecting ML-based software systems and, we further elicit
what lies ahead for the community to develop better approaches to architect
ML-based software systems. Based on the discussions made, we also provide some
pointers on how the role of a future software architect may look like.

Figure 1: High-level view of an ML-based Software System

##  III Architecting ML-based Software Systems: The Case of Uffizi Gallery

The Uffizi Gallery in Florence is one of the most visited museums in Italy. In
2018, it counted more than 2 million visitors. Other than for its priceless
masterpieces from Botticelli, Michelangelo, Raffaelo, Leonardo, and many more,
Uffizi is also known for potentially long waiting queues. The reasons are
manifold: i) as reported by the 2016 ISTAT Report on Tourism [12], 20 museums
over a total of 4,976 in Italy, attract one-third of all visitors (Uffizi
being one of those); ii) Uffizi has a limited capacity that, in some periods
of the year, is much smaller than the number of visitors arriving at any time;
iii) the museum does not bound the time required for a visit, and therefore
tourists may stay as long as they want.

Based on a joint project between the Uffizi Gallery and the University of
L’Aquila, started in 2016, our team was made responsible for solving the queue
problem in Uffizi.

Visitors’ flow management in famous and large museums involves different
stakeholders. In the Uffizi case, we had to collect information from the
Director of the Uffizi Gallery, from the Concessionaire responsible for the
ticketing and welcome services, from the external Tour Operators and, finally,
from visitors themselves. We realized that many reasons could cause queues in
the Gallery. Among the most relevant are the following: A large number of
tourists come for just one day visit to Florence and the Uffizi Gallery. These
numbers are very high in peak season and on certain days of the week. However,
the museum has a limited capacity and cannot accommodate more than a fixed
number of people at the same time. As soon as this number is reached, no one
can enter the museum until someone leaves. When the museum gets crowded and
the number of people wishing to enter outnumbers the people leaving, the
waiting queue starts to grow. Two factors may exacerbate this phenomenon: i)
the tourists visit is not time-bounded (therefore, if they decide to stay
longer, the waiting queue tends to increase), ii) there exist two separate
queues: one priority line for visitors with a reservation, and a low priority
queue for those without a reservation. When the priority line grows, the
unbooked one may go into starvation. We considered all these different
factors, along with external factors like weather, nature of the season, etc.,
to come up with an ML-based ticketing software system that was able to reduce
the waiting time from hours to minutes [13].

We followed a typical data-driven process to realize the solution. The overall
solution was a system that used IoT (with standard data pipeline architecture
for data ingestion, monitoring, and storage), machine learning, statistical
optimization, and data analytics. Such a solution was accomplished with the
help of a team comprising of members of varying skills, including software
developers, statisticians, machine learning experts, hardware engineers, and
IoT experts.

While our experience is specific to smart tourism and the Uffizi Gallery, we
believe that the same can be generalized to any ML-based software system. It
also represents the needed intertwine between data acquisition with ambient
intelligence, IoT, predictive and prescriptive models, and front-end
solutions. The applied process is highly iterative and incremental, with new
questions arising from time to time and new solutions being proposed
incrementally. During the process, there were different challenges involved in
architecting the overall solution. The main reason was that there were no
standard practices to be followed to architect this kind of system where the
dynamics are entirely different from a traditional software system. In the
following sections, we base our discussion on the lessons learned, and the
experience gathered while architecting the overall system.

##  IV Software Architecture For ML-based Systems: What we miss?

This section discusses four key areas that require the attention of both the
research and practitioner community to standardize the architecting practices
for ML-based software systems. We provide details on what exists in these
different areas and what we believe needs to be done in the future. These
areas have been derived based on our expertise in the field of software
architecture and the experience in architecting ML-based software system for
queue management in the Uffizi gallery (refer Section III).

###  IV-A Architecture Framework

An architecture framework (AF) is a coordinated set of viewpoints,
conventions, principles, and practices for architecture description within a
specific domain of application or community of stakeholders [14]. They are
knowledge structures that enable software architects to organize the
architecture description into complementary views based on the application
domain.

What exists: Different architectural frameworks have evolved from the time the
foundations of software architecture were laid by Perry and Wolf [11]. These
include but not limited to: Zachman Framework by Zachman [15], 4+1 views by
Kruchten [16], RM-ODP Framework by Raymond [17], etc. They allow expressing
the system’s architecture through different viewpoints by considering the
different stakeholders and their concerns. However, as pointed out by Eoin
Woods [18], these do not provide support for data or algorithms, which are
fundamental building blocks of ML-based systems as most of the time, the
availability of data determines the choice of the ML technique to be used.
Further, they also do not take into consideration the different stakeholders
and concerns that arise with ML-based software system (as depicted in Figure
1).

What lies ahead: As shown in Figure 1, the domain of ML, in general, brings in
many new stakeholders and concerns which cannot be generalized to the standard
software architecture practices. These cannot be captured using the existing
architectural frameworks and requires the development of novel architectural
framework(s) that shall consider the following:

1\. Stakeholders: The key stakeholders of a traditional software system
consists of mainly software developers, testers, database admin, etc.
(stakeholders of software subsystem in Figure 1). However, unlike traditional
software systems, key stakeholders are mostly from a mathematical/statistical
background in an ML-based software system. These include but are not limited
to Data Scientists, ML Developers, Ethics experts, Data Engineers, etc.
(stakeholders of machine learning subsystem in Figure 1). Further, they can
also include members from the operations team as well as software developers
who develop components that consume the ML models.

2\. Concerns: Each stakeholder may have one or more concerns that the system
needs to address/satisfy. While the concerns of stakeholders of a traditional
software system deal with choice of technologies, testing, fault tolerance,
availability, security, etc., ML-based software system with an additional set
of stakeholders brings in different concerns. These include data quality,
ethics, data privacy, fairness, trustworthiness, ML models’ performance, etc.

3\. Viewpoints: An architectural viewpoint is a collection of patterns,
templates, and conventions for creating a view [14]. Such a view can be used
to represent the concerns of one or more stakeholders of the system. In an ML-
based software system, many involved stakeholders with varying skill sets
require the architect to use multiple viewpoints to capture the different
concerns. For instance, it might be required to create a learning viewpoint to
support the construction of a view to represent the machine learning flow,
machine learning components, etc. This view can then capture the concerns of
the different stakeholders like ML developers, data scientists, ethics
experts, etc. Further, a data viewpoint might be required to build a view to
represent the data components, model the data pipeline, etc., that capture the
concerns of stakeholders like data engineers, data scientists, etc.

These different stakeholders, concerns, and viewpoints in ML-based software
systems give rise to three key potential open research areas that require the
attention of members from both the software architecture as well as the ML
community.

i) How to define an AF for machine learning systems? Such a framework can
provide means to establish a common architecting standard that needs to be
followed while architecting ML-based software systems or any intelligent
systems in general.

ii) The software system will itself be developed following an AF based on the
application domain. Since the software system itself may obey its AF, we
expect that the ML-based software system will comprise the interaction between
multiple AFs. This opens up a new research area which should focus on how
correspondences rule(s) can be established between the AFs used for
architecting the ML subsystem and the one used for architecting the software
subsystem.

iii) It would also be interesting to study and define if, especially in legacy
software systems where machine learning needs to be incorporated a posteriori,
is it then enough to just have multiple viewpoints to define the machine
learning system and then establish correspondence rules with the already
existing viewpoints of the system?

Experience: As explained in Section III, a team composed of experts in
Software Engineering, Operational Research, Statistics, and IoT had to work on
the UFFIZI project. The performance was a primary concern we had to handle
carefully since the system released up to 850 tickets in a time frame of just
15 minutes. Security was another concern since the denial of service could
essentially block the release of the tickets while having the museum only
partially crowded. Ethics was also a concern due to the (potential) need to
use personal info, such as fingerprint, face model, etc., to minimize
secondary ticketing. While we had a framework, CAPS[19], to model the software
architecture, IoT, and digital space dimensions, we did not have a viewpoint
for the ML concern.

###  IV-B Architecting Process

An architecting process deals with the different activities and tasks involved
in the production of architectural solutions for software systems.

What exists: There have been works that report on the interplay between
software engineering and machine learning workflow, such as the one presented
by Amershi et al. [20]. The work also discusses in detail how these interplay
in workflow results in a constant back and forth communication between
software development and machine learning teams. This process requires the
software development teams to be upskilled with more in-depth knowledge of ML
to enable smoother interaction between such teams. Further, the impact of
using machine learning on different software development practices starting
from requirements gathering to testing and maintenance was discussed by
Zhiyuan et al. [8] while a taxonomy of software engineering challenges for
machine learning systems was discussed by Lwakatare et al. [21]. However,
these work focus on the engineering aspects and are not specialized in
architectural artifacts and solutions.

Zhiyuan et al. state that ML development is an incrementally iterative process
[8] where many times the development starts with performing experiments to
understand what algorithm/technique suits the best to satisfy a particular
requirement. This may imply modifying the architecture of the system to meet
the needs of the algorithm/technique (e.g., through better mechanisms to
collect data or additional components for pre-processing). This type of
development would also mean that there is a constant back and forth
interaction between software architects and stakeholders of the ML components
(who speak more of a mathematical language) as well as between the software
architects and the stakeholders of the software system (who speak a
programmatic language). The nature of two different development methodologies
and two different teams with totally different backgrounds can impact the
various stages of the architecting process111The different process are based
on the different stages prescribed by the International Federation of
Information Processing Working Group 2.10:

1\. Architecture Design: In an ML-based software system, due to the existence
of two different subsystems (as depicted in Figure 1), the first potential
area that needs to be investigated is understanding what drives the
architectural design of an ML-based software system. Is it the concerns of the
ML subsystem or the concerns of the software subsystem? It is more like an egg
or chicken problem. One possible way to handle this is that the software
architect starts from a more significant design concern, breaks it down into
sub concerns, and then maps them into design decisions within each subsystem.
The second broad area is how to manage trade-offs between cross-cutting design
decisions that span across both subsystems. This is because on one side, in
the ML subsystem, design decisions will be more driven by data and algorithm
requirements, whereas, on the other side, it will be more based on the
software functional and non-functional requirements. So how to balance trade-
offs in scenarios where achieving non-functional requirements requires the
degradation of ML performance or vice versa.

2\. Architecture Analysis: One of the vital steps in the process of
architecting after the design is to analyze the architecture. Such an analysis
is accomplished in a traditional software system by generating informal,
formal, or mathematical models with queuing networks, quantitative
verification, etc. [22, 23]. These are then used to determine if the system
satisfies specific quality attributes. However, in an ML-based software
system, the very nature of the process itself is probabilistic in nature. This
is because the output of an ML algorithm itself is based on a probabilistic
measure. Hence, quantifying the flow on components, performing analysis, and
verifying different functional and non-functional properties in such a system
requires sophisticated mechanisms.

3\. Architecture Realization: Most software development these days follows an
agile methodology. On the contrary, ML development follows an increasingly
iterative process. Moreover, agile follows the principle of user first, where
the development is based on user stories. In contrast, in ML-based software
systems, the development is based on features that may or may not directly
impact the user. Hence the development team might use two different
methodologies for development, which needs to be better managed. The
organizational aspect of such teams also needs to be considered. There might
be people with different expertise, so the need for a central coordinator who
understands both the software and ML world is increasingly becoming important.

4\. Architecture Representation: One of the expected results of any software
architecting process is to generate artifacts that can be shared with the
concerned stakeholders to better communicate the system’s architecture. In a
traditional software system, this is achieved with the help of different types
of UML diagrams or even simple box and lines/arrow diagrams. However, in the
case of ML-based software systems, this may not be possible. The main reason
for this can be attributed to the fact that ML requires a lot of mathematical
understanding, and communicating these to the business stakeholder(s) is often
challenging (as artifacts are often produced models, versioned datasets, etc.)
This brings back to the interplay between the introvert nature of an architect
(with skills on formal reasoning and analysis) and her extrovert nature,
highlighting her role as communicator and negotiator[24].

Establishing a standard set of processes for architecting ML-based systems is
fundamental given the ever-growing usage of ML in production. This implies we
need extensive research to be done to:

i) understand how to better manage and document design decisions which also
considers the data quality, data volume, probabilistic nature of the learning
algorithms, etc., as well as the constraints on software systems.

ii) develop methodologies with tool support that allows architects to analyze
the architecture of ML-based software systems.

iii) establish a set of practices that need to be followed to better organize
the development teams such that the software development team and ML team can
work in a more cohesive environment, thereby leading to smoother functioning
of teams.

iv) develop tools and techniques that can provide rich visualizations of the
data and models generated behind the scenes. This will also enable the
architects to communicate better the effort required in realizing such complex
systems.

Experience: In the Uffizi project, there was a continuum of data selection, ML
model creation, and architecture realization. There was not a systematic
process, but the continuous interleave between ML-based decisions (i.e., which
data to generate, which data to analyze and store, which ML model to use) and
software/hardware-based decisions (i.e., how to collect the data in a
historical place, how to maximize performance, how to maximize precision).
This imposed the linearization of many tasks, thus reducing development speed.
We adverted the need for a more systematic process to clearly and effectively
divide the workload among team members. Moreover, the software engineering
team had to learn the data-scientist language, the ML expert jargon, and vice-
versa.

###  IV-C Self-Adaptive Architecting

Self-adaptative architecture equips the system with the ability to
autonomously adapt the architecture of the system (with minimal human
intervention) to handle the different types of uncertainties, which may lead
to Quality of Service degradation and failure.

What exists: The field of Self-adaptive systems evolved over the years from
the term ”Software Crisis” which was first coined in 1968 at the NATO Software
Engineering Conference [25]. Modern software systems are subjected to various
types of uncertainties due to resource constraints, component failures, etc.
Towards this over the years, self-adaptation continues to emerge as a
potential solution [26] as it enables the architectures to autonomously adapt
to the different uncertainties so as to satisfy the overall goals of the
system. There has been an extensive amount of literature work that has been
done in the area of self-adaptive systems. An elaborate survey on different
approaches to engineer self-adaptive systems was presented by Macías-Escrivá
et al. [27], and Krupitzer et al. [28]. In recent years, there have been
different works done in the self-adaptation literature that makes use of
machine learning techniques to better adapt traditional software systems [29,
30, 31]. There have also been works done on adapting machine learning
techniques to better guarantee robustness [32, 33].

What lies ahead: As depicted in Figure 1, when we build an ML-based software
system, there is a constant interaction between the ML process and the
traditional software components. Even though different techniques for self-
adaptive architecting have been proposed in the literature, ML-based software
systems bring in more challenges as the uncertainties may arise not only from
the software components but also from the ML components. These give rise to
the following areas, which we believe requires more attention from the ML and
software architecture research community as well as the practitioners in the
near future:

1\. Architectural Adaptation by ML: This concerns the use of ML techniques for
enacting architectural adaptations. For instance, the ML algorithms from the
ML subsystem (Figure 1) can be leveraged to predict the uncertainties that the
software subsystem may encounter (e.g., overutilization of CPU, failures,
etc.). Further, it can be used to autonomously select the best strategy to
adapt the architecture. Such strategies might involve changing the structural
composition of the software subsystem, reconfiguring the behavior of the
components, etc. However, incorrect predictions of uncertainties or incorrect
strategy selection can lead to sub-optimal or infeasible adaptations that may
implicitly affect a system’s execution. Moreover, these techniques need to
take into consideration the probabilistic nature of ML processes, which might
itself be the cause of uncertainty.

2\. Architectural Adaptation for ML: In an ML-based software system, the
overall performance (response time, utilization, etc.) of the software is also
impacted by the choice and implementation of the ML algorithm. This is because
the selection of the algorithm decides how complex the final model will be.
For instance, referring back to the ML subsystem in Figure 1, we can make use
of different algorithms to solve the same problem, which of course can offer
different accuracy measures and produce different kind of computationally
intensive models. A complex deep learning algorithm might produce a heavier
and highly accurate model (e.g., a model with more neural network layers). But
since the model is dense with more number parameters, software component(s)
from the software subsystem (Figure 1), leveraging the model may consume more
CPU resources and takes more time to process. On the contrary, using a lighter
model may offer less accuracy but may higher performance guarantees to the
components consuming it (e.g., less latency for generating a prediction and
thereby better response time). At runtime, over a period of time, the ML
subsystem with automated MLOps practices generates different versions and
types of ML models. This would require the software subsystem to make use of
mechanisms to adapt autonomously between the choice of the ML models by
considering the overall performance requirements of the system.

3\. Architectural Adaptation of ML: ML suffers from the problems of learning
bias and accuracy [34]. Moreover, ML models over a period suffer from model
degradation where the accuracy starts reducing over time due to the variations
in data. For instance, the ML subsystem (Figure 1) might be making use of ML
models that work very well with specific data types. However, with time as
depicted in Figure 1, new data also flows into the system, and this might mean
the predictions of the models also start degrading. Due to this phenomenon,
the components consuming the model in the software subsystem might start
behaving erroneously (e.g., a recommendation system might start producing
absurd recommendations to the user). This might require adapting the
architecture/behavior of the neural network/ML algorithm itself to ensure
robustness (e.g., dynamically adapt the layers of a deep neural network, adapt
hyperparameters, etc.). This will become more relevant in the coming years,
especially with the increasing popularity of Software 2.0 [35], where software
components are expected to be designed and implemented autonomously using ML
techniques.

Developing state of the art techniques for handling self-adaptive concerns of
ML-based software systems will become more critical in the coming years. This
is especially true considering the amount of run-time uncertainty that can be
induced within the system due to the very nature of the ML process itself. It
is also true that one cannot expect a software architect to consider all the
different uncertainties at design-time. This implies that better techniques
will be required to:

i) accurately identify uncertainties of an ML-based software system with
provable guarantees.

ii) autonomously select ML models from a set of available models to better
guarantee the overall performance of the system without compromising much on
the accuracy of the ML model.

iii) handle the adaptation of the ML process itself (at the algorithmic level)
to better handle issues associated with robustness, fairness, etc., which may,
in turn, affect the functionality of the overall system.

Experience: Within the Uffizi project, we experienced both case 1 and case 2
above. In the former case, we adapted the system hardware architecture by
opening or closing kiosks at run-time, depending on the actual needs
forecasted by the ML model (closing kiosks was seen as an operational value
since they were temporarily placed in a space that is traditionally reserved
to other activities). In the latter case, since the ML model used to allocate
large (competing) groups to time slots was quite complex to compute, we had to
impose computational constraints on our software components to avoid response
delays.

###  IV-D Architecture Evolution

Software architecture evolution refers to the process of maintaining and
evolving software architectures over time based on the changes in requirements
and environments. In other words, it allows the architecture to easily
accommodate future changes. Evolvability of software is considered as a
fundamental characteristic towards making strategic decisions and for
increasing the economic value of a software [36].

What exists: Much work has been done in the literature that deals with
software architecture evolution [36]. Modern software systems, especially ML-
based software systems, have a continuously evolving architecture. The
architecture of these systems is expected to evolve at run-time continuously
[18, 37, 38]. This is primarily because more data becomes available as time
progresses, along with the availability of newer and better algorithms. This
process may call for an update of the learning algorithm. Further, this may
impact changing the database schema (to incorporate new data) or adding a new
database (just for storing the new data), modifying software components (due
to change in the interface of the ML component), and so on. Further, how much
data is enough and how much learning is enough at each step of the evolution
requires better techniques to investigate. Just like sometimes software
architecture is driven by technological constraints, the architecture of an
ML-based software system can be driven by algorithmic and data constraints. In
addition, disruptive events might completely change the system’s dynamics and
require a downgrade or upgrade of learned knowledge, or a previously learned
knowledge might become useless. How such situations need to be handled and how
the functional and non-functional requirements can be satisfied by overcoming
such events is something that needs wider research and discussion. E.g., COVID
and how it can impact people’s behavior in entering the museum.

What lies ahead: The primary drivers on one side of ML-based systems are data
and model, which is in turn based on the choice of the learning algorithm.
Over a period of time, any changes in requirement arising due to the data or
algorithm may require the architecture of the entire system to be evolved to
satisfy the overall requirements. This brings up two essential areas that need
to be considered:

1\. Data-Induced Evolution: One of the fundamental drivers of machine learning
is the availability of good quality training data. ML-based software systems
are usually implemented with good data collection pipelines responsible for
collecting, filtering, and transforming data as required by the ML algorithms.
The ML components further rely on the data collected to make predictions,
classifications, etc. Over time, due to additional requirements, the ML
algorithm may need to be adapted, and this may cause the data pipeline to be
adapted to satisfy the data requirements of the ML components. This means the
architect should be able to foresee such drastic changes while considering the
architecture runway, which further calls for mechanisms/tools that can allow
the architect to better evaluate data quality standards.

2\. ML Algorithm-Induced Evolution: The second fundamental driver of any ML-
based software system is the choice of the learning algorithm(s) to be used
and the type of model(s) generated from the learning process. Once the
architecture is implemented, the ML part of the system usually keeps
generating new ML models periodically based on the availability of qualitative
and quantitative data. These models are further deployed into production using
some standard MLOps practices. However, over time the learning algorithm might
need to be modified (to produce lighter models for performance or more
accurate models). This may require new data to be collected and the model
interface to be redefined. This may further require the architecture of the
software to be evolved to better support the new learning algorithm’s
requirements. This kind of evolution may also arise in the case of legacy
software systems that are in need of building intelligence to existing
functionalities (e.g., adding recommendation feature to traditional e-commerce
system).

One of the challenges in architecting ML-based software systems, or any
software systems in general, is equipping the systems with the ability to
evolve. As we have pointed above, in ML-based systems, this evolution (apart
from the software side) can primarily arise from two important drivers, which
include data and algorithm. However, more research needs to be done on:

i) how such evolution can be managed or how to better architect ML-based
systems that can cope with the fluctuating demands of data and constantly
evolving ML techniques.

ii) how to evolve a legacy software system to ML-based software systems. In
such evolution, how to better handle existing team dynamics, technology
constraints, organizational constraints, business requirements, etc.

iii) the tools/frameworks that architects can leverage to better consider an
architecture runway that supports the constantly evolving requirements of an
ML-based software system.

Experience: Within the Uffizi project, we built a sophisticated and precise ML
model, with a 0.02 error rate, after collecting two years of data and
incrementally generating a museum-specific ML model. This model was in
operation during the free Sundays, for more than 20 months, till February
2020, when museums had to close due to the COVID pandemic. Now that museums
are partially re-opening, and since the COVID has distorted all the rules
(e.g., we have no clue on the average visiting time of tourists and how many
visitors will come), can we still trust the previous data and ML model?
Probably not! For instance, the COVID protocols might require the visitors to
maintain a minimum distance and move in a particular manner. This might, in
turn, impact the visiting time and thereby requiring additional data on
visitor flow to be collected (using multiple cameras), henceforth resulting in
an update to the ML model. Further, the software component(s) consuming the ML
model may have to be reconfigured to accommodate the changes in the prediction
accuracy/confidence score of the new ML model.

##  V Conclusion

In this work, we have discussed the current outlook of software architecture
in the context of ML-based systems. Based on the context of discussions put
forward in light of our experience in architecting an ML-based system, we
believe that future software architects’ role will change from just being yet
another software architect to an ML-aware software architect. In effect, there
won’t be a separation boundary in the vision of the architect (as depicted in
Figure 1). It will be more of a unified view where there won’t be any
difference between software components and machine learning components at the
architectural level. Rather, they will be considered as another component such
as a model generator, model consumer, data/event generator, data/event
consumer, etc. Such a view can then facilitate the architect to consider an
ML-based software system through the lens of both machine learning and
software architecture resulting in better architecting practices. In this
work, we have proposed different directions that shall allow the community to
propel towards such a standard.

This is an ongoing work. The four different areas that we have considered in
this paper are based on our experience while architecting the ML-based
software system for queue management in Uffizi. There are certainly more areas
of software architecture, such as technical debt, architecture quality, etc.,
which we have not covered in this work. As future work, we plan to investigate
deeper into these different areas and the other research directions presented
in this work. We also believe that these research directions may open up
avenues for developing new architectural style(s) for ML-based software
systems. However, we believe that it is a long-term process, and unlike any
disruptive trend, this, too, shall pose new challenges to the software
architect to wear yet another hat of a machine learning expert.

## Acknowledgment

The authors would like to thank the Uffizi Gallery for the professional
support they got, especially from Director Eike Schmidt and his collaborators,
Simona Pasquinucci, Gianluca Ciccardi, Serena De Laurentiis, Claudia Gerola,
Angela Rossi, and Alessandra Vergari. Further, the authors would also like to
thank their collaborators, Alessandro Attanasio, Maurizio Maravalle, Fabrizio
Rossi, Gianluca Scatena, Francesco Tarquini, Giorgio Lattanzi, Giulio
Nazzicone, Mahyar Moghaddam and Mirco Franzago from the University of L’Aquila
and team Nexpecto for their constant efforts during the design,
implementation, and deployment of the system.

## References

  * [1] McKinsey Analytics, “The age of analytics: competing in a data-driven world,” Technical report, San Francisco: McKinsey & Company, Tech. Rep., 2016\. [Online]. Available: https://www.sipotra.it/wp-content/uploads/2017/01/THE-AGE-OF-ANALYTICS.pdf
  * [2] I. Gerostathopoulos, M. Konersmann, S. Krusche, D. I. Mattos, J. Bosch, T. Bures, B. Fitzgerald, M. Goedicke, H. Muccini, H. H. Olsson _et al._ , “Continuous Data-driven Software Engineering-Towards a Research Agenda: Report on the Joint 5th International Workshop on Rapid Continuous Software Engineering (RCoSE 2019) and 1st International Works,” _ACM SIGSOFT Software Engineering Notes_ , vol. 44, no. 3, pp. 60–64, 2019.
  * [3] F. Bernard Marr. (2018, May) How Much Data Do We Create Every Day? The Mind-Blowing Stats Everyone Should Read. [Online]. Available: https://tinyurl.com/2dyu68fr
  * [4] E. Alpaydin, _Introduction to Machine Learning_. MIT press, 2009.
  * [5] S. Business. (2017, Mar.) Andrew Ng: Why AI Is the New Electricity. [Online]. Available: https://www.gsb.stanford.edu/insights/andrew-ng-why-ai-new-electricity
  * [6] Gartner. (2019, Oct.) Gartner predicts the future of AI technologies. [Online]. Available: https://www.gartner.com/smarterwithgartner/gartner-predicts-the-future-of-ai-technologies/
  * [7] J. Bosch, I. Crnkovic, and H. H. Olsson, “Engineering AI Systems: A Research Agenda,” _arXiv preprint arXiv:2001.07522_ , 2020.
  * [8] Z. Wan, X. Xia, D. Lo, and G. C. Murphy, “How Does Machine Learning Change Software Development Practices?” _IEEE Transactions on Software Engineering_ , 2019.
  * [9] T. Bi, P. Liang, A. Tang, and C. Yang, “A Systematic Mapping Study on Text Analysis Techniques in Software Architecture,” _Journal of Systems and Software_ , vol. 144, pp. 533–558, 2018.
  * [10] H. Muccini and K. Vaidhyanathan, “A Machine Learning-Driven Approach for Proactive Decision Making in Adaptive Architectures,” in _2019 IEEE International Conference on Software Architecture Companion (ICSA-C)_. IEEE, 2019, pp. 242–245.
  * [11] D. E. Perry and A. L. Wolf, “Foundations for the study of software architecture,” _ACM SIGSOFT Software engineering notes_ , vol. 17, no. 4, pp. 40–52, 1992.
  * [12] ITSTAT. (2016, Jan.) I MUSEI, LE AREE ARCHEOLOGICHE E I MONUMENTI IN ITALIA. [Online]. Available: https://www.istat.it/it/files/2016/12/Report-Musei.pdf?title=Musei+
  * [13] N. Squires. (2018, Jan.) Florence’s Uffizi Gallery to reduce four-hour queues to five minutes with the new ticketing algorithm. [Online]. Available: https://www.telegraph.co.uk/news/2018/10/09/florences-uffizi-galleries-reduce-four-hour-queues-five-minutes/
  * [14] “ISO/IEC/IEEE Systems and software engineering – Architecture description,” _ISO/IEC/IEEE 42010:2011(E) (Revision of ISO/IEC 42010:2007 and IEEE Std 1471-2000)_ , pp. 1–46, 2011.
  * [15] J. A. Zachman, “A framework for information systems architecture,” _IBM systems journal_ , vol. 26, no. 3, pp. 276–292, 1987.
  * [16] P. B. Kruchten, “The 4+ 1 View Model of Architecture,” _IEEE Software_ , vol. 12, no. 6, pp. 42–50, 1995.
  * [17] K. Raymond, “Reference model of open distributed processing (RM-ODP): Introduction,” in _Open distributed processing_. Springer, 1995, pp. 3–14.
  * [18] E. Woods, “Software Architecture in a Changing World,” _IEEE Software_ , vol. 33, no. 6, pp. 94–97, 2016.
  * [19] H. Muccini and M. Sharaf, “CAPS: Architecture Description of Situational Aware Cyber Physical Systems,” in _2017 IEEE International Conference on Software Architecture, ICSA 2017, Gothenburg, Sweden, April 3-7, 2017_. IEEE Computer Society, 2017, pp. 211–220. [Online]. Available: https://doi.org/10.1109/ICSA.2017.21
  * [20] S. Amershi, A. Begel, C. Bird, R. DeLine, H. Gall, E. Kamar, N. Nagappan, B. Nushi, and T. Zimmermann, “Software Engineering for Machine Learning: A Case Study,” in _2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP)_. IEEE, 2019, pp. 291–300.
  * [21] L. E. Lwakatare, A. Raj, J. Bosch, H. H. Olsson, and I. Crnkovic, “A Taxonomy of Software Engineering Challenges for Machine Learning Systems: An Empirical Investigation,” in _International Conference on Agile Software Development_. Springer, Cham, 2019, pp. 227–243.
  * [22] L. Dobrica and E. Niemela, “A survey on software architecture analysis methods,” _IEEE Transactions on Software Engineering_ , vol. 28, no. 7, pp. 638–653, 2002.
  * [23] M. Kwiatkowska, “Quantitative Verification: Models Techniques and Tools,” in _Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering_ , 2007, pp. 449–458.
  * [24] I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, and A. Tang, “What Industry Needs from Architectural Languages: A Survey,” _IEEE Transactions on Software Engineering_ , vol. 39, no. 6, pp. 869–891, 2013.
  * [25] B. Randell, “The 1968/69 NATO Software Engineering Reports,” _History of software engineering_ , vol. 37, 1996.
  * [26] D. Weyns, _An Introduction to Self-adaptive Systems: A Contemporary Software Engineering Perspective_. John Wiley & Sons, 2020.
  * [27] F. D. Macías-Escrivá, R. Haber, R. del Toro, and V. Hernandez, “Self-adaptive systems: A survey of current approaches, research challenges and applications,” _Expert Systems with Applications_ , vol. 40, no. 18, pp. 7267 – 7279, 2013. [Online]. Available: http://www.sciencedirect.com/science/article/pii/S0957417413005125
  * [28] C. Krupitzer, F. M. Roth, S. VanSyckel, G. Schiele, and C. Becker, “A survey on engineering approaches for self-adaptive systems,” _Pervasive and Mobile Computing_ , vol. 17, pp. 184–206, 2015.
  * [29] P. Jamshidi, J. Cámara, B. Schmerl, C. Käestner, and D. Garlan, “Machine Learning Meets Quantitative Planning: Enabling Self-Adaptation in Autonomous Robots,” in _2019 IEEE/ACM 14th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS)_. IEEE, 2019, pp. 39–50.
  * [30] F. Quin, T. Bamelis, S. B. Sarpreet, and S. Michiels, “Efficient Analysis of Large Adaptation Spaces in Self-Adaptive Systems using Machine Learning,” in _2019 IEEE/ACM 14th International Symposium on Software Engineering for Adaptive and Self-Managing Systems (SEAMS)_. IEEE, 2019, pp. 1–12.
  * [31] H. Muccini and K. Vaidhyanathan, “Leveraging Machine Learning Techniques for Architecting Self-Adaptive IoT Systems,” in _2020 IEEE International Conference on Smart Computing (SMARTCOMP)_ , 2020, pp. 65–72.
  * [32] M. Wu and M. Kwiatkowska, “Robustness Guarantees for Deep Neural Networks on Videos,” in _Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition_ , 2020, pp. 311–320.
  * [33] J. Cámara, H. Muccini, and K. Vaidhyanathan, “Quantitative Verification-Aided Machine Learning: A Tandem Approach for Architecting Self-Adaptive IoT Systems,” in _2020 IEEE International Conference on Software Architecture (ICSA)_ , 2020, pp. 11–22.
  * [34] R. Courtland, “Bias detectives: the researchers striving to make algorithms fair,” _Nature_ , vol. 558, no. 7710, pp. 357–357, 2018.
  * [35] Oreilly. (2021, Jan.) The Road to Software 2.0. [Online]. Available: https://www.oreilly.com/radar/the-road-to-software-2-0/
  * [36] H. P. Breivold, I. Crnkovic, and M. Larsson, “A systematic review of software architecture evolution research,” _Information and Software Technology_ , vol. 54, no. 1, pp. 16–40, 2012.
  * [37] A. Cummaudo, R. Vasa, J. Grundy, M. Abdelrazek, and A. Cain, “Losing confidence in quality: Unspoken eevolution of computer vision services,” in _2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)_. IEEE, 2019, pp. 333–342.
  * [38] A. Cummaudo, S. Barnett, R. Vasa, J. Grundy, and M. Abdelrazek, “Beware the Evolving ‘intelligent’web service! An integration architecture tactic to guard AI-first components,” in _Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering_ , 2020, pp. 269–280.


# Effect of Stacking Order on the Electronic State of 1 _T_ -TaS2

Zongxiu Wu  Zhejiang Province Key Laboratory of Quantum Technology and Device,
Department of Physics, Zhejiang University, Hangzhou 310027, China  Kunliang
Bu  Zhejiang Province Key Laboratory of Quantum Technology and Device,
Department of Physics, Zhejiang University, Hangzhou 310027, China  Wenhao
Zhang  Zhejiang Province Key Laboratory of Quantum Technology and Device,
Department of Physics, Zhejiang University, Hangzhou 310027, China  Ying Fei
Zhejiang Province Key Laboratory of Quantum Technology and Device, Department
of Physics, Zhejiang University, Hangzhou 310027, China  Yuan Zheng  Zhejiang
Province Key Laboratory of Quantum Technology and Device, Department of
Physics, Zhejiang University, Hangzhou 310027, China  Jingjing Gao  Key
Laboratory of Materials Physics, Institute of Solid State Physics, Chinese
Academy of Sciences, Hefei 230031, China  University of Science and Technology
of China, Hefei 230026, China  Xuan Luo  Key Laboratory of Materials Physics,
Institute of Solid State Physics, Chinese Academy of Sciences, Hefei 230031,
China  Zheng Liu  Institute for Advanced Study, Tsinghua University, Beijing
100084, China  Yu-Ping Sun  Key Laboratory of Materials Physics, Institute of
Solid State Physics, Chinese Academy of Sciences, Hefei 230031, China  High
Magnetic Field Laboratory, Chinese Academy of Sciences, Hefei 230031, China
Collaborative Innovation Center of Advanced Microstructures, Nanjing
University, Nanjing 210093, China  Yi Yin<EMAIL_ADDRESS>Zhejiang Province
Key Laboratory of Quantum Technology and Device, Department of Physics,
Zhejiang University, Hangzhou 310027, China  Collaborative Innovation Center
of Advanced Microstructures, Nanjing University, Nanjing 210093, China

###### Abstract

New theoretical proposals and experimental findings on transition metal
dichalcogenide 1 _T_ -TaS2 have revived interest in its possible Mott
insulating state. We perform a comprehensive scanning tunneling microscopy and
spectroscopy experiment on different single-step areas in pristine 1 _T_
-TaS2. After accurately determining the relative displacement of the Star-of-
David super-lattices in two layers, we find that different stacking orders can
correspond to the similar large-gap spectrum on the upper terrace. When the
measurement is performed away from the step edge, the large-gap spectrum can
always be maintained. The stacking order seems rarely disturb the large-gap
spectrum in the ideal bulk material. We conclude that the large insulating gap
is from the single-layer property, which is a correlation-induced Mott gap
based on the single-band Hubbard model. Specific stacking orders can perturb
the state and induce a small-gap or metallic spectrum for a limited area
around the step edge, which we attribute to a surface and edge phenomenon. Our
work provides more evidence about the stacking-order effect on the electronic
state and deepens our understanding of the Mott insulating state in 1 _T_
-TaS2.

##  I Introduction

The correlation of electrons in many cases plays a crucial role in determining
the special physical properties of quantum materials [1, 2, 3, 4]. The layered
transition metal dichalcogenide (TMD) 1 _T_ -TaS2 is a long-known charge
density wave (CDW) material with a rich phase diagram [5, 7, 6]. In the
commensurate CDW (CCDW) phase, every 13 Ta atoms shrink into a CDW cluster
called star of David (SD) and establish a $\sqrt{13}\times\sqrt{13}$
electronic reconstruction. The multi-folded band of SD super-lattice induces a
flat band around the Fermi energy, whose narrow bandwidth pushes the low-
energy physics to a strong correlation limit. The conventional view is that
each SD contributes one unpaired electron forming a half-filled flat band near
the Fermi level. With the relatively strong correlation of electrons, the
half-filled band splits into lower and upper Hubbard bands (LHB and UHB),
resulting in a Mott insulating gap [1]. The insulating state has been
identified by many experiments like transport, scanning tunneling microscopy
(STM), angle-resolved photoemission spectroscopy (ARPES), $\it{etc}$ [7, 8,
9]. Based on this single-band Mott insulator scenario, many exotic phases like
superconducting and quantum spin liquid state have been proposed and explored
[10, 11, 12, 13, 14, 15].

However, there remain some long-standing unsolved issues about the nature of
the insulating state [16, 17]. The density functional theory (DFT) calculation
always yields a metallic band along the $c$-axis in bulk 1 _T_ -TaS2. It is
inconsistent with the experimental insulating state [18]. Further DFT
calculations reveal that different stacking orders can change the electronic
state on the $ab$-plane, and even open a gap in the whole Brillouin zone
without considering the onsite-U interaction [19, 20, 21]. Experimentally, the
high-resolution synchrotron x-ray diffraction (XRD) and ARPES measurements
found some ambiguous evidence of dimerization along the $c$-axis, and
simplified the insulating state into a trivial band insulator [25, 26]. Recent
STM results revealed two typical terminations showing insulating gaps with
different gap sizes [22, 23, 24]. The large-gap spectrum is similar to the
regular spectrum measured in previous experiments. The large-gap spectrum on
the upper terrace corresponds to an AA-stacking order, in which the SD centers
in the upper and lower layers are aligned. The small-gap spectrum has a much
smaller gap size. The small-gap spectrum on the upper terrace corresponds to
an AC-stacking order in which the SD centers in the upper and lower layers are
misaligned. With a unit-cell doubling model, the authors propose that these
two spectra should alternate in successive layers, and they suggest that the
large gap is a band gap originating from the AA-stacked two layers, while the
small gap on a misaligned termination is the single-layer Mott insulating gap.
These DFT and experimental results seem to be compatible, while some
fundamental problems still exist. These results are strongly against the
conventional single-band Mott scenario in 1 _T_ -TaS2. Previous experiments
show that the large gap can be effectively tuned by external parameters such
as strain, doping, and intercalation [10, 11, 12, 27, 29, 30, 31, 32], which
cannot be simply explained by the band insulator scenario. The molecular beam
epitaxy (MBE)-grown single-layer TMDs 1 _T_ -TaS2 and 1 _T_ -TaSe2 exhibit a
large insulating gap [33, 34], consistent with the most frequently observed
large-gap spectrum in bulk 1 _T_ -TaS2.

To solve the above problems, we implement a systematic and comprehensive STM
study on the stacking order and corresponding electronic state of 1 _T_ -TaS2.
We report accurate determination of various inter-layer alignments of SD
super-lattices and the associated $\it{dI/dV}$ spectra by exploring single-
step areas of the cleaved 1 _T_ -TaS2. Through multiple measurements, we find
that different stacking orders can correspond to the general large-gap
spectrum in 1 _T_ -TaS2. The layer-by-layer stacking order is likely to be
random in the bulk material, against a simple inter-layer dimerization
mechanism [21, 25, 26, 22, 23, 24]. The stacking order seems rarely disturb
the large-gap spectrum in the ideal bulk material. The large gap is therefore
most possibly a single-layer feature and a correlation-driven Mott gap. Within
a limited area around the step edges, stacking orders can purturb the
eletronic state. For the AC- and AB-stacking orders, the top $\it{dI/dV}$
spectra exhibit a small-gap spectrum and a metallic V-shaped spectrum,
respectively. This stacking-order-induced modulation is attributed to a
surface and edge phenomenon instead of the bulk property in 1 _T_ -TaS2. We
continue this project in a related work [35].

Figure 1: Structural and electronic properties of 1 _T_ -TaS2. (a) The upper
panel shows the atomic structure of 1 _T_ -TaS2. The lower panel is a top-view
diagram, with the purple and yellow balls representing the Ta atoms and the
uppermost S atoms, respectively. Ta atom positions can be divided into
central, inner-corner, and outer-corner cases, which are labeled by A, B, and
C (C’), respectively. The red arrow indicates the shrinking of the surrounding
12 Ta atoms toward the central Ta. (b) A typical $30\times 30$ nm2 topography
in a flat area. The inset displays an atomically resolved topography under the
tunneling condition of $V_{\mathrm{b}}=600$ mV, $I=100$ pA. (c) The typical
insulating $\it{dI/dV}$ spectrum of 1 _T_ -TaS2. The red arrows label the
upper and lower Hubbard bands. (d) A complex surface topography.

##  II Experiment and Results

Each layer of 1 _T_ -TaS2 is comprised of a triangular lattice of Ta atoms
sandwiched between the top and bottom triangular lattice of S atoms [Fig.
1(a)]. Each Ta atom is coordinated octahedrally by S atoms. In the CCDW phase,
each SD cluster is formed by 13 Ta atoms, roughly classified by one central Ta
atom (position A), six neighboring Ta atoms at the inner-corner site (position
B), and six next neighboring Ta atoms at the outer-corner site (position C and
C’). We glue the sample on a silica substrate or a regular BeCu sheet, cleave
the sample at liquid nitrogen (LN2) temperature. We found little difference
between silica and BeCu substrate samples after we performed numerous
measurements. We guess the thermal expansion coefficient of two materials is
not large enough to introduce a measurable strain on the surface. Most cleaved
surfaces are very flat as shown in Fig. 1(b), while sometimes we can find a
surface topography with steps as shown in Fig. 1(d). The cleaved sample is
thereafter quickly transferred to the STM scan head in the cryogenic Dewar. We
perform the following STM measurement at LN2 temperature.

The SD super-lattice is discerned in the flat surface topography [Fig. 1(b)],
with each bright spot representing one SD. The surface exposed S atoms can be
atomically resolved within SDs [inset of Fig. 1(b)], when the tip is sharp
enough. A typical $\it{dI/dV}$ spectrum measured at one SD center is shown in
Fig. 1(c). The two coherence peaks are well established roughly at $\pm 200$
mV. The resulting insulating gap of 400 meV has been conventionally considered
as a Mott gap between the LHB and UHB. Peaks outside the Hubbard bands are
associated with CDW features.

Figure 2: AA-stacking single-step area with a top large-gap spectrum. (a) STM
topography of the single-step area. (b) The red and black curves show the
$\it{dI/dV}$ spectra on the upper and lower terraces, respectively. Both
spectra are similar to the typical spectrum in Fig. 1(c). The bottom left
inset displays a schematic diagram of the AA-stacking order. (c) A series of
$\it{dI/dV}$ spectra measured along the black arrowed line in (a), with the
height profile displayed in the lower panel. (d) The determination of SD
super-lattice for the area within the black dashed frame in (a).

STM is an ideal tool to determine the relative displacement of SD super-
lattices in different layers. The electronic density of states (DOS) can also
be simultaneously measured to provide correspondence between the stacking
order and the electronic state. Here we specially choose the flat and single-
step areas. On the one hand, we measure a lot of single-step areas and
statistically infer the most frequent stacking orders between neighboring
layers in the bulk material. On the other hand, we also extend the measurement
away from the step to check whether the results around the step edge is
compatible with that further away from the step.

Figure 2(a) shows the topography of a common example of a single-step area.
For both smooth top and underlying layers, the topography includes a
triangular SD super-lattice and each bright spot represents one SD. Two
typical $\it{dI/dV}$ spectra measured on the lower and upper terraces are
displayed in Fig. 2(b), both similar to the spectrum in Fig. 1(c). To check
how the spectrum evolves, a linecut map is measured along the arrowed line in
Fig. 2(a). As shown in Fig. 2(c), the linecut map of $\it{dI/dV}$ spectrum is
vertically displayed in color in the top panel, corresponding to the height
profile in the bottom panel. On both the lower and upper terraces, the
$\it{dI/dV}$ spectrum shows a periodic intensity variation, and shares the
similar large-gap feature except for some modulations at the step edge. With
both the upper and lower terraces exposed, we analyze the relative
displacement of the upper and lower super-lattices. Within the rectangular
area, the red dots in Fig. 2(d) show the SD array for the lower layer. We
further observe that the red dots at the peninsula coverage area coincide with
the SD centers in the upper layer. The SD centers in the upper and lower
layers are aligned along the $c$-axis. This stacking order can be defined as
the AA-stacking order [inset in Fig. 2(b)].

Figure 3: Three misaligned examples on the single-step area. (a), (c), and (e)
STM topography of the single-step area. The red (blue) dots label SD centers
in the lower (upper) layer, showing a misaligned configuration. (b), (d), and
(f) The red and black curves show the corresponding $\it{dI/dV}$ spectra on
the upper and lower terraces in (a), (c), and (e), respectively.

In the process of collecting and analyzing data, we find examples with
misaligned SD super-lattices in which the large-gap spectrum is obtained on
both the upper and lower terraces. Figure 3(a), 3(c), and 3(e) display three
topographies around different single-step areas. The SD centers are positioned
on both the upper (blue dots) and lower (red dots) terraces, with red dots
also linearly extended to the upper terrace. The SD centers in the upper layer
are misaligned with those in the lower layer. Due to the lattice symmetry in 1
_T_ -TaS2, positioning of SD centers correspond to two possible atomic
arrangements, which differ with a $27.8^{\circ}$ rotation of each SD. We
further apply a specific point defect to obtain the only definite atomic
lattice of the lower layer, with the method shown in Appendix A. In Fig. 3(a),
the SD centers in the upper layer are aligned with different but equivalent
next nearest Ta atoms in each SD in the lower layer. This stacking order is
defined as the AC-stacking order. In Fig. 3(c), the SD centers in the upper
layer are aligned with the nearest Ta atoms in each SD in the lower layer.
This stacking order is defined as the AB-stacking order. The stacking orders
in Fig. 3(e) is determined to be the AC’-stacking order, with the C’ site
different from the C site as shown in Fig. 1(a). Figure 3(b), 3(d), and 3(f)
display the corresponding $\it{dI/dV}$ spectra measured on the lower and upper
terraces of three topographies, respectively. They all share the similar
large-gap feature in spectrum. Multiple measurements have been collected in
different samples with different tips. The electronic state and corresponding
stacking orders are summarized in Table 1. We record 27 times of AA-stacking,
7 times of AC-stacking, 5 times of AB-stacking, and 2 times of AC’-stacking,
all with two large-gap spectra on the lower and upper terraces. The AA-
stacking is relatively dominant, while other stackings also occur a non-
negligible number of times. For all these examples, we also extend the
measurement far away from the step edge, and the large-gap spectrum can always
be maintained (Appendix B). We then presume that the correspondence between
the different stacking orders and the two large-gap spectra is an intrinsic
bulk property instead of just a phenomenon around the step edge.

Table 1: Counts of stacking orders corresponding to different electronic states. Upper surface spectrum | Stacking order | Time
---|---|---
Large-gap | AA-stacking | 27
| AC-stacking | 7
| AB-stacking | 5
| AC’-stacking | 2
Small-gap | AC-stacking | 10
Metallic | AB-stacking | 2

The large insulating gap is the most identified spectrum feature in our
experiment. For all single-step areas, spectrum on the lower terrace exhibits
the large-gap spectrum. For the examples in Fig. 3, the upper-layer spectrum
is not strongly altered in misaligned stacking conditions. The consecutive two
large-gap spectra on two terraces (Fig. 2), instead of the alternating large-
and small-gap spectra, rule out the possibility that the large-gap spectrum
originates from a unit-cell doubling of two AA-stacked layers. When a domain
wall appears in the flat area, researchers have always detected two large-gap
spectra on both sides of the domain wall [28], although different stacking
orders are expected to appear on two sides of the domain wall. Two large-gap
spectra corresponding to non-AA stacking orders in Fig. 3 are naturally
compatible with the domain wall results. The non-AA stacking order with
consecutive two large-gap spectra further excludes the unit-cell doubling
mechanism. A more reasonable model is that the large insulating gap spectrum
reflects the single-layer property, which is still a Mott insulating gap.
Within the ideal bulk material, the stacking order seems to rarely disturb the
large-gap spectrum.

Figure 4: AC-stacking single-step area with a top small-gap spectrum. (a) STM
topography of the single-step area. The red dashed line indicates a domain
wall on the top terrace. (b) Three $\it{dI/dV}$ curves correspond to the
electronic states measured at the red, blue, and green dot positions in (a),
respectively. (c) A series of $\it{dI/dV}$ spectra measured along the black
arrowed line in (a), with the height profile displayed in the lower panel.
(d), (e) The enlargement of the two black boxes in (a). The SD centers in the
upper layer are all aligned with the SD outer-corner sites in the lower layer.

Besides the large insulating gap, other types of $\it{dI/dV}$ spectra have
been observed on the upper terrace of different single-step areas. Figure 4(a)
displays a topography with a top peninsula area. The red dashed line on the
upper terrace marks a domain wall. The SD super-lattices within two domains
are shifted relative to each other. At locations of three points marked in the
image, the $\it{dI/dV}$ spectra are measured on the lower terrace, and two
domains on the upper terrace, respectively. As shown in Fig. 4(b), the
spectrum on the lower terrace is still an insulating spectrum similar to that
in Fig. 1(c). In contrast, the spectra measured within both domains on the
upper terrace are different. The UHB peak is shifted to $140$ mV, and the LHB
splits into two peaks at $-100$ and $-205$ mV. Following we call this type of
spectrum a small-gap spectrum. A linecut map is measured along the arrowed
line in Fig. 4(a), with the results shown in Fig. 4(c). Together with the
periodic intensity variation, the $\it{dI/dV}$ spectrum shows a large-gap
spectrum on the lower terrace and a small-gap spectrum on the upper terrace,
except for some modulations at the step edge and domain wall.

An SD array is extracted for the lower layer, as shown by the red dots in Fig.
4(d) and 4(e). The SD centers in the upper layer, labeled by blue and green
dots for two domains, are observed to be not aligned with those in the lower
layer. They are both determined to be the AC-stacking order, as shown in Fig.
4(d) and 4(e). The similar small insulating gap has been reported with the
same stacking order in recent STM experiments [22, 23, 24]. From the periodic
intensity variation of $\it{dI/dV}$ spectrum on the upper terrace [Fig. 4(c)],
we observe that the three shifted peaks around Fermi energy (zero bias) are
still evident at the SD centers, representing that they are from the Hubbard
bands of central Ta orbital [29]. Since we consider the large-gap spectrum a
single-layer property, the small-gap spectrum in our opinion is a perturbed
and reduced Mott gap in the AC-stacking configuration. During the measurement
of single-step areas, we find that the example in Fig. 4 is also constantly
reproducible (10 times in Table 1). When we extend the measurements away from
the step edge, we find that the small-gap spectra on the upper terrace often
exist within a certain range of the step edge, e.g. 20 nm (Appendix B).
Compared with the AC-stacking case in Fig. 3(a)-3(b), the AC-stacking with a
top small-gap spectrum is a more related to a surface and edge phenomenon.

Figure 5: AB-type stacking single-step area with a top metallic spectrum. (a)
The STM topography of a single-step area. (b) The red and black curves show
the $\it{dI/dV}$ spectra on the upper and lower terraces, respectively. (c) A
series of $\it{dI/dV}$ spectra measured along the black arrowed line in (a),
with the height profile displayed in the lower panel. (d) The determination of
SD super-lattices for the area in the black dashed frame in (a). The red dots
label SD centers in the lower layer, and the blue dots label SD centers in the
upper layer. (e) The enlargement of the black box in (d). The SD centers in
the upper layer are aligned with the SD inner-corner sites in the lower layer.

Another occasional case is presented in Fig. 5 (2 times in Table 1), in which
the AB-stacking order corresponds to a metallic spectrum on the upper terrace.
From the linecut map measured along the arrowed line [Fig. 5(c)], we observe
that the coherent peaks of metallic spectrum are evident at the SD centers and
originate from the Hubbard bands of central Ta orbital [29]. Although a rare
occurrence, the AB-stacking plays the strongest perturbation to the upper-
layer electronic state. The metallic spectra on the upper terrace exist within
a small range of the step edge, also expected to be a surface or edge
phenomenon. The same stacking order can lead to different electronic states
(like Fig. 3(a) vs. Fig. 4) means that some subtle factors other than the
stacking order take effect. The stacking-order-induced modulation of
electronic states can also happen under other complex conditions, like the
mosaic state in a pulsed [36] or strained [30] sample. We do not exclude the
presence of small-gap or metallic spectra under a non-ideal local environment
within the bulk material.

Taken all the above examples together, we conclude that the examples in Fig. 2
and Fig. 3 reflect the stacking orders and electronic states in the bulk
material. By measuring a lot of single-step areas, we can infer the most
frequent stacking orders between neighboring layers in the bulk material. The
AA-stacking is a prominent stacking order, while other stacking orders like
the AC-stacking also appear from time to time in our samples. The large-gap
spectrum of the single-layer property is, however, not disturbed by different
stacking orders. This picture is compatible with the regular domain wall
results in the bulk material. Around step edges, the AC-stacking and AB-
stacking orders can possibly introduce a modulation of electronic states.
Results around the step-edge areas could be surface and edge phenomena, which
should be avoided when we try to infer the intrinsic property in the bulk
material.

We note that all the typical spectra shown in [22] are also observed in our
experiment, but we provide a different physical picture. The large insulating
gap can also be well compared with that observed in an MBE-grown single layer
1 _T_ -TaS2 [33]. Note that although the large-gap spectrum reflects the
single-layer property of 1 _T_ -TaS2, the special slope from LHB to zero bias
position may be associated with the inter-layer effect along the $c$-axis. A
most recent DFT calculation suggests that the conventional use of atomic-
orbital basis could seriously misevaluate the electron correlation in the CDW
state [37]. By adopting a generalized basis, they successfully reproduce the
Mott insulating state under AA-stacking order condition in 1 _T_ -TaS2,
consistent with our results.

Figure 6: Details of the three-petal shaped defect. (a), (b) Topographies
including the same defect under positive and negative bias voltages. The
tunneling condition is $V_{\mathrm{b}}=-600$ mV and $I=100$ pA in (a), and
$V_{\mathrm{b}}=-1$ V and $I=100$ pA in (b). (c) The red and black curves show
the $\it{dI/dV}$ spectra measured at the center of one defect and a normal SD,
respectively. (d) An atomically resolved three-petal shaped defect under the
tunneling condition of $V_{\mathrm{b}}=600$ mV and $I=200$ pA. (e) Topography
at the same area as in (d). The dashed triangles in (d) and (e) indicate that
three petals of the defect are at the sites of three next nearest S atoms. (f)
Another topography with a three-petal shaped defect ($V_{\mathrm{b}}=-600$ mV,
$I=200$ pA), with the structure of SD cluster superimposed.

##  III Conclusion

In conclusion, our experimental results show that the large insulating gap is
a correlation-driven Mott gap feature of a single-layer 1 _T_ -TaS2, which is
nearly unperturbed in the bulk material even under different stacking orders.
Within a certain range of the step area, the misaligned stacking orders may
disturb the Mott gap to a small-gap or metallic spectrum, which we attribute
to a surface and edge phenomenon. Further theoretical investigations are
required to clarify the subtle interplay between electron correlation, CDW and
stacking order effect.

###### Acknowledgements.

This work was supported by the National Key Research and Development Program
of China (Grants No. 2019YFA0308602), the Key Research and Development Program
of Zhejiang Province, China (2021C01002), and the Fundamental Research Funds
for the Central Universities in China. Z.L. thanks the National Nature Science
Foundation of China (NSFC-11774196) and Tsinghua University Initiative
Scientific Research Program. J.J.G., X.L., and Y.P.S. thank the support of the
National Key Research and Development Program of China (Grants No.
2016YFA0300404), the National Nature Science Foundation of China
(NSFC-11674326 and NSFC-11874357), the Joint Funds of the National Natural
Science Foundation of China, and the Chinese Academy of Sciences’ Large-Scale
Scientific Facility (U1832141, U1932217, U2032215).

##  Appendix A A Special Type of Point Defect in 1 _T_ -TaS2

Figure 7: Two consecutive AA-stacking steps with a large-gap spectrum. (a) The
STM topography of the two-step area. The single-step edges are blurred as
affected by the tip features. (b) and (c) The determination of SD super-
lattice for the left (right) black frame in (a). (d) The black, red, and blue
curves show the dI/dV spectra on the lower, middle, and upper terraces.

Figure 6 shows representative data for a particular type of defect we find in
1 _T_ -TaS2. Figure 6(a) and 6(b) are two topographic images taken at the same
area with bias voltage at 600 mV and -1000 mV, respectively. A three-petal
shaped defect can be observed in the middle of both images, pointing in the
same direction but with the three petals in Fig. 6(b) gathered closer. We
notice that each SD is a triangle in the topography, with the direction of the
triangle in both topographies inverted. Figure 6(c) shows two $\it{dI/dV}$
spectra measured at the center of the three-petal defect and a normal SD.
Compared with the normal large-gap spectrum, the defect spectrum shows a
totally suppressed UHB while the LHB is left with a raised peak at -300 mV.

Occasionally, the atomically resolved topography can be obtained when the tip
is under a special condition. Figure 6(d) and 6(e) are two topographic images
in the same area, with Fig. 6(d) showing the atomically resolved surface, on
which the top S atoms can be discerned. The brightest atoms in each SD are the
three nearest neighboring S atoms of the central Ta, leading to the triangle
SDs in Fig. 6(e). The dashed triangles in Fig. 6(d) and 6(e) directly
illustrate that the three-petal feature of the defect corresponds to the sites
of the next nearest S atoms of the central Ta atom. In Fig. 6(d), the black
hole within the defect area indicates that the defect is possibly a missing
central Ta, with both UHB and LHB suppressed in the defect spectrum. The
origin of the raised peak below LHB is still an open question at current
status. Then this special type of point defect can help to determine the
atomic lattice arrangement as shown in Fig. 6(f).

Figure 8: Three typical examples of the single-step area results. (a) and (c)
Two single-step area topographies. On the top terrace, small-gap spectra
appear on the blue-shaded areas. Large-gap spectra appear on all the other
regions in both topographies. Red dashed lines indicate domain walls. (b) A
series of dI /dV spectra measured along the black arrowed line in (a), with
the height profile displayed in the lower panel. (d) A single-step area
topography. The large-gap spectra appear on the top terrace and extend the
whole area of the top terrace.

##  Appendix B Different examples of electronic states at step areas

In Fig. 7, we give a two-step area example showing three large-gap spectra
compatible with the AA-AA-AA stacking. Although we mainly apply the single-
step area results to infer the stacking order information, the multi-step
result could be compatible with the inferred information. The explicit example
of AA-AA-AA stacking can be a counterexample to the AA-AC-AA-AC stacking in
the unit-cell doubling model. Then we further exclude the unit-cell doubling
mechanism.

In Fig. 8(a) and 8(c), we show two single-step topographies. On the top
terrace, the small-gap spectra appear in small areas at the edge of the step
(blud shaded areas). When going away from the step edge, the small-gap spectra
recover to the large-gap insulating spectra. In Fig. 8(a), this boundary is a
domain wall on the top terrace, marked by the red dashed line. In Fig. 8(b),
we present the $dI/dV$ spectra taken along the black arrowed line in Fig.
8(a). On two sides of the domain wall, we could observe an abrupt change from
the small-gap spectra to the large-gap spectra. In Fig. 8(c), although no
domain walls appear on the top terrace, the small-gap spectra also change
abruptly to the large-gap spectra. Guided by the red dashed line of domain
wall on the bottom layer, the blue shaded area in Fig. 8(c) is possibly
surrounded by the bottom-layer domain walls. Figure 8(d) shows another single-
step topography. The large-gap spectra appear on the top terrace and extend
the whole area of the top terrace.

## References

  * [1] N. F. Mott,  Metal-Insulator Transition,  Rev. Mod. Phys. 40, 677-683 (1968).
  * [2] M. Imada, A. Fujimori, and Y. Tokura,  Metal-Insulator Transitions,  Rev. Mod. Phys. 70, 1039 (1998).
  * [3] P. A. Lee, N. Nagaosa, and X. G. Wen,  Doping a Mott Insulator: Physics of High Temperature Superconductivity,  Rev. Mod. Phys. 78, 17-85 (2006).
  * [4] D. Belitz and T. R. Kirkpatrick,  The Anderson-Mott Transition,  Rev. Mod. Phys. 66, 261-380 (1994).
  * [5] R. Manzke, T. Buslaps, B. Pfalzgraf, M. Skibowski, and O. Anderson,  On the Phase Transitions in 1 _T_ -TaS2,  Europhys. Lett. 8, 195-200 (1989).
  * [6] P. Fazekas and E. Tosatti,  Charge Carrier Localization in Pure and Doped 1 _T_ -TaS2,  Phys. B + C 99, 183-187 (1980).
  * [7] P. Fazekas and E. Tosatti,  Electrical, Structural and Magnetic Properties of Pure and Doped 1 _T_ -TaS2,  Phil. Mag. B 39, 229-244 (1979).
  * [8] J. J.Kim, W. Yamaguchi, T. Hasegawa, and K. Kitazawa,  Observation of Mott Localization Gap Using Low Temperature Scanning Tunneling Spectroscopy in Commensurate 1 _T_ -TaS2.  Phys. Rev. Lett. 73, 2103 (1994).
  * [9] F. Zwick, H. Berger, I. Vobornik, G. Margaritondo, L. Forró, C. Beeli, M. Onellion, G. Panaccione, A. Taleb-Ibrahimi, and M. Grioni  Spectral Consequences of Broken Phase Coherence in 1 _T_ -TaS2 Phys. Rev. Lett. 81, 1058 (1998).
  * [10] B. Sipos, A. F. Kusmartseva, A. Akrap, H. Berger, L. Forró, and E. Tutiš,  From Mott State to Superconductivity in 1 _T_ -TaS2,  Nat. mater. 7, 960-965 (2008).
  * [11] Y. Liu, R. Ang, W. J. Lu, W. H. Song, L. J. Li, and Y. P. Sun,  Superconductivity Induced by Se-Doping in Layered Charge-Density-Wave System 1 _T_ -TaS${}_{2-x}Se_{x}$,  Appl. Phys. Lett. 102, 192602 (2013).
  * [12] R. Ang, Y. Miyata, E. Ieki, K. Nakayama, T. Sato, Y. Liu, W. J. Lu, Y. P. Sun, and T. Takahashi,  Superconductivity and Bandwidth-Controlled Mott Metal-Insulator Transition in 1 _T_ -TaS${}_{2-x}Se_{x}$,  Phys. Rev. B 88, 115145 (2013).
  * [13] K. T. Law and P. A. Lee,  1 _T_ -TaS2 as a Quantum Spin Liquid,  Proc. Natl. Acad. Sci. USA 114, 6996-7000 (2017).
  * [14] H. Murayama, Y. Sato, T. Taniguchi, R. Kurihara, X. Z. Xing, W. Huang, S. Kasahara, Y. Kasahara, I. Kimchi, M. Yoshida, Y. Iwasa, Y. Mizukami, T. Shibauchi, M. Konczykowski, and Y. Matsuda,  Effect of Quenched Disorder on the Quantum Spin Liquid State of the Triangular-Lattice Antiferromagnet 1 _T_ -TaS2,  Phys. Rev. Research 2, 013099 (2020).
  * [15] M. Klanjšek, A. Zorko, R. Žitko, J. Mravlje, Z. Jagličić, P. K. Biswas, P. Prelovšek, D. Mihailovic, and D. Arčon,  A High-Temperature Quantum Spin Liquid with Polaron Spins,  Nat. Phys. 13, 1130-1134 (2017).
  * [16] P. Darancet, A. J. Millis, and C. A. Marianetti,  Three-Dimensional Metallic and Two-Dimensional Insulating Behavior in Octahedral Tantalum Dichalcogenides,  Phys. Rev. B 90, 045134 (2014).
  * [17] M. T. Suzuki and H. Harima,  Electronic Band Structure of 1 _T_ -TaS2 in CDW Phase,  J. Magn. Magn. Mater. E653, 272-276 (2004).
  * [18] F. J. Di Salvo and J. E. Graebner,  The Low Temperature Electrical Properties of 1 _T_ -TaS2,  Solid State Commun. 23, 825-828 (1977).
  * [19] T. Ritschel, J. Trinckauf, K. Koepernik, B. B$\ddot{u}$chner, M. v. Zimmermann, H. Berger, Y. I. Joe, P. Abbamonte and J. Geck,  Orbital Textures and Charge Density Waves in Transition Metal Dichalcogenides,  Nat. Phys. 11, 328-331 (2015).
  * [20] T. Ritschel, H. Berger, and J. Geck,  Stacking-Driven Gap Formation in Layered 1 _T_ -TaS2,  Phys. Rev. B 98, 195134 (2018).
  * [21] S. H. Lee, J. S. Goh, and D. Cho,  Origin of the Insulating Phase and First-Order Metal-Insulator Transition in 1 _T_ -TaS2,  Phys. Rev. Lett. 122, 106404 (2019).
  * [22] C. J. Butler, M. Yoshida, T. Hanaguri, and Y. Iwasa,  Mottness Versus Unit-Cell Doubling as the Driver of the Insulating State in 1 _T_ -TaS2,  Nat. Commun. 11, 2477 (2020).
  * [23] C. J. Butler, M. Yoshida, T. Hanaguri, and Y. Iwasa,  Doublonlike Excitations and Their Phononic Coupling in a Mott Charge-Density-Wave System,  Phys. Rev. X 11, 011059 (2021).
  * [24] J. Lee, K.-H. Jin, H.W. Yeom,  Distinguishing a Mott Insulator from a Trivial Insulator with Atomic Adsorbates,  Phys. Rev. Lett. 126, 196405 (2021).
  * [25] Y. D. Wang, W. L. Yao, Z. M. Xin, T. T. Han, Z. G. Wang, L. Chen, C. Cai, Y. Li, and Y. Zhang,  Band Insulator to Mott Insulator Transition in 1 _T_ -TaS2,  Nat. Commun. 11, 4215 (2020).
  * [26] Q. Stahl, M. Kusch, F. Heinsch, G. Garbarino, N. Kretzschmar, K. Hanff, K. Rossnagel, J. Geck, and T. Ritschel,  Collapse of Layer Dimerization in the Photo-Induced Hidden State of 1 _T_ -TaS2,  Nat. Commun. 11, 1247 (2020).
  * [27] L. J. Li, W. J. Lu, X. D. Zhu, L. S. Ling, Z. Qu, and Y. P. Sun,  Fe-Doping-Induced Superconductivity in the Charge-Density-Wave System 1 _T_ -TaS2,  Europhys. Lett. 97, 67005 (2012).
  * [28] D. Cho, G. Gye, J. Lee, S. H. Lee, L. Wang, S. W. Cheong, and H. W. Yeom,  Correlated electronic states at domain walls of a Mott-charge-density-wave insulator 1 _T_ -TaS2,  Nat. Commun. 8, 392 (2017).
  * [29] S. Qiao, X. T. Li, N. Z. Wang, W. Ruan, C. Ye, P. Cai, Z. Q. Hao, H. Yao, X. H. Chen, J. Wu, Y. Y. Wang, and Z. Liu,  Mottness Collapse in 1 _T_ -TaS${}_{2-x}Se_{x}$ Transition-Metal Dichalcogenide: an Interplay Between Localized and Itinerant Orbitals,  Phys. Rev. X 7, 041054 (2017).
  * [30] K. L. Bu, W. H. Zhang, Y. Fei, Z. X. Wu, Y. Zheng, J. J. Gao, X. Luo, Y. P. Sun, and Y. Yin,  Possible Strain Induced Mott Gap Collapse in 1 _T_ -TaS2,  Commun. Phys. 2, 146 (2019).
  * [31] E. Lahoud, O. N. Meetei, K. B. Chaska, A. Kanigel, and N. Trivedi,  Emergence of a Novel Pseudogap Metallic State in a Disordered 2D Mott Insulator,  Phys. Rev. Lett. 112, 206402 (2014).
  * [32] Y. J. Yu, F. Y. Yang, X. F. Lu, Y. J. Yan, Y. H. Cho, L. G. Ma, X. H. Niu, S. Kim, Y. W. Son, D. L. Feng, S. Y. Li, S. W. Cheong, X. H. Chen, and Y. B. Zhang,  Gate-Tunable Phase Transitions in Thin Flakes of 1 _T_ -TaS2,  Nat. Nanotechnol. 10, 270-276 (2015).
  * [33] H. C. Lin, W. T. Huang, K. Zhao, S. Qiao, Z. Liu, J. Wu, X. Chen, and S. H. Ji,  Scanning Tunneling Spectroscopic Study of Monolayer 1 _T_ -TaS2 and 1 _T_ -TaSe2,  Nano Res. 13, 133-137 (2020).
  * [34] Y. Chen, W. Ruan, M. Wu, S. J. Tang, H. Ryu, H. Z. Tsai, R. Lee, S. Kahn, F. Liou, C. H. Jia, O. R. Albertini, H. Y. Xiong, T. Jia, Z. Liu, J. A. Sobota, A. Y. Liu, J. E. Moore, Z. X. Shen, S. G. Louie, S. K. Mo, and M. F. Crommie,  Strong Correlations and Orbital Texture in Single-Layer 1 _T_ -TaSe2,  Nat. Phys. 16, 218-224 (2020).
  * [35] W. Zhang, Z. Wu, K. Bu, Y. Fei, Y. Zheng, J. Gao, X. Luo, Z. Liu, Y. Sun, and Y. Yin,  Reconciling the bulk metallic and surface insulating state in 1 _T_ -TaSe2,  Phys. Rev. B 105, 035110 (2022).
  * [36] L. G. Ma, C. Ye, Y. J. Yu, X. F. Lu, X. H. Niu, S. Kim, D. L. Feng, D. Tomáanek, Y. W. Son, X. H. Chen, and Y. B. Zhang,  A Metallic Mosaic Phase and the Origin of Mott-Insulating State in 1 _T_ -TaS2,  Nat. Commun. 7, 10956 (2016).
  * [37] D. B. Shin, T. -D. Nicolas, J. Zhang, M. S. Okyay, A. Rubio, and N. Park,  Identification of the Mott Insulating Charge Density Wave State in 1 _T_ -TaS2,  Phys. Rev. Lett. 126, 196406 (2021).