# Evident: a Development Methodology and a Knowledge Base Topology for Data
Mining, Machine Learning and General Knowledge Management

Mingwu (Barton) Gao
Work done in Philips North America
Now with Google LLC
<EMAIL_ADDRESS>
<EMAIL_ADDRESS>
Samer Haidar
Philips North America
<EMAIL_ADDRESS>
Corresponding Author

###### Abstract

Software has been developed for knowledge discovery, prediction and management
for over 30 years. However, there are still unresolved pain points when using
existing project development and artifact management methodologies.
Historically, there has been a lack of applicable methodologies. Further,
methodologies that have been applied, such as Agile, have several limitations
including scientific unfalsifiability that reduce their applicability.
_Evident_ , a development methodology rooted in the philosophy of logical
reasoning and _EKB_ , a knowledge base topology, are proposed. Many pain
points in data mining, machine learning and general knowledge management are
alleviated conceptually. _Evident_ can be extended potentially to accelerate
philosophical exploration, science discovery, education as well as knowledge
sharing & retention across the globe. _EKB_ offers one solution of storing
information as knowledge, a granular level above data. Related topics in
computer history, software engineering, database, sensing hardware,
philosophy, and project & organization & military managements are also
discussed.

##  1 Introduction

Necessity is the mother of invention, claimed Plato [1]. Deficient in rigorous
scientific scrutinization as the statement is, major methodology evolutions in
software development did not emerge until the emergence of major computer
innovations and thereafter elevated effort orchestration needs.

In the 1940s, digital programmable electronic computers revolutionized
scientific calculation done previously with mechanical and analog computing
machines [2]. Assembly (1947) [3, 4] and high level (1953) [5, 6] programming
languages rose to harness the unprecedented and ever-increasing computing
power, Eventually the term software was coined (1953) [7]. Two Software
Development Methodologies (SDMs) were proposed: 1. a project breakdown of
sequential phases, the essence of Waterfall (see Fig 1a), first presented no
later than 1956 [8] and 2. iterative and incremental SDM, the essence of Agile
(see Fib 1b), first executed no later than 1957 [9].

In the 1960s, operating systems (1962) emerged to orchestrate multiple
computation tasks[10]. This signified the shift of computer development from
single-task specialized machines for military and academia to machines
accessible to the general public. The shift was exemplified by The Mother of
All Demos (1968) which demonstrated many fundamental elements of personal
computing for the first time [11] and showed how software had evolved in both
diversity and complexity. Meanwhile, the first formal detailed diagram of the
Waterfall methodology appeared in literature (See Fig 1a) (1970) [12] and the
name of Waterfall was ultimately coined (1976) [13]. Agile variants such as
evolutionary project management [14] and adaptive SDM [15] appeared in the
early 1970s, although no clear preference between Waterfall and Agile variants
was found in the literature.

Table 1: Major Software Usage Evolutions and Methodology Developments
---
Period |  Technology | Software Usage |  Major Methodology Development
1940s |  Programing Language |  Scientific Calculation |  First Waterfall variant presentation (1956) [8]; first Agile variant execution (1957)[9].
1960s |  Operating System |  Shifting to Applications |  First detailed diagram of Waterfall idea(1970)[12], Waterfall name (1976)[13]; Agile variants: evolutionary project management [14] & adaptive SDM [15](early 1970s).
1980s |  GUI & Internet |  PC & Internet Applications |  Waterfall standardized in military (1985)[20]; The Manifesto signed (2001)[24]. Agile significantly more popular than Waterfall.
Around 1990 |  Data Storage |  Knowledge Discovery, Prediction and Management | NA

In the 1980s, personal computers entered households[16] followed by graphic
user interface (GUI) (1983) [16]. The Internet Protocol Suite (TCP/IP) was
standardized (1982)[17] and commercial Internet service providers emerged
(1989) [18, 19] Unprecedented user-computer interactions and user-user
communications created tremendous software needs, while Waterfall was still
widely deployed in software development. United States Department of Defense
issued a military standard describing Waterfall as the required military
software development process (1985) [20]. However, software user needs grew so
fast that, the heavy Waterfall SDM failed to deliver in pace. Consequently, a
number of light weight SDMs were proposed and practiced (1990s) [4, 21, 22,
23]. Eventually The Manifesto for Agile Software Development (The Manifesto)
[24] was signed by 17 practitioners of light-weight SDM (2001) and became the
de facto SDM.

Around 1990, data storage capacities grew significantly and software usages in
Data Mining (DM, defined as knowledge discovery from data) reached the tipping
point. While data and software’s storage manners differ between Von Neumann
and Harvard architectures, data storage capacity growth empowered software to
discover knowledge supported by scientific evidence (defined as Knowledge)
that people never had access to. Corporations started to analyze customers’
behavior and make business decisions based on Knowledge (1990s) [25]. The
first DM methodology, Cross-Industry Standard Process for Data Mining (CRISP-
DM) was conceived (1996) [26, 27]. However, CRISP-DM and its variants appear
more of a theoretical framework, offer little meaningful or actionable
guidance, and therefore have not gotten much traction. In addition, CRISP-DM
is concerned only with DM, not Machine Learning (ML, defined as to deliver an
algorithm (Algo) for Knowledge prediction) or Knowledge Management (KM) in
general for science, medicine, military and so on. Due to the absence of
alternative methodologies(see Table 1), Agile is still being offered up for
DM, ML, and KM [28, 29] with questions being asked about its appropriateness
[30, 31].

This paper discusses limitations in Agile as a scientific claim and why it may
not address the current pain points of DM, ML and KM, which are later
summarized. _Evident_ along with _Evident Knowledge Base_ (_EKB_) is proposed
as a project development and artifact management methodology. _Evident_ ’s
potential in alleviating many current pain points is demonstrated
conceptually. Unalleviated pain points and future work to fulfill the
potential are also discussed. Beyond software development, _Evident_ is
illustrated to be applicable in many aspects of society. _EKB_ is demonstrated
as one potential infrastructure to store information as Knowledge, a granular
level above data.

##  2 Agile ambiguity and unfasifiability

Most people regard Agile as iterative, evolutionary and incremental software
development [9] (see Fig 1b) and many claim to be Agile practitioners.
However, Agile empirical evidence is mixed and hard to find [32, 30] while no
measurable scientific evidence has been found at all. Although control
experiment challenges or absence of quantitative project Agility measurements
may explain no measurable scientific evidence, concerns remain with the
ambiguity with which Agile’s approaches and scope are defined in The
Manifesto.

###  2.1 Agile approaches are vaguely defined in The Manifesto

The Manifesto includes 4 values and 12 principles [24]. The goal is crystal
clear: to rapidly deliver quality software that meets user needs, but not so
much can be found for how to get there. Most of the Values and Principles
appear to be goals but not approaches (see Appendix); some are concerned with
approaches but vaguely defined; only three principles are actionable, which
turn out to have no relevance in how to implement iterative, evolutionary or
incremental development. Agile Alliance, co-founded by some original signers
of The Manifesto, defines Agile as “an umbrella term for a set of frameworks
and practices” from which Agile practitioners “figure out the right things to
do given your particular context.” [33] Unfortunately, no actionable
approaches are defined.

Therefore although there are numerous frameworks under the Agile umbrella [34,
35], it’s impossible to determine if a development practice is Agile and the
claim of Agile practice becomes unfalsifiable. Because falsifiability is the
standard evaluating scientific against non-scientific claims introduced by
Karl Popper [36], Agile is not a scientific claim. Consequently, no observable
scientific evidence can prove or disprove Agile, because technically no one
can determine if a project is Agile or not in the first place. If an Agile
rollout “fails”, Agile proponents can always argue that the Agile rollout was
not implemented correctly.

Meanwhile Agile practitioners cannot determine if they practice Agile
correctly either. Projects employing Agile frameworks such as Test Driven
Development or Feature Driven Development may not even realize that the
projects may not be adaptive to new user needs. People who are essentially
practicing Waterfall may believe they are practicing Agile only because they
implement each sequential Waterfall phase incrementally or simply use Scrum or
Kanban.

In defense, some proponents claim Agile as a philosophy [37, 38]. Granted
Agile’s goal may fit into Axiology, one of Philosophy’s four domains (the rest
as Metaphysics, Epistemology and Logic) [39], concerned with what is good, it
appears to be a common understanding and offers little value when Agile’s
approaches are vaguely defined.

###  2.2 No scopes are defined in The Manifesto

“The right things to do given your particular context” by Agile Alliance [33]
are expected to be found within Agile’s frameworks, otherwise Agile is not
practiced right. With no scope defined, Agile seems to cover the scope of all
softwares. However, some softwares have non-incremental needs or simply only
one need, e.g. to solve one specific partial differential equation
numerically. Their needs are either met or not at all. No iteration or
evolutionary Agile design cycles exist.

Agile is also not applicable for Knowledge discovery tasks such as DM. In a
typical Agile development cycle (Fig 1b), Review phase is to discover
Knowledge about user needs, which can be done through DM. Therefore Agile
should not be applicable to DM, one phase of its own design cycle.

Table 2: Pain Points of DM, ML and KM.
---
Pain Points for DM
Overall |  Struggles to deliver fast with technical debt |  abc
Project Progress not easily measurable |  b
Uncertainty in project timeline |  b
Activities not easily trackable or reproducible |  bc
Not scalable in terms of both collaborator number and project maintenance |  ab
Few general project design patterns |  abc
Anti-patterns not uncommon |  abc
Collabor- ation |  No methodologies to orchestrate team of size commonly seen in software development |  b
Few intuitive manners to divide task among team members |  ab
Deficient common awareness in needs for process improvement |  a
Tasks completed or ideas explored by team members cannot be easily found and reproduced causing duplicated work. |  bc
Data |  Data compromised in availability, accuracy and consistency during acquisition |  x
Data preprocessing process not standardized such as data labeling, object detection (e.g. identify object pixels in images) causing unstable data dependency, cascade correction and uncertainty in project progress |  b
Underutilized data may take unnecessary resource |  b
Data may be presented in different data type such as integer, float or string, causing unnecessary data dependency for Algo and experiments |  b
Knowledge Discovery / ML Algo Research |  Off-the-shelf models are available for DM automation. However, DM automation has not become a common practice. |  abc
Inefficient in-house model code implementation not uncommon |  b
No appropriate version control tools. Current version control tools such as git are designed to only keep the best version Algo/experiment available, while DM and ML need multiple versions available concurrently for reference |  abc
No easy solution to request flexible data storage, memory and computation capacity as needed. Hard drive, RAM, CPU and GPU are difficult to allocate even on the cloud. |  x
The use of other Algos’ output as input results in correction cascades |  b
Algo is a sequential computation process different from typical software applications with a number of independent features. Difficult to assign one Algo development into multiple team members |  x
Algo user may have no clear understanding about the Algo and deploys it outside its scope. |  b
Multiple programing language smell |  x
Pain Points for ML
Algo Production |  Significant efforts of research Algo migration into production |  bc
Even more significant efforts if production Algo is written in a different language than the language used in research, e.g. in embedded system |  x
For Algo analyzing sensor data such as cameras or bio-sensors, product grade data won’t be available for Algo research until sensor hardware designs are complete. Algo becomes the product release bottleneck, resulting in either sub-optimal production Algo or delayed product release. |  x
Production data source is inconsistent with research data source |  x
Algo production is often done by team members, most likely software engineers, who did not produce the Algo, causing misuse |  abc
Algo needs to load data in real time during production but most often not in real time during research, causing unnecessary Algo code re-factoring |  b
Prototype Algo may be accidentally run in production causing damages |  x
No straightforward way to organize codes repository for research and production team members work in the same repository |  abc
Dead code path |  b
Feedback Loop |  Algo update workflow not straight forward |  b
Few clear pattern designs for monitoring Algo performance in production |  b
Actions based on unseen data predicted by Algo may alter observed data |  x
Pain Points for KM
Manage- ment Tool |  Few tools or resource help people check if Knowledge formed is well supported by evidence, especially when evidence appears long after presumed Knowledge has been formed. |  abc
Knowledge dissemination among community has always been a challenge. |  abc
Knowledges formed by different organizations are not easy to combine |  abc
Knowledge formed within organizations is not easy to share and retain. |  abc
Standardi- zation |  Knowledge has been recorded in sentences or articles. Few standardized ways to represent general Knowledge. |  abc
a/b/c: Pain points that can be alleviated by _Evident_ ’s character a, b or c.
x: Pain points that cannot be alleviated by _Evident_.

##  3 Pain points for DM, ML and KM

Owing to the absence of applicable methodologies, pain points have been
continuously reported for DM, ML and KM [40, 41, 42, 43] (see Table 2) in the
current big data era with explosive growth in data volume, variety and
velocity.

DM & ML’s Algo typically comprises a data computation flow (defined as a
Model, supervised or unsupervised), such as logistic regression, and its
configuration, such as logistic regression coefficients. DM employs off-the-
shelf or in-house Models to discover Knowledge from data. ML compares
Knowledges discovered by DM by candidate models and deploys the one that
performs best with its configuration, as the production Algo, for Knowledge
prediction in production. Therefore, DM’s pain points still apply to ML.
Meanwhile because DM and ML are special forms of KM, their pain points are
also applicable for KM (see Fig 2).

Generally speaking, DM has not been regarded highly collaborative and scalable
activities to deliver high throughput Knowledge. It’s rare to see hundreds of
contributors in a DM project, unlike for example some complicated open source
software projects that, deliver promptly, efficiently and continuously for
years or even decades [44, 45]. It is also rare of mass Knowledge production
in a organized and standardized manner with high production yield for a unit
period, commonly seen in consumer products such as automobiles or toothpastes.
DM often struggles to deliver Knowledge rapidly with technical debts in
reproducibility, measurability, trackability. DM needs to not only handle
artifacts of different modalities such as documents, codes and data, but also
address computation and data storage resource requests potentially across
multiple platforms. Raw or preprocessed data can be compromised in
availability, accuracy and consistency. Data dependency and entangled models
often cause cascaded correction and uncertainty in project planning. In
addition, routine tasks such as quarterly or annual finance analysis mostly
have not be automated. Tools and project management methodologies are highly
in demand to fulfill DM’s potential and deliver values.

In ML, the team members, usually software engineers or product managers, that
deploy an Algo in production to predict future data may not have produced the
Algo and may misuse it. The Algo codes are often refactored sometimes in
different programming languages, operating systems or even in fixed point
instead of float point. If the Algo is to be deployed on a data acquisition
product such as cameras or bio-sensors, no product grade data are available
for Algo research until the sensor hardware design is finalized to enable data
collection. Algo research therefore becomes the bottleneck for product
release. Frequently sub-optimal Algo is deployed to meet the deadline or
projects become delayed. What’s more, production data may come from different
sources compared to research data potentially caused by, e.g. sensor upgrade
or downgrade, resulting in the under performance of production Algo. After
Algo deployment, no straightforward way exists to monitor Algo performance or
thereafter update Algo. Future Knowledge predicated by the deployed Algo may
encourage Algo users to alter decisions, which leads to the formation of
future data with unanticipated hidden feedback loops. In addition, prototype
Algo or dead codes may be accidentally run in production potentially causing
catastrophic consequences.

Although scientific methods have guided people to discover Knowledge and
improve practices such as evidence-based medicine [46] and experiment based
military development [47], people still form Knowledge that lacks in
supporting evidence [48]. One possible reason is the unavailability of tools
or resources to check if the Knowledge formed is well supported by evidence,
especially when there is a significant time gap between the Knowledge formed
and the appearance of supporting evidence, e.g. for long-term investments or
corporation strategies. Knowledge dissemination and retention are also huge
challenges among the community and organization [49]. Furthermore, Knowledge
is mostly recorded in the form of articles. However, because articles writing
has not been and probably will never be standardized, Knowledge has not been
able to be represented in a standardized manner for definition, reference and
storage. The same Knowledge recorded in different sentences or even languages
may be interpreted differently.

##  4 _Evident_ : a project development and artifact management methodology

###  4.1 Definition and scope

_Evident_ is a methodology of project, including but not limited to software,
development and artifact management for DM, ML and KM, characterized by

  1. a.

project development mimicking a continuous process of logical reasoning in
philosophy;

  2. b.

project activities or artifacts are broken into containers of Observations,
Hypotheses and Tests (collectively defined as Containers);

  3. c.

directional association constructions towards and only towards Test Containers
to represent Knowledge.

Observation is a collection of facts. A Hypothesis is Knowledge to be formed
out of Observation. A Test is a Hypothesis evaluation process using
Observation to prove or disprove the Hypothesis with or without confidence
levels. Containers indicate Observations, Hypotheses and Tests can only be
added or removed as a block.

###  4.2 Knowledge representation

Loosely speaking, a Test associated with a Hypothesis and an Observation
represents induction Knowledge (see Fig 3a); a Test associated with a
Hypothesis set and an Observation represents abduction Knowledge (see Fig 3b),
a Hypothesis associated Test that is also associated with an induction or
abduction Knowledge Test represents deduction Knowledge or prediction (see Fig
3a&b). Deduction Knowledge becomes induction Knowledge once Observation
proving or disproving deduction Knowledge is associated with Test, while stay
deducted Knowledge if the associated Observation overlooks (fails to either
prove or disprove), the deduction Knowledge. Multiple Tests associated with
the same pair of Hypothesis(es) and Observation represent multiple different
Knowledges based on different evaluation metrics (e.g. profit maximization or
cost minimization) or Observation usage strategies (e.g. cross-validation
grouping) (see Fig 3c).

DM may be regarded as Knowledge induction with data as Observation, model as
Hypothesis to be evaluated and data analysis experiment as model test on data
to form induction Knowledge with statistical confidence (see Fig 4a).
Similarly, ML is Knowledge abduction. An example is a data analysis experiment
that picks the best off-the-shelf or in-house model that best explains the
data to form the Algo for production (see Fig 4b). Experiments employing
different cost functions (e.g. RMSE, AUC or correlation coefficients),
statistical confidence levels or data allocation strategies for training and
testing may result in different Knowledges or Algos.

###  4.3 Project development

_Evident_ project developments are intuitively broken down into two granular
levels: Knowledges and Containers. Mimicking logical reasoning in philosophy,
each project period develops a batch of independent Knowledges or Containers
assigned to teams of various sizes to maximize unit time throughput (see Fig
5). The next batches of Knowledge or Containers can be adaptively planned
after period reviews or retrieved from backlogs. _Evident_ is compatible with
Kanban, Scrum or other development tools or frameworks for project planning
and development of a single Knowledge or Container.Any tools or frameworks
that do not compromise the project breakdown into Knowledge and Containers are
applicable.

###  4.4 Artifact management: _EKB_

_Evident_ artifact management may build on a topology of a relational
Knowledge base, named _EKB_ , composed of _Evident_ Containers and directional
associations (see Fig 6). Knowledges can be reproduced by Containers stored in
_EKB_. Oversimplified as a table, _EKB_ columns represent Observations; rows
represent Hypotheses; values represent Tests or Test to be done (TBD). A Test
can only be associated with one Observation, even if the associated
Observation overlooks the Hypothesis(es) associated with the Test. Any new
Observation proving, disproving or overlooking the same Hypothesis(es)
occupies a column in _EKB_.

####  4.4.1 _EKB_ stores containers and Knowledges continuously

When new Hypotheses, Observations or deduction Knowledge Tests are developed,
new rows or columns of TBDs are inserted. A Test associated with
Hypothesis(es) and a Observation can be stored in the designated row and
column to represent different Knowledges.

An induction Knowledge Test is placed in the row of its associated Hypothesis
and the column of its associated Observation (see Fig 3a&c & Fig 6). An
abduction Knowledge Test is placed in the row of the Hypothesis best
explaining the Observation (see Fig 3b & Fig 6). A deduction Knowledge is
placed in the row of its associated Hypothesis and the column of the pending
Observation (see Fig 3a&b & Fig 6). Once an Observation becomes available
proving or disproving the Hypothesis, a deduction Knowledge becomes an
induction Knowledge. Multiple Tests representing different Knowledges can be
placed in the same slot (see Fig 3c & Fig 6).

####  4.4.2 _EKB_ supports relational database operations of Permutation And
Join

_EKB_ is similar to a relational database [50] with Observations as columns,
Hypotheses as rows and Tests as values, but with potential associations among
values for deduction Knowledges. Relational database operations independent of
values associations, such as Permutation (switching rows and columns) and Join
(merging _EKB_ s) can be implemented without compromise in _EKB_ ; operations
dependent on values associations such as Restriction (select rows), Projection
(select columns) and Compositions (merge selected columns&rows from multiple
_EKB_ s) can only be implemented for _EKB_ s storing only induction or
abduction Knowledge and have no associations among Tests.

_EKB_ s are highly flexible for team collaboration and maintenance. Different
team members working on different Containers can share one _EKB_ as the common
work space to improve efficiency. Multiple _EKB_ s can be joined together
without information loss so that Knowledges produced by different teams or
team members can be accumulated into one _EKB_. For _EKB_ s storing only
induction and abduction Knowledge, all relational database operations are
applicable, so that team members can compose their own _EKB_ s without keeping
a potentially large team _EKB_ on the local machines.

##  5 Advantages and pain points alleviated

Inspired by the philosophy of logical reasoning, _Evident_ is intuitive to
understand and follow. Project activity and artifact containerization supports
incremental as well as adaptive project planning and artifact pattern
abstraction. Disentangling Hypotheses and Observations reduces unnecessary
dependency, cascade correction and uncertainty in project planning. Knowledge
representation in associations among artifacts can not only track Knowledge
development, but also Knowledge development status (prove, disproved or
overlooked), which improves project measurability, trackability and
reproducibility. Overall _Evident_ may help applicable projects deliver fast
and at scale with many pain points alleviated in DM, ML and KM (see Table 2).

###  5.1 DM

Containerized Data and Models in _Evident_ prevents unstable data dependency,
model entanglement and cascade correction. Dead data and codes can be easily
identified and removed. Standardized Models and Experiments encourage reuse of
computationally efficient containers, support automatic DM. Different
experiments may use different optimization target function on the same Model
and Data to deliver different Knowledges for different users, e.g. Marketing
vs Engineering managers.

Containerization is an alternative to the state of the art artifact version
control, such as git, which keeps only the one version of the code or data in
the workspace with historic versions saved as commits. _Evident_ keeps all
applicable versions available in the workspace for easy access. This may
appear to use more storage space. However current version control tools all
save version commits as snapshots [51], demanding comparable storage space of
_Evident_ if a _Evident_ equivalent number of versions are stored.

_Evident_ granulates project activities into independent standardized
Knowledge and Container levels, supports adaptive development, facilitates
project planning among collaborators in teams of various sizes and reduces
planning overhead. Artifacts are continuously stored in _EKB_ , making project
development measurable, trackable, reproducible and scalable. Meanwhile once
Containers are produced, Knowledge or documentation reports can be generated
automatically instead of manually. _Evident_ accelerates DM delivery in both
short-term and long-term.

###  5.2 ML

A deployed Algo can be evaluated easily by re-applying the original Research
Experiment on the production data. Different users involved in the deployment
can understand the Algo’s scope and origins easily by examining the research
Experiment (see Fig 4b). Research Experiments can load data in real time as
Production Experiment, so that both Experiments can inherit the same design
patterns with statistical analysis and evaluation metrics. The Production
Experiment can report and examine the prediction performance at regular time
intervals to detect production data pattern drift for either model
reconfiguration or model replacement. Once a model with its configuration is
retired from production, the production data is containerized and associated
with the Production Experiment, transforming the Production Experiment into
Research Experiment and a deduction Knowledge for prediction into an induction
Knowledge that is also preserved in _EKB_.

Because both research and production can operate on the same _EKB_ , research
and production team members can share the same workspace the way software
engineers work on the same code repository, facilitating the model migration
from research to production and efficient team collaborations.

###  5.3 KM

Knowledge formatting into design patterns of Containers provides a meaningful
progress towards Knowledge standardization for improved definition, reference
and storage compared to state of art sentences or articles. _EKB_ with
standardized Container templates may offer potential tools for people to
examine the Hypotheses formed against evidence or Observations, facilitating
evidence-based decision making and Knowledge development. _EKB_ can not only
facilitate Knowledge dissemination, accumulation and retention, but also label
the development status of each Hypothesis as proved, disproved or overlooked,
a desirable design pattern for projects and Knowledge Management.

##  6 Discussions

###  6.1 Significance

_Evident_ may advance many society domains such as software, philosophy,
science, business as well as Knowledge sharing and retention across the globe,
thanks to its applicability to general KM.

_EKB_ may make no smaller impacts than relational data base [50], the
invention of which created a data base industry, as one solution to store
information as Knowledge, a granular level above data.

###  6.2 Work to do

Work needs to be done regarding _Evident_ ergodicity over logical reasoning in
philosophy. If proved, _Evident_ can support all logical reasoning in
philosophy. No evidence has existed to prove or disprove the claim. _Evident_
ergodicity is overlooked, stated in _Evident_ language, especially considering
logical reasoning in philosophy may evolve.

Control studies need to be done to show _Evident_ can truly provide value. No
tools tailored to support _Evident_ project development planning and _EKB_ are
available, although some existing tools are applicable for use. Particularly
the tools that allow unexpected alteration proof, easy access and
visualization of Containers are in demand. More detailed discussions need to
be done about how _Evident_ help applicable projects with examples.

###  6.3 Pain points not alleviated

_Evident_ offers no detailed guidance in development below Container level.
For example, a Model or computation flow cannot be broken down further into
smaller modules by _Evident_ for incremental and adaptive development.
Multiple languages smells and accidents running prototype Algo in production
cannot be avoided by _Evident_ either. In addition, _Evident_ cannot control
future observation alteration caused by decisions made by people based on
_Evident_ produced Knowledge.

_Evident_ can only manage project artifacts of data or codes but not sensors
or hardwares. Pain points caused in data acquisition such as availability,
inaccuracy and inconsistency are out of _Evident_ ’s scope. _Evident_ is
incapable of improving computation hardware resources allocation either.

###  6.4 More words about Agile

Due to Agile’s ambiguity and unfalsifiability as a scientific claim, it might
be a better practice to drop the term Agile and instead quote each framework
currently under Agile on its own. Frameworks such as iterative and
evolutionary development as well as Kanban are valuable although need to be
employed discretionally. Practitioners should have better understood what
exactly they were doing without being fuzzed by the buzzword Agile.

##  7 Conclusions

The paper proposes _Evident_ as a project development and artifact management
methodology for DM, ML and KM as well as _EKB_ as a Knowledge base topology.
_Evident_ and _EKB_ have been shown of great value to alleviate many
unresolved pain points. _Evident_ has the potential to facilitate the
advancement of many aspects of society due to its utility in general Knowledge
management. _EKB_ may serve as the infrastructure for storing information as
Knowledge, a granular level above data.

##  Appendix A Appendix

###  A.1 The following among the four Values and twelve Principles of The
Manifesto [24] appear to be goals:

Value 4: Responding to change over following a plan;

Principle 1: Customer satisfaction by early and continuous delivery of
valuable software.

Principle 2: Welcome changing requirements, even in late development.

Principle 3: Deliver working software frequently (weeks rather than months)

Principle 7: Working software is the primary measure of progress

Principle 8: Sustainable development, able to maintain a constant pace

Principle 9: Continuous attention to technical excellence and good design

Principle 10 : Simplicity—the art of maximizing the amount of work not done—is
essential

###  A.2 The following in The Manifesto appear to be approaches but vaguely
defined:

Value 1: Individuals and interactions over processes and tools

Value 2: Working software over comprehensive documentation

Value 3: Customer collaboration over contract negotiation

Principle 5: Projects are built around motivated individuals, who should be
trusted

Principle 11: Best architectures, requirements, and designs emerge from self-
organizing teams

###  A.3 The following in The Manifesto appear to be actionable approaches but
irrelevant of iterative, evolutionary or incremental development regarded as
Agile by most people [9]:

Principle 4: Close, daily cooperation between business people and developers

Principle 6: Face-to-face conversation is the best form of communication (co-
location)

Principle 12: Regularly, the team reflects on how to become more effective,
and adjusts accordingly

## References

  * [1] B. Jowett and L. Campbell, _Plato’s Republic : the Greek text_. Oxford : At the Clarendon Press, 1894.
  * [2] J. J. P. Eckert and J. W. Mauchly, “Electronic numerical integrator and computer,” New York, NY, 1947.
  * [3] A. D. Booth and K. H. Britten, “General considerations in the design of an all purpose electronic digital computer,” Tech. Rep., 1947.
  * [4] M. Campbell-Kelly, “The development of computer programming in britain (1945 to 1955),” _Annals of the History of Computing_ , vol. 4, no. 2, pp. 121–139, 1982.
  * [5] P. Bentley, _Digitized: The science of computers and how it shapes our world_. New York: Oxford University Press, 2012.
  * [6] D. E. Knuth and L. T. Pardo, “Early development of programming languages,” _A History of Computing in the Twentieth Century_ , 1980.
  * [7] R. R. Carhart, _A Survey of the Current Status of the Electronic Reliability Problem_. Santa Monica, CA: RAND Corporation, 1953.
  * [8] _Symposium on advanced programming methods for digital computers : Washington, D.C., June 28, 29, 1956_. Office of Naval Research, Dept. of the Navy, 1956.
  * [9] C. Larman and V. R. Basili, “Iterative and incremental development: A brief history,” _Computer_ , vol. 36, pp. 47–56, 2003.
  * [10] S. H. Lavington, _A History of Manchester Computers_. British Computer Society, 1998.
  * [11] T. Bardini, _Bootstrapping: Douglas Engelbart, Coevolution, and the Origins of Personal Computing_. Standford CA: Stanford University Press, 2000.
  * [12] W. W. Royce, “Managing the development of large software systems,” in _Technical Papers of Western Electronic Show and Convention_ , 1970.
  * [13] T. E. Bell and T. A. Thayer, “Software requirements: Are they really a problem?” in _Proceedings of the 2nd International Conference on Software Engineering_. Washington, DC, USA: IEEE Computer Society Press, 1976.
  * [14] T. Gilb, _Software Metrics_. Winthrop Publishers, 1976.
  * [15] E. A. Edmonds, “A process for the development of software for nontechnical users as an adaptive system,” _General Systems_ , vol. 19, p. 215–18, 1974\.
  * [16] W. Isaacson, _The Innovators: How a Group of Hackers, Geniuses, and Geeks Created the Digital Revolution_. SIMON and SCHUSTER, 2014.
  * [17] J. L. Pelkey, “The history of computer communications,” April 2022. [Online]. Available: https://historyofcomputercommunications.info/
  * [18] R. Clarke, “Origins and nature of the internet in australia,” _Emergence: Complexity and Organization_ , vol. 4, pp. 1990–1994, 2004.
  * [19] R. H. Zakon, “Hobbes’ internet timeline 25,” April 2022. [Online]. Available: https://www.zakon.org/robert/internet/timeline/
  * [20] “Military standard: Defense system software development by department of defense,” Jun 1985.
  * [21] J. M. Kerr and R. Hunter, _Inside RAD: How to Build a Fully Functional System in 90 Days or Less_. McGraw-Hill, 1993.
  * [22] R. Nagel and R. Dove, _21st Century Manufacturing Enterprise Strategy: An Industry-Led View_. Diane Pub Co, 1991\.
  * [23] A. Presley, J. Mills, and D. Liles, “Agile aerospace manufacturing,” 1995.
  * [24] M. Beedle, A. van Bennekum, and A. Cockburn, “Manifesto for agile software development,” April 2001. [Online]. Available: https://agilemanifesto.org/
  * [25] D. J. Power, “A brief history of decision support systems,” April 2022. [Online]. Available: http://DSSResources.COM/history/dsshistory.html
  * [26] R. Wirth and J. Hipp, “Crisp-dm: Towards a standard process model for data mining,” _Proceedings of the 4th International Conference on the Practical Applications of Knowledge Discovery and Data Mining_ , 2000.
  * [27] IBM, “Crisp-dm help overview,” April 2022. [Online]. Available: https://www.ibm.com/docs/en/spss-modeler/SaaS?topic=dm-crisp-help-overview
  * [28] Microsoft, “Agile development of data science projects,” April 2022. [Online]. Available: https://docs.microsoft.com/en-us/azure/architecture/data-science-process/agile-development
  * [29] “Agile data science by data science process alliance,” April 2022. [Online]. Available: https://www.datascience-pm.com/agile-data-science/
  * [30] I. Lee, “6 reasons why i think agile data science does not work,” April 2022. [Online]. Available: https://towardsdatascience.com/6-reasons-why-i-think-agile-data-science-does-not-work-ee4dd680bb59
  * [31] E. Yan, “Data science and agile (what works, and what doesn’t,” April 2022. [Online]. Available: https://eugeneyan.com/writing/data-science-and-agile-what-works-and-what-doesnt/
  * [32] T. Dyba and T. Dingsøyr, “Empirical studies of agile software development: A systematic review,” _Information and Software Technology_ , vol. 50, no. 9, pp. 833–859, 2008.
  * [33] “Agile 101 by agile alliance,” April 2022. [Online]. Available: https://www.agilealliance.org/agile101/
  * [34] P. Abrahamsson, O. Salo, J. Ronkainen, and J. Warsta, “Agile software development methods: Review and analysis,” 2017.
  * [35] A. L. Fruhling and A. E. Tarrell, “Best practices for implementing agile methods: A guide for department of defense software developers,” _Information Systems and Quantitative Analysis Faculty Publications_ , vol. 27, 2007.
  * [36] K. Popper, _The Logic of Scientific Discovery_. London and New York: Routledge, 2002.
  * [37] S. Braams, “The software development landscape: A rationalization of agile software development as a strategy in the face of organizational complexity,” April 2022. [Online]. Available: http://essay.utwente.nl/80784/
  * [38] S. Forum, “Agile - methodology or framework or philosophy,” April 2022. [Online]. Available: https://www.scrum.org/forum/scrum-forum/6117/agile-methodology-or-framework-or-philosophy
  * [39] T. Schick, _Doing Philosophy: An Introduction Through Thought Experiments_. Mcgraw-Hill, 2009.
  * [40] D. Sculley, G. Holt, D. Golovin, E. Davydov, T. Phillips, D. Ebner, V. Chaudhary, M. Young, J.-F. Crespo, and D. Dennison, “Hidden technical debt in machine learning systems,” in _Advances in Neural Information Processing Systems_ , vol. 28. Curran Associates, Inc., 2015.
  * [41] H. H. Nithya Sambasivan, Shivani Kapania, “"everyone wants to do the model work, not the data work": Data cascades in high-stakes ai,” 2021.
  * [42] T. J. Sebastian Schelter, Felix Biessmann, “On challenges in machine learning model management,” _IEEE Data Eng. Bull._ , 2018.
  * [43] F. Kumeno, “Sofware engneering challenges for machine learning applications: A literature review,” _Intelligent Decision Technologies, vol. 13, no. 4, pp._ , vol. 13, no. 4, pp. 463–476, 2019.
  * [44] “Python,” April 2022. [Online]. Available: https://www.python.org/
  * [45] “Ubuntu,” April 2022. [Online]. Available: https://ubuntu.com/
  * [46] D. L. Sackett, “Evidence-based medicine,” _Seminars in Perinatology_ , vol. 21, no. 1, pp. 3–5, 1997.
  * [47] S. Spear and T. Hone, “Succeeding in periods of change,” _Proceedings U.S. Naval Institute_ , March 2022.
  * [48] LessWrong, “Welcome to lesswrong!” April 2022. [Online]. Available: https://www.lesswrong.com/posts/bJ2haLkcGeLtTWaD5/welcome-to-lesswrong
  * [49] E. M. Rogers, _Diffusion of innovations_ , 5th ed. New York, NY: Free Press, 2003.
  * [50] E. F. Codd, “A relational model of data for large shared data banks,” _Commun. ACM_ , vol. 13, no. 6, p. 377–387, jun 1970.
  * [51] Git, “Git internals - git objects,” April 2022. [Online]. Available: https://book.git-scm.com/book/en/v2/Git-Internals-Git-Objects

## Checklist

The checklist follows the references. Please read the checklist guidelines
carefully for information on how to answer these questions. For each question,
change the default [TODO] to [Yes] , [No] , or [N/A] . You are strongly
encouraged to include a justification to your answer, either by referencing
the appropriate section of your paper or providing a brief inline description.
For example:

  * •

Did you include the license to the code and datasets? [Yes] See Section
LABEL:gen_inst.

  * •

Did you include the license to the code and datasets? [No] The code and the
data are proprietary.

  * •

Did you include the license to the code and datasets? [N/A]

Please do not modify the questions and only use the provided macros for your
answers. Note that the Checklist section does not count towards the page
limit. In your paper, please delete this instructions block and only keep the
Checklist section heading above along with the questions/answers below.

  1. 1.

For all authors…

    1. (a)

Do the main claims made in the abstract and introduction accurately reflect
the paper’s contributions and scope? [Yes]

    2. (b)

Did you describe the limitations of your work? [Yes]

    3. (c)

Did you discuss any potential negative societal impacts of your work? [Yes]

    4. (d)

Have you read the ethics review guidelines and ensured that your paper
conforms to them? [Yes]

  2. 2.

If you are including theoretical results…

    1. (a)

Did you state the full set of assumptions of all theoretical results? [Yes]

    2. (b)

Did you include complete proofs of all theoretical results? [Yes]

  3. 3.

If you ran experiments…

    1. (a)

Did you include the code, data, and instructions needed to reproduce the main
experimental results (either in the supplemental material or as a URL)? [N/A]

    2. (b)

Did you specify all the training details (e.g., data splits, hyperparameters,
how they were chosen)? [N/A]

    3. (c)

Did you report error bars (e.g., with respect to the random seed after running
experiments multiple times)? [N/A]

    4. (d)

Did you include the total amount of compute and the type of resources used
(e.g., type of GPUs, internal cluster, or cloud provider)? [N/A]

  4. 4.

If you are using existing assets (e.g., code, data, models) or
curating/releasing new assets…

    1. (a)

If your work uses existing assets, did you cite the creators? [N/A]

    2. (b)

Did you mention the license of the assets? [N/A]

    3. (c)

Did you include any new assets either in the supplemental material or as a
URL? [N/A]

    4. (d)

Did you discuss whether and how consent was obtained from people whose data
you’re using/curating? [N/A]

    5. (e)

Did you discuss whether the data you are using/curating contains personally
identifiable information or offensive content? [N/A]

  5. 5.

If you used crowdsourcing or conducted research with human subjects…

    1. (a)

Did you include the full text of instructions given to participants and
screenshots, if applicable? [N/A]

    2. (b)

Did you describe any potential participant risks, with links to Institutional
Review Board (IRB) approvals, if applicable? [N/A]

    3. (c)

Did you include the estimated hourly wage paid to participants and the total
amount spent on participant compensation? [N/A]


# An open charm tetraquark candidate: note on $X_{0}(2900)$

Jian-Rong Zhang  Department of Physics, College of Liberal Arts and Sciences,
National University of Defense Technology, Changsha 410073, Hunan, People’s
Republic of China

###### Abstract

Motivated by the LHCb’s very recent observation of exotic $X_{0}(2900)$ in the
$B^{+}\rightarrow D^{+}D^{-}K^{+}$ process, for which could be a good open
charm $ud\bar{c}\bar{s}$ tetraquark candidate, we endeavor to investigate its
possibility by means of QCD sum rules. In technique, four configurations of
interpolating currents with $J^{P}=0^{+}$ are studied for the
$ud\bar{c}\bar{s}$ tetraquark state. In the end, mass values are calculated to
be $2.76^{+0.16}_{-0.23}~{}\mbox{GeV}$ for the axial vector diquark-axial
vector antidiquark configuration and $2.75^{+0.15}_{-0.24}~{}\mbox{GeV}$ for
the scalar diquark-scalar antidiquark configuration, both of which are
consistent with the experimental data $2.866\pm 0.007\pm 0.002~{}\mbox{GeV}$
of $X_{0}(2900)$ in view of the uncertainty. These results support that
$X_{0}(2900)$ could be a $0^{+}$ tetraquark state with open charm flavor.

###### pacs:

11.55.Hx, 12.38.Lg, 12.39.Mk

##  I Introduction

In the past decades, the so-called $X$, $Y$, and $Z$ new hadrons have
attracted wide attentions and some of them were assigned to be possible exotic
states (for recent reviews e.g. see Th-rev ; Th-rev1 ; Th-rev2  and references
therein). For example, some prediction was made on a $0^{+}$ bound state with
a pole mass of $2848~{}\mbox{MeV}$ via coupled-channel unitarity Oset . Very
recently, the LHCb Collaboration reported the first amplitude analysis of the
$B^{+}\rightarrow D^{+}D^{-}K^{+}$ decay and included two new exotic
structures in the $D^{-}K^{+}$ channel with an overwhelming significance X2900
. Particularly for the spin-$0$ resonance $X_{0}(2900)$, its mass and width
were measured to be $2.866\pm 0.007\pm 0.002~{}\mbox{GeV}$ and $57\pm 12\pm
4~{}\mbox{MeV}$, respectively. Taking notice of its decay final states being
$D^{-}K^{+}$, $X_{0}(2900)$ was proposed to be a nice open charm tetraquark
candidate Th .

Activated by the LHCb’s new experimental result on $X_{0}(2900)$, we attempt
to study its possibility to be an open charm $ud\bar{c}\bar{s}$ tetraquark
state. To research into a genuine hadron, one has to face the very complicated
nonperturbative QCD problem. As one trustable approach for evaluating
nonperturbative effects, the QCD sum rule svzsum  is firmly established on QCD
basic theory and has been successfully applied to numerous hadronic systems
overview1 ; overview2 ; overview3 ; reinders ; overview4 . For instance, the
charm-strange $D_{s0}^{*}(2317)$ was explored in a tetraquark picture with QCD
sum rules tetra1 ; tetra2 ; tetra3-heavy-limit ; tetra3-Narison ; tetra3 ;
tetra4 ; tetra5 . In this work, to uncover the internal structure of
$X_{0}(2900)$, we devote to investigating that whether it could be an open
charm $ud\bar{c}\bar{s}$ tetraquark state by QCD sum rules.

The rest of the paper is organized as follows. In Sec. II, $X_{0}(2900)$ is
studied as a tetraquark state via QCD sum rules, followed by numerical
analysis and discussions in Sec. III. The last part gives a concise summary.

##  II QCD sum rule study of $X_{0}(2900)$ as a $0^{+}$ $ud\bar{c}\bar{s}$
tetraquark state

Complying with the usual treatment of QCD sum rules, a tetraquark state can be
represented by an interpolating current with the diquark-antidiquark
configuration (e.g. see the review overview4  and references therein).
Particularly for the present $0^{+}$ $ud\bar{c}\bar{s}$ tetraquark state, one
can construct its different configuration currents with $0^{+}$ composed of an
$ud$-diquark and a $\bar{c}\bar{s}$-antidiquark, taking into account that
$u_{a}^{T}C\gamma_{5}d_{b}$ as a $0^{+}$ scalar diquark, $u_{a}^{T}Cd_{b}$ as
a $0^{-}$ pseudoscalar diquark, $u_{a}^{T}C\gamma_{\mu}d_{b}$ as a $1^{+}$
axial vector diquark, $u_{a}^{T}C\gamma_{5}\gamma_{\mu}d_{b}$ as a $1^{-}$
vector diquark, and likewise for the $\bar{c}\bar{s}$-antidiquark. In this
manner, following forms of currents are presented for the $0^{+}$
$ud\bar{c}\bar{s}$ tetraquark state, with

$\displaystyle
j_{(1)}=\epsilon_{abg}\epsilon_{a^{\prime}b^{\prime}g}(u_{a}^{T}C\gamma_{5}d_{b})(\bar{c}_{a^{\prime}}\gamma_{5}C\bar{s}_{b^{\prime}}^{T})$
(1)

for the scalar diquark-scalar antidiquark configuration,

$\displaystyle j_{(2)}$ $\displaystyle=$
$\displaystyle\epsilon_{abg}\epsilon_{a^{\prime}b^{\prime}g}(u_{a}^{T}Cd_{b})(\bar{c}_{a^{\prime}}C\bar{s}_{b^{\prime}}^{T})$
(2)

for the pseudoscalar diquark-pseudoscalar antidiquark configuration,

$\displaystyle j_{(3)}$ $\displaystyle=$
$\displaystyle\epsilon_{abg}\epsilon_{a^{\prime}b^{\prime}g}(u_{a}^{T}C\gamma_{\mu}d_{b})(\bar{c}_{a^{\prime}}\gamma^{\mu}C\bar{s}_{b^{\prime}}^{T})$
(3)

for the axial vector diquark-axial vector antidiquark configuration, and

$\displaystyle j_{(4)}$ $\displaystyle=$
$\displaystyle\epsilon_{abg}\epsilon_{a^{\prime}b^{\prime}g}(u_{a}^{T}C\gamma_{5}\gamma_{\mu}d_{b})(\bar{c}_{a^{\prime}}\gamma^{\mu}\gamma_{5}C\bar{s}_{b^{\prime}}^{T})$
(4)

for the vector diquark-vector antidiquark configuration. Here $T$ indicates
matrix transposition, $C$ is the charge conjugation matrix, and the subscripts
$a$, $b$, $g$, $a^{\prime}$, and $b^{\prime}$ are color indices.

Besides, one can construct some other current, such as

$\displaystyle j_{(5)}$ $\displaystyle=$
$\displaystyle\epsilon_{abg}\epsilon_{a^{\prime}b^{\prime}g}(u_{a}^{T}C\sigma_{\mu\nu}d_{b})(\bar{c}_{a^{\prime}}\sigma^{\mu\nu}C\bar{s}_{b^{\prime}}^{T}).$
(5)

Meanwhile, one could consider that the corresponding diquark and antidiquark
are higher excitation and they are comparatively difficult to be stably
formed. Then the concrete calculations for this current are not involved here,
for which could be taken into account in some further work.

On the one hand, the two-point correlator

$\displaystyle\Pi_{i}(q^{2})=i\int d^{4}x\mbox{e}^{iq.x}\langle
0|T[j_{(i)}(x)j_{(i)}^{{\dagger}}(0)]|0\rangle,~{}(i=1,~{}2,~{}3,~{}\mbox{or}~{}4)$
(6)

can be phenomenologically expressed as

$\displaystyle\Pi_{i}(q^{2})=\frac{\lambda_{H}^{2}}{M_{H}^{2}-q^{2}}+\frac{1}{\pi}\int_{s_{0}}^{\infty}\frac{\mbox{Im}\big{[}\Pi_{i}^{\mbox{phen}}(s)\big{]}}{s-q^{2}}ds,$
(7)

where $s_{0}$ is the continuum threshold, $M_{H}$ is the hadron’s mass, and
$\lambda_{H}$ denotes the hadronic coupling constant $\langle
0|j|H\rangle=\lambda_{H}$.

On the other hand, $\Pi_{i}(q^{2})$ can be theoretically formalized as

$\displaystyle\Pi_{i}(q^{2})=\int_{(m_{c}+m_{s})^{2}}^{\infty}\frac{\rho_{i}}{s-q^{2}}ds+\Pi_{i}^{\mbox{cond}}(q^{2}),$
(8)

in which $m_{c}$ is the charm mass, $m_{s}$ is the strange mass, and the
spectral density $\rho_{i}=\frac{1}{\pi}\mbox{Im}\big{[}\Pi_{i}(s)\big{]}$.

Matching the two equations (7) and (8), assuming quark-hadron duality, and
making a Borel transform $\hat{B}$, the sum rule can be written as

$\displaystyle\lambda_{H}^{2}e^{-M_{H}^{2}/M^{2}}$ $\displaystyle=$
$\displaystyle\int_{(m_{c}+m_{s})^{2}}^{s_{0}}\rho_{i}e^{-s/M^{2}}ds+\hat{B}\Pi_{i}^{\mbox{cond}},$
(9)

with the Borel parameter $M^{2}$.

Taking the derivative of the sum rule (9) with $-\frac{1}{M^{2}}$ and then
dividing the result by (9) itself, one can get the hadronic mass

$\displaystyle
M_{H}=\sqrt{\bigg{[}\int_{(m_{c}+m_{s})^{2}}^{s_{0}}\rho_{i}se^{-s/M^{2}}ds+\frac{d\big{(}\hat{B}\Pi_{i}^{\mbox{cond}}\big{)}}{d(-\frac{1}{M^{2}})}\bigg{]}/\bigg{[}\int_{(m_{c}+m_{s})^{2}}^{s_{0}}\rho_{i}e^{-s/M^{2}}ds+\hat{B}\Pi_{i}^{\mbox{cond}}\bigg{]}},$
(10)

for which the spectral density $\rho_{i}$ and the term
$\hat{B}\Pi_{i}^{\mbox{cond}}$ can be derived making use of the similar
techniques as Refs. tetra1 ; tetra2 ; overview4 ; Zhang , and for concision
their expressions are wholly enclosed in the Appendix A.

One could note that there is not the $\langle\bar{q}q\rangle$ or $\langle
g\bar{q}\sigma\cdot Gq\rangle$ condensate in this work, which is mainly
resulted from two aspects of reasons. On the one hand, both light $u$ and $d$
quark masses are so small comparing with the heavy charm mass that light quark
masses have been safely neglected, and thus there does not appear the
$\langle\bar{q}q\rangle$ or $\langle g\bar{q}\sigma\cdot Gq\rangle$ term
proportional to $m_{u}$ or $m_{d}$. On the other hand, the
$\langle\bar{q}q\rangle$ or $\langle g\bar{q}\sigma\cdot Gq\rangle$ term
without $m_{u}$ or $m_{d}$ vanishes owing to that its corresponding matrix
trace happens to be zero. In this way, the spectral density $\rho$ does not
contain the $\langle\bar{q}q\rangle$ or $\langle g\bar{q}\sigma\cdot
Gq\rangle$ condensate.

##  III numerical analysis and discussions

To extract the mass $M_{H}$, one can carry out the numerical analysis of sum
rule (10), with the aid of input parameters $\langle\bar{q}q\rangle=-(0.24\pm
0.01)^{3}~{}\mbox{GeV}^{3}$, $\langle g\bar{q}\sigma\cdot
Gq\rangle=m_{0}^{2}~{}\langle\bar{q}q\rangle$,
$\langle\bar{s}s\rangle=m_{0}^{2}~{}\langle\bar{q}q\rangle$, $\langle
g\bar{s}\sigma\cdot Gs\rangle=m_{0}^{2}~{}\langle\bar{s}s\rangle$,
$m_{0}^{2}=0.8\pm 0.1~{}\mbox{GeV}^{2}$, $\langle g^{2}G^{2}\rangle=0.88\pm
0.25~{}\mbox{GeV}^{4}$, and $\langle g^{3}G^{3}\rangle=0.58\pm
0.18~{}\mbox{GeV}^{6}$ svzsum ; overview2 . Besides, quark masses are taken as
$m_{c}=1.27\pm 0.02~{}\mbox{GeV}$ and $m_{s}=93^{+11}_{-5}~{}\mbox{MeV}$ PDG ,
respectively. Keeping to the procedure of sum rule analysis, both the OPE
convergence and pole dominance should be inspected to find suitable work
windows for the threshold $\sqrt{s_{0}}$ and the Borel parameter $M^{2}$.

Taking the axial vector diquark-axial vector antidiquark case as an example,
its various relative OPE contributions are compared in FIG. 1, which displays
that there are three main condensate contributions, i.e. the two-quark
condensate $\langle\bar{s}s\rangle$, the mixed condensate
$\langle\bar{s}g\sigma\cdot Gs\rangle$, and the four-quark condensate
$\langle\bar{q}q\rangle^{2}$. Comparatively, one could note that the
$\langle\bar{q}q\rangle^{2}$ contribution is bigger than the lower dimension
condensate like $\langle\bar{s}s\rangle$ or $\langle\bar{s}g\sigma\cdot
Gs\rangle$. Frankly speaking, this is a common problem existing in some
multiquark QCD sum rule studies but not newly arisen, for which has already
been discussed in some other works P-Matheus ; P-Chen ; P-Wang ; P-Zhang .
Namely, some individual high dimension condensate (e.g. the
$\langle\bar{q}q\rangle^{2}$ here) plays an important role on the OPE side,
which causes that it is not easy to satisfy the traditional condition for
conventional hadrons that low dimension condensate should be bigger than high
dimension one in the OPE. Acceptably, these main condensate contributions can
fortunately counteract each other to some extent. One might note that the
$\langle\bar{q}q\rangle^{2}\langle\bar{s}s\rangle$ condensate is not small at
$M^{2}=1~{}\mbox{GeV}^{2}$, however, it descends rapidly with the increase of
$M^{2}$ and becomes very small while taking $M^{2}\geq 2.0~{}\mbox{GeV}^{2}$.
All these factors bring that the lowest dimension perturbative part can play
an important role on the total OPE when $M^{2}\geq 2.0~{}\mbox{GeV}^{2}$ and
the corresponding OPE convergence is still under control in the work windows.

In phenomenology, FIG. 2 shows the comparison between pole contribution and
continuum contribution of sum rule (9) for $\sqrt{s_{0}}=3.4~{}\mbox{GeV}$,
which manifests that the relative pole contribution is close to $50\%$ at
$M^{2}=2.2~{}\mbox{GeV}^{2}$ and decreases with $M^{2}$. Thereby, the upper
bound of $M^{2}$ is chosen as $2.2~{}\mbox{GeV}^{2}$ for
$\sqrt{s_{0}}=3.4~{}\mbox{GeV}$. Similarly, the upper values of $M^{2}$ can
also be achieved for $\sqrt{s_{0}}=3.3~{}\mbox{GeV}$ and
$\sqrt{s_{0}}=3.5~{}\mbox{GeV}$. Accordingly, work windows for the axial
vector diquark-axial vector antidiquark case are fixed as $M^{2}=2.0\sim
2.1~{}\mbox{GeV}^{2}$ for $\sqrt{s_{0}}=3.3~{}\mbox{GeV}$, $M^{2}=2.0\sim
2.2~{}\mbox{GeV}^{2}$ for $\sqrt{s_{0}}=3.4~{}\mbox{GeV}$, and $M^{2}=2.0\sim
2.3~{}\mbox{GeV}^{2}$ for $\sqrt{s_{0}}=3.5~{}\mbox{GeV}$, respectively. In
FIG. 3, the mass $M_{H}$ as a function of $M^{2}$ from sum rule (10) is shown
for the axial vector diquark-axial vector antidiquark case. Within the chosen
work windows, it may seem not very flat for the Borel curves. As one knows, in
the choice of work windows, the flatness of Borel curves is an important
factor under consideration. Meanwhile, it should not be the only judgement. In
fact, the Borel curves can look much flatter if one naively chooses Borel
windows with some larger $M^{2}$ here. However, the hypothesis of pole
dominance in the phenomenological side of QCD sum rules would be severely
broken if overly paying attention to the flatness of Borel curves. In
practice, the procedure of finding work windows has actually been developed
from the traditional way of mainly observing that wether there is some flat
Borel plateau to the present-day way of choosing suitable work windows
fulfilling both the OPE convergence and pole dominance, to ensure that two
sides of QCD sum rules have a good overlap and information on the hadronic
resonance can be reliably extracted. Moreover, the variation of mass with
Borel parameter $M^{2}$ in the Borel curve can be numerically embodied by the
uncertainty of final result. After considering the uncertainty from the
variation of QCD parameters, one gains the final mass
$2.76^{+0.16}_{-0.23}~{}\mbox{GeV}$ for the axial vector diquark-axial vector
antidiquark case.

Figure 1: The relative contributions of various condensates as a function of
$M^{2}$ in sum rule (9) for $\sqrt{s_{0}}=3.4~{}\mbox{GeV}$ for the axial
vector diquark-axial vector antidiquark case.

Figure 2: The phenomenological contribution as a function of $M^{2}$ in sum
rule (9) for $\sqrt{s_{0}}=3.4~{}\mbox{GeV}$ for the axial vector diquark-
axial vector antidiquark case. The solid line is the relative pole
contribution and the dashed line is the relative continuum contribution.

Figure 3:  The mass of $0^{+}$ $ud\bar{c}\bar{s}$ tetraquark state with the
axial vector diquark-axial vector antidiquark configuration as a function of
$M^{2}$ from sum rule (10). The ranges of $M^{2}$ are taken as $2.0\sim
2.1~{}\mbox{GeV}^{2}$ for $\sqrt{s_{0}}=3.3~{}\mbox{GeV}$, $2.0\sim
2.2~{}\mbox{GeV}^{2}$ for $\sqrt{s_{0}}=3.4~{}\mbox{GeV}$, and $2.0\sim
2.3~{}\mbox{GeV}^{2}$ for $\sqrt{s_{0}}=3.5~{}\mbox{GeV}$, respectively.

For the scalar diquark-scalar antidiquark case, through the similar procedure,
its Borel windows are determined to be $2.0\sim 2.2~{}\mbox{GeV}^{2}$ for
$\sqrt{s_{0}}=3.3~{}\mbox{GeV}$, $2.0\sim 2.3~{}\mbox{GeV}^{2}$ for
$\sqrt{s_{0}}=3.4~{}\mbox{GeV}$, and $2.0\sim 2.4~{}\mbox{GeV}^{2}$ for
$\sqrt{s_{0}}=3.5~{}\mbox{GeV}$, respectively. Furthermore, its mass $M_{H}$
dependence on $M^{2}$ from sum rule (10) is shown in FIG. 4. Including the
uncertainty due to QCD parameters, the mass for the scalar diquark-scalar
antidiquark configuration is calculated to be
$2.75^{+0.15}_{-0.24}~{}\mbox{GeV}$ at last.

Figure 4:  The mass of $0^{+}$ $ud\bar{c}\bar{s}$ tetraquark state with the
scalar diquark-scalar antidiquark configuration as a function of $M^{2}$ from
sum rule (10). The ranges of $M^{2}$ are taken as $2.0\sim
2.2~{}\mbox{GeV}^{2}$ for $\sqrt{s_{0}}=3.3~{}\mbox{GeV}$, $2.0\sim
2.3~{}\mbox{GeV}^{2}$ for $\sqrt{s_{0}}=3.4~{}\mbox{GeV}$, and $2.0\sim
2.4~{}\mbox{GeV}^{2}$ for $\sqrt{s_{0}}=3.5~{}\mbox{GeV}$, respectively.

After similar analysis, it is noted that the OPE convergence for the
pseudoscalar diquark-pseudoscalar antidiquark and the vector diquark-vector
antidiquark cases is so unsatisfactory that one cannot find any appropriate
work windows for them and it is not advisable to continue extracting their
mass results. Anyway, the final results for the axial vector diquark-axial
vector antidiquark and the scalar diquark-scalar antidiquark cases both agree
with the experimental data of $X_{0}(2900)$ viewing the uncertainty of final
results, which supports that $X_{0}(2900)$ could be a $0^{+}$
$ud\bar{c}\bar{s}$ tetraquark state with the axial vector diquark-axial vector
antidiquark or the scalar diquark-scalar antidiquark configuration.

##  IV Summary

Stimulated by the new observation of exotic $X_{0}(2900)$, we explore the
possibility of $X_{0}(2900)$ as an open charm $ud\bar{c}\bar{s}$ tetraquark
state with $J^{P}=0^{+}$ in the framework of QCD sum rules. Finally, the mass
values are computed to be $2.76^{+0.16}_{-0.23}~{}\mbox{GeV}$ for the axial
vector diquark-axial vector antidiquark configuration, and
$2.75^{+0.15}_{-0.24}~{}\mbox{GeV}$ for the scalar diquark-scalar antidiquark
configuration, respectively. Considering the uncertainty of these results,
they are both in agreement with the experimental data of $X_{0}(2900)$. It
supports that $X_{0}(2900)$ could be interpreted as a $0^{+}$
$ud\bar{c}\bar{s}$ tetraquark state, whose configuration could be either the
axial vector diquark-axial vector antidiquark or the scalar diquark-scalar
antidiquark. In future, it is expected that further experimental observations
and theoretical efforts could disclose more information on the nature of
$X_{0}(2900)$.

###### Acknowledgements.

This work was supported by the National Natural Science Foundation of China
under Contract Nos. 11475258 and 11675263, and by the project for excellent
youth talents in NUDT.

## Appendix A

The spectral density
$\rho_{i}=\rho_{i}^{\mbox{pert}}+\rho_{i}^{\langle\bar{s}s\rangle}+\rho_{i}^{\langle
g^{2}G^{2}\rangle}+\rho_{i}^{\langle g\bar{s}\sigma\cdot
Gs\rangle}+\rho_{i}^{\langle\bar{q}q\rangle^{2}}+\rho_{i}^{\langle
g^{3}G^{3}\rangle}+\rho_{i}^{\langle\bar{s}s\rangle\langle g^{2}G^{2}\rangle}$
and the term $\hat{B}\Pi_{i}^{\mbox{cond}}$ are collected below, with

$\displaystyle\rho_{1}^{\mbox{pert}}$ $\displaystyle=$
$\displaystyle\frac{1}{3\cdot
2^{10}\pi^{6}}\int_{\Lambda}^{1}d\alpha\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{3}(\alpha
s-m_{c}^{2}+4m_{s}m_{c})(\alpha s-m_{c}^{2})^{3},$ (11)
$\displaystyle\rho_{1}^{\langle\bar{s}s\rangle}$ $\displaystyle=$
$\displaystyle-\frac{\langle\bar{s}s\rangle}{2^{6}\pi^{4}}\int_{\Lambda}^{1}d\alpha\frac{1-\alpha}{\alpha^{2}}[(1-\alpha)m_{c}-\alpha
m_{s}](\alpha s-m_{c}^{2})^{2},$ (12) $\displaystyle\rho_{1}^{\langle
g^{2}G^{2}\rangle}$ $\displaystyle=$ $\displaystyle-\frac{m_{c}\langle
g^{2}G^{2}\rangle}{3^{2}\cdot
2^{10}\pi^{6}}\int_{\Lambda}^{1}d\alpha\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{3}[(m_{c}-3m_{s})(\alpha
s-m_{c}^{2})+m_{s}m_{c}^{2}],$ (13) $\displaystyle\rho_{1}^{\langle
g\bar{s}\sigma\cdot Gs\rangle}$ $\displaystyle=$ $\displaystyle\frac{\langle
g\bar{s}\sigma\cdot Gs\rangle}{3\cdot
2^{6}\pi^{4}}\int_{\Lambda}^{1}\frac{d\alpha}{\alpha}[3(1-\alpha)m_{c}-\alpha
m_{s}](\alpha s-m_{c}^{2}),$ (14)
$\displaystyle\rho_{1}^{\langle\bar{q}q\rangle^{2}}$ $\displaystyle=$
$\displaystyle\frac{\langle\bar{q}q\rangle^{2}}{3\cdot
2^{2}\pi^{2}}\int_{\Lambda}^{1}d\alpha[(\alpha s-m_{c}^{2})+m_{s}m_{c}],$ (15)
$\displaystyle\rho_{1}^{\langle g^{3}G^{3}\rangle}$ $\displaystyle=$
$\displaystyle-\frac{\langle g^{3}G^{3}\rangle}{3^{2}\cdot
2^{12}\pi^{6}}\int_{\Lambda}^{1}d\alpha\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{3}(\alpha
s-3m_{c}^{2}+6m_{s}m_{c}),$ (16)
$\displaystyle\rho_{1}^{\langle\bar{s}s\rangle\langle g^{2}G^{2}\rangle}$
$\displaystyle=$ $\displaystyle-\frac{m_{c}\langle\bar{s}s\rangle\langle
g^{2}G^{2}\rangle}{3^{2}\cdot
2^{8}\pi^{4}}\int_{\Lambda}^{1}d\alpha\bigg{[}1+3\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{2}\bigg{]},$
(17) $\displaystyle\hat{B}\Pi_{1}^{\mbox{cond}}$ $\displaystyle=$
$\displaystyle-\frac{m_{s}m_{Q}\langle\bar{q}q\rangle\langle
g\bar{q}\sigma\cdot Gq\rangle}{3\cdot 2^{3}\pi^{2}}e^{-m_{Q}^{2}/M^{2}}$ (18)
$\displaystyle-$
$\displaystyle\frac{\langle\bar{q}q\rangle^{2}\langle\bar{s}s\rangle}{2\cdot
3^{2}}\bigg{(}2m_{Q}-m_{s}-\frac{m_{s}m_{Q}^{2}}{M^{2}}\bigg{)}e^{-m_{Q}^{2}/M^{2}}$
$\displaystyle+$ $\displaystyle\frac{\langle g\bar{q}\sigma\cdot
Gq\rangle^{2}}{3\cdot
2^{6}\pi^{2}}\bigg{[}1+\frac{m_{Q}^{2}}{M^{2}}+\frac{m_{s}m_{Q}^{3}}{(M^{2})^{2}}\bigg{]}e^{-m_{Q}^{2}/M^{2}},$

for the scalar diquark-scalar antidiquark case,

$\displaystyle\rho_{2}^{\mbox{pert}}$ $\displaystyle=$
$\displaystyle\frac{1}{3\cdot
2^{10}\pi^{6}}\int_{\Lambda}^{1}d\alpha\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{3}(\alpha
s-m_{c}^{2}-4m_{s}m_{c})(\alpha s-m_{c}^{2})^{3},$ (19)
$\displaystyle\rho_{2}^{\langle\bar{s}s\rangle}$ $\displaystyle=$
$\displaystyle\frac{\langle\bar{s}s\rangle}{2^{6}\pi^{4}}\int_{\Lambda}^{1}d\alpha\frac{1-\alpha}{\alpha^{2}}[(1-\alpha)m_{c}+\alpha
m_{s}](\alpha s-m_{c}^{2})^{2},$ (20) $\displaystyle\rho_{2}^{\langle
g^{2}G^{2}\rangle}$ $\displaystyle=$ $\displaystyle-\frac{m_{c}\langle
g^{2}G^{2}\rangle}{3^{2}\cdot
2^{10}\pi^{6}}\int_{\Lambda}^{1}d\alpha\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{3}[(m_{c}+3m_{s})(\alpha
s-m_{c}^{2})-m_{s}m_{c}^{2}],$ (21) $\displaystyle\rho_{2}^{\langle
g\bar{s}\sigma\cdot Gs\rangle}$ $\displaystyle=$ $\displaystyle-\frac{\langle
g\bar{s}\sigma\cdot Gs\rangle}{3\cdot
2^{6}\pi^{4}}\int_{\Lambda}^{1}\frac{d\alpha}{\alpha}[3(1-\alpha)m_{c}+\alpha
m_{s}](\alpha s-m_{c}^{2}),$ (22)
$\displaystyle\rho_{2}^{\langle\bar{q}q\rangle^{2}}$ $\displaystyle=$
$\displaystyle\frac{\langle\bar{q}q\rangle^{2}}{3\cdot
2^{2}\pi^{2}}\int_{\Lambda}^{1}d\alpha[-(\alpha s-m_{c}^{2})+m_{s}m_{c}],$
(23) $\displaystyle\rho_{2}^{\langle g^{3}G^{3}\rangle}$ $\displaystyle=$
$\displaystyle-\frac{\langle g^{3}G^{3}\rangle}{3^{2}\cdot
2^{12}\pi^{6}}\int_{\Lambda}^{1}d\alpha\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{3}(\alpha
s-3m_{c}^{2}-6m_{s}m_{c}),$ (24)
$\displaystyle\rho_{2}^{\langle\bar{s}s\rangle\langle g^{2}G^{2}\rangle}$
$\displaystyle=$ $\displaystyle\frac{m_{c}\langle\bar{s}s\rangle\langle
g^{2}G^{2}\rangle}{3^{2}\cdot
2^{8}\pi^{4}}\int_{\Lambda}^{1}d\alpha\bigg{[}1+3\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{2}\bigg{]},$
(25) $\displaystyle\hat{B}\Pi_{2}^{\mbox{cond}}$ $\displaystyle=$
$\displaystyle-\frac{m_{s}m_{Q}\langle\bar{q}q\rangle\langle
g\bar{q}\sigma\cdot Gq\rangle}{3\cdot 2^{3}\pi^{2}}e^{-m_{Q}^{2}/M^{2}}$ (26)
$\displaystyle-$
$\displaystyle\frac{\langle\bar{q}q\rangle^{2}\langle\bar{s}s\rangle}{2\cdot
3^{2}}\bigg{(}2m_{Q}+m_{s}+\frac{m_{s}m_{Q}^{2}}{M^{2}}\bigg{)}e^{-m_{Q}^{2}/M^{2}}$
$\displaystyle+$ $\displaystyle\frac{\langle g\bar{q}\sigma\cdot
Gq\rangle^{2}}{3\cdot
2^{6}\pi^{2}}\bigg{[}-1-\frac{m_{Q}^{2}}{M^{2}}+\frac{m_{s}m_{Q}^{3}}{(M^{2})^{2}}\bigg{]}e^{-m_{Q}^{2}/M^{2}},$

for the pseudoscalar diquark-pseudoscalar antidiquark case,

$\displaystyle\rho_{3}^{\mbox{pert}}$ $\displaystyle=$
$\displaystyle\frac{1}{3\cdot
2^{8}\pi^{6}}\int_{\Lambda}^{1}d\alpha\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{3}(\alpha
s-m_{c}^{2}+2m_{s}m_{c})(\alpha s-m_{c}^{2})^{3},$ (27)
$\displaystyle\rho_{3}^{\langle\bar{s}s\rangle}$ $\displaystyle=$
$\displaystyle-\frac{\langle\bar{s}s\rangle}{2^{5}\pi^{4}}\int_{\Lambda}^{1}d\alpha\frac{1-\alpha}{\alpha^{2}}[(1-\alpha)m_{c}-2\alpha
m_{s}](\alpha s-m_{c}^{2})^{2},$ (28) $\displaystyle\rho_{3}^{\langle
g^{2}G^{2}\rangle}$ $\displaystyle=$ $\displaystyle-\frac{m_{c}\langle
g^{2}G^{2}\rangle}{3^{2}\cdot
2^{9}\pi^{6}}\int_{\Lambda}^{1}d\alpha\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{3}[(2m_{c}-3m_{s})(\alpha
s-m_{c}^{2})+m_{s}m_{c}^{2}],$ (29) $\displaystyle\rho_{3}^{\langle
g\bar{s}\sigma\cdot Gs\rangle}$ $\displaystyle=$ $\displaystyle\frac{\langle
g\bar{s}\sigma\cdot Gs\rangle}{3\cdot
2^{5}\pi^{4}}\int_{\Lambda}^{1}\frac{d\alpha}{\alpha}[3(1-\alpha)m_{c}-2\alpha
m_{s}](\alpha s-m_{c}^{2}),$ (30)
$\displaystyle\rho_{3}^{\langle\bar{q}q\rangle^{2}}$ $\displaystyle=$
$\displaystyle\frac{\langle\bar{q}q\rangle^{2}}{3\cdot
2\pi^{2}}\int_{\Lambda}^{1}d\alpha[(\alpha s-m_{c}^{2})+2m_{s}m_{c}],$ (31)
$\displaystyle\rho_{3}^{\langle g^{3}G^{3}\rangle}$ $\displaystyle=$
$\displaystyle-\frac{\langle g^{3}G^{3}\rangle}{3^{2}\cdot
2^{10}\pi^{6}}\int_{\Lambda}^{1}d\alpha\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{3}(\alpha
s-3m_{c}^{2}+3m_{s}m_{c}),$ (32)
$\displaystyle\rho_{3}^{\langle\bar{s}s\rangle\langle g^{2}G^{2}\rangle}$
$\displaystyle=$ $\displaystyle-\frac{m_{c}\langle\bar{s}s\rangle\langle
g^{2}G^{2}\rangle}{3^{2}\cdot
2^{7}\pi^{4}}\int_{\Lambda}^{1}d\alpha\bigg{[}1+3\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{2}\bigg{]},$
(33) $\displaystyle\hat{B}\Pi_{3}^{\mbox{cond}}$ $\displaystyle=$
$\displaystyle-\frac{m_{s}m_{Q}\langle\bar{q}q\rangle\langle
g\bar{q}\sigma\cdot Gq\rangle}{3\cdot 2\pi^{2}}e^{-m_{Q}^{2}/M^{2}}$ (34)
$\displaystyle-$
$\displaystyle\frac{\langle\bar{q}q\rangle^{2}\langle\bar{s}s\rangle}{3^{2}}\bigg{(}4m_{Q}-m_{s}-\frac{m_{s}m_{Q}^{2}}{M^{2}}\bigg{)}e^{-m_{Q}^{2}/M^{2}}$
$\displaystyle+$ $\displaystyle\frac{\langle g\bar{q}\sigma\cdot
Gq\rangle^{2}}{3\cdot
2^{5}\pi^{2}}\bigg{[}1+\frac{m_{Q}^{2}}{M^{2}}+2\frac{m_{s}m_{Q}^{3}}{(M^{2})^{2}}\bigg{]}e^{-m_{Q}^{2}/M^{2}},$

for the axial vector diquark-axial vector antidiquark case, and

$\displaystyle\rho_{4}^{\mbox{pert}}$ $\displaystyle=$
$\displaystyle\frac{1}{3\cdot
2^{8}\pi^{6}}\int_{\Lambda}^{1}d\alpha\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{3}(\alpha
s-m_{c}^{2}-2m_{s}m_{c})(\alpha s-m_{c}^{2})^{3},$ (35)
$\displaystyle\rho_{4}^{\langle\bar{s}s\rangle}$ $\displaystyle=$
$\displaystyle\frac{\langle\bar{s}s\rangle}{2^{5}\pi^{4}}\int_{\Lambda}^{1}d\alpha\frac{1-\alpha}{\alpha^{2}}[(1-\alpha)m_{c}+2\alpha
m_{s}](\alpha s-m_{c}^{2})^{2},$ (36) $\displaystyle\rho_{4}^{\langle
g^{2}G^{2}\rangle}$ $\displaystyle=$ $\displaystyle-\frac{m_{c}\langle
g^{2}G^{2}\rangle}{3^{2}\cdot
2^{9}\pi^{6}}\int_{\Lambda}^{1}d\alpha\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{3}[(2m_{c}+3m_{s})(\alpha
s-m_{c}^{2})-m_{s}m_{c}^{2}],$ (37) $\displaystyle\rho_{4}^{\langle
g\bar{s}\sigma\cdot Gs\rangle}$ $\displaystyle=$ $\displaystyle-\frac{\langle
g\bar{s}\sigma\cdot Gs\rangle}{3\cdot
2^{5}\pi^{4}}\int_{\Lambda}^{1}\frac{d\alpha}{\alpha}[3(1-\alpha)m_{c}+2\alpha
m_{s}](\alpha s-m_{c}^{2}),$ (38)
$\displaystyle\rho_{4}^{\langle\bar{q}q\rangle^{2}}$ $\displaystyle=$
$\displaystyle\frac{\langle\bar{q}q\rangle^{2}}{3\cdot
2\pi^{2}}\int_{\Lambda}^{1}d\alpha[-(\alpha s-m_{c}^{2})+2m_{s}m_{c}],$ (39)
$\displaystyle\rho_{4}^{\langle g^{3}G^{3}\rangle}$ $\displaystyle=$
$\displaystyle-\frac{\langle g^{3}G^{3}\rangle}{3^{2}\cdot
2^{10}\pi^{6}}\int_{\Lambda}^{1}d\alpha\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{3}(\alpha
s-3m_{c}^{2}-3m_{s}m_{c}),$ (40)
$\displaystyle\rho_{4}^{\langle\bar{s}s\rangle\langle g^{2}G^{2}\rangle}$
$\displaystyle=$ $\displaystyle\frac{m_{c}\langle\bar{s}s\rangle\langle
g^{2}G^{2}\rangle}{3^{2}\cdot
2^{7}\pi^{4}}\int_{\Lambda}^{1}d\alpha\bigg{[}1+3\bigg{(}\frac{1-\alpha}{\alpha}\bigg{)}^{2}\bigg{]},$
(41) $\displaystyle\hat{B}\Pi_{4}^{\mbox{cond}}$ $\displaystyle=$
$\displaystyle-\frac{m_{s}m_{Q}\langle\bar{q}q\rangle\langle
g\bar{q}\sigma\cdot Gq\rangle}{3\cdot 2\pi^{2}}e^{-m_{Q}^{2}/M^{2}}$ (42)
$\displaystyle-$
$\displaystyle\frac{\langle\bar{q}q\rangle^{2}\langle\bar{s}s\rangle}{3^{2}}\bigg{(}4m_{Q}+m_{s}+\frac{m_{s}m_{Q}^{2}}{M^{2}}\bigg{)}e^{-m_{Q}^{2}/M^{2}}$
$\displaystyle+$ $\displaystyle\frac{\langle g\bar{q}\sigma\cdot
Gq\rangle^{2}}{3\cdot
2^{5}\pi^{2}}\bigg{[}-1-\frac{m_{Q}^{2}}{M^{2}}+2\frac{m_{s}m_{Q}^{3}}{(M^{2})^{2}}\bigg{]}e^{-m_{Q}^{2}/M^{2}},$

for the vector diquark-vector antidiquark case. For brevity, the light quark
condensate $\langle\bar{u}u\rangle$ or $\langle\bar{d}d\rangle$ is uniformly
represented by $\langle\bar{q}q\rangle$, and the integration limit is defined
as $\Lambda=m_{c}^{2}/s$. Some high dimension condensates are included above,
e.g. $\langle\bar{q}q\rangle\langle g\bar{q}\sigma\cdot Gq\rangle$,
$\langle\bar{q}q\rangle^{2}\langle\bar{s}s\rangle$, and $\langle
g\bar{q}\sigma\cdot Gq\rangle^{2}$. In the chosen work windows, the relative
contributions of these kind condensates are very small, and they merely affect
the final results in some sort. Most of other high dimension condensates are
formed into some similar terms with negative powers of $q^{2}$, which will be
strongly suppressed after making a Borel transform. Similarly, from the work
tetra5  on studying $D_{s0}^{*}(2317)$ as a $qs\bar{q}\bar{c}$ tetraquark, one
can see that high dimension contributions are rather small.

## References

  * (1) H. X. Chen, W. Chen, X. Liu, Y. R. Liu, and S. L. Zhu, Rept. Prog. Phys. 80, 076201 (2017).
  * (2) F. K. Guo, C. Hanhart, Ulf-G. Meißer, Q. Wang, Q. Zhao, and B. S. Zou, Rev. Mod. Phys. 90, 015004 (2018).
  * (3) A. Esposito, A. Pilloni, and A. D. Polosa, Phys. Rep. 668, 1 (2016).
  * (4) R. Molina, T. Branz, and E. Oset, Phys. Rev. D 82, 014010 (2010).
  * (5) R. Aaij et al. (LHCb Collaboration), arXiv:2009.00026 [hep-ex]; arXiv:2009.00025 [hep-ex].
  * (6) M. Karliner and J. L. Rosner, Phys. Rev. D 102, 094016 (2020).
  * (7) M. A. Shifman, A. I. Vainshtein, and V. I. Zakharov, Nucl. Phys. B147, 385 (1979); B147, 448 (1979); V. A. Novikov, M. A. Shifman, A. I. Vainshtein, and V. I. Zakharov, Fortschr. Phys. 32, 585 (1984).
  * (8) B. L. Ioffe, in The Spin Structure of The Nucleon, edited by B. Frois, V. W. Hughes, and N. de Groot (World Scientific, Singapore, 1997).
  * (9) S. Narison, Camb. Monogr. Part. Phys. Nucl. Phys. Cosmol. 17, 1 (2002), arXiv:hep-ph/0205006.
  * (10) P. Colangelo and A. Khodjamirian, in At the Frontier of Particle Physics: Handbook of QCD, edited by M. Shifman, Boris Ioffe Festschrift Vol. 3 (World Scientific, Singapore, 2001), pp. 1495-1576.
  * (11) L. J. Reinders, H. R. Rubinstein, and S. Yazaki, Phys. Rep. 127, 1 (1985).
  * (12) M. Nielsen, F. S. Navarra, and S. H. Lee, Phys. Rep. 497, 41 (2010).
  * (13) M. E. Bracco, A. Lozea, R. D. Matheus, F. S. Navarra, and M. Nielsen, Phys. Lett. B 624, 217 (2005).
  * (14) H. Kim and Y. Oh, Phys. Rev. D 72, 074012 (2005).
  * (15) Z. G. Wang and S. L. Wan, Nucl. Phys. A778, 22 (2006).
  * (16) R. Albuquerque, S. Narison, A. Rabemananjara, and D. Rabetiarivony, Int. J. Mod. Phys. A 31, 1650093 (2016).
  * (17) W. Chen, H. X. Chen, X. Liu, T. G. Steele, and S. L. Zhu, Phys. Rev. D 95, 114005 (2017).
  * (18) S. S. Agaev, K. Azizi, and H. Sundu, Eur. Phys. J. C 78, 141 (2018); K. Azizi and U. Özdem, J. Phys. G: Nucl. Part. Phys. 45, 055003 (2018).
  * (19) J. R. Zhang, Phys. Lett. B 789, 432 (2019).
  * (20) J. R. Zhang, Phys. Rev. D 87, 076008 (2013); Phys. Rev. D 89, 096006 (2014); Eur. Phys. J. C 79, 1001 (2019); J. R. Zhang, J. L. Zou, and J. Y. Wu, Chin. Phys. C 42, 043101 (2018).
  * (21) M. Tanabashi et al. (Particle Data Group), Phys. Rev. D 98, 030001 (2018) and 2019 update.
  * (22) R. D. Matheus, F. S. Navarra, M. Nielsen, and R. Rodrigues da Silva, Phys. Rev. D 76, 056005 (2007).
  * (23) H. X. Chen, A. Hosaka, and S. L. Zhu, Phys. Lett. B 650, 369 (2007).
  * (24) Z. G. Wang, Nucl. Phys. A791, 106 (2007).
  * (25) J. R. Zhang, L. F. Gan, and M. Q. Huang, Phys. Rev. D 85, 116007 (2012); J. R. Zhang and G. F. Chen, Phys. Rev. D 86, 116006 (2012); J. R. Zhang, Phys. Rev. D 87, 116004 (2013).