Repository: CITCOM-project/CausalTestingFramework (language: python)

Issue:
Update and Improve the Documentation
We should really update our documentation (ideally on a regular cadence, e.g. automating when every release is made via webhooks?) to reflect recent changes. For instance, the [usage section](https://causal-testing-framework.readthedocs.io/en/latest/usage.html) still references the causal_test_engine, which has been refactored for a while now.

Also, a couple of (semantic) points worth discussing regarding separate feature requests:

1. The documentation IMO is generally quite text-heavy - can/should we introduce more diagrams, flow-charts, etc. to make the framework more accessible for non-expert programmers, and making it more aesthetic? 
2. Similarly, do we want to choose a theme for the documentation? Something specific for the CITCOM branding (if one exists)?

If you have any more ideas/suggestions, please do add them in this thread, and I'm happy to own this issue.


Discussion / hints:

Fix patch:
diff --git a/README.md b/README.md
index 8fc526b7..929179e5 100644
--- a/README.md
+++ b/README.md
@@ -1,6 +1,15 @@
-# Causal Testing Framework: A Causal Inference-Driven Software Testing Framework
+# Causal Testing Framework
+### A Causal Inference-Driven Software Testing Framework
 
-![example workflow](https://github.com/CITCOM-project/CausalTestingFramework/actions/workflows/ci-tests.yaml/badge.svg) [![codecov](https://codecov.io/gh/CITCOM-project/CausalTestingFramework/branch/main/graph/badge.svg?token=04ijFVrb4a)](https://codecov.io/gh/CITCOM-project/CausalTestingFramework) [![Documentation Status](https://readthedocs.org/projects/causal-testing-framework/badge/?version=latest)](https://causal-testing-framework.readthedocs.io/en/latest/?badge=latest)
+
+[![Project Status: Active – The project has reached a stable, usable state and is being actively developed.](https://www.repostatus.org/badges/latest/active.svg)](https://www.repostatus.org/#active) 
+![example workflow](https://github.com/CITCOM-project/CausalTestingFramework/actions/workflows/ci-tests.yaml/badge.svg) 
+[![codecov](https://codecov.io/gh/CITCOM-project/CausalTestingFramework/branch/main/graph/badge.svg?token=04ijFVrb4a)](https://codecov.io/gh/CITCOM-project/CausalTestingFramework) 
+[![Documentation Status](https://readthedocs.org/projects/causal-testing-framework/badge/?version=latest)](https://causal-testing-framework.readthedocs.io/en/latest/?badge=latest)
+![Dynamic TOML Badge](https://img.shields.io/badge/dynamic/toml?url=https%3A%2F%2Fraw.githubusercontent.com%2FCITCOM-project%2FCausalTestingFramework%2Fmain%2Fpyproject.toml&query=%24.project%5B'requires-python'%5D&label=python)
+![PyPI - Version](https://img.shields.io/pypi/v/causal-testing-framework)
+[![DOI](https://t.ly/FCT1B)](https://orda.shef.ac.uk/articles/software/CITCOM_Software_Release/24427516)
+![GitHub License](https://img.shields.io/github/license/CITCOM-project/CausalTestingFramework)
 
 Causal testing is a causal inference-driven framework for functional black-box testing. This framework utilises
 graphical causal inference (CI) techniques for the specification and functional testing of software from a black-box
@@ -12,10 +21,9 @@ system-under-test that is expected to cause a change to some output(s).
 
 ![Causal Testing Workflow](images/workflow.png)
 
-
 ## Installation
 
-See the readthedocs site for [installation
+See the Read the Docs site for [installation
 instructions](https://causal-testing-framework.readthedocs.io/en/latest/installation.html).
 
 ## Documentation
diff --git a/docs/README.md b/docs/README.md
index 5dadbaf7..de8abb3f 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -6,7 +6,7 @@ The documentation is accessible on [Read the Docs](https://causal-testing-framew
 
 ## Locally building
 To build locally, the requirements in `docs/source/requirements.txt` will need to be installed.
-
+[README.md](README.md)
 Within `docs/`, run `make html` to create or update the .html files in the `docs/build` directory. 
 
 Running `make clean` will clean the `build` folder.  
\ No newline at end of file
diff --git a/docs/source/_static/css/custom.css b/docs/source/_static/css/custom.css
new file mode 100644
index 00000000..70b8a18d
--- /dev/null
+++ b/docs/source/_static/css/custom.css
@@ -0,0 +1,29 @@
+/* Custom CSS */
+
+/* Note: /*
+The CSS below will only work if 'logo_only':True in conf.py, but will require adjusting if False.
+ */
+
+.wy-side-nav-search a .logo {
+    max-width: 200px;
+    max-height: 170px;
+    height: auto;
+    width:auto;
+}
+
+
+
+.wy-nav-top a {
+    color: #131E29;  /* Change the colour of the homepage navigation title on mobiles */
+}
+
+.wy-menu-vertical p.caption {
+
+    color: #9ADBE8; /* Change the colour of captions*/
+}
+
+
+.rst-content code.literal, .highlight .s2, .highlight .s1, .rst-content tt.literal{
+    color: #440099;
+    font-weight: bold;
+}
\ No newline at end of file
diff --git a/docs/source/_static/images/CITCOM-logo.png b/docs/source/_static/images/CITCOM-logo.png
new file mode 100644
index 00000000..af9f058a
Binary files /dev/null and b/docs/source/_static/images/CITCOM-logo.png differ
diff --git a/docs/source/conf.py b/docs/source/conf.py
index a9aa633a..d9ab4e48 100644
--- a/docs/source/conf.py
+++ b/docs/source/conf.py
@@ -12,6 +12,7 @@
 #
 import os
 import sys
+from datetime import date
 
 # Include root directory of project
 sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), "../..")))
@@ -19,9 +20,9 @@
 
 # -- Project information -----------------------------------------------------
 
-project = "Causal Testing"
-copyright = "2021, Andrew Clark, Michael Foster, Neil Walkinshaw, Rob Hierons, Bob Turner"
-author = "Andrew Clark, Michael Foster, Neil Walkinshaw, Rob Hierons, Bob Turner"
+project = "Causal Testing Framework"
+copyright = f"{date.today().year}, The CITCOM Team"
+author = "Andrew Clark, Michael Foster, Neil Walkinshaw, Rob Hierons, Bob Turner, Christopher Wild, Farhad Allian"
 
 
 # -- General configuration ---------------------------------------------------
@@ -49,7 +50,24 @@
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
 # so a file named "default.css" will overwrite the builtin "default.css".
-# html_static_path = ['_static']
+html_static_path = ['_static']
+
+html_css_files = ['css/custom.css']
 
 # Path to generate documentation from using sphinx AutoAPI
 autoapi_dirs = [os.path.abspath(os.path.join("..", "..", "causal_testing"))]
+
+autoapi_generate_api_docs = True
+autoapi_keep_files = True
+
+# Suppress label warnings
+suppress_warnings = ['autosectionlabel.*']
+
+
+html_logo = '_static/images/CITCOM-logo.png'
+
+html_theme_options = {
+    'style_nav_header_background': '#9ADBE8',  # Set the colour using CSS
+    'logo_only' : True,
+}
+
diff --git a/docs/source/credits.rst b/docs/source/credits.rst
new file mode 100644
index 00000000..6a82e48e
--- /dev/null
+++ b/docs/source/credits.rst
@@ -0,0 +1,37 @@
+Acknowledging CITCOM
+*********************
+
+If you use the Causal Testing Framework for your work, please add the following line within your paper to acknowledge
+our work:
+
+.. admonition:: Important
+   :class: important
+
+   This research has used version X.Y.Z (software citation) of the Causal Testing Framework (paper citation).
+
+The paper citation should be the Causal Testing Framework paper_, and the software citation should be the specific
+Figshare DOI_ for the version used in your research.
+
+.. _paper: https://dl.acm.org/doi/10.1145/3607184
+.. _DOI: https://dl.acm.org/doi/10.1145/3607184
+
+.. code-block:: latex
+
+    @ARTICLE{Clark_etal_2023,
+    author = {Clark, Andrew G. and Foster, Michael and Prifling, Benedikt and Walkinshaw, Neil and Hierons, Robert M.
+    and Schmidt, Volker and Turner, Robert D.},
+    title = {Testing Causality in Scientific Modelling Software},
+    year = {2023},
+    publisher = {Association for Computing Machinery},
+    url = {https://doi.org/10.1145/3607184},
+    doi = {10.1145/3607184},
+    journal = {ACM Trans. Softw. Eng. Methodol.},
+    month = {jul},
+    keywords = {Software Testing, Causal Testing, Causal Inference}
+    }
+
+The CITCOM Team
+***************
+
+- Andrew G. Clark, Michael Foster, Richard Somers, Christopher Wild, Farhad Allian, Neil Walkinshaw.
+
diff --git a/docs/source/description.rst b/docs/source/description.rst
index 514e62ce..c15f78f6 100644
--- a/docs/source/description.rst
+++ b/docs/source/description.rst
@@ -1,29 +1,28 @@
-Framework Overview
+Background
 =====================================
 
-CTF Components
---------------
+The Causal Testing Framework consists of 3 main components: 1) Causal Specification, 2) Causal Test Case and 3) Data Collection.
 
 #.
-   :doc:`Causal Specification <../modules/causal_specification>`\ : Before we can test software, we need to obtain an
-   understanding of how it should behave in a particular use-case scenario. In addition, to apply graphical CI
+   :doc:`Causal Specification <../modules/causal_specification>`\ : To apply graphical CI
    techniques for testing, we need a causal DAG which depicts causal relationships amongst inputs and outputs. To
    collect this information, users must create a *causal specification*. This comprises a set of scenarios which place
    constraints over input variables that capture the use-case of interest, a causal DAG corresponding to this scenario,
    and a series of high-level functional requirements that the user wishes to test. In causal testing, these
    requirements should describe how the model should respond to interventions (changes made to the input configuration).
 
+
+
 #.
    :doc:`Causal Tests <../modules/causal_tests>`\ : With a causal specification in hand, we can now go about designing
    a series of test cases that interrogate the causal relationships of interest in the scenario-under-test. Informally,
-   a causal test case is a triple (M, X, Delta, Y), where M is the modelling scenario, X is an input configuration,
-   Delta is an intervention which should be applied to X, and Y is the expected *causal effect* of that intervention on
-   some output of interest. Therefore, a causal test case states the expected causal effect (Y) of a particular
-   intervention (Delta) made to an input configuration (X). For each scenario, the user should create a suite of causal
+   a causal test case is a triple ``(M, X, Delta, Y)``, where ``M`` is the modelling scenario, ``X`` is an input configuration,
+   ``Delta`` is an intervention which should be applied to ``X``, and ``Y`` is the expected *causal effect* of that intervention on
+   some output of interest. Therefore, a causal test case states the expected causal effect (``Y``) of a particular
+   intervention (``Delta``) made to an input configuration (``X``). For each scenario, the user should create a suite of causal
    tests. Once a causal test case has been defined, it is executed as follows:
 
-
-   #. Using the causal DAG, identify an estimand for the effect of the intervention on the output of interest. That is,
+   a. Using the causal DAG, identify an estimand for the effect of the intervention on the output of interest. That is,
       a statistical procedure capable of estimating the causal effect of the intervention on the output.
    #. Collect the data to which the statistical procedure will be applied (see Data collection below).
    #. Apply a statistical model (e.g. linear regression or causal forest) to the data to obtain a point estimate for
@@ -35,6 +34,8 @@ CTF Components
       test should pass or fail based on the results. In the simplest case, this takes the form of an assertion which
       compares the point estimate to the expected causal effect specified in the causal test case.
 
+
+
 #.
    :doc:`Data Collection <../modules/data_collector>`\ : Data for the system-under-test can be collected in two
    ways: experimentally or observationally. The former involves executing the system-under-test under controlled
@@ -48,22 +49,3 @@ CTF Components
    provide instructions for an execution that will fill the gap (future work).
 
 For more information on each of these steps, follow the link to their respective documentation.
-
-Causal Inference Terminology
-----------------------------
-
-Here are some explanations for the causal inference terminology used above.
-
-
-* Causal inference (CI) is a family of statistical techniques designed to quantify and establish **causal**
-  relationships in data. In contrast to purely statistical techniques that are driven by associations in data, CI
-  incorporates knowledge about the data-generating mechanisms behind relationships in data to derive causal conclusions.
-* One of the key advantages of CI is that it is possible to answer causal questions using **observational data**. That
-  is, data which has been passively observed rather than collected from an experiment and, therefore, may contain all
-  kinds of bias. In a testing context, we would like to leverage this advantage to test causal relationships in software
-  without having to run costly experiments.
-* There are many forms of CI techniques with slightly different aims, but in this framework we focus on graphical CI
-  techniques that use directed acyclic graphs to obtain causal estimates. These approaches used a causal DAG to explain
-  the causal relationships that exist in data and, based on the structure of this graph, design statistical experiments
-  capable of estimating the causal effect of a particular intervention or action, such as taking a drug or changing the
-  value of an input variable.
diff --git a/docs/source/dev/actions_and_webhooks.rst b/docs/source/dev/actions_and_webhooks.rst
index aeaa38b3..030745e8 100644
--- a/docs/source/dev/actions_and_webhooks.rst
+++ b/docs/source/dev/actions_and_webhooks.rst
@@ -1,26 +1,30 @@
 Github Actions and Webhooks
 ===========================
 
-Github Actions
+Actions
 --------------
 
-Currently this project makes use of 3 `Github Actions <https://github.com/features/actions>`_, which can be found in the `.github/workflows <https://github.com/CITCOM-project/CausalTestingFramework/tree/main/.github/workflows>`_ directory
+Currently, this project makes use of 3 `Github Actions <https://github.com/features/actions>`_,
+which can be found in the
+`.github/workflows <https://github.com/CITCOM-project/CausalTestingFramework/tree/main/.github/workflows>`_ directory.
 
 They are:
 
-#.  ci-tests.yaml, which runs CI tests on each PR
+#.  ``ci-tests.yaml``, which runs continuous integration (CI) tests on each on each pull request.
 
-#.  lint-format.yaml, runs linting on each PR
+#.  ``lint-format.yaml``, which runs linting on each pull request.
 
-#.  publish-to-pypi.yaml, runs when a new version tag is pushed and publishes that tag version to pypi
+#.  ``publish-to-pypi.yaml``, runs when a new version tag is pushed and publishes that tag version to PyPI.
 
-Github Webhooks
+Webhooks
 ---------------
 
-The project also uses 3 `Webhooks <https://docs.github.com/en/webhooks-and-events/webhooks/about-webhooks>`_, which can be found in the `project settings <https://github.com/CITCOM-project/CausalTestingFramework/settings>`_ on Github
+The project also uses 3 `Webhooks <https://docs.github.com/en/webhooks-and-events/webhooks/about-webhooks>`_, which can
+be found in the `project settings <https://github.com/CITCOM-project/CausalTestingFramework/settings>`_ on Github. These
+include:
 
-#.  To codacy
+#.  `Codacy <https://github.com/codacy>`_
 
-#.  To codecov
+#.  `Codecov <https://github.com/codecov>`_
 
-#.  To readthedocs
\ No newline at end of file
+#.  `Read the Docs <https://github.com/readthedocs>`_
\ No newline at end of file
diff --git a/docs/source/dev/documentation.rst b/docs/source/dev/documentation.rst
index a561a560..71b7284c 100644
--- a/docs/source/dev/documentation.rst
+++ b/docs/source/dev/documentation.rst
@@ -1,27 +1,23 @@
 Project Documentation
 =====================
 
-This page aims to describe:
+This page describes:
 
-#. The projects documentation style
+#. The projects documentation style,
 
-#. The tools used for documentation
+#. The tools used for documentation,
 
-#. ReadTheDocs where the documentation for this project is hosted
+#. Read the Docs where the documentation for this project is hosted.
 
 
-Documentation Style
+Style and Tools
 -------------------
 
-The `Sphinx docstring format <https://sphinx-rtd-tutorial.readthedocs.io/en/latest/docstrings.html#the-sphinx-docstring-format>`_ is used throughout the projects codebase to allow for the easy understanding of classes, methods, functions, etc.
-This format allows for the easy generation of html documentation pages.
+The `Sphinx docstring format <https://sphinx-rtd-tutorial.readthedocs.io/en/latest/docstrings.html#the-sphinx-docstring-format>`_ is used
+throughout the projects codebase to allow for the easy understanding of classes, methods, functions, etc. This format
+allows for the easy generation of html documentation pages. It also checks for docstrings that have been added to the projects PyLint configuration.
 
-Checks for docstrings have been added to the projects Pylint configuration.
-
-Documentation Tools
--------------------
-
-To install the packages required to work with the documentation please ensure the projects **dev** dependencies are installed::
+To install the packages required to work with the documentation, please ensure the projects **dev** dependencies are installed::
 
     pip install causal-testing-framework[dev]
 
@@ -42,20 +38,25 @@ To cleanup the compiled docs you can run::
     make clean
 
 
-Situation within `docs/source` are the reStructuredText files (.rst) which contain the handwritten doc pages, which get compiled by the make commands.
 
-Autodoc & Autoapi
+The source reStructuredText files (.rst) files can be found within `docs/source` directory, which contains the
+handwritten documentation pages and get compiled by the ``make`` commands.
+
+Autodoc & AutoAPI
 *****************
 
-`Autodoc <https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html>`_ is an extension to sphinx that can import code modules and compile documentation from their docstrings.
+`Autodoc <https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html>`_ is an extension to Sphinx that can import
+code modules and compile documentation from their docstrings.
 
-`AutoAPI <https://sphinx-autoapi.readthedocs.io/en/latest/>`_ is a third party sphinx tool for recursively discovering code modules and compiling them into a logical doctree structure
+`AutoAPI <https://sphinx-autoapi.readthedocs.io/en/latest/>`_ is a third party Sphinx tool for recursively discovering
+code modules and compiling them into a logical doctree structure
 
-The configuration for Sphinx, Autodoc and AutoAPI are all found in `/docs/source/conf.py <https://github.com/CITCOM-project/CausalTestingFramework/blob/main/docs/source/conf.py>`_.
+The configuration for Sphinx, Autodoc and AutoAPI can all be found in `/docs/source/conf.py <https://github.com/CITCOM-project/CausalTestingFramework/blob/main/docs/source/conf.py>`_.
 
 ReadTheDocs
 -----------
-`Read the Docs <https://readthedocs.org/>`_ is a documentation hosting site that hosts, versions and builds documentation for free for open source projects.
+`Read the Docs <https://readthedocs.org/>`_ is a documentation hosting site that hosts, versions and builds documentation
+for free for open source projects.
 
-This project makes use of a Github Webook to trigger the build in ReadTheDocs, further reading on this can be found :doc:`here <../dev/actions_and_webhooks>`\
+This project makes use of a Github Webhook to trigger the build in ReadTheDocs, further reading on this can be found :doc:`here <../dev/actions_and_webhooks>`\
 
diff --git a/docs/source/dev/version_release.rst b/docs/source/dev/version_release.rst
index 6dde2c2d..85264bb8 100644
--- a/docs/source/dev/version_release.rst
+++ b/docs/source/dev/version_release.rst
@@ -2,28 +2,28 @@ Version Releases
 ================
 
 This project follows the `Semantic Versioning 2.0.0 <https://semver.org/>`_ style for code releases.
-This page aims to describe the release process for a new code version on the `Project Github <https://github.com/CITCOM-project/CausalTestingFramework>`_
+This page describes the release process for a new framework version on the `Project Github <https://github.com/CITCOM-project/CausalTestingFramework>`_.
 
 How to release
 --------------
 
-#. Once your PR(s) are merged, navigate to https://github.com/CITCOM-project/CausalTestingFramework/releases, which can be found on the right hand side of the projects Github main page by clicking on 'Releases'
+#. Once your PR(s) are merged, navigate to https://github.com/CITCOM-project/CausalTestingFramework/releases, which can be found on the right hand side of the projects Github main page by clicking on 'Releases'.
 
-#. Press the **Draft a new release** button in the top right of the releases page
+#. Press the **Draft a new release** button in the top right of the releases page.
 
-#. Press the **Choose a tag** button and add the new version following the Semantic Version guidelines. Please include the 'v' before the tag, e.g. **v0.0.0**
+#. Press the **Choose a tag** button and add the new version following the Semantic Version guidelines. Please include the 'v' before the tag, e.g. **v0.0.0**.
 
-#. Enter the same tag name into the **Release Title** box
+#. Enter the same tag name into the **Release Title** box.
 
-#. Press **Generate Release Notes** button
+#. Press **Generate Release Notes** button.
 
 #. Add any additional information that may be helpful to the release notes. If there are breaking changes for example, which modules will they affect?
 
-#. Ensure the **Set as the latest release** checkbox is selected
+#. Ensure the **Set as the latest release** checkbox is selected.
 
-#. Press publish release
+#. Press publish release.
 
-#. Check that the Github Action worker, found in the `Actions tab <https://github.com/CITCOM-project/CausalTestingFramework/actions>`_ on the github, has successfully completed. Typical time to publish to PyPI is around 2 minutes.
+#. Check that the Github Action worker, found in the `Actions tab <https://github.com/CITCOM-project/CausalTestingFramework/actions>`_ has successfully completed. The typical time to publish to PyPI is around 2 minutes.
 
 #. Check on the projects `PyPI page <https://pypi.org/project/causal-testing-framework/>`_ that the latest release is ready!
 
diff --git a/docs/source/frontends/json_front_end.rst b/docs/source/frontends/json_front_end.rst
index dcff7928..7d0fe957 100644
--- a/docs/source/frontends/json_front_end.rst
+++ b/docs/source/frontends/json_front_end.rst
@@ -1,27 +1,26 @@
 JSON Frontend
 ======================================
-The JSON frontend allows Causal Tests and parameters to be specified in JSON to allow for tests to be quickly written
-whilst retaining the flexibility of the Causal Testing Framework (CTF).
+The JSON frontend allows causal tests and parameters to be specified in JSON to allow for tests to be quickly written
+whilst retaining the flexibility of the framework.
 
-basic workflow
+Basic Workflow
 --------------
 The basic workflow of using the JSON frontend is as follows:
 
-#. Specify your test cases in the JSON format (more details below)
-#. Create your DAG in a dot file
-#. Initialise the JsonUtility class in python with a path of where you want the outputs saved
-#. Set the paths pointing the Json class to your json file, dag file and optionally your data file (see data section below) using the :func:`causal_testing.json_front.json_class.JsonUtility.set_paths` method
-#. Run the :func:`causal_testing.json_front.json_class.JsonUtility.setup` method providing your scenario
+#. Specify your test cases in the JSON format (more details below).
+#. Create your DAG in a dot file.
+#. Initialise the JsonUtility class in python with a path of where you want the outputs saved.
+#. Set the paths pointing the Json class to your json file, dag file and optionally your data file (see data section below) using the :func:`causal_testing.json_front.json_class.JsonUtility.set_paths` method.
+#. Run the :func:`causal_testing.json_front.json_class.JsonUtility.setup` method providing your scenario.
 #. Run the :func:`causal_testing.json_front.json_class.JsonUtility.run_json_tests` method, which will execute the test cases provided by the JSON file.
 
 Example Walkthrough
 -------------------
-An example is provided in `examples/poisson` which will be walked through in this README to better understand
-the framework
+An example is provided in `examples/poisson` which contains a README with more detailed information.
 
 run_causal_tests.py
 *******************
-`examples/poisson/run_causal_tests.py <https://github.com/CITCOM-project/CausalTestingFramework/blob/main/examples/poisson/run_causal_tests.py>`_
+The `examples/poisson/example_run_causal_tests.py <https://github.com/CITCOM-project/CausalTestingFramework/blob/main/examples/poisson/example_run_causal_tests.py>`_
 contains python code written by the user to implement scenario specific features
 such as:
 
@@ -31,13 +30,13 @@ such as:
 #. Meta constraint functions
 #. Mapping JSON distributions, effects, and estimators to python objects
 
-Use case specific information is also declared here such as the paths to the relevant files needed for the tests.
+Use-case specific information is also declared here such as the paths to the relevant files needed for the tests.
 
 causal_tests.json
 *****************
-`examples/poisson/causal_tests.json <https://github.c#om/CITCOM-project/CausalTestingFramework/blob/main/examples/poisson/causal_tests.json>`_ contains python code written by the user to implement scenario specific features
-is the JSON file that allows for the easy specification of multiple causal tests. Tests can be specified two ways; firstly by specifying a mutation lke in the example tests with the following structure:
-Each test requires:
+The `examples/poisson/causal_tests.json <https://github.com/CITCOM-project/CausalTestingFramework/blob/main/examples/poisson/causal_tests.json>`_ contains Python code written by the user to implement scenario specific features
+is the JSON file that allows for the easy specification of multiple causal tests.
+Tests can be specified two ways; firstly by specifying a mutation lke in the example tests with the following structure:
 
 #. name
 #. mutations
@@ -58,17 +57,22 @@ The second method of specifying a test is to specify the test in a concrete form
 #. expected_effect
 #. skip
 
+
+Alternatively, a ``causal_tests.json`` file can be created from a ``dag.dot`` file using the ``causal_testing/specification/metamorphic_relation.py`` script as follows::
+
+  python causal_testing/specification/metamorphic_relation.py --dag_path dag.dot --output_path causal_tests.json
+
 Run Commands
 ************
-This example uses the Argparse utility built into the JSON frontend, which allows the frontend to be run from a commandline interface as shown here.
+This example uses the ``Argparse`` utility built into the JSON frontend, which allows the frontend to be run from a commandline interface as shown here.
 
 To run the JSON frontend example from the root directory of the project, use::
 
-    python examples\poisson\run_causal_tests.py --data_path="examples\poisson\data.csv" --dag_path="examples\poisson\dag.dot" --json_path="examples\poisson\causal_tests.json
+    python examples\poisson\example_run_causal_tests.py --data_path="examples\poisson\data.csv" --dag_path="examples\poisson\dag.dot" --json_path="examples\poisson\causal_tests.json
 
 A failure flag `-f` can be specified to stop the framework running if a test is failed::
 
-    python examples\poisson\run_causal_tests.py -f --data_path="examples\poisson\data.csv" --dag_path="examples\poisson\dag.dot" --json_path="examples\poisson\causal_tests.json
+    python examples\poisson\example_run_causal_tests.py -f --data_path="examples\poisson\data.csv" --dag_path="examples\poisson\dag.dot" --json_path="examples\poisson\causal_tests.json
 
 There are two main outputs of this frontend, both are controlled by the logging module. Firstly outputs are printed to stdout (terminal).
 Secondly a log file is produced, by default a file called `json_frontend.log` is produced in the directory the script is called from.
@@ -79,13 +83,9 @@ The behaviour of where the log file is produced and named can be altered with th
 
 
 Runtime Data
-----------
+-------------
 
 There are currently 2 methods to inputting your runtime data into the JSON frontend:
 
 #. Providing one or more file paths to `.csv` files containing your data
-#. Setting a dataframe to the .data attribute of the JsonUtility instance, this must be done before the setup method is called.
-
-
-
-
+#. Setting a dataframe to the .data attribute of the JSONUtility instance, this must be done before the setup method is called.
\ No newline at end of file
diff --git a/docs/source/glossary.md b/docs/source/glossary.md
deleted file mode 100644
index b0160c1c..00000000
--- a/docs/source/glossary.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Glossary
-
-TDB
diff --git a/docs/source/glossary.rst b/docs/source/glossary.rst
new file mode 100644
index 00000000..4e57012b
--- /dev/null
+++ b/docs/source/glossary.rst
@@ -0,0 +1,62 @@
+.. Glossary
+
+Glossary
+###################
+
+.. glossary::
+
+   Causal inference
+    Causal inference (:abbr:`CI`) is a family of statistical techniques designed to quantify and establish **causal**
+    relationships in data. In contrast to purely statistical techniques that are driven by associations in data, CI
+    incorporates knowledge about the data-generating mechanisms behind relationships in data to derive causal conclusions.
+
+    Causal DAG
+      A Directed Acyclic Graph depicting the direct causal relationships between variables, in which an edge ``X -> Y`` indicates that ``X`` directly causes ``Y``. That is, there exists an intervention on ``X`` which brings about a change in ``Y``.
+
+      Treatment Variable
+        The changed variable of interest (``X``).
+
+      Outcome Variable
+        The observed variable of interest (``Y``).
+
+    Causal Specification
+      A causal specification is a pair ``S = (M, G)`` comprising a modelling scenario ``M`` and a causal DAG ``G`` capturing the causal relationships amongst the inputs and outputs of the SUT that are central to the modelling scenario.
+
+    Causal Test Case
+      A causal test case is a 4-tuple ``(M, X, |delta|, Y)`` that captures the expected causal effect, Y, of an intervention, ``delta``, made to an input valuation, ``X``, on some model outcome in the context of modelling scenario ``M``.
+
+   Directed acyclic graph (DAG)
+    A directed acyclic graph (:abbr:`DAG`) is a graphical representation used in causal inference to model and visualize relationships between variables.
+    In a DAG, nodes represent variables, and directed edges between nodes indicate causal relationships, with the absence of cycles ensuring acyclicity.
+
+   Estimate Type
+    The effect measure to use, typically (C)ATE, Risk Ratio, or Odds Ratio
+
+      ATE
+      ~~~~
+      **Average treatment effect** (:abbr:`ATE`): The additive difference in the outcome between the control and treatment populations.
+
+      CATE
+      ~~~~~~~~~~~
+      **Conditional ATE** (:abbr:`CATE`): The additive difference in the outcome between the control and treatment populations across different strata of the population.
+
+      Risk Ratio
+      ~~~~~~~~~~~
+      **Risk ratio**: The multiplicative difference in the outcome between the control and treatment populations.
+
+      Odds Ratio
+      ~~~~~~~~~~~
+      **Odds Ratio**: The ratio of the odds of A in the presence of B and the odds of A in the absence of B.
+
+
+   Minimal Adjustment Set
+      The smallest set of variables which must be controlled, or "adjusted for", to produce an unbiased estimate of causal effect.
+
+   Scenario
+      A modelling scenario ``M`` is a pair ``(X, C)`` where ``X`` is a non-strict subset of the model's input variables and ``C`` is a set of constraints over valuations of ``C``, which may be empty.
+
+   Scenario Execution
+      A software execution satisfying a given modelling scenario.
+
+   Intervention
+      An intervention ``delta : X -> X'`` is a function which manipulates the values of a subset of input valuations.
\ No newline at end of file
diff --git a/docs/source/index.rst b/docs/source/index.rst
index 3e41b28f..88985895 100644
--- a/docs/source/index.rst
+++ b/docs/source/index.rst
@@ -1,19 +1,102 @@
-.. Causal Testing documentation master file, created by
-
-Welcome to Causal Testing's documentation!
+Welcome to the Causal Testing Framework
 ==========================================
 
-Causal testing is a causal inference-driven framework for functional black-box testing. This framework utilises
+|status| |ci-tests| |code-cov| |docs| |python| |pypi| |doi| |license|
+
+Overview
+**********
+
+Causal testing is a :term:`causal inference`-driven framework for functional black-box testing. This framework utilises
 graphical causal inference (CI) techniques for the specification and functional testing of software from a black-box
 perspective. In this framework, we use causal directed acyclic graphs (DAGs) to express the anticipated cause-effect
 relationships amongst the inputs and outputs of the system-under-test and the supporting mathematical framework to
+relationships amongst the inputs and outputs of the system-under-test and the supporting mathematical framework to
 design statistical procedures capable of making causal inferences. Each causal test case focuses on the causal effect
 of an intervention made to the system-under test. That is, a prescribed change to the input configuration of the
 system-under-test that is expected to cause a change to some output(s).
 
-.. image:: /images/workflow.png
+.. raw:: html
+
+   <style>
+   .zoom-overlay {
+       position: fixed;
+       top: 0;
+       left: 0;
+       width: 100%;
+       height: 100%;
+       background-color: rgba(0, 0, 0, 0.7);
+       display: flex;
+       align-items: center;
+       justify-content: center;
+       z-index: 9999;
+   }
+
+   .zoom-container {
+       cursor: zoom-in;
+       transition: transform 1s ease-in-out;
+   }
+
+   .zoom-container.zoomed {
+       transform: scale(2);
+       cursor: zoom-out;
+   }
+
+   .zoomable-image {
+       max-width: 100%;
+       max-height: 100%;
+       margin: auto;
+   }
+
+   .zoom-container:hover {
+       cursor: zoom-in;
+   }
+   </style>
+
+.. raw:: html
+
+   <script>
+   document.addEventListener('DOMContentLoaded', function () {
+       var image = document.querySelector('.zoomable-image');
+
+       image.addEventListener('click', function () {
+           var overlay = document.createElement('div');
+           overlay.className = 'zoom-overlay';
+
+           var container = document.createElement('div');
+           container.className = 'zoom-container';
+           container.style.cursor = 'zoom-out';
+
+           var clonedImage = image.cloneNode();
+           clonedImage.classList.add('zoomable-image');
+           container.appendChild(clonedImage);
+           overlay.appendChild(container);
+
+           document.body.appendChild(overlay);
+
+           overlay.addEventListener('click', function () {
+               overlay.remove();
+           });
+       });
+   });
+   </script>
+
+
+
+.. container:: zoom-container
+
+   .. image:: /images/workflow.png
+      :class: zoomable-image
+      :alt: Zoomable Image
+
 
 .. toctree::
+   :hidden:
+   :caption: Home
+
+   self
+
+.. toctree::
+   :hidden:
    :maxdepth: 1
    :caption: Introduction
 
@@ -22,6 +105,7 @@ system-under-test that is expected to cause a change to some output(s).
    usage
 
 .. toctree::
+   :hidden:
    :maxdepth: 1
    :caption: Module Descriptions
 
@@ -32,11 +116,13 @@ system-under-test that is expected to cause a change to some output(s).
 .. toctree::
    :maxdepth: 2
    :caption: API
+   :hidden:
    :titlesonly:
 
-   /autoapi/causal_testing/index
+   /autoapi/index
 
 .. toctree::
+   :hidden:
    :maxdepth: 1
    :caption: Front Ends
 
@@ -44,21 +130,67 @@ system-under-test that is expected to cause a change to some output(s).
    frontends/test_suite
 
 .. toctree::
+   :hidden:
    :maxdepth: 1
    :caption: Glossary
 
    glossary
 
 .. toctree::
+   :hidden:
    :maxdepth: 1
-   :caption: Development Documentation
+   :caption: Development
 
    /dev/version_release
    /dev/documentation
    /dev/actions_and_webhooks
 
-Indices and tables
-==================
+.. toctree::
+   :caption: Useful Links
+   :hidden:
+   :maxdepth: 2
+
+   Paper <https://dl.acm.org/doi/10.1145/3607184>
+   Figshare <https://orda.shef.ac.uk/articles/software/CITCOM_Software_Release/24427516>
+   PyPI <https://pypi.org/project/causal-testing-framework/>
+
+.. toctree::
+   :hidden:
+   :maxdepth: 2
+   :caption: Credits
+
+   credits
+
+.. Define variables for our GH badges
+
+.. |ci-tests| image:: https://github.com/CITCOM-project/CausalTestingFramework/actions/workflows/ci-tests.yaml/badge.svg
+   :target: https://github.com/CITCOM-project/CausalTestingFramework/actions/workflows/ci-tests.yaml
+   :alt: Continuous Integration Tests
+
+.. |code-cov| image:: https://codecov.io/gh/CITCOM-project/CausalTestingFramework/branch/main/graph/badge.svg?token=04ijFVrb4a
+   :target: https://codecov.io/gh/CITCOM-project/CausalTestingFramework
+   :alt: Code coverage
+
+.. |docs| image:: https://readthedocs.org/projects/causal-testing-framework/badge/?version=latest
+   :target: https://causal-testing-framework.readthedocs.io/en/latest/?badge=latest
+   :alt: Documentation
+
+.. |python| image:: https://img.shields.io/badge/dynamic/toml?url=https%3A%2F%2Fraw.githubusercontent.com%2FCITCOM-project%2FCausalTestingFramework%2Fmain%2Fpyproject.toml&query=%24.project%5B'requires-python'%5D&label=python
+   :target: https://img.shields.io/badge/dynamic/toml?url=https%3A%2F%2Fraw.githubusercontent.com%2FCITCOM-project%2FCausalTestingFramework%2Fmain%2Fpyproject.toml&query=%24.project%5B'requires-python'%5D&label=python
+   :alt: Python
+
+.. |pypi| image:: https://img.shields.io/pypi/v/causal-testing-framework
+   :target: https://pypi.org/project/causal-testing-framework/
+   :alt: PyPI
+
+.. |status| image:: https://www.repostatus.org/badges/latest/active.svg
+   :target: https://www.repostatus.org/#active
+   :alt: Status
+
+.. |doi| image:: https://t.ly/FCT1B
+   :target: https://orda.shef.ac.uk/articles/software/CITCOM_Software_Release/24427516
+   :alt: DOI
 
-* :ref:`genindex`
-* :ref:`modindex`
\ No newline at end of file
+.. |license| image:: https://img.shields.io/github/license/CITCOM-project/CausalTestingFramework
+   :target: https://github.com/CITCOM-project/CausalTestingFramework
+   :alt: License
diff --git a/docs/source/installation.rst b/docs/source/installation.rst
index 86f42c1b..48736aa3 100644
--- a/docs/source/installation.rst
+++ b/docs/source/installation.rst
@@ -1,23 +1,32 @@
-Installation
-============
+Getting started
+================
 
 Requirements
-------------
-CausalTestingFramework requires python version 3.9 or later
-If installing on Windows, ensure `Microsoft Visual C++ <https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist>`_ is version 14.0 or greater
+---------------
+* Python >= 3.9.
+* `Microsoft Visual C++ <https://docs.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist>`_ 14.0+ (Windows only).
+
+
+Installation
+-----------------
+The Causal Testing Framework can be installed through either the `Python Package Index (PyPI)`_ (recommended), or directly from source.
+
+.. _Python Package Index (PyPI): https://dl.acm.org/doi/10.1145/3607184
+
+Method 1: Installing via pip
+..............................
 
-Pip Install
------------
 To install the Causal Testing Framework using :code:`pip` for the latest stable version::
 
     pip install causal-testing-framework
 
-To install with development packages/tools::
+or if you want to install with development packages/tools::
 
     pip install causal-testing-framework[dev]
 
-Install from source
--------------------
+
+Method 2: Installing via source
+...............................
 
 To install from source::
 
diff --git a/docs/source/modules/causal_specification.rst b/docs/source/modules/causal_specification.rst
index f8c24412..9774e019 100644
--- a/docs/source/modules/causal_specification.rst
+++ b/docs/source/modules/causal_specification.rst
@@ -2,27 +2,42 @@
 Causal Specification
 ====================
 
-In causal testing, our units of interest are specific usage **scenarios** of the system-under-test. For example, when testing an epidemiological computational model, one scenario could focus on the simulation of the spread of a virus in a crowded indoors space. For this scenario, our causal specification will describe how a number of interventions should **cause** some outputs to change e.g. opening a window should reduce the spread of the virus by some factor.
+- In causal testing, our units of interest are specific usage **scenarios** of the system-under-test. For example,
+  when testing an epidemiological computational model, one scenario could focus on the simulation of the spread of a virus in a crowded indoors space.
+  For this scenario, our causal specification will describe how a number of interventions should **cause** some outputs to change e.g. opening a window should reduce the spread of the virus by some factor.
 
-In order to isolate the causal effect of the defined interventions, the user needs to express the anticipated cause-effect relationships amongst the inputs and outputs involved in the scenario. This is achieved using a causal DAG, a simple dot and arrow graph that does not contain any cycles where nodes are random variables that represent the inputs and outputs in the scenario-under-test, and edges represent causality. For example, ``window --> infection_prob`` encodes the belief that opening or closing the window should cause the probability of infection to change.
+- In order to isolate the causal effect of the defined interventions, the user needs to express the anticipated cause-effect relationships amongst the inputs and outputs involved in the scenario.
+  This is achieved using a causal DAG, a simple dot and arrow graph that does not contain any cycles where nodes are random variables that represent the
+  inputs and outputs in the scenario-under-test, and edges represent causality. For example, ``window --> infection_prob`` encodes the belief that opening or closing the
+  window should cause the probability of infection to change.
 
-A causal specification is simply the combination of these components: a series of requirements for the scenario-under-test and a causal DAG representing causality amongst the inputs and outputs. We will discuss these in more detail below.
+- A causal specification is simply the combination of these components: a series of requirements for the scenario-under-test and a causal DAG representing causality
+  amongst the inputs and outputs. We will discuss these in more detail below.
 
 Scenario Requirements
 ---------------------
 
-Each scenario is defined as a series of constraints placed over a set of input variables. A constraint is simply a mapping from an input variable to a specific value or distribution that characterises the scenario in question. For example, a scenario simulating the spread of a virus in a crowded indoors space would likely place a constraint over the size of room, the number of windows, and the number of people in the room.
+- Each scenario is defined as a series of constraints placed over a set of input variables. A constraint is simply a mapping
+  from an input variable to a specific value or distribution that characterises the scenario in question.
+  For example, a scenario simulating the spread of a virus in a crowded indoors space would likely place a constraint over the size of room,
+  the number of windows, and the number of people in the room.
 
-Requirements for this scenario should describe how a particular intervention (e.g. opening the window, changing the number of people, changing the size of the room etc.) is expected to cause a particular outcome (number of infections, deaths, R0 etc.) to change. The way these requirements are expressed is up to the user, however, it is essential that they focus on the expected effect of an intervention.
+- Requirements for this scenario should describe how a particular intervention
+  (e.g. opening the window, changing the number of people, changing the size of the room etc.) is expected to cause a particular outcome (number of infections, deaths, R0 etc.) to change.
+  The way these requirements are expressed is up to the user, however, it is essential that they focus on the expected effect of an intervention.
 
 Causal DAG
 ----------
 
-In order to apply CI techniques, we need to capture causality amongst the inputs and outputs in the scenario-under-test. Therefore, for each scenario, the user must define a causal DAG. While there is generally no guidance/algorithm that can be followed to create a causal DAG, there are a couple of requirements that should be satisfied.
+In order to apply CI techniques, we need to capture causality amongst the inputs and outputs in the scenario-under-test.
+Therefore, for each scenario, the user must define a causal DAG. While there is generally no guidance/algorithm that can be followed to create a causal DAG,
+there are a couple of requirements that should be satisfied.
 
 
 #. The DAG must contain all inputs and outputs involved in the scenario-under-test.
 #. If there are any other variables which are not directly involved but are expected to have a causal relationship with the variables in the scenario-under-test, these should also be added to the graph. For example, the size of the room might be partially caused by the simulated location (house styles, average wealth etc.), in which case location should be added to the DAG with an edge to room size and any other variables it is deemed to influence.
 #. If in doubt, add an edge. It is a stronger assumption to exclude an edge (X and Y are independent) than to include one (X has some potentially negligiable causal effect on Y).
 
-Collectively, the components of the causal specification provide both contextual information in the form of constraints and requirements, as well as causal information in the form of a causal DAG. Later on, these components will be used to design statistical experiments that can answer causal questions about the scenrio-under-test, such as ``Does opening a window impair the viruses ability to spread?``
+-  Collectively, the components of the causal specification provide both contextual information in the form of constraints and requirements,
+   as well as causal information in the form of a causal DAG. Later on, these components will be used to design statistical experiments that
+   can answer causal questions about the scenario-under-test, such as `Does opening a window impair the viruses ability to spread?`
diff --git a/docs/source/modules/data_collector.rst b/docs/source/modules/data_collector.rst
index 508f897e..be1e73c7 100644
--- a/docs/source/modules/data_collector.rst
+++ b/docs/source/modules/data_collector.rst
@@ -1,24 +1,28 @@
 Data Collection
 ===============
 
-For causal testing, we require data for the scenario-under-test. This data can be collected in two ways: experimentally
+For causal testing, we require data for the scenario-under-test. This data can be collected in 2 ways: experimentally
 and observationally.
 
-Experimental data collection involves running the system-under-test with two specific input configurations, one with the
-intervention and one without. We refer to these as the treatment and control configurations, respectively. The only
-difference between these two input configurations is the intervention and therefore the observed difference in outcome
-is the causal effect. If the system-under-test is non-deterministic, each input configuration should be ran multiple
-times to observe the difference in the distributions of outputs.
+Experimental Data Collector
+****************************
+- Experimental data collection involves running the system-under-test with two specific input configurations, one with the
+  intervention and one without. We refer to these as the treatment and control configurations, respectively. The only
+  difference between these two input configurations is the intervention and therefore the observed difference in outcome
+  is the causal effect. If the system-under-test is non-deterministic, each input configuration should be ran multiple
+  times to observe the difference in the distributions of outputs.
 
-Observational data collection involves collecting past execution data for the system-under-test that was not ran under
-the experimental conditions necessary to isolate the causal effect. Instead, we will use the causal knowledge encoded
-in the causal specification's causal DAG to identify and appropriately mitigate any sources of bias in the data. That
-way, we can still obtain the causal effect of the intervention but avoid running costly experiments.
+Observational Data Collector
+*****************************
 
-We cannot use any data as observational data, though. We need to ensure that the data is representative of the
-scenario-under-test. To achieve this, we filter any provided data using the defined constraints by checking whether the
-data for a variables falls within the specified distribution or meets the exact specified value.
+- Observational data collection involves collecting past execution data for the system-under-test that was not ran under
+  the experimental conditions necessary to isolate the causal effect. Instead, we will use the causal knowledge encoded
+  in the causal specification's causal DAG to identify and appropriately mitigate any sources of bias in the data. That
+  way, we can still obtain the causal effect of the intervention but avoid running costly experiments.
 
-This package should contain methods which collect the data for causal inference. Users must implement these methods in a
-way that generates (experimental) or collects (observational) data for the scenario-under-test. For the observational
-case, we should also provide helper methods which filter the data.
\ No newline at end of file
+- We cannot use any data as observational data, though. We need to ensure that the data is representative of the
+  scenario-under-test. To achieve this, we filter any provided data using the defined constraints by checking whether the
+  data for a variables falls within the specified distribution or meets the exact specified value.
+
+- This package should contain methods which collect the data for causal inference. Users must implement these methods in a way that generates (experimental) or collects
+  (observational) data for the scenario-under-test. For the observational case, we should also provide helper methods which filter the data.
\ No newline at end of file
diff --git a/docs/source/usage.rst b/docs/source/usage.rst
index 7341280e..7f1e701d 100644
--- a/docs/source/usage.rst
+++ b/docs/source/usage.rst
@@ -2,14 +2,13 @@
 Usage
 -----
 
-There are currently three methods of using the Causal Testing Framework, through
-the :doc:`JSON Front End </frontends/json_front_end>`\, using
-:doc:`Test Suites </frontends/test_suite>`\, or directly as
+There are currently 3 methods of using the Causal Testing Framework; 1) :doc:`JSON Front End </frontends/json_front_end>`\, 2)
+:doc:`Test Suites </frontends/test_suite>`\, or 3) directly as
 described below.
 
-The causal testing framework is made up of three main components: Specification, Testing, and Data Collection. The first
+The causal testing framework is made up of 3 main components: Specification, Testing, and Data Collection. The first
 step is to specify the (part of the) system under test as a modelling ``Scenario``. Modelling scenarios specify the
-observable variables and any constraints which exist between them. We currently support three types of variable:
+observable variables and any constraints which exist between them. We currently support 3 types of variable:
 
 
 * ``Input`` variables are input parameters to the system.
@@ -77,19 +76,12 @@ data, e.g.
 
 .. code-block:: python
 
-   data_csv_path = 'results/data.csv'
-   data_collector = ObservationalDataCollector(modelling_scenario, data_csv_path)
+   obs_df = pd.read_csv('results/data.csv')
+   data_collector = ObservationalDataCollector(modelling_scenario, obs_df)
 
-The actual running of the tests is done using the ``CausalTestEngine`` class. The setup of the test engine is as follows:
-
-.. code-block:: python
-
-   from causal_testing.testing.causal_test_engine import CausalTestEngine
-
-   causal_test_engine = CausalTestEngine(causal_specification, data_collector)  # Instantiate the causal test engine
 
 Whether using fresh or pre-existing data, a key aspect of causal inference is estimation. To actually execute a test, we
-need an estimator. We currently support two estimators: linear regression and causal forest. The estimators require the
+need an estimator. We currently support two estimators: linear regression and logistic regression. The estimators require the
 minimal adjustment set from the causal_dag. This and the estimator can be instantiated as per
 the `documentation <https://causal-testing-framework.readthedocs.io/en/latest/autoapi/causal_testing/testing/estimators/index.html>`_.
 
@@ -98,18 +90,17 @@ the `documentation <https://causal-testing-framework.readthedocs.io/en/latest/au
    from causal_testing.testing.estimators import LinearRegressionEstimator
 
    minimal_adjustment_set = causal_dag.identification(base_test_case)
-   estimation_model = LinearRegressionEstimator("x",), 0, 1, minimal_adjustment_set, ("y",), causal_test_engine.scenario_execution_data_df)
+   estimation_model =  LinearRegressionEstimator(treatment=treatment, control=control, treatment_value=1, control_value=0, adjustment_set = minimal_adjustment_set, df = obs_df)
+
+
 
 We can now execute the test using the estimation model. This returns a causal test result, from which we can extract
 various information. Here, we simply assert that the observed result is (on average) what we expect to see.
 
 .. code-block:: python
 
-   causal_test_result = causal_test_engine.execute_test(
-       estimator = estimation_model,
-       causal_test_case = causal_test_case)
+   causal_test_result = causal_test_case.execute_test(estimation_model, data_collector)
    test_passes = causal_test_case.expected_causal_effect.apply(causal_test_result)
    assert test_passes, "Expected to see a positive change in y."
 
-Multiple tests can be executed at once using the test engines `test_suite <https://causal-testing-framework.readthedocs.io/en/test_suite.html>`_
-feature
+Multiple tests can be executed at once using the test engines :doc:`Test Suite </frontends/test_suite>` feature.


Test patch:
diff --git a/docs/source/frontends/test_suite.rst b/docs/source/frontends/test_suite.rst
index 94d10d92..8ddd0afa 100644
--- a/docs/source/frontends/test_suite.rst
+++ b/docs/source/frontends/test_suite.rst
@@ -4,12 +4,12 @@ Test Suite
 The test_suite feature allows for the effective running of multiple causal_test_cases using a logical structure.
 This structure is defined by the parameters in the class: :class:`causal_testing.testing.causal_test_suite`.
 
-A current limitation of the Test Suite is that it requires references to the estimator class not instances (objects) of
-estimator classes. Which prevents the usage of some of the features of an estimator class.
+A current limitation of the Test Suite is that it requires references to the estimator class, not instances (objects) of
+estimator classes, which prevents the usage of some of the features of an estimator.
 
-Test Suite - Class
+Class
 --------------------
-The test_suite class is an extension of the python UserDict_, meaning it simulates a standard python dictionary where
+The test_suite class is an extension of the python UserDict_, meaning it simulates a standard Python dictionary where
 any dictionary method can be used. The class also features a setter to make adding new test cases quicker and less
 error prone :meth:`causal_testing.testing.causal_test_suite.CausalTestSuite.add_test_object`.
 
@@ -20,12 +20,12 @@ the value is a test object in the format of another dictionary:
 
     test_object = {"tests": causal_test_case_list, "estimators": estimators_classes, "estimate_type": estimate_type}
 
-Each `base_test_case` contains the treatment and outcome variables and only causal_test_cases testing this relationship
-should be placed in the test object for that `base_test_case`.
+Each ``base_test_case`` contains the treatment and outcome variables, and only causal_test_cases testing this relationship
+should be placed in the test object for that ``base_test_case``.
 
 .. _UserDict: https://docs.python.org/3/library/collections.html#collections.UserDict
 
-Test Suite - Execution
+Execution
 -----------------------
 The test_suite can be executed by a call to the :meth:`causal_testing.testing.causal_test_engine.CausalTestEngine.execute_test_suite`.
 Here the causal_test_engine will iterate over all the test objects and execute each `test` once per `estimator` and per
diff --git a/docs/source/modules/causal_tests.rst b/docs/source/modules/causal_tests.rst
index 36ef3227..a8ea33c9 100644
--- a/docs/source/modules/causal_tests.rst
+++ b/docs/source/modules/causal_tests.rst
@@ -4,9 +4,9 @@ Causal Testing
 
 This package contains the main components of the causal testing framework, causal tests and causal oracles, which utilise both the specification and data collection packages.
 
-A causal test case is a triple ``(X, \Delta, Y)`` where ``X`` is an input configuration, ``\Delta`` is an intervention, and ``Y`` is the expected causal effect of applying ``\Delta`` to ``X``. Put simply, a causal test case states the expected change in an outcome that applying an intervention to X should cause. In this context, an intervention is simply a function which manipulates the input configuration of the scenario-under-test in a way that is expected to cause a change to some outcome.
+- A causal test case is a triple ``(X, \Delta, Y)`` where ``X`` is an input configuration, ``\Delta`` is an intervention, and ``Y`` is the expected causal effect of applying ``\Delta`` to ``X``. Put simply, a causal test case states the expected change in an outcome that applying an intervention to X should cause. In this context, an intervention is simply a function which manipulates the input configuration of the scenario-under-test in a way that is expected to cause a change to some outcome.
 
-For example, suppose we have an epidemiological computational model and we are testing the model in a classroom scenario. In particular, we are interested in how various precautions, such as hand washing and mask wearing, can prevent the spread of the virus in a classroom. Let us walk through the steps of causal testing.
+- For example, suppose we have an epidemiological computational model and we are testing the model in a classroom scenario. In particular, we are interested in how various precautions, such as hand washing and mask wearing, can prevent the spread of the virus in a classroom. Let us walk through the steps of causal testing.
 
 Specification
 -------------
@@ -42,21 +42,18 @@ We then define a number of causal test cases to apply to the scenario-under-test
 * ``mask_wearing_test = (X={precaution = None}, \Delta = {precaution = Mask}, Y = {-20% < n_infected_t5 < -10% })`` (Mask wearing is expected to result in between 10% and 20% fewer infections).
 * ``hand_washing_test = (X={precaution = None}, \Delta = {precaution = Hand Washing}, Y = {-40% < n_infected_t5 < -25%})`` (Hand washing is expected to result in between 25% and 40% fewer infections).
 
-Data Collection
----------------
+- To run these test cases experimentally, we need to execute both ``X`` and ``\Delta(X)`` - that is, with and without the interventions. Since the only difference between these test cases is the intervention, we can conclude that the observed difference in ``n_infected_t5`` was caused by the interventions. While this is the simplest approach, it can be extremely inefficient at scale, particularly when dealing with complex software such as computational models.
 
-To run these test cases experimentally, we need to execute both ``X`` and ``\Delta(X)`` - that is, with and without the interventions. Since the only difference between these test cases is the intervention, we can conclude that the observed difference in ``n_infected_t5`` was caused by the interventions. While this is the simplest approach, it can be extremely inefficient at scale, particularly when dealing with complex software such as computational models.
-
-To run these test cases observationally, we need to collect *valid* observational data for the scenario-under-test. This means we can only use executions with between 20 and 30 people, a square environment of size betwen 20x20 and 40x40, and where a single person was initially infected. In addition, this data must contain executions both with and without the intervention. Next, we need to identify any sources of bias in this data and determine a procedure to counteract them. This is achieved automatically using graphical causal inference techniques that identify a set of variables that can be adjusted to obtain a causal estimate. Finally, for any categorical biasing variables, we need to make sure we have executions corresponding to each category otherwise we have a positivity violation (i.e. missing data). In the worst case, this at least guides the user to an area of the system-under-test that should be executed.
+- To run these test cases observationally, we need to collect *valid* observational data for the scenario-under-test. This means we can only use executions with between 20 and 30 people, a square environment of size betwen 20x20 and 40x40, and where a single person was initially infected. In addition, this data must contain executions both with and without the intervention. Next, we need to identify any sources of bias in this data and determine a procedure to counteract them. This is achieved automatically using graphical causal inference techniques that identify a set of variables that can be adjusted to obtain a causal estimate. Finally, for any categorical biasing variables, we need to make sure we have executions corresponding to each category otherwise we have a positivity violation (i.e. missing data). In the worst case, this at least guides the user to an area of the system-under-test that should be executed.
 
 Causal Inference
 ----------------
 
-After collecting either observational or experimental data, we now need to apply causal inference. First, as described above, we use our causal graph to identify a set of adjustment variables which mitigate all bias in the data. Next, we use statistical models to adjust for these variables (implementing the statistical procedure necessary to isolate the causal effect) and obtain the desired causal estimate. Depending on the statistical model used, we can also generate 95% confidence intervals (or confidence intervals at any confidence level for that matter).
+- After collecting either observational or experimental data, we now need to apply causal inference. First, as described above, we use our causal graph to identify a set of adjustment variables which mitigate all bias in the data. Next, we use statistical models to adjust for these variables (implementing the statistical procedure necessary to isolate the causal effect) and obtain the desired causal estimate. Depending on the statistical model used, we can also generate 95% confidence intervals (or confidence intervals at any confidence level for that matter).
 
-In our example, the causal DAG tell us it is necessary to adjust for ``environment`` in order to obtain the causal effect of ``precaution`` on ``n_infected_t5``. Supposing the relationship is linear, we can employ a linear regression model of the form ``n_infected_t5 ~ p0*precaution + p1*environment`` to carry out this adjustment. If we use experimental data, only a single environment is used by design and therefore the adjustment has no impact. However, if we use observational data, the environment may vary and therefore this adjustment will look at the causal effect within different environments and then provide a weighted average, which turns out to be the partial coefficient ``p0``.
+- In our example, the causal DAG tell us it is necessary to adjust for ``environment`` in order to obtain the causal effect of ``precaution`` on ``n_infected_t5``. Supposing the relationship is linear, we can employ a linear regression model of the form ``n_infected_t5 ~ p0*precaution + p1*environment`` to carry out this adjustment. If we use experimental data, only a single environment is used by design and therefore the adjustment has no impact. However, if we use observational data, the environment may vary and therefore this adjustment will look at the causal effect within different environments and then provide a weighted average, which turns out to be the partial coefficient ``p0``.
 
 Test Oracle Procedure
 ---------------------
 
-After conducting causal inference, all that remains is to ascertain whether the causal effect is expected or not. In our example, this is simply a case of checking whether the causal effect on ``n_infected_t5`` falls within the specified range. However, in the future, we may wish to implement more complex oracles.
+- After conducting causal inference, all that remains is to ascertain whether the causal effect is expected or not. In our example, this is simply a case of checking whether the causal effect on ``n_infected_t5`` falls within the specified range. However, in the future, we may wish to implement more complex oracles.