BY ORDER OF THE COMMANDER
AIR FORCE MATERIEL COMMAND
AIR FORCE MATERIEL COMMAND
INSTRUCTION 63-1201
2 DECEMBER 2022
Acquisition
INTEGRATED LIFE CYCLE SYSTEMS
ENGINEERING AND TECHNICAL
MANAGEMENT
COMPLIANCE WITH THIS PUBLICATION IS MANDATORY
ACCESSIBILITY: Publications and forms are available for downloading or ordering on the e-
publishing website at www.e-Publishing.af.mil.
RELEASABILITY: There are no releasability restrictions on this publication.
OPR: AFMC/ENS Certified by: AFMC/ENS
(Ms. Janet A. Jackson, NH-IV)
Supersedes: AFMCI63-1201, 28 March 2017 Pages: 78
This Air Force Materiel Command Instruction (AFMCI) implements guidance contained in
Department of Defense Instruction (DoDI) 5000.88, Engineering of Defense Systems, Air Force
Instruction (AFI) 63-101/20-101, Integrated Life Cycle Management, and other relevant
publications. It assigns Air Force Materiel Command (AFMC) responsibilities, prescribes policy
and procedures, and provides direction for standardizing, verifying, and maintaining the
accomplishment of required missions and end states in accordance with (IAW) Department of
Defense (DoD), United States Air Force (USAF), and AFMC policy. It applies to regular Air
Force, civilians, and contractors. This publication does not apply to United States Space Force,
Air Force Reserve Command, or Air National Guard units. Ensure that all records created as a
result of processes prescribed in this publication are maintained IAW AFI 33-322, Records
Management and Information Governance Program, and disposed of IAW Air Force Records
Information Management System Records Disposition Schedule. Refer recommended changes and
questions about this publication to the office of primary responsibility (OPR) using the Department
of Air Force (DAF) Form 847, Recommendation for Change of Publication; route AF Forms 847
from the field through the appropriate functional chain of command. This publication may be
supplemented at any level, but all supplements must be routed to the OPR of this publication for
coordination prior to certification and approval. The authorities to waive wing/unit level
requirements in this publication are identified with a tier (“T-0, T-1, T-2, T-3”) number following
the compliance statement. See Department of the Air Force Manual (DAFMAN) 90-161,
Publishing Processes and Procedures, for a description of the authorities associated with the tier
numbers. Submit requests for waivers through the chain of command to the appropriate tier waiver
2 AFMCI63-1201 2 DECEMBER 2022
approval authority, or alternately, to the Publication OPR for non-tiered compliance items using a
completed Department of the Air Force (DAF) Form 679, Department of the Air Force Publication
Compliance Item Waiver Request/Approval (or equivalent information). The use of the name or
mark of any specific manufacturer, commercial product, commodity, or service in this publication
does not imply endorsement by the Air Force.
SUMMARY OF CHANGES
This document has been substantially revised and needs to be completely reviewed. Major changes
have been made in order to streamline the life cycle systems engineering and technical
management process and its supporting activities.
Chapter 1—ROLES AND RESPONSIBILITIES 4
1.1. AFMC Engineering and Technical Management Directorate. ................................ 4
1.2. AFMC Center-Level Engineering Director or Equivalent. ...................................... 4
1.3. Director of Engineering or Equivalent. .................................................................... 5
1.4. Lead Systems Engineer/Chief Engineer. ................................................................. 6
1.5. Engineering Senior Professional (Senior Level/Scientific and Professional). ......... 6
1.6. Supply Chain Engineer. ........................................................................................... 6
Chapter 2—INTEGRATED LIFE CYCLE SYSTEMS ENGINEERING AND
TECHNICAL MANAGEMENT 8
2.1. Life Cycle Systems Engineering. ............................................................................. 8
Figure 2.1. OSS&E Taxonomy (Notional, Tailorable). ............................................................. 9
2.2. Technical Management. ........................................................................................... 16
Chapter 3—DELEGATION OF RESPONSIBILITIES/AUTHORITIES 18
3.1. Processes/Activities. ................................................................................................ 18
3.2. Responsibility/Authority Delegation. ...................................................................... 18
3.3. Delegated Responsibility/Authority Holders. .......................................................... 18
3.4. Delegation of Specific Responsibility/Authority. .................................................... 18
Attachment 1—GLOSSARY OF REFERENCES AND SUPPORTING INFORMATION 20
Attachment 2—LIFE CYCLE SYSTEMS ENGINEERING PROCESSES 35
Attachment 3—OPERATIONAL SAFETY, SUITABILITY, AND EFFECTIVENESS 52
Attachment 4—SYSTEMS ENGINEERING PLAN REQUIREMENTS 56
Attachment 5—HUMAN SYSTEMS INTEGRATION ACTIVITIES BY PROGRAM
PHASE 57
4 AFMCI63-1201 2 DECEMBER 2022
Chapter 1
ROLES AND RESPONSIBILITIES
1.1. AFMC Engineering and Technical Management Directorate. AFMC Engineering and
Technical Management Directorate (AFMC/EN) is the AFMC chief engineer and technical
authority per Air Force Materiel Command Mission Directive 401, Headquarters Air Force
Materiel Command (HQ AFMC). The chief engineer and technical authority:
1.1.1. Provides the AFMC Commander (AFMC/CC), unbiased technical advice for pre-
acquisition investment decisions and throughout the acquisition life cycle.
1.1.2. Engages implementing commands and center-level engineering offices to provide
technical support to program executive officers (PEO) and program managers (PM).
1.1.3. Oversees AFMC engineering enterprise policy and guidance and directs external
technical assessments of programs, as needed.
1.2. AFMC Center-Level Engineering Director or Equivalent.
1.2.1. Advocates for resources necessary to conduct and sustain effective systems engineering
(SE), life cycle systems engineering (LCSE) and operational safety, suitability, and
effectiveness (OSS&E) related processes and procedures. (T-2)
1.2.2. Ensures implementation of standard SE, LCSE, and OSS&E-related procedures across
center programs and projects, with tailoring/waivers as authorized and appropriate. (T-3)
1.2.3. Ensures AFMC center organizations implement center and organizational (i.e.,
Directorate, Group or equivalent) SE operating instruction (OI), directive policy supplements,
and other applicable SE standards, with tailoring/waivers as authorized by the assigned or
delegated Authority. (T-3)
1.2.3.1. Centers with diverse sub-organizations may issue SE OIs at sub-organizational
levels, with authorization by the center-level engineering director or equivalent.
1.2.3.2. Each SE OI identifies the organizations to which it applies.
1.2.3.3. The SE processes covered in an approved Systems Engineering Plan (SEP) will
be consistent with applicable SE OIs.
1.2.4. Ensures their center's SE-related OIs, supplements and other applicable SE standards
are reviewed by their OPRs no less often than biennially and updated as needed. (T-3)
1.2.5. Develops and implement center SE, LCSE, and OSS&E policy consistent with AFMC
policies. (T-3)
1.2.5.1. Provides opportunities for the center-wide workforce to keep current with
evolving policies and guidance spanning the processes in this instruction.
1.2.5.2. Provides associated best practice examples appropriate to the nature of center
programs and implementation of specific processes, with recommendations on how to
effectively implement the best practice(s) within the center.
1.2.5.3. Provides associated examples of deficient/problematic processes, with
recommendations on how to prevent recurrence of such practices within the center. Some
AFMCI63-1201 2 DECEMBER 2022 5
examples may be available via the AFMC Acquisition Incident Review process-- reference
AFMCMAN 63-101/20-101, Acquisition Incident Review (AIR) Process, for more
information.
1.2.6. Serves as the center’s Standardization Management Executive, or delegate the
responsibility as appropriate, IAW AFI 60-101 AFMCSUP, Materiel Standardization.
1.3. Director of Engineering or Equivalent.
1.3.1. Program Executive Officer Director of Engineering or Equivalent. Identified by the
PEO, is accountable to the PEO for oversight of the portfolio’s engineering functional support.
(T-3)
1.3.2. Air Force Research Laboratory Director of Engineering or Equivalent
1.3.2.1. Documents standard SE processes appropriate to the maturity of the technology
under development IAW Air Force Research Laboratory (AFRL) SE OIs and supplements
and implements standard SE processes in science and technology (S&T) programs. (T-3)
1.3.2.1.1. The AFRL SE OI or Supplement identifies all organizations to which it
applies. The AFRL SE OI is not required to identify all programs to which it applies.
1.3.2.1.2. AFRL SE OIs are reviewed no less often than biennially and updated as
required by the appropriate OI OPR.
1.3.2.1.3. AFRL S&T research and development efforts, including AFRL-led basic
research, applied research, and advanced research, follow this guidance.
1.3.2.1.4. AFRL documents and archives trade study results for use in future
technology demonstration or acquisition programs.
1.3.2.2. Supports technology transition planning in collaboration with a transition and/or
acquisition agent IAW AFI 61-101, Management of Science and Technology. (T-3)
1.3.2.3. Coordinates with PM(s) on S&T programs intended to modify existing systems,
subsystems, or end items.
1.3.2.4. Ensures that S&T program managers coordinate with the system PM or
acquisition agent to integrate OSS&E baseline definition and certification requirements
into a developer’s design and development activity. An S&T program intended to transition
to operational use, either as a modification to an existing system, subsystem, end item, or
as a new system, subsystem, or end item ensures that the OSS&E baseline definition and
certification requirements are coordinated with the system’s (or enterprise) technical
architecture. (T-3)
1.3.2.5. Recognizes the system, subsystem, or end item S&T PM as the designated
individual with responsibility and oversight over an S&T program targeted for integration
onto an existing system, subsystem, or end item. The PM retains overall SE responsibility
for a supported system, subsystem, or end item. (T-3)
1.3.2.6. Ensures S&T program is not connected (physically or through information
networks) to any fielded system, subsystem, or end item without (1) approval by the
Configuration Control Board (CCB) for the affected system, subsystem, or end item and
6 AFMCI63-1201 2 DECEMBER 2022
(2) implementation of OSS&E requirements or use of major command /A3 (or CC/CV)
waiver. (T-3)
1.3.2.7. Conducts (or ensure the appropriate Technology Directorate Director conducts)
structured technical reviews (program management review, program baseline review, or
equivalent). (T-3)
1.3.2.8. As the AFRL Director of Engineering (DoE) determines to be appropriate, ensure
S&T programs prepare S&T Program Protection Plan (PPP) and implement required
countermeasures IAW DoDI 5000.83. Reference DoDI 5000.83 DAFI 63-113 for more
information. IAW the above referenced guidance, ensures identification of Critical
Program Information (CPI) and protection of Designated Science and Technology
Information. (T-3)
1.4. Lead Systems Engineer/Chief Engineer. IAW AFI 63-101/20-101, Integrated Life Cycle
Management, Paragraph 2.8, Chief Engineer. Note: In this instruction, the terms lead systems
engineer (LSE) and chief engineer (CE) are synonymous, referring to the senior (having
precedence in making decisions) responsible engineer in a program office.
1.5. Engineering Senior Professional (Senior Level/Scientific and Professional).
1.5.1. Engineering Senior Level (SL) will primarily guide the Department of the Air Force
(DAF) strategy, vision, and goals in their technical area(s) in direct support of, and consistent
with, broad national, DoD, DAF, and AFMC policy and strategic guidance.
1.5.2. Scientific and Professional (ST) will perform high-level research and development in
the physical, biological, medical, or engineering sciences, or a closely related field, typically
in a laboratory setting. STs serve as principal scientific/technical advisors, independent
researchers, and recognized national/international experts in a major technology focus area.
1.6. Supply Chain Engineer.
1.6.1. Receive and manage sustaining engineering funding for sustainment of fielded assets
and for re-engineering of obsolete or unsustainable items.
1.6.2. Document and deliver products that meet OSS&E requirements defined by a PM for an
assigned system, subsystem, or end item. With support from the appropriate LSE/CEs, ensures
that any changes to a product, component, or end item include an evaluation for any required
changes to associated automated test equipment including test program set (TPS) and support
equipment.
1.6.3. Communicate/coordinate product changes with the PM as required to maintain system-
level OSS&E end states.
1.6.4. Execute duties, responsibilities, and authorities delegated by the PM and/or LSE/CE
and help to ensure appropriate documentation of the delegation IAW Chapter 3. To ensure
the critical mission of the supply chain organization continues while the delegation of
authority/responsibility is being documented, in the absence of delegation documentation from
the PM or LSE/CE the respective Supply Chain Manager (SCM) Group Director of
Engineering has, by default, the following authority. These apply to those cases where
consignment transfer has been accomplished for spares, repairs, and technical orders (TO) that
are owned by AF SCM; is not a transfer of workload or configuration control inherent to the
assigned program office.
AFMCI63-1201 2 DECEMBER 2022 7
1.6.4.1. Executes Class II change authority for engineering change proposal (ECP) and
engineering change order action items within the SCM portfolio which preserve form, fit,
function and interface at the next higher assembly level of the weapon system(s). Note: For
more information on ECP classes, reference MIL-HDBK-61B.
1.6.4.2. Responds to Engineering Technical Assistance Requests to include AFMC Form
202, Engineer Technical Assistance Request, Defense Logistics Agency (DLA) Form 339,
Request for Engineering Support; DLA Form 1912, Defense Logistics Agency Local
Purchase – Technical Support Request; requests IAW TO 00-25-107, Maintenance
Assistance; Material Review Board deviation dispositions; screening actions for contract
purchases and repairs; Source Approval Requests; First Article Test dispositions; Depot
Level TO Validation, Verification, Update and Correction; and Deficiency Report/Material
Improvement Project investigations (per TO 00-35D-54) where the National Stock Number
roles and responsibilities are currently assigned to the SCM for Classes of Supply II
(General Support Items), VII (Major End Items) and IX (Repair Parts, Less Medical
Special Repair Parts). Note: For more information on classes of supply, reference Joint
Publication (JP) 4-09, Distribution Operations.
1.6.4.3. Accomplishes and implements the Consolidated Sustainment Activity Group-
Supply, General Support Division, and TPS sustainment Engineering projects to include
the following:
1.6.4.3.1. Eliminate deficiencies of consigned items within the SCM portfolio to
diminishing manufacturing sources and material shortages, shortfalls in reliability and
maintainability, and safety defects.
1.6.4.3.2. Perform necessary sustainment to consigned TPS, to include:
1.6.4.3.2.1. Adaptive maintenance that modifies software or hardware to properly
interface with a changing environment.
1.6.4.3.2.2. Perfective maintenance for adding new capabilities, modifying
existing functions, and making general enhancements.
8 AFMCI63-1201 2 DECEMBER 2022
Chapter 2
INTEGRATED LIFE CYCLE SYSTEMS ENGINEERING AND TECHNICAL
MANAGEMENT
2.1. Life Cycle Systems Engineering. Systems engineering is a collaborative, interdisciplinary
execution approach, which provides technical and managerial processes to unify, integrate and
focus the efforts of all stakeholders - researchers, acquirers, developers, users, testers, trainers,
maintainers, and sustainers - throughout the life cycle of a product or system. Systems engineering
provides the integrating technical processes and design leadership to define and balance system
performance, cost, schedule, risk, and system security within and across individual systems and
programs. Tailored application of Systems engineering processes begins at concept inception and
continues throughout the life cycle phases (user needs identification through disposal). Systems
engineering decisions can be made at any life cycle phase and can affect the cost, schedule, and
performance of an item, system, and Family/System of Systems. Life cycle systems engineering
emphasizes disciplined technical planning, organization, and execution of integrated systems
engineering efforts across all stakeholder organizations to balance research, development,
acquisition, test and evaluation, and sustainment needs (including regeneration and disposal),
thereby ensuring that delivered products and capabilities meet user requirements. It develops a
relevant engineering and technical knowledge base that is matured, maintained, and utilized in a
disciplined manner over the life cycle of the capability. See Attachment 2.
2.1.1. Systems Engineering Areas. This document focuses on nine areas within systems
engineering. These include (1) OSS&E, (2) Digital Engineering, (3) Government Reference
Architecture Governance Structure, (4) Agile Software and Intellectual Property, (5) Mission
Engineering, (6) Test and Evaluation, (7) System Safety, (8) Human Systems Integration, and
(9) Technology Assessment Process. These areas are considered key in AFMC’s systems
engineering process.
2.1.1.1. Operational Safety, Suitability, and Effectiveness. Robust products and systems
that exhibit required attributes of system security, mission assurance, and OSS&E
assurance are the principal outcomes of properly planned and applied SE. However, while
OSS&E is an outcome of properly applied SE principles, processes, and practices, it is
important to recognize that system OSS&E characteristics are dynamic over the entire
system life cycle, particularly in the Operations and Sustainment (O&S) phase. Various
program management, engineering, and technical practices are needed to ensure that
systems and end items remain operationally safe, suitable, and effective across the life
cycle. As an example, Figure 2.1 shows a notional taxonomy of factors and processes that
help to ensure a system's OSS&E. While LCSE describes the processes needed to achieve
and maintain required system capabilities, the processes related to the OSS&E outcomes
help to establish, document and track system/item configurations, characteristics, and
behaviors throughout their life cycles. See Attachment 3.
AFMCI63-1201 2 DECEMBER 2022 9
Figure 2.1. OSS&E Taxonomy (Notional, Tailorable).
2.1.1.1.1. In simplest terms, OSS&E assurance consists of two parts: (1) defining and
establishing the OSS&E baseline and (2) tracking and sustaining the OSS&E baseline
throughout the life cycle of a system. As an overarching concept, OSS&E assurance
can best be viewed as an approach that pulls together requirements, technical baseline
data, and life cycle processes for the sustainment of systems, subsystems, and end
items. Characteristics of an effective OSS&E assurance approach are:
2.1.1.1.1.1. Development and documentation of an initial OSS&E baseline,
including identification/definition of the key characteristics necessary to assure
OSS&E.
2.1.1.1.1.2. Delivery of systems, subsystems, end items, and information in
accordance with the established OSS&E baseline.
2.1.1.1.1.3. Preservation and tracking of OSS&E baseline characteristics of
systems, subsystems, and end items over their operational lives to ensure that
systems, items, and supporting critical processes continue to meet OSS&E
requirements.
2.1.1.1.1.4. Updating of OSS&E baselines when making modifications or changes
to systems, subsystems, or end items.
10 AFMCI63-1201 2 DECEMBER 2022
2.1.1.1.2. The OSS&E baseline consists of key features and aspects that describe the
system, subsystem, or end item capabilities, require continuous tracking, and merit the
attention of the PM (with support from the LSE/CE) and user(s) in terms of OSS&E. It
comprises the system/item characteristics and limitations that must be understood,
acknowledged, and maintained during operational use, deployment, experimentation,
exercises, training, and maintenance. It is also supported by measurable, useful,
affordable metrics. The OSS&E baseline is established in development and is updated
as significant changes (threat, operational usage, aging, etc.) occur or are made to the
system/item over the life cycle.
2.1.1.1.3. The PM and LSE/CE apply LCSE processes and practices to monitor
systems and ensure preservation of the technical baseline, which provides system
descriptions of functions, performance, and interfaces, and enables the underlying
design to progress using a common reference-- see paragraph A2.8 for more
information. The PM (with support from the LSE/CE) describes how the LCSE and
technical baseline requirements are being met in the appropriate program documents.
For the OSS&E baseline, the program and operational stakeholders utilize technical
baseline data and SE processes to identify the key OSS&E performance characteristics
for the system and establish the means to track and maintain those characteristics over
the life cycle.
2.1.1.1.4. The program SEP should identify technical data, including specifications
and standards, for achieving and assuring preservation of baseline OSS&E
characteristics. See Attachment 4 for SEP recommendations and requirements related
to LCSE and OSS&E. In addition, Human Systems Integration (HSI) planning content
can be included in the SEP as discussed in Attachment 5.
2.1.1.1.5. OSS&E Relationships. The PM (with support from the LSE/CE) is
responsible for assuring the OSS&E of systems, subsystems, and end items. The
LSE/CE is the primary program Engineering/Technical Authority responsible for
establishing, implementing, managing, and controlling LCSE activities necessary to
develop and field robust products and systems that exhibit attributes of systems
security, OSS&E, and mission assurance. PMs and LSE/CEs collaborate to continue
rigorous application of SE principles and processes. All relevant aspects of SE
performance are periodically assessed by these stakeholders with a focus on ensuring
OSS&E over the life cycle.
2.1.1.1.5.1. The PM's (with support from the LSE/CE) responsibilities include
ensuring OSS&E for the Peculiar Support Equipment (PSE) required to sustain a
system, subsystem, or end item; subsystems and components that compose a system
or PSE; and integration of any government furnished equipment (GFE), payload,
cargo or other item that physically or electronically connects to a system,
subsystem, or end item.
2.1.1.1.5.2. The LSE/CE is the overall Engineering/Technical Authority for the
program and system. The LSE/CE typically leads implementation of program
LCSE processes and ensures the integrity of those processes, including technical
risk assessments focused on ensuring OSS&E of an assigned system. The LSE/CE
is a system's final Engineering/Technical Authority for all PSE, GFE, subsystems
AFMCI63-1201 2 DECEMBER 2022 11
and components, and integration of any payload, cargo or other item that physically
or electronically connects to the system. As required, the LSE/CE provides a
technical assessment to the PM for commercial- or government-managed
subsystems and end items, intended to be either temporarily or permanently
installed on a system, physically/electronically connected to a system, or used to
manufacture or maintain a system.
2.1.1.1.5.3. The PM (with support from the LSE/CE) includes representatives of
the operational, logistics, maintenance/sustainment, safety, and test and evaluation
(T&E) communities in the program efforts to define, achieve, track, and maintain
the OSS&E baseline.
2.1.1.1.5.4. The PM and LSE/CE ensure that designation/delegation of program,
engineering and technical authorities related to OSS&E are clearly documented and
consistent with the roles and responsibilities in this instruction. This includes
documenting specific delegation of program management-related OSS&E
authority given to the Product Support Manager(s) (PSM), Product Group
Manager(s) (PGM) and SCM(s). Specific program management-related OSS&E
authorities and responsibilities are documented and approved by the appropriate
OPR, as well as the designated/delegated organization. Reference DAFPAM 63-
128 for additional recommended procedures. Also, see Attachment 6 for
recommended templates related to delegation of engineering authorities for the
AFMC Form 202.
2.1.1.1.5.5. Any delegation of OSS&E responsibilities/authorities documented in
a center level agreement (CLA) or other Memorandum of Agreement (MOA)
should be made available by the PM (with support from the LSE/CE) to program
OSS&E stakeholders.
2.1.1.1.5.6. For assets stored at the 309 Aerospace Maintenance and Regeneration
Group (AMARG): If the asset program office no longer exists, and if no PM or
program LSE/CE is assigned to provide programmatic or engineering
authority/disposition for the stored assets at the 309 AMARG, the 309 AMARG
Engineering Group assumes engineering/disposition authority IAW this
instruction.
2.1.1.1.5.6.1. A PM or LSE/CE assigned to provide programmatic, or
engineering authority/disposition should consider delegation of engineering
authority/disposition to the 309 AMARG Engineering Group for assets
assigned to 309 AMARG 2000 or 4000 type storage. Reference Air Force TO
1-1-686, Desert Storage Preservation, and Process Manual for Aircraft, Aircraft
Engines, and Aircraft Auxiliary Power Unit Engines, for more information. For
such delegation the 309 AMARG Engineering Group and the PM or LSE/CE
with primary authority should document any periodic reporting requirements
between stakeholders as part of the authority delegation memo.
2.1.1.1.5.7. Non-Air Force-Managed U.S. Military Systems and End Items. AFPD
63-1/20-1, Integrated Life Cycle Management, indicates that OSS&E assurance
applies to systems and end items managed by the Air Force. However, the PM (with
support from the LSE/CE) should consider control of certain aspects of OSS&E for
12 AFMCI63-1201 2 DECEMBER 2022
U.S. military systems, components and end items that are not managed by the Air
Force -- OSS&E assurance may still have some limited applicability. For example,
if the Air Force does not own or maintain a training simulator system, training
effectiveness may be the only applicable portion of OSS&E. However, ineffective
training resulting from poor configuration control could cause unsafe actions in the
aircraft and lead to suitability issues. Contracts for a pilot or maintainer, leased
aircraft and/or contractor logistics support (CLS) can further complicate the
application of the program's OSS&E approach. The PM and LSE/CE should
evaluate and tailor the application of the OSS&E requirements to meet the unique
program needs and constraints.
2.1.1.1.5.8. Foreign Military Sales (FMS) Efforts. Export sales and transfers of
U.S. defense articles and associated services are complex transactions involving
three primary stakeholders or parties: the United States Government (USG),
international partners (allied and friendly governments/organizations), and defense
contractors and suppliers (U.S. and international). IAW Air Force Manual
(AFMAN) 16-101, Security Cooperation (SC) And Security Assistance (SA)
Management, the system PM, Security Assistance Program Manager, Air Force
Security Assistance Cooperation (AFSAC) Directorate Command Country
Manager or Case Manager, and other FMS stakeholders work to ensure the delivery
of the required system, items, spares, support equipment and/or services in a timely
manner. For FMS programs, the following OSS&E guidance applies:
2.1.1.1.5.8.1. IAW AFI 63-101/20-101, program office technical and
management processes (e.g., systems engineering, system and component
qualification, configuration management, etc.) are followed as is normally done
in the execution of programs during acquisition and modifications. This may
include certifications, coordination, and approvals (e.g., aerial refueling,
spectrum management, etc.) required to be accomplished in support of
acquisition and modification program activities while the systems being
supplied are under USAF cognizance (i.e., development, flight test, and ferry).
However, compliance with this AFMCI for OSS&E baselines, metrics, and
other requirements intended for application over the life cycle of a system/item
are not required unless they are needed to comply with higher level
DoD/Joint/AF directive policies, the terms of the Letter of Offer and
Acceptance, or other applicable agreement mechanism(s) with the international
partner(s).
2.1.1.1.5.8.2. FMS programs should ensure that each weapon system delivered
to a partner nation has met its OSS&E and applicable
certification/coordination/approval requirements. Unless otherwise stipulated
in the Letter of Offer and Acceptance or other agreement, final responsibility
and accountability for these items remain with the PM (with support from the
LSE/CE) until officially transferred to the gaining country. Transfer of OSS&E
and other responsibilities should be considered as the Letter of Offer and
Acceptance is drafted for each system and country.
2.1.1.1.6. Summary. Through effective LCSE and OSS&E approaches, the program
office and the supporting stakeholders should have the means to determine the
AFMCI63-1201 2 DECEMBER 2022 13
adequacy of the products that they deliver to their customers. In turn, the customers
should have assurance that the criteria used for system acceptance are based on sound
SE practices and are traceable to the system's performance requirements.
2.1.1.2. Digital Engineering. The LSE/CE, in support of the PM, has execution
responsibility for the program’s digital engineering and should adhere to the governance
structure. In addition, the LSE/CE shall develop and implement digital engineering
utilizing the Air Force Digital Guide and plan for digital engineering strategy as part of
SEP. Information on digital enterprise can be found at the Air Force Digital Guide website,
which is located at https://usaf.dps.mil/teams/afmcde/SitePages/Home.aspx.
2.1.1.3. Government Reference Architecture Governance Structure. The LSE/CE shall use
either the term “System Architecture” or “Solution Architecture” for architectural design
work specific to one weapon system and should avoid using the term “Reference
Architecture” for any work that is not guiding design principles of multiple architectures
and solutions.
2.1.1.4. Agile Software and Intellectual Property.
2.1.1.4.1. The LSE/CE shall assist the PM in determining and executing the
appropriate program development technical acquisition processes.
2.1.1.4.1.1. Software Development Methodologies and Techniques. The LSE/CE
ensures incremental software development methodologies and techniques are
considered as the preferred approach to the technical implementation of systems.
The LSE/CE and Integrated Test Team in conjunction with the PM shall consider
agile implementation in support of rapid delivery of capability status to program
office personnel, key stakeholders, and timely delivery of capabilities to end user
communities at sufficient intervals. Since the functionality of avionics components
are likely developed in the form of software, the LSE/CE should consider creation
of a software capability team composed of cross domain avionics subject matter
experts (SMEs) and software SMEs charged with the responsibility to conduct
highly collaborative/transparent technical oversight of software development. See
chapter on Agile Dev-Sec-Ops at
https://www.milsuite.mil/book/community/spaces/air-force-engineers.
2.1.1.4.1.2. Data Rights Identification & Sustainment. The scope of the
sustainment strategy is limited only to those elements that are candidates for update
during the sustainment period of a component or system. The LSE/CE assures the
program office personnel identify only that set of data rights that support the
sustainment strategy in order to facilitate a manageable system data rights profile.
The LSE/CE should consider creating a program data rights council (PDRC)
consisting of SMEs across all technical domains charged with ensuring the program
data rights profile remains consistent with the sustainment strategy and that the
needed data rights for sustainment persist throughout the system’s life cycle. The
PDRC shall determine the initial set data rights that the program shall pursue for
system sustainment. For the remaining life cycle of the system, the PDRC should
conduct analysis at strategic points to assure the system data rights remain aligned
with the sustainment strategy. For guidance, see Intellectual Property Strategy
section in AFI 63-101/20-101 and the Air Force Data Rights Guidebook at
14 AFMCI63-1201 2 DECEMBER 2022
https://www.dau.edu/pdfviewer?Guidebooks/Air-Force-Data-Rights-
Guidebook.pdf.
2.1.1.5. Mission Engineering. IAW the National Defense Authorization Act (NDAA) for
Fiscal Year 2017, Section 855, the LSE/CE, in support of the PM, shall establish Mission
Integration Management (MIM) as a core activity within the acquisition, engineering, and
operational communities. Mission engineering is the technical sub-element of MIM as a
means to provide engineered mission-based outputs to the requirements process, guide
prototypes, provide design options, and inform investment decisions. For implementation,
LSE/CE should consult Office of the Undersecretary of Defense for Research and
Engineering Mission Engineering Guide available at https://ac.cto.mil/mission-
engineering when conducting Mission Engineering and MIM.
2.1.1.6. Test and Evaluation. IAW DoDI 5000.88, the PM (with support from the LSE/CE)
shall ensure test and evaluation planning and program activities are conducted in
accordance with DoDI 5000.89 DAFI 99-103. To the greatest extent possible, test and
evaluation planning and resultant activities (e.g., strategy, test plans, test resources,
requirements traceability, test data, test analyses, and other related activities) shall use and
contribute to the information contained in the evolving digital system representation. The
fundamental purpose of T&E is to provide essential information to decision makers, verify
and validate performance capabilities documented as requirements, assess attainment of
technical performance parameters, and determine whether systems are operationally
effective, suitable, survivable, and safe for intended use.
2.1.1.6.1. T&E shall be a continuum of integrated test (Contractor Test,
Developmental Test, Certification Test, and Operational Test, at a minimum)
throughout the defense acquisition process to provide program offices with system
maturity and readiness assessments to advance to the next phase of development or
fielding including OSS&E.
2.1.1.6.1.1. Test results shall provide feedback to analyze the design progress
toward performance goals.
2.1.1.6.1.2. The continuum of test activities shall support technical reviews and
provide feedback to the systems engineering process.
2.1.1.6.1.3. The PM (with support from the LSE/CE and Chief Developmental
Tester/Test Manager) shall utilize test activities and test documentation to inform
and support acquisition decisions.
2.1.1.6.2. The SEP, Test and Evaluation Master Plan (TEMP) and other T&E related
digital or legacy documents shall be aligned to ensure that they are mutually supportive
and traceable to each other.
2.1.1.6.2.1. Testing activities derived from the TEMP or the Test and Evaluation
Strategy (TES) shall be structured to provide the required evaluation data for all
design decision points, audits, and reviews that are part of the systems engineering
process.
2.1.1.6.2.2. Technical thresholds and objectives including specific performance
requirements shall be included in developmental test objectives.
AFMCI63-1201 2 DECEMBER 2022 15
2.1.1.7. System Safety.
2.1.1.7.1. System safety is the application of engineering and management principles,
criteria, and techniques to achieve acceptable mishap risk within the constraints of
operational effectiveness, suitability, time, and cost, throughout all phases of the system
life cycle. System Safety objectives include:
2.1.1.7.1.1. The identification of Environment, Safety, and Occupational Health
(ESOH) hazards, assess hazard risk in terms of severity and probability, reduce the
risks by the safety design order of precedence, (a) eliminate the hazard through
design selection, (b) reduce risk through design alteration, (c) incorporate
engineered features or devices, (d) provide warning devices, and (e) incorporate
signage, procedures, training, and personal protective equipment.
2.1.1.7.1.2. Accept residual risks (interim and final). Chapter 11 of AFI 91-202,
The US Air Force Mishap Prevention Program, outlines system safety program
requirements and responsibilities for PMs and using commands as well as defining
the process for safety hazard risk acceptance. The greater the risk, the higher the
acceptance authority.
2.1.1.7.2. The PM (with support from the LSE/CE) is to establish and maintain a
tailored system safety program using MIL-STD-882E, System Safety, as a guide to
manage ESOH. Where variation or innovation in tasking or methodology is allowed,
proof is required to demonstrate that the approach accomplishes the required objectives
and tasking contained in the Air Force policies. Some basic tenets of a system safety
program include the establishment of hazard risk-resolution criteria, properly scoped
hazard analyses, hazard tracking, resolution, documentation, and forums for hazard
deliberations and resolution.
2.1.1.7.3. AFI 91-202 requires that System Safety Groups (SSG) be established for all
Acquisition Category I (ACAT I) programs and for all aircraft programs unless waived
by the major command (MAJCOM). The purpose of the SSG is to oversee the system
safety program throughout the life cycle of the system and to document the mishap risk
review process with the specifics identified in the SSG charter. The PM or deputy chairs
(with support from the LSE/CE) the SSG, and membership includes user command
maintenance and operations representatives. If residual risk remains after being
addressed by the SSG, AFI 91-202 and MIL-STD-882E define the appropriate levels
of risk approval authority (Low/Medium is the PM, Serious is the PEO, and High is the
component acquisition executive) for acceptance of residual mishap risk. In the
sustainment phase, SSGs are primarily concerned with engineering change proposals,
mishap trends and recommendations, time-compliant technical orders (TCTO), and
deficiency report (DR) tracking.
2.1.1.8. Human Systems Integration. The LSE/CE shall establish HSI planning and
implementation that addresses the systematic integration of interrelated domains. This shall
enable the systems engineering process and program management effort. It allows
integrated and comprehensive analysis, design, and assessment of requirements, concepts,
and resources. See Attachment 5.
16 AFMCI63-1201 2 DECEMBER 2022
2.1.1.9. Technology Assessment Process. The LSE/CE shall use and employ novel or
substitute materials, processes, and product form(s) for enterprise technologies IAW
https://usaf.dps.mil/teams/21080/TechAssessProc/SitePages/Home.aspx. Novel or
substitute materials, processes, and product forms are those that are not adequately defined
by approved material and/or process specifications to enable application across the
enterprise.
2.2. Technical Management. Technical management and its processes are used to manage the
development of a system. Technical processes are used to design, develop, and analyze the system.
These processes are foundational and are used consistently to provide insight and control over the
technical development of a system throughout its life cycle.
2.2.1. Technical Reviews and Assessments.
2.2.1.1. Independent Technical Risk Assessment.
2.2.1.1.1. The LSE/CE shall conduct Independent Technical Risk Assessments
(ITRA) per DoDI 5000.88, Engineering of Defense Systems. ITRAs are conducted on
all Major Defense Acquisition Programs (MDAP) before approval of Milestone A,
Milestone B, and any decision to enter into low-rate initial production or full-rate
production. The Under Secretary of Defense for Research and Engineering establishes
policy and guidance for the conduct of ITRAs, consistent with Section 4272 of Title
10, United States Code (U.S.C.). The 25 Jun 2020 SAF/AQ Memo, ITRA Roles and
Responsibilities, designates SAF/AQR as the primary office responsible for all AF
ITRA activities, and the 12 Feb 2021 SAF/AQR Memo, ITRA Execution Roles and
Responsibilities, establishes roles of SAF/AQR, AFMC/EN, and the PM.
2.2.1.1.2. AFMC/EN’s shall identify SMEs to serve on AF ITRAs and to provide risk
management team training. The OSD 2017 Risk, Issue, and Opportunity Management
Guide is located at https://acqnotes.com/wp-content/uploads/2017/07/DoD-Risk-
Issue-and-Opportunity-Management-Guide-Jan-2017.pdf.
2.2.1.1.3. Preliminary Design Review and Critical Design Review. To fulfill this
requirement, SAF/AQR memorandum, Delegation Authority – Conduct of Post-
Preliminary Design /Critical Design Review Assessments, dated 8 Dec 2021,
designates center level engineering functional offices to fill the role of the independent
review team. Specifically, SAF/AQR designates SSC/ZAE, AFLCMC/EN, and
AFNWC/EN to conduct post-PDR/CDR assessments for their respective MDAPs.
2.2.1.2. Air Force Systems Engineering Assessment Model Tool.
2.2.1.2.1. Air Force Systems Engineering Assessment Model. The LSE/CE may use
the Air Force Systems Engineering Assessment Model (AF SEAM) Management
Guide and Self-Assessment Tool for conducting assessments relative to life cycle
management. The primary purpose of the AF SEAM is to promote the application and
use of standard systems engineering processes across the AF and to improve the
performance of those processes through continuous process improvement.
2.2.1.2.2. Approach. This is achieved by providing both standard process definitions
and an associated set of SE best practices tailored for use by United States Air Force
programs and projects. These practices include the activities performed by technical
AFMCI63-1201 2 DECEMBER 2022 17
professionals across the AF charged with the responsibilities of identifying, acquiring,
testing, and sustaining military weapon systems. Combined, these practices form the
foundation for SE process discipline that leads to repeatable excellence in product life-
cycle management and higher levels of customer satisfaction. The processes and
associated practices address acquirer activities as well as activities conducted by the
integrator or supplier and other organizations throughout the supply-chain. It is the
acquirer’s role to over-see the adequacy of the SE processes and ensure effective
implementation of systems engineering. This includes those government processes that
have been flowed down and are then delegated to the supplier. The final responsibility
for the performance of the processes remains with the acquirer.
2.2.1.2.3. Tailor-ability and Limitations. While designed to assess the existence of SE
process work products (i.e., CONOPS, plans, technical documents, etc.) it does not
assess the outcomes delivered to the customer. The model concentrates on “what” SE
processes must be in place which, when properly executed, increase the likelihood
customer needs shall be satisfied. Therefore, AF SEAM must be used in conjunction
with other more traditional tools to gain a full understanding of project/program status.
Also, the model was designed to be flexible and simultaneously take full advantage of
creative solutions and CPI by not bounding the user to prescribed implementation
approaches “how to” for achieving systems engineering best practices.
2.2.1.2.4. Assessment Models and Checklists. Developed models and checklists are
available within these 11 focus areas: General Practices; Configuration Management;
Decision Analysis; Design; Manufacturing; Project Planning; Requirements; Risk
Management; Transition; Fielding and Sustainment; Technical Management and
Control; and Verification and Validation.
2.2.1.2.5. Additional content and user training related to the AF SEAM can be found
at https://www.milsuite.mil/wiki/AF_SEAM_(AF_ERC).
18 AFMCI63-1201 2 DECEMBER 2022
Chapter 3
DELEGATION OF RESPONSIBILITIES/AUTHORITIES
3.1. Processes/Activities. For the scope of processes/activities covered by this instruction,
delegation of engineering/technical responsibilities and authorities to a qualified individual is
specific in nature, documented by official memo, and regularly reviewed/updated over time. See
AFMCMAN 63-1202 for additional details. Responsibility/authority will be delegated to a
qualified individual, not to an organization, team, or office.
3.2. Responsibility/Authority Delegation. For responsibility/authority to be delegated, the
individual should be assessed by both the individual’s functional office and the delegating
OPR/authority as having the qualifications and needed levels of competence to carry out the tasks
covered by that responsibility/authority. The person delegating responsibility/authority is
responsible for ensuring that the delegation does not conflict with other responsibility/authority
assignments or delegations.
3.3. Delegated Responsibility/Authority Holders. Delegated responsibility/authority holders
should:
3.3.1. Exercise their responsibility/authority only within the limits of their assignment and
only for the intended purposes.
3.3.2. Apply accepted standards and procedures (with tailoring, if authorized/appropriate), and
promptly advise appropriate offices when they cannot or should not be applied.
3.3.3. Keep up to date with advances and changes in their area(s) of expertise.
3.3.4. Use established processes when exercising any further delegation of
responsibility/authority.
3.4. Delegation of Specific Responsibility/Authority. Delegation of specific
responsibility/authority is made IAW the policy and/or direction that applies to the unique
delegation. It is made via official memo to the assigned individual and made available to the PM
and LSE/CE, affected program teams and other related stakeholder organizations. Delegating
responsibility and authority does not delegate the statutory/regulatory accountability of the
individual assigned by law or policy. Note: Reference Attachment 1 Glossary to distinguish the
terms “responsibility”, “authority”, and “accountability”.
3.4.1. A delegation memo is provided by the delegating Authority. Memos will be provided
within 30 calendar days of the assignment. For delegations within the scope of
processes/activities covered by this AFMCI that were made prior to this instruction's
publication, memos will be provided within 270 calendar days of this instruction's publication
date.
3.4.2. The delegated authority, responsibility, and reporting relationships should be clearly
defined, along with the period of assignment. The authority exists only for the duration of the
period of assignment.
3.4.3. Delegation memos are reviewed no less often than once every two years by the
delegating and delegated Authorities and are updated as needed to account for changes in
applicable policies, programmatic relationships, and supporting organizational structures.
AFMCI63-1201 2 DECEMBER 2022 19
3.4.4. The delegating Authority documents the termination of a delegation IAW the guidance
in this chapter. Memos will be provided within 30 calendar days of the termination.
3.4.5. IAW applicable policy and local instructions, individuals with delegated authority may
temporarily (no longer than 180 calendar days) sub-delegate one level down to a qualified
person; however, responsibility for sub-delegated actions remains with the delegated authority.
Sub-delegations will be documented IAW the above guidance.
ROBERT B. FOOKES, JR., SES, AFMC/EN
Director, Engineering and Technical Management
20 AFMCI63-1201 2 DECEMBER 2022
Attachment 1
GLOSSARY OF REFERENCES AND SUPPORTING INFORMATION
References
Acquisition Streamlining and Standardization Information System (ASSIST)
AFI 10-601, Operational Capability Requirements Documentation and Validation, 27 Apr 2021
AFI 16-402, Aerospace Vehicle Programming, Assignment, Distribution, Accounting, and
Termination, 20 May 2013
AFI 17-130, Cybersecurity Program Management, 13 Feb 2020
AFI 20-106 IP, Management of Aviation Critical Safety Items, 25 Jan 2006
AFI 21-101 AFMCSUP, Aircraft and Equipment Maintenance Management, 10 Nov 2020
AFI 33-322, Records Management and Information Governance Program, 28 Jul 2021
AFI 61-101, Management of Science and Technology, 14 Mar 2013
AFI 60-101 AFMCSUP, Materiel Standardization, 13 Jan 2020
AFI 63-101/20-101, Integrated Life Cycle Management, 30 Jun 2020
AFI 63-138, Acquisition of Services, 21 May 2013
AFI 63-145, Manufacturing and Quality Management, 4 Dec 2020
AFI 91-202 AFMCSUP, The US Air Force Mishap Prevention Program, 6 Apr 2022
AFI 91-204, Safety Investigations and Reports, 10 Mar 2021
AFI 91-401, Directed Energy Weapons Safety, 28 Nov 2018
AFMC202, Delegated Engineering Authority Process Guide v1.0, 18 Sep 2012
AFMAN 16-101, International Affairs and Security Assistance Management, 15 Feb 2011
AFMCMAN 63-101/20-101, Acquisition Incident Review (AIR) Process, 16 Aug 2016
AFMCMAN 63-1202, Air Force Materiel Command Engineering Technical Assistance (ETAR)
Process, 25 Jan 2018
Air Force Materiel Command Mission Directive 401, Headquarters Air Force Materiel
Command (HQ AFMC), 5 Oct 2021
AFOTEC Operational Test and Evaluation Guide, 11th Edition, 24 Aug 2020
AFPD 63-1/20-1, Integrated Life Cycle Management, 3 Jun 2016
Air Force Human Systems Integration Requirements Pocket Guide, USAF HSI Office, Sep 2009
Air Force Institute of Technology (AFIT) Course Catalog
Air Force Institute of Technology School of Systems and Logistics (AFIT/LS) Life Cycle Risk
Management Group
Air Force Product Support Tool Kit (PSTK), AFLCMC/LG, 1 Sep 2015 Analysis of Alternatives
(AoA) Handbook, Office of Aerospace Studies, 10 Jun 2013
AFMCI63-1201 2 DECEMBER 2022 21
CJCSI 3170.01, Joint Capabilities Integration and Development System (JCIDS), 23 Jan 2015
DAFI 61-201, Management of Scientific and Technical Information (STINFO), 30 Nov 2020
DAFMAN 63-119, Mission-Oriented Test Readiness Certification, 15 Apr 2021
DAFMAN 90-161, Publishing Processes and Procedures, 23 Mar 2022
DAFPAM 63-128, Integrated Life Cycle Management, 3 Feb 2021
Defense Manufacturing Management Guide for Program Managers, 16 Oct 2012
DoDI 5000.83 DAFI 63-113, Technology and Program Protection to Maintain Technological
Advantage, 8 Mar 2022
DoDI 5000.89 DAFI99-103 AFMCSUP, Capabilities-Based Test and Evaluation, 15 Mar 2022
Defense Acquisition Guidebook (DAG), Defense Acquisition University
DLA Form 339, Request for Engineering Support
DLA Form 1912, Defense Logistics Agency Local Purchase – Technical Support Request DoD
Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs, DASD(SE),
Jan 2017
DoD Manufacturing Readiness Level Deskbook, Office of the Secretary of Defense (OSD) SIB
Manufacturing Technology Program, 2020
DoD Technology Readiness Assessment Guidance, Assistant Secretary of Defense for Research
and Engineering, Apr 2011
DoDD 5230.25, Withholding of Unclassified Technical Data from Public Disclosure, 6
November 1984, with Change 1 dated 18 Aug 1995
DoDI 4151.22, Condition Based Maintenance Plus (CBM+) for Materiel Maintenance, 16 Oct
2012
DoDI 5000.02, Operation of the Defense Acquisition System, 7 January 2015; incorporating
Change 1, effective Jan 26, 2017; and Change 2, effective 2 Feb 2017
DoDI 5000.88, Engineering of Defense Systems, 18 Nov 2020
DoDI 5000.89, Test and Evaluation, 19 Nov 2020
DoDI 5000.89 DAFI 99-103, Capabilities-Based Test and Evaluation, 9 Dec 2021
DoDI 5200.39, Critical Program Information Protection within the Department of Defense, 28
May 2015
DoDI 5200.44, Protection of Mission Critical Functions to Achieve Trusted Systems and
Networks (TSN), 6 Nov 2012
DoDI 5230.24, Distribution Statements on Technical Documents, 23 Aug 2012, with Change 1
effective 28 Apr 2016
DoDM 4140.01 Volume 2, DoD Supply Chain Materiel Management Procedures: Demand and
Supply Planning, 9 Nov 2018
22 AFMCI63-1201 2 DECEMBER 2022
DoDM 4140.01, Volume 11, DoD Supply Chain Materiel Management Procedures: Inventory
Accountability and Special Management and Handling, 8 Mar 2017
DoDM 4151.22-M, Reliability Centered Maintenance (RCM), 30 Jun 2011
DoDM 4160.21 Volume 1, Defense Material Disposition: Disposal Guidance and Procedures,
22 Oct 2015
DoDM 4160.21 Volume 2, Defense Material Disposition: Property Disposal and Reclamation,
22 Oct 2015
DoDM 4160.21 Volume 3, Defense Material Disposition: Reutilization, Transfer, and Sale of
Property, 22 Oct 2015
DoDM 4160.21 Volume 4, Defense Material Disposition: Instructions for Hazardous Property
and Other Special Processing Materiel, 22 Oct 2015
EIA-649-1A, Configuration Management Requirements for Defense Contracts, Aug 2020
EIA-649C, Configuration Management Standard, Feb 2019
GEIA-HB-649A, Configuration Management Standard Implementation Guide, 1 Mar 2016
Government - Industry Data Exchange Program (GIDEP), DASD(SE)
(http://www.gidep.org/gidep.htm)
HSI and ESOH Handbook for Pre Milestone a JCIDS and AoA Activities, Department of
Defense, 2013
IEEE 828, Configuration Management in Systems and Software Engineering, 6 Feb 2012
ISO/IEC/IEEE 15288, Systems and Software Engineering – System Life Cycle Processes, 15
May 2015
ISO/IEC/IEEE 15288.1, Application of Systems Engineering on Defense Programs, 5 Jun 2015
ISO/IEC/IEEE 15288.2, Technical Reviews and Audits on Defense Programs, 5 Jun 2015
ISO/IEEE 26702, Systems Engineering – Application and Management of the Systems
Engineering Process, 15 Jul 2007
JP 1-02, Department of Defense Dictionary of Military and Associated Terms, 12 Apr 2001
JP 4-09, Distribution Operations, 5 Feb 2010
Logistics Health Assessment (LHA) User Guide, AFLCMC/LG, 10 Jul 2013
Manual for the Operation of the Joint Capabilities Integration and Development System
(JCIDS), 12 Feb 2015
MIL-HDBK-61B, Configuration Management Guidance, 7 Apr 2020
MIL-HDBK-260, Reference Data for Logistics Metrics, 10 Sep 2014
MIL-HDBK-502A, Product Support Analysis, 6 Mar 2018
MIL-HDBK-520A, Systems Requirements Document Guidance, 19 Dec 2011
MIL-HDBK-524, Interoperable Systems Management and Requirements Transformation
(iSmart) Process, 20 Jun 2012
AFMCI63-1201 2 DECEMBER 2022 23
MIL-HDBK-896A, Manufacturing Management Program Guide, 26 Aug 2016
MIL-HDBK-1587, Materials and Process Requirements for Air Force Weapons Systems, 18 Jul
1996
MIL-HDBK-1785, System Security Engineering Program Management Requirements, 22 Apr
2014
Military Engineering Data Asset Locator System (MEDALS), Defense Logistics Agency
MIL-STD-881, Work Breakdown Structures for Defense Materiel Items, 3 Oct 2011
MIL-STD-882E, System Safety, 11 May 2012
MIL-STD-1472H, Human Engineering, 15 Sep 2020
MIL-STD-3022, Documentation of Verification, Validation, and Accreditation (VV&A) for
Models and Simulations, 5 Apr 2012
MIL-STD-31000B, Technical Data Packages, 31 Oct 2018
MIL-STD-46855A, Human Engineering Requirements for Military Systems, Equipment, and
Facilities, 24 May 2011
Product Data Acquisition, Functional Areas, AF Portal (https://www.my.af.mil/gcss-
af/USAF/ep/globalTab.do?channelPageId=s2D8EB9D629AAD6C8012A3858765B1825)
Program Protection Plan Outline & Guidance, Version 1, DASD(SE), Jul 2011
Risk Management Plan (RMP) Template, Acquisition Document Development and Management
(ADDM) System. See also DAU Examples of Documents Required for Milestone/Decision
Reviews - PM Related
Risk Management Tools - Acquisition Community Connection - DAU
SAE AS9102B, Aerospace First Article Inspection Requirement, 6 Oct 2014,
SAE AS9103A, Quality Management Systems - Variation Management of Key Characteristics,
16 Aug 2012, (http://standards.sae.org)
SD-22, A Guidebook of Best Practices and Tools for Implementing a Proactive DMSMS
Management Program, Defense Standardization Program Office (DSPO), 1 Feb 2015
Systems Engineering Plan (SEP) Outline, v3.0, 12 May 2017
Systems Engineering Working-Level Integrated Product Team (WIPT) Generic Charter
Template, DASD(SE)
System Security Engineering Cyber Guidebook, 26 Jul 2021
TEMP Guidebook, Director, Operational Test & Evaluation (DOT&E), 16 Nov 2015
TO 00-5-1, AF Technical Order System, 1 Oct 2014
TO 00-5-3, AF Technical Order Life Cycle Management, 1 Apr 2015
TO 00-5-15, Air Force Time Compliance Technical Order Process, 31 March 2022
TO 00-20-2, Maintenance Data Documentation, 1 Nov 2012
24 AFMCI63-1201 2 DECEMBER 2022
TO 00-25-107, Maintenance Assistance, 1 Oct 2015
TO 00-35D-54, USAF Deficiency Reporting, Investigation, and Resolution, 15 Apr 2021
TO 1-1-686, Desert Storage Preservation and Process Manual for Aircraft, Aircraft Engines,
and Aircraft Auxiliary Power Unit Engines, with Change 5, 5 Dec 2014
USAF Acquisition Process Model, SAF/AQ
Verification, Validation & Accreditation Recommended Practices Guide (RPG), DoD Modeling
& Simulation Coordination Office (M&SCO)
Adopted Forms.
AFMC Form 202, Engineer Technical Assistance Request, 30 Sep 2022
Abbreviations and Acronyms
ACAT—Acquisition Category
ADDM—Acquisition Document Development and Management (System)
AF—Air Force
AFI—Air Force Instruction
AFIT—Air Force Institute of Technology
AFLCMC—Air Force Life Cycle Management Center
AFMAN—Air Force Manual
AFMC—Air Force Materiel Command
AFMCI—Air Force Materiel Command Instruction
AFMCSUP—Air Force Materiel Command Supplement
AFMCMAN—Air Force Materiel Command Manual
AFNWC—Air Force Nuclear Weapons Center
AFOTEC—Air Force Operational Test and Evaluation Center
AFPAM—Air Force Pamphlet
AFPD—Air Force Policy Directive
AFRL—Air Force Research Laboratory
AFSAC—Air Force Security Assistance Cooperation (Directorate)
AFSC—Air Force Sustainment Center
AIR—Acquisition Incident Review
AMARG—Aerospace Maintenance and Regeneration Group
AoA—Analysis of Alternatives
AS—Acquisition Strategy
AFMCI63-1201 2 DECEMBER 2022 25
ASD—Assistant Secretary of Defense
ASDP—Acquisition and Sustainment Data Package
ASSIST—Acquisition Streamlining and Standardization Information System
ATD—Advanced Technology Demonstration
CBA—Capabilities-Based Assessment
CBM+—Condition Based Maintenance Plus
CCB—Configuration Control Board
CDD—Capability Development Document
CDR—Critical Design Review
CDRL—Contract Data Requirements List
CE—Chief Engineer
CEP—Circular Error Probable
CI—Configuration Item
CJCSI—Chairman Joint Chiefs of Staff Instruction
CLA—Center Level Agreement
CLS—Contractor Logistics Support
CM—Configuration Management
CMP—Configuration Management Plan
COTS—Commercial Off-the-Shelf
CPD—Capability Production Document
CPI—Critical Program Information
CSI—Critical Safety Item
CUI—Controlled Unclassified Information
DAG—Defense Acquisition Guidebook
DASD—Deputy Assistant Secretary of Defense
DASD(SE)—Deputy Assistant Secretary of Defense, Systems Engineering
DAF—Department of the Air Force
DAU—Defense Acquisition University
DID—Data Item Description
DLA—Defense Logistics Agency
DMSMS—Diminishing Manufacturing Sources and Materiel Shortages
DoD—Department of Defense
26 AFMCI63-1201 2 DECEMBER 2022
DoDAF—DoD Architecture Framework
DoDD—Department of Defense Directive
DoDI—Department of Defense Instruction
DoDM—Department of Defense Manual
DoE—Director of Engineering
DOT&E—Director, Operational Test and Evaluation
DR—Deficiency Report
DSPO—Defense Standardization Program Office
DT&E—Developmental Test and Evaluation
ECP—Engineering Change Proposal
EIA—Electronic Industries Alliance
EMA—Expectations Management Agreement
EMD—Engineering and Manufacturing Development
ESOH—Environment, Safety, and Occupational Health
ETAR—Engineering Technical Assistance Request
FCA—Functional Configuration Audit
FMECA—Failure Modes, Effects, and Criticality Analysis
FMS—Foreign Military Sales
FoS—Family of Systems
F3I—Form, Fit, Function, and Interface
FYDP—Future Years Defense Program
GEIA—Government Electronics Information-technology Association
GFE—Government Furnished Equipment
GIDEP—Government - Industry Data Exchange Program
GOTS—Government Off-the-Shelf
HSI—Human Systems Integration
IAW—In Accordance With
ICD—Initial Capabilities Document
IEC—International Electrotechnical Commission
IEEE—Institute of Electrical and Electronics Engineers
IER—Information Exchange Requirement
IHA—Intelligence Health Assessment
AFMCI63-1201 2 DECEMBER 2022 27
IMD—Intelligence Mission Data
IOT&E—Initial Operational Test and Evaluation
IPT—Integrated Product Team
ISA—Intelligence Supportability Analysis
ISO—International Organization for Standardization
IT—Information Technology
ITT—Integrated Test Team
ITRA—Independent Technical Risk Assessment
IUID—Item Unique Identification
JCIDS—Joint Capabilities Integration and Development System
JCTD—Joint Capability Technology Demonstration
JP—Joint Publication
KPP—Key Performance Parameter
KSA—Key System Attribute
LCSE—Life Cycle Systems Engineering
LCSP—Life Cycle Sustainment Plan
LHA—Logistics Health Assessment
LIMS-EV—Logistics, Installations, and Mission Support - Enterprise View
LSE—Lead Systems Engineer
MAJCOM—Major Command
MDA—Milestone Decision Authority
MDAP—Major Defense Acquisition Program
MEDALS—Military Engineering Data Asset Locator System
MIE—Materiel Intelligence Enterprise
MIM—Mission Integration Management
MOA—Memorandum of Agreement
MoE—Measure of Effectiveness
MoP—Measure of Performance
MoS—Measure of Suitability
MOSA—Modular Open Systems Approach
MOU—Memorandum of Understanding
MTBCF—Mean Time Between Critical Failure
28 AFMCI63-1201 2 DECEMBER 2022
M&S—Modeling and Simulation
M&SCO—Modeling and Simulation Coordination Office
NDAA—National Defense Authorization Act
NDI—Non-Destructive Inspection
NSI—Nuclear Surety Inspection
OAS—Office of Aerospace Studies
OI—Operating Instruction
OPR—Office of Primary Responsibility
ORI—Operational Readiness Inspection
OSD—Office of the Secretary of Defense
OSS&E—Operational Safety, Suitability, and Effectiveness
O&M—Operations and Maintenance
O&S—Operations and Sustainment
PCA—Physical Configuration Audit
PDR—Preliminary Design Review
PDRC—Program Data Rights Council
PEO—Program Executive Officer
PGM—Product Group Manager
PHS&T—Packaging, Handling, Storage, and Transport
PLM—Product Lifecycle Management
PM—Program Manager
PMO—Program Management Office
POC—Point of Contact
PPP—Program Protection Plan
PSE—Peculiar Support Equipment
PSM—Product Support Manager
PSTK—Product Support Tool Kit
PWS—Performance Work Statement
QAP—Quality Assurance Program
RCM—Reliability Centered Maintenance
RFP—Request for Proposal
RMP—Risk Management Plan
AFMCI63-1201 2 DECEMBER 2022 29
RPG—Recommended Practices Guide
SAE—Society of Automotive Engineers
SSC—Space Systems Command
SCM—Supply Chain Manager
SE—Systems Engineering
SEP—Systems Engineering Plan
SFR—System Functional Review
SLA—Service Level Agreement
SMA—Services Management Agreement
SME—Subject Matter Expert
SOO—Statement of Objectives
SoS—System-of-systems
SOW—Statement of Work
SPO—System Program Office (a.k.a. Program Management Office (PMO))
SRD—System Requirements Document
SSE—Systems Security Engineering
SSG—System Safety Groups
STAR—System Threat Assessment Report
STINFO—Scientific and Technical Information
SVR—System Verification Review
S&T—Science and Technology
TCTO—Time Compliance Technical Order
TDP—Technical Data Package
TEMP—Test and Evaluation Master Plan
TFS—Transition, Fielding, and Sustainment
TMRR—Technology Maturation and Risk Reduction
TNMCM—Total Not Mission Capable for Maintenance
TNMCS—Total Not Mission Capable for Supply
TO—Technical Order
TPM—Technical Performance Measure
TPS—Test Program Set
TSN—Trusted Systems and Networks
30 AFMCI63-1201 2 DECEMBER 2022
T&E—Test and Evaluation
UCI—Unit Compliance Inspection
URL—Uniform Resource Locator
USAF—United States Air Force
U.S.C—United States Code
USG—United States Government
VV&A—Verification, Validation, and Accreditation
WBS—Work Breakdown Structure
WG—Working Group
WIPT—Working-level Integrated Product Team
Office Symbols
AFLCMC/EN—AFLCMC Engineering Directorate
AFMC/EN—AFMC Engineering Directorate
AFLCMC/LG—AFLCMC Logistics Directorate
AFMC/ENS—AFMC Systems Engineering Division
AFNWC/EN—AFNWC Engineering Directorate
SAF/AQR—SAF Science, Technology, and Engineering
SSC/ZAE—SSC Portfolio Architect Engineering
Terms
Accountability—The continuous obligation of an individual to answer for assigned activities and
resources, to accept responsibility for them, and to disclose status and results in a transparent
manner. It is also the reckoning, when an individual must answer for decisions and actions and
accept the consequences, good or bad.
Allocated Baseline—The system's or configuration item’s (CI) documented, validated, and
approved "design-to" requirements, and all changes thereto approved IAW the contract. The
allocated baseline includes (a) the physical hierarchy, (b) the design-to requirements for each
product in the hierarchy, and (c) separable documentation identifying all design-to requirements
for each component and integrated grouping of components.
Authority—The legitimate right or power of an individual to make determinations or direct
actions within the scope of the position to achieve specific objectives. Assigned persons are
responsible to exercise their authority to accomplish the assigned task(s).
(Aviation) Critical Safety Item—A part, assembly, installation equipment, launch equipment,
recovery equipment, or support equipment for an aircraft or aviation weapons system that contains
a characteristic for which any failure, malfunction, or absence could cause a catastrophic or critical
failure resulting in the loss or serious damage to the aircraft or weapons system; an unacceptable
risk of personal injury or loss of life; or an un-commanded engine shutdown that jeopardizes safety.
AFMCI63-1201 2 DECEMBER 2022 31
Damage is considered serious or substantial when it would be sufficient to cause a "Class A"
accident or a mishap of severity category I.
Configuration Items—Aggregations of work products that are designated for configuration
management and are treated as single entities within the configuration management process.
Data Management—The practice of putting into place policies, procedures, and best practices to
ensure that data is understandable, trusted, visible, accessible, and interoperable. Data
Management functions include processes and procedures that cover planning, data acquisition,
data rights assertions, modeling, security, cybersecurity, access control, and quality. Outcomes of
Data Management include the improvement of data quality and assurance, enablement of
information sharing, and the fostering of data reuse by minimizing data redundancy.
DULL SWORD—A reporting term identifying a nuclear weapon safety deficiency.
End Item—Equipment that can be used by itself to perform a military function. The final
production product, assembled or completed, and ready for issue/deployment.
Engineering—The profession concerned with the application of mathematic and scientific
principles to design, build, and use actual and/or virtual architectures, mechanisms, and structures.
Engineering Change Proposal—The documentation by which a proposed engineering change is
described, justified, and submitted to (1) the current document change authority for
approval/disapproval or deferral of the design change in the documentation, and (2) to the
procuring activity for approval/disapproval or deferral of implementing the design change in units
to be delivered or retrofit into assets already delivered.
Expectation Management Agreement—A jointly developed and formally documented
agreement between the PM and the functional sponsor to proactively resolve or de-conflict
potential issues to include cost, schedules, and performance expectations of the program. Note:
the term "EMA" has been replaced by Services Management Agreement (SMA) in AFI 63-138,
Acquisition of Services.
Family of Systems—A set of systems that provide similar capabilities through different
approaches to achieve similar or complementary effects.
Functional Baseline (a.k.a., Requirements Baseline)—The documented, validated, and
approved system-level or CI (top level) functional and performance requirements and design
constraints, their allocation or assignment to the next level, and all changes thereto approved IAW
the contract. Typically, this baseline is initially approved at the System Functional Review or
similar event.
Integrated Digital Environment—A compilation of data, models, and tools for collaboration,
analysis, and visualization across all functional domains. IDE includes the methodology and
specification for data, models, and tools arrangement with processes and procedures to exploit
informational results.
Item Performance Specification—A program-unique specification, usually approved as part of
the allocated baseline (formerly called a “B Specification” or “Development Specification”).
States all necessary design requirements of a CI in terms of performance. Essential physical
constraints are included. Item performance specifications state requirements for the development
of items below the system level. They specify all of the required item functional characteristics
and the tests required to demonstrate achievement of those characteristics.
32 AFMCI63-1201 2 DECEMBER 2022
Operational Effectiveness—The overall degree of mission accomplishment of a system or end
item used by representative personnel in the environment planned or expected (e.g., natural,
electronic, threat) for operational employment, considering organization, doctrine, tactics,
cybersecurity, force protection, survivability, vulnerability, and threat (including countermeasures;
initial nuclear weapons effects; and nuclear, biological, and chemical contamination threats). The
PM maintains the operational effectiveness of the system by ensuring that it continues to satisfy
the documented user capability requirements.
Operational Safety—The level of safety risk to the system, the environment, and the occupational
health caused by a system or end item when employed in an operational environment. The PM
shall utilize the established system safety process to assure operational safety.
Operational Suitability—The degree to which a system or end item can be placed satisfactorily
in field use, with consideration given to availability, compatibility, transportability,
interoperability, reliability, maintainability, wartime use rates, full-dimension protection,
operational safety, human factors, architectural and infrastructure compliance, manpower
supportability, logistics supportability, natural environmental effects and impacts, and
documentation and training requirements.
Product Baseline—The "build-to" requirements for each physical element to be manufactured;
the software code for each software element that has been separately designed or tested; and the
"buy-to" requirements for any other physical element, part, or material to be procured from a
subcontractor or vendor.
Product Group—A set of products that use similar or same production processes, have similar
physical characteristics, or share customer segments, distribution channels, pricing methods, etc.
Product Group Manager—The manager of a product group (e.g., Life Support, Avionics,
Automatic Test Equipment) responsible for all cost, schedule, and performance aspects of a
product group and related sustainment activities. Product Groups and Product Group Managers are
typically appointed when enterprise management of materiel used to support multiple weapon
systems is desired to improve interoperability and decrease costs through commonality.
Product Support Manager—The individual responsible for managing the package of support
functions required to field and maintain the readiness and operational capability of major weapon
systems, subsystems, and components, including all functions related to weapon system readiness,
in support of the PM’s life cycle management responsibilities.
Program—A directed, funded effort that provides a new, improved, or continuing materiel,
weapon, or information system or service capability in response to an approved need. Acquisition
programs are divided into acquisition categories that are established to facilitate decentralized
decision making, execution, and compliance with statutory requirements.
Program Management Office—The integrated organization responsible for cradle-to-grave
military system management. Formerly known as the System Program Office (SPO).
Quality—The composite of material attributes, performance features and characteristics of a
product to satisfy a given need.
Quality Assurance—A planned and systematic pattern of actions necessary to provide confidence
that adequate technical requirements are established; products conform to established technical
requirements; and satisfactory performance is achieved.
AFMCI63-1201 2 DECEMBER 2022 33
Responsibility—The obligation to act or to do a task that one must answer for either to team
members, assessors, auditors, inspectors, or supervisors. When an individual has responsibility for
a task, the individual requires the authority necessary to carry it out.
Services Designated Official—The individual designated in accordance with Title 10 U.S.C.
Section 4502 to exercise responsibility for the management of the acquisition of services. These
responsibilities include certifying that service acquisitions are performance-based during
acquisition strategy formulation; and approving, in advance, any acquisition that is not
performance-based.
Services Management Agreement—An agreement executed between responsible Services
Designated Officials, organizational leadership, and/or executing organizations delineating the
expectations, responsibilities, and delegations within the relationship. Note: term replaces
Expectation Management Agreement (EMA) in AFI 63-138, Acquisition of Services.
Subsystem—A functional grouping of components that combine to perform a major function
within an element such as electrical power, attitude control, and propulsion.
Supply Chain Manager—Designated individual responsible for managing a line of National
Stock Number-coded items. SCM functions include requirements determination; engineering
responsibility for items delegated from the Program Offices; cataloging, standardization, and
engineering data management; stock control and distribution; technical management functions;
and pricing for their assigned items.
System—A specific grouping of subsystems, commodities, and/or components designed and
integrated to perform a military function.
System of Systems—A set or arrangement of systems that results when independent and useful
systems are integrated into a larger system that delivers unique capabilities.
Systems Engineering—Comprises the scientific, technical, and managerial efforts needed to
define/refine requirements, develop, test, verify, deploy, support, sustain and dispose of a product,
platform, system, or integrated System-of-Systems/Family-of-Systems (SoS/FoS) capability to
meet user needs. SE may be referred to as a discipline, a methodology, an approach, a practice, a
process, a set of processes and sub-processes, or various other terms; however, its fundamental
elements – systematic technical and managerial processes and measurements – remain the same
regardless of the collective nomenclature.
Systems Security Engineering—An element of systems engineering that applies scientific and
engineering principles to identify security vulnerabilities and minimize or contain risks associated
with these vulnerabilities.
Technical—Relating to special and/or practical knowledge of an engineering or scientific nature,
having special knowledge of how a particular kind of work (involving but not necessarily limited
to science and engineering) is done.
Technical Data Package—The authoritative technical description of an item. This technical
description supports the acquisition, production, inspection, engineering, and logistics support of
the item. The description defines the required design configuration and/or performance
requirements, and procedures required to ensure adequacy of item performance. It consists of
applicable technical data such as models, engineering design data, associated lists, specifications,
standards, performance requirements, quality assurance provisions, software documentation and
34 AFMCI63-1201 2 DECEMBER 2022
packaging details. (NOTE: The Product Level TDP, per MIL-STD-31000B, is NOT sufficient to
produce, maintain, sustain, operate, and modify weapon systems (e.g., software). The Acquisition
& Sustainment Data Package (ASDP) was developed within that defines the data need to produce,
maintain, sustain, operate, and modify weapon systems and is located on the Digital Guide)
Technical Baseline—Includes a functional baseline, an allocated baseline, and a product baseline.
Each is a reference from which to measure progress of the System's or CI’s development. They
enable the underlying "design-to" process using a common reference. Once a baseline is
established, change becomes a formalized process, which provides stability during design.
Management of the technical baselines is generally referred to as Configuration Management
(CM).
Technical Performance Measure—A subset of metrics and measures that evaluates technical
progress (i.e., product maturity). TPMs support evidence-based decisions at key points such as
technical reviews, audits, and milestone decisions. TPMs compare the actual versus planned
technical development and design; they report progress and the degree to which system
performance requirements are met. Systems engineering uses TPMs to balance cost, schedule, and
performance throughout the life cycle and can be integrated with other management methods.
TPMs from the lower-level products are used to continuously measure growth toward meeting the
required KPP goal at the end of development. NOTE: For additional terms and definitions not
provided here see JP 1-02, Department of Defense Dictionary of Military and Associated Terms,
and Air Force Doctrine Document 1-2, Air Force Glossary, which contain standardized terms and
definitions for DoD and Air Force use.
AFMCI63-1201 2 DECEMBER 2022 35
Attachment 2
LIFE CYCLE SYSTEMS ENGINEERING PROCESSES
A2.1. Description. This attachment provides a description of the life cycle processes used to
implement successful systems engineering for AFMC programs.
A2.2. Need for Systems Engineering. The continuous need for systems engineering is driven by
the increasing technical complexity and development costs of defense acquisition programs.
Congressional and DoD guidance emphasizes the need for sustained, disciplined processes and
process improvement, including the assessment of SE process performance.
A2.3. Project Planning.
A2.3.1. Project (program) planning is a multi-disciplined process used to establish and
maintain plans that define program activities. In the context of LCSE, project planning starts
by aligning engineering/technical activities with the Acquisition Strategy (AS) and is followed
by planning engineering/technical activities in increasing levels of detail. The resulting plans
should be periodically reviewed for consistency with the overall acquisition plan. The
acquirer’s and suppliers’ program planning processes are continuous, and the plans evolve to
meet program and operational needs.
A2.3.2. Project planning relates technical objectives, constraints, availability of assets and
technologies, accommodation of user considerations, consideration of risk, and technical
support for the program over the life cycle. It defines the scope of the technical effort required
to develop, field, and sustain the system; provides the program’s plan for technical reviews
and audits; and provides critical quantitative inputs to program planning and life-cycle cost
estimates. It establishes a framework for the PM and LSE/CE to accomplish the technical
activities that collectively increase product maturity and knowledge while reducing technical
risks. It should also account for resources (skilled workforce, support equipment/tools,
facilities, etc.) necessary to develop, test, produce, deploy, and sustain the system. Technical
project planning is captured primarily in the SEP.
A2.3.3. Recommended Minimum Actions:
A2.3.3.1. Define project life cycle phases, milestones, and key decision points.
A2.3.3.2. Identify and plan for the involvement of project stakeholders.
A2.3.3.3. Define the attributes (e.g., weight, size, reliability, security and resource
requirements, detection range) based on requirements document (e.g., 1067, ICD, and
CDD) that scope each product-component and task that are of concern to the project.
A2.3.3.4. Develop a plan for the management of project technical data required to manage
and support a system throughout its lifecycle. Programs should consider making this data
management plan separate from the configuration management plan, especially if using a
digital acquisition approach. The data management plan should address the following for
project technical data in line with the intellectual property strategy and lifecycle mission
data plan (for intelligence mission data dependent programs) and IAW the Air Force
Digital Guide, DoDI 5010.44, DoD 5010.12-M, and AFI 63-101/20-101:
A2.3.3.4.1. Data identification and justification, including data formats
36 AFMCI63-1201 2 DECEMBER 2022
A2.3.3.4.2. Data acquisition
A2.3.3.4.3. Data deliverables and timeline, including identifying stakeholders who
need to use the data
A2.3.3.4.4. Data protection (e.g., ensure compliance with DoD cybersecurity
requirements for the purpose of interoperating in an integrated digital environment)
A2.3.3.4.5. Intelligence Mission Data production shortfalls and associated risks
A2.3.3.4.6. Determination of, and necessary adjustments throughout the life cycle to,
Controlled Unclassified Information (CUI) and Scientific and Technical Information
(STINFO) distribution control markings (i.e., appropriate distribution statement
authorized audience, up-to-date controlling office information, export control
determination and marking, destruction notice and any other applicable control
markings) IAW DAFI 61-201, DoDI 5200.48, DoDI 5230.24 and DoDD 5230.25.
A2.3.3.4.7. Data verification (e.g., review to ensure meets contract requirements and
for technical accuracy; data and metadata conform to a common data architecture and
are easily searchable, revised, and controlled; etc.).
A2.3.3.4.8. Data storage, including organization of the data. Storage of data may be
accomplished through the usage of a digital environment integrated with Siemens’
Teamcenter for the PLM data management platform per the Jan 2021 PLM Enterprise
Systems memo from SAF/AQ. In that case, the plan should address change control
within the integrated digital environment.
A2.3.3.4.9. Data maintenance (e.g., long term archival and retrieval, version control)
A2.3.3.4.10. Program Office shall use either the term “System Architecture” or
“Solution Architecture” for architectural design work specific to one weapon system
and should avoid using the term “Reference Architecture” for any work that is not
guiding design principles of multiple architectures and solutions.
A2.3.3.4.11. Identify available weapon system Government Reference Architectures
that satisfy the Mission and Capability Reference Architectures to be used to guide and
constrain a weapon system solution architecture (A list of available Government
Reference Architectures can be found on the Digital Guide at
https://usaf.dps.mil/teams/afmcde/SitePages/Government-Reference-
Architecture.aspx.
A2.3.3.4.12. Program Offices should follow the Modular Open Systems Approach
(MOSA) guidelines spelled out in the AFMC MOSA Implementation Plan.
A2.3.4. Artifacts:
A2.3.4.1. Integrated Master Plan and Integrated Master Schedule
A2.3.4.2. Systems Engineering Plan; Life Cycle Sustainment Plan
A2.3.4.3. Program Protection Plan, with appendices including the Cybersecurity Strategy
A2.3.4.4. Work Breakdown Structure (WBS)
A2.3.4.5. Data Management Plan, with Security Classification Guide (if applicable)
AFMCI63-1201 2 DECEMBER 2022 37
A2.3.4.6. Project stakeholder MOAs, MOUs, Expectation Management Agreements
(EMA), and/or Service Level Agreements (SLA) as applicable
A2.3.5. DoDI 5000.02 and AFI 63-101/20-101 provide the primary regulatory guidance for
project planning. For additional information, see the following sources:
A2.3.5.1. SAF/AQ, USAF Acquisition Process Model
A2.3.5.2. IEEE 15288.2, Technical Reviews and Audits on Defense Programs
A2.3.5.3. MIL-STD-881, Work Breakdown Structures for Defense Materiel Items
A2.3.5.4. DASD(SE), Systems Engineering Plan (SEP) Outline
A2.4. Decision Analysis.
A2.4.1. The decision analysis process is used to consider possible decisions, using a formal
process, that evaluates identified alternatives against established criteria. It is often a multi-
disciplined activity requiring considerations of costs, schedules, risks, sustainment impacts and
other factors. A repeatable, criteria-based decision-making process is especially important,
both while making the critical decisions that define and guide the acquisition process itself and
later when critical decisions are made with the selected suppliers. The establishment of a
formal process for decision making provides the program with documentation of the decision
rationale. Such documentation allows the criteria for critical decisions to be revisited when
changes that impact program requirements or other critical program parameters change.
A2.4.2. Decision analysis and associated trade studies should be integrated with, and mutually
supportive of, aspects of several SE processes in the early stages of the program, particularly
technical planning and assessments, stakeholder requirements definition and analysis, and
architecture design.
A2.4.3. Recommended Minimum Actions:
A2.4.3.1. Establish and maintain guidelines to determine which issues are subject to a
formal evaluation process.
A2.4.3.2. Determine technical review requirements and associated entry/exit criteria.
A2.4.3.3. Identify, document, and evaluate alternative solutions to program requirements.
A2.4.4. Artifacts:
A2.4.4.1. Decision guidelines, including evaluation criteria and methods
A2.4.4.2. Technical review entry/exit criteria and meeting minutes
A2.4.4.3. Analysis of Alternatives; trade studies / tradeoff analyses
A2.4.4.4. Decision briefings (as applicable)
A2.4.5. For additional information on decision analysis see the following sources:
A2.4.5.1. AFI 63-101/20-101
A2.4.5.2. MIL-HDBK-502A, Product Support Analysis
A2.4.5.3. MIL-HDBK-520A, Systems Requirements Document Guidance
A2.4.5.4. Office of Aerospace Studies (OAS), Analysis of Alternatives (AoA) Handbook
38 AFMCI63-1201 2 DECEMBER 2022
A2.5. Technical Management and Control.
A2.5.1. The technical management and control process enables the PM and LSE/CE to
compare achieved results against defined criteria to provide a fact-based understanding of the
current level of product knowledge, technical maturity, program status and technical risk. This
assessment results in a better understanding of the health and maturity of the program, giving
the PM a sound technical basis upon which to make program decisions. It is also utilized to
provide an understanding of the program’s technical progress so that corrective actions can be
taken when the program’s performance deviates significantly from the plan. A deviation is
significant if, when left unresolved, it precludes the program from meeting its objectives.
Corrective actions may require revising the original plan, establishing new agreements, and/or
including additional risk/issue handling activities in the current plan. If a corrective action is
required to resolve variances from program plans, these actions should be defined and tracked
to closure.
A2.5.2. A program’s documented engineering/technical plans (e.g., SEP, Life Cycle
Sustainment Plan (LCSP), T&E Master Plan (TEMP)) are the basis for monitoring activities,
communicating status and taking corrective actions. Progress is primarily determined by
comparing actual work product and task attributes, effort, cost, and schedule to the plan at
prescribed milestones or control levels in the program schedule and/or WBS. The PM and
LSE/CE typically evaluate technical maturity in support of program decisions at the key event-
driven technical reviews and audits that occur throughout the acquisition life cycle. The
program uses various measures and metrics, including Technical Performance Measures
(TPM) and leading indicators, to gauge technical progress against planned goals, objectives,
and requirements.
A2.5.3. Monitoring and control functions are typically established early in the program as the
program’s planning is performed and the acquisition strategy is defined. As the acquisition of
technology solutions unfolds, monitoring and control activities are essential to ensure that
appropriate resources are being applied and that program activities are progressing according
to plan.
A2.5.4. Recommended Minimum Actions:
A2.5.4.1. Define and implement technical standard work and process guidelines.
A2.5.4.2. Establish and maintain engineering/technical integrated product teams (IPT).
A2.5.4.3. Plan and conduct technical reviews and audits IAW process guidelines and
technical review entry/exit criteria.
A2.5.4.4. Establish and maintain a program measurement approach to track technical work
products and program data.
A2.5.4.5. Monitor and manage corrective actions to closure (use a deficiency reporting
system as appropriate).
A2.5.5. Artifacts:
A2.5.5.1. Standard operating procedures (OIs, guides, standard processes, etc.)
A2.5.5.2. Technical planning documents (e.g., SEP, LCSP, TEMP)
AFMCI63-1201 2 DECEMBER 2022 39
A2.5.5.3. Technical IPT (e.g., Configuration Control Board, Deficiency Review Board)
charters and minutes
A2.5.5.4. Program/system/item technical metrics.
A2.5.5.5. Technical status and deficiency reports
A2.5.5.6. Technical review meeting minutes and audit reports
A2.5.5.7. Corrective action plans and reports
A2.5.6. For additional information on technical management and control see the following
sources:
A2.5.6.1. DASD(SE), Systems Engineering Working-Level Integrated Product Team
(WIPT) Generic Charter Template
A2.5.6.2. MIL-HDBK-61B, Configuration Management Guidance
A2.5.6.3. EIA-649C, Configuration Management Standard
A2.5.6.4. EIA-649-1A, Configuration Management Requirements for Defense Contracts
A2.5.6.5. GEIA-HB-649A, Configuration Management Standard Implementation Guide
A2.5.6.6. MIL-HDBK-189, Reliability Growth Management
A2.5.6.7. EIA-748, Earned Value Management Systems
A2.5.6.8. ISO/IEEE 15288.2, Technical Reviews and Audits on Defense Programs
A2.5.6.9. TO 00-35D-54, USAF Deficiency Reporting, Investigation and Resolution
A2.5.6.10. AFOTEC Operational Test and Evaluation Guide, 11th Edition, 24 Aug 2020
A2.5.6.11. Assistant Secretary of Defense for Research and Engineering, DoD Technology
Readiness Assessment Guidance
A2.6. Requirements.
A2.6.1. The requirements process is used to develop and analyze user, product and component
requirements to assure consistency between them and the program’s technical plans and work
products, and to manage requirements evolution through the life cycle.
A2.6.2. Developing increasingly detailed derived requirements is a continuous, iterative
process that occurs as the multiple layers of a complex product are defined (for example,
requirements flow from the stakeholders to the product, segment, etc., and eventually down to
hardware and/or software component levels). See Figure A2.1.
A2.6.2.1. As more detailed design requirements are identified, program stakeholders can
make informed trades between the requirements and available resources, potentially
achieving a match and establishing a sound basis for a program business case. As the
requirements decomposition process takes place, engineering and design knowledge grows
and overall risk should decrease, leading to more realistic cost and schedule estimates and
more predictable program outcomes.
A2.6.2.2. The responsibility for developing requirements down through the levels is
generally met through partnerships between the government and vendor stakeholders. The
40 AFMCI63-1201 2 DECEMBER 2022
government organizations are generally more responsible for the higher levels (starting
with operational requirements), and the vendors are generally more responsible for lower
levels. The division of responsibilities between the government and vendor partners is
specific to each program.
Figure A2.1. Requirements Decomposition and Systems Engineering.
A2.6.3. Each government office that has a stake in the requirements process is typically
responsible for defining and baselining the requirements levels under its control and
monitoring the vendors’ definition(s) at their levels. Requirements should be managed and
maintained with discipline so that changes are not executed without recognizing the impacts
to the program, system and user(s). Requirements should be analyzed throughout the product
life cycle to ensure they are both necessary and sufficient.
A2.6.4. Recommended Minimum Actions:
A2.6.4.1. Identify and involve stakeholders when developing requirements.
A2.6.4.2. Identify and document primary (operational user), compulsory (e.g., statutory,
regulatory, KPPs, interfaces), and derived (programmatic) requirements.
A2.6.4.3. Prioritize the requirements.
A2.6.4.4. Manage the requirements (avoid requirements creep).
A2.6.4.5. Ensure requirements have bidirectional traceability from the user need to the
design solution.
A2.6.5. Artifacts:
A2.6.5.1. Requirements stakeholder lists, with MOAs/MOUs/EMAs/SMAs as required
AFMCI63-1201 2 DECEMBER 2022 41
A2.6.5.2. Stakeholder requirements documents (e.g., JCIDS requirements documents,
Concept of Operations, System Requirements Document (SRD), Request for Proposal
(RFP), performance specifications).
A2.6.5.3. Requirements traceability matrix / correlation matrix or table
A2.6.5.4. Functional baseline, allocated baseline, product baseline
A2.6.5.5. Technical review documentation (e.g., entrance and exit criteria, meeting
minutes, action items)
A2.6.6. For additional information on requirements see the following sources:
A2.6.6.1. CJCSI 3170.01, Joint Capabilities Integration and Development System
(JCIDS), and the JCIDS Manual
A2.6.6.2. MIL-HDBK-520A, Systems Requirements Document Guidance
A2.6.6.3. MIL-HDBK-524, Interoperable Systems Management and Requirements
Transformation (iSmart) Process
A2.6.6.4. MIL-HDBK-1587, Materials and Process Requirements for Air Force Weapons
Systems
A2.6.6.5. MIL-HDBK-1785, System Security Engineering Program Management
Requirements
A2.6.6.6. MIL-STD-46855A, Human Engineering Requirements for Military Systems,
Equipment, and Facilities
A2.6.6.7. AFI 10-601, Operational Capability Requirements Development
A2.7. Risk Management.
A2.7.1. The risk management process is used to identify potential problems before they occur,
so that risk handling activities may be planned and implemented as needed to increase the
chances of meeting program objectives within the program's constraints.
A2.7.2. IAW DoDI 5000.02 and AFI 63-101/20-101, PMs pursue comprehensive, integrated
risk analysis throughout the life cycle and prepare/maintain a Risk Management Plan (RMP).
The PM has primary responsibility for risk management and the RMP; the program LSE/CE
takes program direction from the PM and ensures that technical risks are incorporated into both
the program’s overall risk management effort and its LCSE strategy. Risk identification and
estimation of likelihood and consequences, particularly for those risks involved in meeting
cost/schedule/performance requirements, largely determine the acquisition strategy. For this
reason, the RMP is typically incorporated into the Acquisition Strategy or other appropriate
planning document. The RMP is linked to the risk management activities described in other
planning documents (e.g., Source Selection Plan, LCSP, SEP, and Programmatic
Environmental, Safety and Occupational Health Evaluation).
A2.7.2.1. The LSE/CE, in support of the PM, for threat/intelligence-sensitive
activities/projects/programs, works with the program’s assigned acquisition intelligence
support to incorporate intelligence mission data (IMD) shortfall and threat risk
considerations, including the likelihood and consequence(s) of critical intelligence
42 AFMCI63-1201 2 DECEMBER 2022
parameter breaches, into the technical risk management process through the intelligence
supportability analysis (ISA) process.
A2.7.2.1.1. IAW the AFMC Materiel Intelligence Enterprise (MIE) Manual, an
activity, project or program shall be considered threat/intelligence-sensitive if at any
point in its lifecycle the effort: 1) produces, consumes, processes, or handles
intelligence information; 2) requires intelligence-related Doctrine, Organization,
Training, Materiel, Leadership and Education, Personnel, Facilities, and Policy or
Planning and Direction, Collection, Processing, Analysis and Production, and
Dissemination intelligence support; or 3) requires threat support to make programmatic
decisions.
A2.7.2.1.2. ISA is the process by which intelligence-related requirements and
supporting intelligence infrastructure necessary to successfully acquire and employ
DAF capabilities are identified, documented, planned for, and addressed, thereby
ensuring intelligence supportability. Intelligence health assessments (IHA) detail the
status of a program’s intelligence supportability and identify intelligence-related risks
derived through the ISA process, including IMD risk management planning IAW
DODD 5250.01. IHA factors shall be evaluated and incorporated into a program’s
overall risk assessment. IAW the AFMC MIE Manual, assigned Senior Intelligence
Officers shall develop IHAs, as appropriate, to support risk management decisions by
PEOs, technology executive offices, and other Materiel Leaders (e.g., Program/Project
Managers).
A2.7.3. Independent Technical Risk Assessments (ITRAs) in accordance with Title 10,
U.S.C., Section 4271, shall be conducted on all Major Defense Acquisition Programs prior to
Milestone A or B approval, and any decision to enter into low-rate initial production or full-
rate production. ITRAs shall be completed in a timely manner to facilitate milestone or
production decisions by the Milestone Decision Authority (MDA), and every effort shall be
expended to prevent any unreasonable delay.
A2.7.3.1. The ITRA shall consider the full spectrum of Technology, Engineering and
Integration risk and the potential impacts to cost, schedule, and performance. ITRAs
provide a view of program technical risk, independent of the program or component. When
conducted in the first instance for each covered program, the ITRA shall facilitate the
MDA's establishment of program cost, schedule, and performance goals as required by title
10, U.S.C. Section 4271.
A2.7.3.2. An ITRA conducted prior to Milestone A shall identify critical technologies and
manufacturing processes that need to be matured. At subsequent milestone or production
decisions, ITRAs shall identify critical technologies and manufacturing processes that have
not been successfully demonstrated in a relevant environment. ITRAs shall be provided to
the MDA to support the determinations, certifications, and reporting to Congress in
accordance with Title 10, U.S.C., Sections 4251, 4252, and 4253.
A2.7.4. Recommended Minimum Actions:
A2.7.4.1. Develop a risk management approach. The approach should include the intent
to identify risk "cause and effect chains" which include root causes (a.k.a. risk events),
contributing causes, impacts, and outcomes. The approach should address all risk
AFMCI63-1201 2 DECEMBER 2022 43
categories/areas/events that may have a detrimental impact on at least one dimension of
consequence (cost/schedule/performance) for the program. Although predictive in nature,
the approach should also address contingency planning when negative events do occur.
A2.7.4.2. Identify and document risk cause and effect chains, along with associated risk
assumptions, event dependencies, and risk event timeframes.
A2.7.4.3. Analyze risk cause and effect chains. Define risk likelihood and consequence
criteria and determine likelihood and consequence for each risk based on the established
criteria.
A2.7.4.4. Assess and prioritize risks based on likelihood, consequence(s), timeframe and
other factors relevant to the program at its current point in the life cycle. Consider
aggregating interrelated risks.
A2.7.4.5. Develop and implement an appropriate risk handling plan for each identified
risk.
A2.7.4.6. Track identified risks; monitor and periodically assess/report status of risk
handling activities.
A2.7.5. Artifacts:
A2.7.5.1. Risk Management Plan
A2.7.5.2. Risk reporting matrix with defined likelihood and consequence criteria
A2.7.5.3. Detailed risk analysis/review documentation
A2.7.5.4. Results of failure modes, effects, and criticality analysis (FMECA)
A2.7.6. For additional information on risk management see the following sources:
A2.7.6.1. DASD(SE), Department of Defense Risk, Issue, and Opportunity Management
Guide for Defense Acquisition Programs
A2.7.6.2. DAU - Acquisition Community Connection - Risk Management Tools site
A2.7.6.3. DoDM 4151.22-M, Reliability Centered Maintenance (RCM)
A2.7.6.4. MIL-STD-882E, System Safety
A2.7.6.5. Risk Management Plan (RMP) Template (see Attachment 1 reference for
URLs)
A2.7.6.6. DAFPAM 63-128, Integrated Life Cycle Management
A2.7.6.7. AFI 91-202, The US Air Force Mishap Prevention Program
A2.7.6.8. Air Force Institute of Technology (AFIT) School of Systems and Logistics
(AFIT/LS) Life Cycle Risk Management Group site.
A2.8. Configuration Management.
A2.8.1. Configuration management and planning provide a basis for documenting and
managing the decisions made in the SE processes. It also identifies the program/system
resources available and helps to produce a sustainment plan for cradle-to-grave supportability.
Over the life cycle, the configuration management process establishes and maintains the
44 AFMCI63-1201 2 DECEMBER 2022
integrity of the product’s technical baseline while accommodating change. A baseline is a set
of specifications, design data and associated lists, source code listings or other work/data
products, formally reviewed and agreed on, that thereafter serves as the basis for further
development and authoritative representation of the product.
A2.8.2. A system's technical baseline includes a functional baseline, an allocated baseline and
a product baseline. Each is a reference from which to measure progress of the system's
development, enable CM, and assure OSS&E. A progression of technical baselines is
developed during the development life cycle of a product, and each baseline is typically
approved at the appropriate systems engineering technical review.
A2.8.2.1. Functional Baseline (a.k.a. Requirements Baseline) - The documented, validated
and approved system-level (top level) or CI functional and performance requirements and
design constraints, their allocation or assignment to the next level, and all changes
approved IAW the contract. Typically, this baseline is initially approved at the System
Functional Review (SFR) or similar event, using the Capability Development Document
(CDD) and System Performance Specification as inputs to the SFR.
A2.8.2.2. Allocated Baseline - The System’s or CI’s documented, validated, and approved
"design-to" requirements and all changes approved IAW the contract. The allocated
baseline includes (a) the physical hierarchy, (b) the design-to requirements for each product
in the hierarchy, and (c) separable documentation identifying all design-to requirements
for each component and integrated grouping of components. Typically, this baseline is
initially approved at the Preliminary Design Review (PDR) or similar event, using the Item
Performance Specification(s) as an input to the PDR.
A2.8.2.3. Product Baseline - The "build-to" requirements as designed for each physical
element to be manufactured; the software code for each software element that has been
separately designed or tested; and the "buy-to" requirements for any other physical
element, part, or material to be procured from a subcontractor or vendor. Typically, this
baseline is initially approved at the Critical Design Review (CDR) or similar event, using
the Item Detail Specification(s) as an input to the CDR.
A2.8.3. The technical baseline provides a stable basis for continuing evolution of CIs, which
are defined as aggregations of work products that are designated for configuration management
and are treated as single entities within the configuration management process. Once a baseline
is established, configuration change becomes a formalized process, which provides stability
during design and over the life cycle.
A2.8.4. Recommended Minimum Actions:
A2.8.4.1. Document the configuration management process.
A2.8.4.2. Establish a Configuration Control Board (CCB).
A2.8.4.3. Identify the CIs and maintain CI lists.
A2.8.4.4. Establish and maintain the technical baseline.
A2.8.4.5. Document changes to the CIs and maintain change logs.
A2.8.4.6. Perform configuration audits (e.g., Functional Configuration Audit (FCA),
Physical Configuration Audit (PCA)) to maintain integrity of the configuration baselines.
AFMCI63-1201 2 DECEMBER 2022 45
A2.8.5. Artifacts:
A2.8.5.1. Configuration Management Plan (CMP).
A2.8.5.2. CCB Charter, decisions and supporting rationale. AFTO Form 872,
Configuration Control Board Directive, may be used to document CCB decisions and
supporting rationale.
A2.8.5.3. List of CIs
A2.8.5.4. Technical baseline description(s) (e.g., functional, allocated, product)
A2.8.5.5. Change requests
A2.8.5.6. Configuration audit results
A2.8.5.7. Action items to address discrepancies
A2.8.6. For additional information on CM see the following sources:
A2.8.6.1. MIL-HDBK-61B, Configuration Management Guidance
A2.8.6.2. Defense Logistics Agency (DLA) Military Engineering Data Asset Locator
System (MEDALS)
A2.8.6.3. AFI 21-101 AFMCSUP, Aircraft and Equipment Maintenance Management
A2.8.6.4. TO 00-5-15, Air Force Time Compliance Technical Order Process
A2.8.6.5. TO 00-20-2, Maintenance Data Documentation
A2.8.6.6. AF Portal, functional area Product Data Acquisition
A2.8.6.7. EIA-649C, Configuration Management Standard
A2.8.6.8. EIA-649-1A, Configuration Management Requirements for Defense Contracts
A2.8.6.9. GEIA-HB-649A, Configuration Management Standard Implementation Guide
A2.8.6.10. IEEE 828, Configuration Management in Systems and Software Engineering
A2.9. Design.
A2.9.1. The Design process involves conceiving and proofing an integrated solution that
satisfies product requirements. It focuses on product design, initial implementation, and
integration. As each level of the product is defined, there is an iterative process of allocation,
high level design and requirements definition for the next lower level.
A2.9.1.1. Some design considerations are required by laws, regulations or treaties, and
others are required by a particular product domain or Service component. These mandates
should be incorporated during the requirements analysis process to achieve balance across
all of the system requirements. The program should review system/item design
requirements to determine conformance with government policy and legal compliance, and
to identify potential integration and interoperability challenges.
A2.9.1.2. There are five types of defense standards ("MIL-STDs"), each of which can
influence system/item design: interface standards, design criteria standards, manufacturing
process standards, standard practices, and test method standards. Many of these standards
are available via the ASSIST Database. Standards are also referenced in DAFPAM 63-128.
46 AFMCI63-1201 2 DECEMBER 2022
A2.9.2. Product design consists of two broad phases that may overlap in execution:
preliminary and detailed design. Preliminary design establishes product capabilities and the
product architecture, including product partitions, product-component identifications, product
states and modes, major inter-component interfaces, and external product interfaces. Detailed
design fully defines the structure and capabilities of the product components. During detailed
design, the product architecture details are finalized and product components and interfaces
are completely defined (detailed in the context of containing all the information needed to
manufacture, code, or otherwise implement the design as a product or product component).
A2.9.3. Product integration is achieved through progressive assembly of product components,
in one stage or in incremental stages, according to a defined integration sequence and
procedures. A critical aspect of product integration is the management of interfaces to the
products and between product components to ensure compatibility among the interfaces.
Attention should be paid to interface management throughout the program.
A2.9.4. Recommended Minimum Actions:
A2.9.4.1. Evaluate design alternatives based on established selection criteria.
A2.9.4.2. Develop detailed designs for components, end items, systems, etc.
A2.9.4.3. Develop design documentation (e.g., DODAF views, interface design
documents).
A2.9.4.4. Develop initial designs for each component, end item, system, etc. based on
identified requirements, statutory/regulatory mandates, and constraints. Consider
purchasing COTS products versus developing new ones.
A2.9.4.5. Establish and maintain design artifacts that describe the conditions, functions,
operating modes and operating states specific to the components of the design architecture.
A2.9.4.6. Prepare Acquisition and Sustainment Data Package / Technical Data Package(s).
A2.9.5. Artifacts:
A2.9.5.1. Design criteria (e.g., KPPs, interfaces, statutory/regulatory requirements)
A2.9.5.2. Design interface control documents/data (e.g., DoDAF views, engineering
drawings/models, use cases, interface control documents, interface requirements
document, interface design documents, Bill of Materials).
A2.9.5.3. Documented baseline (e.g., functional, allocated)
A2.9.5.4. Trade studies/analyses
A2.9.5.5. Acquisition and Sustainment Data Package / Technical Data Package
A2.9.6. For additional information on design considerations see the following sources:
A2.9.6.1. DAG, Systems Engineering Processes, Design Considerations
A2.9.6.2. MIL-STD-31000B, Technical Data Packages
A2.9.6.3. MIL-STD-1472H, Human Engineering
A2.9.6.4. MIL-STD-46855A, Human Engineering Requirements for Military Systems,
Equipment, and Facilities
AFMCI63-1201 2 DECEMBER 2022 47
A2.10. Manufacturing.
A2.10.1. The manufacturing process is used to prepare for and produce the required product
and includes the following: (1) application of industrial base and manufacturing process
expertise/information to the requirements and design processes; (2) planning for and managing
the manufacturing process maturation efforts needed for successful transition from product
development to rate production; and (3) stabilizing a sustained rate of production while
assuring affordable quality products.
A2.10.2. Clear manufacturing readiness criteria should exist for each phase of the program
and be agreed to by stakeholders. Manufacturing readiness assessments should be conducted
to confirm manufacturing readiness at key points in the program. Manufacturing transition
plans are established to address the manufacturing readiness criteria and executed to ensure
maturation of manufacturing capability. The residuals of manufacturing (e.g., facilities,
processes, tooling, and test equipment) should be integrated into the support infrastructure
required for the remainder of the product life cycle.
A2.10.3. Recommended Minimum Actions:
A2.10.3.1. Establish and maintain strategy and plans for manufacturing.
A2.10.3.2. Include manufacturing and quality management requirements in contracts.
A2.10.3.3. Assess and report manufacturing readiness using the DoD Manufacturing
Readiness Levels.
A2.10.3.4. During TMRR, initiate manufacturing technology development efforts to
address manufacturing risks.
A2.10.3.5. During EMD, mature manufacturing capabilities in support of CDR and
Milestone C.
A2.10.3.6. During Production and Deployment, monitor and review production metrics to
ensure program cost, schedule, and quality goals are met.
A2.10.3.7. During Operations & Support, assess the capabilities of maintenance
organizations to perform O&S activities.
A2.10.4. Artifacts:
A2.10.4.1. Manufacturing Plan
A2.10.4.2. Quality Assurance Program Plan
A2.10.4.3. Manufacturing and Quality Statement of Work requirements
A2.10.4.4. Manufacturing Readiness Level Assessment report, including Manufacturing
Maturation Plans
A2.10.4.5. Manufacturing and Quality metrics
A2.10.4.6. Documented baseline (e.g., product)
A2.10.5. For additional information on manufacturing see the following sources:
A2.10.5.1. Defense Manufacturing Management Guide for Program Managers
A2.10.5.2. MIL-HDBK-896A, Manufacturing Management Program Guide
48 AFMCI63-1201 2 DECEMBER 2022
A2.10.5.3. AFI 63-145, Manufacturing and Quality Management
A2.10.5.4. TO 00-35D-54, USAF Deficiency Reporting, Investigation, and Resolution
A2.10.5.5. SAE AS9102B, Aerospace First Article Inspection Requirement
A2.10.5.6. SAE AS9103A, Quality Management Systems - Variation Management of Key
Characteristics
A2.10.5.7. OSD Manufacturing Technology Program, DoD Manufacturing Readiness
Level Deskbook
A2.10.5.8. SAE AS6500, Manufacturing Management Program
A2.10.5.9. SAE AS9100D, Quality Management Systems - Requirements for Aviation,
Space, and Defense Organizations
A2.11. Verification and Validation.
A2.11.1. The verification process ensures that work products meet their specified
requirements, whereas the validation process demonstrates that a product fulfills its intended
use when placed in its intended environment.
A2.11.2. The PM and LSE/CE manage verification activities and methods as defined in the
functional and allocated baselines and review the results of verification. Verification activities
and results are documented among the artifacts for the FCA and the System Verification
Review (SVR). The output of the Verification process is a verified, production-representative
article with documentation to support Initial Operational Test and Evaluation (IOT&E). The
SVR provides a determination of the extent to which the system meets the system performance
specification.
A2.11.3. The PM and LSE/CE should ensure that a proper verification environment exists,
that it selects work products to evaluate based on documented criteria, and that the supplier
uses appropriate methods to verify its work products. In this context, the T&E community is a
major stakeholder and should participate in up-front planning through final product
acceptance.
A2.11.4. Validation consists of evaluating the operational safety, suitability, effectiveness,
sustainability, and survivability of the system or system elements under operationally realistic
conditions. The PM and LSE/CE are responsible for supporting the validation process. The
execution of the validation process is typically conducted by independent testers IAW the
program TEMP. System end users and other stakeholders are typically involved in validation
activities. Product validation activities can be applied to all aspects of the product in any of its
intended environments, such as operations, training, manufacturing, maintenance, and support
services.
A2.11.5. Recommended Minimum Actions:
A2.11.5.1. Form an Integrated Test Team (ITT).
A2.11.5.2. Document an integrated approach for verification and validation (include
methodology, procedures, criteria, required environments, required resources, etc.).
A2.11.5.3. Conduct verification and validation according to the plan.
AFMCI63-1201 2 DECEMBER 2022 49
A2.11.5.4. Ensure any necessary certifications and accreditations are completed.
A2.11.5.5. Document and analyze the results of the verification and validation activities
and perform any necessary corrective actions.
A2.11.6. Artifacts:
A2.11.6.1. ITT Charter
A2.11.6.2. Test plan (e.g., TEMP, Software Test Plan)
A2.11.6.3. Test reports
A2.11.6.4. Certification and accreditation approvals
A2.11.6.5. Deficiency reports
A2.11.6.6. Corrective action plan
A2.11.7. For additional information on verification and validation see the following sources:
A2.11.7.1. DoD Modeling & Simulation Coordination Office (M&SCO), Verification,
Validation & Accreditation Recommended Practices Guide (RPG)
A2.11.7.2. Director, Operational Test & Evaluation (DOT&E) TEMP Guidebook
A2.11.7.3. MIL-STD-3022, Documentation of Verification, Validation, and Accreditation
(VV&A) for Models and Simulations
A2.11.7.4. DoDI5000.89 DAFI99-103 AFMCSUP, Capabilities-Based Test and
Evaluation
A2.11.7.5. DAFMAN 63-119, Mission-Oriented Test Readiness Certification
A2.11.7.6. ISO/IEEE 26702, Systems Engineering - Application and Management of the
Systems Engineering Process
A2.12. Transition, Fielding, and Sustainment.
A2.12.1. The transition, fielding, and sustainment process is used to prepare for and execute
the support, maintenance, repair, and disposal of a product while ensuring it is operationally
safe, suitable, and effective. Transition is the process applied to move any system/element to
the next level in the physical architecture. For the overall system, it is the process to install and
field the system to the user in the operational environment. The item/system may need to be
integrated with other items/systems in the operational environment IAW defined external
interfaces, which would require TFS to be performed in conjunction with integration and
interface management processes for a smooth transition.
A2.12.2. Early planning for system TFS reduces risk and supports rapid delivery and
acceptance by the system’s end user. TFS considerations should include, as appropriate, user
and maintainer requirements, training, deployability, support tasks, support equipment, and
packaging, handling, storage, and transportation (PHS&T). Part of the TFS process is ensuring
that each site is properly prepared for the receipt, acceptance, and/or installation of the system.
A2.12.3. The overarching support concept should be considered from the start of any
development or modification effort. Support concepts like CBM+ typically drive requirements
50 AFMCI63-1201 2 DECEMBER 2022
and design decisions. Early logistics/sustainment representation in development of TFS
concepts and related requirements is necessary to reduce total ownership costs.
A2.12.4. Recommended Minimum Actions:
A2.12.4.1. Identify/establish TFS activities to support operations, maintenance, repair,
and disposal of the product.
A2.12.4.2. Establish list of qualified suppliers.
A2.12.4.3. Establish and maintain strategy and plan(s) for transitioning acquired products
into operational use and support.
A2.12.4.4. Establish and maintain inventory and supplier management/control.
A2.12.4.5. Maintain OSS&E end states, and baseline.
A2.12.5. Artifacts:
A2.12.5.1. LCSP (or equivalent)
A2.12.5.2. Materiel Fielding Plan (may be part of the LCSP or AS)
A2.12.5.3. TOs and training manuals
A2.12.5.4. IUID Implementation Plan
A2.12.5.5. Acquisition and Sustainment Data Packages / Technical Data Packages
A2.12.5.6. Intellectual Property Strategy
A2.12.6. For additional information on TFS see the following sources:
A2.12.6.1. DoDM 4160.21 Volumes 1-4, Defense Materiel Disposition
A2.12.6.2. DoDI 4151.22, Condition Based Maintenance Plus (CBM+) for Materiel
Maintenance
A2.12.6.3. AFI 16-402, Aerospace Vehicle Programming, Assignment, Distribution,
Accounting, and Termination
A2.12.6.4. AFI 20-106 IP, Management of Aviation Critical Safety Items
A2.12.6.5. AFI 21-101 AFMCSUP, Aircraft and Equipment Maintenance Management
A2.12.6.6. AFLCMC/LG, Logistics Health Assessment (LHA) User Guide
A2.12.6.7. Air Force Product Support Tool Kit (PSTK)
A2.12.6.8. Defense Standardization Program Office (DSPO) SD-22, A Guidebook of Best
Practices and Tools for Implementing a Proactive DMSMS Management Program.
A2.13. System Security Engineering.
A2.13.1. System Security Engineering (SSE) is a subset of system engineering. It is the
systematic application of engineering principles to design systems that are difficult to
manipulate maliciously and readily recover from the manipulation attempts. Many defined
specialties must be managed to arrive at robust protection and recovery to include anti-tamper,
cybersecurity, STINFO protection, and trusted systems and networks (TSN). The ultimate goal
is to afford decision makers on the residual risk. To determine the residual risk the program
AFMCI63-1201 2 DECEMBER 2022 51
must assess the overall risk, correct identified deficiencies, and do so within established funds
and schedule. No one specialty is sufficient to provide adequate protection and failure to
address all results in systems that are inadequately protected with susceptibility to easy
malicious manipulation. The documentation for the processes enhances understanding current
decisions and facilitates future upgrades.
A2.13.2. SSE is taken concurrently with overall system engineering process. Most often SSE
activities are indistinguishable from system engineering activities, as they are systems
engineering best practices.
A2.13.3. Recommended Minimum Actions:
A2.13.3.1. The breadth, depth, and overall authority for protecting infrastructure and
weapons systems is categorized by protection development phase contained in System
Security Engineering Cyber Guidebook. Application specific for Command TSN is
contained in the AFMC Trusted Systems and Networks Implementation Plan is in the
AFMC Systems Engineering Toolbox at
https://usaf.dps.mil/:b:/t/AFMCTSNRoundTable/EfyWkb2xeQZAi90NEmBVhj8B
Bb2h0shGM6vwW_gB6SVEXQ?e=U0aESl.
A2.13.3.2. Contact the respective center TSN Focal Point for guidance.
A2.13.3.3. Obtain hardware and software bill of materials for system.
A2.13.3.4. Request available intel and contractor illumination.
A2.13.3.5. Expand cybersecurity criticality analysis to encompass critical
microelectronics.
A2.13.4. Artifacts:
A2.13.4.1. Systems Engineering Plan section identifying critical components, their
protection scheme (including security and privacy controls from NIST SP 800-53) and test
techniques to assess protection scheme(s) effectiveness.
A2.13.4.2. Program Protection Plan section detailing critical functions, critical
components, and the assessment of system impact if compromise.
A2.13.4.3. TSN Risk Assessment results
A2.13.4.4. Life-cycle Sustainment Plan sections containing notice of critical components,
their protection, and sustainment. Properly document critical components in sustainment
form.
A2.13.5. For additional information, see the following sources:
A2.13.5.1. DoDI 5200.44, Protection of Mission Critical Functions to Achieve Trusted
Systems and Networks (TSN)
A2.13.5.2. DoDM 4140.01, Volume 11, DoD Supply Chain Materiel Management
Procedures: Inventory Accountability and Special Management and Handling
A2.13.5.3. DoDI 5000.83 DAFI 63-113, Technology and Program Protection to Maintain
Technological Advantage
A2.13.5.4. AFI 17-130, Cybersecurity Program Management
52 AFMCI63-1201 2 DECEMBER 2022
Attachment 3
OPERATIONAL SAFETY, SUITABILITY, AND EFFECTIVENESS
A3.1. OSS&E-related goals or end states (not including airworthiness) are accomplished by
achieving and preserving technical integrity through use of disciplined SE practices, proper O&M,
effective supply systems, and distribution of state/trend information to system stakeholders.
Overall, an effective program OSS&E approach is one in which competent people make
reasonable and defensible program, engineering, and technical decisions throughout the life cycle
to maintain the required safety, suitability, and effectiveness characteristics of systems and items.
A3.1.1. The PM, with LSE/CE, is ultimately responsible for the implementation and execution
of OSS&E-related procedures for the system and/or end items. However, since the operational
sponsor bears responsibility for some OSS&E-related procedures within their MAJCOM, the
PM and LSE/CE should work to ensure that the user MAJCOM(s) and their operating units
understand their roles in assuring OSS&E.
A3.1.2. To ensure all external organizations are aware of their roles in continued OSS&E
assurance, a flow-down of requirements to other organizations through contracts, MOAs,
SLAs, or other means should be employed where they add value.
A3.1.3. Any changes that impact the OSS&E baseline or form, fit, function, and interface
(F3I) need to be communicated/coordinated with each customer. The goal is for the PM,
LSE/CE and operational/functional users to be kept informed of changes (and the impacts of
those changes) to equipment installed on the platform that they manage or operate.
A3.1.4. The PM receiving equipment with OSS&E assurance managed elsewhere is still
responsible for the integrated system OSS&E assurance.
A3.1.5. For additional information see MIL-HDBK-260, Reference Data for Logistics
Metrics, and AFOTEC Operational Test and Evaluation Guide, 11th Edition, 24 Aug 2020.
Also, see Figure A3.1 and Table A3.1.
A3.1.5.1. Safety Metrics Considerations. Safety DRs, TCTOs, CSIs and FMECA should
be addressed by risk assessment-- reference MIL-STD-882, System Safety. Also, reference
AFI 91-204, Safety Investigations and Reports, for mishap reporting.
A3.1.5.2. Suitability Metrics Considerations. Reference TO 00-20-2, Maintenance Data
Documentation. Also, review metrics/data provided by the Air Force Logistics,
Installations and Mission Support - Enterprise View (LIMS-EV) capability. More
information on LIMS-EV is available via the Air Force Portal.
A3.1.5.3. Effectiveness Metrics Considerations. Reference TO 00-20-2. Also, reference
user effectiveness KPPs and KSAs from the JCIDS requirements documents; effectiveness
specifications from program SRD; and T&E Measures of Performance (MoPs) and
Measures of Effectiveness (MoEs).
AFMCI63-1201 2 DECEMBER 2022 53
Figure A3.1. OSS&E Metrics Taxonomy (Development Example).
Table A3.1. OSS&E Metrics Examples (Notional, Tailorable).
Safety (SE)
Suitability (SU)
Effectiveness (EF)
SE1 – Class A Mishap Rate
Std = 1/100,000 flying
hours
SU1 – Mission Availability
Std = 75% (includes all
primary mission systems)
EF1 – Mean Detect Range
Std = R
0
(1m
2
Radar Cross
Section, Combat Air Patrol orbit
altitude)
SE2 – Total Mishap Rate
Std = 1/10,000 flying hours
(combined Class A/B/C)
SU2 – Mean Time Between
Critical Failure (MTBCF)
Std = 120 hours (includes all
primary mission systems)
EF2 – Electronic
Countermeasures
Std = Fully effective against
STAR-E18 Table 3 threats
54 AFMCI63-1201 2 DECEMBER 2022
Safety (SE)
Suitability (SU)
Effectiveness (EF)
SE3 – Deficiency
Resolution
Std = CAT-1 DRs, DULL
SWORD, Unsatisfactory
Reports (URs – nuclear)
resolved within 90 days
SU3 – Average Mean Time
to Repair
Std = 5 hours
EF3 – Interoperability
Std = Meets all TO-051-C Table
7 Information Exchange
Requirements (IERs)
SE4 – Dropped Objects
Std = 1/50,000 flying hours
SU4 – Total Not Mission
Capable for Maint.
(TNMCM)
Std =
EF4 – Mission Crew
Effectiveness
Std = Rating of 7 or higher for
all mission crews
SE5 – Unit
ORIs/NSIs/UCIs
Std = All certified O&M
units receive "Sat" or
higher rating for safety
SU5 – Total Not Mission
Capable for Supply
(TNMCS)
Std =
EF5 – Gun Circular Error
Probability (CEP)
Std = xx feet and yy% at range
zzz
SE6 – Nuclear Surety Cert.
Std =
SU6 - Mission Capable Rate
Std = 0.70 (operation fleet)
A3.2. OSS&E Baseline - Components. The items composing the program's OSS&E baseline
are tailorable to the program and its life cycle phase; but in general, an OSS&E baseline includes:
A3.2.1. A complete set of traceable requirements (including user requirements, derived
program requirements, and certification/statutory/regulatory requirements).
A3.2.2. Descriptive configuration information, characteristics, and limitations of hardware
and software product(s) satisfying the requirements.
A3.2.3. Information on the support and procedures needed to ensure that the product(s)
continue(s) to meet requirements throughout the life cycle.
A3.2.4. A system model that captures functions, behavior, components, interfaces, and data
flow (internally and externally, as applicable).
A3.3. In order to assure OSS&E, the PM and the LSE/CE ensure documentation of authority for
activities that impact design considerations or involve providing technical direction for the use and
sustainment of the weapon system/end item.
A3.3.1. For the system or end item, the program's designated overall Engineering Authority
fulfills the role of the Design Control Activity defined in Title 10 U.S.C. Section 3243, and
may fulfill the ESA role IAW AFI 20-106 IP, Management of Aviation Critical Safety Items.
A3.3.2. The LSE/CE is the program's overall Engineering/Technical Authority. However,
supporting organizations may appoint Engineering/Technical Authorities IAW their applicable
AFMCI63-1201 2 DECEMBER 2022 55
policies and guidance. Regardless of the assigning OPR, each Authority manages, documents,
and tracks any further delegation of their authority and provides copy to the PM and LSE/CE-
- see Chapter 3 and DAFPAM 63-128 for required/recommended processes. Individuals who
are designated/delegated as an Engineering/Technical Authority are responsible for reviewing
and endorsing the informational artifacts and metrics applicable to their assigned activities.
A3.3.3. The PM and LSE/CE collaborate with the appropriate center EN to determine the
qualifications necessary for an individual to be an Engineering/Technical Authority for the
designated program activity. Also, the PM and LSE/CE establish clear reporting guidelines for
communicating program-related engineering concerns from individuals designated as an
Engineering or Technical Authority.
A3.3.4. The delegation of engineering authority to Air Force Sustainment Center (AFSC)
supply chain groups can use delegation templates endorsed by the applicable center ENs.
A3.3.5. Document processes to provide engineering disposition to resolve nonstandard
conditions. Reference TO 00-25-107, Maintenance Assistance; TO 00-5-3, Air Force
Technical Order Life Cycle Management; and AFMCMAN 63-1202, Air Force Materiel
Command Engineering Technical Assistance (ETAR) Process. Also, document processes to
resolve maintenance TO deficiencies or errors-- reference TO 00-5-1, AF Technical Order
System.
56 AFMCI63-1201 2 DECEMBER 2022
Attachment 4
SYSTEMS ENGINEERING PLAN REQUIREMENTS
A4.1. SEP production requirements and waivers/exemptions for AFMC programs are established
in DoDI 5000.02, DoDI 5000.88, AFI 63-101/20-101 and AFI 61-101. This AFMCI does not
expand applicability of SEP production requirements beyond what is published in higher guidance.
However, an AFMC program which is required to produce a SEP should contain the following
information, tailored to the program life cycle phase. The SEP can reference other program
documents with the content described below rather than duplicate the same information.
A4.1.1. A description of how OSS&E-related life cycle processes shall be implemented,
executed and verified by both the implementing and operational commands.
A4.1.2. A definition of when the OSS&E baseline shall be brought under government
configuration control.
A4.1.3. A description of OSS&E-related data management systems and planned compatibility
with Air Force acquisition, logistics, operations, and sustainment architectures.
A4.1.4. Engineering/technical resources required to execute the product support strategy.
A4.1.5. Engineering/technical risks that have been accepted at levels above the PM.
A4.2. If the PM has chosen to develop a HSI plan as a separate document, that document should
be referenced in the SEP. See Attachment 5 for more details.
A4.3. The program LSE/CE ensures the SEP conforms to the common documented SE processes
(with approved tailoring and/or waivers) prior to review/approval by the PM.
A4.4. Product Group systems/items in the O&S phase should develop a Group/Directorate-level
SEP that identifies maintenance and sustainment processes for equipment replacement and
replenishment.
AFMCI63-1201 2 DECEMBER 2022 57
Attachment 5
HUMAN SYSTEMS INTEGRATION ACTIVITIES BY PROGRAM PHASE
A5.1. The human is a critical component in any system. HSI planning and implementation
addresses the systematic integration of interrelated domains-- human factors engineering;
personnel; habitability; manpower; training; safety and occupational health; and force protection
and survivability-- in order to accomplish the DoD 5000 series goals to optimize total system
performance and ownership costs. HSI includes interdisciplinary technical and management
processes for integrating human considerations within and across all system elements. HSI is a
tailored, “total system” approach that includes humans, technology, the operational context, and
the necessary interfaces between and among the system elements to make them all work in
harmony.
A5.1.1. HSI is a key component of SE and LCSE processes requiring HSI planning to address
human centered design issues across trade space and related domains. HSI planning content
can be included in the SEP or the PM’s plan for HSI can also be a separate document. The PM
can require a HSI plan from the contractor (Human Systems Integration Program Plan or
HSIPP) through a Data Item Description (DID) DI-HFAC-81743A or can develop an "organic"
government plan (Human Systems Integration Plan or HSIP), which can be especially useful
for complex systems and programs. If the HSI plan is a separate document, that document
should be referenced in the SEP. At a minimum, HSI plans should be updated prior to each
program milestone (or equivalent decision point).
A5.1.2. Early and frequent consideration of HSI is integral to effective implementation. For
program acquisitions consisting of Government Off-the-Shelf (GOTS), COTS and/or non-
developmental items, the equipment and its integration with the overall system are still
assessed and addressed for implications on the human and human performance. HSI is assessed
and addressed in design trade studies and risk mitigations. The HSI assessment is tailored to
program needs and should be accomplished prior to milestones and program reviews. HSI
assessments capture HSI issues that may require mitigation/resolution before potentially
causing a major system redesign.
A5.1.3. IAW DoDI 5000.02, PMs ensure that AF HSI staff are aware of and engaged with
WIPTs tasked with the development and review of program planning documents that reflect
HSI planning and inform program decisions. HSI shall be considered at each milestone during
the program life cycle, and should be coordinated with other enabling functionals such as,
intelligence, logistics, and the user communities during each acquisition phase. HSI-related
assessments/activities by program life cycle phases are described below-- these can be tailored
to reflect the unique needs of the program and the type of item/system being developed.
A5.2. Materiel Solution Analysis Phase Activities (Pre-Milestone A).
A5.2.1. Perform HSI task analyses and assessments to identify major HSI-related concerns
and capability gaps. Target audience is identified and includes all those who operate, maintain,
support or are transported by the system.
A5.2.2. Work with the operational sponsor to document HSI considerations in the AoA Report
and in the Technology Development Strategy.
58 AFMCI63-1201 2 DECEMBER 2022
A5.2.3. Ensure that appropriate HSI trade-offs are completed to contribute to the optimization
of the overall cost, schedule, performance, and overall affordability of the viable materiel
solutions.
A5.2.4. Include HSI planning in the development of system specifications and associated
objectives/thresholds through human-related Measures of Effectiveness (MoE), Measures of
Suitability (MoS) and Measures of Performance (MoP), as applicable.
A5.2.5. Address HSI implications evolving from the ICD and analyses/assessments in the
draft CDD/CPD.
A5.2.6. Ensure KPPs, KSAs or other attributes which address HSI domains are
considered/included during requirements development.
A5.2.7. Develop HSI-related risk handling planning.
A5.2.8. Develop and integrate HSI planning with technical and program planning.
A5.2.9. Estimate costs for HSI support through the system life cycle and include in cost
estimates.
A5.2.10. As applicable, assess and document HSI considerations as requirements in the draft
SRD / system performance specification.
A5.2.11. As applicable, perform or place on contract HSI-related demonstrations, analyses
and risk reduction studies using mock-ups or modeling and simulation (M&S) to analyze
critical performance elements.
A5.2.12. Capture and utilize HSI lessons learned at Milestone A for the next phase activity.
A5.3. Technology Maturation & Risk Reduction Phase Activities (Pre-Milestone B).
A5.3.1. Review the SEP and provide input to the TEMP, focusing on usability, sustainability
and other applicable HSI considerations.
A5.3.2. Plan for and implement HSI, integrated with technical and program planning:
A5.3.2.1. Develop or update HSI plans/planning as applicable, including managerial and
technical approaches.
A5.3.2.2. Summarize HSI planning or reference the HSI plan in the SEP.
A5.3.2.3. Determine/establish HSI personnel participation in IPTs and/or WGs.
A5.3.2.4. Ensure HSI considerations include design, integration, modification, test,
verification, certification, logistics planning, operational support, and disposal.
A5.3.2.5. Ensure HSI planning, evaluations and studies are placed on contract IAW
program plans and requirements. As needed, select the appropriate Data Item Descriptions
(DID) for inclusion in the Contract Data Requirements List (CDRL), and place concise
wording in the Statement of Work (SOW), Statement of Objectives (SOO) or Performance
Work Statement (PWS). Review HSI-related contractor deliverables.
A5.3.2.6. Ensure logistics planning includes maintainability and other HSI considerations.
A5.3.2.7. Establish HSI-related metrics as needed, including Technical Performance
Measures, Systems Engineering artifacts, and elements of the technical baseline.
AFMCI63-1201 2 DECEMBER 2022 59
A5.3.2.8. Ensure HSI personnel participate in technical and design reviews.
A5.3.2.9. Conduct HSI trade studies, as needed.
A5.3.2.10. Ensure HSI issues/concerns identified during test are addressed.
A5.3.2.11. IAW system and program requirements, document HSI-specific entrance and
exit criteria for design and programmatic reviews.
A5.3.2.12. Establish and implement a process for identification, tracking, and mitigation
of human-related concerns and risks integrated with the overall program risk management
process.
A5.3.3. Plan for sustainment of and training for the system. Ensure documentation within the
LCSP and technical planning.
A5.3.4. Review Manpower Estimate Report as required.
A5.3.5. IAW the JCIDS Manual, work with the operational sponsor to ensure adequacy of
HSI-related capability requirements in the CDD prior to CDD validation.
A5.3.6. As applicable, assess, translate, refine, and document HSI considerations as
requirements in the SRD / system performance specification IAW overall program plans and
requirements.
A5.3.7. Generate risk assessment criteria for human-related concerns.
A5.3.8. Include HSI considerations in ATDs and prototyping efforts.
A5.3.9. Ensure HSI tradeoffs are considered, demonstrated, and refined in ATD and prototype
development.
A5.3.10. Capture and utilize HSI lessons learned at Milestone B for the next phase activity.
A5.4. Engineering & Manufacturing Development Phase Activities (Pre-Milestone C).
A5.4.1. Plan for sustainment of and training for the system. Ensure documentation within the
LCSP and technical planning.
A5.4.2. Ensure needed HSI planning, evaluations and studies are on contract IAW program
plans and requirements. Select the appropriate DIDs for inclusion in the CDRL, and place
concise wording in the SOW, SOO, or PWS.
A5.4.3. Review contractor deliverables for adequacy of HSI implementation and performance
of HSI-related evaluations and studies.
A5.4.4. Enable HSI participation in WGs/IPTs, with special emphasis on design reviews.
A5.4.5. Ensure HSI considerations are reflected in the product baseline for the system and its
constituent system elements.
A5.4.6. Coordinate with Developmental Test and Evaluation (DT&E) community on human
performance considerations derived from weapon system capability-based requirements and
program documentation.
A5.4.7. Review test, operational assessment and evaluation reports, and results of HSI-related
system elements. Ensure deficiencies are captured in the program risk management process.
60 AFMCI63-1201 2 DECEMBER 2022
A5.4.8. Finalize design decisions and document human-in-the-loop tradeoffs.
A5.4.9. Capture and utilize HSI lessons learned at Milestone C for the next phase activity.
A5.5. Production & Deployment Phase Activities (Post-Milestone C).
A5.5.1. Update SEP and TEMP based on human effectiveness in system utilization during
initial system tests.
A5.5.2. Analyze and work to resolve any operational deficiencies in the system’s ability to
meet HSI-related requirements.
A5.5.3. Review finalization and implementation of training program.
A5.5.4. Assess new contracts for HSI-related considerations, risks, and inputs.
A5.5.5. Capture and utilize HSI lessons learned from IOT&E for the next phase activity.
A5.6. Operations & Sustainment Phase Activities.
A5.6.1. Include consideration of human concerns (e.g., human tasks, usability, anthropometric
accommodations, maintainability) in system upgrades and modifications.
A5.6.2. Participate in system safety and incident reviews to help identify human-related root
causes.
A5.6.3. Capture and provide lessons learned for future CBA and AoA efforts.
A5.6.4. Provide input on Deficiency Reports with human implications, as required.
A5.7. HSI Relationships.
A5.7.1. The PM implements HSI early in the acquisition process and throughout the product
life cycle. On behalf of the PM, the LSE/CE should implement either a HSI IPT or include an
HSI lead in the Systems Engineering IPT. Additional HSI resources to support program office
activities are available from the broader HSI community (AFMC/EN and AFLCMC/EN).
A5.7.1.1. HSI organizations and processes facilitate trade-offs among human-centric
domains without replacing or duplicating individual domain activities, responsibilities and
reporting channels.
A5.7.1.2. HSI organizations and processes inform the PM and LSE/CE to support program
decision-making.
A5.7.2. The program LSE/CE helps the PM to ensure HSI issues are properly addressed. The
LSE/CE is responsible for HSI technical content presented in the SEP, milestone decision
inputs, and technical reviews. In addition, the LSE/CE should provide HSI support through the
HSI POC for the program IPTs. In collaboration with the PM, the LSE/CE should
communicate HSI opportunities and risks to the center DoE, center level technical authority
and PEO DoE in support of the PEO program portfolio and program milestone decisions.
A5.7.3. AFMC/ENS and AFLCMC ensure that HSI is effectively accomplished across
acquisition program offices via the AFLCMC Human Systems Integration Enterprise chaired
by the Crew Systems Engineering and HSI Enterprise Branch (AFLCMC/EZFC). The
AFLCMC HSI Enterprise creates a network of HSI practitioners from each of the AFLCMC
execution directorates and connects them with domain expertise from a variety of functional
communities.
AFMCI63-1201 2 DECEMBER 2022 61
A5.8. HSI Guidance and Resources. For more information, refer to:
A5.8.1. AF HSI Requirements Pocket Guide
A5.8.2. AFOTEC Operational Test and Evaluation Guide, 11th Edition, 24 Aug 2020
A5.8.3. DAFPAM 63-128
A5.8.4. Defense Acquisition Guidebook
A5.8.5. HSI and ESOH Handbook for Pre-Milestone A JCIDS and AoA Activities
A5.8.6. MIL-STD-1472H
A5.8.7. MIL-STD-46855A
62 AFMCI63-1201 2 DECEMBER 2022
Attachment 6
DELEGATED ENGINEERING AUTHORITY FOR AFMC FORM 202 PROCESSES
A6.1. This attachment provides LSE/CEs with recommended guidance on the delegation of
engineering/technical authority to depot maintenance engineers that develop engineering
disposition for technical problems beyond published authority. Specifically, it provides guidance
on how maintenance engineers may participate in the approval of the AFMC Form 202,
Nonconforming Technical Assistance Request and Reply. This guidance does not direct the
LSE/CE to delegate authority; instead, it provides a recommended process to facilitate delegated
engineering authority efforts. While this guidance focuses on the AFMC 202 process,
organizations may be able to utilize elements of this process to tailor their AFMC 107 and/or DLA
339 processes IAW TO 00-25-107 and DLA Form 339 guidance. Note: This attachment cancels,
incorporates, and updates information from the AFMC 202 Delegated Engineering Authority
Process Guide v1.0, 18 September 2012.
A6.1.1. If the LSE/CE and/or PM determine that delegated engineering authority is warranted,
they ensure that the designee(s) is/are qualified and technically competent to provide sound
engineering disposition for problem resolution.
A6.2. General Principles.
A6.2.1. Air Force policy vests the overall programmatic responsibility for a weapon system
with the PM. The LSE/CE is the overall engineering/technical authority for the program, and
usually has delegated programmatic responsibilities/authorities from the PM, which are related
to executing engineering and technical tasks for the program. Through this arrangement, the
LSE/CE typically acts on behalf of the PM to maintain control of the OSS&E baseline and
airworthiness. Policy and disciplined SE require the PM and LSE/CE to clearly document and
describe any delegated program management, engineering or technical authority, and to ensure
delegated authority for activities are limited to competent organic and contractor activities. It
is therefore necessary for the LSE/CE to have insight into the competencies of engineers with
delegated engineering/technical authority.
A6.2.2. While the OSS&E and airworthiness characteristics of the system are the paramount
consideration, both AFLCMC and AFSC has a shared responsibility to the warfighter to meet
their aircraft availability requirements. Among many factors, the engineering support provided
to maintenance and repair actions has a direct effect on an AFMC center's ability to meet
warfighter availability requirements. This attachment provides AFMC centers with a
consistent mechanism to partner with the program office in the execution of engineering
support to maintenance organizations, establishing a process that balances OSS&E and
airworthiness principles with aircraft availability needs and providing clear lines of authority.
A6.3. Recommended Non-Delegable and Delegable Tasks.
A6.3.1. Non-Delegable. Due to the potential OSS&E/airworthiness implications and the
necessity for independence, 202s meeting the following criteria should generally not be
delegated to a maintenance engineer as the engineering approval authority in block 26E. While
LSE/CEs have the flexibility to delegate authority as they deem necessary, items on the list
below are generally outside of AFMC norms for delegation. The items on the list below should
AFMCI63-1201 2 DECEMBER 2022 63
not be delegated unless the LSE/CE (in collaboration with the PM) determines it is necessary
and presents acceptable risk. Recommended non-delegable tasks include:
A6.3.1.1. CSIs, safety of flight, parts/repairs with catastrophic failure consequences, major
structural repairs, nuclear certified items, deferred repairs, interface changes, deviation to
work specifications, new manufacturing processes, low observable critical item or
processes, disposition of product quality deficiency report, material substitution, new
repairs and/or repair processes, changes with the potential to degrade reliability or
performance, changing of test limits/requirements, changing of calibration requirements
on weapons system support equipment, hardness critical items/processes, corrosion
prevention and control requirements, changes that affect program office contract or
warranty, and dispositions that require contracted expertise.
A6.3.2. Delegable. When the business case supports delegation, typical delegable tasks
include those that have the following characteristics: negligible consequences in accordance
with MIL-STD-882; known approved repair using standard process; qualified proven process;
does not have appreciable cost increase to life cycle; repair expected to last through depot
cycle. Note: "Negligible" is defined as “could result in injury or illness not resulting in a lost
workday, loss exceeding $2K but less than $10K, or minimal environmental damage not
violating law or regulation.” Tasks that typically have these characteristics include but are not
limited to:
A6.3.2.1. Form 202 rejection, condemnations, reclamations, oversize holes/fasteners,
rework assessment, secondary structure repairs, clarification of TO, troubleshooting,
catalog analysis, reissue 202 within limitations of AFMCMAN 63-1202, remove and
replace a qualified part, temporary support equipment substitutes, repairing beyond TO
limits due to limited supply, repeat authority, sequencing of subsystem / component
removal / installation, and parts substitution where: previously approved or not yet in TO
and consumables (common, recurring, bench stock).
A6.4. Form 202 Engineering Delegation Responsibilities.
A6.4.1. General Responsibilities. While LSE/CEs are generally permitted to delegate
engineering/technical authorities to qualified and competent organic organizations and
contractors, there is no mandated standard process to delegate these authorities. AFPAM 63-
128 provides general recommended procedures. The following paragraphs outline the specific
responsibilities associated with delegating engineering authority from a program office
LSE/CE to a maintenance engineer in an organic maintenance organization.
A6.4.2. There are two key engineering roles in the development and approval of the 202.
While these roles are generally applicable to program office engineers, the scope of this
paragraph is in the context of delegation to engineers in the maintenance organization. Policy
and sound engineering practices require that the engineer developing the disposition
instructions in Part B of the 202 cannot be the same engineer who approves the repair.
A6.4.2.1. The engineer developing the disposition instructions is referred to as the
disposition engineer and has “1st Signature” approval (Block 26A).
A6.4.2.2. The engineer who approves the recommended disposition on the 202 is referred
to as the engineering approval authority and has "2nd Signature" approval (Block 26E).
64 AFMCI63-1201 2 DECEMBER 2022
A6.4.3. LSE/CE Responsibilities. In accordance with his/her documented authorities, the
LSE/CE has the final engineering/technical responsibility for the program and weapon system.
LSE/CEs ensure that delegated engineering/technical authorities have been delegated in
writing, that the scope/limits of the delegations are clearly identified, and that delegations are
limited to qualified individuals who are technically competent to perform tasks within the
scope of their delegation. Specific LSE/CE responsibilities include:
A6.4.3.1. Delegate in writing any LSE/CE authorities delegated to the disposition engineer
or the engineering approval authority.
A6.4.3.1.1. Because the delegation letter designates (by name) an engineer who may
assume authority for delegated aircraft, processes and component configuration control
deviations, as well as airworthiness, it is imperative that the delegation letter clearly
identify what that engineer can and cannot approve.
A6.4.3.2. Monitor 202 dispositions for OSS&E and airworthiness assurance purposes.
A6.4.3.3. Ensure appropriate mentoring of new disposition engineers and engineering
approval authorities to ensure their delegated authorities are being fulfilled appropriately.
A6.4.3.4. Conduct annual audit of 202s in which a maintenance engineer has been
approved as the engineering approval authority. Quarterly or semiannual audits are
recommended upon initial delegation (i.e., in the first year of delegation).
A6.4.3.5. Provide technical support and direction whenever dispositions are outside the
expertise of the disposition engineer or engineering approval authority.
A6.4.4. Disposition Engineer Responsibilities. Disposition engineers are typically delegated
specific authorities from the LSE/CE. The disposition engineer's primary role is to develop the
disposition instructions in Blocks 21 and 22 of the 202. The disposition engineer's signature
means he/she is attesting that the recommended disposition is accurate and based on sound
engineering; and that if the recommendation is approved and implemented as proposed there
will be no detriment to the OSS&E or airworthiness characteristics of the system. This does
not preclude someone other than the disposition engineer from developing/providing
recommendations to the disposition engineer. Specific disposition engineer duties include:
A6.4.4.1. Ensure authorities are executed within the scope of the delegated engineering
authority letter from the LSE/CE.
A6.4.4.2. Provide written disposition via the Form 202 or utilize an approved automated
Form 202.
A6.4.4.3. Review 202 Part A, information/attachments and ensure they are complete,
accurate, and include pertinent technical data references, pictures, etc. for incorporation
into applicable Air Force data repository.
A6.4.4.4. When necessary, review the problem with maintenance personnel who
originated the 202 request to clarify any issues or obtain needed information.
A6.4.4.5. Ensure all coordination required in paragraph A6.4.4.11 below is received and
annotated on the 202.
A6.4.4.6. Complete the 202, Part B, Block 17-26A IAW AFMCMAN 63-1202 as required
to meet the 202 delegation authority granted by the program office LSE/CE.
AFMCI63-1201 2 DECEMBER 2022 65
A6.4.4.7. Submit the 202 to the appropriate engineering approval authority for Block 26E
approval.
A6.4.4.8. Notify the applicable program office via applicable form (e.g., Air Force
Technical Order (AFTO) Form 22, Technical Manual Change Recommendation and
Reply) when there is a need to correct/update technical orders, drawings and/or the work
specification (if applicable).
A6.4.4.9. Ensure all changes to technical data procedures, even one-time changes via a
202, are verified by performance or as otherwise specified by TO 00-5-3 or the LSE/CE in
the delegation letter.
A6.4.4.10. Notify engineering approval authorities if they will be unavailable for extended
periods.
A6.4.4.11. Special coordination requirements for disposition engineers. Certain categories
of dispositions require program office subject matter expert (SME) coordination, and in
general apply to disposition engineers regardless of organizational location. As specified
below, the following disposition instructions are coordinated with the SMEs prior to
submitting to the engineering approval authority:
A6.4.4.11.1. Repairs to or replacement of fatigue critical structure is coordinated with
program office aircraft structural integrity program (ASIP) manager.
A6.4.4.11.2. New or prototyped Non-Destructive Inspection (NDI) procedures are
coordinated with the AFLCMC program office ASIP manager and the AFSC weapon
system NDI PM or qualified NAS 410 Level III support point.
A6.4.4.11.3. Work-arounds, complicated structural repairs, efforts to save structure, or
repair/replacement that requires analysis to ensure the integrity of the disposition
approach are coordinated with program office engineering. Any additional OEM
support required for the 202 disposition is the responsibility of the program office
engineering staff; therefore, the 202 should be returned to the program office for further
disposition instructions.
A6.4.4.11.4. Any defects found during analytical condition inspections are
coordinated with the Analytical Condition Inspection Manager in the program office.
A6.4.4.11.5. Any request to waive (or not work) technical requirements specified by
work specification, technical order and/or drawings are worked through the program
office LSE/CE. The 202 is not used to request a waiver for technical requirements.
A6.4.4.11.6. Deferred Repairs, Interim Repairs and Alternate Part Substitutions are
coordinated with the program office to assess life cycle impacts.
A6.4.4.11.7. Follow any additional review and coordination as required by local OIs.
A6.4.5. Engineering Approval Authority Responsibilities. The Engineering Approval
Authority works within an engineering organization. The responsibilities below are
independent of whether the Engineering Approval Authority works directly for the LSE/CE or
the maintenance organization. Specific duties for the Engineering Approval Authority include:
A6.4.5.1. Ensure that approvals are within the scope of the delegated authorities from the
LSE/CE.
66 AFMCI63-1201 2 DECEMBER 2022
A6.4.5.2. Review 202s for completeness, accuracy, soundness of engineering
practices/principles, technical resolution proposed, and for cost, schedule and weapon
system life cycle considerations. If the 202 is incorrect, the 202 is demoted back to the
responsible disposition engineer for revision.
A6.4.5.3. Ensure all coordination required in paragraph A6.4.4.11 is received and
annotated on the 202.
A6.4.5.4. Complete the 202, Part B, Block 26E IAW AFMCMAN 63-1202 as required to
meet the 202 delegation authority from the program office LSE/CE.
A6.4.5.5. Ensure timely completion of open 202s.
A6.4.5.6. Ensure the completed 202, with signatures and all attachments, is retained in the
authorized electronic system or repository.
A6.4.6. Air Logistics Complex (ALC) Technical Director Responsibilities. The ALC (or
equivalent) Technical Director's responsibilities regarding delegated engineering authority
include:
A6.4.6.1. Submit/recommend requests for delegated engineering authority for ALC-
assigned disposition engineers and engineering approval authorities to the applicable
weapon system LSE/CEs.
A6.4.6.2. Ensure each ALC-assigned disposition engineer and engineering approval
authority is rated within an engineering chain that is outside of the group/directorate that
is conducting the maintenance.
A6.4.6.3. Provide processes, training, tools and facilities to enable the engineering
activity. This includes standardized processes supporting the LSE/CE's required audits.
A6.4.7. Maintenance Supervisors of Disposition Engineers and Engineering Approval
Authorities. Supervisors of disposition engineers and engineering approval authorities will
ensure the disposition engineers and engineering approval authorities have sufficient technical
training to achieve and maintain proficiency in the technical areas that delegated engineering
authority has been granted and as required by their applicable LSE/CE.
A6.4.8. Depot Maintenance Planner. While the detailed responsibilities of the depot
maintenance planner are outside the scope of this instruction, they play a key role in the 202
disposition process. Disposition engineers should be aware of and leverage the planner's role
in the 202 process. In many cases, the disposition engineer can help the planner with their part
of the 202 process by verifying that there are no technical data (drawings, technical orders,
etc.) or procedures that exist to address the deficiency, and by ensuring the deficiency
description is clearly and accurately documented on the 202.
A6.5. Rating Chain for Disposition Engineer and Engineering Approval Authority.
A6.5.1. Each disposition engineer and Engineering Approval Authority is rated within an
engineering chain that is outside of the Group/Directorate that is conducting the maintenance.
A6.5.2. Disposition engineers are rated within an engineering chain separate from the
Maintenance Product Group/Directorate that is being supported by the delegated Engineering
Authority.
AFMCI63-1201 2 DECEMBER 2022 67
A6.5.3. Engineering approval authority in the maintenance organization is assigned to a
person within an engineering organization in the Air Logistics Complex (or equivalent),
typically the ALC Technical Director; and the rater is a senior engineer on a Critical
Engineering Position as defined by AFMCI 62-202, Criteria for Critical Engineering
Positions. The program office LSE/CE should provide input to the supervisor/rater of the
Engineering Approval Authority.
A6.6. Delegation Letters. Delegations are made via formal delegation letter from the LSE/CE.
Table A6.2 and Table A6.3 in this attachment provide specific templates for delegation letters to
disposition engineers and engineering approval authorities. These are recommended (not
mandatory) templates, and they may be tailored for specific programs and organizations. However,
regardless of tailoring, the following is required for delegation to disposition engineers and
engineering approval authorities:
A6.6.1. Delegations are reviewed and updated IAW Chapter 3 of this instruction.
A6.6.2. Delegation letters stipulate that no further delegation is authorized.
A6.7. Business Case and Justification for Delegation of Engineering Authority.
A6.7.1. It is the responsibility of the maintenance organization to initiate the business case for
delegation, but it is developed in conjunction with the program office because several items
will require input from the program office. The applicable weapon system PM is the final
decision authority of the business case and the decision to delegate or not; however, since AF
policy designates the LSE/CE as the program's final Engineering/Technical Authority,
LSE/CE coordination is also required. The business case should be reviewed no less often than
biennially to assess improvement opportunities and possible expansion/reduction in the scope
of responsibilities. The business case should follow the outline below-- it can be tailored to
program needs to include program-unique content and other factors.
A6.7.1.1. Proposed scope of delegation.
A6.7.1.2. Schedule benefit (or "none anticipated"): Programmed Depot Maintenance
(PDM) flow reduction, 202 flow times, etc.
A6.7.1.3. Cost benefit (or "none anticipated"): labor cost, cost avoidance, implementation
cost, etc.
A6.7.1.4. Risks: OSS&E and airworthiness related risks, cost/schedule risk, etc., including
risk reduction and any proposed mitigations.
A6.7.1.5. Intangible benefits: better responses, reduce invalid 202s, other opportunities.
A6.7.1.6. Documentation: supporting documentation such as quantity of 202s processed,
existing flow times, and qualification of engineers compared to desired qualifications.
A6.7.1.7. Comparative Analysis: overall comparison of existing process against the
process being proposed. Comparison should also include any other applicable options and
an implementation recommendation.
A6.8. Annual Reviews. The LSE/CE or his/her staff should meet annually with the delegated
engineering authority engineers (disposition engineers and engineering approval authorities) to
assess the delegated efforts, the 202 disposition response time and the rationale for resources (if
68 AFMCI63-1201 2 DECEMBER 2022
any) that were required from the program office. Initially it is recommended that such reviews
occur more frequently to ensure proper implementation of delegated engineering authority efforts.
A6.9. Non-Concurrence. The LSE/CE or his/her staff should periodically review completed
202s to ensure they are of adequate quality and that dispositions did not have unintended OSS&E
or airworthiness consequences. The LSE/CE retains the right to non-concur and readdress any
previously completed 202 disposition.
A6.10. Memorandum of Agreement (MOA). Depending on the needs of the program office
and the maintenance organization, it may be necessary to document organizational level
agreements to facilitate delegated engineering authority. A tailorable MOA template is provided
in Table A6.4 The examples included in the recommended MOA template are just examples of
decisions that should be considered and are not intended to recommend a decision. The need for a
formal MOA should consider the following:
A6.10.1. Is there a benefit to rotating engineers between the program office and the
maintenance organization?
A6.10.2. Is there a benefit to participating in various cross-organizational meetings (e.g.,
production meetings)?
A6.10.3. Are there specific training requirements?
A6.10.4. Are there detailed agreements that apply to multiple delegated engineering
authorities that are better captured in an MOA?
A6.11. Depot Maintenance Delegated Engineering Authority - Recommended Qualifications for
Disposition Engineers and Engineering Approval Authorities.
A6.11.1. To aid in the consistent interpretation of what constitutes an engineer with sufficient
competency to have delegated engineering authority, PMs and LSE/CEs should consider the
qualification guidelines in Table A6.1 The delegated Engineering Authority engineers should
meet the knowledge/skills/abilities as defined in the standard core documents for a given
series/grade. In addition, the LSE/CE and/or PM may require delegated engineering authorities
to have additional qualifications prior to delegation, such as specific weapon system
familiarization courses. In all cases regardless of organizational location, engineering approval
authorities should be journeymen level (at a minimum) in their field of engineering.
A6.11.2. Note: A December 2012 memo from SAF/AQR (Selecting Professional S&E
(Scientist and Engineer) Employees (Science, Technology and Engineering)) states that "all
professional engineering Standard Core Personnel Documents (SCPDs) will contain the
following statement: 'A professional engineering degree at the bachelor's level from an
Accreditation Board for Engineering and Technology (ABET) accredited institution in
[specific discipline of position] or a closely related engineering discipline is highly desired."
A6.11.3. There may be occasions where the maintenance engineer being considered as a
disposition engineer or engineering approval authority holds an engineering degree outside of
their assigned job series. In these cases, the engineer can take qualifying engineering courses
more appropriate to the assigned series. Examples of qualifying aerospace engineering courses
include: aerodynamics, fracture mechanics, finite element analysis, propulsion systems,
dynamic systems and controls, control systems, dynamics of atmospheric flight, elements of
space flight, and airframe structures. Examples of qualifying mechanical engineering courses
AFMCI63-1201 2 DECEMBER 2022 69
include: fluid mechanics, mechanics of solids, materials science, strength of materials, and
heat/mass transfer.
Table A6.1. Recommended Qualification Guidelines for Disposition Engineer and
Engineering Approval Authority Engineers.
Disposition Engineer (Block 26A)
Engineering Approval
Authority (Block 26E)
Minimum Requirements
Entry Level
Journeyman
Journeyman
Education:
Undergraduate
Engineering
Degree
Bachelor of Science Engineering degree (e.g., Mech., Elect., Aero.)
AND four (4) qualifying engineering courses if the degree is outside
the assigned series (see paragraph A6.11)
Job-Specific
Coursework
As identified by LSE/CE
Advanced Technical
Degree
Not Required Desired, Not Required
Experience:
Weapon System
or
Product
None Required
Three (3) years of
demonstrated tech.
experience in a
weapon system or
commodity, in
either a
development or
sustainment role
Five (5) years of
experience applying
engineering principles to
solve weapon system
problems
Systems Engineering Knowledge:
OSS&
E
One (1) year of
weapon system
experience
Three (3) years of
weapon system
experience
Three (3) years of
weapon system
experience
Airworthiness
AF Institute of
Technology (AFIT)
SYS 116,
Introduction to AF
Airworthiness
Certification, or
equivalent
AFIT SYS 116 or
equivalent; and AFIT
SYS 316, Advanced
Airworthiness
Certification or
equivalent
AFIT SYS 116 or
equivalent; and AFIT
SYS 316 or equivalent
A6.12. Options in Lieu of Delegated Engineering Authority to a Maintenance
Engineer. This attachment’s recommended processes to enable engineering delegation to a
maintenance organization's engineer do not prohibit the implementation of other alternatives to
70 AFMCI63-1201 2 DECEMBER 2022
provide engineering support to production organizations. The maintenance organization and the
program office may consider other options, such as reassigning a member of their staff to reside
in the maintenance organization. This person would still be a direct report to the LSE/CE but might
take day-to-day direction from maintenance supervision. Another option may include delegating
engineering authority to qualified and competent contractors.
AFMCI63-1201 2 DECEMBER 2022 71
Table A6.2. Recommended Template for 202 Disposition Engineer Approval Delegation.
72 AFMCI63-1201 2 DECEMBER 2022
Table A6.3. Recommended Template for 202 Engineering Approval Authority Delegation.
AFMCI63-1201 2 DECEMBER 2022 73
74 AFMCI63-1201 2 DECEMBER 2022
Table A6.4. Recommended Delegated Engineering Authority Organizational MOA
Template.
AFMCI63-1201 2 DECEMBER 2022 75
76 AFMCI63-1201 2 DECEMBER 2022
AFMCI63-1201 2 DECEMBER 2022 77
78 AFMCI63-1201 2 DECEMBER 2022
