<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="part2stratml.xsl"?>
<PerformancePlanOrReport xmlns="urn:ISO:std:iso:17469:tech:xsd:PerformancePlanOrReport" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

 xsi:schemaLocation="urn:ISO:std:iso:17469:tech:xsd:PerformancePlanOrReport http://stratml.us/references/PerformancePlanOrReport20160216.xsd" Type="Strategic_Plan"><Name>BLUEPRINT FOR AN AI BILL OF RIGHTS: MAKING AUTOMATED SYSTEMS WORK FOR THE AMERICAN PEOPLE</Name><Description>The Blueprint for an AI Bill of Rights is a set of five principles and associated practices to help guide the
design, use, and deployment of automated systems to protect the rights of the American public in the age of
artificial intel-ligence. Developed through extensive consultation with the American public, these principles are
a blueprint for building and deploying automated systems that are aligned with democratic values and protect
civil rights, civil liberties, and privacy.</Description><OtherInformation>The Blueprint for an AI Bill of Rights: Making Automated Systems Work for the American People was
published by the White House Office of Science and Technology Policy in October 2022. This framework was
released one year after OSTP announced the launch of a process to develop “a bill of rights for an AI-powered
world.” Its release follows a year of public engagement to inform this initiative. The framework is available
online at: https://www.whitehouse.gov/ostp/ai-bill-of-rights</OtherInformation><StrategicPlanCore><Organization><Name>The White House</Name><Acronym>TWH</Acronym><Identifier>_3a6bad5c-ad95-11ed-babb-fa59ff82ea00</Identifier><Description/><Stakeholder StakeholderTypeType="Organization"><Name>Office of Science and Technology Policy</Name><Description>The Office of Science and Technology Policy (OSTP) was established by the National Science and Technology Policy, Organization, and Priorities Act of 1976 to provide the President and others within the Executive Office of the President with advice on the scientific, engineering, and technological aspects of the economy, national security, health, foreign relations, the environment, and the technological recovery and use of resources, among other topics. OSTP leads interagency science and technology policy coordination efforts, assists the Office of Management and Budget (OMB) with an annual review and analysis of Federal research and development in budgets, and serves as a source of scientific and technological analysis and judgment for the President with respect to major policies, plans, and programs of the Federal Government.</Description></Stakeholder></Organization><Vision><Description>Automated systems are aligned with democratic values</Description><Identifier>_3a6bae60-ad95-11ed-babb-fa59ff82ea00</Identifier></Vision><Mission><Description>To help guide the design, use, and deployment of automated systems to protect the rights of the American public in the age of artificial intel-ligence</Description><Identifier>_3a6baeec-ad95-11ed-babb-fa59ff82ea00</Identifier></Mission><Value><Name>Safety</Name><Description>SAFE AND EFFECTIVE SYSTEMS ~ You should be protected from unsafe or ineffective systems. Automated systems should be developed with consultation
from diverse communities, stakeholders, and domain experts to identify concerns, risks, and potential impacts of the system. Systems
should undergo pre-deployment testing, risk identification and mitigation, and ongoing monitoring that demonstrate they are safe and
effective based on their intended use, mitigation of unsafe outcomes
including those beyond the intended use, and adherence to domain-specific standards. Outcomes of these protective measures
should include the possibility of not deploying the system or removing a system from use. Automated systems should not be designed
with an intent or reasonably foreseeable possibility of endangering
your safety or the safety of your community. They should be designed
to proactively protect you from harms stemming from unintended,
yet foreseeable, uses or impacts of automated systems. You should be
protected from inappropriate or irrelevant data use in the design, development, and deployment of automated systems, and from the
compounded harm of its reuse. Independent evaluation and reporting that confirms that the system is safe and effective, including re- porting of steps taken to mitigate potential harms, should be performed and the results made public whenever possible. </Description></Value><Value><Name>Effectiveness</Name><Description/></Value><Value><Name>Nondiscrimination</Name><Description>ALGORITHMIC DISCRIMINATION ~ Protections
You should not face discrimination by algorithms
and systems should be used and designed in an
equitable way. Algorithmic discrimination occurs when
automated systems contribute to unjustified different treatment or
impacts disfavoring people based on their race, color, ethnicity,
sex (including pregnancy, childbirth, and related medical
conditions, gender identity, intersex status, and sexual
orientation), religion, age, national origin, disability, veteran status,
genetic infor-mation, or any other classification protected by law.
Depending on the specific circumstances, such algorithmic
discrimination may violate legal protections. Designers, developers,
and deployers of automated systems should take proactive and
continuous measures to protect individuals and communities
from algorithmic discrimination and to use and design systems in
an equitable way. This protection should include proactive equity
assessments as part of the system design, use of representative data
and protection against proxies for demographic features, ensuring
accessibility for people with disabilities in design and development,
pre-deployment and ongoing disparity testing and mitigation, and
clear organizational oversight. Independent evaluation and plain
language reporting in the form of an algorithmic impact assessment,
including disparity testing results and mitigation information,
should be performed and made public whenever possible to confirm
these protections.</Description></Value><Value><Name>Data</Name><Description>DATA PRIVACY ~ You should be protected from abusive data practices via built-in
protections and you should have agency over how data about
you is used. You should be protected from violations of privacy through
design choices that ensure such protections are included by default, including
ensuring that data collection conforms to reasonable expectations and that
only data strictly necessary for the specific context is collected. Designers, developers, and deployers of automated systems should seek your permission
and respect your decisions regarding collection, use, access, transfer, and deletion of your data in appropriate ways and to the greatest extent possible;
where not possible, alternative privacy by design safeguards should be used.
Systems should not employ user experience and design decisions that obfuscate user choice or burden users with defaults that are privacy invasive. Consent should only be used to justify collection of data in cases where it can be
appropriately and meaningfully given. Any consent requests should be brief,
be understandable in plain language, and give you agency over data collection
and the specific context of use; current hard-to-understand notice-and-choice practices for broad uses of data should be changed. Enhanced
protections and restrictions for data and inferences related to sensitive domains, including health, work, education, criminal justice, and finance, and
for data pertaining to youth should put you first. In sensitive domains, your
data and related inferences should only be used for necessary functions, and
you should be protected by ethical review and use prohibitions. You and your
communities should be free from unchecked surveillance; surveillance technologies should be subject to heightened oversight that includes at least
pre-deployment assessment of their potential harms and scope limits to protect privacy and civil liberties. Continuous surveillance and monitoring
should not be used in education, work, housing, or in other contexts where the
use of such surveillance technologies is likely to limit rights, opportunities, or
access. Whenever possible, you should have access to reporting that confirms
your data decisions have been respected and provides an assessment of the
potential impact of surveillance technologies on your rights, opportunities, or
access. </Description></Value><Value><Name>Privacy</Name><Description/></Value><Value><Name>Sensitivity</Name><Description>EXTRA PROTECTIONS FOR DATA RELATED TO SENSITIVE
DOMAINS ~ Some domains, including health, employment, education, criminal justice, and personal finance, have long been
singled out as sensitive domains deserving of enhanced data protections. This is due to the intimate nature of these
domains as well as the inability of individuals to opt out of these domains in any meaningful way, and the
historical discrimination that has often accompanied data knowledge.69 Domains understood by the public to be
sensitive also change over time, including because of technological developments. Tracking and monitoring
technologies, personal tracking devices, and our extensive data footprints are used and misused more than ever
before; as such, the protections afforded by current legal guidelines may be inadequate. The American public
deserves assurances that data related to such sensitive domains is protected and used appropriately and only in
narrowly defined contexts with clear benefits to the individual and/or society.
^^
To this end, automated systems that collect, use, share, or store data related to these sensitive domains should meet
additional expectations. Data and metadata are sensitive if they pertain to an individual in a sensitive domain (defined
below); are generated by technologies used in a sensitive domain; can be used to infer data from a sensitive domain or
sensitive data about an individual (such as disability-related data, genomic data, biometric data, behavioral data,
geolocation data, data related to interaction with the criminal justice system, relationship history and legal status such
as custody and divorce information, and home, work, or school environmental data); or have the reasonable potential
to be used in ways that are likely to expose individuals to meaningful harm, such as a loss of privacy or financial harm
due to identity theft. Data and metadata generated by or about those who are not yet legal adults is also sensitive, even
if not related to a sensitive domain. Such data includes, but is not limited to, numerical, text, image, audio, or video
data. “Sensitive domains” are those in which activities being conducted can cause material harms, including significant adverse effects on human rights such as autonomy and dignity, as well as civil liberties and civil rights. Domains
that have historically been singled out as deserving of enhanced data protections or where such enhanced protections
are reasonably expected by the public include, but are not limited to, health, family planning and care, employment,
education, criminal justice, and personal finance. In the context of this framework, such domains are considered
sensitive whether or not the specifics of a system context would necessitate coverage under existing law, and domains
and data that are considered sensitive are understood to change over time based on societal norms and context. </Description></Value><Value><Name>Notice</Name><Description>NOTICE AND EXPLANATION ~ You should know that an automated system is being used,
and understand how and why it contributes to outcomes
that impact you. Designers, developers, and deployers of automated systems should provide generally accessible plain language documentation including clear descriptions of the overall system functioning and the role automation plays, notice that such systems are in
use, the individual or organization responsible for the system, and explanations of outcomes that are clear, timely, and accessible. Such
notice should be kept up-to-date and people impacted by the system
should be notified of significant use case or key functionality changes. You should know how and why an outcome impacting you was determined by an automated system, including when the automated
system is not the sole input determining the outcome. Automated
systems should provide explanations that are technically valid,
meaningful and useful to you and to any operators or others who
need to understand the system, and calibrated to the level of risk
based on the context. Reporting that includes summary information
about these automated systems in plain language and assessments of
the clarity and quality of the notice and explanations should be made
public whenever possible. </Description></Value><Value><Name>Explanation</Name><Description/></Value><Value><Name>Human Interaction</Name><Description>HUMAN ALTERNATIVES, CONSIDERATION, AND FALLBACK ~ You should be able to opt out, where appropriate, and
have access to a person who can quickly consider and
remedy problems you encounter. You should be able to opt
out from automated systems in favor of a human alternative, where
appropriate. Appropriateness should be determined based on reasonable expectations in a given context and with a focus on ensuring
broad accessibility and protecting the public from especially harmful impacts. In some cases, a human or other alternative may be required by law. You should have access to timely human consideration and remedy by a fallback and escalation process if an automated system fails, it produces an error, or you would like to appeal or
contest its impacts on you. Human consideration and fallback
should be accessible, equitable, effective, maintained, accompanied
by appropriate operator training, and should not impose an unreasonable burden on the public. Automated systems with an intended
use within sensitive domains, including, but not limited to, criminal
justice, employment, education, and health, should additionally be
tailored to the purpose, provide meaningful access for oversight,
include training for any people interacting with the system, and incorporate human consideration for adverse or high-risk decisions.
Reporting that includes a description of these human governance
processes and assessment of their timeliness, accessibility, outcomes, and effectiveness should be made public whenever possible.</Description></Value><Goal><Name>Safety &amp; Effectiveness</Name><Description>Eensure that automated systems are safe and effective</Description><Identifier>_3a6baf64-ad95-11ed-babb-fa59ff82ea00</Identifier><SequenceIndicator>1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>In order to ensure that an automated system is safe and effective, it should include safeguards to protect the
public from harm in a proactive and ongoing manner; avoid use of data inappropriate for or irrelevant to the task
at hand, including reuse that could cause compounded harm; and demonstrate the safety and effectiveness of
the system. These expectations are explained below. </OtherInformation><Objective><Name>Protection</Name><Description>Protect the public from harm in a proactive and ongoing manner</Description><Identifier>_3a6bafd2-ad95-11ed-babb-fa59ff82ea00</Identifier><SequenceIndicator>1.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Consultation. The public should be consulted in the design, implementation, deployment, acquisition, and
maintenance phases of automated system development, with emphasis on early-stage consultation before a
system is introduced or a large change implemented. This consultation should directly engage diverse impacted communities to consider concerns and risks that may be unique to those communities, or disproportionately prevalent or severe for them. The extent of this engagement and the form of outreach to relevant stakeholders may differ depending on the specific automated system and development phase, but should include
subject matter, sector-specific, and context-specific experts as well as experts on potential impacts such as
civil rights, civil liberties, and privacy experts. For private sector applications, consultations before product
launch may need to be confidential. Government applications, particularly law enforcement applications or
applications that raise national security considerations, may require confidential or limited engagement based
on system sensitivities and preexisting oversight laws and structures. Concerns raised in this consultation
should be documented, and the automated system developers were proposing to create, use, or deploy should
be reconsidered based on this feedback.


Testing. Systems should undergo extensive testing before deployment. This testing should follow
domain-specific best practices, when available, for ensuring the technology will work in its real-world
context. Such testing should take into account both the specific technology used and the roles of any human
operators or reviewers who impact system outcomes or effectiveness; testing should include both automated
systems testing and human-led (manual) testing. Testing conditions should mirror as closely as possible the
conditions in which the system will be deployed, and new testing may be required for each deployment to
account for material differences in conditions from one deployment to another. Following testing, system
performance should be compared with the in-place, potentially human-driven, status quo procedures, with
existing human performance considered as a performance baseline for the algorithm to meet pre-deployment,
and as a lifecycle minimum performance standard. Decision possibilities resulting from performance testing
should include the possibility of not deploying the system.


Risk identification and mitigation. Before deployment, and in a proactive and ongoing manner, potential risks of the automated system should be identified and mitigated. Identified risks should focus on the
potential for meaningful impact on people’s rights, opportunities, or access and include those to impacted
communities that may not be direct users of the automated system, risks resulting from purposeful misuse of
the system, and other concerns identified via the consultation process. Assessment and, where possible, measurement of the impact of risks should be included and balanced such that high impact risks receive attention
and mitigation proportionate with those impacts. Automated systems with the intended purpose of violating
the safety of others should not be developed or used; systems with such safety violations as identified unintended consequences should not be used until the risk can be mitigated. Ongoing risk mitigation may necessitate rollback or significant modification to a launched automated system. 

Ongoing monitoring. Automated systems should have ongoing monitoring procedures, including recalibration procedures, in place to ensure that their performance does not fall below an acceptable level over time,
based on changing real-world conditions or deployment contexts, post-deployment modification, or unexpected conditions. This ongoing monitoring should include continuous evaluation of performance metrics and
harm assessments, updates of any systems, and retraining of any machine learning models as necessary, as well
as ensuring that fallback mechanisms are in place to allow reversion to a previously working system. Monitoring should take into account the performance of both technical system components (the algorithm as well as
any hardware components, data inputs, etc.) and human operators. It should include mechanisms for testing
the actual accuracy of any predictions or recommendations generated by a system, not just a human operator’s
determination of their accuracy. Ongoing monitoring procedures should include manual, human-led monitoring as a check in the event there are shortcomings in automated monitoring systems. These monitoring procedures should be in place for the lifespan of the deployed automated system.


Clear organizational oversight. Entities responsible for the development or use of automated systems
should lay out clear governance structures and procedures. This includes clearly-stated governance procedures before deploying the system, as well as responsibility of specific individuals or entities to oversee ongoing
assessment and mitigation. Organizational stakeholders including those with oversight of the business process
or operation being automated, as well as other organizational divisions that may be affected due to the use of
the system, should be involved in establishing governance procedures. Responsibility should rest high enough
in the organization that decisions about resources, mitigation, incident response, and potential rollback can be
made promptly, with sufficient weight given to risk mitigation objectives against competing concerns. Those
holding this responsibility should be made aware of any use cases with the potential for meaningful impact on
people’s rights, opportunities, or access as determined based on risk identification procedures. In some cases,
it may be appropriate for an independent ethics review to be conducted before deployment. </OtherInformation></Objective><Objective><Name>Data Use &amp; Reuse</Name><Description>Avoid inappropriate, low-quality, or irrelevant data use and the compounded harm of its reuse</Description><Identifier>_0d69647a-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>1.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Relevant and high-quality data. Data used as part of any automated system’s creation, evaluation, or
deployment should be relevant, of high quality, and tailored to the task at hand. Relevancy should be
established based on research-backed demonstration of the causal influence of the data to the specific use case
or justified more generally based on a reasonable expectation of usefulness in the domain and/or for the
system design or ongoing development. Relevance of data should not be established solely by appealing to
its historical connection to the outcome. High quality and tailored data should be representative of the task at
hand and errors from data entry or other sources should be measured and limited. Any data used as the target
of a prediction process should receive particular attention to the quality and validity of the predicted outcome
or label to ensure the goal of the automated system is appropriately identified and measured. Additionally,
justification should be documented for each data attribute and source to explain why it is appropriate to use
that data to inform the results of the automated system and why such use will not violate any applicable laws.
In cases of high-dimensional and/or derived attributes, such justifications can be provided as overall
descriptions of the attribute generation process and appropriateness. 

Derived data sources tracked and reviewed carefully. Data that is derived from other data through
the use of algorithms, such as data derived or inferred from prior model outputs, should be identified and
tracked, e.g., via a specialized type in a data schema. Derived data should be viewed as potentially high-risk
inputs that may lead to feedback loops, compounded harm, or inaccurate results. Such sources should be carefully validated against the risk of collateral consequences.


Data reuse limits in sensitive domains. Data reuse, and especially data reuse in a new context, can result
in the spreading and scaling of harms. Data from some domains, including criminal justice data and data indicating adverse outcomes in domains such as finance, employment, and housing, is especially sensitive, and in
some cases its reuse is limited by law. Accordingly, such data should be subject to extra oversight to ensure
safety and efficacy. Data reuse of sensitive domain data in other contexts (e.g., criminal data reuse for civil legal
matters or private sector use) should only occur where use of such data is legally authorized and, after examination, has benefits for those impacted by the system that outweigh identified risks and, as appropriate, reasonable measures have been implemented to mitigate the identified risks. Such data should be clearly labeled to
identify contexts for limited reuse based on sensitivity. Where possible, aggregated datasets may be useful for
replacing individual-level sensitive data. </OtherInformation></Objective><Objective><Name>Demonstration</Name><Description>Demonstrate the safety and effectiveness of the systems</Description><Identifier>_0d6966d2-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>1.3</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Independent evaluation. Automated systems should be designed to allow for independent evaluation (e.g.,
via application programming interfaces). Independent evaluators, such as researchers, journalists, ethics
review boards, inspectors general, and third-party auditors, should be given access to the system and samples
of associated data, in a manner consistent with privacy, security, law, or regulation (including, e.g., intellectual
property law), in order to perform such evaluations. Mechanisms should be included to ensure that system
access for evaluation is: provided in a timely manner to the deployment-ready version of the system; trusted to
provide genuine, unfiltered access to the full system; and truly independent such that evaluator access cannot
be revoked without reasonable and verified justification.


Reporting.12 Entities responsible for the development or use of automated systems should provide
regularly-updated reports that include: an overview of the system, including how it is embedded in the
organization’s business processes or other activities, system goals, any human-run procedures that form a
part of the system, and specific performance expectations; a description of any data used to train machine
learning models or for other purposes, including how data sources were processed and interpreted, a
summary of what data might be missing, incomplete, or erroneous, and data relevancy justifications; the
results of public consultation such as concerns raised and any decisions made due to these concerns; risk
identification and management assessments and any steps taken to mitigate potential harms; the results of
performance testing including, but not limited to, accuracy, differential demographic impact, resulting
error rates (overall and per demographic group), and comparisons to previously deployed systems;
ongoing monitoring procedures and regular performance testing reports, including monitoring frequency,
results, and actions taken; and the procedures for and results from independent evaluations. Reporting
should be provided in a plain language and machine-readable manner. </OtherInformation></Objective></Goal><Goal><Name>Discrimination</Name><Description>Ensure automated systems are free from algorithmic discrimination</Description><Identifier>_0d696862-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Any automated system should be tested to help ensure it is free from algorithmic discrimination before it can be
sold or used. Protection against algorithmic discrimination should include designing to ensure equity, broadly
construed. Some algorithmic discrimination is already prohibited under existing anti-discrimination law. The
expectations set out below describe proactive technical and policy steps that can be taken to not only
reinforce those legal protections but extend beyond them to ensure equity for underserved communities
even in circumstances where a specific legal protection may not be clearly established. These protections
should be instituted throughout the design, development, and deployment process and are described below
roughly in the order in which they would be instituted. </OtherInformation><Objective><Name>Protection</Name><Description>Protect the public from algorithmic discrimination in a proactive and ongoing manner</Description><Identifier>_0d6969de-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>2.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Proactivity</Name><Description>Conduct proactive equity assessments</Description><Identifier>_0d696b0a-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>2.1.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Proactive assessment of equity in design. Those responsible for the development, use, or oversight of
automated systems should conduct proactive equity assessments in the design phase of the technology
research and development or during its acquisition to review potential input data, associated historical
context, accessibility for people with disabilities, and societal goals to identify potential discrimination and
effects on equity resulting from the introduction of the technology. The assessed groups should be as inclusive
as possible of the underserved communities mentioned in the equity definition: Black, Latino, and Indigenous
and Native American persons, Asian Americans and Pacific Islanders and other persons of color; members of
religious minorities; women, girls, and non-binary people; lesbian, gay, bisexual, transgender, queer, and intersex (LGBTQI+) persons; older adults; persons with disabilities; persons who live in rural areas; and persons
otherwise adversely affected by persistent poverty or inequality. Assessment could include both qualitative
and quantitative evaluations of the system. This equity assessment should also be considered a core part of the
goals of the consultation conducted as part of the safety and efficacy review.</OtherInformation></Objective><Objective><Name>Representation &amp; Robustness</Name><Description>Ensure data is representative and robust</Description><Identifier>_0d696c2c-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>2.1.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Representative and robust data. Any data used as part of system development or assessment should be
representative of local communities based on the planned deployment setting and should be reviewed for bias
based on the historical and societal context of the data. Such data should be sufficiently robust to identify and
help to mitigate biases and potential harms.</OtherInformation></Objective><Objective><Name>Proxies</Name><Description>Guard against proxies</Description><Identifier>_0d696e52-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>2.1.3</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Guarding against proxies. Directly using demographic information in the design, development, or
deployment of an automated system (for purposes other than evaluating a system for discrimination or using
a system to counter discrimination) runs a high risk of leading to algorithmic discrimination and should be
avoided. In many cases, attributes that are highly correlated with demographic features, known as proxies, can
contribute to algorithmic discrimination. In cases where use of the demographic features themselves would
lead to illegal algorithmic discrimination, reliance on such proxies in decision-making (such as that facilitated
by an algorithm) may also be prohibited by law. Proactive testing should be performed to identify proxies by
testing for correlation between demographic information and attributes in any data used as part of system
design, development, or use. If a proxy is identified, designers, developers, and deployers should remove the
proxy; if needed, it may be possible to identify alternative attributes that can be used instead. At a minimum,
organizations should ensure a proxy feature is not given undue weight and should monitor the system closely
for any resulting algorithmic discrimination.</OtherInformation></Objective><Objective><Name>Accessibility</Name><Description>Ensure accessibility</Description><Identifier>_0d696f92-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>2.1.4</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Ensuring accessibility during design, development, and deployment. Systems should be
designed, developed, and deployed by organizations in ways that ensure accessibility to people with disabilities. This should include consideration of a wide variety of disabilities, adherence to relevant accessibility
standards, and user experience research both before and after deployment to identify and address any accessibility barriers to the use or effectiveness of the automated system. </OtherInformation></Objective><Objective><Name>Disparities</Name><Description>Assess disparities</Description><Identifier>_0d6970be-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>2.1.5</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Disparity assessment. Automated systems should be tested using a broad set of measures to assess whether the system components, both in pre-deployment testing and in-context deployment, produce disparities.
The demographics of the assessed groups should be as inclusive as possible of race, color, ethnicity, sex
(including pregnancy, childbirth, and related medical conditions, gender identity, intersex status, and sexual
orientation), religion, age, national origin, disability, veteran status, genetic information, or any other classification protected by law. The broad set of measures assessed should include demographic performance measures, overall and subgroup parity assessment, and calibration. Demographic data collected for disparity
assessment should be separated from data used for the automated system and privacy protections should be
instituted; in some cases it may make sense to perform such assessment using a data sample. For every
instance where the deployed automated system leads to different treatment or impacts disfavoring the identified groups, the entity governing, implementing, or using the system should document the disparity and a
justification for any continued use of the system.</OtherInformation></Objective><Objective><Name>Mitigation</Name><Description>Mitigate disparities</Description><Identifier>_0d697208-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>2.1.6</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Disparity mitigation. When a disparity assessment identifies a disparity against an assessed group, it may
be appropriate to take steps to mitigate or eliminate the disparity. In some cases, mitigation or elimination of
the disparity may be required by law. Disparities that have the potential to lead to algorithmic
discrimination, cause meaningful harm, or violate equity49 goals should be mitigated. When designing and
evaluating an automated system, steps should be taken to evaluate multiple models and select the one that
has the least adverse impact, modify data input choices, or otherwise identify a system with fewer
disparities. If adequate mitigation of the disparity is not possible, then the use of the automated system
should be reconsidered. One of the considerations in whether to use the system should be the validity of any
target measure; unobservable targets may result in the inappropriate use of proxies. Meeting these
standards may require instituting mitigation procedures and other protective measures to address
algorithmic discrimination, avoid meaningful harm, and achieve equity goals</OtherInformation></Objective><Objective><Name>Monitoring</Name><Description>Regularly monitor to assess algorithmic discrimination</Description><Identifier>_0d697352-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>2.1.7</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Ongoing monitoring and mitigation. Automated systems should be regularly monitored to assess algorithmic discrimination that might arise from unforeseen interactions of the system with inequities not
accounted for during the pre-deployment testing, changes to the system after deployment, or changes to the
context of use or associated data. Monitoring and disparity assessment should be performed by the entity
deploying or using the automated system to examine whether the system has led to algorithmic discrimination when deployed. This assessment should be performed regularly and whenever a pattern of unusual
results is occurring. It can be performed using a variety of approaches, taking into account whether and how
demographic information of impacted people is available, for example via testing with a sample of users or via
qualitative user experience research. Riskier and higher-impact systems should be monitored and assessed
more frequently. Outcomes of this assessment should include additional disparity mitigation, if needed, or
fallback to earlier procedures in the case that equity standards are no longer met and can't be mitigated, and
prior mechanisms provide better adherence to equity standards.</OtherInformation></Objective><Objective><Name>Demonstration</Name><Description>Demonstrate that the system protects against algorithmic discrimination</Description><Identifier>_0d697492-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>2.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Evaluation</Name><Description>Independently evaluate potential algorithmic discrimination caused by automated systems </Description><Identifier>_0d69762c-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>2.2.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Independent evaluation. As described in the section on Safe and Effective Systems, entities should allow
independent evaluation of potential algorithmic discrimination caused by automated systems they use or
oversee. In the case of public sector uses, these independent evaluations should be made public unless law
enforcement or national security restrictions prevent doing so. Care should be taken to balance individual
privacy with evaluation data access needs; in many cases, policy-based and/or technological innovations and
controls allow access to such data without compromising privacy.</OtherInformation></Objective><Objective><Name>Reporting</Name><Description>Report algorithmic impact assessments</Description><Identifier>_0d69778a-ad9a-11ed-bdff-0f1a0083ea00</Identifier><SequenceIndicator>2.2.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Entities responsible for the development or use of automated systems should provide
reporting of an appropriately designed algorithmic impact assessment, with clear specification of who
performs the assessment, who evaluates the system, and how corrective actions are taken (if necessary) in
response to the assessment. This algorithmic impact assessment should include at least: the results of any
consultation, design stage equity assessments (potentially including qualitative analysis), accessibility
designs and testing, disparity testing, document any remaining disparities, and detail any mitigation
implementation and assessments. This algorithmic impact assessment should be made public whenever
possible. Reporting should be provided in a clear and machine-readable manner using plain language to
allow for more straightforward public accountability. </OtherInformation></Objective></Goal><Goal><Name>Privacy</Name><Description>Protect privacy</Description><Identifier>_215fac30-ad9c-11ed-9cd3-7b5c0083ea00</Identifier><SequenceIndicator>3</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Traditional terms of service—the block of text that the public is accustomed to clicking through when using a website or digital app—are not an adequate mechanism for protecting privacy. The American public should be protected via built-in privacy protections, data minimization, use and collection limitations, and transparency, in addition
to being entitled to clear mechanisms to control access to and use of their data—including their metadata—in a
proactive, informed, and ongoing way. Any automated system collecting, using, sharing, or storing personal data
should meet these expectations. </OtherInformation><Objective><Name>Design &amp; Default</Name><Description>Protect privacy by design and by default</Description><Identifier>_215fb54a-ad9c-11ed-9cd3-7b5c0083ea00</Identifier><SequenceIndicator>3.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Privacy by design and by default. Automated systems should be designed and built with privacy protected by default. Privacy risks should be assessed throughout the development life cycle, including privacy risks
from reidentification, and appropriate technical and policy mitigation measures should be implemented. This
includes potential harms to those who are not users of the automated system, but who may be harmed by
inferred data, purposeful privacy violations, or community surveillance or other community harms. Data
collection should be minimized and clearly communicated to the people whose data is collected. Data should
only be collected or used for the purposes of training or testing machine learning models if such collection and
use is legal and consistent with the expectations of the people whose data is collected. User experience
research should be conducted to confirm that people understand what data is being collected about them and
how it will be used, and that this collection matches their expectations and desires.</OtherInformation></Objective><Objective><Name>Goals</Name><Description>Limit data collection in scope, with specific, narrow identified goals</Description><Identifier>_215fb6ee-ad9c-11ed-9cd3-7b5c0083ea00</Identifier><SequenceIndicator>3.1.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Data collection and use-case scope limits. Data collection should be limited in scope, with specific,
narrow identified goals, to avoid "mission creep." Anticipated data collection should be determined to be
strictly necessary to the identified goals and should be minimized as much as possible. Data collected based on
these identified goals and for a specific context should not be used in a different context without assessing for
new privacy risks and implementing appropriate mitigation measures, which may include express consent.
Clear timelines for data retention should be established, with data deleted as soon as possible in accordance
with legal or policy-based limitations. Determined data retention timelines should be documented and justified. </OtherInformation></Objective><Objective><Name>Risks &amp; Harms</Name><Description>Proactively identify harms and seek to manage them so as to avoid, mitigate, and respond appropriately to identified risks</Description><Identifier>_215fb888-ad9c-11ed-9cd3-7b5c0083ea00</Identifier><SequenceIndicator>3.1.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Risk identification and mitigation. Entities that collect, use, share, or store sensitive data should
attempt to proactively identify harms and seek to manage them so as to avoid, mitigate, and respond appropriately to identified risks. Appropriate responses include determining not to process data when the privacy risks
outweigh the benefits or implementing measures to mitigate acceptable risks. Appropriate responses do not
include sharing or transferring the privacy risks to users via notice or consent requests where users could not
reasonably be expected to understand the risks without further support. </OtherInformation></Objective><Objective><Name>Use Cases</Name><Description>Follow privacy and security best practices to ensure data and metadata do not leak beyond the specific consented use case</Description><Identifier>_215fba04-ad9c-11ed-9cd3-7b5c0083ea00</Identifier><SequenceIndicator>3.1.3</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Privacy-preserving security. Entities creating, using, or governing automated systems should follow
privacy and security best practices designed to ensure data and metadata do not leak beyond the specific
consented use case. Best practices could include using privacy-enhancing cryptography or other types of
privacy-enhancing technologies or fine-grained permissions and access control mechanisms, along with
conventional system security protocols. </OtherInformation></Objective><Objective><Name>Surveillance</Name><Description>Protect the public from unchecked surveillance</Description><Identifier>_215fbb80-ad9c-11ed-9cd3-7b5c0083ea00</Identifier><SequenceIndicator>3.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Oversight</Name><Description>Subject surveillance and monitoring systems to heightened oversight</Description><Identifier>_215fbd1a-ad9c-11ed-9cd3-7b5c0083ea00</Identifier><SequenceIndicator>3.2.1</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Heightened oversight of surveillance. Surveillance or monitoring systems should be subject to
heightened oversight that includes at a minimum assessment of potential harms during design (before deployment) and in an ongoing manner, to ensure that the American public’s rights, opportunities, and access are
protected. This assessment should be done before deployment and should give special attention to ensure
there is not algorithmic discrimination, especially based on community membership, when deployed in a
specific real-world context. Such assessment should then be reaffirmed in an ongoing manner as long as the
system is in use. </OtherInformation></Objective><Objective><Name>Necessity &amp; Proportionality</Name><Description>Avoid surveillance unless it is strictly necessary to achieve a legitimate purpose and it is proportionate to the need</Description><Identifier>_215fbe96-ad9c-11ed-9cd3-7b5c0083ea00</Identifier><SequenceIndicator>3.2.2</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Limited and proportionate surveillance. Surveillance should be avoided unless it is strictly necessary
to achieve a legitimate purpose and it is proportionate to the need. Designers, developers, and deployers of
surveillance systems should use the least invasive means of monitoring available and restrict monitoring to the
minimum number of subjects possible. To the greatest extent possible consistent with law enforcement and
national security needs, individuals subject to monitoring should be provided with clear and specific notice
before it occurs and be informed about how the data gathered through surveillance will be used. </OtherInformation></Objective><Objective><Name>Scope</Name><Description>Limit the scope of surveillance to protect rights and democratic values</Description><Identifier>_215fc0bc-ad9c-11ed-9cd3-7b5c0083ea00</Identifier><SequenceIndicator>3.2.3</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>Scope limits on surveillance to protect rights and democratic values. Civil liberties and civil
rights must not be limited by the threat of surveillance or harassment facilitated or aided by an automated
system. Surveillance systems should not be used to monitor the exercise of democratic rights, such as voting,
privacy, peaceful assembly, speech, or association, in a way that limits the exercise of civil rights or civil liberties. Information about or algorithmically-determined assumptions related to identity should be carefully
limited if used to target or guide surveillance systems in order to avoid algorithmic discrimination; such identity-related information includes group characteristics or affiliations, geographic designations, location-based
and association-based inferences, social networks, and biometrics. Continuous surveillance and monitoring
systems should not be used in physical or digital workplaces (regardless of employment status), public educational institutions, and public accommodations. Continuous surveillance and monitoring systems should not
be used in a way that has the effect of limiting access to critical resources or services or suppressing the exercise of rights, even where the organization is not under a particular duty to protect those rights.</OtherInformation></Objective><Objective><Name>Consent, Access &amp; Control</Name><Description>Provide the public with mechanisms for appropriate and meaningful consent, access, and control over their data</Description><Identifier>_4b4a1df2-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>3.3</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name>The Public</Name><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Specificity</Name><Description>Seek consent specific, narrow use contexts, for specific time durations, and for use by specific entities</Description><Identifier>_4b4a2874-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>3.3.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Use-specific consent. Consent practices should not allow for abusive surveillance practices. Where data
collectors or automated systems seek consent, they should seek it for specific, narrow use contexts, for specific time durations, and for use by specific entities. Consent should not extend if any of these conditions change;
consent should be re-acquired before using data if the use case changes, a time limit elapses, or data is transferred to another entity (including being shared or sold). Consent requested should be limited in scope and
should not request consent beyond what is required. Refusal to provide consent should be allowed, without
adverse effects, to the greatest extent possible based on the needs of the use case. </OtherInformation></Objective><Objective><Name>Readability &amp; Comprehensibility</Name><Description>Make consent requests brief and direct</Description><Identifier>_4b4a2f40-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>3.3.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Brief and direct consent requests. When seeking consent from users short, plain language consent
requests should be used so that users understand for what use contexts, time span, and entities they are
providing data and metadata consent. User experience research should be performed to ensure these consent
requests meet performance standards for readability and comprehension. This includes ensuring that consent
requests are accessible to users with disabilities and are available in the language(s) and reading level appropriate for the audience. User experience design choices that intentionally obfuscate or manipulate user
choice (i.e., “dark patterns”) should be not be used.</OtherInformation></Objective><Objective><Name>Access &amp; Correction</Name><Description>Enable people to access and correct data about them</Description><Identifier>_4b4a3742-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>3.3.3</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Data access and correction. People whose data is collected, used, shared, or stored by automated
systems should be able to access data and metadata about themselves, know who has access to this data, and
be able to correct it if necessary. Entities should receive consent before sharing data with other entities and
should keep records of what data is shared and with whom.</OtherInformation></Objective><Objective><Name>Withdrawal</Name><Description>Allow withdrawal of data access consent</Description><Identifier>_4b4a3a9e-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>3.3.4</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Consent withdrawal and data deletion. Entities should allow (to the extent legally permissible) withdrawal of data access consent, resulting in the deletion of user data, metadata, and the timely removal of
their data from any systems (e.g., machine learning models) derived from that data.</OtherInformation></Objective><Objective><Name>Automated Systems</Name><Description>Allow individuals to use their own automated systems to help them make consent, access, and control decisions in a complex data ecosystem</Description><Identifier>_4b4a3ddc-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>3.3.5</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Automated system support. Entities designing, developing, and deploying automated systems should
establish and maintain the capabilities that will allow individuals to use their own automated systems to help
them make consent, access, and control decisions in a complex data ecosystem. Capabilities include machine
readable data, standardized data formats, metadata or tags for expressing data processing permissions and
preferences and data provenance and lineage, context of use and access-specific tags, and training models for
assessing privacy risk. </OtherInformation></Objective><Objective><Name>Demonstration</Name><Description>Demonstrate that data privacy and user control are protected</Description><Identifier>_4b4a4520-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>3.6</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Evaluation</Name><Description>Independently evaluate claims regarding data policies</Description><Identifier>_4b4a4886-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>3.6.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Independent evaluation. As described in the section on Safe and Effective Systems, entities should allow
independent evaluation of the claims made regarding data policies. These independent evaluations should be
made public whenever possible. Care will need to be taken to balance individual privacy with evaluation data
access needs. </OtherInformation></Objective><Objective><Name>Reporting</Name><Description>Respond quickly when members of the public wish to know what data about them is being used</Description><Identifier>_4b4a4b24-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>3.6.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name>Members of the Public</Name><Description/></Stakeholder><OtherInformation>When members of the public wish to know what data about them is being used in a system, the
entity responsible for the development of the system should respond quickly with a report on the data it has
collected or stored about them. Such a report should be machine-readable, understandable by most users, and
include, to the greatest extent allowable under law, any data and metadata about them or collected from them,
when and how their data and metadata were collected, the specific ways that data or metadata are being used,
who has access to their data and metadata, and what time limitations apply to these data. In cases where a user
login is not available, identity verification may need to be performed before providing such a report to ensure
user privacy. Additionally, summary reporting should be proactively made public with general information
about how peoples’ data and metadata is used, accessed, and stored. Summary reporting should include the
results of any surveillance pre-deployment assessment, including disparity assessment in the real-world
deployment context, the specific identified goals of any data collection, and the assessment done to ensure
only the minimum required data is collected. It should also include documentation about the scope limit
assessments, including data retention timelines and associated justification, and an assessment of the
impact of surveillance or data collection on rights, opportunities, and access. Where possible, this
assessment of the impact of surveillance should be done by an independent party. Reporting should be
provided in a clear and machine-readable manner. </OtherInformation></Objective></Goal><Goal><Name>Sensitive Data</Name><Description>Provide enhanced protections for data related to sensitive domains</Description><Identifier>_4b4a5146-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>4</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>In addition to the privacy expectations above for general non-sensitive data, any system collecting, using, sharing, or storing sensitive data should meet the expectations below. Depending on the technological use case and
based on an ethical assessment, consent for sensitive data may need to be acquired from a guardian and/or child. </OtherInformation><Objective><Name>Necessity</Name><Description>Use sensitive only functions strictly necessary</Description><Identifier>_4b4a54ac-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>4.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Necessary functions only. Sensitive data should only be used for functions strictly necessary for that
domain or for functions that are required for administrative reasons (e.g., school attendance records), unless
consent is acquired, if appropriate, and the additional expectations in this section are met. Consent for nonnecessary functions should be optional, i.e., should not be required, incentivized, or coerced in order to
receive opportunities or access to services. In cases where data is provided to an entity (e.g., health insurance
company) in order to facilitate payment for such a need, that data should only be used for that purpose.</OtherInformation></Objective><Objective><Name>Ethics &amp; Prohibitions</Name><Description>Conduct ethical reviews and consider use prohibitions</Description><Identifier>_4b4a5754-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>4.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Ethical review and use prohibitions. Any use of sensitive data or decision process based in part on sensitive data that might limit rights, opportunities, or access, whether the decision is automated or not, should go
through a thorough ethical review and monitoring, both in advance and by periodic review (e.g., via an independent ethics committee or similarly robust process). In some cases, this ethical review may determine that data
should not be used or shared for specific uses even with consent. Some novel uses of automated systems in this
context, where the algorithm is dynamically developing and where the science behind the use case is not well
established, may also count as human subject experimentation, and require special review under organizational
compliance bodies applying medical, scientific, and academic human subject experimentation ethics rules and
governance procedures. </OtherInformation></Objective><Objective><Name>Data Quality</Name><Description>Maintain the quality of data</Description><Identifier>_4b4a5d76-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>4.3</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Data quality. In sensitive domains, entities should be especially careful to maintain the quality of data to
avoid adverse consequences arising from decision-making based on flawed or inaccurate data. Such care is
necessary in a fragmented, complex data ecosystem and for datasets that have limited access such as for fraud
prevention and law enforcement. It should be not left solely to individuals to carry the burden of reviewing and
correcting data. Entities should conduct regular, independent audits and take prompt corrective measures to
maintain accurate, timely, and complete data. </OtherInformation></Objective><Objective><Name>Access</Name><Description>Limit access to sensitive data and derived data</Description><Identifier>_4b4a6118-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>4.4</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Sensitive data and derived data should not be sold,
shared, or made public as part of data brokerage or other agreements. Sensitive data includes data that can be
used to infer sensitive information; even systems that are not directly marketed as sensitive domain technologies
are expected to keep sensitive data private. Access to such data should be limited based on necessity and based
on a principle of local control, such that those individuals closest to the data subject have more access while
those who are less proximate do not (e.g., a teacher has access to their students’ daily progress data while a
superintendent does not). </OtherInformation></Objective><Objective><Name>Reporting</Name><Description>Regularly provide public reports in a clear and machine-readable manner</Description><Identifier>_4b4a63de-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>4.5</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>In addition to the reporting on data privacy (as listed above for non-sensitive data), entities developing technologies related to a sensitive domain and those collecting, using, storing, or sharing sensitive data
should, whenever appropriate, regularly provide public reports describing: any data security lapses or breaches
that resulted in sensitive data leaks; the number, type, and outcomes of ethical pre-reviews undertaken; a
description of any data sold, shared, or made public, and how that data was assessed to determine it did not present a sensitive data risk; and ongoing risk identification and management procedures, and any mitigation added
based on these procedures. Reporting should be provided in a clear and machine-readable manner. </OtherInformation></Objective><Objective><Name>Leaks</Name><Description>Describe any data security lapses or breaches that resulted in sensitive data leaks</Description><Identifier>_4b4a6956-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>4.5.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Pre-Reviews</Name><Description>Describe the number, type, and outcomes of ethical pre-reviews undertaken</Description><Identifier>_4b4a6d98-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>4.5.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Release</Name><Description>Describe any data sold, shared, or made public, and how that data was assessed to determine it did not present a sensitive data risk</Description><Identifier>_4b4a705e-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>4.5.3</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Risk</Name><Description>Describe ongoing risk identification and management procedures, and any mitigation added based on these procedures</Description><Identifier>_4b4a782e-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>4.5.4</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective></Goal><Goal><Name>Notice &amp; Explanation</Name><Description/><Identifier>_4b4a7bda-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>An automated system should provide demonstrably clear, timely, understandable, and accessible notice of use, and explanations as to how and why a decision was made or an action was taken by the system. These expectations are explained below. </OtherInformation><Objective><Name>Clarity &amp; Timeliness</Name><Description>Provide clear, timely, understandable, and accessible notice of use and explanations</Description><Identifier>_4b4a7ebe-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Documentation</Name><Description>Ensure that documentation describing the overall system is public and easy to find</Description><Identifier>_4b4a8558-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5.1.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Generally accessible plain language documentation. The entity responsible for using the automated system should ensure that documentation describing the overall system (including any human components) is public and easy to find. The documentation should describe, in plain language, how the system works and how any automated component is used to determine an action or decision. It should also include expectations about reporting described throughout this framework, such as the algorithmic impact assessments described as
part of Algorithmic Discrimination Protections. </OtherInformation></Objective><Objective><Name>Accountability</Name><Description>Clearly identify the entities responsible for designing each component of the systems and the entities using them</Description><Identifier>_4b4a894a-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5.1.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Accountable. Notices should clearly identify the entity responsible for designing each component of the system and the entity using it. 
</OtherInformation></Objective><Objective><Name>Timeliness &amp; Currency</Name><Description>Ensure that notices are timely and up-to-date</Description><Identifier>_4b4a8c38-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5.1.3</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Timely and up-to-date. Users should receive notice of the use of automated systems in advance of using or
while being impacted by the technology. An explanation should be available with the decision itself, or soon
thereafter. Notice should be kept up-to-date and people impacted by the system should be notified of use case
or key functionality changes. </OtherInformation></Objective><Objective><Name>Brevity &amp; Clarity</Name><Description>Ensure that those using or impacted by the automated system are able to easily
find notices and explanations, read them quickly, and understand and act on them</Description><Identifier>_4b4a930e-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5.1.4</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Brief and clear. Notices and explanations should be assessed, such as by research on users’ experiences,
including user testing, to ensure that the people using or impacted by the automated system are able to easily
find notices and explanations, read them quickly, and understand and act on them. This includes ensuring that
notices and explanations are accessible to users with disabilities and are available in the language(s) and reading level appropriate for the audience. Notices and explanations may need to be available in multiple forms,
(e.g., on paper, on a physical sign, or online), in order to meet these expectations and to be accessible to the
American public. </OtherInformation></Objective><Objective><Name>Explanation</Name><Description>Provide explanations as to how and why a decision was made or an action was taken by an automated system</Description><Identifier>_4b4a96b0-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Purposes</Name><Description>Tailor and clearly state the purposes for which users are expected to use explanations</Description><Identifier>_4b4a9994-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5.2.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Tailored to the purpose. Explanations should be tailored to the specific purpose for which the user is
expected to use the explanation, and should clearly state that purpose. An informational explanation might
differ from an explanation provided to allow for the possibility of recourse, an appeal, or one provided in the
context of a dispute or contestation process. For the purposes of this framework, 'explanation' should be
construed broadly. An explanation need not be a plain-language statement about causality but could consist of
any mechanism that allows the recipient to build the necessary understanding and intuitions to achieve the
stated purpose. Tailoring should be assessed (e.g., via user experience research). </OtherInformation></Objective><Objective><Name>Targeting</Name><Description>Tailor explanation to their targets</Description><Identifier>_4b4aa038-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5.2.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Tailored to the target of the explanation. Explanations should be targeted to specific audiences and
clearly state that audience. An explanation provided to the subject of a decision might differ from one provided
to an advocate, or to a domain expert or decision maker. Tailoring should be assessed (e.g., via user experience
research). </OtherInformation></Objective><Objective><Name>Risk</Name><Description>Tailor assessments to the levels of risk</Description><Identifier>_4b4aa40c-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5.2.3</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Tailored to the level of risk. An assessment should be done to determine the level of risk of the automated system. In settings where the consequences are high as determined by a risk assessment, or extensive
oversight is expected (e.g., in criminal justice or some public sector settings), explanatory mechanisms should
be built into the system design so that the system’s full behavior can be explained in advance (i.e., only fully
transparent models should be used), rather than as an after-the-decision interpretation. In other settings, the
extent of explanation provided should be tailored to the risk level. </OtherInformation></Objective><Objective><Name>Validity</Name><Description>Accurately reflect the factors and the influences leading to decisions</Description><Identifier>_4b4aa7a4-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5.3.4</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Valid. The explanation provided by a system should accurately reflect the factors and the influences that led
to a particular decision, and should be meaningful for the particular customization based on purpose, target,
and level of risk. While approximation and simplification may be necessary for the system to succeed based on
the explanatory purpose and target of the explanation, or to account for the risk of fraud or other concerns
related to revealing decision-making information, such simplifications should be done in a scientifically
supportable way. Where appropriate based on the explanatory system, error ranges for the explanation should
be calculated and included in the explanation, with the choice of presentation of such information balanced
with usability and overall interface complexity concerns. </OtherInformation></Objective><Objective><Name>Demonstration</Name><Description>Demonstrate protections for notice and explanation</Description><Identifier>_4b4aad76-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5.4</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Reporting</Name><Description>Document the determinations made</Description><Identifier>_4b4ab136-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>5.4.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Summary reporting should document the determinations made based on the above considerations, including: the responsible entities for accountability purposes; the goal and use cases for the system,
identified users, and impacted populations; the assessment of notice clarity and timeliness; the assessment of
the explanation's validity and accessibility; the assessment of the level of risk; and the account and assessment
of how explanations are tailored, including to the purpose, the recipient of the explanation, and the level of
risk. Individualized profile information should be made readily available to the greatest extent possible that
includes explanations for any system impacts or inferences. Reporting should be provided in a clear plain
language and machine-readable manner. </OtherInformation></Objective></Goal><Goal><Name>Human Interaction</Name><Description>Support human interactions</Description><Identifier>_4b4ab424-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6</SequenceIndicator><Stakeholder><Name/><Description/></Stakeholder><OtherInformation>An automated system should provide demonstrably effective mechanisms to opt out in favor of a human alternative, where appropriate, as well as timely human consideration and remedy by a fallback system, with additional
human oversight and safeguards for systems used in sensitive domains, and with training and assessment for any
human-based portions of the system to ensure effectiveness. </OtherInformation><Objective><Name>Opt-Out</Name><Description>Provide a mechanism to conveniently opt out from automated systems in favor of a human alternative, where appropriate</Description><Identifier>_4b4abae6-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Notices &amp; Instructions</Name><Description>Provide brief, clear, accessible notice and instructions</Description><Identifier>_4b4abe9c-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.1.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Brief, clear, accessible notice and instructions. Those impacted by an automated system should be
given a brief, clear notice that they are entitled to opt-out, along with clear instructions for how to opt-out.
Instructions should be provided in an accessible form and should be easily findable by those impacted by the
automated system. The brevity, clarity, and accessibility of the notice and instructions should be assessed (e.g.,
via user experience research).</OtherInformation></Objective><Objective><Name>Human Alternatives</Name><Description>Provide human alternatives when appropriate</Description><Identifier>_4b4ac234-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.1.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Human alternatives provided when appropriate. In many scenarios, there is a reasonable expectation
of human involvement in attaining rights, opportunities, or access. When automated systems make up part of
the attainment process, alternative timely human-driven processes should be provided. The use of a human
alternative should be triggered by an opt-out process.</OtherInformation></Objective><Objective><Name>Timeliness &amp; Burden</Name><Description>Ensure that human alternatives are timely and not unreasonably burdensome</Description><Identifier>_4b4ac81a-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.1.3</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Timely and not burdensome human alternative. Opting out should be timely and not unreasonably burdensome in both the process of requesting to opt-out and the human-driven alternative provided. </OtherInformation></Objective><Objective><Name>Fallback &amp; Escalation</Name><Description>Provide timely human consideration and remedy by a fallback and escalation system in the event that an automated system fails, produces error, or you would like to appeal or contest its impacts on you</Description><Identifier>_4b4acbda-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Proportionality</Name><Description>Ensure the availability of human consideration and fallback is proportionate to the potential of the automated system to meaningfully impact rights, opportunities, or access</Description><Identifier>_4b4acfae-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.2.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Proportionate. The availability of human consideration and fallback, along with associated training and
safeguards against human bias, should be proportionate to the potential of the automated system to meaningfully impact rights, opportunities, or access. Automated systems that have greater control over outcomes,
provide input to high-stakes decisions, relate to sensitive domains, or otherwise have a greater potential to
meaningfully impact rights, opportunities, or access should have greater availability (e.g., staffing) and oversight of human consideration and fallback mechanisms.</OtherInformation></Objective><Objective><Name>Accessibility</Name><Description>Ensure that mechanisms for human consideration and fallback are easy to find and use</Description><Identifier>_4b4ad788-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.2.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Accessible. Mechanisms for human consideration and fallback, whether in-person, on paper, by phone, or
otherwise provided, should be easy to find and use. These mechanisms should be tested to ensure that users
who have trouble with the automated system are able to use human consideration and fallback, with the understanding that it may be these users who are most likely to need the human assistance. Similarly, it should be
tested to ensure that users with disabilities are able to find and use human consideration and fallback and also
request reasonable accommodations or modifications. </OtherInformation></Objective><Objective><Name>Convenience</Name><Description>Ensure that mechanisms for human consideration and fallback are not unreasonably burdensome</Description><Identifier>_4b4adb8e-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.2.3</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Convenient. Mechanisms for human consideration and fallback should not be unreasonably burdensome as compared to the automated system’s equivalent. </OtherInformation></Objective><Objective><Name>Equity</Name><Description>Ensure outcomes of fallback and escalation systems are equitable</Description><Identifier>_4b4ade90-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.2.4</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Equitable. Consideration should be given to ensuring outcomes of the fallback and escalation system are equitable when compared to those of the automated system and such that the fallback and escalation system provides equitable access to underserved communities.</OtherInformation></Objective><Objective><Name>Timeliness</Name><Description>Ensure that human consideration and fallback are conducted and concluded in a
timely manner</Description><Identifier>_4b4ae5ca-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.2.5</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Timely. Human consideration and fallback are only useful if they are conducted and concluded in a
timely manner. The determination of what is timely should be made relative to the specific automated
system, and the review system should be staffed and regularly assessed to ensure it is providing timely
consideration and fallback. In time-critical systems, this mechanism should be immediately available or,
where possible, available before the harm occurs. Time-critical systems include, but are not limited to,
voting-related systems, automated building access and other access systems, systems that form a critical
component of healthcare, and systems that have the ability to withhold wages or otherwise cause
immediate financial penalties. </OtherInformation></Objective><Objective><Name>Effectiveness</Name><Description>Ensure that new decisions are effectively enacted if human decision-makers determine automated decisions should be overruled</Description><Identifier>_4b4aea7a-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.2.6</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Effective. The organizational structure surrounding processes for consideration and fallback should
be designed so that if the human decision-maker charged with reassessing a decision determines that it
should be overruled, the new decision will be effectively enacted. This includes ensuring that the new
decision is entered into the automated system throughout its components, any previous repercussions from
the old decision are also overturned, and safeguards are put in place to help ensure that future decisions do
not result in the same errors. </OtherInformation></Objective><Objective><Name>Maintenance</Name><Description>Maintain and support the human consideration and fallback process for as long as the relevant automated systems continue to be used</Description><Identifier>_4b4aedc2-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.2.7</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Maintained. The human consideration and fallback process and any associated automated processes should be maintained and supported as long as the relevant automated system continues to be in use.</OtherInformation></Objective><Objective><Name>Training, Assessment &amp; Oversight </Name><Description>Institute training, assessment, and oversight to combat automation bias and ensure any human-based components of a system are effective.</Description><Identifier>_4b4af43e-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.3</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Training &amp; Assessment</Name><Description>Train those administering, interacting with, or interpreting the outputs of automated systems on how to interpret outputs in light of the intended purposes and how to mitigate the effects of automation bias</Description><Identifier>_4b4af902-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.3.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Training and assessment. Anyone administering, interacting with, or interpreting the outputs of an automated system should receive training in that system, including how to properly interpret outputs of a system
in light of its intended purpose and in how to mitigate the effects of automation bias. The training should reoccur regularly to ensure it is up to date with the system and to ensure the system is used appropriately. Assessment should be ongoing to ensure that the use of the system with human involvement provides for appropriate results, i.e., that the involvement of people does not invalidate the system's assessment as safe and effective
or lead to algorithmic discrimination. </OtherInformation></Objective><Objective><Name>Oversight</Name><Description>Assess the potential for bias as well as other concerns that may limit the effectiveness human-based systems</Description><Identifier>_4b4afc36-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.3.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Human-based systems have the potential for bias, including automation bias, as well as other concerns that may limit their effectiveness. The results of assessments of the efficacy and potential bias of such human-based systems should be overseen by governance structures that have the potential to update the operation of the human-based system in order to mitigate these effects.</OtherInformation></Objective><Objective><Name>Sensitive Domains</Name><Description>Implement additional human oversight and safeguards for automated systems related to sensitive domains</Description><Identifier>_4b4b0424-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.4</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Automated systems used within sensitive domains, including criminal justice, employment, education, and
health, should meet the expectations laid out throughout this framework, especially avoiding capricious,
inappropriate, and discriminatory impacts of these technologies. Additionally, automated systems used within
sensitive domains should meet these expectations:</OtherInformation></Objective><Objective><Name>Scope</Name><Description>Narrowly scope data and inferences</Description><Identifier>_4b4b091a-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.4.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Narrowly scoped data and inferences. Human oversight should ensure that automated systems in
sensitive domains are narrowly scoped to address a defined goal, justifying each included data item or attribute as relevant to the specific use case. Data included should be carefully limited to avoid algorithmic
discrimination resulting from, e.g., use of community characteristics, social network analysis, or group-based
inferences. </OtherInformation></Objective><Objective><Name>Tailoring</Name><Description>Ensure that automated systems in sensitive domains are tailored to the specific use cases and real-world deployment scenarios</Description><Identifier>_4b4b0c44-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.4.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Tailored to the situation. Human oversight should ensure that automated systems in sensitive domains
are tailored to the specific use case and real-world deployment scenario, and evaluation testing should show
that the system is safe and effective for that specific situation. Validation testing performed based on one location or use case should not be assumed to transfer to another. </OtherInformation></Objective><Objective><Name>Human Consideration</Name><Description>Ensure human consideration before high-risk decisions</Description><Identifier>_4b4b12f2-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.4.3</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Human consideration before any high-risk decision. Automated systems, where they are used in
sensitive domains, may play a role in directly providing information or otherwise providing positive outcomes
to impacted people. However, automated systems should not be allowed to directly intervene in high-risk
situations, such as sentencing decisions or medical care, without human consideration. </OtherInformation></Objective><Objective><Name>Access &amp; Examination</Name><Description>Ensure meaningful access to examine systems</Description><Identifier>_4b4b16da-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.4.4</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name>Automated Systems Designers</Name><Description/></Stakeholder><Stakeholder StakeholderTypeType="Generic_Group"><Name>Automated Systems Developers</Name><Description/></Stakeholder><Stakeholder StakeholderTypeType="Generic_Group"><Name>Automated Systems Deployers</Name><Description/></Stakeholder><OtherInformation>Meaningful access to examine the system. Designers, developers, and deployers of automated
systems should consider limited waivers of confidentiality (including those related to trade secrets) where
necessary in order to provide meaningful oversight of systems used in sensitive domains, incorporating measures to protect intellectual property and trade secrets from unwarranted disclosure as appropriate. This
includes (potentially private and protected) meaningful access to source code, documentation, and related
data during any associated legal discovery, subject to effective confidentiality or court orders. Such meaningful access should include (but is not limited to) adhering to the principle on Notice and Explanation using the
highest level of risk so the system is designed with built-in explanations; such systems should use fully-transparent models where the model itself can be understood by people needing to directly examine it. </OtherInformation></Objective><Objective><Name>Demonstration</Name><Description>Demonstrate access to human alternatives, consideration, and fallback</Description><Identifier>_4b4b1a0e-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.5</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Reporting</Name><Description>Make reports public at regular intervals for as long as systems are in use</Description><Identifier>_4b4b2152-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.5.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>Reporting should include an assessment of timeliness and the extent of additional burden for human alternatives, aggregate statistics about who chooses the human alternative, along with the results of the assessment about brevity, clarity, and accessibility of notice and opt-out instructions. Reporting on the accessibility, timeliness, and effectiveness of human consideration and fallback should be made public at regular intervals for as long as the system is in use. This should include aggregated information about the number and type of requests for consideration, fallback employed, and any repeated requests; the timeliness of the handling of these requests, including mean wait times for different types of requests as well as maximum wait times; and information about the procedures used to address requests for consideration along with the results of the evaluation of their accessibility. For systems used in sensitive domains, reporting should include information about training and governance procedures for these technologies. Reporting should also include documentation of goals and assessment of meeting those goals, consideration of data included, and documentation of the governance of reasonable access to the technology. Reporting should be provided in a clear and machine-readable manner. </OtherInformation></Objective><Objective><Name>Human Alternatives</Name><Description>Assess of timeliness and the extent of additional burden for human alternatives</Description><Identifier>_4b4b256c-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.5.1.1</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Statistics</Name><Description>Provide aggregate statistics about who chooses human alternatives</Description><Identifier>_4b4b28a0-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.5.1.2</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Notices &amp; Instructions</Name><Description>Assess the brevity, clarity, and accessibility of notice and opt-out instructions</Description><Identifier>_4b4b2ff8-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.5.1.3</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation>This should include aggregated information about the number and type of requests for consideration, fallback employed, and any repeated requests; the timeliness of the handling of these requests, including mean wait times for different types of requests as well as maximum wait times; and information about the procedures used to address requests for consideration along with the results of the evaluation of their accessibility.</OtherInformation></Objective><Objective><Name>Training &amp; Governance</Name><Description>Include information about training and governance procedures</Description><Identifier>_4b4b3426-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.5.1.4</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Goals</Name><Description>Document the goals and assess achievement of them</Description><Identifier>_4b4b3868-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.5.1.5</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Data</Name><Description>Document consideration of data included</Description><Identifier>_4b4b3eda-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.5.1.6</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Governance</Name><Description>Document the governance of reasonable access to the technology</Description><Identifier>_4b4b42e0-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.5.1.7</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective><Objective><Name>Clarity &amp; Machine-Readability</Name><Description>Issue reports in a clear and machine-readable manner</Description><Identifier>_4b4b475e-adb3-11ed-8515-bde60383ea00</Identifier><SequenceIndicator>6.5.1.8</SequenceIndicator><Stakeholder StakeholderTypeType="Generic_Group"><Name/><Description/></Stakeholder><OtherInformation/></Objective></Goal></StrategicPlanCore><AdministrativeInformation><StartDate>2022-10-31</StartDate><EndDate/><PublicationDate>2023-02-15</PublicationDate><Source>https://www.whitehouse.gov/wp-content/uploads/2022/10/Blueprint-for-an-AI-Bill-of-Rights.pdf</Source><Submitter><GivenName>Owen</GivenName><Surname>Ambur</Surname><PhoneNumber/><EmailAddress>Owen.Ambur@verizon.net</EmailAddress></Submitter></AdministrativeInformation></PerformancePlanOrReport>