**Draft Revision 0.3**

**18 May 2001**

![](media/image1.png)

##### EIA STANDARD 836

#######  CONFIGURATION MANAGEMENT DATA EXCHANGE AND INTEROPERABILITY

**G-33 Data and Configuration Management Committee**

**For Committee and Public Review**

***This standard is a work in progress. Its current content represents
the work that has been accomplished as of the cut-off date for this
draft revision. As of the date of this draft revision, all changes will
be made via the formal EIA comment system provided by ManTech.***

***Enter new comments, and check for already documented comments, and
comment dispositions with revised content at***

<http://mars.dcnicn.com/custcomm/eia649>

***To join the GEIA EIA-836 Working Group or to discuss any aspect of
this standard,\
contact one of the following:***

***Alan Lager, GEIA Task Leader, MLR Associates/ ManTech \~**
<alan_e_lager@msn.com>**, 703-567-3280***

***Merv Leavitt, OSD/Navy, OSD Task Leader \~**
<mervyn.Leavitt@osd.mil>**, 703-695-2300***

***Russ Moody, SAIC, Technology Leader \~**
<Russell.F.Moody@saic.com>**, 937-431-2282***

***Linda Baroni, ManTech Program Manager \~** <kingl@mantech-wva.com>**,
304-367-1699***

**Page Intentionally Blank**

# Contents

***Click on any entry***

[Contents 3](#contents)

[Foreword 7](#foreword)

[Introduction 7](#introduction)

[1.1 Scope of the Standard 9](#scope-of-the-standard)

[1.2 Overview of the Standard 9](#overview-of-the-standard)

[1.3 Data Element Naming Conventions
10](#data-element-naming-conventions)

[2. Normative References 12](#normative-references)

[3. Definitions 14](#definitions)

[4. Symbols and Abbreviations 14](#symbols-and-abbreviations)

[4.1 Symbols 14](#symbols)

[4.2.1 Abbreviations 14](#abbreviations)

[5. CM Reference Schema Description
15](#cm-reference-schema-description)

[5.1 Common Oblets 15](#common-oblets)

[Address.dtd 15](#address.dtd)

[Copyright.dtd 16](#copyright.dtd)

[DataRights.dtd 16](#datarights.dtd)

[DateTime.dtd 16](#datetime.dtd)

[DistributionRestriction.dtd 16](#distributionrestriction.dtd)

[DocumentIdentification.dtd 16](#documentidentification.dtd)

[Effectivity.dtd 17](#effectivity.dtd)

[Entity.dtd 17](#entity.dtd)

[ExportControl.dtd 18](#exportcontrol.dtd)

[FacilityIdentification.dtd 18](#facilityidentification.dtd)

[File.dtd 18](#file.dtd)

[Organization.dtd 18](#organization.dtd)

[PackagedProduct.dtd 19](#packagedproduct.dtd)

[Part-MaterialIdentification.dtd 19](#part-materialidentification.dtd)

[Patent.dtd 19](#patent.dtd)

[Person.dtd 19](#person.dtd)

[PostalAddress.dtd 20](#postaladdress.dtd)

[ProductIdentification.dtd 20](#productidentification.dtd)

[ProductInstance.dtd 20](#productinstance.dtd)

[ProductProtection.dtd 20](#productprotection.dtd)

[ProductType.dtd 20](#producttype.dtd)

[SecurityClassification.dtd 21](#securityclassification.dtd)

[SoftwareIdentification.dtd 21](#softwareidentification.dtd)

[Trademark.dtd 22](#trademark.dtd)

[UnitOfMeasure.dtd 22](#unitofmeasure.dtd)

[Variance.dtd 22](#variance.dtd)

[5.2 Business Relationships 22](#business-relationships)

[BusinessRelationships.dtd 23](#businessrelationships.dtd)

[TradingPartner.dtd 23](#tradingpartner.dtd)

[Agreement-Contract-Data.dtd 23](#agreement-contract-data.dtd)

[ChangeControlEntity.dtd 24](#changecontrolentity.dtd)

[5.3 Product Definition 25](#product-definition)

[Product.dtd 25](#product.dtd)

[Hardware.dtd 25](#hardware.dtd)

[Software.dtd 27](#software.dtd)

[Process.dtd 29](#process.dtd)

[Facility.dtd 30](#facility.dtd)

[5.4 Product Configuration 31](#product-configuration)

[ProductConfiguration.dtd 31](#productconfiguration.dtd)

[AsDesignedProductStructure.dtd 33](#asdesignedproductstructure.dtd)

[AsPlannedProductStructure.dtd 35](#asplannedproductstructure.dtd)

[AsBuiltConfiguration.dtd 35](#asbuiltconfiguration.dtd)

[AsMaintained-ModifiedConfiguration.dtd
37](#asmaintained-modifiedconfiguration.dtd)

[5.5 Document 38](#document)

[Document.dtd 38](#document.dtd)

[UniversalDocumentData.dtd 38](#universaldocumentdata.dtd)

[ProductRequirementsObject.dtd 39](#productrequirementsobject.dtd)

[Specification.dtd 39](#specification.dtd)

[EngineeringDesignObject.dtd 39](#engineeringdesignobject.dtd)

[ProductOperationObject.dtd 40](#productoperationobject.dtd)

[ProductMaintenanceObject.dtd 40](#productmaintenanceobject.dtd)

[5.6 CM Actions 40](#cm-actions)

[CMActions.dtd 41](#cmactions.dtd)

[ActionItem.dtd 41](#actionitem.dtd)

[SelectingConfigurationItems.dtd 42](#selectingconfigurationitems.dtd)

[AssigningTrackingIdentifiers.dtd 42](#assigningtrackingidentifiers.dtd)

[NumberingProducts-Documents.dtd 42](#numberingproducts-documents.dtd)

[DocRelease-Review-ApprovalStatus.dtd
42](#docrelease-review-approvalstatus.dtd)

[IdentifyingNeedForChange .dtd 44](#identifyingneedforchange-.dtd)

[RequestingChangeOrVariance.dtd 44](#requestingchangeorvariance.dtd)

[Classifying Changes.dtd 44](#classifying-changes.dtd)

[ChangeImpactAssessment .dtd 45](#changeimpactassessment-.dtd)

[DeterminingChangeEffectivityAndCost.dtd
45](#determiningchangeeffectivityandcost.dtd)

[ChangeDecisionAction.dtd 45](#changedecisionaction.dtd)

[ChangeImplementingAction.dtd 45](#changeimplementingaction.dtd)

[ConfigAuditAction.dtd 47](#configauditaction.dtd)

[DeliveryAcceptance.dtd 48](#deliveryacceptance.dtd)

[MaintainStatusAccounting.dtd 49](#maintainstatusaccounting.dtd)

[6. CM Business Objects 50](#cm-business-objects)

[6.1 CM Planning And Management Business Objects
50](#cm-planning-and-management-business-objects)

[CMPlan.dtd 50](#cmplan.dtd)

[ActionItemStatusReport.dtd 53](#actionitemstatusreport.dtd)

[6.2 Configuration Identification Business Objects
54](#configuration-identification-business-objects)

[InterfaceControlDoc-Def.dtd 54](#interfacecontroldoc-def.dtd)

[ReleaseRecord.dtd 55](#releaserecord.dtd)

[EngineeringReleaseRecord-Def.dtd 55](#engineeringreleaserecord-def.dtd)

[TrackingIdentifierAssignmentRecord.dtd
57](#trackingidentifierassignmentrecord.dtd)

[6.3 Configuration Change Management Business Objects
57](#configuration-change-management-business-objects)

[RequestForChange.dtd 57](#requestforchange.dtd)

[RequestForVariance.dtd 57](#requestforvariance.dtd)

[RequestForDeviation-Def.dtd 58](#requestfordeviation-def.dtd)

[ChangeProposal.dtd 59](#changeproposal.dtd)

[EngineeringChangeProposal-Def.dtd
60](#engineeringchangeproposal-def.dtd)

[ChangeDirective.dtd 68](#changedirective.dtd)

[SpecificationChangeNotice-Def.dtd
69](#specificationchangenotice-def.dtd)

[DocumentRevisionNotice.dtd 70](#documentrevisionnotice.dtd)

[NoticeOfRevision-Def.dtd 71](#noticeofrevision-def.dtd)

[ChangeCommitmentRecord.dtd 72](#changecommitmentrecord.dtd)

[ChangeImplementationPlan.dtd 72](#changeimplementationplan.dtd)

[6.4 Configuration Status Accounting Business Objects
72](#configuration-status-accounting-business-objects)

[ChangeProcessStatusReport.dtd 72](#changeprocessstatusreport.dtd)

[Part-MaterialUsageReport.dtd 72](#part-materialusagereport.dtd)

[ChangeIncorporationReport.dtd 72](#changeincorporationreport.dtd)

[AsBuiltStatusReport.dtd 72](#asbuiltstatusreport.dtd)

[ConfigStatusAcctingReport-Def.dtd
73](#configstatusacctingreport-def.dtd)

[InstallationCompletionNotice.dtd 74](#installationcompletionnotice.dtd)

[6.5 Configuration Verification And Audit Business Objects
74](#configuration-verification-and-audit-business-objects)

[AsDesigned-AsBuiltReconciliationReport.dtd
74](#asdesigned-asbuiltreconciliationreport.dtd)

[ConfigAuditReport.dtd 74](#configauditreport.dtd)

[ConfigAuditSummaryReport-Def.dtd 75](#configauditsummaryreport-def.dtd)

[6.6 Data-Document Management Business Objects
75](#data-document-management-business-objects)

[CommentToDocument.dtd 75](#commenttodocument.dtd)

[DocumentCommentDisposition.dtd 76](#documentcommentdisposition.dtd)

[DocumentTransfer.dtd 76](#documenttransfer.dtd)

[6.7 General Business Objects 76](#general-business-objects)

[ManufacturingPlan.dtd 76](#manufacturingplan.dtd)

[ModificationInstruction.dtd 77](#modificationinstruction.dtd)

[ModKitValidationReport.dtd 78](#modkitvalidationreport.dtd)

[MaintenancePlan.dtd 78](#maintenanceplan.dtd)

[ProductDelivery-AcceptanceReport.dtd
78](#productdelivery-acceptancereport.dtd)

[KitShipmentReport.dtd 79](#kitshipmentreport.dtd)

[7. Application Notes 80](#application-notes)

[Annex A. CM Data Dictionary 81](#annex-a.-cm-data-dictionary)

[A.1 Scope 81](#a.1-scope)

[EIA-836 Annex A. CM Data Dictionary 81](#__RefHeading___Toc514502257)

[A.2 Data Dictionary Content 81](#a.2-data-dictionary-content)

[Annex B. EIA-836 User Guidance (Informative)
82](#annex-b.-eia-836-user-guidance-informative)

[B.1 Scope 82](#b.1-scope)

[B.2 How To Read EIA-836 Schemas 82](#b.2-how-to-read-eia-836-schemas)

[EIA-836 Schema Guide 82](#__RefHeading___Toc514502262)

[B.2.1 XML Element Content Model 82](#b.2.1-xml-element-content-model)

[B.2.2 XML Element and Attribute Datatyping
82](#b.2.2-xml-element-and-attribute-datatyping)

[B.2.3 XML Attribute Usage 82](#b.2.3-xml-attribute-usage)

[Annex C. Data Element -- Alias Cross-Reference
83](#annex-c.-data-element-alias-cross-reference)

[C.1 Scope 83](#c.1-scope)

[C.2 Alias Cross-Reference Content
83](#c.2-alias-cross-reference-content)

[Annex D. Data Element -- UDEF Cross-Reference
85](#annex-d.-data-element-udef-cross-reference)

[D.1 Scope. 85](#d.1-scope.)

[D.2 Data Element-UDEF Cross Reference Content
85](#d.2-data-element-udef-cross-reference-content)

[Annex E. EIA-836 Data Type Definitions
86](#annex-e.-eia-836-data-type-definitions)

[E.1 Scope. 86](#e.1-scope.)

[E.2 Data Type Definition List 86](#e.2-data-type-definition-list)

# Foreword

In the era of digital data and e-business, rapid access to accurate CM
data has never been more important. Effective access to, sharing of, and
exchange of CM data including common business objects and ad-hoc query
to information in databases or hosted on websites depends upon
standardized CM data definitions including data element relationships.

EIA-836 facilitates the interoperability and exchange of configuration
management data. The level of interoperability between dissimilar
systems is determined by trading partner agreement. The extensible
markup language (XML) facilitates data sharing and exchange among
different systems. EIA-836 provides a set of standard definitions and
business objects that can be used by XML frameworks in interfacing the
content elements among one or more systems or databases.

EIA-836 is designed to have wide applicability across vertical
industries. The process employed to provide access, sharing or exchange,
is typically accomplished using one of many available product data
management tools or systems, often customized to a specific
organizational environment. To be most effective, the capabilities of
the process, tools or systems, should embody the CM principles in
ANSI/EIA-649 in conjunction with the business objects and data element
definitions in EIA-836.

# Introduction

EIA-836 is a logical extension of ANSI/EIA-649, "National Consensus
Standard for Configuration Management," which defines the CM principles
upon which it is based. EIA-836 also supports the Product Life Cycle
Support (PLCS) Activity and Data Models. As shown in Figure 1, the
primary focus of EIA-836 is on data element definitions and
relationships and business objects for information exchange.

![](media/image2.wmf){width="4.809722222222222in"
height="3.6222222222222222in"}

EIA-836 is a fundamental reference for the access, sharing and exchange
of CM data, and for developing; mapping and using CM enabled tools,
systems, and databases. It facilitates interoperability regardless of
specific schema or specific method of data transfer.

1\. Scope

## 1.1 Scope of the Standard

EIA-836 provides a comprehensive reference vocabulary. It includes
definitions of all CM data elements and attributes considered to be
within the CM domain that address:

-   Product identification and relationships

-   Configuration identification,

-   Configuration change management

-   Configuration status accounting,

-   Configuration verification and audit, and

-   Data and document management

EIA-836 provides a complete set of XML reference schema to provide the
context for the CM data definitions by graphically illustrating the data
element and attribute relationships, and to establish a basis for data
modeling, data mapping, and data exchange.

The set of CM Business Objects in EIA-836 facilitates exchange of
documents, data transactions, messages, and inquiries. The business
objects may be modified or tailored by users to suit specific trading
partner situations and different industry domains.

Since the focus of this standard is on CM data, it does not address all
of the content elements of such objects as engineering drawings, part
models, or specifications. The standard includes data necessary to
locate such objects and includes only metadata pertinent to
configuration management. Content, such as the following is considered
to be out of scope:

-   Product definition geometry, topology, tolerances, features,
    specifications/requirements,

-   Process description, and manufacturing process plans.

## Overview of the Standard

The body of EIA-836 essentially consists of CM reference schemas, which
are annotated with data element definitions, and CM business objects.
Annexes to the standard contain user guidance, an alphabetically
arranged data dictionary, and several informative cross-reference
tables.

**Clauses 1 through 4** of this standard contain the scope, normative
references, definitions, and symbols and abbreviations.

**Clause 5. CM Reference Schema** provides a graphical representation of
the relationships between CM data elements implemented in an XML
schema[^1]. Data relationships are essential to a clear understanding of
the data element definitions. Even more important, however, proper
relationships are what enable a system to access the correct CM data for
a given product configuration from among vast amounts of potentially
erroneous or irrelevant data that a data query might otherwise return.
The purpose of the schema is to convey a clear picture of the
relationships to provide context for the data element definitions.

**Clause 6. CM Business Objects** contains detailed content descriptions
of CM "business objects. The business objects are data exchange
documents represented as templates rather than rigid standards.

**Annex A. CM Data Dictionary** is a tabular alphabetic listing showing
the definition of all the data elements and attributes that are used in
the EIA-836 reference schema and business objects. For each element
name, a link to the originating reference schema is provided. The
dictionary contains known aliases for the elements listed as well.

**Annex B. EIA-836 User Guidance** provides user assistance in
navigating and applying EIA-836

**Annex C. Data Element -- Alias Cross-Reference** provides a listing of
alias (alternative) names for the data element names used in the
reference schemas and business object schemas, listed alphabetically by
alias name.

**Annex D. Schema Usage Cross-Reference** provides a listing for each
schema showing the related schemas and oblets that are invoked within
it.

**Annex E. Data Element -- UDEF Cross-Reference** provides a Universal
Data Element Framework (UDEF) name and code for each data element in
EIA-836.

**Annex F. Data Type Definitions (dtds)** contains the complete set of
individual dtds that are described in Clauses 5 and 6 and which
collectively comprise the EIA-836 Reference Schema.

## 1.3 Data Element Naming Conventions 

The EIA-836 Data Element Dictionary (Appendix B) contains the full set
of business terms (data elements) needed to support the CM process
throughout the product life cycle. These data elements and their
definitions provide the foundation for effective information exchange
and sharing between business partners., including human-to-human,
human-to-computer, and computer-to-computer communications.

Data elements and attributes in EIA-836 are named descriptively based on
common usage by configuration management practitioners, i.e., the names
are \"semantically meaningful\" and consistent with respect to the
element/attribute information content/value. Other factors influencing
the naming of EIA-836 elements and attributes include human and machine
readability, and compatibility with related industry standards,
particularly those being adopted by the e-commerce and product data
management communities.

XML element and XML attribute names consist of one or more words strung
together without spaces. The element/attribute name is comprised of one
"Object" word identifying the real world object that the
element/attribute applies to, one "Property" word that describes the
content/value of the element/attribute, and optional Qualifier words for
the Object and Property words. The Object word precedes the Property
word. The Qualifier word precedes the word that it qualifies. An example
of the word order is shown in Figure 1.3-1.

![](media/image3.wmf){width="2.8in" height="2.1145833333333335in"}

**Figure 1.3-1. Element/Attribute Naming Convention**

In the schemas and dictionary, each definition of an element, or
attribute is preceded by an element name in two formats. The first
format is the "formal name," which has each word spelled out and
separated by a space from the adjoining word. The second format,
enclosed in parenthesis, is the "element name" used in the schema. In
accordance with XML practice and for clarity, each Object, Property, and
Qualifier word begins with a capital letter. There are no spaces between
words.

Words and abbreviations used in element and attribute names are
consistent throughout the EIA-836 Context Schema, Business Object
Schemas, and Data Element Dictionary. The use of abbreviations,
acronyms, and jargon in XML element and attributes names is avoided as
much as possible. Abbreviations are used when they are in common usage
within a broad segment of the intended user community, are in common
usage within the CM domain, e.g., abbreviations used in EIA-649, or in
some cases where the un-abbreviated element name would be excessively
long. Articles and prepositions are also avoided. For example, *Product
Component* is used in lieu of *Component Of Product*. Exceptions
includes common usage terms such as *Statement Of Work*. Hyphenation
between words is sometimes used where it enhances clarity, where it
substitutes for an "and" or an "or, " or where common usage includes a
hyphen between the words.

# Normative References

NORMATIVE REFERENCES

  -----------------------------------------------------------------------
  541

  ANSI Y14

  ANSI/EIA-649

  ANSI/IEEE STD 260

  DDRS element 10

  DFAR 252

  DFAR 52

  DOD 4100

  DoD 5120

  DoD 5200

  ISO 10303-203

  ISO 8601
  -----------------------------------------------------------------------

INFORMATIVE REFERENCES

  -----------------------------------------------------------------------
  125

  ANSI Y14

  ANSI Y14-24M

  Department of Defense Data Repository System (DDRS) element 7

  DFAR 52

  DFARS 204

  DI-CMAN-80463C

  DI-CMAN-80640C

  DI-CMAN-80642C

  DI-CMAN-80643C

  DI-CMAN-80858B

  DI-CMAN-81022C

  DI-CMAN-81245A

  DI-CMAN-81253A

  DODD 5230

  DOD-STD-2167A

  DOE 4700

  DOE Order 413

  DOE-STD-1073

  EIA-632

  EIA-649

  IEEE-STD-1016

  IEEE-STD-610

  INCOSE Facilities Committee Working Papers

  ISO 10303-203

  ISO 10303-41

  ISO 6523

  ISO/IEEE/EIA 12207

  Library of Congress Copyright Office

  MIL-DTL-31000

  MIL-HDBK-61A(SE)

  MIL-PRF-49506

  MIL-STD-100

  MIL-STD-961D Notice 1

  MIL-STD-962

  United States Patent and Trademark Office
  -----------------------------------------------------------------------

#  

# 3. Definitions

Definitions in this clause are for the purpose of understanding the
standard, definition of all the configuration and data management terms
are contained in Appendix A.

-   **Oblet** -- A small, reusable schema (element grouping) that has
    some business sense, e.g., product identifier, document identifier,
    effectivity, address, and is used as a building blocks in the
    EIA-836 reference schemas.

-   **Product --** As used in this standard, every item is considered a
    product. Thus a piece part is a product, an assembly is a product,
    an end item is a product. As in EIA-649, references to a product
    should be interpreted as applicable to any item including any of the
    generic product categories of hardware, software, processes, data,
    materials, or services. (This is consistent with the definition of
    "product" in ISO Standard 8402).

# 

# 4. Symbols and Abbreviations

## 4.1 Symbols

The symbols used in the Reference schemas are described in Annex B.

## Abbreviations 

Abbreviations used in EIA-836 are as follows:

CM Configuration Management

Doc Document

Mfr Manufacture

Rep Representation

Rev Revision

\[Listing is incomplete -- To be completed for next draft\]

# 5. CM Reference Schema Description

The EIA-836 Reference Schema is an information model that provides a
real world-view of the business data and data relationships associated
with configuration management (CM) processes. The Reference Schema
encompasses all the data necessary to support CM processes as defined in
EIA-649. The lexical representation of the Reference Schema is an XML
Document Type Definition (DTD). The Reference Schema can be represented
graphically using any one of a number of XML DTD editors.

The Reference Schema includes graphical representations of the
relationships between data elements and definitions of the elements and
element attributes. It includes two subdivisions called Reference
Schema, and Business Objects, respectively. Both consist of a linking of
many individual document type definitions (dtds), which may be found
individually in Annex E, and which are logically grouped into
categories.

The Reference Schema categories corresponding to the subsections of
clause 5 that describe them are: Oblets (5.1), Business Relationships
(5.2), Product Definition (5.3), Product Configuration (5.4), Document
(5.5) and Configuration Management Actions (5.6).

The Business Object Schema categories are discussed in clause 6.

If an XML Editor (Such as Tibco Extensibility -- XML Authority) is
installed, click on the link below to access the EIA-836.dtd. You may
navigate to the entire content model of EIA-836 by clicking on the icons
within the entity boxes in the graphical display.

[EIA-836 Reference Schema](../EIA-836DTDFiles010516/EIA-836.dtd)

You may also refer to the EIA-836 Schema Diagrams PowerPoint file
(enclosed with this draft) for graphic views of individual schemas, and
to Annex E for the text representations of each schema.

[CM Reference Schema Diagrams including Oblets
(5.1)](../SchemaDiagrams-Oblets.ppt)

[CM Reference Schema Diagrams including Business Relationships (5.2)
through Configuration Management Actions
(5.6)](../SchemaDiagrams-Reference.ppt)

[CM Business Objects Reference Schema Diagrams
(6)](../SchemaDiagrams-Objects.ppt).

*Element Names* are italicized in the following descriptions of the
reference schema.

## 5.1 Common Oblets

Common Oblets define the elements in common building block schemas
referred to as "oblets" that are invoked repeatedly throughout the
standard. Oblets are reusable schemas that may be thought of as
"building blocks" for the EIA-836 reference schema. Each oblet is an
individual data type definition (dtd), which may also include other
oblets. The oblets dtds are individually described, in alphabetical
order, as follows:

###### Address.dtd 

Address is a general multi-purpose oblet schema. It includes one or more
of the optional elements: *Postal Address* (which is an included oblet),
*Location Designator*, and zero or more occurrences of *Phone Number,
E-mail address, or Internet Address*. The schema is constructed so that
any of these components can be used independently or collectively by the
schema that invokes the oblet, e.g., the Address oblet can be invoked
solely to refer to a Location Designator code such as an airport
designation like JFK, DCA, or LAX.

###### Copyright.dtd 

The Copyright oblet contains the data elements needed to uniquely
identify and describe a copyright including effectivity, expiration,
issuer and holder. Copyright has an attribute, *Copyright Status* which
allows trading partners to explicitly state if there are, or are not,
copyright restrictions associated with the data they are exchanging. The
Copyright oblet contains the data element *Copyright Statement* that
provides a description of the copyright and use restrictions of the
product. The oblet contains the data element, *Copyright Date* that
identifies the copyright registration date, which is the date the
Copyright Office receives all the required application elements in
acceptable form. The Copyright oblet also contains optional data
elements, *Copyright Expiration Date*, *Copyright Holder*, and
*Copyright Issuer* that provide the expiration date, holder and issuer
of the Copyright if required.

###### DataRights.dtd 

The Data Rights dtd provides the indicators for the protective
requirements on the delivered product. A required enumerated *Data
Rights Code* attribute denotes the restriction on the use of the
product. Optionally, the *Data Rights Authority* (organization issuing
the classification), *Data Rights Expiration Date*, and *Data Rights
Statement* (the text of the data rights statement) may be provided. For
US Government restrictions, the code and text that represents and/or
denotes the restriction on the use of the delivered product may also be
provided.

###### DateTime.dtd 

The Date and Time oblet is used when the *Date,* and optionally the
*Time* are needed within other schemas or *Time Duration* may be chosen
to represent a period of time versus a specific date or time. The
allowable formats are those specified in ISO 8601.

###### DistributionRestriction.dtd 

Distribution restrictions may be placed on a delivered product for
several reasons. This is usually due to sensitive data contained within
the product. The included elements are the *Distribution Authority* that
controls the distribution restriction on the product, *Distribution
Restriction Statement,* and optionally the *Distribution Restriction
Date.*

###### DocumentIdentification.dtd 

The Document Identification dtd provides the information needed to
uniquely identify a document, which includes the identifier of a
document by a number or title, source of the identifier, and revision.
Note: In addition to the primary identifier, a document can have
alternate numbers or names that may also uniquely define the document
.In the context of this standard those aliases are additional document
identifications. The root element Document Identification consists of
the elements *Document Identifier*, *Document Revision*, and *Document
Identification Source*.

The element *Document Identifier*, which can be a number or title,
consists of either *Document Title* (used as the identifier of a
document when there is no alphanumeric document identifier) or *Document
Alphanumeric Identifier* (the identification number a document).

The element *Document Revision* (the version or revision of a document)
provides for identification of different representations of the same
document revision, as well. *Document Revision* is represented by either
(or both) *Revision Identifier* or *Document Revision Date (*an initial
release or a revision to a document*)*, and optionally *Document
Representation Revision.*

The *Document Representation Revision* element allows identification of
each document\'s representation by either (or both) *Document
Representation Revision Identifier* (an alphanumeric identifier
representing a specific iteration of a document representation) or
*Revision Representation Date* (the date of a document representation
revision).

The element *Document Identification Source*, the *Entity* assigning the
document identifier, is the element that gives the identification
uniqueness.

###### Effectivity.dtd 

Effectivity, a fundamental CM concept, is expressed in this oblet that
is used in a variety of different ways to express applicability of a
change or variance or usage of a product or component. The schema that
invokes the effectivity oblet provides the specific context in which the
effectivity oblet is used, e.g., production effectivity, and retrofit
effectivity. The optional attribute *Effectivity Type*, which applies
specifically to the effectivity of a change, indicates either a hard
(mandatory) or soft (guidance) effectivity, as elaborated in the
enumeration provided in the definition of the attribute.

Effectivity includes a *Tracking Identifier Prefix* element that
describes the type of tracking identifier, such as manufacturer's serial
number, and one or more tracking identifiers, expressed as either a
single *Tracking Identifier*, or a range (*Start Tracking Identifier,
Stop Tracking Identifier*), or both. The tracking identifiers (data type
string) are usually, but not necessarily numeric. This schema
construction enables effectivity to be stated in terms of a single unit,
a single range of units or any sequence of individual and multiple
ranges of tracking identifiers, such as in serial numbers 1, 3-5, 8,
9-12.

###### Entity.dtd 

The Entity oblet is the parent schema for the Organization and Person
oblets. This oblet allows the option of the elements *Organization* (see
the Organization dtd oblet) or *Person* (see the Person dtd oblet) when
the choice is presented in other schemas.

###### ExportControl.dtd 

The Export Control dtd is a Boolean element, indicating whether a
product is under export control due to US Government regulations.

###### FacilityIdentification[.]{.underline}dtd 

The Facility Identification oblet contains the data elements needed to
uniquely identify a facility, specifically a *Facility Identifier*
element and a *Facility Identification Source* element. The *Facility
Identifier* is defined by either a *Facility Name* [or]{.underline} a
unique *Facility Alphanumeric Identifier*. The *Facility Identification
Source* is the *Entity* (*Person* or *Organization*) that assigns the
*Facility Identifier*.

###### File.dtd 

The File oblet contains the data elements needed to uniquely identify,
describe, and locate a digital or hard copy representation of a
collection of information. The File oblet contains the elements *File
Name,* *File Created,* and *File Location* plus optional data elements
*File Version*, *File Size,* *File Description*, *File Compression*,
*Operating System*, *Associated File*, and/or the oblet *Product
Protection*. File also has the attribute *File Type Code* that
represents or denotes the general type of electronic file (e.g. ASCII,
CGM, DOC, DSSSL, DTD)

**[LicenseAgreement.dtd]{.underline}**

The License Agreement dtd provides the information needed to uniquely
identify an agreement between two parties for the use of a given
product. This License Agreement could be a software license, hardware
maintenance license, or other license agreements not normally covered
through a legal contract. The root element *License Agreement* contains
*License Agreement Identifier* (a role of *Document Identification* that
uniquely identifies the license agreement and the issuer of that
agreement), *License Issue Date*, *License Period Terms* (including
*License Period*, and *License Expiration Date*), and *License Agreement
Description*.

###### Organization.dtd

Organization contains the information identifying a Company,
Association, Institution, or Government agency also referred to as a
trading partner. One or more of the following may define an
Organization:  *Name*, *Acronym*, and/or *Organization Code*. The
*Organization Code* used to identify an organization may contain such
identifiers as a CAGE, NSCM, or ISO Supplier Code.

###### PackagedProduct.dtd 

The Packaged Product oblet contains the data elements needed to uniquely
identify and describe the packaged end item as delivered to the
customer. The Packaged Product oblet contains the elements *Packaging
Process* that is defined by child element *Packaging Process Defining
Document*, and optional element *Packaging* (that may occur zero or more
times and is defined by child element *Packaging Defining Document*.
Packaging is optional and repeatable because you may have packaging
process that requires no physical packaging e.g. a software download.
Conversely you may have several different types of packaging required
for a single product e.g. a modular home shipped in pieces.

###### Part-MaterialIdentification.dtd

The Part-Material Identification oblet contains the data elements needed
to uniquely identify a Part-Material product, specifically a
*Part-Material Identifier* element and a *Part-Material Identification
Source* element plus optional elements *Part-Material Parameter* (zero
or more) and/or *Part-Material Revision* (zero or one). The
*Part-Material Identifier* is defined by either a *Part-Material Name*
or a *Part-Material Alphanumeric Identifier*. The *Part-Material
Parameter* element is a text descriptor of the part or material
classification scheme, which differentiates various parts or materials
from each other. This descriptor may be a text description of one or
more of the characteristics associated with the part or material
parameter type specified in the *Part-Material Parameter Type* attribute
(e.g. Category, Class, Color, Composition). The *Part-Material Revision*
is an optional element that provides for a revision indicator when
needed to uniquely identify a part or material. The *Part-Material
Identification Source* contains the *Entity* element, *Person* or
*Organization* that assigns the *Part-Material Identifier*.

###### Patent.dtd 

The Patent oblet allows for the identification of pertinent data with
regards to a product's patent, which includes the elements *Patent
Number*, *Patent Issuer*, *Patent Title*, *Patent Date* and *Patent
Holder*. The attribute *Patent Status* indicates whether a patent is
pending or issued. *Patent Date* is the date the patent was issued by
the Official Patent Organization or the date the patent application was
submitted. The *Issuing Organization*, *Patent Title*, and the *Patent
Holder* (which could be an organization or an individual) are optional
elements.

###### Person.dtd

The Person oblet allows for the unique identification of a person by a
unique identifier and name. There must be one or more occurrences of the
element *Person Identifier* and *Person Name* to uniquely identify a
person. The *Person Identifier* is an alphanumeric string identifier,
and attributes *Person Identifier* *Source* (source of the identifier
e.g., US Government or Company), *Person Identification Type* (an
indication of the type of identifier, e.g., SSN, Badge Number, Employee
Number, etc.) A persons Name may have zero or more *Prefix Titles*,
*Middle Names*, and *Suffix Titles*. There may be a *First Name* but a
*Last Name* is required, at a minimum, to identify a person by name.

###### PostalAddress.dtd

Postal Address includes zero or more *Street* elements, zero or one
*Post Box*, *City*, *Region* (e.g. State in the US), Optional *Postal
Code* (Zip Code in the US), Optional *Country*, and *Internal Address*
(e.g., Suite Number, Apartment Number, Building Designation, etc.). All
of the elements in Postal Address are typed as string elements. Note
that the address oblet does not contain the addressee name and/or
organization because these elements are contained in the reference
schemas that invoke the oblet.

###### ProductIdentification.dtd 

The Product Identification oblet contains the data elements needed to
uniquely identify one of four different product classes, *Part-Material
Identification*, *Software Identification, Facility Identification*, and
*Document Identification*, each of which has a separate dtd described in
this clause.

###### ProductInstance.dtd 

A Product Instance is a single occurrence of a product such as one unit
of a product, e.g., serial number 5, or one group of a product (series
of like units that are not individually identified), e.g., lot 12. The
root element *Product Instance* consists of the elements *Product
Identification* (which invokes the Product identification oblet),
*Tracking Identifier Prefix* that describes the type of tracking
identifier (such as serial number), and *Tracking Identifier*, which in
conjunction with the prefix identifies the unique instance (such as
serial number 500).

###### ProductProtection.dtd

The Product Protection oblet contains subordinate oblets that are
associated with intellectual property rights, security, export control,
and licensing. The oblet provides maximum flexibility to select the
product protection appropriate to a particular product by making the
choices optional and repeatable. The Product Protection oblet contains
the oblets Copyright, Data Rights, Distribution Restriction, Export
Control, License Agreement, Patent, Security Classification and
Trademark.

###### ProductType.dtd 

The Product Type dtd characterizes a product, or the instance of a
product, as to its nature, designation, or relative position within an
end item or system. The root element *Product Type* provides the choice
of one of two subordinate elements *Part-Material Type*, and *Software
Type*.

The *Part-Material Type* element provides an enumeration of hardware
categories such as Product, Synthetic Part, Configuration Item, End
Item, Major Assembly, Module, Modification Kit, Standard Part, Source
Control, or Altered Item and others. Additional categories can be
established by trading partners.

The *Software Type* element provides an enumeration of discrete and
identifiable levels of software decomposition for purposes of
development, configuration management, and delivery. Examples are
Computer Software Configuration Item (CSCI), Software End Item, Computer
Software Component, Software Unit, or Test Unit. Additional categories
can be established by trading partners.

###### SecurityClassification.dtd 

*Security Classification* is the root element of the Security
Classification oblet, which provides information concerning the security
classification, classification authority, and instructions for
classification downgrading and declassification of any item including a
document, file, component, assembly, or product. It consists of the
elemenets *Security Level* and its attribute *Security Level Code*
(which define the specific security classification), *Security
Classification* *Date*, *Security Classification* *Authority* (the
organization that issues the classification), zero or more occurrences
of *Access Restriction* and its attribute *Access Restriction Code*
(which define the access limitations). The oblet includes information
about *Security Classification Downgrade* including the *Security Level*
to be downgraded to, and the *Security Classification Downgrade Event*
or *Security Classification Downgrade Date.* It also addresses *Security
Classification Declassify* information including the *Security
Classification Declassify Event* or *Security Classification Declassify
Date*.

###### SoftwareIdentification.dtd 

The Software Identification oblet contains the data elements needed to
uniquely identify a software product, specifically *Software
Identifier*, *SW Version or Revision,* and *Software Identification
Source* elements.

The *Software Identifier* consists of either a *Software Name* or a
*Software Alphanumeric Identifier*.

The *SW Version or Revision* element is made-up of optional elements *SW
Version Identifier* and /or *SW Revision Identifier*, where:

-   SW Version Identifier consists of elements SW Version Number and SW
    Version Date.

-   SW Revision Identifier consists of elements SW Revision Number and
    SW Revision Date.

-   The use of both SW Version Identifier and SW Revision Identifier is
    governed by the attribute, Precedence, which provides the choice of
    two naming conventions for software version/revision. In the Major
    Version Minor Revision case, the primary identifier is version
    (Version 1, Revision 02, commonly referred to as Version 1.02). In
    the Major Revision Minor Version case, the primary identifier is
    revision (Revision 1, Version 02, commonly referred to as Revision
    1.02).

*Software Identification Source* contains the *Entity* element (*Person*
or *Organization* that assigns the *Software Identifier*).

###### Trademark.dtd 

A Trademark identifies and distinguishes the source of the goods or
services of one party from those of others. The attribute *Trademark
Categories* identifies two categories of Trademark (Common Law or
Federal Law); the attribute *Trademark Type* identifies five types
(Trade, Service, Registered, Collection, or Certification). The
categories and types are optional (blank when unknown). *Trademark*
includes the required elements *Trademark Item* (the symbol designating
the trademark), *Trademark Holder* (an organization or person), and
*Trademark Issue Date*. *Trademark Expiration Date* element is optional.

###### UnitOfMeasure.dtd 

The Unit Of Measure dtd provides a place for a text description of the
unit associated with an expression of quantity and also includes an
optional attribute Unit Of Measure Code that provides an enumeration of
abbreviations for the type of units that regulate the measurement of
parts and materials, e.g., BBL -- Barrel, Ft -- Foot, Gal. -- Gallon, G
-- Gram.

###### Variance.dtd

A Variance (alias: Deviation, Waiver, Concession) is a departure from a
particular requirement(s) of a product\'s current approved configuration
documentation for a specific number of units and/or a specified period
of time. A variance differs from an engineering change in that it does
not require a corresponding revision of the product\'s current approved
configuration documentation.

The Variance dtd root element *Variance* contains the elements *Variance
Description* (a text description of the variance)*, Variance
Classification* (a categorization of a variance as to its relative
severity)*, Document Identification* (delineating the document that
defines the variance)*, Effectivity Base Product* (the product to which
effectivity is assigned)*,* and *Variance Effectivity,* which invokes
the Effectivity oblet to indicate the effectivity to which the variance
applies.

The Variance Classifications include Critical, Major and Minor. The
*Effectivity Base Product* element includes the Product Identification
and Product Type oblets.

## 5.2 Business Relationships

The following Business Relationships schemas define and illustrate the
relationships of the data elements concerning organizations (including
companies, associations, government agencies, etc.) and people, and the
programs and projects those organizations are engaged in as trading
partners.

###### BusinessRelationships.dtd

The Business Relationships dtd is a container linking the business
relationships schemas. It contains the elements *Trading Partner*,
*Agreement-Contract Data*, and *Change Control Entity*, all of which are
inter-related. Each invokes a dtd of the same name, described below:

###### TradingPartner.dtd

The Trading Partner dtd provides correlation between the members of a
trading partnership associated with a specific program or project. The
root element *Trading Partnership* consists of one or more occurrences
of *Trading Partner Identification* (a role name for *Organization)* and
*Program-Project*. The *Program-Project* element consists of the
*Program-Project Identification* and a repeatable group of elements that
identify an *Agreement-Contact Identification*, an associated *Product
Identification* and an optional *Change Control Entity* (invoking the
Change Control Entity dtd) that has cognizance over the product or some
aspect of it.

###### Agreement-Contract-Data.dtd

The Agreement-Contract-Data dtd identifies the parties to a contract or
an agreement and provides the content relationships within the
*Contract* or the *Agreement.* The root element *Agreement-Contract*
consists of One or more (at least two) occurrences of *Trading Partner
Identification,* and one or more occurrences of either of the elements
*Contract* or *Agreement.*

The *Contract* element describes the content of a contract and the
relationships between the parts of the contract and the products, work
tasks, and data required by the contract. It consists of *Universal
Document Data* (which includes the document identification and revision
elements for the contract as described in 5.5), the *Program Project
Identification,* and the following elements:

-   *Contract Schedule*, a major part of the contract that identifies
    one or more occurrences of *Contract Line Item,* (CLIN)*,* which
    provides the *Product Identification* of the products that are
    ordered, and also includes a *Data CLIN Reference* that identifies
    any data line items

-   *Description*, which provides text describing the products or
    services to be provided under the contract that are listed as CLINS

-   *The elements:* Packaging-Marking*,* Inspection-Acceptance,
    Delivery-Performance, Administrative Data, *and* Special
    Requirements, *which detail any requirements in these categories.*

-   Contract Clauses, *providing standard contract verbiage, often
    containing provisions required by law. These fall into the
    subcategories of* Federal Acquisition Requirements, Defense
    Acquisition Requirements, *and* Other Standard Requirements.

-   List of Documents, Exhibits and Attachments *encompass the
    separately packaged items that are enclosed with the contract,
    including the* Statement of *Work (Defining the* Contracted Work
    Effort,*including the* Products *and* Data *Products that result
    from it and referencing a* Cited *Specification (invoking the
    Specification dtd) that relates the* Specification *Content
    consisting of the* Technical Requirements *and* Tests-Demonstrations
    *to verify those requirements*.

-   Exhibits-Data CLINS, *which provide the* Contract Data Requirements
    *that reference applicable* Data Item Description Identification

-   Representations and Instructions, *containing the assertions by the
    performing trading partner that it will meet the regulatory
    requirements required by the contracting trading partner.*

The *Agreement* element describes the content of an Agreement and the
relationships between the tasks, responsibilities, schedules and
processes that are agreed to by the trading partners. It consists of
*Universal Document Data*, *Program-Project Identification*, and
agreements on *Tasks-Responsibilities, Schedules, Data Exchange, Data
Protection*, *Change Process* (for maintaining the agreement) and
*Problem Resolution*.

###### ChangeControlEntity.dtd 

The Change Control Entity dtd defines the entity that has the authority
to make change control decisions. The root element *Change Control
Entity* is either a *Person* or a *Change Board* that may report to zero
or more *Higher*

*Authority Entity* (also a *Change Control Entity*), and has specific
(one or more occurrences of) *Control Authority.*

The *Change Board* element consists of the attribute *Change Board Type*
(which indicated whether the board is a voting or a non-voting board)
and the following the following elements:

-   *Change Board Name*, an identifying name for the change board

-   *Change Board Charter*, a written or implied charter delineating the
    boards purpose, membership, responsibilities and authority

-   *Change Board Chair,* the *Person* and related *Organization*
    responsible for the board

-   *Change Board Member*, a *Person* and related *Organization* who is
    a member of the board, and the person's specific role (represented
    by the element *Responsibility Text)*

The *Control Authority* element identifies the type of authority
exercised by the *Change Control Entity*, as delineated in the *Control
Authority Type* attribute (e.g., document change approval, product
change approval, etc.) and the *Control Domain* in which that authority
applies. *Control Domain* is comprised of the choice of repeatable
elements:

-   *Organization*, the authority applies across one or more
    organizations

-   *Program-Project Identification*, the authority applies to one or
    more programs or projects

-   *Product Identification*, the authority applies to one or more
    products

-   *Document Identification,* the authority applies to one or more
    documents

-   *Document Category*, the authority applies to one or more document
    categories.

## 5.3 Product Definition

The Product Definition schemas define and illustrate relationships of
the data elements that uniquely identify and provide the distinguishing
characteristics of products in a number of different product classes,
namely hardware, software, facility and document, and also define the
supporting engineering, manufacturing, quality and other processes.

###### Product.dtd

The Product dtd is an overarching schema, relating all the schemas
associated with product definition and product configuration. Its root
element is *Product,* which includes the elements *Product Class,
Process, and Product Configuration.* The element *Product Class*
categorizes products into *Hardware, Software, Facility,* and
*Document.* Each of these elements invokes a dtd for that product class,
as described below. It should be noted that EIA-649 also defines
Services as a product type or class. However, In the context of EIA-836
schemas, services are covered only as tasks associated with a contract
or trading partner agreement that are defined solely by a statement of
work.

The *Process* element, which could be considered as a product class in
its own right, is shown as a process that supports any of the other
product classes. It is also described in a dtd, below. *Product
Configuration,* links to the dtd's in 5.4

###### Hardware.dtd

The *Hardware* dtd covers hardware in the larger sense of the word,
essentially parts and materials, which encompass everything from a top
level system down to the lowest piece part, including those parts that
happen to be embedded software. The root element is *Hardware,* which
consists of a sequence of the following elements:

-   *Part-Material Identification* invokes the Part-Material
    Identification dtd, One or more times, accommodating the fact that a
    product may be uniquely identified by multiple sources

-   *Part-Material Name* is an element that provides the option to
    assign a name, where the unique part-material identification is an
    alphanumeric identifier, not a name.

-   *Part-Material Type*, an element of the oblet Product Type, which
    categorizes the Part-Material as for example, a Product, a Synthetic
    Part, a Configuration Item, an End Item, a Major Assembly, a Module,
    a Variant, a Modification Kit, an Altered Item, a Control Item, a
    Material Review Item, a Source Control item, a Vendor Control item,
    a Standard Part, or a number of other types (see definition).

-   *Make From* indicates a Part-Material Identification of a part or
    material that the *Part-Material Identifier* above is to be
    fabricated from.

-   The element *Stock Identifier*, of which there may be zero or more,
    is an additional identifier for the part or material that is used
    for stock keeping purposes. A part or material that is stocked by a
    number of different suppliers may have a separate Stock Identifier
    for each. This element is composed of the elements Stock Number
    Source and Stock Alphanumeric Identifier. (A common commercial stock
    identifier, that most shoppers can recognize is a SKU number that is
    bar coded on a product to be scanned at the cash register.)

-   The element *Part-Material Defining Document*, of which there may be
    one or more, defines the functional and physical design
    requirements, fabrication or construction instructions or test and
    acceptance inspection criteria for a part or material. These
    requirements may be contained in one or more *Document
    Identification* elements.

-   The element *Part-Material Status* contains a code used to indicate
    whether a product is active, obsolete or superseded by another
    product as reflected by the defining document(s).

-   The element *Part-Material Life*, which is optional, provides for
    specifying the projected part or material life expectancy that is
    identified by the *Service Life* and/or *Shelf Life* elements. If a
    part or material has a *Part-Material Life* it must have at least a
    *Service Life* or *Shelf Life* but may have multiple *Service
    Life*(s) and/or *Shelf Life*(s) depending on its *Part-Material
    Usage* and/or *Storage Environment* respectively.

```{=html}
<!-- -->
```
-   The element *Service Life*, of which there may be zero or more, is
    used to identify the service life for materials or parts. *Service
    Life* is defined by the elements *Part-Material Usage* and
    associated *Service Life Duration*. A part-material may have
    multiple *Service Life*(s) depending on *Part-Material Usage*.

-   The element *Part-Material Usage* defines the conditions under which
    the product service life period is applicable.

-   The element *Service Life Duration* has two attributes, *Service
    Life Period* and *Service Life Period Unit Code*, which provide the
    service life period and unit of measure, respectively.

```{=html}
<!-- -->
```
-   The element *Shelf Life*, of which there may be zero or more, is
    used to identify the shelf life for materials or parts. *Shelf Life*
    is defined by the elements *Shelf Life Duration* and associated
    *Storage Environment*. A part-material may have multiple *Shelf
    Life*(s) depending on *Storage Environment*.

```{=html}
<!-- -->
```
-   The element *Shelf Life Duration* has an attribute, *Shelf Life
    Code* that identifies the shelf life period.

-   The element *Storage Environment* defines the conditions under which
    the product shelf life period is applicable.

```{=html}
<!-- -->
```
-   The element *Special Handling*, which is optional, provides for
    identification codes that indicate special conditions or processes
    applicable for handling purposes. Special Handling Codes include but
    are not limited to Precious Metal, Hazardous Material, and Special
    Conditions Codes. If a part-material requires the element *Special
    Handling* it must contain at least one special handling code but may
    contain multiple codes.

```{=html}
<!-- -->
```
-   The element *Precious Metal Code* identifies precious metal (silver,
    gold, platinum) content in a part or material.

-   The element *Hazardous Material Code* identifies a hazardous
    material condition that requires special handling for environmental
    or safety reasons.

-   The element *Special Condition Code* identifies the special handling
    requirements for a part or material such as protection against
    Electrostatic Discharge*.*

```{=html}
<!-- -->
```
-   The element *Weight*, which is optional, provides for specifying the
    weight of material or a part.

-   The oblet *Packaged Product* provides for the processes and
    procedures used to protect a product from deterioration and/or
    damage during storage and/or shipment. This may include processes
    and procedures such as cleaning, drying, preserving, packing,
    marking, and unitization.

-   The element *Suitability For Use* identifies whether an item is
    appropriate for use in one or programs or products and refers to
    \"accreditation\" of an item; a certification by an individual or
    organization that an item is suitable for a particular use within a
    specific process or function.

###### Software.dtd

The *Software* dtd covers software, which encompasses everything from
the upper most system level architecture down to the lowest sub-routine,
including associated resources such as hardware, software, facilities,
documentation, tools, procedures and information used to perform
development, operation, test or maintenance of software. The *Software*
schema provides for identification, description, metadata and associated
documentation for a software product or item. The root element is
*Software*, which consists of a sequence of the following elements:

-   The element *Software Identification* is an oblet that provides the
    information needed to uniquely identify a software or database
    product. There must be at least one occurrence of *Software
    Identification* that is unique to a source but there may be multiple
    sources in the supply chain and therefore multiple (one or more)
    *Software Identification*(s). As seen in the Software Identification
    dtd, the unique identifier may a *Software Name* or *Software
    Alphanumeric Identifier* plus a *Software Version or Revision*
    identifier, all of which must be defined in conjunction with the
    *Software Identification Source* to provide uniqueness.

-   The element *Software Name* provides for an optional (zero or one)
    common usage identifier that distinguishes one software application
    from another.

-   The element *Software Documentation*, of which there may be zero or
    more, provides for *Document Identification* of each document
    associated with the software product that define the functional,
    performance and physical requirements and provide software
    description(s) plans, specifications, test plans and user manuals
    necessary to support the product life-cycle including development,
    operation, maintenance and test.

-   The element *Software Defining Document*, \[which appears in the
    schema is redundant with Software documentation and will be deleted
    in the next Rev.\]

-   The element *Software Domain* describes the functional domain of the
    software. Examples include, but are by no means limited to:
    Programming Language, Database, Integrated Development Environment,
    Middleware, Modeling, Operating System, Graphical User Interface,
    Presentation, Simulation, Spreadsheet, Utility and Word Processing

-   *SoftwareType*, an element of the oblet Product Type, describes the
    discrete and identifiable levels of software decomposition for
    purposes of development, configuration management, and delivery.
    Examples include, but are by no means limited to: Computer Software
    Configuration Item (CSCI), Software End Item, Software Unit,
    Computer Software Component, Test Unit and Software Module.

-   The oblet *Packaged Product*, provides for the processes and
    procedures used to define packaging and labeling of the software
    product.

-   The element *Software Environment* identifies the collection of
    resources such as software, hardware, facilities, documentation,
    tools, procedures and information used to perform development,
    operation, test or maintenance of software. Typical elements include
    computer equipment, compilers, assemblers, operating systems,
    debuggers, simulators, emulators, test tools, documentation tools,
    and database management systems. *Software Environment* has one
    attribute, *Software Environment Type*, and the following data
    elements: *Required Operating System, Required CPU, Required Memory,
    Required Tool, Required Database, Required Protocol and Web
    Browser.*

```{=html}
<!-- -->
```
-   The attribute *Software Environment Type* specifies the type of
    environment. The valid domain values are: Host, Target, Test,
    Development, Maintenance

-   The element *Required Operating System* provides for identifying the
    metadata for the collection of software and firmware that controls
    the execution of computer programs. The metadata is identified in
    the subordinate element *Software Identification*, of which there
    may be one or more.

-   The element *Required CPU* provides for identifying type and speed
    of CPU required in a software environment in contained elements *CPU
    Type* and *CPU Speed* respectively.

-   The element *Required Memory* has the attribute *Memory Type* that
    describes the type of random access memory e.g. DRAM, SRAM and
    contains the elements *Min Memory* and *Recommended Memory* that
    describe the minimum and recommended amount of memory needed in a
    software environment.

-   The element *Required Tool*, of which there may be zero or more,
    contains the element *Software Identification*, of which there may
    be one or more, that identifies the software tool(s) required in a
    software environment.

-   The element *Required Database*, of which there may be zero or more,
    contains the element *Software Identification*, of which there may
    be one or more, that identifies the database software required in a
    software environment.

-   The element *Required Protocol*, of which there may be zero or more,
    contains the element *Protocol Defining Document*, of which there
    may be one or more, that provides for identifying the metadata for
    the required set of conventions that govern the interaction of
    processes, devices, and other components within a software
    environment. The metadata is identified in the subordinate element
    *Document Identification*.

-   The element *Web Browser*, of which there may be zero or more,
    contains the element *Software Identification*, of which there may
    be one or more, that identifies the Web Browser software required in
    a software environment.

The *Product Protection* oblet contains subordinate oblets that are
associated with intellectual property rights, security, export control,
and licensing.

###### Process.dtd

The *Process* dtd provides for identification, description and other
metadata for a process that is defined as is a series of operations used
in the manufacture or assembly of a product, typically in accordance
with a documented standard or procedure. *Process* is the root element
of the schema, which consists of a sequence of the following elements:

-   The element *Process Identification* provides for the unique
    identification of a Process. Identification information includes the
    element *Process Identifier* which contains: a choice between the
    elements *Process Name* or *Process Alphanumeric Identifier*, an
    optional element *Process Revision,* and the *Process Identification
    Source* element, identifying the design activity or other entity
    (person or organization) that assigns the identifier to a process.

-   The element *Process Name* provides for an optional common usage
    identifier that distinguishes one process from another.

-   The element *Process Type*, of which there may be zero or more,
    provides the ability to categorize processes into types. Examples of
    types of processes include but are not limited to Quality,
    Manufacturing, Engineering, Test, and Inspection.

-   The element *Process Defining Document*, of which there may be zero
    or more, provides the oblet Document Identification, for each of the
    one or more document(s) that define the process.

-   The element *Skill Level* describes the knowledge and ability of
    personnel required to perform a task or process, which may be
    expressed as a class or other qualification indicator.

    The element *Process Related Product*, which is optional (0:1)
    \[should change to optional and repeatable (zero or more) -- next
    rev\] provides for identification of a product that is necessary for
    the application of a process. *Process Related Product* contains the
    element *Product Identification*, of which there may be one or more,
    that provides the metadata identifying the product. An example of a
    process related product is the test equipment needed to conduct
    tests of a product.

###### Facility.dtd 

The Facility schema contains the data elements and their relationships
to uniquely identify, locate, describe, and define/identify interfaces,
both external to the Facility and internal within the Facility. The
Facility schema contains the oblet [Facility
Identification](../../../../../../../../C:/WINDOWS/Desktop/#FacilityIdentification)
dtd that is repeatable if a Facility is uniquely identified by multiple
sources (e.g. Johnson Space Flight Center, Launch Facility 201, Houston,
Launch Control). The *Facility Name* element provides the option to
assign an additional but non-unique name to a Facility.

The schema contains the Address oblet and data elements for *Facility
Type*, *Facility External Environment*, *Real Property*, and *Supporting
Facility*.

-   The *Facility Type* element provides a designation as to the use of
    a facility (e.g. production, launch, integration).

-   *Facility External Environment* is optional depending on the
    importance of its impact on the facility and facility-installed
    equipment. It defines the natural and induced conditions experienced
    by the facility, including its people, products, and processes
    (desert, polar, swampy, temperature, humidity, dust level).

-   *Real Property* contains the information needed to describe the
    physical Facility, its contents, and define/identify interfaces.
    *Real Property* contains the optional (zero or one) data elements
    *Real Property Installed Equipment* and *Volume Plan* and the
    sequence of data elements *Infrastructure,* *Site Floor Plan* and
    *Physical Structure.*

```{=html}
<!-- -->
```
-   Real Property Installed Equipment is made-up of the data elements
    Systems, Subsystems, and Facility-System Interfaces.

-   Facility-System Interfaces are defined in a Product Requirements
    Object that addresses all of the applicable attributes contained in
    Facility-System Interface Type (e.g. cooling, communications,
    temperature) and Special Requirements Type (e.g. safety, hazardous
    material, cleanliness).

-   Infrastructure is defined in a Product Requirements Object that
    addresses all of the applicable attributes contained in
    Infrastructure Type (e.g. heating, ventilation, air conditioning).

The data element *Supporting Facility* is optional and repeatable,
providing the ability to uniquely identify, locate, describe, and
define/identify interfaces for a supporting facility. *Supporting
Facility* is recursive containing the element Facility and all
associated data elements.

## 

## 5.4 Product Configuration

The Product Configuration schemas are an extension of the Product
Definition schemas that define the data elements and information
relationships describing product configuration from both a configuration
baseline perspective and a product structure perspective. They also
define and enable tracking of the configuration of each product instance
throughout its life cycle.

###### ProductConfiguration.dtd

The Product Configuration dtd provides several views of product
configuration. One view is the *Configuration Baseline Perspective*.
Another view is the *Product Structure Perspective*. Since baselines are
defined by ANSI/EIA-649 as a set of documents, the baseline perspective
is essentially a document-centric view. The *Product Structure
Perspective* is essential a product component/part centric view. In
addition to those two perspectives, the Product Configuration schema
includes the *Product Instance Configuration,* which is a view of the
actual product configuration of a product that has been built as opposed
to the intended configuration represented by the *Configuration
Baseline* Perspective and *Product Structure Perspective*.

The *Baseline Perspective* consists of the date of the baseline (because
all baseline reflect the configuration of a product as of a point in
time), and a choice of the following different general categories or
classes of baselines, each of which consist of choices of one or more of
different baselines within that category:

-   *Conceptual baseline* is left rather undefined because of the wide
    variety of different types of documents that may be included during
    the conceptual phases of a program or project.

-   The *Requirements Baselines* are all conceptually the same, but each
    of the baselines has a slightly different connotation.

```{=html}
<!-- -->
```
-   The Requirements Baseline is a generic baseline consisting of one or
    more Product Requirements Objects such as Specifications or
    Requirements Documents

-   The *Functional Baseline* and *Allocated Baseline* are common
    terminology in the CM domain. *Functional Baseline* consists of a
    repeatable set of elements: A qualifying *Functional Baseline Type*
    element, which tells whether the baselined document type is a system
    specification, top-level specification, requirements specification,
    requirements document, etc and *Product Requirements Object* (See
    Document dtd).

-   Similarly, the *Allocated Baseline* is defined by one or more
    *Product Requirements Objects* and the *Allocated Baseline Document
    Type,* which provides an enumerated list such as the subsystem
    specification, product specification, software requirements
    specification, etc.

```{=html}
<!-- -->
```
-   The *Product Development Baselines* include the baselines used
    internal to the development organization to maintain information
    about the product at specific milestones or events. They include the
    Design Release Baseline or a Planning-Process Baseline where,

```{=html}
<!-- -->
```
-   The *Design Release Baseline* may include a *Release Record*, one or
    more Engineering Design Objects, and one or more *Engineering Change
    Documents*. The *Engineering Change Document* (EO, ECN, ECR, etc.)
    is used by a trading partner to describe an engineering change that
    typically addresses a change to a *Product Requirements Object* or
    an *Engineering Design Object*.

-   The *Planning Process Baseline* is a baseline option that reflects
    the complete expectation for a product is to be manufactured, or in
    the case of Software to be created or coded. As such, it encompasses
    the *Design Release Baseline*, one or more occurrences of
    *Manufacturing Plan*, and one or more *Process Defining Documents*
    for product. See the Manufacturing Plan Business Object for the
    content of the *Manufacturing Plan*.

```{=html}
<!-- -->
```
-   The *Product Baselines* are a collection of various product baseline
    types, such as *Product Baseline*, *As Built Baseline*, *As Shipped
    Baseline*, etc, as indicted by the *Product Baseline Type* element.
    In addition, each of the types within *Product Baselines* consists
    of one or more of each of the following types of objects: *Products
    Requirements Objects* (specifications or requirements documents),
    *Engineering Design Objects* (engineering drawings or models) and
    *Process Defining Documents*. All of the product baseline types may
    be thought of as as-built baselines in that they reflect the actual
    configuration of a real (as opposed to a conceptual or planned)
    product at a particular point in time. The types *Product Baseline*
    and *Technical Data Package* consist of the total list of all
    documents that pertain to the product at the time of the baseline.
    Others, such as *As Delivered*, *As Installed*, etc., include those
    that pertain to the particular product instance.

-   The *Operational Baseline* reflects the documents that are used to
    operate (*Product Operation Object*) and maintain (*Product
    Maintenance Object*) a product that is in operational use, examples
    are operation manuals and maintenance manuals, illustrated parts
    breakdown manuals etc.

The *Product Structure Perspective* may consist of a view of the *As
Designed Product Structure* (the detailed product composition at the
time the design is released) or the *As Planned Product Structure*
(which also includes the manufacturing requirements and identifiers
associated with the to-be created and installed or attached product).
These two product structure views are described in the As Designed
Product Structure dtd and As Planned Product Structure dtd,
respectively. (See Below.)

The *Product Instance Configuration,* which is a view of the actual
product configuration of a product that has been built. It consists of
*As Of Date* or *As Of Event*, or both, *As Built Configuration*
(described in the As Built dtd), which is a common core of all the
*Product Instance Configuration* choices, and a choice of one of the
following (all of which are additive to the core As Built
Configuration):

-   *As Maintained-Modified Configuration* *(*described below under *As
    Maintained-Modified Configuration dtd)*

-   *As Operated Configuration* (See Definition)

-   *Mission Configuration* (See Definition)

-   *As Received Configuration* (See Definition)

-   *As Tested Configuration* (See Definition)

-   *As Installed Configuration* (See Definition)

-   *As Delivered Configuration* (See Definition)

-   *As Disposed Configuration* (See Definition)

###### AsDesignedProductStructure.dtd 

A product structure is typically thought of as a tree structure (see
Figure 5.4-1) reflecting parent-child relationships of the entire
structure of a product from its highest assembly to its lowest
component.

![](media/image4.wmf){width="2.3097222222222222in" height="1.725in"}

**Figure 5.4-1 Typical Product Structure View**

::: Definition-Term
The As Designed Product Structure dtd treats the product structure as a
snapshot of a repeatable portion of the traditional tree structure,
looking at a specific product, referred to as the *Product In Focus*,
its component products, and its next higher products. The schema, from
which the traditional tree structure can be derived by viewing each
higher or component product as a *Product In Focus* that has upward and
downward pointers, affords the opportunity to show the relationships of
significant CM information associated with each product.
:::

The As Designed Product Structure dtd root element *As Designed Product
Structure* has three subordinate elements:

-   Zero or more *Next Higher Product* (zero if the *Product In Focus*
    is a standalone product or is the end item)

-   The *Product In Focus*

-   Zero or more occurrences of the element *Product Component*.

The *Next Higher Product* element contains the *Product Identification*
of the *Next Higher Product* and its *Product Type*; and the effectivity
and quantity of the *Product In Focus* as reflected in the elements
*Product Effectivity Per Next Higher Product* (a role of Effectivity)
and *Product Quantity Per Next Higher Product**, ***(a role of Product
Quantity), respectively.

The *Product In Focus* element contains the *Product Identification* of
the Product In Focus, its *Product Type**, ***and the container element
*Related Configuration Management Information*, which in-turn provides
information related to the *Product In Focus* concerning zero or more
occurrences of *Engineering Change*, *Approved Variance*, *Product
Tracking Requirement*, and *Allowable Alternate or Substitute Products*.

The *Engineering Change* element has an attribute *Change
Classification* indicating whether the change classification is Class I
or Class II, Major or Minor, or Significant or Insignificant, depending
on government or industry trading partner practice. This element
identifies:

-   One or more occurrence of *Product Requirement Object* or
    *Engineering Design Object* elements, or both, to which the
    engineering change is addressed,

-   One or more occurrences of the *Change Authority* element, which is
    composed of an attribute identifying the *Change Authority Type*
    that authorizes the change and one or more occurrences of elements
    *Document Identification* (which identifies the document) and/or
    *Change Control Entity* that provides the authority.

-   A *Change Effectivity* element, which is composed of zero or more
    occurrences of *Affected Document* (tabulating the documents that
    must be changed as a result of the engineering change), the
    *Effectivity Base Product* (identifying the product to which
    effectivity tracking identifiers are assigned), and the *Production
    Effectivity* and/or *Retrofit Effectivity* of the change,

-   One or more occurrences of *Engineering Change Document*. It has an
    attribute identifying the *Engineering Change Document Type* (e.g.,
    EO, ECN, ECO, etc.) and is composed of: a sequence of elements
    relating to the *Engineering Change Document* and its content:

```{=html}
<!-- -->
```
-   The *Document Identification* element for the engineering change
    document,

-   The *Release Date* element indicating the that the engineering
    change document was released,

-   The *Change Description Was Is* element providing the before and
    after description of the change,

-   One or more occurrences of the *New Product* element, where
    applicable, (including its *Product Identification, New Product
    Effectivity* and *Product Interchangeability*, indicating whether it
    is interchangeable,

-   The *Replaced Product* element indication the product that is
    replaced, as applicable, including a *Parts Made Disposition*
    attribute indicating whether parts already made in the old
    configuration can be reworked, the *Product Identification*, and
    *Revised Effectivity* of the replaced part,

-   And *Affected Document* (the document affected by the change, which
    would typically be the engineering design object).

```{=html}
<!-- -->
```
-   There may be zero or more *Approved Variances* (see the Variance dtd
    oblet) associated with the *Product In Focus.*

-   The *Product Tracking Requirement* element provides a *Tracking
    Identifier Prefix* (e.g., serial number). There are zero or more
    occurrences of this element (zero indicates that a tracking
    identifier is not required); there may be more than one *Tracking
    Identifier* required (e.g., both serialization and lot control). The
    *Product Tracking Requirement* also includes the *Traceable Item*
    element, which indicates by a yes/no (true/false) choice whether the
    *Product In Focus* is designated as a *Traceable Item* (its product
    instances are to be traced through higher level products to the
    ultimate end item).

-   There may be zero or more *Allowable Alternate or Substitute
    Products* that may be used in lieu of the *Product In Focus*.

The *Product Component* element identifies the zero or more components
of the *Product In Focus.* It consists of the *Product Identification*
for the product component, the *Product Type* of the *Product
Component*, and the *Component Quantity Per Product* (quantity of
component that is installed in, attached to, or forms a part of the
*Product In Focus*). It also includes zero or more *Allowable Alternate
or Substitute* parts for the *Product Component*, when used in the
*Product In Focus*.

###### AsPlannedProductStructure.dtd

The As Planned Product Structure dtd content model parallels the As
Designed (i.e., same parent-child element relationships) with several
notable exceptions. The Next Higher Product, Product In Focus and
Product Component equivalent elements in this dtd are prefixed with
"mfr". This prefix indicates that, although the product identification
values in these elements may be the same as the values in the As
Designed Product Structure, they may also vary because of manufacturing
and assembly and construction considerations, such as the use of
temporary or synthetic parts or assemblies (see definition). The other
difference is the inclusion of the *Manufacturing Plan* element related
to the *Mfr Product In Focus* element. The *Manufacturing Plan*
essentially details the work instructions for creating, reworking, or
assembling the product. (See the *Manufacturing Plan* Business Object).
In addition, the *Mfr Product In Focus* element does not contain the
*Related Configuration Management Information* that is contained in the
As Designed Product Structure's *Product In Focus* element.

###### AsBuiltConfiguration.dtd

The As Built Configuration schema defines the configuration of an
instance of a product that has been manufactured (or coded) and/or
installed in a higher product. The As Built Configuration dtd has *As
Built Configuration* as its root element. Its content model consists of
the element *Product Instance* and the sequence of elements *Product
Type*, *Product Instance Mfr*, and zero or more occurrences of *Product
Instance Install*:

The *Product Instance* element reflects what instance of the product the
as built record represents.

The *Product Type* element invokes the Product Type dtd oblet.

The *Product Instance Mfr* element, consists of a sequence of elements
that provide configuration information relating to the manufacture of
the product instance:

-   *Manufacturing Plan Identification*, which provides the Document
    Identification for the Manufacturing Plan,

-   A *Completed* attribute of the Manufacturing Plan provides status as
    to whether the it has been satisfactorily implemented in the product
    instance,

-   The *Manufacture Date* (the date that the manufacturing plan was
    completed),

-   An optional *Product Quantity* element used when the product
    instance is a lot or batch,

-   An optional enumeration of the *Product Instance Status*, which
    indicates the current as-built condition of the product instance
    (e.g., in-work, pending, completed, destroyed, etc.),

-   Zero or more occurrences of *Product Instance History* to enable
    capture of any changes to the as-built configuration of the product
    instance or record any pertinent information, It consists of prior
    occurrences of *Product Instance Status*, the associated *Status
    Date*, and a String element *Note*.

-   The *Difference From As-Designed* element, which provides a means of
    recording an optional text description, and a set of choices of
    various types of differences from the as-designed configuration of
    the product:

```{=html}
<!-- -->
```
-   The actual *Alternate Or Substitute* (i.e., Product Instance) that
    has been used in place of the as-designed item,

-   An *Approved Variance* that applies to the instance of the product
    that is manufactured. It consists of the *Request For Variance* (a
    business object) and the *Approval Document* that approved the
    request.

-   Any *Associated Material Review Report* that relates to the
    particular product instance, consisting of The *Material Review
    Report* element itself and an optional *MRR Part Identification*
    element that would be used where a unique MRR identifier is assigned
    to the item.

-   An optional *Other Authorization* string element that may be used to
    reflect unique user organization means of authorization.

The *Product Instance Install* element reflects the installation of the
as-built product instance into a higher product. It consists of:

-   *Installed in Higher Product* element, which indicates the instance
    of the higher product in which the installation or assembly takes
    place,

-   Zero or more occurrences of the *Installation Zone-Location*
    element, (used when there are multiple installation points for lot
    controlled item and traceability by location is required),

-   *Manufacturing Plan Identification*, citing the work instructions
    for the installation, with the same composition as in the *Product
    Instance Mfr* element,

-   The following installation elements, which may be repeatable:
    *Installation Date, Installed By, Verified By*. Note that
    *Installation Date* includes the time of installation.

-   And the following *optional and repeatable removal elements: Removal
    Date, Removed By* and *Reason For Removal. Removal* *Date* also
    includes the time of removal, allowing for multiple installations
    and removals in the same day.

###### AsMaintained-ModifiedConfiguration.dtd

The As Maintained-Modified Configuration schema reflects changes that
are made to the product after it is put into service (entered into the
operation and maintenance phase of its life cycle) as a result of
maintenance action or as a result of modifications issued in kit form
for retrofit installation or incorporation in the product. The As
Maintained-Modified Configuration content model contains:

-   A sequence of elements that identify:

```{=html}
<!-- -->
```
-   The *Product Being Modified Or Replaced*, either by incorporation of
    a new product or by rework of the product to a new configuration is
    identified by the *Product Instance* (See Product Instance oblet)
    and *Product Type* (See Product Type oblet) elements,

-   The *Replacing Or Re-identified Product* is identified by the
    element *Product Instance*, which is assumed to be the same product
    type as the product it replaces,

-   An optional (Zero or one) *Installed In Next Higher Product*,
    identifying the next higher product for the product that is being
    modified or replaced,

-   The element *Maintenance-Mod Location* indicating the location at
    which the maintenance or modification action is to be effected,

```{=html}
<!-- -->
```
-   And a choice between the elements *Maintenance Replacement* and
    *Retrofit*

```{=html}
<!-- -->
```
-   If the choice is *Maintenance Replacement*, the *Replacement Date*
    element indicates when the replacement took place, the *Replaced By*
    element indicates the *Person* and *Organization* who performed the
    replacement, and *Reason For Replacement* indicates why the
    maintenance replacement was necessary.

-   If the choice is *Retrofit*, the *Mod Kit Identification* element
    provides the product identification of the kit used for retrofit,
    the *Date Installed* element provides the date of installation, the
    *Installed By* and optional *Verified By* elements tell who
    installed and who validated the kit installation. In addition, the
    *Variances Noted* element provides zero or more notations concerning
    anomalies or conditions that may require attention.

## 5.5 Document

The Document schemas define and show the relationships of the data
elements concerning documents and document representations in general,
and specific documents that are used in the definition and control of
product configuration.

###### Document.dtd

The Document dtd is a container, linking to all of the document schemas,
which contain metadata pertinent to configuration management for
specific categories of document "objects," a Generic Document (any
referenced document), and also linking to the set of CM Business Objects
(Section 6). The Universal Document Data dtd, which contains metadata
common to all documents, is included within each of the document
schemas.

The *Document* root element provides choice of the elements *Product
Requirements Object, Engineering Design Object, Product Operation
Object, Product Maintenance Object, Generic Document, and Business
Objects. Business Objects* links to the dtds in Clause 6. The *Generic
Document* simply includes the *Universal Document Data*. The other
elements are described in their individual dtds, as follows:

###### UniversalDocumentData.dtd

The Universal Document Data dtd is a schema that is common to all
documents. It provides all of the metadata that is necessary to identify
a document, and the files that comprise a representation of the
document. It also provides additional optional metadata concerning
document management. This schema is invoked in lieu of repeating its
elements for each type of document dtd. The root element *Universal
Document Data* consists of the following elements:

-   *Document Identification* (See the Document Identification dtd
    oblet)

-   *Document Representation,* which invokes zero or more *File*
    elements (see File.dtd oblet) to identify and provide information
    about all the files that comprise the document

-   An optional *CDCA* *(Current Document Control Authority)* element
    that identifies the organization that has the sole authority to
    effect changes to the document

-   Zero or more occurrences of *Associated Product Identifier*, to
    identify products to which the document is related

-   Zero or more occurrences of *Related Document Identifier*, to
    identify other documents to which the document is related

-   Optional *Sheet-Page Management*, to accommodate those documents
    with single or multiple sheets, or pages that must be separately
    change controlled. A total sheet count shall be provided (one (1)
    would the default value.) For each sheet or page being managed, a
    change type of Add, Change, or Delete is indicated. The page number
    within the grouping (one (1) again is the default) will be required
    along with zero or one sheet or page size. One or more page
    revisions and representations combinations are included in the
    management of sheets/pages.

-   Zero or more occurrences of *Revision Authorization Identifier,*
    which cites the document or entity that authorized a revision to the
    document

-   Zero or more invocations of the Product Protection oblet, which in
    turn provides selection of applicable protection oblets such as
    Security, Data Rights, Distribution Restriction, etc.

###### ProductRequirementsObject.dtd

The Product Requirements dtd refers to a class of documents that define
requirements for a product. It identifies the *Release Date* of the
Document and provides a choice between *Requirements Document* (defined
by the *Universal Document Data* element and *Specification* (see
Specification.dtd).

###### Specification.dtd

The Specification dtd consists of the elements *Specification Type*
(which categorizes a specification into one of the many different types
of specifications that are typically used in relation to a product) and
the *Universal Document Data*.

###### EngineeringDesignObject.dtd

The Engineering Design Object dtd refers to documents that completely
define the design of a product. It identifies the *Release Date* of the
Document and provides a repeatable choice (one or more) between
*Engineering* *Drawing, Part Model*, and *Associated List*, where:

-   *Engineering Drawing* consists of the *Universal Document Data* and
    a series of optional attributes that identify the *Drawing Type*
    (reflecting the purpose of the drawing), *Parts List Type* (whether
    the parts list is integral to the drawing or separate), *Drawing
    Category* (a categorization for purposes of assembling a defense
    technical data package), and *Detail Type* (which indicates either a
    mono-detail or multi-detail drawing).

-   *Part Model* consists of an attribute *Part Model Type* (which
    denotes the type of digital model representation of a product), one
    or more *File* elements (invoking the File dtd oblet for each file
    comprising the model), and *Universal Document Data*.

-   *Associated List* refers to one of the several types of lists that
    are related to an *Engineering Drawing* or *Part Model*. The element
    contains an attribute *Associated List Code* that indicates the type
    of list (e.g., Parts List, Index List, Data List, etc.), *Universal
    Document Data*, and zero or one occurrence of *Parts List*. *Parts
    List* contains significant information elements of concern to
    configuration management, as follows:

```{=html}
<!-- -->
```
-   *Part-Material Identifier*, which provides the identity of a part or
    material

-   *Find Number*, which locates the part or material on the field of an
    engineering drawing

-   *Nomenclature-Description*, which provides the name of the part or
    material or a short description

-   *Quantity*, which indicates how many of the part or material are
    used

-   *Next Higher Product*, which indicates the higher product in which
    the part or material is effective.

```{=html}
<!-- -->
```
-   *Drawing Note*, a statement adding clarification to an engineering
    design object. This element is attached to the *Engineering Design
    Object* and stated only once rather that repeat it three times, as
    Notes may be physically recorded on the *Engineering Drawing*,
    within a *Part Model*, or on a *Parts List*, in accordance with
    individual trading partner practice.

###### ProductOperationObject.dtd

The *Product Operation Object* refers to a class of documents that
provide instructions for operating a product. It identifies the *Release
Date* of the Document and *Universal Document Data.*

###### ProductMaintenanceObject.dtd

The *Product Maintenance Object* refers to a class of documents that
provide instructions for maintaining a product. It identifies the
*Release Date* of the Document and *Universal Document Data.*

## 5.6 CM Actions

The CM Actions schemas define and show the relationships of data
elements that derive from and support configuration management actions
in performing a broad range of CM and data management functions, such as
managing configuration documentation and engineering changes,
maintaining related status, managing action items, conducting
configuration audits, reviewing, releasing and approving documents,
documenting change decisions and implementing changes.

> **NOTE:** THIS SECTION IS INCOMPLETE. ONLY THOSE CM ACTION SCHEMAS
> THAT HAVE BEEN COMPLETED AT THE TIME OF THIS DRAFT ARE FULLY
> DESCRIBED. TO ILLUSTRATE THE FULL SCOPE OF THE STANDARD, OTHERS THAT
> WILL BE ADDED IN LATER DRAFTS, ARE PROVIDED AS PLACEHOLDERS

###### 

###### CMActions.dtd

The CM Actions dtd is a container schema for the set of reference
schemas concerning the informational elements and relationships
supporting configuration management functional activities. \[Many of the
dtds listed below are placeholders for dtds to be added in the next
revision.\]

###### ActionItem.dtd

The action item dtd provides a generic action item tracking and
accountability capability that has wide applicability. It becomes a part
of several of the schemas in EIA-836, where these capabilities are
required. The root element *Action Item* provides for the assignment of
an action resulting from an audit, meeting or other activity. It
consists of:

-   *Action Item Number*, the identifier used as a unique reference for
    an action item.

-   *Action Item Title*, the name or title of an action item.

-   *Action Assignment*, the designation of (one or more) *Organization*
    and/or *Person* as responsible for completing an action item, the
    *Assignment Date* \[To be added Next Rev\], *Responsibility
    Accepted*, an acknowledgement that responsibility for an action item
    is accepted by the organization and/or person assigned the action
    item, and *Responsibility Date*, the date that the responsibility
    was accepted.

-   *Action Item Description*, which consists of

```{=html}
<!-- -->
```
-   Action Item Description Text,

-   Zero or more occurrences of *Affected Product*, a role of product
    identifier that uniquely identifies a product to which an action
    item is related,

-   Zero or more occurrences of *Discrepancy Citation*, A reference to a
    document, citing a particular portion (e.g., paragraph number), and
    describing the discrepancy from the requirements of that citation.
    It consists of *Document Identification*, *Document Citation* (the
    particular section or paragraph), and *Discrepancy Description*
    (text description of the discrepancy),

-   And optional Recommended Solution.

```{=html}
<!-- -->
```
-   *Action Completion Due Date*, the date when recommended action item
    is to be completed.

-   Zero or more occurrences of *Related Action Item Number,* another
    action item that may have some bearing on the subject action item,
    such as an action item dealing with a subordinate issue.

-   *Action Item Comment*, a notation concerning the action item.

-   *Action Item Resolution,* documenting actions taken to complete an
    action item including:

```{=html}
<!-- -->
```
-   *Close Out Document*, zero or more document(s) used to close out an
    action item.

-   *Action Description*, a description of action taken,

-   If applicable, *Action Completion Verification*, confirmation by a
    third party source that the action was successfully completed, and

-   Any pertinent *Resolution Comments* concerning the completion of a
    required action.

```{=html}
<!-- -->
```
-   *Action Item Status* and associated attribute *Action Item
    Disposition Code* an indicator of the status of completion of an
    action item as of a given *Action Item Disposition Date*.

###### SelectingConfigurationItems.dtd

The Selecting Configuration Items dtd will be added in the next
revision. It will provide the information elements and relationships
concerned with the process of choosing which items in a product
hierarchy to designate as Configuration Items.

###### AssigningTrackingIdentifiers.dtd 

The Assigning Tracking Identifiers dtd will be added in the next
revision. It will provide the information elements and relationships
concerned with the process of assigning tracking identifiers such as
serial numbers or lot numbers against an effectivity base product to the
instances of a product.

###### NumberingProducts-Documents.dtd

The Numbering Products and Documents dtd will be added in the next
revision. It will provide the information elements and relationships
concerned with the process of assigning identifiers to products and
documents.

###### DocRelease-Review-ApprovalStatus.dtd

The Document Release, Review and Approval Status dtd provides the
information elements and relationships involved in the data management
processes of document release, document review (including the management
of comments), document approval and maintaining document status. The
root element *Doc Release-Review-Approval Status* consists of the
following elements:

-   *Document Identification*, which invokes the Document Identification
    oblet,

-   *Document Release* a current status of a document representation
    revision indicating that it is released for use, approval, review,
    or other stated purpose. It consists of the following elements:

-   Zero or more occurrences of the element *Release Limitation*, which
    delineate limitations connected with the release of a document,
    e.g., release may be limited to use for specific actions only.

-   The *Release Status* element has an attribute *Release Status Code*
    (In Work, In Review, Release, Rejected), and an element *Release
    Status Date* (the date at which that status occurred).

-   The optional *Next Status* element, used to indicate the next
    workflow event in the release process with the attribute *Next
    Status Code* (In Work, In Review, Release) and the element *Next
    Status Suspense Date* (the date scheduled for the next event)

-   The optional element *Baseline Affected*, which indicates the
    baseline that the document is related to, if any,

-   And a repeatable choice of elements defining the purpose of the
    document release (i.e., it could be for a number of purposes), which
    include

```{=html}
<!-- -->
```
-   *For Release* \[will be changed to "For Use" in next Rev\] (which
    means for the intended use of the document),

-   *For Review*, which contains all the elements and attributes
    associated with the document review process, including

```{=html}
<!-- -->
```
-   *Document Review Requirements*, which has a required attribute
    defining the Type Of Review (Peer, Pre-Release, Application
    Activity, User, Approval Authority, or Other) and is composed of
    zero or more Contract Identifier and, Data Item Identifier elements
    and the Comments Due Date element.

-   *Draft Document Revision Representation Identifier*, a string
    element that provides a unique identifier to the representation of
    the draft offered for review, that can be iterated for successive
    drafts, without causing the revision identifier of the next revision
    to be advanced until a draft revision representation has finally
    been approved for release

-   One or more occurrences of *Reviewer Identifier*, a Person, with the
    attribute Reviewer Role (Peer, Superior, Subordinate, User,
    Application Activity, Lead Application Activity, CDCA, Interested
    Party)

-   An optional string element *Reviewer Recommendation*, to capture a
    reviewers recommendation as to whether the document should be
    approved or disapproved, or other appropriate recommendation

-   Zero or more comments represented as the *Comment File Identifier*
    element, which is the filename of a file containing one or more
    occurrences of *Document Comment*. The Document Comment element
    includes all the information related to the content of a comment,
    and review and disposition of the comment; it consists of:

```{=html}
<!-- -->
```
-   *Comment Identifier*, a string element providing for a comment
    number or other identification

-   *Comment Date*, the date of the comment

-   *Comment Reference*, a string element citing the page, section,
    paragraph, line, figure, table or other portion of the document that
    is the target for the comment.

-   *Comment Text*, a string element for the text of the comment

-   *Comment Justification*, a string element for the reason for making
    the comment

-   *Comment Status*, an indicator of the status of the comment with
    respect to its review and disposition, as defined by the attribute
    *Comment Status Code* (Approved, Approved With Changes, Rejected, or
    Deferred

-   And optionally, *Comment Dispositioned By*, the *Person* who
    dispositioned the comment, *Comment Disposition Date*, *Comment
    Disposition Rationale* (a reason why a comment was rejected), and
    *Comment Incorporation Note* (a reference to the revision of the
    document that an accepted/approved comment is planned to be
    incorporated in.

```{=html}
<!-- -->
```
-   *For Document Authority Approval*, a reason for release indicating
    that a document representation is to be submitted for approval, is
    embodied in the required attribute *Document Approval Status*
    (resubmit, submit, approved, approved with changes, disapproved, or
    deferred), and the element *Document Approval Authority*, which
    invokes the *Entity* oblet to denote the person or organization with
    the authority to approve the document.

-   For Archiving

*Document Revision Approval* \[To Be Changed in next Revision to
Document Revision Approval Status\] show is the status of the Current
Change Control Authority (CDCA) approval process relative to a document
revision submitted for formal approval. It consists of:

-   *Approval Status* \[Change cardinality to + in next Rev\] which
    contains the element *Approval Status Date* and the attribute
    *Approval Status Code* (In-Work, Submitted, Approved, Approved With
    Changes, Or Disapproved)

-   \[To be deleted in next Rev\] Zero or one occurrences of the element
    *Next Approval Status* which contains the element *Next* *Approval
    Status Suspense Date* and the attribute *Next* *Approval Status
    Code* (Submitted, Approval

###### IdentifyingNeedForChange .dtd

The Identifying Need For Change dtd will be added in the next revision.
It will provide the information elements and relationships concerned
with this portion of the change management process

###### RequestingChangeOrVariance.dtd

::: Definition-Term
The Requesting Change Or Variance dtd will be added in the next
revision. It will provide the information elements and relationships
concerned with concerned with this portion of the change management
process
:::

###### Classifying Changes.dtd

The Classifying Changes dtd will be added in the next revision. It will
provide the information elements and relationships concerned with
concerned with this portion of the change management process

###### ChangeImpactAssessment .dtd

The Change Impact Assessment dtd will be added in the next revision. It
will provide the information elements and relationships concerned with
concerned with this portion of the change management process

###### DeterminingChangeEffectivityAndCost.dtd

The Determining Change Effectivity And Cost dtd will be added in the
next revision. It will provide the information elements and
relationships concerned with the concerned with this portion of the
change management process

###### ChangeDecisionAction.dtd

The Change Decision Action dtd describes the records and status of a
change decision and the implementing direction for an approved change.
The root element *Change Decision Action* consists of a sequence the
following elements:

-   *Change Control Entity*, which invokes the Change Control Entity
    oblet to identify the entity making the change control decision

-   *Program-Project Identifier*, which uniquely identifies a program or
    project.

-   *Product Identification*, which invokes the Product Identification
    oblet to uniquely identify the product that is associated with the
    change decision

-   One or more occurrences of *Document Reviewed*, invoking the
    Document Identification oblet to identify a document reviewed by the
    change control entity. The attributes *Document Type* (Change
    Proposals, Request for Variance, Specifications, etc) and
    *Disposition Status Code* (Approved, Disapproved, Deferred, or
    Concur) categorize the document and provide the change control
    entity's decision concerning it.

-   *Discussion Minutes-Text* captures the discussion of a change
    control entity concerning each document being considered

-   *Change Decision Date and Time* invokes the DateTime oblet to
    indicate when that a change decision was rendered, the time
    providing the decision sequence

-   Zero or one \[Should change to zero or more in next Rev\]
    occurrences of *Implementing Action Assignment Action* assigned to
    complete the implementation of a change invoke the Action Item dtd
    for documentation and tracking of the assigned action

###### ChangeImplementingAction.dtd

The Change Implementing Action dtd provides the information
relationships concerning the requirements for, and the actions taken to
implement an engineering change or modification to a product after it
has been approved for implementation. The root element *Change Implement
Action* contains the elements that describe the *Change Implementation
Requirement*, and choice of *Production Implementation*, and/or
*Retrofit Accomplishment*.

The *Change Implementation Requirement* element provides the
requirements that establish the actions necessary to implement an
approved engineering change to a product and to all affected interfacing
products. It includes:

-   Where applicable, the *Approved Change Proposal* element identifies
    the specific revision to a Change Proposal that has been approved
    for implementation by the change control entity.

-   The *Product To Be Changed* element, provides the *Product
    Identification* and an attribute *Asset Type* (e.g. Operating
    Software, Supporting Software, Supporting Plan, Supporting Product,
    Product used by the Trainer, Product used in Training, Spare or
    Repairable Part, Operating or Maintenance Manual). It also includes
    choice of the product's *As-Designed Product Structure* (invoking
    the As Designed Product Structure dtd) or its *As-Planned Product
    Structure* (invoking the As-Planned Product Structure dtd) relating
    manufacturing and assembly instructions.

-   If required, the *Modification Design* element, which provides the
    design and instructions for implementation of engineering change to
    completed and in-service products. Modification design and parts may
    differ from production because of such considerations as facility
    tooling differences, and different disassembly, and re-assembly
    constraints. The *Modification Design* element consists of a choice
    of zero or more of each of the following elements:

```{=html}
<!-- -->
```
-   *Modification Instruction,* which invokes the Modification
    Instruction business object.

-   *Modification Drawing*, which provides the design of a modification
    and associated parts and materials that differ in some respects to
    the production parts and materials because of such factors as
    facilities, tooling, disassembly and assembly considerations.

The *Production Implementation* element provides information relating to
the implementation of an engineering change into a product at the
product\'s originating place of manufacture or assembly prior to that
product having been completed and distributed or delivered to a user, or
otherwise entering the marketplace. The information relationships for
product implementation are embodied in the *As Built Configuration*
element, which invokes the As Built Configuration dtd.

The *Retrofit Accomplishment* element identifies the modification kit,
the validation of the kit, the associated modification instructions, and
the records associated with incorporation of the kit into the effected
product instances.

-   The *Modification Kit Identification* element provides information
    that identifies a modification kit used to accomplish retrofit,
    which consists of its *Product Identification* (invoking the Product
    Identification dtd) and the *Stock Identifier* element, e.g., Stock
    Keeping Unit (SKU) A code for stock identification, implemented in a
    bar coding on a product.

-   Zero or more occurrences of *Modification Kit-Modification
    Instruction Validation,* the proofing of a modification kit and its
    attendant modification instructions. This element consists of the
    following subordinate elements:

```{=html}
<!-- -->
```
-   *Validation Scheduled Date*, the date that validation is scheduled
    to be completed

-   *Validation Actual Date*, the date that validation is completed.

-   *Validation Location*, a role of Address that identifies the
    location at which validation takes place.

-   *Validating Organization*, a role of Organization to identify the
    organization(s) involved in the modification kit-modification
    instruction validation.

-   *Validation Kit Instance,* a role of product instance uniquely
    identifying the specific modification kit unit (instance) used in
    kit-instruction validation.

-   *Modification Instruction Revision and Date Validated,* a text
    record of the specific revision of a modification instruction that
    is validated (typically by trial kit installation) and the date that
    the validation was completed.

-   *Validation Report Identifier,* a role of document identifier that
    uniquely identifies a written report on the accomplishment of a
    validation of a modification kit and modification instruction.

```{=html}
<!-- -->
```
-   *Kit Instance Information*, records concerning the identification
    shipping, of, and incorporation of each individual unit of a
    retrofit (modification) kit. It has an attribute *Kit* Status
    (Assembled, Shipped, Available for Installation, or Installed)

```{=html}
<!-- -->
```
-   *Modification Kit Instance*, a single instance of a retrofit
    (modification) kit, i.e., a single modification kit. It consists of
    *Modification Kit Identification*, *Tracking Identifier Prefix*, and
    *Tracking Identifier*).

-   *Shipping Date,* the date on which an item is shipped to a
    destination.

-   *Shipping Record Identifier*, identifies the record of modification
    kit shipments such as a Bill of Lading or Postal or shipping company
    tracking identifier

-   *Shipping Location*, a role of Address that identifies the location
    to which a product is shipped.

-   *Incorporation In Product Instance*, incorporation of a specific
    retrofit kit (retrofit kit instance) in a specific product instance
    as reflected in the *As Modified-As Maintained Configuration*
    element that invokes the As Maintained-Modified Configuration dtd.

###### ConfigAuditAction.dtd

The Configuration Audit Action dtd provides product configuration
verification accomplished by Configuration Audit, inspecting documents,
products and records; and reviewing procedures, processes, and systems
of operation to verify that the product has achieved its required
attributes (performance requirements and functional constraints) and the
product\'s design is accurately documented. A configuration audit is
sometimes divided into separate functional and physical configuration
audits. The root element Configuration Audit consists of the attribute
*Audit Type Code*, which indicates if the audit is a Functional
Configuration Audit (FCA), Physical Configuration Audit (PCA), or a
combined FCA/PCA, and a sequence of elements *Audit Requirement*,
*Product Identification*, *Audit Identifier*, *Audit Date, Audit Action
Item, Configuration Audit Status, Configuration Audit Comment, and
Configuration Audit Report Identifier*.

-   The *Audit Requirement* element provides the basis for the conduct
    of the configuration audit. It consists of two optional elements
    *Audit Requirement Description* (textual description of the need for
    the audit) and *Audit Contract Requirement*, whose subordinate
    elements *Contract Identifier* and *Audit Requirement Citation*
    reference a contract and a particular citation in a contract that
    prescribes that a configuration audit be conducted.

-   The *Product Identification* element invokes the Product
    Identification oblet as many times as necessary to identify all of
    the Products audited.

-   *The Audit Identifier* element is an optional string element that
    provides a unique identifier for a specific audit.

-   *The Audit Date* element provides scheduled and actual dates of
    audit start and completion.

-   The *Audit Action Item* element identifies zero or more action items
    assigned as a result of the configuration audit. It invokes the
    Action Item dtd.

-   The *Configuration Audit Status* element provides the condition of a
    configuration audit (Appeal, Cancel, Complete, Defer, In Work, or
    Pending) via the attribute *Audit Disposition Code* and the element
    *Audit Disposition Date*.

-   The *Configuration Audit Comment* element provides one or more
    notations concerning a configuration audit, usually recorded in an
    audit report.

-   The *Configuration Audit Report Identifier* invokes the Document
    Identifier oblet one or more times to provide the identifiers for
    the document(s) containing the results of a configuration audit.

###### DeliveryAcceptance.dtd

The Delivery and Acceptance dtd provides a product\'s as-delivered
record. It contains the data such as shipping/delivery date, location,
record identifier, date it was placed in stock, and material/process
certification. The root element *Delivery-Acceptance* has an attribute
*Delivery Location Code* that indicates (Destination or Source) where
the product will be inspected and accepted. It consists of the following
sequence of elements:

-   *Acceptance Record*, identifying the document that records the
    official acceptance of a product. (It could be a DD-250 or
    equivalent)

-   Zero or more occurrences of *Test Documentation*, to be delivered
    with a product. It consists of Test Procedure, Test Report, and Test
    Data.

-   Zero or more occurrences of *Variances Noted* -- any anomalies noted
    during testing and inspection

-   *Shipping or Delivery Date*, the date that a product unit was
    shipped, or delivered to a using location.

-   Shipping Location, a role of Address that identifies the location to
    which a product is shipped.

-   Optional *Shipping Record Identifier*, identifies the record of
    modification kit shipments such as a Bill of Lading or Postal or
    shipping company tracking identifier

-   *In Stock Date*, the date that an item is to be delivered and ready
    for use.

-   Zero or more occurrences of *Material and Process Certification*, a
    quality control document that certifies the composition of a
    material or the completion of a process in accordance with a
    specified requirement. Certifications are mandated to accompany
    shipped products or materials by regulations in many instances.

###### MaintainStatusAccounting.dtd

The Maintain Status Accounting dtd will be added in the next revision.
It will provide the information elements and relationships concerned
with the process of accounting for the current status and history of a
product with respect to its baselines and all configuration changes.

# 6. CM Business Objects

A Business Object is a set of related information that has meaning and
purpose in the business process sense, e.g., Purchase Order, Invoice,
Engineering Change Proposal. . The business objects are XML Documents to
be used as is, or tailored to suit specific trading partner situations
and different industry domains. They are to be considered as templates
rather than rigid standards. Users will be able to modify them and
register them as additional variations.

Each CM Business Objects in this clause includes a reference schema
(dtd), the XML document and a sample XML style sheet (.xls). Definitions
of the elements in each business object are contained in the business
object reference schemas as well as in Annex B. To access the business
objects, click on the links below.

::: Definition-Term
The Business Object Schema categories corresponding to the subsections
of clause 6 that describe them are: CM Management and Planning Business
Objects (6.1), Configuration Identification Business Objects (6.2),
Configuration Change Management Business Objects (6.3), Configuration
Status Accounting Business Objects (6.4), Configuration Verification And
Audit Business Objects (6.5), Data-Document Management Business Objects
(6.6), and General Business Objects (6.7).
:::

> **NOTE:** THIS SECTION IS INCOMPLETE. ONLY THOSE BUSINESS OBJECTS THAT
> HAVE BEEN COMPLETED AT THE TIME OF THIS DRAFT ARE FULLY DESCRIBED. TO
> ILLUSTRATE THE FULL SCOPE OF THE STANDARD, OTHERS THAT WILL BE ADDED
> IN LATER DRAFTS, ARE PROVIDED AS PLACEHOLDERS

## 6.1 CM Planning And Management Business Objects

###### CMPlan.dtd

The Configuration Management Plan dtd is the reference schema for the
Department of Defense business object corresponding to data item
description DI-CMAN-80858B, the Contractor\'s Configuration Management
Plan, which is based on the content in MIL-HDBK-61A. It describes the
contractor\'s configuration management program, how it is organized, how
it will be conducted, and the methods procedures and controls effective
configuration identification, change control, status accounting, and
audits of the total configuration, including hardware, software and
firmware. The principal use is to provide the government a basis for
review, evaluation and monitoring of the CM program and its proposed
components.

The root element of the Configuration Management Plan dtd is
*Configuration Management Plan*. It consists of the *CM Plan
Identification element*, a sequence of elements corresponding to the
Sections of the CM Plan, and an optional element *File* (which invokes
the File oblet), as follows:

-   The *CM Plan Identification* element includes the elements
    *Configuration Management Plan Title*, *Configuration Management
    Plan Number*, and *Configuration Management Plan Date.*

-   The element *Configuration Management Plan Introduction* is a string
    element for the following content:

    a.  The purpose, scope and specific contractual applicability of the
        configuration management plan and the program phase(s) to which
        it applies;

    b.  A brief description of the system or top level CI, and of the
        component lower level CIS, using approved CI nomenclature when
        available, to which the CM Plan pertains;

    c.  Reference to applicable directives or glossaries containing
        definitions of terminology and acronyms used in the plan; and

    d.  A description of the plan\'s major features and objectives and a
        concise summary of the contractor's approach to CM, including
        any special conditions (such as large number of organizations,
        security constraints, interoperability constraints, unique
        contracting methods, non-developmental items, etc.) upon which
        the approach is based.

-   The element *Configuration Management Plan Reference Documents*
    provides for a list of the specifications, standards, manuals and
    other documents, including contractor policy directives, referenced
    in the Plan by title, document number, issuing authority, revision,
    and when applicable, change notice, amendment number, and date of
    issue. It consists of the elements *Document Identification* and
    *CMP Reference Documents Description.*

-   The element *Configuration Management Plan Organization* includes
    the element *CMP Organization Description*, which provides for a
    text description and graphical portrayal (optional *File* element)
    of the contractor\'s organization with emphasis on the CM
    activities, which includes:

    a.  The relationships and integration of the contractor\'s project
        organization and functional organization;

    b.  Responsibility and authority for CM of all participating groups
        and organizations including their role in configuration control
        boards, and the integration of CM functions with other program
        activities such as technical reviews;

    c.  Identification of the contractor\'s CM organization and its
        responsibilities; and

    d.  Interfaces between the contractor\'s CM organization and the
        Government, subcontractors, and associate contractors.

-   The element *Configuration Management Plan Phasing Milestones*
    includes the elements *CMP Phasing Milestone Description*, and
    optional *File* to describe and graphically portray the sequence of
    events and milestones for implementation of CM in phase with major
    program milestones and events, including:

a.  Release and submittal of configuration documentation in relation to
    program events (e.g., technical reviews);

b.  Establishment of internal developmental configuration and
    contractual baselines;

c.  Implementation of internal and Government configuration control;

d.  Establishment of configuration control boards;

e.  Implementation of a status accounting information system and
    provision of reports/or access to the status accounting information;
    and

f.  Conduct of configuration audits.

-   The string element *Configuration Management Plan Data Management*
    provides a place to describe the methods for meeting the
    configuration management technical data requirements of the
    contract.

-   The string element *Configuration Management Plan Configuration
    Identification* provides a place to describe the contractor\'s
    procedures for meeting Configuration Identification requirements,
    including:

    a.  Selection of CIs (HWCIs and CSCIs);

    b.  Establishment and management of developmental configuration
        including document, drawing and software development libraries
        and corrective action process;

    c.  Establishment of the Functional, Allocated and Product
        baselines, definition of the configuration documentation
        required for each and graphic illustration of configuration
        documentation relationships;

    d.  Engineering release and correlation of manufactured products;

    e.  Assignment and application of configuration identifiers
        including document numbers, nomenclature, serial numbers and
        part number to hardware; and software identifiers to software
        and firmware.

-   The string element *Configuration Management Plan Interface
    Management* provides a place to describe the procedures for
    identification of interface requirements, establishment of interface
    agreements and participation in interface control working groups
    (ICWG).

-   The string element *Configuration Management Plan Configuration
    Control* provides a place to describe the contractor\'s procedures
    for meeting Configuration Control requirements, including:

    a.  Functions, responsibility, and authority of configuration
        control boards;

    b.  Classification of changes, and the level of authority for change
        approval/concurrence;

    c.  Processing of Class I Engineering Change Proposals (ECPS) and
        Value Engineering Change Proposals (VECPS);

    d.  Processing of Class II ECPS;

    e.  Processing of Requests for Deviations and Waivers;

    f.  Processing of Specification Change Notices (SCNS); and

    g.  Processing of Notices of Revision (NORS).

-   The element *Configuration Management Plan Configuration Status
    Accounting* consists of elements *CMP Configuration Status
    Accounting Description* and optional *File*, providing a place to
    describe the contractor\'s procedures for meeting Configuration
    Status Accounting requirements, including:

    a.  The contractors methods for collecting, recording, processing
        and maintaining data necessary to provide contractual status
        accounting information via reports and/or data base access;

a.  Description of reports/information system content related to, as
    applicable:

> \(1\) Identification of current approved configuration documentation
> and configuration identifiers associated with each CI;
>
> \(2\) Status of proposed engineering changes from initiation to
> implementation;
>
> \(3\) Results of configuration audits; status and disposition of
> discrepancies;
>
> \(4\) Status of requests for critical and major deviations and
> waivers;
>
> \(5\) Traceability of changes from baselined documentation of each CI;
> and
>
> \(6\) Effectivity and installation status of configuration changes to
> all CIS at all locations.

b.  Methods of access to information in status accounting information
    systems and/or frequency of reporting and distribution.

-   The element *Configuration Management Plan Audits* consists of
    elements *CMP Audits Description* and optional *File* to describe
    the contractor\'s approach to meeting the requirements described in
    the plan, including Plans, Procedures, Documentation, and Schedules
    for functional and physical configuration audits; and format for
    reporting results of in-process configuration audits.

-   The element *Configuration Management Plan Subcontractors and
    Vendors* consists of elements *Configuration Management Plan
    Subcontractor and Vendor Description* and optional *File* to
    describe the methods used by the contractor to ensure
    subcontractor/vendor compliance with configuration management
    requirements.

###### ActionItemStatusReport.dtd

The Action Item Status Report dtd represents a collection of data
depicting the status of one or more action items. It consists of a
sequence of three oblets:

-   The Document Identification dtd, which identifies the report

-   One occurrence of the Action Item dtd for each action item covered
    by the report

-   Product Protection, invoking any applicable security, data rights,
    or other protection schemas that apply.

## 6.2 Configuration Identification Business Objects

###### InterfaceControlDoc-Def.dtd

The Interface Control Document \[Defense\] is a US Air Force business
object that provides a compilation of interface information. Based on
Data Item Description (DID) DI-CMAN-81248A, this business object
provides a record of all interface information (such as drawings,
diagrams, tables, and textual information) generated for the project.
The Interface Control Document described in this business object is NOT
what is commonly referred to as an interface control drawing or
interface control document, ICD, although by reference it provides
access to, or delivery of, copies of actual interface information that
may be embodied in ICDs. The Interface Control Document -- Def dtd
consists of the following elements:

-   *Interface Control Document Identification*, the identification data
    that uniquely identifies the ICD, consisting of

```{=html}
<!-- -->
```
-   String element *Interface Control Document Title*, the name given to
    the ICD, normally called \"Interface Control Drawing
    Documentation.\"

-   *Interface Control Document Number,* the role of Document
    Identification that uniquely identifies the ICD. This will include
    revision and the source of the document.

-   *Interface Control Document Date*, the date the ICD was issued and
    approved

-   *Interface Control Document Associated Projects,* the title,
    alphanumeric string, or other character string that uniquely
    identifies a program or project associated with the item identified
    by the ICD.

-   *Interface Control Document Revision History*, a textual summary of
    the revisions made to this document.

```{=html}
<!-- -->
```
-   *Interface Control Document Description*, a free form textual
    description of the ICD

-   *Interface Control Document Information,* a listing of all
    released/approved interface information for the project, consisting
    of:

```{=html}
<!-- -->
```
-   One or more occurrences of *Interface Control Document Information
    Item* providing the unique metadata that identifies the item
    associated with the project listed on the ICD. The metadata consists
    of the following elements:

```{=html}
<!-- -->
```
-   *Interface Control Document Information Item Identifier*, The role
    of Document Identification that uniquely identifies the item being
    identified

-   *Interface Control Document Information Item Custodian*, a role of
    Entity that identifies who maintains physical control over the item.

-   *Interface Control Document Information Item Access*, a link to the
    actual documentation defining the released/approved interface
    information for the project consisting of Source Document (the URI
    or location of the document defining the interface information for
    the project).

-   *Interface Control Document Information Item Revision Record*, a
    revision record for all released/approved interface information for
    the project, including release dates. It contains Document
    Identification.

-   *Interface Control Document Information Item Associated System/CI*,
    a cross-reference listing relating all released/approved interface
    information for the project to the configuration items and system
    elements to which they apply.

```{=html}
<!-- -->
```
-   *Interface Control Document Relationship Description*, a description
    of the physical and functional relationships between all
    released/approved interface information for the project included in
    the elements *Interface Control Document Relationship* and
    *Associated Information Item*.

-   *Interface Control Document Distribution*, the role of *Distribution
    Restriction* identifying the restrictions placed on the distribution
    of the ICD.

###### ReleaseRecord.dtd

The Release Record dtd will be added in the next revision. It will
provide the information elements and relationships concerned with
concerned with the release of requirements objects and engineering
design objects.

###### EngineeringReleaseRecord-Def.dtd

The Engineering Release Record -- Defense Business Object dtd describes
a document, referred to as an ERR, that is used by the US Army (only) to
officially authorize the use of newly approved configuration
documentation. This US Defense Industry version of the ERR meets the
basic requirements of Data Item Description (DID) DI-CMAN-80463C.

The root element *Engineering Release Record -- Def* consists of the
following sequence of elements: *ERR Identification*, *ERR Disposition*,
*ERR Description*, one or more occurrences of *ERR Document*, zero or
more occurrences of *ERR Associated ECP*, *ERR Remarks Miscellaneous*,
and *ERR Distribution.*

The element *ERR Identification* provides unique identification data for
the ERR, which consists of:

-   *ERR Number*, a role of Document Identification

-   *ERR Originator*, a role of Organization that provides a name for
    the responsible organization.

-   *ERR Submittal Date*, the date the ERR was submitted for
    consideration.

The element *ERR Disposition* provides *ERR Approval Authority* (the
*Organization* that approves the ERR), and *ERR Approval Date.*

The element *ERR Description* provides descriptive data pertaining to
the item on the ERR, which consists of optional string element *ERR
Procuring Activity Number,* if known (Army only), optional string
element ERR DODAAC (the DOD Activity code for the procuring activity),
*ERR Baseline*, and *ERR System Configuration Item.*

-   *ERR Baseline* identifies the configuration baseline established or
    changed, i.e., functional, allocated, or product. The required
    attribute *ERR Release Type* indicates whether the release is
    establishing a baseline (initial) or a change to the established
    configuration baseline (change) as the result of an approved ECP.

-   *ERR System Configuration Item* provides *ERR Nomenclature* (a
    configuration item identifier which includes an alphanumeric
    designation and/or a noun name), *ERR Part Number* (the role of
    Part-Material Identification that identifies a product), and one or
    more occurrences of *ERR Lowest Assembly* (the lowest functional
    assembly(s) to which the ERR applies).

The element *ERR Document* provides a separate line entry of ERR
document data for each document and sheet, except that multi-sheet
documents are entered as a single line entry when all sheets are
maintained at the same revision level. This element has a required
attribute *Release,* which indicates the type of release for the
document. The types are \"IR\" if the document is being initially
released, \"NAR\" if the document has a new application, \"CH\" for each
document listed for which the revision level of an established baseline
document is being changed, and \"CAN\" for each listed document that is
to be deleted from an established configuration baseline. Its
subordinate elements are:

-   *ERR Document Associated Originator Identification*, a role of
    Organization that provides the CAGE Code or equivalent (e.g. DUNS)
    of the document listed.

-   *ERR Document Identification*, a role of *Document Identification*
    that provide the unique document identifier.

-   *ERR Document Date*

-   *ERR Document Revision Symbol,* the new revision of the document
    listed. (The original issue of a document is indicated by a hyphen
    (-).

-   *ERR Document Type*, the standard code which represents and/or
    denotes a category or type of formal papers or records of similar
    characteristics know as a document, i.e.,

```{=html}
<!-- -->
```
-   Drawing List (Application List, Data List, Drawing List, Indentured
    Data List, Index List, Parts List, or Wire List),

-   Specification (Associated Specification, Detail Specification, Item
    Specification, Material Specification, Manufacturer\'s
    Specification, Other specifications, Performance Specification,
    Process Specification, System Specification),

-   Software Support Document (Computer Resources Integrated Support
    Document, Computer System Operator\'s Manual, Firmware Support
    Manual, Interface Design Document or Description, Software Design
    Document or Description, Software Development Plan, Software
    Programmer\'s Manual, System/Segment Design Document or Description,
    Software Test Plan, Software Test Report, Software User\'s Manual,
    Version Description Document).

```{=html}
<!-- -->
```
-   *ERR Document Pages* provides *ERR Document Page Number* (the
    particular page number) and *ERR Document Page Count* (the total
    count of pages) of the document being released.

The element *ERR Associated Engineering Change Proposal* provides the
*ECP Identifier* and the *ECP Approval Date*, of applicable (zero or
more) ECPs.

The element *ERR Miscellaneous Remarks* provides the item that the
documentation identifies, e.g., system specification, minor item,
configuration item, critical component, partial or complete releases, or
any other remarks pertinent to the data being released.

The element *ERR Distribution* indicates the authorized circulation or
dissemination of the ERR, as indicated by the attribute ERR Distribution
Type, which provides the appropriate distribution statement to be
affixed to the ERR in accordance with the requirements of the contract.
(See the Distribution Restriction oblet.)

###### TrackingIdentifierAssignmentRecord.dtd

The Tracking Identifier Assignment Record dtd will be added in the next
revision. It will provide the information elements and relationships
concerned with maintaining records of the assignment of tracking
identifiers against an effectivity base product.

## 6.3 Configuration Change Management Business Objects

###### RequestForChange.dtd

The Request For Change dtd will be added in the next revision. It will
provide the information elements and relationships concerned with
identifying and requesting an engineering change.

###### RequestForVariance.dtd

\[Note: this dtd is incomplete. It needs additional elements to identify
the requestor and the RFV, and to provide corrective action. It will be
revised in the next revision\]

The Request For Variance dtd includes descriptive information and other
information associated with a variance to a product\'s baseline
configuration. A Variance (alias: Deviation, Waiver, Concession) is a
departure from a particular requirement(s) of a product\'s current
approved configuration documentation for a specific number of units
and/or a specified period of time. A variance differs from an
engineering change in that it does not require a corresponding revision
of the product\'s current approved configuration documentation.

The root element *Request For Variance* contains the *Variance* element
consisting of the elements *Variance Description* (a text description of
the variance)*, Variance Classification* (a categorization of a variance
as to its relative severity)*, Document Identification* (delineating the
document that defines the variance)*, Effectivity Base Product* (the
product to which effectivity is assigned)*,* and *Variance Effectivity*
(invoking the Effectivity oblet to indicate the effectivity to which the
variance applies).

The Variance Classifications include Critical, Major and Minor. The
*Effectivity Base Product* element includes the Product Identification
and Product Type oblets.

###### RequestForDeviation-Def.dtd

The Request for Deviation-Defense describes a proposed departure from (a
non-conformance with) the contractually specified configuration
documentation for a specific number of units or for a specified period.
The Defense RFD conforms to Data Item Description (DID) DI-CMAN-80640C.
Guidance is provided in MIL-HDBK-61A (SE). The root element *Request for
Deviation* contains the elements *RFD Identification*, *RFD
Description*, *RFD Corrective Action*, and *RFD Associated Contract*.

The element *RFD Identification*, the data and metadata that identifies
an RFD, includes the following elements:

-   *RFD Title*, a string element for name or title assigned to the RFD

-   *RFD Number*, a role of *Document Identification* that uniquely
    identifies an RFD for any CAGE Code identified activity

-   *RFD Submittal Date*, the date the RFD is submitted for approval.

-   *RFD Classification* and its attribute *RFD Class* provide the
    information (see definitions) for a request for deviation to be
    designated as critical, major, or minor by the originator.
    Classification disagreements shall be referred to the Government for
    decision.

-   *RFD Designation*, the identification of the product affected by the
    RFD, includes the elements *RFD Model Type* (an identifier of
    Type-Model/Series Nomenclature for a weapon system), and *RFD Top
    Level Product* (the highest level assembly for the product affected
    by the RFD).

-   *RFD Procuring Activity No*., the identification of the activity
    procuring the product. This element invokes the oblet Entity.

The element RFD Description, the descriptive data for the RFD, includes
the following:

-   *RFD Configuration Item* consists of *RFD CI Name* and *RFD CI
    Number* (the name and CI designation given to the configuration item
    being addressed in the RFD), and either *RFD Quantity* (the quantity
    associated with the configuration item) or *RFD Effectivity* (the
    effectivity of the configuration item being addressed in the RFD).

-   *RFD Affected Baseline* and its attribute, *RFD Affected Baseline
    Code* identify the baseline affected the RFD.

-   The string element *RFD Deviation Description* delineates the nature
    of the proposed departure from the technical requirements of the
    configuration documentation including analysis to determine that it
    does not affect any of the factors constituting a Class I change.

-   The *RFD Need* string element explains why it is impossible or
    unreasonable to comply with the configuration documentation within
    the specified delivery schedule and why a deviation is proposed in
    lieu of a permanent design change.

-   One or more occurrences of *RFD Lowest Level Items*, identifying the
    part(s) affected by the RFD

-   An optional string element *Recurrence Rationale*, which applies if
    this is a recurring deviation, references the previous
    correspondence, the request number, and corrective action, and the
    rationale why recurrence was not prevented by previous corrective
    action and/or a design change.

-   The element *RFD Effect* provides a place to state that the RFD will
    have no effect on, or if the deviation will have such impact, to
    describe such effects. NOTE: An effect on logistics support,
    interface, or software indicates that an engineering change is
    required in lieu of an RFD.

-   The element *RFD Other Systems or Configuration Item Impact*
    identifies other systems or configuration items that may be impacted
    by the RFD.

The string element *RFD Corrective Action* describes action being taken
to correct the non-conformance to prevent a future recurrence.

The element *RFD Associated Contract* provides identifies data and
metadata associated with one or more Contracts associated with the RFD.
Each consists of:

-   *RFD Contract Number* and *RFD Contract Line Item*

-   *RFD Contract Procuring Officer*

-   *RFD Contract Delivery Schedule Effect* (statement of the effects on
    the contract delivery schedule that will result from both approval
    and disapproval of the RFD),

-   And either *RFD Contract Cost Consideration* (an estimated reduction
    or price adjustment or other specific consideration that will be
    provided to the Government) or *RFD Contract Price Rationale*
    (rationale for no offer of a change in price, cost, or fee).

###### ChangeProposal.dtd

The Change Proposal dtd will be added in the next revision. It will
provide many of the same information elements and relationships as the
DoD ECP, but will not use DoD unique terminology, and a significantly
greater proportion of the information will be optional.

###### EngineeringChangeProposal-Def.dtd

The Engineering Change Proposal -- Defense dtd provides the
documentation in which the engineering change is described. It includes
change impacts to systems, configuration items and other associated
configuration documentation that is affected by the proposed change. In
addition, it typically describes how the proposed change will be
implemented along with providing estimated schedules and associated
costs. This Business Object meets the requirements of Data Item
Description (DID) DI-CMAN-80639C Engineering Change Proposal. Guidance
may be found in MIL-HDBK-61A (SE). Some of the ECP DTD elements are only
required for a Class I ECP. These \"Class I Only\" elements are
identified in the Schema Notes.

The root element *Engineering Change Proposal-Def* consists of the
following elements: *ECP Identification*, *ECP Description*, *ECP
Affected Items*, *ECP Associated Contract*, *ECP Cost Impact*, *ECP
Milestones*, and *ECP Distribution.*

-   *Engineering Change Proposal Identification*, the data that uniquely
    identifies an ECP, consists of the following elements:

```{=html}
<!-- -->
```
-   *ECP Title*, descriptive title for the engineering change proposal

-   ECP Identifier

-   *ECP Type*, for Class I only, indicates the type of ECP(Message,
    Preliminary, or Formal)

-   *ECP Classification*, An ECP is designated as either Class I or II.
    A Proposed change that does not meet the criteria for Class I is
    designated as Class II.

+-----------------------------------------------------------------------+
| [The criteria for Class I are]{.underline}:                           |
|                                                                       |
| a\. The Functional Configuration Documentation (FCD) or Allocated     |
| Configuration Documentation (ACD) is affected to the extent that any  |
| of the following requirements would be outside specified limits or    |
| specified tolerances:                                                 |
|                                                                       |
| \(1\) Performance.                                                    |
|                                                                       |
| \(2\) Reliability, maintainability or survivability.                  |
|                                                                       |
| \(3\) Weight, balance, moment of inertia.                             |
|                                                                       |
| \(4\) Interface characteristics.                                      |
|                                                                       |
| \(5\) Electromagnetic characteristics.                                |
|                                                                       |
| \(6\) Other technical requirements in the specifications.             |
|                                                                       |
| NOTE: Minor clarifications and corrections to FCD or ACD should be    |
| made only as an incidental part of the next Class I ECP NOR, unless   |
| otherwise directed by the Government.                                 |
|                                                                       |
| b\. A change to the Product Configuration Documentation (PCD) will    |
| affect the FCD or ACD as described in paragraph 9a or will impact one |
| or more of the following:                                             |
|                                                                       |
| \(1\) Government Furnished Equipment (GFE).                           |
|                                                                       |
| \(2\) Safety.                                                         |
|                                                                       |
| \(3\) Compatibility or specified interoperability with interfacing    |
| CIs, support equipment or support software, spares, trainers or       |
| training devices/ equipment/software.                                 |
|                                                                       |
| \(4\) Configuration to the extent that retrofit action is required.   |
|                                                                       |
| \(5\) Delivered operation and maintenance manuals for which adequate  |
| change/revision funding is not provided in existing contracts.        |
|                                                                       |
| \(6\) Preset adjustments or schedules affecting operating limits or   |
| performance to such extent as to require assignment of a new          |
| identification number.                                                |
|                                                                       |
| \(7\) Interchangeability, substitutability, or replaceability as      |
| applied to CIs, and to all subassemblies and parts except the pieces  |
| and parts of non-reparable subassemblies.                             |
|                                                                       |
| \(8\) Sources of CIs or repairable items at any level defined by      |
| source-control drawings.                                              |
|                                                                       |
| \(9\) Skills, manning, training, biomedical factors or                |
| human-engineering design.                                             |
|                                                                       |
| c\. Any of the following contractual factors are affected:            |
|                                                                       |
| \(1\) Cost to the Government including incentives and fees.           |
|                                                                       |
| \(2\) Guarantees or warranties.                                       |
|                                                                       |
| \(3\) Deliveries.                                                     |
|                                                                       |
| > \(4\) Scheduled milestones.                                         |
+-----------------------------------------------------------------------+

-   *ECP Priority*, the priority assigned to a Class I engineering
    change, which determines the relative speed at which the ECP is to
    be reviewed, evaluated, and if approved, ordered and implemented.
    For Class I Only. Priorities are Emergency, Urgent, and Routine.

-   *ECP Justification*, a code that indicates the reason for a Class I
    engineering change. The justification code is not required for Class
    II ECPs. If more than one of the following codes is applicable, the
    one that is the most descriptive or significant shall be assigned to
    the ECP. Values are:

> B Interface
>
> C Compatibility
>
> D Correction of deficiency
>
> O Operational or logistics support
>
> P Production stoppage
>
> R Cost reduction
>
> S Safety
>
> V Value engineering

-   *ECP Designation*, the identification of the specific Model/Type and
    Top Level CI/Nomenclature or System the engineering change is
    referring to.

```{=html}
<!-- -->
```
-   *ECP Model or Type* an identifier of the specific categorization
    within Type as used in Nomenclature for a weapon system, e.g., the
    14 in the Type-Model/Series F-14D. As a data item usually used to
    designate the entire Type-Model series.

-   *ECP Top Level CI or System* A configuration item identifier which
    includes an alphanumeric designation and/or a noun name.

```{=html}
<!-- -->
```
-   ECP Procuring Activity

-   ECP Originator, and ECP Originator Address

-   ECP Submittal Date

```{=html}
<!-- -->
```
-   *ECP Description*, the data describing the requested engineering
    change. It consists of the following elements:

```{=html}
<!-- -->
```
-   *ECP Configuration Item*, one or more CI(s) affected by the ECP.

```{=html}
<!-- -->
```
-   *ECP CI Name*, the name given to a configuration item.

-   *ECP CI Number*, the unique identifier given to a configuration
    item.

-   *ECP Configuration Item In Production*, an indication that a
    configuration item is or is not in production. If CI is in
    production, provide information as to whether deliveries have been
    completed on the contract(s). This data is not always applicable to
    software. For Class I Only.

```{=html}
<!-- -->
```
-   *ECP Change Description*, description of the proposed change phrased
    in definitive language such that, if it is repeated in the
    contractual document authorizing the change, it will provide the
    authorization desired. Including the purpose and sufficient detail
    to describe what is to be accomplished. If the proposed change is an
    interim solution, it shall be so stated.

-   *ECP Change Need*, explanation of the need, identifying the benefit
    of the change, and as applicable:

```{=html}
<!-- -->
```
-   Correspondence such as a request for ECP or Government direction

-   Quantitative improvements in performance characteristics (range,
    speed, performance, endurance, striking power, and defensive or
    offensive capabilities)

-   Nature of a defect, failure, incident, malfunction; available
    failure data.

-   Maintenance/ logistics problems corrected

-   Identification and summary of testing accomplished

-   Supporting data as necessary

-   Consequences of Disapproval.

```{=html}
<!-- -->
```
-   *ECP Baseline Affected*, which identifies the type of configuration
    baseline being affected by the ECP. For Class I Only.

> A Allocated Baseline
>
> C Contracted Baseline
>
> F Functional Baseline
>
> P Product Baseline
>
> T Technical Baseline

-   *ECP Development Requirement and Status*, if proposed engineering
    change requires a major revision of the development program, status
    of current program and details of the revision. When applicable,
    recommendations for additional tests, trials, installations,
    prototypes, fit checks, etc. Include the test objective and test
    vehicle(s) to be used. Indicate the development status of major
    items of to be used in and its availability in terms of the
    estimated production incorporation point. For Class I Only.

-   *ECP Alternative Analysis*, summary of the various solutions
    considered and reasons for adopting the solution proposed by the
    ECP. When analysis addresses new concepts or new technology,
    supporting data may be presented with the proposal to authenticate
    the trade-off analysis. For Class I Only.

-   *ECP Production Items,* Proposed end item CI production effectivity
    for the production items including serial numbers, or other item
    identification (e.g., block or lot numbers). For CSCI\'s, the CSCI
    version number into which the change will be incorporated, if known,
    and the proposed effectivity of the end item CI (vehicle, aircraft,
    tank, ship, etc.) into which the capability represented by the new
    version of the software is proposed to be incorporated. For Class I
    Only.

```{=html}
<!-- -->
```
-   *ECP Production Effectivity*, the effectivity of the change to the
    production item.

-   *ECP Production Item Schedule*, information indicating the proposed
    time line for the change to be implemented into production.

```{=html}
<!-- -->
```
-   ECP Retrofit Items, the collection of data pertaining to a
    retrofitted item. For Class I Only.

```{=html}
<!-- -->
```
-   *ECP Retrofit Recommendation*, when applicable, descriptions of
    recommendations for retrofit of the engineering change into accepted
    items (including applicable substantiating data or discussion of
    implications). If retrofit is not recommended, explanation/reason
    for the recommendation.

-   *ECP Retrofit Effectivity*, quantities and serial (or lot) numbers
    of accepted items in which the change is proposed for incorporated
    by retrofit with retrofit recommendations for items in production
    (at the time of the ECP) based on an estimated ECP approval date.

-   *ECP Ship Or Vehicle Class*, identification assigned to a defined
    asset, such as an aircraft, ship, vehicle, computer operating
    system, or other fielded platform

```{=html}
<!-- -->
```
-   *ECP Ship or Vehicle Class Identification* when the delivered CI is
    installed in one or more ship/vehicle classes; enter the
    identification of such classes. The ship hull numbers or vehicle
    numbers, if retrofit is to be accomplished in ships or vehicles.

-   *Retrofit Location,* the geographic location(s) where retrofit is
    proposed to be accomplished.

```{=html}
<!-- -->
```
-   *ECP Retrofit Kit Delivery Schedule*, estimated kit delivery
    schedule by quantity and date. Dates of availability for any special
    tools, jigs, or test equipment required in conjunction with the
    kits.

-   *ECP Retrofit Order,* identification of the ECPs and order of
    implementation, where this change must be accomplished before, with,
    or after other previously approved retrofit ECPs.

-   *ECP Retrofit Work Hours*, work-hours per unit that must be
    programmed for to install the retrofit kit, test the system or the
    item following installation of the retrofit kit, and conduct system
    tests in all proposed installation environments, including where
    applicable, when weapon system is undergoing overhaul.

```{=html}
<!-- -->
```
-   Are contractor field service engineering or other supporting
    organizations required on site? If \"yes\" attach proposed
    requirements for participation.

-   Estimate the total time period from removal of the equipment from
    operational service until equipment will be returned to operational
    status after being retrofitted.

-   Estimate the out of service time from removal of the equipment from
    operational service until equipment will be returned to operational
    status after being retrofitted.

```{=html}
<!-- -->
```
-   The element *ECP Affected Items*, the data that identifies the
    affected items associated with the proposed change. (For Class I
    only except for *ECP Affected Document*. It consists of the
    following elements:

```{=html}
<!-- -->
```
-   *ECP Affected Specification,* the role of Document Identification
    that uniquely identifies zero or more specifications cited in the
    contract that are affected by the ECP, by the CAGE code of the
    design activity, document number and revision letter, and if
    applicable, the number of the NOR being submitted with the ECP. For
    Class I Only.

-   *ECP Performance And Interface Change*, the change in performance
    and in functional/physical interfaces. For Class I Only.

-   *ECP Operations Impact*, effects of the proposed change on
    operational employment, deployment, logistics, and/or personnel and
    training requirements specified in the approved system and/or CI
    specifications, including any changes or effects on operability and
    survivability. Quantitative values shall be used whenever
    practicable and are required when reliability and service life are
    impacted. Survivability includes nuclear survivability.

```{=html}
<!-- -->
```
-   Effect on interoperability.

-   Effect on operational software. For CSCIs, as applicable:

```{=html}
<!-- -->
```
-   Required changes to database parameters, values, or management
    procedures;

-   Anticipated effects on acceptable computer operating time and
    cycle-\
    time utilization;

-   Estimate of the net effect on computer software storage; and,

-   Other relevant impact of the proposed change on utilization of the\
    system.

> For Class I Only.

-   *ECP Acquisition Logistics Impact*, the following shall be covered,
    as applicable:

```{=html}
<!-- -->
```
-   Effects on schedule and content of the ALS plan.

-   Effect on maintenance concept and plans for the levels of
    maintenance and procedures.

-   System and/or CI logistics support analysis (LSA) tasks to be
    accomplished and LSA data requiring update (MIL-PRF-49506)

-   Extension/revision of the interim support plan.

-   Spares and repair parts that are changed, modified, obsolete or
    added, including detailed supply data for interim support spares

-   Revised or new technical manuals.

-   Revised or new facilities requirements and site activation plan.

-   New, revised, obsolete or additional support equipment (SE), test
    procedures and software.

-   Description of the proposed change(s) to SE and trainers and
    reference to related ECPs.

-   Effect on maintenance or training software

-   Qualitative and quantitative personnel requirements data identifying
    additions or deletions to operator or maintenance manpower
    requirements in terms of personnel skill levels, knowledge and
    numbers required to support the modified CI.

-   New operator and maintenance training requirements in terms of
    training equipment, trainers and training software for operator and
    maintenance courses. This information should include identification
    of specific courses, equipment, technical manuals, personnel, etc.
    required to set up the course at either the contractor or Government
    facility.

-   Effect on contract maintenance that increases the scope or dollar
    limitation established in the contract.

-   Effects on packaging, handling, storage, and transportability
    resulting from changes in materials, dimensions, fragility, inherent
    environmental or operating conditions. For Class I Only

```{=html}
<!-- -->
```
-   *ECP Other Impacts*, the effects of the proposed engineering change
    on the following shall be identified:

```{=html}
<!-- -->
```
-   Interfaces having an effect on adjacent or related items (output,
    input, size, mating connections, etc.).

-   GFE or Government Furnished Data (GFD) changed, modified or
    obsolete.

-   Physical constraints. Removal or repositioning of items, structural
    rework, increase or decrease in overall dimensions.

-   Software (other than operational, maintenance, and training
    software) requiring a change to existing code and/or, resources or
    addition of new software.

-   Rework required on other equipment not included previously which
    will effect the existing operational configuration.

-   Additional or modified system test procedures required.

-   Any new or additional changes having an effect on existing
    warranties or guarantees.

-   Changes or updates to the parts control program.

-   Effects on life cycle cost projections for the configuration item or
    program, including projections of operation and support
    costs/savings for the item(s) affected over the contractually
    defined life and projections of the costs/savings to be realized in
    planned future production and spares buys of the item(s) affected.

> For Class I Only.

-   *ECP Other Configuration Item Impact,* identify other systems
    affected by the proposed change that are outside the purview of the
    originator. Indicate whether the effect on other systems or CIs
    requires the submittal of related Class I ECPs. For Class I Only.

```{=html}
<!-- -->
```
-   *ECP Other Configuration Item ID*, the unique identification of
    other configuration items affected by the proposed change.

-   *ECP Other Configuration Item Impact Description,* the effects of
    the proposed change to other configuration items affected by the
    proposed change.

```{=html}
<!-- -->
```
-   *ECP Lower Level Item Impact*, identify lower level CI, CSCI, or
    parts affected, and the quantity and NSN of each part, where
    applicable. For Class I Only.

-   *ECP Activity Impact*, identify other contractors or Government
    activities that will be affected by this engineering change. For
    Class I Only.

-   ECP Affected Document, if drawings or other product configuration
    documents that are ordered, or provided by the government are
    affected by the ECP, their identity by the CAGE code of the design
    activity, document number, revision letter, and, if applicable, the
    NOR number of the NOR being submitted with the ECP.

```{=html}
<!-- -->
```
-   Document Identification,

-   *ECP Associated NOR*, a role of *Document Identification* that
    uniquely identifies the associated Notice of Revision document.

```{=html}
<!-- -->
```
-   *Engineering Change Proposal Associated Contract*, the data
    pertaining to the associated contract.

```{=html}
<!-- -->
```
-   ECP Contract Number, and ECP Contract Line Item,

-   *ECP Contract Procuring Officer,* Procuring Contracting Officer\'s
    name, code, and telephone number. For Class I Only.

-   *ECP Contract Authority Required Date*, date contractual authority
    is required in order to maintain the established production
    schedule. For Class I Only.

-   *ECP Contract Retrofit Authority Required Date*, date contractual
    authority is needed to accomplish retrofit as proposed. For Class I
    Only.

```{=html}
<!-- -->
```
-   *Engineering Change Proposal Cost Impact*, data associated with the
    cost impact of the proposed engineering change. For Class I Only.
    This data could be in a free form text string or attached file.

```{=html}
<!-- -->
```
-   *ECP Production Cost*, estimated costs/savings applicable to
    production of the item resulting from the change.

```{=html}
<!-- -->
```
-   *ECP Production Cost Data,* estimated costs/savings applicable to
    production of the item resulting from the change. Includes the costs
    of redesign of the CIs or components thereof, of factory test
    equipment, of special factory tooling, of scrap, of engineering
    design, of engineering data revision, of revision of test
    procedures, and of testing and verification of performance of new
    items

```{=html}
<!-- -->
```
-   *ECP Retrofit Cost*, estimated costs applicable to retrofit of the
    item including installation and testing costs.

```{=html}
<!-- -->
```
-   *ECP Retrofit Cost Data* includes retrofit-specific engineering data
    revision, prototype testing, kit proof testing, purchase of retrofit
    kits for operational systems, preparation of modification
    instructions, design and manufacture of special tooling for
    retrofit, installation of kits by contractor personnel, installation
    of kits by government personnel, testing after retrofit and
    modification, and testing and verification of performance of
    Government Furnished Equipment/Property (GFE/GFP).

```{=html}
<!-- -->
```
-   *ECP Logistics Cost*, estimated costs/savings of the various
    elements of logistics support applicable to the item.

```{=html}
<!-- -->
```
-   *ECP Logistics Cost Data*, estimated costs/savings of the various
    elements of logistics support applicable to the item. Includes
    spares/repair parts rework, new spares and repair parts,
    supply/provisioning data, support equipment, retrofit kit for
    spares, operator training courses, maintenance training courses,
    revision of technical manuals, new technical manuals,
    training/trainers, interim support, maintenance manpower, and
    computer programs/documentation.

```{=html}
<!-- -->
```
-   *ECP Other Cost*, Includes estimated costs of interface changes
    accomplished by other contractor activities.

```{=html}
<!-- -->
```
-   *ECP Other Cost Data* includes estimated costs of interface changes
    accomplished by other contractor activities. (Do not include costs
    if the changes are covered by related ECPs by other contractors.
    Also includes estimated costs of interface changes accomplished by
    the Government for changes which must be accomplished in previously
    delivered items (aircraft, ships, facilities, etc.), other
    interfacing products, and/or retrofit of GFE/GFP, to the extent that
    such costs are not covered under production, retrofit, or logistics
    support.

```{=html}
<!-- -->
```
-   *ECP Total Cost*, total estimated cost of changes proposed through
    the engineering change.

```{=html}
<!-- -->
```
-   *Engineering Change Proposal Milestones* includes the sequence of
    events and milestones for implementation of the engineering change.
    This could be in a free form text string or attached file. For Class
    I Only.

-   *Engineering Change Proposal Distribution*, the data used to
    indicate the authorized circulation or dissemination of the
    engineering change document.

###### ChangeDirective.dtd

The Change Directive dtd describes a document issued by a change control
entity to dispositions a change (such as an engineering change proposal
or a request for variance or RFD) and may issue directions for
implementation, if applicable. The root element Change Directive
consists of the following elements:

-   *Document Identification* (see Document Identification oblet) of the
    Change Directive

-   *Change Control Entity*, which invokes the Change Control Entity
    oblet to identify the entity making the change control decision

-   *Program-Project Identifier*, which uniquely identifies a program or
    project.

-   And one or more of the following sequence of elements

```{=html}
<!-- -->
```
-   *Product Identification*, which invokes the Product Identification
    oblet to uniquely identify the product that is associated with the
    change decision

-   One or more occurrences of *Document Reviewed*, invoking the
    Document Identification oblet to identify a document reviewed by the
    change control entity. The attributes *Document Type* (Change
    Proposals, Request for Variance, Specifications, etc) and
    *Disposition Status Code* (Approved, Disapproved, Deferred, or
    Concur) categorize the document and provide the change control
    entity's decision concerning it.

-   *Discussion Minutes-Text* captures the discussion of a change
    control entity concerning each document being considered

-   *Change Decision Date and Time* invokes the DateTime oblet to
    indicate when that a change decision was rendered, the time
    providing the decision sequence

-   Zero or one \[Should change to zero or more in next Rev\]
    occurrences of *Implementing Action Assignment Action* assigned to
    complete the implementation of a change invoke the Action Item dtd
    for documentation and tracking of the assigned action

###### SpecificationChangeNotice-Def.dtd

The Specification Change Notice Defense dtd is used to record and
transmit approved change pages to an existing paper specification. Once
an Engineering Change Proposal (ECP) has been approved and the
associated Notice Of Revision (NOR) has been incorporated by the
specification custodian, the SCN provides official notice to holders of
the specification that the attached change pages can be incorporated
into their copy(ies) of the specification. The dtd is based on Data Item
Description (DID) DI-CMAN-80643C.

The root element *Specification Change Notice --Def* consists of five
elements corresponding to the parts of the SCN, *SCN Identification, SCN
Associated ECP, SCN Change Pages, SCN Associated SCN, and SCN Associated
SCN Change Pages*.

-   *SCN Identification* provides the data and metadata that uniquely
    identifies an SCN, including the elements SCN Number (a role of
    *Document Identification* that uniquely identifies an SCN), *SCN
    Submittal Date*, *SCN Originator*, and *SCN Specification* (the data
    and metadata used to uniquely identify the Specification affected by
    the SCN). *SCN Specification* includes elements SCN Specification
    Title, SCN Specification Identification (the unique *Document
    Identification* for the specification), and SCN Specification
    Custodian.

-   *SCN Associated Engineering Change Proposal*, provides the *Document
    Identification* for the associated ECP

-   *SCN Change Pages* includes one or more occurrences of the element
    *SCN Changed Page* and its attributes *Change Type* (Replace, Add or
    Delete) and *Approval Date* to provide the number of specification
    change pages associated with the SCN and the type of action required
    for each page.

-   The element *SCN Associated SCN* provides the Document
    Identification for one or more other SCNs that are associated with
    the specification that have been previously issued; *SCN Associated
    SCN Change Pages* provides the change page information related to
    those SCNs

###### DocumentRevisionNotice.dtd

The Document Revision Notice dtd describes a multi-purpose instrument to
document a change or revision to a document of any kind, to attach to a
proposal for approval of that change, and to issue that change to the
users of the document to effect the revision. [Note]{.underline}: The
DRN contains all the elements necessary to serve as a change notice to a
product requirements object engineering change document, documenting a
change to an engineering design object, or a notice of revision to a
product requirements object or engineering design object. It is an
EIA-836 commercial equivalent to the SCN-Def, the NOR-def, and the
Engineering Order (EO), also known as ECO, ECN and other names. Trading
partners can rename this Business Object to suit specific purposes.

The root element *Document Revision Notice* has an attribute *Document
Revision Notice Type* that indicates whether the DRN is proposed or
approved and released, and the following elements *DRN Number*, *DRN
Date*, *DRN Originator Address*, *DRN Associated Change Proposal*,
*Associated Product*, *Document Being Revised*, *New Revision
Identifier*, *DRN Revision Description*, and *Product Protection*.

-   *DRN Number* a role of Document *Identification* providing an
    identifier assigned by the originator to uniquely identify the DRN.

-   *DRN Date*, date appearing on a document revision notice

-   *DRN Originator*, name, address, and organization of the activity
    originating a document revision notice.

-   Optional *DRN Associated Change Proposal*, A change proposal to
    which a document revision notice is associated.

-   Zero or more occurrences of *Associated Product*, each providing the
    *Product Identification* of a product with which the DRN is
    associated

-   Document Being Revised, The unique *Document Identification* for a
    document that is being revised.

-   New Revision Identifier, The revision identifier assigned to a
    document being revised. The attribute *Type Of Revision* categorizes
    the revision as a complete revision or an amendment.

-   *DRN Revision Description*, the comprehensive record of the change,
    including the reason for making it and the record of what is changed
    as a result of incorporating the DRN.

```{=html}
<!-- -->
```
-   Reason For Revision, a textual reason why a revision was created

-   Optional Revision Summary Description, a brief description of the
    changes to a document.

-   Revision Detail Description, a complete detailed description of the
    changes to a document. The attribute *Revision Detail Type*
    indicates the means by which the detail description is provided,
    i.e., Revision Red Line, From-To Description, Change Pages, Change
    Paragraphs.

-   Optional element *Attached Revision* is used when a revised
    document, which incorporates the changes prescribed by one or more
    DRNs is distributed with a DRN. The Attached Revision element
    includes one or more File elements (invoking the File oblet) and one
    or more Incorporated DRN elements, providing Document Identification
    of each of the DRNs that incorporated in the new revision.

-   *Associated DRN*, *Document Identification* of zero or more approved
    unincorporated DRNs for the affected document that are to be
    incorporated in the document in its next revision.

```{=html}
<!-- -->
```
-   And *Product Protection*, invoking the Product protection oblet to
    accommodate any security, data rights, distribution restrictions,
    etc.

###### NoticeOfRevision-Def.dtd

The Notice Of Revision -- Defense dtd describes the proposed changes to
a technical document being requested by an Engineering Change Proposal
(ECP). It is in accordance with Notice Of Revision, Data Item
Description (DID) DI-CMAN-80642C and guidance for it is provided in
MIL-HDBK-61A (SE). The root element *Notice of Revision -- Def* contains
elements *NOR Identification*, *NOR Associated ECP, System Or
Configuration Item*, *NOR Affected Document*, and *NOR Change
Description*.

-   *NOR Identification,* data and metadata that identifies a NOR,
    consisting of elements

```{=html}
<!-- -->
```
-   *NOR Number*, NOR *Document Identification* assigned by the
    originator, unless the use of a Government assigned number is
    prescribed. NOR Associated ECP Number

-   *NOR Procuring Activity Number*, used when provided by Procuring
    Activity (Army only).

-   *NOR Originator*, Name, address, and CAGE Code of the activity
    submitting the NOR.

-   *NOR Submittal Date*, submittal date of the NOR or NOR Revision.
    Normally this date will be identical to the ECP submittal date.

```{=html}
<!-- -->
```
-   *NOR Associated ECP, System or Configuration Item*, Government
    assigned system designation (if any); or the name and type
    designation of the Configuration Item to which the ECP applies.

-   *NOR Affected Document*, the data and metadata that identifies the
    documents affected by the NOR. Subordinate elements are *NOR
    Document Title*, *NOR Document Number* (number of the drawing,
    standard, specification, list or other document to which the NOR
    applies), *NOR Design Activity CAGE* (for both current and
    originating design activities), *NOR Unincorporated NOR*
    (Identifying all approved unincorporated NORs for the affected
    document).

-   *NOR Change Description* providing exact wording of sentences or
    paragraphs that are to be added, or that are to replace designated
    sentences or paragraphs of the current document.

###### ChangeCommitmentRecord.dtd

The Change Commitment Record dtd will be added in the next revision. It
will provide the information elements and relationships concerned with
identifying recording the commitment of the participants in implementing
a change to the change implementation planning.

###### ChangeImplementationPlan.dtd

The Change Implementation Plan dtd will be added in the next revision.
It will provide the information elements and relationships concerned
with planning the implementation of an engineering change.

## 6.4 Configuration Status Accounting Business Objects

###### ChangeProcessStatusReport.dtd

The Change Process Status Report dtd will be added in the next revision.
It will provide the information elements and relationships concerned
with managing engineering changes.

###### Part-MaterialUsageReport.dtd

The Part-Material Usage Report dtd will be added in the next revision.
It will provide the information elements and relationships concerned
with maintaing "where used" records.

###### ChangeIncorporationReport.dtd

The Change Incorporation Report dtd will be added in the next revision.
It will provide the information elements and relationships concerned
with maintaining status of the incorporation of engineering changes.

###### AsBuiltStatusReport.dtd

The As-Built Status Report dtd will be added in the next revision. It
will provide the information elements and relationships concerned with
as-built records.

###### ConfigStatusAcctingReport-Def.dtd

The Configuration Status Accounting Report -- Defense, the recording and
reporting of information needed to manage configuration items
effectively, including:

-   A record of the approved configuration documentation and
    identification numbers.

-   The status of proposed changes, deviations, and waivers to the
    configuration.

-   The implementation status of approved changes,

-   The configuration of all units of the configuration item in the
    operational inventory.

This dtd is in accordance with DI-CMAN-81253A and guidance in
MIL-HDBK-61A (SE).

The root element *Configuration Status Accounting Report -- Def*
consists of the elements

*CSA Record Identification, CSA Associated Contract,* and *CSA
Associated CI,* and a repeatable choice between the following elements:
*CSA Performance Specification, CSA Design Document, CSA Software
Document, CSA Support Document, CSA Product Identifier, CSA Product
Installed Parts, CSA Engineering Changes, CSA Deviations*, and *CSA
Configuration Audit.*

-   The *CSA Record Identification* element provides the data that
    uniquely identifies the CSAR. It consists of the elements *CSA
    Record Number* (a role of *Document Identification* that uniquely
    identifies the CSAR), CSA Record Date (CSAR issue date), and *CSA
    Record Originator* (the *Organization* that originated the CSAR).

-   The *CSA Associated Contract* element provides the association of
    the report to a specific contract *Document Identification.*

-   The *CSA Associated Configuration Item* element provides the
    association to configuration item identifier, which includes an
    alphanumeric designation and/or a noun name.

-   If applicable, the element *Performance Specification* identifies
    the Performance Specification(s) pertaining to the associated
    contract and CI . It includes *Document Identification*, *Related
    SCN* and *Related ECP.*

-   If applicable, *CSA Design Document* identifies the design
    documentation and related ECPs pertaining to the associated contract
    and CI.

-   If applicable, *Software Document* identifies the software
    documentation and related ECPs pertaining to the associated contract
    and CI.

-   If applicable, *Support Document* identifies supporting
    documentation and related ECPS pertaining to the associated contract
    and CI.

-   The element *CSA* *Product Identifier* is a role of *Product
    Identification* that uniquely identifies the Product the CSAR is
    related to.

-   The element *Product Installed Parts*, includes the effectivity of
    installed parts related to the Product/CI.

-   *Engineering Changes*, is an element that correlates the ECPS and
    the Product/CI covered by the CSAR.

```{=html}
<!-- -->
```
-   *Related* *Engineering Change Proposal* provides the documentation
    in which the engineering change is described.

-   *Change Status* and attribute *Change Status Code* indicate the
    status (Release for Submittal, Submitted, Approved, Approved with
    Conditions, Disapproved, and Deferred) of the Engineering Change
    Proposal (ECP), Request for Deviation/Waiver (RFD/RFW).

```{=html}
<!-- -->
```
-   *Deviations*, the Deviation Requests related to the Product/CI
    covered by the CSAR.

-   *Configuration Audit Report*, the Configuration Audit Report related
    to the Product/CI covered by the CSAR.

-   *Specification Change Notice,* used to record and transmit approved
    change pages to an existing paper specification., related to product
    specifications

-   *Request For Deviation Status* and attribute *Request ForDeviation
    Status Code*, the status of the RFD referenced in the CSAR.

###### InstallationCompletionNotice.dtd

The Installation Completion Notification Defense dtd describes the
Installation Completion Notification (ICN) used to report field
accomplishment of retrofit changes by contractor personnel as required
by an approved Engineering Change Proposal (ECP). The notification is
provided to the Government when the Government is maintaining the
configuration status accounting information about the configuration of
units in the operational inventory. The reporting of the installation of
retrofit kits in the field by the contractor during the acquisition
phase and prior to the end of operational test and evaluation is
required to verify the status of delivered configuration items
subsequent to Government product acceptance. Informative Ref: Data Item
Description (DID) DI-CMAN-81245A and MIL-HDBK-61A (SE). The ICN will be
described in the next revision.

## 6.5 Configuration Verification And Audit Business Objects

###### AsDesigned-AsBuiltReconciliationReport.dtd

The As Designed -- As Built Reconciliation Report dtd will be added in
the next revision. It will provide the information elements and
relationships concerned with the reconciliation of as-designed and
as-built configuration records.

###### ConfigAuditReport.dtd

The Configuration Audit Report dtd describes a document containing the
results of one or more configuration audits. The root element
Configuration Audit Report consists of the elements Document
Identification (which invokes the Document Identification oblet to
define the identification of the audit report), one or more occurrences
of the element Configuration Audit (which invokes the Configuration
Audit Action dtd to delineate all the information relationships
concerned with an audit and follow-up action items), and if applicable,
the Product Protection oblet.

###### ConfigAuditSummaryReport-Def.dtd

The Configuration Audit Summary Report -- Defense dtd describes the
Configuration Audit Summary Report, which provides text and marked-up
technical documents (e.g., specifications, engineering drawings), which
identify discrepancies between the material (including software) and the
requirements delineated in the applicable technical documents. Depending
on the type of audit, the identified discrepancies may be attributable
to the material, technical documents, or both. Informative Ref:
DI-CMAN-81022C and MIL-HDBK-61A(SE).

The Configuration Audit Summary Report -- Defense dtd will be described
in the next revision.

## 

## 6.6 Data-Document Management Business Objects

###### CommentToDocument.dtd

The Comment To Document dtd describes the complete content of a comment
to a document that is in a review process, as well as the data and
metadata related to the comment. The root element *Comment To Document*
consists of the following elements:

-   *Document Identification Source, Document Number, and Document
    Title*

-   *Draft Document Revision Representation Identifier*, a string
    element that provides a unique identifier to the representation of
    the draft offered for review

-   *Reviewer Identifier*, a Person, with the attribute Reviewer Role
    (Peer, Superior, Subordinate, User, Application Activity, Lead
    Application Activity, CDCA, Interested Party)

-   An optional string element *Reviewer Recommendation*, to capture a
    reviewers recommendation as to whether the document should be
    approved or disapproved, or other appropriate recommendation

-   Optional *Comment File Identifier* element, which is the filename of
    a file containing one or more occurrences of *Document Comment*

-   *Comment Identifier*, a string element providing for a comment
    number or other identification *Comment Date*, the date of the
    comment

-   *Comment Reference*, a string element citing the page, section,
    paragraph, line, figure, table or other portion of the document that
    is being commented to

-   *Comment Category*, Categorization of the comment as to its relative
    importance. Comment Category Code essential, suggested, or
    editorial.

-   *Comment Text*, a string element for the text of the comment

-   *Comment Justification*, a string element for the reason for making
    the comment

###### DocumentCommentDisposition.dtd

The Document Disposition dtd provides a record of a comment to a
document that is in a review process, and a record of the disposition of
that comment by a comment reviewer. consists of the

Elements:

-   *Comment To Document*, links to the Comment To Document dtd.

-   *Comment Disposition*, the present disposition of an identified
    comment to a document, expressed by the attribute Comment
    Disposition Code (Approved, Approved with Change, Rejected, Defer)

-   *Comment Dispositioned By*, Person who dispositioned the comment

-   *Comment Disposition Date*

-   *Comment Disposition Rationale*, reason for rejecting a comment.

-   *Comment Incorporation Note*, when or in what revision the comment
    will be incorporated

###### DocumentTransfer.dtd

The Document Transfer dtd represents all of the information needed to
transfer or provide access to any document. The root element *Document
Transfer* is a \"container\" element that provides a mechanism for
document sharing between business partners. Documents can be shared
either by including them as an attachment to the Document Transfer
Business Object or by providing the information needed to access the
document. It consists of the element, *Universal Document Data*, which
invokes the Universal Document Data dtd, and the attribute *Transfer
Method*, the method of sharing (Access, Attachment).

## 6.7 General Business Objects

###### ManufacturingPlan.dtd

The Manufacturing Plan dtd describes a document addressing the
assignment of responsibility and the work instruction for producing or
assembling a product. (Aliases, nearly equivalent, or closely associated
terms are Operation Sheet, Work Order.) The root element *Manufacturing
Plan* consists of three elements *Document Identification* (which
invokes the Document Identification oblet), *Issue Date*, and one or
more instances of *Work Instruction*.

The element *Work Instruction* provides one or more in a series of
assignments of responsibility and specific instructions for producing, a
product, such as fabricating, assembling, reworking, and inspecting. Its
required attribute *Assignment Category* designates the choice between
Normal Production, Out Of Station Production, or Retrofit Operation.
This information is significant because many configuration verification
processes require verification feedback on a new change until its
incorporation has been verified in the normal production workflow for a
designated number of units. Work Instruction consists of the following
sequence of elements:

-   *Work Station*, the location at which the work instruction is to be
    accomplished, such as a shop, laboratory, facility, or a designated
    location in an assembly line process.

-   *Organization*, using the organization oblet to identify the
    activity assigned the responsibility for accomplishing the work
    instruction at the assigned workstation.

-   *Higher Product*, the specific assembly or component higher in the
    product structure in which a specific product is to be installed,
    attached or embedded.

-   *Manufacturing Effectivity*, the specific effectivity of a higher
    product for which a work instruction is assigned. It invokes the
    Effectivity oblet

-   And a choice between Create Product and Rework Product

```{=html}
<!-- -->
```
-   Create Product applies when the work instruction is to produce a new
    product as opposed to reworking an old product. It consists of the
    elements:

```{=html}
<!-- -->
```
-   *Product Identification*,

-   *Product Type*,

-   *Product Quantity*, the quantity of a product that applies to a
    specific higher product.

-   *Due In Stock Date*, when a product or a grouping of like products
    such as a lot or batch is scheduled to complete its
    manufacturing/production process.

```{=html}
<!-- -->
```
-   Rework Product applies when the work instruction is to rework a
    product to a new configuration. It consists of the elements:

```{=html}
<!-- -->
```
-   *Old Product Identification*, the *Product Identification* of the
    product to be reworked (the \"from\" configuration).

-   New Product Identification, the Product Identification to be
    assigned to the product after rework (the \"to\" configuration).

-   And the elements *Product Type*, *Product Quantity*, *Due In Stock
    Date*

###### ModificationInstruction.dtd

The Modification Instruction dtd provides the information and
instructions used to effect modification of a completed or in-service
product. This schema defines the metadata and content of a modification
instruction. The root element *Modification Instruction* has an
attribute *Modification Instruction* *Type* categorizes a modification
instruction reflecting the source, origination and unique requirement
for format and content by indicating if it is a Technical Directive
(Navy), Time Compliance Technical Order (Air Force), Modification Work
Order (Army), Service Bulletin, Recall and Replacement Instruction, etc.
Modification Instruction consists of:

-   *Universal Document Data* links the Universal Document data dtd, and
    optional element *Compliance Standard Document* applies when
    compliance to a standard is required.

-   The sequence of date elements pertaining to the Modification
    Instruction document: *Issue Date*, *Effective-Date* (date it
    becomes effective for use), and *Rescission Date* (when it is
    anticipated that the modification instruction will have completely
    served its purpose).

-   And one or more occurrences of the following sequence of elements:

```{=html}
<!-- -->
```
-   One or more instances of *Product To Be Retrofit*, a role of
    *Product Identification*

-   *Modification Description Text*, the specific modifications to be
    made to a product.

-   *Modification Installation Work Hours*, the time in work hours
    required to install a retrofit kit.

-   *Modification Test Work Hours*, the time in work hours required to
    conduct tests of modified equipment after retrofit.

-   *Modification Kit Identification*, Product Identification for the
    Modification Kit

-   *Kit Parts List or Bill Of Materials*, list of the parts and or
    materials that are included in a retrofit kit. Typically, the
    KPL/BOM is part of the modification instruction. It provides the
    *Product Identification* and *Quantity Per Kit* for each part.

###### ModKitValidationReport.dtd

The Modification Kit Validation Report dtd will be added in next
revision.

###### MaintenancePlan.dtd

The Maintenance Plan dtd will be added in the next revision

###### ProductDelivery-AcceptanceReport.dtd

The Product Delivery And Acceptance Record dtd provides a product\'s
as-delivered record. It contains the data such as shipping/delivery
date, location, record identifier, date it was placed in stock, and
material/process certification. The root element *Product Delivery And
Acceptance Record* has an attribute *Delivery Location Code* that
indicates (Destination or Source) where the product will be inspected
and accepted. It consists of the following sequence of elements:

-   If applicable, *Document Identification*, identifying the Acceptance
    Record document that records the official acceptance of a product.
    (It could be a DD-250 or equivalent)

-   *Product Instance* (See Product instance oblet) identifying the
    delivered product

-   *Acceptance Date*

-   Zero or more occurrences of *Test Documentation*, to be delivered
    with a product. It consists of *Test Procedure*, *Test Report*, and
    *Test Data.*

-   Zero or more occurrences of *Variances Noted* -- any anomalies noted
    during testing and inspection

-   *Shipping or Delivery Date*, the date that a product unit was
    shipped, or delivered to a using location.

-   *Shipping Location*, a role of Address that identifies the location
    to which a product is shipped.

-   Optional *Shipping Record Identifier*, identifies the record of
    shipments such as a Bill of Lading or Postal or shipping company
    tracking identifier

-   *In Stock Date*, the date that an item is to be delivered and ready
    for use.

-   Zero or more occurrences of *Material and Process Certification*, a
    quality control document that certifies the composition of a
    material or the completion of a process in accordance with a
    specified requirement. Certifications are mandated to accompany
    shipped products or materials by regulations in many instances.

###### KitShipmentReport.dtd

Kit Shipment Report dtd provides the metadata associated with the
shipment of retrofit kits.

The root element *Kit Shipment Report* has one or more occurrences of to
uniquely identify each modification kit instance and provide information
on its status via the attribute *Kit Status* (Assembled, Shipped,
Available for Installation, or Installed)

*Modification Kit Instance Information* consists of *Modification Kit
Instance*, *Shipping Date*, *Shipping Record Identification*, and
*Shipping Location.*

# 7. Application Notes

Note 1 --- One goal of EIA-836 is to standardize the terminology used in
CM information and relationships to the extent that there is a neutral
reference vocabulary for the e-business environment that can provide the
basis for compatibility between dissimilar systems. Another goal is to
provide "Business Objects" that can be used "out of the box" for
information exchange, or modified by users. Having a standard template
for these objects can help to accelerate the time it takes to establish
a working interface among trading partners. The overarching objective
however is to promote a broader understanding of configuration
management relationships and the full breadth and scope of configuration
management information. To accomplish this, it is necessary for the
standard to be able to be understood by a variety of users ranging from
CM practitioners with no data modeling experience to sophisticated tool
vendors and to encompass a broad spectrum of industry and government.
The benefits that accrue, when these goals are met are expected to be a
long term legacy of

-   CM data interoperability

-   Improved information systems

-   Compatible CM/PDM tools and systems

-   Rapid ad hoc CM data exchange (SMEs to mega corporations)

-   Easier integration of extended enterprises

-   Reduced CM costs; expanded CM information resulting in reduced
    product life cycle cost and risk.

Note 2 --- EIA-836 is a work in progress that is evolving. It is web
accessible and dynamic, but also has a pdf version, which facilitates a
printed version (without some of the "bells and whistles"). Each draft
has emerged in a different form and with additional capabilities. It is
advancing with technology. For example, the current revision shows
reference schemas and business object schemas as document type
definitions (dtds). It is expected that later editions may show the
Business Objects as XML documents. With at least one style sheet example
for each, and it is probable that the user may be able to choose from a
variety of XML formats.

# Annex A. CM Data Dictionary

## A.1 Scope

This annex provides an alphabetical listing of all of the Data Elements
and attributes in EIA-836 and their definitions, as contained in the
reference schemas in Clause 5 and the Business Objects in Clause 6.
Clicking on the link below accesses the listing:

## [[]{#__RefHeading___Toc514502257 .anchor}EIA-836 Annex A. CM Data Dictionary](../ElementListReport.doc) 

## A.2 Data Dictionary Content 

For each element name, a reference to the originating reference schema
is provided. In some cases elements and attributes with multiple use
throughout the reference schema have been elevated to their highest
point of use to avoid redundancy and eliminate parsing errors.

The dictionary contains known aliases for the elements listed as well.
Any business object data elements that are not in the reference schemas
are also included in the dictionary.

The fields of information in the data dictionary are as follows:

-   **Formal Name** -- is the English language format for the data
    element name, which has each word spelled out and separated by a
    space from the adjoining word.

-   **Element Name** -- is the truncated name for the data element as
    used in the schemas. The first letter of each word is capitalized
    and there are no spaces between words except for hyphens or
    underscores.

-   **Definition** -- is the meaning of the data element in the context
    of this standard including, where applicable:

```{=html}
<!-- -->
```
-   Normative and informative references to source documents,

-   Known aliases for the terminology used in the data element naming,
    and

```{=html}
<!-- -->
```
-   **DTD File --** is the reference to the schema or business object
    from which the data element originates.

# Annex B. EIA-836 User Guidance (Informative)

## B.1 Scope

This annex will contain descriptive information supporting both users
and maintainers of EIA-836)

## B.2 How To Read EIA-836 Schemas 

The schema files can also be viewed in any text editor, e.g., Microsoft
Notepad, Wordpad, or Word. For this draft, refer to the following
powerpoint presentation for reference on how to read the graphical and
text versions of EIA-836 dtds.

## [[]{#__RefHeading___Toc514502262 .anchor}EIA-836 Schema Guide](../EIA-836SchemaGuideR0.3.ppt)

## 

## B.2.1 XML Element Content Model

There are five possible content model types for XML elements:

-   Child elements only,

-   Parsed character data only,

-   Mixed content, which can include both child elements and parsed
    character data,

-   ANY, which allows any combination of child elements and parsed
    character data, and

-   EMPTY, i.e., the element contains no content.

The difference between the mixed and ANY content types is that the mixed
content type requires the allowable child elements to be specified in
the element declaration, whereas the ANY content type does not. EIA-836
XML elements are generally limited to child elements only and parsed
character data only, i.e., no mixed, ANY, or EMPTY elements.

## B.2.2 XML Element and Attribute Datatyping

Data element datatypes typically correspond to constraints on the data
values from a business perspective, for example, YYYMMDD for Date, where
MM is limited to the range 00 though 12. Some data value constraints
placed on data elements to facilitate database design and data storage
are covered under "Field Characteristics".

## B.2.3 XML Attribute Usage

There is very little consensus within the XML development community as
to when it is appropriate to use XML attributes versus XML elements.
Attributes may be appropriate for representing atomic properties of
elements. EIA-836 Attribute use is limited to metadata about the content
of its associated element's content model. Metadata can include content
model datatype, identification references, and other "atomic" properties
associated with the character data or child elements of the associated
element.

# Annex C. Data Element -- Alias Cross-Reference

## C.1 Scope

This annex provides an alphabetical cross reference listing between the
aliases to the data element names and attributes in EIA-836 contained in
the Reference Schemas in Clause 5 and the Business Objects in Clause 6
identified to date, and the element names.

## C.2 Alias Cross-Reference Content 

The fields of information in the Alias Cross-Reference list are as
follows:

-   **Alias Name** -- is the alias for the data element name

-   **Element Name** -- is the truncated name for the data element as
    used in the schemas. The first letter of each word is capitalized
    and there are no spaces between words except for hyphens or
    underscores.

  -----------------------------------------------------------------------
  **[ALIAS NAME]{.underline}**        **[SCHEMA ELEMENT
                                      NAME]{.underline}**
  ----------------------------------- -----------------------------------
  Abandonment Date                    TrademarkExpirationDate

  Application File Date               PatentDate

  Application Number                  PatentNumber

  Approved ECP                        ApprovedChangeProposal

  As-Planned Baseline                 Planning-ProcessBaseline

  Assignee                            PatentHolder

  Company Proprietary Data Rights     USDataRightsCode
  Code                                

  Company Proprietary Data Rights     DataRightsStatement
  Text                                

  Concession                          Variance

  Configuration Control Board (CCB)   ChangeBoardName

  Desription of Mark                  TrademarkItem

  Deviation                           Variance

  Electronic Storage Place Identifier FileLocation

  Enterprise Acronym                  OrganizationAcronym

  Enterprise Code                     OrganizationCode

  Enterprise Name                     OrganizationName

  Expiration Date                     CopyrightExpDate

  Family Name                         LastName

  Filing Date                         TrademarkIssueDate

  Inventor                            PatentHolder

  Next Higher Assembly                NextHigherProduct

  Operation Sheet                     ManufacturingPlan

  Part Product Identifier             SoftwareAlphanumericIdentifier

  Patent Mark                         PatentStatus

  Patronymic                          LastName

  Personal Property                   RealProperty

  Proprietary Data Rights Code        DataRightsCode

  Real Estate                         RealProperty

  Registered Date                     CopyrightDate

  Registration Date                   TrademarkIssueDate

  Related Personal Property           RealProperty

  Service Life Period                 ServiceLife

  Service Life Period                 ServiceLifeDuration

  Service Life Value                  ServiceLife

  Service Life Value                  ServiceLifeDuration

  Software Document Identifier        SoftwareName

  Software Product Basic Suffix       SoftwareName
  Identifier                          

  Surname                             LastName

  Technical Government Data Rights    DataRightsCode
  Code                                

  Technical Government Data Rights    USDataRightsCode
  Code                                

  UOM                                 UnitOfMeasureCode

  Waiver                              Variance

  Work Order                          ManufacturingPlan
  -----------------------------------------------------------------------

# Annex D. Data Element -- UDEF Cross-Reference

## D.1 Scope. 

This Annex provides a Universal Data Element Framework (UDEF) name and
code for each data element name in EIA-836.

## D.2 Data Element-UDEF Cross Reference Content

**TBD**

# Annex E. EIA-836 Data Type Definitions

## E.1 Scope. 

This Annex provides a complete set of all the Data Type Definitions
(dtds) in EIA-836.

[EIA836.dtd](../EIA-836DTDFiles010516/EIA-836.dtd)

## E.2 Data Type Definition List

The text file dtds will be inserted in this Annex in a later revision.
They are currently included in the Live EIA-836 files that are provided
in the EIA-836 Draft 0.3 Download.

[Live EIA-836](../WebEIA-836DraftRev0.3/_WebEIA-836index.html)

[^1]: EIA-836 uses the term "schema" in the generic sense of data
    relationships or structures; it should not infer an association with
    the W^3^C XML Schema Candidate Recommendations.