abstract: Responsible AI is the practice of developing and using AI systems in a way that benefits the humans, society, and environment, while minimising the risk of negative consequences. Various responsible AI principles have been released recently. However, those principles are very abstract and not practical enough. Further, significant efforts have been put on algorithm-level solutions which are usually confined to a narrow set of principles (such as fairness and privacy). To bridge the gap, we adopt a pattern-oriented approach and build a responsible AI pattern catalogue for operationalising responsible AI from a system perspective. In this article, we first summarise the major challenges in operationalising responsible AI at scale and introduce how we use responsible AI pattern catalogue to address those challenges. Then, we discuss the case study we have conducted using the chatbot development use case to evaluate the usefulness of the pattern catalogue.
author: Qinghua Lu^1^, Yuxiu Luo^2^, Liming Zhu^1^, Mingjian Tang^3^, Xiwei Xu^1^, Jon Whittle^1^
^1^Data61, CSIRO, Australia
^2^Westpac, Australia
^3^Atlassian, Australia
title: Operationalising Responsible AI Using a Pattern-Oriented Approach: A Case Study on Chatbots in Financial Services

# Introduction

Artificial Intelligence (AI) has the huge potential to tackle grand societal and environmental challenges, increase productivity, transform industries, and provide more comprehensive intelligent services to communities and societies. The global AI market was valued at USD 93.5 billion in 2021 and is expected to grow with an annual growth rate of 38.1% from 2022 to 2030 [^1]. For the world to realise these benefits, it is important to ensure the AI systems are responsibly designed and developed by business, governments and academia throughout the entire lifecycle and trusted by citizens and communities who are expected to rely on them. This goal has triggered significant global effort to pursue and realize responsible AI in the world.

Responsible AI is the practice of developing, deploying, and maintaining AI systems in a way that benefits the humans, society, and environment, while minimising the risk of negative consequences. To solve the challenge of responsible AI, many AI ethics princples have been released recently by governments, organisations, and enterprises . For example, in 2019, CSIRO's Data61 worked with the Australian Government to conduct the AI Ethics Framework research, which led to the release of eight voluntary AI ethics principles [^2] to ensure Australia's adoption of AI is safe, secure and reliable .

A principle-based approach provides technology-neutral and context-independent guidance while allowing context-specific interpretations for implementing responsible AI. However, those principles are too abstract and high-level for practitioners to use in practice. For example, it is a very challenging and complex task to operationalise the the human-centered value principle regarding how it can be designed for, implemented and monitored throughout the entire lifecycle of AI systems. In addition, the existing work mainly focuses on algorithm-level solutions for a subset of mathematics-amenable AI ethics principles (such as privacy and fairness). However, responsible AI issues can happen at any stage of the development lifecycle crosscutting various AI and non-AI components of systems beyond AI algorithms and models. To try to bridge the principle-algorithmic gap, further guidance such as guidebooks[^3][^4], question banks, , checklists  and documentation templates  have begun to emerge. Those attempts tend to be ad-hoc and lack of systematic solutions to cover the entire lifecycle of AI systems taking into account different levels of stakeholders.

We have adopted a pattern-oriented approach and built a responsible AI pattern catalogue [^5] for different types and levels of stakeholders in AI industry . In this article, we first summarise the major challenges in operationalising responsible AI at scale and introduce how responsible AI pattern catalogue addresses those challenges. Then, we discuss the case study we have conducted using the chatbot use case to evaluate the usefulness of the pattern catalogue.

# MAJOR CHALLENGES IN OPERATIONALISING RESPONSIBLE AI AT SCALE

Through our engagement with industry, we have summarised three major challenges in operationalising responsible AI at scale:

-   **Challenge 1: Diverse Stakeholders and Risk Landscape.** Organisations usually take a risk-based approach to ensuring responsible AI. However, in AI ecosystems, different levels of stakeholders have various interests on responsible AI risks. Industry-level stakeholders (e.g., responsible AI regulators) and organisation-level stakeholders (e.g., board and executives) are more interested in harms and societal impacts, associated preventive/corrective cost and governance mechanisms, while team-level stakeholders (e.g., developers) care more about algorithmic risks, reliability and security techniques. AI technology/solution procurers are a type of industry-level stakeholders who are interested in how to verify the ethical quality of third party AI technologies/solutions without having full access to their proprietary models and how to deal with accountability and contestability when third parties are involved. Those varying stakeholder interests in responsible AI risk management demanding different but connected methods and tools.

-   **Challenge 2: Competing Risk Silos.** Organisations usually create individual board risk committees to manage different types of risks, such as financial, reputation and legal risks with some dedicated cybersecurity and privacy risk management. However, having dedicated risk committees including responsible AI risk committees give rise to risk silos which usually have limited connections between risks assessed separately and compete for resources. This makes risk management perceived as a forced and meaningless roll-up in organisations.

-   **Challenge 3: Lack of Risk Expertise.** Each organisation has existing and different governance and risk approaches. There is a shortage of expertise to assess new risks, including responsible AI risks. Most of the organisations do not have the necessary scope to handle responsible AI risks and the capacity to examine each AI project deeply. Thus, the organisations heavily reply on the project teams to do self-assessment. The current risk assessment practices include checklists, conversations, information sheets, rather than formal or technical approaches. Organisations usually treat risk analysis as hazard/threat analysis, omitting system vulnerability, exposure risks, and response/mitigation risk.

# PATTERN-ORIENTED APPROACH: RESPONSIBLE AI PATTERN CATALOGUE

We have adopted a pattern-oriented approach and built a responsible AI pattern catalogue to address the end-to-end/top-to-bottom responsible AI challenges. In software engineering, a pattern is a reusable solution to a recurring problem within a given context during software development. Patterns are documented to capture the knowledge about reusable solutions in an accessible and structure way for stakeholders to learn. A pattern catalogue is a collection of patterns that are related to some extend and can be used together or independently.

Based on the results of a multivocal review , we analysed successful case studies and generalised best practices into patterns. The current version of pattern catalogue has collected 63 patterns, including 24 governance patterns, 17 process patterns, and 22 product patterns. To describe the pattern, we extended the traditional pattern template with additional elements, including summary, pattern type, objective, target users, impacted stakeholders, relevant AI ethics principles, context, problem, solution, consequences (i.e., benefits and drawbacks), related patterns and known uses. Each pattern provides meaningful analysis on consequences, where pointers are added to measurement metrics and methods, residues of risk, and new risk introduced. Patterns are connected at multi-levels, multi-angles and across AI system life cycles through the related patterns.

As illustrated in Fig. , the responsible AI pattern catalogue has the following characteristics to help stakeholders better navigate the landscape and achieve responsible AI systems more successfully.

-   **Across multiple angles and connected – governance, process, and product.** As listed in Fig. , the patterns are organised into three interconnected categories for easier adoption for impact.

    -   Governance patterns for building multi-level governance for responsible AI;

    -   Process patterns for establishing responsible software development processes and AI engineering;

    -   Product patterns for building responsible-AI-by-design into AI systems .

    The stakeholders should use product patterns as product features to enforce responsible AI principles directly in the product and verify/validate the product. In the meantime, the stakeholders should also use process and governance patterns to complement responsible AI further.

-   **Across multiple organization levels and connected – industry/community, organisation, and teams.** The patterns introduced are at different levels, so stakeholders can situate the practice areas in the bigger picture and see how the patterns can fit in and how different patterns influence and reinforce each other from an industry/community, organisation, and team level.

-   **Across system lifecycle and connected – requirements, design, implementation, testing, deployment, and post-deployment monitoring.** Across the lifecycle of AI systems, different process patterns can be applied at other times, with the outputs of one pattern becoming the input of another.

-   **Across the supply chain, system, and operation layer and connected.** We connect the product patterns through a system reference architecture across AI supply chain, AI system, and operation/deployment infrastructure layer.

-   **Benefiting multiple connected risks.** Individual responsible AI risks should be managed in silos by using risk-specific solutions. The patterns often help multiple risks together to raise the responsible AI posture of the organization significantly.

-   **Acknowledging drawbacks and additional risks introduced.** Adopting pattern-oriented risk mitigation may introduce additional risks and costs. We recognize them by incorporating drawbacks in the patterns and connecting with other related ways to further address the challenges.

-   **Clear differentiation of trust and trustworthiness.** We recognize that the importance of gaining stakeholder trust goes beyond the objective trustworthiness of the systems. Gaining trust is about diverse and inclusive engagement, setting realistic expectations, and communicating trustworthiness evidence in a way that stakeholders can understand and meaningfully critique. We include trust and trustworthiness as pattern objectives.

# CASE STUDY: DEVELOPING CHATBOTS FOR THE FINANCIAL SERVICES

## A Brief History of Chatbots

The concept of chatbots can be traced back to the 1950s when computer scientist and inventor Alan Turing proposed the Turing Test, which aimed to determine whether a machine could exhibit intelligent behavior indistinguishable from a human. In 1966, Joseph Weizenbaum created ELIZA, the first known chatbot, which was designed to simulate a psychotherapist by responding to user inputs with pre-programmed responses . In the 1980s and 1990s, advances in natural language processing and machine learning led to the development of more advanced chatbots, such as Parry and ALICE. In the early 2000s, the rise of messaging platforms and mobile devices made it easier for businesses to integrate chatbots into their customer service systems. In recent years, advancements in AI (such as deep learning) have made it possible for chatbots to handle more complex and natural conversations with users, leading to the widespread use of chatbots in various industries, including finance, healthcare, and e-commerce.

## IBM Watson Assistant

IBM Watson Assistant is one of the chatbot platforms using AI and natural language processing to understand the user's input and provide appropriate responses. The chatbot is trained on a large amount of data to understand natural language and provide relevant and accurate responses to questions. When a user interacts with the chatbot, the input is processed by the algorithms to understand the intent and context of the message. The chatbot then uses pre-programmed rules and algorithms to generate a response based on the user's input. The chatbot can also access additional information from external sources, such as databases or APIs, to provide more detailed and accurate responses. This allows the chatbot to provide a wide range of information and services to users, such as answering frequently asked questions or providing personalized recommendations.

## Development Process of Chatbots

In this section, we introduce the development process of chatbots using IBM Watson Assistant and discuss how patterns can be used to address various responsible AI risks, as illustrated in Fig. . The chatbot development starts with the planning stage. Once the planning is completed, a conversation is designed and then built using the chosen chatbot platform, such as IBM Watson Assistant. The chatbot is then tested and deployed into target production environments. The performance of the chatbot is continuously measured. The chatbot is improved based the performance assessment and new requirements from business.

*Responsible AI risk committee pattern* can be adopted by the organisation to continuously assess the responsible AI risks of AI projects including chatbot projects through a dedicated responsible AI risk committee or the existing risk committee. *Responsible AI risk assessment pattern* can be used by the risk committee and project team to continuously assess the potential risks that could happen at each stage of the lifecycle of chatbots.

### Planning

At the planning stage, stakeholders such as business representatives and chatbot owners need to discuss the following aspects:

-   Overall purpose, such as customer service and internal help desk.

-   Viewpoint which supports the purpose of the chatbot and provides a consistent experience to the user, such as a financial service chatbot providing help to the branch customer.

-   Tone and personality, such as a pessimist or an optimist.

-   Proative or/and reactive nature depending on the purpose and viewpoint. proactive means actively taking the user towards a goal while reactive means letting the user lead the conversations by asking questions.

-   Name of the chatbot which can be the first thing a user will notice in the chat box.

-   Scenario describing brief narratives of anticipated use of a chatbot.

*Responsible AI risk assessment pattern* needs to be applied to examine whether the purpose or viewpoint or scenario is unethical, whether the tone or name is offensive to a group of people. *Ethical user story pattern* can be used to gather ethical requirements from stakeholders on the chatbot. An example user story can be "As an indigenous person, I want the chatbot to respond my questions in both English and indigenous language". The ethical user stories can be used to trace the ethical requirements both backward to the stakeholders who developed the ethical user stories and forward into the design modules, code pieces, and test cases. *Verifiable ethical requirement pattern* can be adopted to specify the ethical requirements in a verifiable form, e.g., "all the responses must be provided with multiple language options including indigenous language option".

### Conversation Design

At the stage of conversation design, content writers, who are subject matter experts, perform the following tasks to provide the best user interaction based on the understanding of user behaviour.

-   Further scenario development: The subject matter experts need to further define the scenarios that the chatbot is expected to fulfill.

-   Question analysis: In this step, the subject matter experts need to define what are the key questions for the chatbot to answer within the scenario defied. These key questions are built as intents in the chatbot later. The subject matter experts also need to provide questions that chatbot developers can use to train the chatbot for each key question/intent. Ideally, the training data are expected to be collected from existing data sources such as call centre logs. However, these existing data are not easy to get. Thus, the subject matter experts need to script or create the questions. For example, super business users in the business domain are grouped together and asked to think how they would ask the question as if they ask the questions to their colleagues or think of how they are asked for such type of questions in their day to day job. This group of uses are then asked to write down the questions for each key questions.

-   Content design: After defining the key questions, the subject matter experts need to write responses to be displayed to user by the chatbot.

-   Conversation flow design: Once the content is completed, the subject matter experts need to design the dialogues that mimic human interaction. This step also needs to consider requirements on escalation to human agent.

-   Interface design: Sometimes subject matter experts contribute to the design of user interface.

*Responsible AI risk assessment pattern* needs to be adopted to check if the defined scenarios describe any unethical narratives, whether the training data collected from existing data sources have any sensitive data or bias issue, whether the participated subject matter experts are diverse enough across gender, culture, race, age, expertise, etc. *Ethical user story pattern* can be used to collect the non-functional and ethical requirements for chatbot interface design, e.g., the chatbot interface design should consider the users who are colour blinded. *Data requirement throughout the entire lifecycle pattern* is important to ensure that the data requirements are specified explicitly throughout the data lifecycle including the model training stage which may involve training data collected from existing data sources or third parties. *Verifiable claim pattern* allows the developers to verify the ethical qualities of the training data which are associated with a verifiable claim on their ethical qualities. *Diverse team pattern* can be applied at the stage of conversation design. Building a diverse team of subject matter experts can effectively eliminate bias in responses and improve the design of dialogues. *Ethics training pattern* can be introduced to provide subject matter experts with knowledge and instructions on how to implement responsible AI in practice. *Human-centered interface design for explainable AI (XAI) pattern* is needed to provide helpful explanations to chatbot users, e.g., informing users that AI algorithms are used to generate responses.

### Implementation

After completing the conversation design, these "raw materials" are handed over to a developer to configure into the chatbot platform, i.e., IBM Watson Assistant in this study. The developer needs to do the following configurations.

-   Skill: A skill is created with the chatbot name.

-   Intents: Intents are configured for key questions provided by the subject matter experts. The intent is then trained with with utterances (sample questions) accordingly.

-   Entities: Entities are created to capture the context. For example, card type can be an entity class, while values can be credit card, debit card.

-   Dialogue: A dialogue is built to capture the responses in dialogue nodes. The conversation flow is configured by the flow control mechanism such as "jump to" and setting of Disambiguation or Digression.

-   Advanced features: The developer could turn on the advanced features depending on the use case and business requirements, e.g., intent recommendations which use machine learning to uncover common topics in existing catalogues to quickly train the chatbot on the most frequent issues and questions; auto-learning that allows business to learn from customer choices to improve the journey.

-   Integration with downstream systems: The developer integrates the responses with downstream systems.

*Responsible AI risk assessment pattern* is needed to examine whether there is any misconfiguration by developers or machine learning algorithms, whether there is any vulnerability in data integration or storage, whether there is any privacy or bias issue with the sample questions for training. *Customised agile process pattern* can be used to adapt the agile development process by incorporating responsible AI principles. Extension points could be artefacts, roles, ceremonies, practices, and culture. Ethical principles could be implemented through modifying the exiting artefacts (e.g., user stories) or adding new artefacts (e.g., regulatory requirements). There is also a need to promote responsible AI through existing roles (e.g., product) or new roles (e.g., ethicist). Similarly, modification of the existing ceremonies (e.g., sprint planning) or introduction of new ceremonies (e.g., ethics-oriented meetings) could be considered. Practices (e.g., user acceptance testing) and culture (e.g., hiring) are two effective ways to address ethical concerns in the agile development process. *Tight coupling of AI and non-AI development pattern* ensures the development of chatbot and other downstream systems are tightly coupled. The teams can share the same sprints and stand-up meetings, and use common co-versioning registry to manage the artifacts and track the progress. *AI mode switcher pattern* is required for the configurations made by the machine learning algorithms. All the suggested configurations need to be reviewed and approved by developers before being released into production. *Data requirements throughout the entire lifecycle pattern* can be used to describe the requirements on data collection/integration and storage taking into account all the involved roles. *Co-versioning registry pattern* can be used to capture the relationships and dependencies of conversation design materials and implementation configurations. *Ethical construction with reuse pattern* allows the developers to reuse the previous configurations (e.g., intents) that have passed the responsible AI risk assessment.

### Testing

This step is relatively straight forward. Conversations are tested with various testing methods such as unit testing, regression testing. *Responsible AI risk assessment pattern* can be used to check if there is any ethical risks with the test cases. Particularly, *ethical assessment for test cases* is required to assess all the test cases. *Ethical acceptance testing pattern* is needed to determine if the ethical requirements are met. Subject matter experts are involved in the testing process and perform the ethical acceptance testing.

### Deployment

In this step, the tested chatbot is deployed throughout the pipeline and released to production for end user to use. Oftentimes the final step to release to production needs to be approved by the chatbot owner or conversation owner. *Responsible AI risk assessment pattern* is needed to assess if there is any risk when integrating the chatbot with other systems and deploying the chatbot at scale. *Continuous deployment pattern* can be used to implement different deployment strategies. For example, phased deployment allows the chatbot to be only deployed for a subset group of users initially. The new version of chatbot rolls out incrementally and serves alongside the old version to reduce the ethical risk. *Standarized reporting pattern* is essential for governing AI systems. Organisations can setup standarized process and templates for informing the new release of chatbot to different stakeholders, such as financial service regulators and customers.

### Monitoring

In this step, the performance of chatbot is measured by multiple metrics, such as Net Promoter Score (NPS) value, feedback from user, effectiveness and coverage of conversation. Most of the chatbot platforms provide analytic capability. Various metrics can be chosen and applied depending on business cases and needs. Also, this step ensures the chatbot answers the right questions, answers the questions in a right way, and answers enough questions. For the proactive chatbot, it means the chatbot needs to take the right actions.

*Responsible AI risk assessment pattern* can be used to check if there are any missing or wrong metrics, whether there are any ethical issues in the questions from users and responses generated by chatbot, whether there is any bias in the results of user feedback. *Ethical black box pattern* can be used to continuously record the monitored data for improvement or auditing. Various approaches and methods can be applied to analyse the monitored data. Transaction review is one of the most popular methods for data analysis. When end users have conversation with the chatbot, the chat history can be captured and stored, e.g., by an immutable data ledger. Then all or a subset of the chat history can be review by the subject matter experts or auditors. *Independent oversight pattern* can be applied for auditing purposes Consistence issues need to be taken into consideration if multiple people perform the review as they may have different understanding. *K-fold cross validation pattern* and *blind testing pattern* can also be applied to evaluate the ethical performance of chatbot. These two patterns are new patterns we identified through the case study.

Once the analysis is completed, the developers configure and build the improvements required into the chatbot. The improvements can be as simple as retraining the chatbot or modifying the responses to provide more accurate and helpful responses in a responsible manner. It can also mean building new dialogue branches or responses that are required from the end users, or even integrating with new capability or other systems to provide more functionality for a new use case.

# CONCLUSION

In this article, we first discuss how we use a pattern-oriented approach to address the responsible AI challenges. Then, we evaluate the responsible AI pattern catalogue using the chatbot development use case. For future work, we plan to build an adapted version of responsible AI pattern catalogue for developing responsible chatbots and design a tool to support the navigation and utilisation of the pattern catalogue.

[^1]: <https://www.grandviewresearch.com/industry-analysis/artificial-intelligence-ai-market>

[^2]: <https://www.industry.gov.au/publications/australias-artificial-intelligence-ethics-framework/australias-ai-ethics-principles>

[^3]: <https://www.microsoft.com/en-us/haxtoolkit/>

[^4]: <https://pair.withgoogle.com/guidebook>

[^5]: <https://research.csiro.au/ss/science/projects/responsible-ai-pattern-catalogue/>


abstract: Liquid Argon Time Projection Chamber (LAr TPC) detectors are ideally suited for studying neutrino interactions and probing the parameters that characterize neutrino oscillations. The ability to drift ionization particles over long distances in purified argon and to trigger on abundant scintillation light allows for excellent particle identification and triggering capability. Recent U.S. based work in the development of LAr TPC technology for massive kiloton size detectors will be discussed in this talk, including details of the ArgoNeuT (Argon Neutrino Test) test-beam project, which is a 175 liter LAr TPC exposed to Fermilab's NuMI neutrino beamline.
address: Yale University
author: Mitchell Soderberg
title: Liquid-Argon Time Projection Chambers in the U.S. [^1]

# Introduction

Liquid Argon Time Projection Chamber (LAr TPC) detectors are an intriguing option for future neutrino experiments that will measure the properties of neutrino oscillations. The unique combination of position resolution, calorimetry, and scalability provided by LArTPCs make them a desirable technology choice for future massive detectors. These detectors are not without their challenges, among which the requirement of very clean argon stands out. With an interest in pursuing this technology for future massive detectors, several groups in the U.S. have been performing research and development of LArTPCs. In this paper several of the components of this research will be briefly described.

# LAr TPC Technique

The LArTPC technique has been around for several decades, with pioneering work done as part of the ICARUS experiment . A wire chamber is placed in highly-purified liquid argon, and an electric field is created within this detector. Particle interactions with the argon inside the detector volume produce ionization electrons that drift along the electric field until they reach the wireplanes, upon which they will produce signals that are utilized for imaging purposes. Applying proper bias voltages to the wireplanes allows several complementary views of the same interaction, providing the information necessary for three-dimensional event imaging. This technique allows for very precise imaging, the resolution being dependent on several factors such as: wire pitch, plane spacing, sampling rate, and electronics S/N levels. The technology is attractive in that the number of electronics channels required for the detector does not scale directly with the volume of the detector. This scaling feature, along with the relatively low cost of Argon, makes LArTPCs an intriguing option for future massive neutrino detectors.

One of the biggest challenges these detectors must address is producing Argon that is pure enough to allow the ionization to drift for the required distances. Several U.S. institutions have worked on developing new filters that can cleanse the Argon to the required levels necessary for a LArTPC experiment, and can also be regenerated when they have become saturated . These new filters are a necessary step along the path to massive detectors, and they also have allowed several teststands to be built in the U.S. with the goals of studying detector material effects on argon purity, and looking for cosmic-ray events in an LArTPC .

# ArgoNeuT

Collecting a sample of neutrino interactions in Argon is one of the early focuses of the U.S. LArTPC program, since such an event sample will be very useful for developing the software tools necessary for data analysis. The realization of this goal comes in the form of ArgoNeuT, a small test-beam project to put a LArTPC in a low-energy neutrino beam. The detector is a 175-liter TPC housed in a 500-liter cryostat, positioned in the on-axis NuMI beamline at Fermilab. As shown in Fig. , the detector is directly upstream of the MINOS near-detector, allowing muons exiting ArgoNeuT to range-out in MINOS and be recovered for analysis. The TPC, shown in Fig. , consists of 480 channels of electronic readout, distributed evenly between an induction plane and a collection plane. There is also an inner "shield" plane, which is not instrumented, that is used for electric field shaping. ArgoNeuT uses a closed-loop cryogenic recirculation system to continually cleanse the liquid Argon to the desired purity levels. ArgoNeuT had a $\approx$`<!-- -->`{=html}45 day commissioning run on the surface at Fermilab in the summer of 2008, during which many cosmic-ray muons were collected. Several improvements were made to the detector following this commissioning run, and as of May 2009 the detector is operational in the NuMI tunnel and recording neutrino interactions. ArgoNeuT will run through the end of 2009 in the NuMI beam, collecting several hundred neutrino interactions each day. Work is already underway to develop software tools for ArgoNeuT, and also to produce simulated event samples which can be used in data analysis.

## ArgoNeuT Electronics

ArgoNeuT uses new electronics, which is an important milestone for the development of LArTPCs in the U.S. A FET preamplifier similar to the D0/ICARUS front-end is utilized. A wide bandwith filter, from 10-200kHz, is applied to each channel. The philosophy is to record as much information as possible, and employ digital signal processing (DSP) offline to extract hit/track parameters. The electronics system has been built to minimize noise sources, including the preamplifiers being housed in a double-shielded Faraday cage which is cooled remotely via ducting. In addition the preamplifier power supplies have extensive DC power filtering built in.

# MicroBooNE

The next step in the U.S. LArTPC program is MicroBooNE, a proposed experiment that will help answer important physics questions and will also provide useful hardware development for future massive detectors. MicroBooNE consists of a $\approx$`<!-- -->`{=html}90 ton TPC which will sit in a 175ton cryostat. The TPC will contain 3 instrumented wireplanes with 3mm pitch, totaling approximately 10000 channels. This experiment will sit on the surface at Fermilab, and will be simultaneously exposed to the on-axis Booster neutrino beamline, and the off-axis NuMI beamline. MicroBooNE will utilize 30 cryogenic photomultiplier tubes that will provide a trigger which will be required in coincidence with a beam spill in order to reduce the data output of the experiment.

MicroBooNE will have several features that will provide valuable data for future massive LArTPC detectors. For example, MicroBooNE will place its preamplifier channels inside of the cryostat, in an 8$\%$ gas ullage at the top of the cryostat. The cold temperature of the ullage gas should allow the preamplifiers to operate with a S/N a factor of 3 better than room temperature performance. Placing the electronics inside the cryostat is likely to be a requirement for future massive detectors, which will have to do everything possible to combat noise incurred during the long transit a signal must make up and out of the very large detector. By amplifying the signal close to the source, noise levels in the data can be kept to a minimum.

Another interesting feature of the MicroBooNE experiment is a purity demonstration it will carry out, filling the cryostat with liquid after a gaseous purge instead of an initial vacuum pumpout. The goal of this is to determine whether or not the required argon purity can be achieved starting from a non-evacuated environment. This is crucial information needed in the design of massive detectors, which may be so large that they cannot be evacuated due to structural risks.

# Massive Detectors

Beyond MicroBooNE there is a desire to build a very massive ($\geq$`<!-- -->`{=html}5kton) LArTPC which would act as the far detector in a long-baseline neutrino experiment. Such a scenario is envisioned for the Deep Underground Science and Engineering Laboratory (DUSEL) located in Homestake, South Dakota. This facility offers the option of several different depths (100m, 1500m) at which a massive neutrino detector might be placed. DUSEL would ideally be combined with an intense neutrino beam emanating from Fermilab, 1300km away. The physics opportunities provided by the combination of the DUSEL depth and the Fermilab beam are quite extraordinary. A massive LArTPC detector could perform neutrino oscillation physics using the Fermilab beam, while simultaneously performing proton-decay searches and watching for supernova neutrinos.

Placing a massive LArTPC at such a depth will be a major feat of engineering. There are very serious safety considerations that must be addressed in order to mitigate the chance of any oxygen-deficiency situations arising from a leak. Maintaining the desired level of argon purity for $\geq$`<!-- -->`{=html}5 ktons of liquid will also be a tremendous challenge.

# Conclusion

There is a very active program of LArTPC development in the U.S., geared towards the goal of building a massive detector to study neutrino oscillation physics. Several test projects already exist in the U.S. to study Argon purity, and to collect a sizable sample of neutrino interactions that can be utilized to develop software tools. MicroBooNE is the next step in the U.S. for LArTPC development, and aside from performing interesting physics analyses, it will help answer several hardware questions that are important for future massive detectors.

[^1]: Presented at the 45th Winter School in Theoretical Physics "Neutrino Interactions: from Theory to Monte Carlo Simulations", Lądek-Zdrój, Poland, February 2–11, 2009.