ARMED SERVICES BOARD OF CONTRACT APPEALS 
Appeals of --
AEON Group, LLC 
Under Contract No. HQ0423-04-C-0003 
APPEARANCE FOR THE APPELLANT: 
) 
) 
) 
) 
) 
APPEARANCES FOR THE GOVERNMENT: 
ASBCA Nos. 56142, 56251 
Michael R. Rizzo, Esq. 
McKenna Long & Aldridge LLP 
Los Angeles, CA 
Neil Bloede, Esq. 
Thomas S. Tyler, Esq. 
Snider Page, Esq. 
Trial Attorneys 
Defense Finance and Accounting Service 
Indianapolis, IN 
OPINION BY ADMINISTRATIVE JUDGE DICKINSON 
AEON Group, LLC, (AEON) appealed in ASBCA No. 56142 from the termination 
for default by the Defense Finance and Accounting Service (DFAS or government) of 
Contract No. HQ0423-04-C-0003 for the "rehosting" of the Department of Defense 
(DoD) Mechanization of Contract Administration System (MOCAS) from its existing 
software platform to a new platform. AEON appealed in ASBCA No. 56251 from the 
government's final decision and demand to 
recover unliquidated performance-based 
payments in the amount of $12,905,117.22. The parties' previous cross-motions for 
summary judgment were denied. AEON Group, LLC, ASBCA Nos. 56142, 56251, 09-2 
BCA if 34,263. We have jurisdiction under the Contract Disputes Act (CDA), 41 U.S.C. 
§§ 7101-7109. Only entitlement is before us. 
FINDINGS OF FACT 
A. Background, Solicitation and Proposal 
1. The MOCAS system at issue in these appeals is a "Critical system in the DoD 
contracting and entitlement process supporting the Warfighter, Homeland Security and 
Disaster relief' (app. supp. R4, tab 281 at 6). MOCAS is used by DoD for two primary 
purposes: by the Defense Contract Management Agency (DCMA) for contract 
administration, quality assurance, property management, contract payments and financial 
administration; and, by DF AS to provide accounting services and payment functions for 

wages and contracts. 1 Over 8600 users ofMOCAS enter data into the system on-line 
during the day; a batch cycle runs at night and the system then automatically generates 
reports and payments. Contract payments are automatically generated by MOCAS when 
the system is able to match up a contract, a receiving report and a contractor invoice. 
(Tr. 1/42, 3/380, 4/753, 5/940, 1076, 1091; R4, tab 3 at 773) The MOCAS system is used 
to pay out about $78 billion per month under government contracts (app. supp. R4, 
tab 283 at 3; tr. 3/380-81). The existing MOCAS system (hereinafter "As-Is MOCAS") 
had three regional 
databases, referred to as MOCs: MOCG (southern region); MOCH 
(eastern region); 
and, MOCL (western region) (tr. 3/383, 577, 599, 4/785; R4, tab 3 at 
773). The As-Is MOCAS at the time of the contract at issue was complex and comprised 
of over 1600 different programs (supp. R4, tab 106 at 14 ), was very old2 and had 
maintenance issues (tr. 1/44). Further, because the system was so old and "there had been 
a lot of software coders that had played with the system" over time, "probably nobody 
really had a full grip as to how good or how bad" the coding of the As-Is MOCAS was 
(tr. 1/74). Documentation for much of the As-Is MOCAS system was nonexistent: 
[T]he paperwork for MOCAS is not current. The system is 
basically over 40 years old, and during that time a lot of the 
changes that were made and everything, the paperwork on 
them were lost.... As we make changes we try to baseline 
what changes we are making, but no ... we do not have a good 
set of baseline documentation for the whole MOCAS system. 
(Tr. 5/984) The As-Is MOCAS system used a SUPRA database which, at the time of 
contract award had only about 200 users worldwide, compared to hundreds of thousands 
of users of newer software like DB2. The government was concerned that the SUPRA 
software was going to become unsupported, creating a variety of issues, in particular 
security issues. (Tr. 4/688) In spite of these challenges, the As-Is MOCAS system 
"operated pretty well" (tr. 4/733). 
2. The government sought to have its MOCAS system be compliant with 
then-current DoD regulations and to take advantage of newer technology and software. 
Rather than incur the expense of a complete replacement of the entire system, after 
consideration of various options, the government made the decision to update the existing 
MOCAS system incrementally in steps. (App. supp. R4, tabs 100, 283, 290; tr. 4/685-86) 
The goal of the program was to simply get MOCAS on a 
platform that was maintainable, THEN, enhancements could 
1 DCMA owns 65% of the MOCAS system and holds all of the system's 
accreditations. DFAS owns 35% of the MOCAS system. (Tr. 3/557) 
2 "[C]irca 1960" (app. supp. R4, tab 290). 
2 

be incrementally introduced by a [readily] available 
[government] workforce, based on current and accurate 
documentation .... 
The Undersecretary of Defense, Comptroller made the 
decision to initiate a spiral acquisition program beginning 
with the replacement of the underlying DBMSY 1 This type of 
program is not new or cutting edge. It has been successfully 
performed numerous times and is nowhere near the risk [of] a 
complete new development or modernization effort. 
(App. supp. R4, tab 283 at 3) 
In order to limit scope and minimize risk, the requirement was 
to be completely technical, providing the exact look and feel 
with 100% of the existing system functionality. There was to 
be no functional change. 
(App. supp. R4, tab 290) 
As a technical upgrade, no new or altered functionality was 
being introduced into the system as part of the Rehost. This 
significantly reduced the potential for scope creep and 
training requirements, increased user acceptance, and reduced 
the need to interpret and refine requirements. These are 
common risk areas in all projects that often result in schedule 
and cost overruns, rework and disruption to production 
operations. As such, per the [Statement of Work] (SOW), 
"The contractor shall ensure that the rehosted MOCAS has 
100% of the functionality of the As-Is MOCAS system." The 
SOW further clarified this requirement for the human-PC 
interfaces, system interfaces, reports and queries, on-line 
updates, batch updates, and error messages. In summary, all 
outputs of the system were required not to have any visibility 
of a change to the end user, and support the same business 
and technical capability uses as the current system. 
(Supp. R4, tab 106 at 1) The government expressed in its answers to prospective 
offerors' questions prior to contract award that it wanted the computer screens, reports 
3 Data Base Management System. 
3 

and all system output to remain exactly as it was before the update but to have all the 
code, interfaces and documentation behind the output be updated. 
QUESTION 118: Reference section 7 ofthe SOW, The 
rehosted system will evidence no change to the screen layouts, 
order of fields, character input, screen resizing capabilities, 
help buttons, or any other characteristic. 
ANSWER: Comment acknowledged. NO CHANGES to any 
characteristics are permitted by the solicitation. 
(R4, tab 1 at 183) The government considered its approach to present "limited 
requirements" that made a firm-fixed-price contract appropriate (tr. 5/1079-80). A 
firm-fixed-price contract "places upon the contractor maximum risk and full 
responsibility for all costs and resulting profit or loss" (FAR 16.202-1) and 
FAR 16.202-2(d) specifies that a firm-fixed-price contract is appropriate where: 
"Performance uncertainties can be identified and reasonable estimates of their cost impact 
can be made, and the contractor is willing to accept a firm[-]fixed[-]price representing 
assumption of the risks involved." The government also considered the use of a 
firm-fixed-price contract to mean that the government's oversight and involvement in the 
work performed under the contract had to be limited (supp. R4, tab 106 at 3; tr. 1/135-36, 
3/520-22). 
[O]ne of our concerns was that we did not hinder [the 
contractor] from their efforts. We did not want to be the 
cause of any delays. 
We certainly didn't claim to have all the expertise. 
[The contractor] was supposed to develop their own test 
plans, own project management plans. It was pretty much 
hands off, and they were supposed to complete everything, 
and tum it over for Government testing, and at that point, we 
would test the functionality. 
(Tr. 4/710-11, see also tr. 5/909) 
3. The government made the decision to provide the successful offeror a 
"complete operation copy" of the As-Is MOCAS (tr. 4/660). 
That was important because they were to deliver a system that 
looked, felt, operated identical to the current as-is. So that 
was the baseline. Everything was to be - we called it the gold 
tape. Everything was to be compared to that, and that is what 
4 

(Id.) 
they were supposed to deliver, and it was very expensive by 
the way. It was unheard of. 
I think it was the first time that we had ever seen that 
done, where a complete copy of the MOCAS was given, that a 
complete operational copy was given. 
A Over the course of the contract [it cost the 
government] probably over a million dollars. 
Q ... Did the Government furnish a detailed 
design? 
A We furnished a complete as-is, which is 
better than any design document that you could ever 
hope for. 
A AEON was supposed to develop [the] 
design .... 
(Tr. 4/729-30, see also tr. 4/874, lines 6-11) On 9 November 2005 AEON expressed its 
understanding that there were usually no design specifications for a conversion project 
such as the one at issue: 
In the new development project business and systems 
requirements specifications are available. From these 
specifications, architecture and designs are developed and 
documented. The design documents are used to create 
program specifications which in tum enable program 
development. Programmers develop their programs in 
accordance with the program specification. When the 
program is developed the programmer unit tests the program 
against the program specifications. For conversion projects 
such as MOCAS Rehost there usually are no business or 
systems requirements and no design or program 
specifications. Further, the programs are partially or fully 
converted using a tool. 
5 

(Supp. R4, tab 68 at 2) (Emphasis added) We find that the copy of the As-Is MOCAS 
system provided to the successful bidder was the performance specification to which 
AEON was to design and produce the Rehosted MOCAS. 
4. On 25 July 2003 DF AS issued Solicitation No. MDA240-03-R-0003 for the 
MOCAS Rehost project which was described as: 
1. Scope 
The scope of this procurement is all services and supplies 
associated with, or supportive of, the rehost of the [MOCAS] 
including but not limited to: 
• Technical migration ofMOCAS to execute on a 
Defense Information System Agency (DISA) 
Standard Operating Environment (SOE) 
compliant Relational Database Management 
System (RDBMS). 
• Development of all system and project 
documentation. 
• Repair of the rehosted MOCAS after 
installation 
2. Background 
MOCAS is an automated 
integrated financial and contract 
administration system developed in the late 1950' s and 
enhanced over the years to maintain regulatory compliance 
and to support new business functionality. The system has 
over 8,600 authorized end users from the [DF AS], [DCMA] 
and other DoD components who access the system from 
locations worldwide. MOCAS resides on a DISA mainframe 
at the Defense Enterprise Computing Center (DECC), 
currently in Columbus, Ohio, and consists of three separate 
databases (MOCH, MOCL, MOCG) that serve two regions: 
East and West. Each database has its own copy of 
executables (programs) and Job Control Language (JCL). 
MOCAS consists of both interactive on-line (MANTIS and 
Customer Information Control System (CICS)) and batch 
system processing. The primary programming languages are 
COBOL and MANTIS, and a few programs written in 
Assembler. There are a number of systems that interface with 
MOCAS using a variety of platforms and interface methods 
that are critical to the overall functions of MOCAS. These 
6 

systems are not part of the MOCAS rehost, but their 
interfaces must be maintained. There are approximately 1.5 
million lines of source code maintained using a single source 
code library. The executables are, in large part, mirrored in 
each of the three databases. 
3. Objective 
The objective of this program is to begin the incremental 
progression ofMOCAS toward a modem, integrated business 
solution. DF AS is, in furtherance of this objective, rehosting 
MOCAS. This will provide a foundation for future business 
process improvements, technical capabilities, and reduced 
costs. However, none of those improvements are included in 
this contract. 
(R4, tab 1 at 8) 
5. On 12 August 2003 DFAS held the MOCAS Rehost Request for Proposal 
(RFP) Conference at which Mr. Art Gold, 4 Director of Systems for Commercial Pay 
Business Line (CPBL), presented information to prospective bidders in the form of 
PowerPoint slides (R4, tab 1at94-121; tr. 1147). Over 30 companies expressed interest 
in the project (supp. R4, tab 120 at 2). AEON was represented at the conference by 
Mr. Glenn Henry (R4, tab 1 at 124). The conference slides described the existing As-Is 
MOCAS system as follows: 
• MOCAS was developed in the late 1950's 
• The last significant upgrade was in the early 1980' s migrating 
MOCAS from Honeywell to Total Information System (TIS) 
• In 1998 MOCAS was moved to its current technology, 
SUPRA DBMS 
• Minor compared to Honeywell to TIS move 
• Hierarchical DBMS with link paths to data 
4 Mr. Gold was one of the principal architects of the MOCAS rehost project 
(tr. 2/273-76). Mr. Gold worked for AEON after his retirement from DFAS, 
which occurred sometime before the contract at issue was terminated for default 
(tr. 2/274). 
7 

• MOCAS contains approximately 1.5 million lines of code 
• COBOL- IM lines 
• MANTIS - 450K lines 
• JCL- 73K lines 
• Assembler - 5K lines 
• MOCAS has over 50 interface applications 
• Shared Data Warehouse (SDW) 
• Integrated extension of MOCAS SUPRA resident 
database 
• Provides reporting and query capabilities 
• Linked and populated via a hardware/software 
configuration referred to as "Forward Technical 
Bridge (FTB)" 
• All changes to MOCAS data is [sic] captured by a 
"change detector element" of the FIB and flows 
to/updates the SDW 
• The existing documentation is outdated and incomplete 
(R4, tab 1 at 101-03) The desired period of performance was presented to the prospective 
bidders as a total of 720 days or 2 years consisting of 540 days for contractor 
development and test, after which the Rehosted MOCAS was to be delivered to the 
government for 180 days of Government Test and Evaluation (GT&E) 5 consisting of 
90 days for functionality testing and followed, if functionality testing was successful, by 
90 days of production testing of the installation of all three MOCs (R4, tab 1 at 109; 
finding 18). 
6. All questions and comments submitted by potential bidders as well as the 
government's answers (R4, tab 1 at 156-212) were posted at 
www.dfas.mil/aso/contract/index.htm and available to all potential offerors by 22 August 
2003 (R4, tab 1 at 165). Among those pertinent to these appeals were: 
5 User acceptance testing (UAT) and GT &E are used throughout the record to refer to the 
same phase of the contract (tr. 3/427). 
8 

QUESTION 15: Will subject matter experts [SMEs] be 
readily available as required, or should we plan for delays in 
having access to subject matter experts and further delays in 
their responses to our questions? What standard of timeliness 
of access and response will DF AS provide to the vendor? 
ANSWER: The Government will not provide SMEs. The 
Government does not guarantee that it will answer any 
particular question that is submitted, however, questions may 
be submitted IA W par. 5 of the statement of work. There is 
no standard of timeliness of responses. 
QUESTION 16: [a] Will application operational personnel be 
readily available as required to demonstrate operation of the 
programs, or [b] should we plan for delays in access to 
application operational personnel and/or time constraints on 
our use of their time in demonstrating operation of the 
programs? [ c] What standard of access and availability will 
DF AS provide to the vendor? 
ANSWER: a.) No. b.) Questions may be submitted IA W 
par. 5 of the statement of work. c.) None 
(R4, tab 1 at 159) 
QUESTION 29: The contractor shall submit, as part of its 
proposal, and in accordance with the terms of the solicitation, 
a Software Test Plan. The Government will use the test plan, 
during the course of the contract, to monitor the contractor's 
progress toward timely and acceptable performance and to 
determine whether deviations from this plan are conditions 
threatening performance. There's no mention of Government 
participation during testing. We request that the Government 
participate during all testing to ensure successful testing and 
that the size of the Government team be agreed upon 60 days 
prior to the test period. 
ANSWER: See SOW section 9. The Government may 
observe but will not participate in contractor testing. 
QUESTION 30: ... [A] complete copy ofMOCAS .... one 
time snapshot of full-production data. Will this snapshot 
include enough data to be representative of the 100% 
functionality (Daily, Monthly, Yearly, etc) ofMOCAS to 
include error processing and exception reporting? 
9 

ANSWER: Not necessarily, there is the possibility that 
specific types of data may not be included in the snapshot at 
the time it is replicated. The as-is snapshot will be able to 
process any and all data that the corresponding production 
database can. Therefore, the contractor can simulate any type 
of data and process it through the as-is environment. This 
includes the data for error processing and exception reporting. 
(R4, tab 1 at 162) 
QUESTION 33: Reference: Section C, paragraph 2 "The 
executables are, in large part, mirrored in each of the three 
databases." Concerning the "mirrored" executables in the 
3 environments that are "in large part" the same, should the 
contractor assume that the code is exactly the same, or should 
a percentage delta factor be assumed? Please supply this 
factor if known. 
ANSWER: A significant portion of the performance under 
this contract is to ascertain the as-is environment. The 
Government is aware that the three environments are "in large 
part" mirror images. The Government suspects that the 
three 
are the same. However, the Government does not know the 
precise extent of possible variances between the three 
environments. 
(R4, tab 1 at 163) 
QUESTION 36: Will the Government have access to the 
as-is legacy MOCAS system (as awarded to the contractor) 
that will permit testing against this baseline as well as 
verification? · 
ANSWER: The Government will have access to the as-is 
system, and a back copy of the as-is system, at all times. The 
Government will not interfere in the contractor's use of the 
as-is system during development and testing. After delivery, 
the Government will use the as-is system as its benchmark. 
QUESTION 38: Will contractor staff be permitted to 
schedule MOCAS re-host activities such as online and batch 
10 

jobs at their priority and discretion or will the Government 
require prior coordination? 
ANSWER: The as-is MOCAS, the testing environment and 
the 
development environment will all reside on the same 
mainframe and will be available and dedicated to the MOCAS 
rehost project. The Government will not interfere in the 
contractor's use of the as-is, development, or testing system. 
QUESTION 49: ... [W]hat criteria will the Government use 
to assess 100% functionality in the rehost? 
ANSWER: See SOW sections 7 and 11. 
(R4, tab 1 at 164, 166) 
QUESTION 62: Do Test Scripts or a Software Test Plan 
exist for MOCAS As-Is? Even informal test scripts may be 
beneficial to 
the vendors bidding on' this solicitation 
ANSWER: The Government will not provide Software Test 
Plans for the MOCAS As-Is. However, ifthe contractor, 
during the course of performance, discovers additional 
documents, they may be requested through the [Contracting 
Officers Representative] (COR). 
(R4, tab 1 at 169) 
QUESTION 74: On several occasions within the RFP, the 
Government states that it cannot guarantee its ability to 
answer questions related to the MOCAS as-is system due to 
incomplete/outdated knowledge of the system. How does the 
Government expect an offeror to provide the required plans 
identified in Section Four Project Management in any 
meaningful detail or substance without having had an 
opportunity to conduct an assessment of the MOCAS As-Is 
environment, and an analysis of approximately 1.5 million 
lines of code? 
ANSWER: The Government is seeking a contractor with the 
expertise to do so. 
(R4, tab 1at171) 
11 

QUESTION 77: The Government specifies in Section Seven 
Functionality that it requires the re-hosted system will have 
100% functionality of the as-is system. Can the Government 
define 100% MOCAS functionality? Can the definition be 
provided in specific terms, quantified by the number of 
conditions, parameters and screen definitions that constitute 
MOCAS 100% functionality? 
ANSWER: See SOW par. 7. 
(R4, tab 1 at 172) 
QUESTION 98: Will DFAS consider the test coverage to be 
sufficient if it covers the program logic exercised in a 
simulated normal operational cycle for each program? Or will 
DF AS want the test coverage 
to be forced to follow all 
accessible logic paths? 
ANSWER: The contractor must determine what testing is 
sufficient to ensure the rehosted MOCAS complies with the 
contract requirements. 
(R4, tab 1 at 178) 
QUESTION 101: ... [A] complete copy ofMOCAS .... one 
time snapshot of full-production data. Will this snapshot 
include internal and external interfaces to include incoming 
and outgoing? 
ANSWER: The Government will provide an as-is snapshot 
that is a replica of the production environment. The snapshot 
will be able to process any and all data that the corresponding 
production database can. There is the possibility that specific 
types of data may not be included in the snapshot at the time it 
is replicated. The snapshot will contain the programming, 
within MOCAS, necessary to operate the interfaces. To 
conduct testing of those interfaces, see SOW section 9. 
(R4, tab 1 at 179) 
7. AEON submitted its proposal on 1December2003 in which it stated that it had 
"just completed another successful conversion of MANTIS and SUPRA to CICS COBOL 
and DB2 with full production implementation .... This proposal will demonstrate how we 
can achieve the same success for DFAS." (R4, tab 2 at 220, 222-23) AEON's proposal 
12 

demonstrated its understanding of the government's decision to modernize MOCAS 
incrementally and to make the Rehosted MOCAS transparent to its users: 
The Government is embarking on a long term project to 
incrementally transition the MOCAS system to a modem 
integrated business solution. The MOCAS Rehost Project is 
the first step in that transition. MOCAS will be moved to a 
modem technical infrastructure without impact to the 
MOCAS user community as the functionality, look and feel of 
the system will mirror the current MOCAS environment. 
(R4, tab 2 at 220) The proposal also stated: 
MOCAS end users will 
not experience any change in system 
functionality, data content and quality. The current business 
processes and workflow will remain unchanged and the 
functionality, look and feel of the MOCAS Rehosted System 
will mirror the current system. Therefore, the system changes 
will be transparent to the user community. 
(R4, tab 2 at 221) AEON's proposal continued: 
We believe we are uniquely qualified to assist you with this 
major undertaking because of our: 
• Team - Our highly skilled management and 
technical team with in-depth MANTIS, 
SUPRA, DB2 and MOCAS knowledge and 
expertise, complex and large conversion 
projects, effective testing and extensive project 
management experiences will reduce the risks 
inherent to a project of this magnitude. 
• Methods, Processes and Best Practices - Our 
Rapid conversion life cycle approach and 
process, industry recognized standards of CMM 
and PMI (Project Management Institute) for our 
program management, our testing best practices 
and our ability to properly manage risk, avoid 
potential project pitfalls will produce high 
quality, timely deliverables. 
13 

• NPGen Conversion Tool - Our proven 
MANTIS and SUPRA specific conversion tool 
will expedite the conversion process while 
producing consistent and high quality 
deliverables. 
• Our Extensive Experience - While others 
may claim that they can do it, we have done it 
successfully many times. 
(R4, tab 2 at 221, 254) AEON listed 11 previous projects, 6 in detail, of which 2 were 
previous DF AS projects. One in particular, the DF AS SCRT project, was identified by 
AEON 
as having multiple similarities to the MOCAS Rehost project. (R4, tab 2 at 
222-25, 255-59) AEON proposed to complete the contract work in 24 months at a 
firm-fixed-price of$14,899,316.00 
and was the highest of the bids submitted to the 
government (R4, tab 2 at 215, 242, tab 3 at 765; tr. 1/68-69, 4/656-58; finding 10). AEON 
proposed to use "our proven conversion tool, NPGen, a rapid conversion approach" that it 
represented to be "our proprietary" and "internally-developed" software conversion tool 
(R4, tab 2 at 220, 227, 229-30, 262, 264-66; tr. l/S0-51, 4/658). AEON's proposal further 
included key management personnel: John Allwood as Project Manager and Lech 
Lakomy as Technical Manager 6, as well as a dedicated Program Manager (Dori Overby) to 
provide additional oversight and an Internal Audit Executive (Shirin Javid) who would 
spend two days per month for the duration of the project reviewing and validating the 
project processes (R4, tab 2 at 237-39, 286-90, 300-31, 338-42, 372-76). The government 
found AEON's proposal to present "strong management plans and had consistent, easily 
understood, documented processes that appeared repeatable .... With ... strong technical 
and management qualifications, and several value added features, the Government selected 
AEon's proposal as representing the best value." (Supp. R4, tab 106 at 4-5; tr. 5/892-93) 
AEON also proposed to use its "successful automated testing approach," grouped into ten 
major categories (see finding 55), to provide "more comprehensive testing with fewer 
people and for a shorter period of time leading to increased testing productivity, 
consistency, quality and ultimately reducing the conversion risk" (R4, tab 2 at 232-33, 
270-72). 
6 The proposal also identified Mr. Lakomy as the "sole developer ofNPGen, a highly 
sophisticated PC based tool suite used to inventory, parse and analyze MANTIS, 
COBOL and SUPRA/TOT AL which will be the conversion tool used on the 
MOCAS 
project" (R4, tab 2 at 238). 
14 

8. AEON's proposal included an extensive risk analysis and proposed specific 
means by which AEON intended to manage the risks it identified. The proposal included 
"several million dollar[s]," stated as a contingency, to cover the various risks identified by 
AEON (tr. 4/657). 
The most significant risk to the MOCAS project is the lack of 
participation by the MOCAS technical and business users. 
We will minimize the risk by using [Computer Sciences 
Corporation] cscPJ resources that bring a wealth of DF AS 
and MOCAS related experience to the project team in the 
form of the Functional Manager, QA leader, testers and 
programmers. We have additional team members who have 
MOCAS and/or contract management and/or DF AS 
experience to further minimize the risk. [SJ 
(R4, tab 2 at 236, 275) 
9. A total of five proposals, including AEON' s, were submitted in response to the 
solicitation and evaluated by the government (supp. R4, tab 120 at 2; tr. 1/99, 4/656, 
5/892). 
B. Contract 
10. On 1April2004 Contract No. HQ042'.3-04-C-0003 for the MOCAS Rehost 
Program was awarded to AEON for the firm-fixed-price of $14,899,316.00. "This 
contract will convert/rewrite all existing MOCAS software programs to a [RDBMS] 
which will enable DF AS to begin its incremental progression toward a 
modem, integrated 
business solution that is compliant with the DoD Business Enterprise Architecture." 
(R4, tab 3 at 765) Contract line item no. (CLIN) 0001, Rehost MOCAS System, in the 
amount of $14,849,316.00 (all but $50,000 of the total contract price) was described as: 
7 AEON's proposal identified CSC and IBM as "alliance partners" (R4, tab 2 at 220, 253, 
261-62). 
8 AEON hired employees who had "a lot" of MOCAS experience. A few of them were 
identified at the hearing as: Dwight Layden, whose nickname was said to be 
"Mr. MOCAS" (division chief of programming under DLA before DCMA and 
DF AS were split oft), Sandra Livingston, Don Miller, Ruth Owen (programming 
supervisor in the financial area), Sheila Gretar (financial analyst and functional 
analyst in MOCAS), Jim Wheeler (DISA) (tr. 4/782-83, 5/942-43). 
15 

The contractor shall provide all tasks identified in the 
statement of work including installation on the test and 
production platforms of the rehosted MOCAS; delivery of 
rehosted MOCAS and migration programs, both with full 
documentation; and sequential migrations of the as-is data to 
the rehosted MOCAS. This CLIN excludes statement of work 
tasks for Government directed travel, and the repair and 
software license options. 
(R4, tab 3 at 770) CLIN 0002, Government Directed Travel, was priced in the amount of 
$50,000 and CLIN 0003, Option-Repair, never exercised (tr. 1111 O; see also 
finding 71), was priced in the amount of $668,316 (R4, tab 3 at 771-72). 
11. The SOW~ 4, Project Management, required AEON to submit as deliverables 
under 
CLIN 0001, as well as update throughout contract performance, a Program 
Management Plan (PMP), 9 Program Quality Assurance Plan (PQAP), Software 
Development Plan (SDP), Configuration Management Plan (CMP), Software Test Plan 
(STP) 10 and a Transition Plan that AEON was to use to manage its performance under the 
contract. "The Government will use these plans, during the course of the contract, to 
monitor the contractor's progress toward timely and acceptable performance. The 
Government may determine that deviations from these plans are conditions threatening 
performance." (R4, tab 3 at 773) AEON was also required to provide a biweekly status 
report identifying work performed and issues impacting performance, minutes of monthly 
In Process Review (IPR) meetings, and a single, ongoing document in which each 
milestone 
met was documented so that it reflected the total progress of all the milestones 
identified in the PMP (see, e.g., app. supp. R4, tab 172 at 8; see also findings 21, 24, 49, 
63, 65, 70). (R4, tab 2 at 236, tab 3 at 773-74; app. supp. R4, tab 169; tr. 21191, 
3/397-99) SOW~ 4 provided that: 
The Government expressly reserves the right to observe, 
shadow, question, make suggestions to, and otherwise interact 
with the contractor during the performance of the contract. 
However, the contractor is responsible to notify the 
Contracting Officer (CO), in writing, if at any time it believes 
that the communication under this term is interfering with the 
performance of the contract and provide the Government 
9 The PMP was a "living document" that was updated throughout contract performance, 
the most 
current version of which was submitted to the government on a regular 
basis. See R4, tab 25 for what is annotated as the final PMP (Sept 2006). 
10 See finding 16. 
16 

24 hours to evaluate the objection and if appropriate, 
discontinue the behavior. 
(R4, tab 3 at 774) 
12. SOW~ 5, As-Is MOCAS, provided: 
The contractor, in order to reproduce the current MOCAS 
functionality in a RDBMS, must ascertain the functionality of 
the current, as-is MOCAS. The contractor will have: 
• ... [A] complete copy ofMOCAS systems loaded with a 
one-time snapshot of full-production data. The 
boundaries of the as-is MOCAS are contained in 
section J, attachment 1.7, MOCAS Rehost 
As-Is 
Documentation - MOCAS Technical Environment 
Chart.... [I]nterfaces, applications, or files not 
designated as part of the as-is MOCAS in that 
attachment [may not be changed]. 
• The as-is documentation provided as an attachment 
to this [contract]. The as-is documentation only 
represents a high-level approximation ofMOCAS. 
It is based on incomplete and/or outdated 
documentation. [I I] 
• The option of submitting questions, in writing, through 
the COR. 
• However, the Government does not guarantee 
that 
it will be able to answer any particular 
question that is submitted because of the 
incomplete and/or outdated knowledge of 
MOCAS. 
• These questions and answers do not relieve the 
contractor from responsibility for ensuring that 
it has a thorough and correct understanding of 
the as-is functionality. 
• The Government will acknowledge the 
contractor's requests 
within two business days. 
11 One of the purposes of the contract to rehost MOCAS was to provide updated 
documentation (tr. 5/1087; see also findings 4, 10, 18, 19, 52, 54, 71, 115). 
17 

(R4, tab 3 at 774) With respect to the provision of the "one-time snapshot of full-production 
data": 
We provided a -- we went to DISA and asked them 
that since we knew that this documentation on the MOCAS, 
was antiquated, we wanted to make sure that they had a 
system that they could go back to, so that when they were 
converting on this side, they can go back and test over on the 
current system to make sure that it was doing the same thing 
as it was doing over here, and it would be doing the same 
thing when they converted it. 
So we provided them a one time snapshot of all three 
databases for them to use, which was very costly. [121 
We provided [AEON] with a system so that they can 
compare and they can see how the system was functioning. 
They could go and do a test and use that so when they were 
over here, and they were having difficulties, they could go 
back to the other system to compare . 
... [T]hey can get new log-ins, and a new sign-on, and 
enter data, and go in and see how it works, and basically to 
see how it was working today, and then when they went and 
converted it, they could go back and check and see if it was 
doing the same thing in the old system when they converted it 
over to the new system. 
(Tr. 3/405-07; see also tr. 5/908-09) 
13. SOW ~ 6, System Development, provided: 
The contractor will -
-
• update, convert or rewrite MOCAS's MANTIS, 
COBOL, and all other programs and batch JCL 
jobs, 
12 (See finding 3 ). 
18 

• using, on the mainframe, only programming 
languages, conversion or development tools that 
are listed as GFP, or that 
have received a waiver 
from the CO, 
• and using, on a workstation connected to the 
ELAN, only software listed in section J, 
attachment 2.1, provided as part of the standard 
DF AS office automation software load, or that 
has received 
a waiver from the CO 
• to execute using a contractor developed/converted 
database utilizing a Government-furnished, 
Government-installed RDBMS as identified in 
section 16 ofthis SOW, 
• that accommodates 
the consolidation of the 
current three physical databases into a single 
instance with a single set of executable files and 
JCL, 
• mapping the as-is MOCAS database file structure 
to the rehosted MOCAS database, 
• which shall reside on a Government-provided 
mainframe, 
• running a Government-tailored operating system 
loaded with all software listed in section J, 
attachment 2 .4. 
The Government will -
-
• no later than 90 days after the date of award, 
provide the contractor test and development 
environments running a Government-tailored 
OS-390 operating system loaded with all GFP 
software, 
• and on or before September 30, 2004, inform the 
contractor that a Government-tailored installation 
package to upgrade to a Z/OS operating 
system 
with a list of the Government-provided software 
that is included in the package is available, 
• over the course of no longer than 72 hours, install 
the available installation package within 30 days 
of the contractor's written request or one week 
prior to the beginning date for delivery of 
CLIN 0001, whichever is earlier, 
19 

Any product used in support of this contract, but not 
required to be used in the Government testing and 
production environments may be loaded on a stand-alone 
workstation. 
The Government will maintain and ensure operability of 
the mainframe hardware and the government-tailored 
operating system. Ifthere is a failure of the mainframe 
or government-tailored operating system, the 
Government will repair or replace it within 48 hours. 
Access to the mainframe via PC and ELAN will be 
available to the contractor 24 hours per day, every day of 
the year except for up to two 24-hour periods per month. 
The contractor will not have physical access to the 
mainframe. 
(R4, tab 3 at 774-75) 
14. SOW~ 7, Functionality, provided the following: 
The contractor shall ensure that the rehosted MOCAS has 
100% of the functionality of the as-is MOCAS system. 
Functionality is: 
• the ability of the software delivered under this 
contract to operate on the 
Government-furnished hardware provided under 
the terms of this contract 
• while supporting every one of the same 
Government business uses that can be 
performed using the as-is MOCAS system (for 
example reports, inputs, processes, outputs, 
screen layouts, interfaces, system accessability 
to users, windows of availability) without any 
visibility of a change to the end users 
• while supporting every technical capability, use, 
and purpose of the as-is MOCAS system (for 
example internal controls, edits, screen scrapes, 
system 
response times, capacity for ongoing 
operations, performance characteristics, archive 
capability, scalability, back-up and restores) 
20 

• and, while ensuring that the Government is able 
to retain or obtain the same level of security 
accreditation as the as-is MOCAS system .... 
The contractor shall read the definition of functionality 
broadly, that is, to be inclusive of features rather than 
exclusive of features. Functionality includes but is not limited 
to: 
• The human-PC interface. The rehosted system will 
evidence no change to the screen layouts, order of fields, 
character input, screen resizing capabilities, help buttons, 
or any other characteristic. For example, if a special key 
must be struck today, then that same key must be used in 
the new system. In addition, end users must have access 
only to that portion of the MOCAS data as they have in 
the current MOCAS system. The contractor must ensure 
that the same emulators used today by end users can 
remain in use in the rehosted system. 
• System interfaces. The rehosted system must maintain all 
system interface capability as the as-is MOCAS system, 
without requiring any changes to non-MOCAS systems. 
• The contractor must retain all interface 
functionality. Where any part of a system 
interface, whether files or programs, are 
identified as part of the as-is MOCAS, the 
contractor may change them, while maintaining 
full functionality. If they are not identified as 
part of the as-is MOCAS, the contractor may 
not change them, and as with all interfaces, their 
functionality must be maintained. The 
contractor shall notify the COR of any 
applications not indicated on the MOCAS 
Technical Environment Diagram as soon as they 
are identified by the contractor. As with all 
interfaces: 
• Any file transferred with a particular file 
transfer protocol must remain capable of being 
transferred with that protocol. 
• Where systems interface with MOCAS via 
emulators on a PC, the contractor must ensure 
21 

that the interfaces are maintained using the 
same emulators. 
• Reports and queries. All reports and queries will have the 
same data elements, formats, information, order, 
distribution (for example reports via the Mechanization of 
Reports Distribution System (MORDS)) and all other 
characteristics as generated by the as-is MOCAS system. 
Specifically, all reports must be based only on the portion 
of the data from which it is drawn in the as-is MOCAS. 
For example, if a report in the as-is system is drawn only 
from the "West" database, it must still only be drawn from 
that data in the rehosted system. 
• On-line updates. Any updates performed on-line in the 
as-is MOCAS system will be performed on-line in the 
rehosted system. The same on-line edits will be 
performed in the rehosted system as in the as-is MOCAS 
system. 
• Batch updates. Any updates performed in batch in the 
as-is MOCAS system will be performed in batch in the 
rehosted system. The same batch edits will be performed 
in the rehosted system as in the as-is MOCAS system. 
The system must allow for timing of batch processing 
(including all pre-cycle and post-cycle maintenance, 
back-ups and restores), which does not alter the as-is 
MOCAS system on-line availability for each time zone. 
• Error messages. Error messages generated by the 
MOCAS application software will be numbered and 
worded in the rehosted system the same as they are 
numbered and worded in the as-is MOCAS system. 
The contractor shall, if it determines that any component of 
the as-is MOCAS code does not perform a function, prepare a 
written explanation of the rationale, prepare complete 
documentation of the code, and submit it to the COR for 
permission prior to making a determination that it is not part 
of the system functionality. The contractor understands that it 
is unlikely that the Government will give permission to omit 
from the rehosted MOCAS code believed to be inactive. 
(R4, tab 3 at 775-76) Under this requirement, the rehosted system was to look and 
operate exactly the same as the As-Is MOCAS system so there was no need to retrain the 
22 

government users (tr. 1/74-79, 511087-88). DFAS MOCAS Program Manager Castrillo 
described it as follows: 
Q How was the rehosted MOCAS supposed to 
operate when it was delivered to the government? 
A No different than as-is MOCAS. One of the 
examples I always gave was, because we acknowledged that 
there's things that MOCAS did that probably wouldn't be 
correct.. .. I'll give you a high level example. IfMOCAS 
said 2 plus 2 is 5, if the as-is MOCAS said that, the 
expectation was that when it's rehosted 2 plus 2 would equal 
5. Because there were a couple times that, you know, we got 
approached, hey we could correct this or, you know, we could 
correct something, and I would say, no, you've got to make it 
work, if it's wrong it's wrong. I mean, you know, it just has 
to do what MOCAS is doing today, don't make it do 
something [else]. 
(Tr. 5/1087-88) 
15. Contracting Officer (CO) Gladski was identified as a Buyer up to and 
including 
the date of contract award. He then became the primary CO on this contract 
until he 
retired from DFAS in June 2008 (tr. 1/30). CO Gladski was involved in drafting 
the terms and conditions of the solicitation and resulting contract (R4, tab 3 at 765; 
tr. 1/46, 62, 75, 2/267). Both documents, due to minimal existing documentation, made 
identification of the functionality of the As-Is MOCAS the responsibility of the contractor 
(tr. 1/73-74, 2/235-36). 
(Tr. 1/76) 
The requirement was pretty clear that the rehosted 
system was basically a form fit function replacement of the 
as-is, and was to mirror exactly the functionality of the old 
system as it would have been transported or converted on to a 
new platform. 
By limiting the conversion effort to 100% functionality 
of the As-Is system, the Rehost project was unique in 
that the test results from the[] rehosted system should 
exactly match the results of running the same transaction 
through the original system. 
23 

(Supp. R4, tab 106 at 16) 
16. SOW~ 9, Contractor Testing, provided: 
The contractor shall submit, as part of its proposal, and in 
accordance with the terms of the solicitation, [an STP]. The 
Government will use the test plan, during the course of the 
contract, to monitor the contractor's progress toward timely 
and acceptable performance and to determine whether 
deviations from this plan are conditions threatening 
performance. The test plan will include, at a minimum: 
• unit testing, 
• integration testing, which includes exception 
testing, interface testing, and testing the rehosted 
MOCAS functionality 
• performance testing, which includes expected 
level and stress level testing of system 
availability, volume and response time capability 
• trial migrations including at least one complete 
migration of all the data in the as-is MOCAS 
databases 
by incrementally migrating one 
database at a time until all the data is copied into 
the rehosted MOCAS system on the test platform 
The Government may, during the performance period, 
recommend exception and 
other testing scenarios that the 
contractor may consider in its testing process. 
Notwithstanding any contractor testing, the Government 
expressly reserves the right to conduct any testing in order to 
determine that the rehosted MOCAS complies with all the 
terms of this contract. No testing by the Government will 
relieve the contractor from its responsibility to comply with 
all the terms of this contract. 
(R4, tab 3 at 776-77; tr. 4/739-43) (Emphasis added) 
24 

17. SOW~ 10, System Delivery and Set-up, provided: 
The contractor shall deliver, as part of CLIN 0001, all the 
source code, executable objects and all other development 
products or programs for the rehosted MOCAS. 
The contractor will have included 
in its Project Plan, the 
following tasks, task durations, and shall: 
• No later than the beginning delivery date for CLIN 0001, 
completely purge the test platform of all data and 
programmmg. 
• On the beginning date of delivery for CLIN 0001, in the 
presence of the COR and any other Government 
representatives, install the rehosted MOCAS programs 
and new MOCAS database on the testing platform. 
• Complete the installation within 24 hours. 
• Upon completion of the installation, using the ET &L 
programs provided in paragraph 8, above, migrate the 
data from one of the three as-is databases to the rehosted 
MOCAS. 
• On the ih calendar day after completion of the migration 
of the first database, migrate the second as-is MOCAS 
database to the test platform. 
• On the 7th calendar day after completion of the migration 
of the second database, migrate the third as-is MOCAS 
database to the test platform. 
• The Government will, for each database, no later than 
30 days after the third migration, notify the contractor to 
migrate any government-edited data 
from the ET &L 
suspense file to the test platform. 
• The contractor shall have 24 hours to complete each 
migration. 
(R4, tab 3 at 777-78) 
18. SOW~ 11, Acceptance/Rejection, provided: 
The Government shall accept or reject CLIN 0001 within 
30 days from the final migration of live, legacy production 
data to the rehosted MOCAS. At any time prior to final 
acceptance, any discrepancy between the functionality of 
25 

the rehosted MOCAS and the as-is MOCAS, or any other 
failure to meet the requirements of this solicitation, may 
be a basis for rejection. Documentation may be rejected if: 
(1) there is any instance where the documentation does 
not reflect the configuration or function of the 
rehosted MOCAS 
(2) it does not provide sufficient instructions to 
operate or maintain any portion of the rehosted 
MOCAS, and/or 
(3) it does not comply with any other requirement in 
this contract. 
(R4, tab 3 at 778) (Emphasis added) SOW if 11 also included the following timeline: 
Example Timeline 
sodays I 
••• 
I 80 Da)"S Government 
; TestmglAcccpmncc 
A The due date for the beginning of delivery of CLIN 000 I 
••• 
CLIN 0003 Renair 
Wamllltv 
B Installation for production testing- beginning 90 days after the due date for the beginning of delivery of CLIN 
0001. Beginning of option CUN 0003, if exercised. 
C Deadline for Government's Accentance or Reicction 
(R4, tab 3 at 778) The timeline was explained as follows: 
The delivery of the rehosted MOCAS and documentation 
defined within the SOW was to occur over 180 days during 
Government Testing and Acceptance phases. The 
Government estimated that it would require 90 days to 
perform (the initial GT &E period of functionality testing]. 
Upon successfully testing the system [A-->B], the production 
MOCs would be migrated to the rehosted system over a 90 
day I 3 month period [B-->C] in which one of the three MOCs 
would be migrated each month. The Government would 
accept or reject the system and documentation within 30 days 
from the final migration. At the time the SOW was written, 
the Government felt that this was a reasonable estimate, but it 
26 

was dependent on the contractor properly testing the system 
(i.e. unit and system integration testing) to ensure that the 
rehosted MOCAS had 100% of the functionality of the as-is 
MOCAS system. Assuming this contract term was met, a 90 
day GT &E was more than sufficient for conducting the 
Government's tests. 
(Supp. R4, tab 106 at 3-4; see also findings 2, 5) Program Manager Castrillo described 
the process as follows: 
[GT &E] was the government 
testing and evaluation, it was 
the government's opportunity to test and evaluate what was 
being delivered. This system issues millions upon millions of 
dollars in payments a year, or in a day I think $20 million. So 
we didn't want to put it in production and have ... any fatal 
errors or any problems. So we set aside 90 days in the 
contract to do whatever testing we wanted or we felt was 
necessary, and then so that was our period before we put 
it 
into production . 
... [O]ur evaluation period was actually I believe 180 
days, 90 days was to do it outside of production and then 90 
days within production.... [W]e go one MOC at a time 
because again being an old system, you know, you want to be 
careful about how you proceed . 
. 
. . [I]t was our full responsibility to determine that the 
terms of the contract were met, that we had an adequate 
system, that we had a rehosted system that would fully operate 
the way as-is MOCAS [operated]. 
(Tr. 5/1088-89) When asked what AEON's role was to be during GT&E, Castrillo 
testified that AEON didn't really have a role in GT &E, stating that "their job should have 
been done" (tr. 5/1089-90). 
AEON was responsible for ensuring the system was delivered 
with 100 percent functionality. So it was a working system. 
They were responsible for doing the testing [see 
finding 16]. Once it was turned over to the Government, 
27 

AEON's testing of the system is over, and it is Government 
testing from there. So they would not 
have an opportunity to 
test once it is turned over. 
So, by default, they have to complete their testing and 
ensur[ e] 100 percent functionality before they tum it over to 
us. 
(Tr. 4/669; see also 5/894) 
19. SOW ii 14, Documentation, provided: 
On the date of the beginning of delivery of CLIN 0001, the 
contractor shall deliver full documentation of both the ET &L 
programs and the rehosted MOCAS including the final 
version of all documentation created by the contractor during 
the performance of the contract. ... 
(R4, tab 3 at 779) "Full documentation" included, but was not limited to, a list of 
24 reports, manuals, guides and other documents enumerated in the contract (R4, tab 3 at 
779). 
20. SOW ii 16, Government Furnished Property, required the government to 
provide to AEON computer workstations loaded with standard DF AS network access, 
access to printers, copiers, fax machines and email, desk space, telephones, general office 
supplies, mainframe resources, software listed in Section J of the SOW, attachments 2.4 
and 2.5, and other enumerated items (R4, tab 3 at 780). There is no other provision in the 
contract that required the government to provide items in addition to those specifically 
listed. In particular, there was no contract requirement for the government to provide the 
government's GT&E test scripts or test plans to AEON: "[AEON was] supposed to 
develop their own test plans and project management plans as they were 
responsible for 
all the tests of the product before the delivery of the system for our testing" (tr. 4/661; 
finding 16). 
21. For purposes of payment, the MOC AS Rehost contract, CLIN 0001, was 
structured to identify eight distinct payment events (also referred to as "Milestones" 
throughout the record (see, 
e.g., findings 11, 49) associated with CLIN 0001 tasks, the 
successful completion of which entitled AEON to receive event-based payments. The 
contract contained the following in full text: 
28 

Performance Based Payment Events As Implemented By 
FAR 52.232-32 PERFORMANCE-BASED PAYMENTS 
(FEB 2002) 
1. Placement of purchase orders for vendors, subcontractors, 
suppliers for labor, travel, supplies and equipment within 
30-45 days after contract award. 
2. Discovery Phase completion identified by the delivery of 
the Discovery Findings and implications report and scheduled 
for the end of the 1st quarter of performance[.] 
3. Proof of Concept completion identified by the results of 
the proof of concept and scheduled for the end of the 2nd 
quarter of performance. 
4. Design Phase completion identified by the completion of 
database and application ( online & batch) design and 
scheduled for[] the end of the 3rd quarter of performance. 
5. Data conversion completion identified by the loading of 
the database into DB2 and scheduled for the end of the 4th 
quarter of performance. 
6. Conversion completion identified by the successful 
completion of unit testing and moving all code from the 
development to the QA/testing environment scheduled for the 
end of the 5th quarter of performance. 
7. QA/Testing Phase completion identified by moving 
software from QA/Test to User Acceptance environment and 
scheduled for the end of the 6th quarter of performance. 
8. Completion of the delivery and acceptance of CLIN 0001 
in the Production environment scheduled for the end of the ?1h 
quarter of performance. 
(R4, tab 3 at 785) The payment events, designed by AEON and contained 
in its proposal, 
were designed to track AEON's progress through contract performance and to establish a 
basis for making progress payments to AEON upon its completion of the enumerated 
milestones roughly once a quarter (R4, tab 2 at 628-29; tr. 1162-65, 21189-90, 5/1081). 
The eight payment events/milestones remained in place 
throughout contract performance; 
29 

however, the later payment events were subdivided into smaller, more refined segments to 
provide a basis for making payments to AEON more frequently (findings 49, 63, 65, 70; 
tr. 3/394-97, 5/1081-85). There is nothing in the payment events identified in the 
contract or subsequent modifications to indicate that they included any tasks other than 
those associated with CLIN 0001 (tr. 5/1085). The amount of payment associated with 
each of the eight (8) payment events was l/8th (or 12.5%) of the total contract price for 
CLIN 0001 (R4, tab 2 at 628-29). There was no liquidation schedule contained in the 
contract (tr. 11155-56). 
22. FAR 52.232-32, PERFORMANCE-BASED PAYMENTS (FEB 2002), incorporated 
in the contract by reference, provided: 
(c) Approval and payment of requests. (1) The Contractor 
shall not be entitled to payment of a request for 
performance-based payment prior to successful 
accomplishment of the event or performance criterion for 
which payment is requested. The [CO] shall determine 
whether the event or performance criterion for which payment 
is requested had been successfully accomplished in 
accordance with the terms of the contract. The [CO] may, at 
any time, require the Contractor to substantiate the successful 
performance of any event or performance criterion which has 
been or is represented as being payable. 
(2) A payment under this performance-based payment clause 
is a contract financing payment under the Prompt Payment 
clause of this contract and not subject to the interest penalty 
provisions of the Prompt Payment Act.... The payment 
period will not begin until the [CO] approves the request. 
(3) The approval by the [CO] of a request for 
performance-based payment does not constitute an acceptance 
by the Government and does not excuse the Contractor from 
performance of obligations under this contract. 
( d) Liquidation of performance-based payments. 
(1) Performance-based finance amounts paid prior to payment 
for delivery of an item shall be liquidated by deducting a 
percentage or a designated dollar amount from the delivery 
payment. If the performance-based finance payments are on a 
delivery item basis, the liquidation amount for each such line 
item shall be the percent of that delivery item price that was 
30 

previously paid under performance-based finance payments or 
the designated dollar amount. If the performance-based 
finance payments are on a whole contract basis, liquidation 
shall be by either predesignated liquidation amounts or a 
liquidation percentage. 
( e) Reduction or suspension of performance-based payments. 
The [CO] may reduce or suspend performance-based 
payments, liquidate performance-based payments by 
deduction from any payment under the contract, or take a 
combination of these actions after finding upon substantial 
evidence any of the following conditions: 
(1) The Contractor failed to comply with any material 
requirement of this contract .... 
(2) Performance of this contract is endangered by the 
Contractor's (i) failure to make progress, or (ii) unsatisfactory 
financial condition. 
U) Special terms regarding default. If this contract is 
terminated under the Default clause, ( 1) the Contractor shall, 
on demand, repay to the Government the amount of 
unliquidated performance-based payments, and (2) title shall 
vest in the Contractor, on full liquidation of all 
performance-based payments, for all property for which the 
Government elects not to require delivery under the Default 
clause of this contract. The Government shall be liable for no 
payment except as provided by the Default clause. 
(R4, tab 3 at 802-04) 
23. Under FAR Subpart 32.10, PERFORMANCE-BASED PAYMENTS, at 32.1001, 
POLICY, performance-based payments "are the preferred Government financing method" 
and they "are contract financing payments that are not payment for accepted items." 
FAR 32.lOOl(a), (b). FAR 32.lOOl(c) provides that performance-based payments are 
"fully recoverable, in the same manner as progress payments, in the event of default." 
Further, FAR 32.1004, PROCEDURES, provides: 
31 

Performance-based payments may be made either on a 
whole contract or 
on a deliverable item basis, unless 
otherwise prescribed by agency regulations. Financing 
payments to be made on a whole contract basis are applicable 
to the entire contract, and not to specific deliverable items. 
Financing payments to be made on a deliverable item basis 
are applicable to a specific individual deliverable item. 
(A deliverable item for these purposes is a separate item with 
a distinct unit price. Thus, a contract line item for 10 
airplanes, with a unit price of $1,000,000 each, has 10 
deliverable items-the separate planes. A contract line item 
for 1 lot of 10 airplanes, with a lot price of $10,000,000 has 
only 
one deliverable item-the lot.) 
(a) Establishing performance bases. (1) The basis for 
performance-based payments may be either specifically 
described events (e.g., milestones) or some measurable 
criterion of performance. Each event or performance criterion 
that will trigger a finance payment must be an integral and 
necessary part of contract performance and must be identified 
in the contract, along with a description of what constitutes 
successful performance of the event or attainment of the 
performance criterion .... An event need not be a critical 
event in order to trigger a payment, but the Government must 
be able to readily verify successful performance of each such 
event or performance criterion. 
(2) Events or criteria may be either severable or 
cumulative. The successful completion of a severable event 
or criterion is independent of the accomplishment of any other 
event or criterion. Conversely, the successful 
accomplishment of a cumulative event or criterion is 
dependent upon the previous accomplishment of another 
event.... The contracting officer must include the following 
in the contract: 
(i) The contract must not permit payment for a 
cumulative event or criterion until the dependent event or 
criterion has been successfully completed. 
32 

(ii) The contract must specifically identify severable 
events or criteria. 
(iii) The contract must identify ... which events or 
criteria are preconditions for the successful achievement of 
each cumulative event or criterion. 
(v) If payment of performance-based finance amounts 
is on a deliverable item basis, each event or performance 
criterion must be part of the performance necessary for that 
deliverable item and must be identified to a specific contract 
line item or subline item. 
(b) Establishing performance-based finance payment 
amounts. (1) The [CO] must establish a complete, fully 
defined schedule of events or performance criteria and 
payment amounts when negotiating contract terms .... 
(3) The contract must specifically state the amount of 
each performance-based payment either as a dollar amount or 
as a percentage of a specifically identified price (e.g., contract 
price, or unit price of the deliverable item) .... 
( d) Liquidating performance-based finance payments. 
Performance-based amounts must be liquidated by deducting 
a percentage or a designated dollar amount from the delivery 
payments. The [CO] must specify the liquidation rate or 
designated dollar amount in the contract. The method of 
liquidation must ensure complete liquidation no later than 
final payment. 
(1) If the [CO] establishes the performance-based 
payments on a delivery item basis, the liquidation amount for 
each line item is the percent of that delivery item price that 
was previously paid under performance-based finance 
payments or the designated dollar amount. 
33 

(2) If the performance-based finance payments are on 
a whole contract basis, liquidation is by predesignated 
liquidation amounts or liquidation percentages. 
24. Prior to invoicing the government for any performance-based payment, 
AEON was required by the contract to submit a Milestone Payment Event Delivery 
Report (MPEDR) which was a living document to which, before submission for each 
payment, was added the most recently updated information (see, e.g., app. supp. R4, 
tab 169; tr. 2/191, 4/716). On each MPEDR AEON indicated the work that had been 
done to justify the payment requested. The CO authorized the release of 
performance-based payments only after the DFAS Program Management Office (PM0) 13 
verified that the items reported by AEON as completed were the items required to be 
completed by any particular payment event. (Tr. 1169-70, 2/174-75, 189-90, 3/397, 
4/716-19, 511082) The PMO did not perform an independent 
check or test to determine 
whether the work reported as completed by AEON was actually completed (tr. 4/719). 
AEON's MPEDR dated 1December2006 14 included the following statement by AEON: 
System Background 
1.1.1 Business and System Objectives 
The objective of the MOCAS Rehost Project is to perform a 
technology update, migrate the MOCAS system from the 
proprietary environment of MANTIS/SUPRA to the 
non-proprietary software environment of CI CS/COBOL and 
DB2, and merge the three existing databases into one 
consolidated database. The rehosted MOCAS system will 
contain all of the functionality of the current MOCAS system 
and, from a business and end user perspective, will mirror the 
current system. Therefore the changes 
that occur as a result 
of rehosting the system will be totally transparent to the users. 
(App. supp. R4, tab 169 at 12) 
13 (See finding 26). 
14 This is the report that sought payment through Payment Event 7 A-2 (app. supp. 
R4, tab 169 at 2). There is no evidence in the record that the quoted language 
was absent or different from any previous iteration of the MPEDR. 
34 

25. The contract incorporated FAR 52.249-8, DEFAULT (FIXED-PRICE SUPPLY 
AND SERVICE) (APR 1984) (R4, tab 3 at 787), which provided in pertinent part: 
(a)(l) The Government may, subject to paragraphs 
( c) and ( d) of this clause, by written notice of default to the 
Contractor, terminate this contract in whole or in part ifthe 
Contractor fails to-
(i) Deliver the supplies or to perform the services 
within the time specified in this contract or any extension; 
(ii) Make progress, so as to endanger performance of 
this contract (but see subparagraph (a)(2) below); or 
(iii) Perform any of the other provisions of this 
contract (but see subparagraph (a)(2) below). 
(2) The Government's right to terminate this contract 
under subdivisions (a)(l )(ii) and (1 )(iii) above, may be 
exercised if the Contractor does not cure such failure within 
10 days (or more if authorized in writing by the Contracting 
Officer) after receipt of the notice from the Contracting 
Officer specifying the failure. 
(f) The Government shall pay contract price for 
completed supplies delivered and accepted .... 
C. Contract Performance 
26. The PMO "had the day to day responsibility to ensure that this program was 
proceeding forward at the anticipated pace that it should, and to ensure that various events 
and milestones were being achieved" (tr. 1141 ). At all times relevant to this appeal, the 
DF AS MOCAS Program Manager was Anthony Castrillo. The PMO consisted primarily 
of Mr. Castrillo, COR Hecker 15 (deputy project manager and the primary COR from 
15 COR Hecker was part of the DFAS/DCMA team that wrote the SOW for the Rehosted 
MOCAS (tr. 4/658-59, 
696) and was the lead on the cost evaluation team that 
reviewed proposals, including AEON's (tr. 4/655, 5/891-92). 
35 

contract award through October 2005) and COR Thrower 16 (the primary COR from 
October 2005 through the end of the contract). (Tr. 1/4 I, 4/65 I, 4/654, 5/1069-76) The 
COR was the primary day-to-day 
contact for AEON (tr. 3/387-88, 400-0I, 506). During 
GT &E, COR Thrower was the liaison between the CO, AEON and the government 
testers (tr. 3/393). 
27. AEON's MOCAS Rehost Project Plan identified the various phases of the 
contract work as WBS I-I I (see, e.g., app. supp. R4, tab I 72 at 5-6). WBS I-8 correlated 
to Payment Events I-8 identified in the contract (finding 2 I). 
I. WBS I, PREP ARE & INITIATE 
28. WBS I correlated to Payment Event 1, the required tasks for which were 
identified in the contract as "Placement of purchase orders for vendors, subcontractors, 
suppliers for labor, travel, supplies and equipment within 30-45 days after contract 
award" (finding 2 I). 
29. AEON's 29 December 2006 MOCAS Rehost Project Plan showed that 
WBS I/Payment Event I was started on 28 May 2004 and completed on 30 August 2004 
(app. supp. R4, tab I 72 at 5). AEON was paid for WBS I/Payment Event I on I June 
2004 (app. supp. R4, tab I 72 at 8). 
30. Shortly after award of the contract the government learned that AEON's 
proposed Project Manager, John Allwood, and Technical Manager, Lech Lakomy, were 
not AEON 
employees and that the NPGen automated conversion tool proposed by AEON 
to be its proprietary product was actually the property of SOC Software, Inc. (SOC) 
which was owned by Allwood and Lakomy. Apparently, AEON had not reached an 
agreement with SOC and, almost immediately upon starting work on the project, AEON 
and SOC, along with Allwood and Lakomy, parted ways. (Finding 7; supp. R4, tab 106 
at 5) On I6 November 2004, eight months into the contract performance period and 
almost three months after the start of its design process (findings 37, 39), AEON formally 
requested permission from the government to use conversion tools other than NPGen: 
16 COR Thrower was a member of the DF AS/DCMA team involved in the drafting of the 
SOW, particularly in the area of the description of the As-Is MOCAS (tr. 3/387). 
At the time of her testimony, Thrower had 25 years of experience with the 
MOCAS system, I 
8 years with the DISA and nearly 7 years 
with DF AS. While 
employed by DISA, where the MOCAS system was hosted on a DISA mainframe 
(tr. 3/384-85; finding 4), one of her responsibilities was to install software changes 
to MOCAS (tr. 3/377-78). Thrower also participated in the evaluation of AEON's 
technical proposal (tr. 3/523-24, 4/656). 
36 

[AEON] performed a risk assessment study focusing on the 
code conversion toolset. Our goal was to identify the best 
toolset for the MOCAS Rehost Project .... We identified 13 
viable CCT£17l vendors and narrowed the list to 2 finalists: 
NPGen which we originally proposed and TMGi-Transformer 
toolset from Trinity-Millennium Group, Inc. (TMGi). Our 
detailed evaluation resulted in TMGi equaling or exceeding 
the NPGen functionality in every evaluation category. 
Therefore, we are seeking DF AS approval to amend the 
MOCAS Rehost Project Contract to replace TMGi CCT and 
iSA T repository for the NPGen CCT and NPGen Repository 
that was originally proposed. 
Benefits. The TMGi-Transformer CCT and the related iSAT 
Repository provide excellent capabilities, specifically tailored 
code conversions to CICS COBOL and DB2 from Mantis and 
Supra respectively. TMGi also offers technical support 
services related to both the user of the CCT and the normal 
activities associated with code conversions. TMGi specializes 
in IT portfolio modernization and offers extensive 
documentation services as well as actual code conversion. 
[AEON] is currently using TMGi's Knowledge Mining 
services to support our program documentation activities. 
Adding the TMGi transformation services provides an 
integrated solution appropriate for the MOCAS Rehost 
Project. 
Impact If No Approval. [AEON] could continue to use the 
NPGen code conversion tool and repository as originally 
proposed. However, [AEON]' s recent assessment indicated 
that the project risks are higher and the CCT capabilities 
would be less than ifTMGi-Transformer were substituted. 
[AEON] would extend the current agreement with TMGi to 
include code conversion services. From a DF AS perspective 
there would be little or no change to the [AEON] approach 
proposed for the MOCAS Rehost Project. The project 
repository content would continue to be stored on the project 
17 We understand this to be an acronym for Code Conversion Tool. 
37 

servers using SQL Server and MS Visual SourceSafe, a 
widely-used COTS product for configuration 
management, 
would [be] substituted for the proprietary CM[ I SJ capabilities 
that were to be incorporated into the NPGen Repository. The 
COTS approach to CM is a less risky approach tha[ n] the 
custom developed, proprietary approach associated with 
NPGen. As an added benefit, TMGi delivers an easy to use, 
browser-based user interface to front-end the iSAT repository 
that is delivered along with their services. 
Cost Impact. None. The proposal to utilize TMGi has an 
additional cost to the project. However, we believe the 
breadth of capabilities of the TMGi-Transformer toolset will 
allow us to accomplish the rehost project objectives with 
fewer staff. The staff efficiencies associated with the use of 
TMGi offset the costs of their toolset/services and some of the 
additional scope/costs identified during the Discovery 
Phase .... 
Team Impact. Minimal. The proposed toolset and 
associated repository are easier to tailor and use than the 
approach originally proposed. 
(R4, tab 9 at 959-60) The government approved the request on 8 December 2004 (R4, 
tab 9 at 961) because it "saw benefit" in the use of the TMGi tools and services AEON 
requested to use in place of the NPGen tool: 
[W]hen [AEON] changed to the [TMGi] 
tool, that tool 
brought to them a discovery method that would allow you to 
go in and extract the information from the system, which was 
a lot more accurate than a handwritten document[ ation]. So 
they had the opportunity to get [system] information from 
things that they developed. 
{Tr. 5/906-07) The lack of an agreement with SOC for the NPGen conversion tool also 
meant that key individuals Allwood and Lakomy in AEON's proposed management team 
18 Configuration Management (R4, tab 25 at 1187). 
38 

(finding 7) were no longer going to participate in the project (supp. R4, tab 106 at 5-6; 
tr. 1/52, 57-60, 2/280-87, 4/738-39). 
As a result of these initial changes AEon requested, their 
whole approach and management structure was changed from 
their proposal. The number and nature of the changes raised 
concern with the Government. The main concern being that 
many of the items (i.e. Management and tool set) being 
replaced were those items the Government saw as strengths in 
their proposal and were important reasons for selecting AEon. 
Despite these concerns, the PMO honored the premise of a 
Firm Fixed Price Contract, in that the Government should not 
direct the contractor in how they perform their work; honored 
the premise that the contractor should be the best judge of 
their competency and tools required; and in good faith 
allowed AEon to proceed with their changes. 
(Supp. R4, tab 106 at 6) 
2. WBS 2, DISCOVERY 
31. WBS 2 correlated to Payment Event 2, the required tasks for which 
were 
identified in the contract as "Discovery Phase completion identified by the delivery of the 
Discovery Findings and implications report and scheduled for the end of the 1st quarter of 
performance" (finding 21). AEON's 29 December 2006 MOCAS Rehost Project Plan 
showed that WBS 2/Payment Event 2 was started on 16 August 2004 (app. supp. R4, 
tab 172 at 5). 
32. The discovery phase of the contract was considered a significant portion of 
contract performance (findings 6 (at Questions 33, 74), 12). CO Gladski testified that the 
government built the discovery phase into the contract so AEON had an opportunity to 
analyze the As-Is MOCAS: 
[U]p front, even before they started to do any coding.. . 
. And 
we paid them very well for that particular phase. We 
considered that probably one of the most critical steps of the 
program, was for them to know what was inside that [As-Is] 
MOCAS .... 
(Tr. 1199, 4/665; see also tr. 11132-34, 2/235-41; app. supp. R4, tab 169 at 12-13) The 
government's only role in the discovery phase was to provide the As-Is MOCAS 
(findings 1, 12) to AEON for its study and analysis (tr. 11100). The discovery phase: 
39 

[I]s one where you would discover scope issues, as well as 
complexity issues. I mean, for example, there may have been 
a lot more code than was originally understood to be there. 
The code may be way more complicated than folks had 
originally expected, and things of that sort. 
Because typically when one proposes, there is a certain 
amount in any program -- well, let's just say uncertainty and 
over-optimism ... [and the discovery phase helps eliminate that 
type of problem]. 
(Tr. 7/1191-92, 1247) 
33. In its 15 October 2004 Discovery Findings Report (Version OlA), AEON 
identified 4, 100 hours of additional work identified during the discovery phase of the 
contract (R4, tab 7 at 950-51 ). In the 27 October 2004 PMO review of the report, the 
government acknowledged that some of the source code had been missing and either 
provided additional information to AEON or expressed that additional research would be 
done (R4, tab 7 at 949, ~~ 6, 16, 23, at 950-51, 953, ~~ 8, 17-18, 29-32, at 952, ~~ 20, 26; 
tr. 4/665-67, 743). In response to AEON's request for test data, the government reminded 
AEON that test data and copies of production interface files were not identified in the 
solicitation as government-furnished items (R4, tab 7 at 950, ~ 7; see also finding 20). 
The government further stated 
in response to AEON' s various requests for test data: 
Although the government will try to accommodate any 
request for copying inbound data sets from production, we 
will not guarantee these data sets test 100% functionality. 
Aeon must recognize that it is Aeon's contractual 
responsibility to develop test data to ensure the rehosted 
system meets the contract requirements. The Government 
will not provide 
test data. The Government provided an as-is 
snapshot that is a replica of the production environment that is 
able to process any and all data that the corresponding 
production database can. There was always a possibility that 
specific types of data may not be included in the snapshot at 
the time it was replicated. Test data and copies of production 
interface files were not identified as government furnished 
property in the solicitation. 
40 

(R4, tab 7 at 949-54, iii/ 5, 28, 34, 35; see also findings 6, 12) 
34. AEON's 29 December 2006 MOCAS Rehost Project Plan showed that 
WBS 2/Payment Event 2 was completed on 15 November 2004 (app. supp. R4, tab 172 
at 8). AEON was paid for WBS 2/Payment Event 2 on 19 November 2004 (app. br. at 
12-16). 
35. On 2 December 2004 AEON advised the government that: "The AEON 
Group, LLC has completed our impact assessment on cost and schedule based on the 
phase 2 Discovery Report Findings and are pleased to report that there will be no change 
to price and schedule as a result of these findings" (R4, tab 8) (emphasis added). 
3. WBS 3, DESIGN 
36. WBS 3 correlated to Payment Event 4, the required tasks for which were 
identified in the contract as "Design Phase 
completion identified by the completion of 
database and application (online & batch) design and scheduled for[] the end of the 3rd 
quarter of performance" (finding 21). 
37. AEON's 29 December 2006 MOCAS Rehost Project Plan showed that 
WBS 3/Payment Event 4 and WBS 4/Payment Event 3 (see finding 39) were both started 
on 16 August 2004 (app. supp. R4, tab 172 at 5). 
38. AEON's 29 December 2006 MOCAS Rehost Project Plan showed that 
WBS 3/Payment Event 4 was completed on 31January2005 (app. supp. R4, tab 172 at 5; 
supp. R4, tab 106 at 8-9). AEON was paid for WBS 3/Payment Event 4 on 18 April 2005 
(app. supp. R4, tab 172 at 8). 
4. WBS 4, PROOF OF CONCEPT 
39. WBS 4 correlated to Payment Event 3, the required tasks for which were 
identified in the contract as "Proof of Concept completion identified by the results of the 
proof of concept and scheduled for the end of the 2nd quarter of performance" 
(finding 21). AEON's 29 December 2006 MOCAS Rehost Project Plan showed that 
WBS 4/Payment Event 3 and WBS 3/Payment Event 4 (see finding 36) were both started 
on 16 August 2004 (app. supp. R4, tab 172 at 5). "The conversion process was divided 
into several 
concurrent phases to include the conversion of the database, on-line 
programs, batch programs, SDW interface and Contract Transfers" (supp. R4, tab 106 at 
9). 
41 

40. AEON's 29 December 2006 MOCAS Rehost Project Plan showed that 
WBS 4/Payment Event 3 was completed on 25 February 2005. AEON was paid for 
WBS 4/Payment Event 3 on 18 April 2005. (App. supp. R4, tab 172 at 8) 
5. WBS 5, CONVERT 
41. WBS 5 correlated to Payment Events 5 and 6. The required tasks for Payment 
Event 5 were identified in the contract as "Data conversion completion identified by the 
loading of the database into DB2 and scheduled for the end of the 4th quarter of 
performance." The required tasks for Payment Event 6 were identified in the contract as 
"Conversion completion identified by the successful completion of unit testing and 
moving all code from the development to the QA/testing environment scheduled for the 
end of the 5th quarter of performance." (Finding 21) AEON's 29 December 2006 
MOCAS Rehost Project Plan showed that WBS 5/Payment Event 5 was started on 
3 January 2005 and continued through 11 October 2006 (app. supp. R4, tab 172 at 5). 
The record shows that AEON was paid for Payment Event 5 on 21 June 2005 (app. supp. 
R4, tab 172 at 8). 
42. Michael Krajnak became involved in the MOCAS Rehost project during the 
discovery phase in September 2004 as an employee of CSC (see finding 8), to whom 
AEON subcontracted certain 
contract work. His primary work was as the lead on-line 
programmer responsible for converting the MANTIS code to COBOL. Toward the end 
of his tenure with the project in 2006 he became the "transition planner" and worked on 
the MOCAS Rehost project through May 2006 (see finding 51 ). Krajnak had extensive 
experience with computer programming and testing beginning in 1981. He had 
previously worked on a project performed by Boeing involving the Shared Data 
Warehouse (SDW), a separate system linked to the MOCAS (finding 5). (Tr. 4/838-45, 
853-55, 860-61, 866-68, 870-73) Krajnak described his duties as oversight of 
programming and conversion work by AEON and contract employees, as well as working 
with the AEON testing team (tr. 4/845). 
43. In a 13 April 2005 internal email, just four months after its approval 
(finding 30), AEON identified numerous "issues" with the TMGi conversion tool: 
~ Tool Development Issues: 
o The tool was developed from scratch using 
VB£19l at our expense. 
o We paid and are paying for it. 
o The tool that was shown to us originally was a 
Rex based tool. 
19 We understand this to be a reference to Visual Basic, a programming language. 
42 

o We were led to believe that TMGi has a tool 
that can convert Mantis to CICS COBOL and 
SUPRA to DB2. This tool only needed to be 
customized to the MOCAS unique requirements 
o We provided all the specs for the development 
of the VB tool 
o Chuck [Cotton] spent a great deal of his time 
debugging the tool and assisting TMGi with 
tool design, development and improvements 
o TMGi lacked Mantis, CICS and DB2 
knowledge and expertise. We provided these 
capabilities for TMGi 
~ Transformation project performance issues: 
o The project plan developed by TMGi was not 
adhered to and no updated plans have been 
given to Aeon. All to-date pre-production dates 
have been missed: 
• The final transformation for the first two 
online deliverables, due in February, 
have not occurred yet. We have not been 
notified of a new date for their delivery. 
Based on the quality of work we can not 
assess or assume a delivery date 
• The other online groups planned for 
March and April have not been delivered 
and no new dates have been provided to 
us. 
• The batch commitments have not been 
met. The work on interface 
transformation has not 
started 
• The TMGi missed dates have had a 
significant negative impact for the 
delivery of our code to QA. Without 
significant intervention and addition of 
new resources by Aeon, this can cause us 
to miss our commitments to our client by 
about 6-8 weeks (first major online 
deliverable, YC02 with 400 programs, 
was due to move to QA on 4126105 based 
43 

on its delivery from TMGi to Aeon in 
February 2005. The new date is 6/17/05) 
Aeon by [sic]. 
o The project quality has been inconsistent and 
poor; 
• Progress achieved in December and 
January was considerably deteriorated 
until the mid March time frame when it 
started improving. We had 180,000 
errors in the first two online groups 
(YSUOl & YCU02). These errors were 
subsequently grouped by Aeon into 10 
groups for the purpose of discussions 
with the client. Some of the errors 
were Aeon related but majority were 
TMGi. We assume contributing factors 
to the deterioration are the events that 
occurred during the role change between 
Stan and Mike. Mike had been involved 
in the online and Stan in the batch 
transformation. During the end of 
January and early February, Mike handed 
off the online to Stan and Stan handed 
off the batch to Clarence. The 
consolidation of the transformers on 
Mike and Stan's PCs caused major tool 
confusion and led to numerous errors. 
• Work quality on the weekly handoffs 
from TMGi are very inconsistent. Some 
weeks the work is good and many weeks 
the work deteriorates as compared to the 
previous handoffs. To-date there are 
80,000 errors on the above mentioned 
two online groups. 
• Considerable overtime charged to Aeon 
during the period when the hand-off 
occurred and tool was considerably 
deteriorated. While we did not support 
the minimization of Mike's involvement 
and the handoff of the online to Stan, we 
expected a smooth transition and did not 
44 

expect to pay overtime for deteriorating 
work quality. 
o Lack of a development environment at TMGi 
office to perform the work to produce its 
committed 100% comp liable code: 
• While TMGi insisted to work one week 
onsite and one week [oft] site, TMGi did 
not have a development 
environment 
similar to MOCAS (mainframe) to 
perform compilation and assess its tool 
and transformation quality before 
handoff to Aeon. 
• Since Aeon was using Micro Focus 
COBOL for its development 
environment, Aeon provided TMGi with 
a thirty day trial Micro Focus COBOL 
software. Aeon's understanding was that 
TMGi will procure its own license at the 
end of the thirty days. We are told that 
the 30 days trial license has expired and 
TMGi has not procured its own license. 
As a result TMGi can no longer compile 
and test its tool and transformed code 
prior to hand off to Aeon. This can 
explain the inconsistent work quality 
received by Aeon. 
? Aeon issues: 
o Aeon has not been paying TMGi invoices on a 
timely fashion due to internal process problems. 
This has been remedied and new processes have 
been established to avoid the delay 
o Aeon has not provided some information to 
TMGi on a timely fashion. Other information 
needed by TMGi, copy books, has been made 
available to TMGi and can only be accessed 
while TMGi is onsite [every other week.] 
45 

(Supp. R4, tab 52) (Emphasis added) Thereafter, in or around the second quarter of 2005, 
AEON parted ways with TMGi after experiencing significant problems with the TMGi 
tool "not converting the anticipated amount of code or MANTIS functionality" (supp. R4, 
tabs 63, 106 at 9-10). From that point on, the conversion process included much more 
manual conversion and experienced multiple delays (supp. R4, tab 106 at 10, 13-14; R4, 
tab 64; tr. 1/88, 4/743, 857-59). 
44. In an internal email dated 5 October 2005, and identified as "Updated 
Situation Analysis," AEON's Program Manager (see R4, tab 25 at 1162), acknowledged 
that AEON had not disclosed to the government "the poor quality of the TMGi tool" and 
that AEON "need[ ed] some 
time to address all the deficiencies we have discovered" 
(supp. R4, tab 63). Also on 5 October 2005, and in apparent preparation of the same 
"Updated Situation Analysis," AEON contractor employee Krajnak (finding 42) 
expressed concerns about the ability of AEON to meet the contract delivery dates and 
functionality requirements: 
Need to tell the client that the project will be delayed at 
least six months and that UAT will not start on Jan 2006 but 
on July 2006. The government expects both batch and online 
programs to function properly at the start ofUAT. The 377 
unconverted online programs will take 2 months to get ready 
for QA testing. The online and batch programs will need 4 
months to fix defects in order to pass the QA functionality 
tests. Performance, Interface, and System tests 
will take an 
additional 3 months. 
(Supp. R4, tab 64) 
45. On 5 October 2005 AEON formally requested an extension of just 1 Yz months 
to complete the conversion process (supp. R4, tab 106 at 10), not the six 
months 
recommended by Krajnak (finding 44) and, with respect to its QA testing, stated to the 
PMO: 
This is a very complex project that needs continuous 
management attention. This is the reason that the internal 
audit function has focused on proactive improvement 
recommendation rather than periodic statements of 
assessment. I would also like to explicitly express our QA 
strategy and approach for the project: 
• QA is a five month set of continuous activities that 
produces a deliverable (fully tested Rehosted MOCAS) 
46 

at its conclusion. While we have specific tests that we 
will be conducting at different times during the five 
months duration, these are internal progress points and 
QA has a single final deliverable. 
• The functionality testing to be completed by 12/30/05 
is intended to provide enough verification of the 
functionality that would enable the remainder of our 
QA (systems testing) activities to be conducted. We 
recognize and believe that we may have functionality 
defects that will be identified and corrected throughout 
the five months QA period. 
(Supp. R4, tab 68 at 4) In a 
7 October 2005 email, AEON advised the PMO that: 
Impact to QA: 
It was determined that the time remaining to perform 
functional testing and defect resolution was insufficient to 
produce a fully functional quality product ready for system 
testing. Therefore functional testing was extended from 
10/14/05 to 12/30/05 in order to achieve that objective. 
(R4, tab 65) AEON also stated in the email that 
"some lines of code were dropped during 
the transformation process" when the "transformation tool was unable to handle specific 
MOCAS code complexities." Even though the record makes 
clear that AEON was aware 
of significant TMGi conversion problems no later than April 2005 (finding 43), it 
reported to the PMO that this problem with the "transformation tool" was "discovered 
during QA testing in August [2005] and caused additional work in September [2005]." 
(Supp. R4, tab 65) The AEON request in early October 2005 for an extension to 
complete the conversion process was the first indication the government had that AEON's 
ability to meet the contractual milestone dates was slipping (tr. 3/430-32). 
46. On 19 October 2005 AEON contract employee Krajnak reported: 
Initial defect rate of the online programs is extremely 
poor. Zero programs have passed QA testing. YINV has 13 
critical defects for 4 programs. YSUl has 16 critical defects 
for 24 programs. The lack of real unit testingczo1 is a risk to 
completing the QA functional testing before system I 
performance test starts on Jan 2006. It is an extremely tight 
20 (See findings 16, 47, 55-59). 
47 

schedule to test and resolve all functional errors by Dec 2005. 
Suggest adding additional 3 months delay to the schedule to 
ensure that all known functional errors are resolved before 
government testing. 
(Supp. R4, tab 66) As of 9 November 2005, Krajnak was still reporting significant 
failures of programs in QA testing (supp. R4, tab 66). 
4 7. On 4 November 2005 the government was advised that AEON had removed 
its QA and Test Manager from the project (supp. R4, tab 69). Despite record 
evidence of 
the significant code conversion problems due to the failure of the TMGi tool and the 
failure of AEON to perform unit testing (findings 43-46), on 9 November 2005 AEON 
management glossed over the conversion tool problems and insisted to the PMO that, 
with respect to unit testing: 
• We have and will continue to conduct unit testing. 
• Unit testing is the category of testing that developers 
perform on a single program. This test is performed 
against a program specification to ensure that each 
program performs in accordance with its program 
specifications. Unit testing is not a user/business 
functionality testing because usually a single program 
does not address the full scope of each user function. 
User functions are usually addressed across several 
programs. When programs specifications are not 
available, the unit testing becomes "reasonability" 
testing. 
• Unit testing for conversion projects is very different 
from new development projects. In the new 
development project business and systems 
requirements specifications are available. From these 
specifications, architecture and designs are developed 
and documented. The design documents are used to 
create program specifications which in tum enable 
program development. Programmers develop their 
programs in accordance with the program 
specification. When the program is developed the 
programmer unit tests the program against the program 
specifications. For conversion projects such as 
MOCAS Rehost there usually are no business or 
system requirements and no design or program 
specifications. Further the programs are partially or 
48 

fully converted using a tool. Therefore, there are no 
specifications to use to test the program against and the 
programmer does not have an in-depth knowledge of 
the program in order to conduct a comprehensive unit 
testing. In such cases limited tests are conducted to 
confirm reasonableness of the converted code. These 
tests are conducted to verify that each program is 
compiled correctly, can be executed and run without 
error. Further, screens are also brought up with 
representative data to observe that reasonable data 
appear on them. 
• The unit testing no matter how comprehensive would 
not have identified the majority of the defects 
identified in QA. Many of the defects that caused the 
numerous hand offs to QA were related to screen field 
layout which is not a critical problem but for 
automated testing it stops the test from further 
execution. These defects can not be discovered during 
unit testing. They are discovered during the 
functionality testing. 
(Supp. R4, tab 68) The PMO later reported that: 
During the Conversion Phase, AEon conveyed that they were 
streamlining their testing. The streamlining consisted 
primarily of reducing the amount of unit testing 
performed .... l211 [I]t appears that AEon did not meet the 
objectives defined in their [STP] and [PQAP] as indicated in 
their certification prior to GT &E. Although the PMO does 
not have insight into all causes of AEon's non-performance, it 
is our position that AEon did not perform the level of care in 
their testing that is required by industry standards and best 
practices. The PMO believes that the reduced level of care 
was the primary cause for the lack of quality in their delivered 
product. The PMO also, believes that by de-scoping their 
testing requirements and not fully ascertaining the 
functionality of the As-Is system, AEon did not fulfill their 
obligation of ensuring that the rehosted system had I 00% 
functionality of the As-Is system. 
21 See finding 46; tr. 4/846-47. 
49 

(Supp. R4, tab 106 at 11) We find AEON's position that, instead of unit testing, all it 
could perform in a conversion project such as the one now at issue was "limited 
[reasonableness] tests" to be contrary to the weight of the record before us. AEON's 
position is contrary to its own proposal with regard to testing (finding 7), is contrary to 
the contract requirements (finding 16), is contrary to AEON's own PMP 
(findings 11, 55), and ignores the significant fact that, in this particular conversion 
project, AEON was provided with a full copy of the As-Is MOCAS, including production 
data, that comprised a comprehensive performance specification to which AEON was to 
design and build the Rehosted MOCAS and against which it could test and compare every 
aspect of the Rehosted MOCAS (see finding 12). 
48. AEON reported that it had 
successfully completed the conversion process for 
the on-line and batch programs on 18 November 2005. By 16 December 2005 or soon 
thereafter the Contract Transfer and SDW interface conversions were also reported as 
complete and the entire conversion process was reported to be completed by 11 October 
2006. (Supp. R4, tab 106 at 10; app. supp. R4, tab 172 at 5) AEON's testing of the 
conversion effort took nearly two years (see finding 41 ). The PMO later reported: 
Due to AEon minimizing issues and continually reassuring 
the Government that the project was going as planned, the 
Government does not have insight into what may have caused 
these defects. We do not know how successful the TMGi tool 
was at converting the code; how many problems were brought 
about by the requirement for manual conversion; if AEon' s 
testing method was insufficient or a combination of these 
factors lead to the problems found during GT &E. 
(Supp. R4, tab 106 at 10) 
49. Modification No. (Mod. No.) P00006, dated 9 January 2006, modified the 
delivery date for the Rehosted MOCAS (CLIN 0001) to 4 May 2006 and subdivided 
payment events 6 and 7 into 6A, 6B, 7 
A and 7B with specific tasks under CLIN 0001 
identified to each subdivision as follows: 
The MOCAS Rehost Project contract defines eight (8) 
Milestones with their related Performance-based Payments. 
Beginning with Milestone 6 the contract payments are revised 
to relate to Payment Events that are Performance-based, each 
of which includes evidence to support completion of these 
Performance-Based Payments as shown in the following 
table .... 
50 

No. 6A- Code Conversion Event- Evidence for payment per 
60% Applications Converted. contract: "Conversion 
completion identified by the 
Estimated Payment successful completion of unit 
Request date l / 16/06 testing and moving all code to 
the QA/Test environment. .. ,, 
... Updated Program 
Management Plan due 
1115/06 .... 
No. 6B- Functionality Testing Evidence for payment per 
40% Event revision to contract[:] "Level 
I & Level II Functionality 
Estimated Payment Testing complete and 
Request date 3/31/06 Documentation Deliverables 
with various publication dates 
between January 03 and 
March 31, 2006. Refer to 
Extended MOCAS Rehost 
Project Plan (WBS): 
• Level I & Level II 
Functionality Testing complete 
0 
All automated test 
scripts completed 
0 
All database and file 
compares completed .... 
No. 7A- User Acceptance Event Evidence for payment per 
50% revision to contract: "User 
Estimated Payment Acceptance event identified by 
Request date 5/4/06 moving software from QA/Test 
environment to User 
Acceptance environment for 
start of User Acceptance 
Testing ... and Documentation 
deliverables with dates as listed 
below." 
• User Acceptance includes: 
° Functional 
configuration Audit 
0 
Operational User 
Acceptance Test 
Environment 
51 

0 
Training conducted for 
computer operations, 
application programmers and 
technical support personnel. ... 
No. 7B User Acceptance Event Evidence for payment per 
[50%] Complete revision to contract: "User 
Acceptance event completion 
Estimated Payment identified by the expiration of 
Request date 8/4/06 the contractually defined 
90-day UAT period within 
which the following items are 
delivered: 
• A complete set of 
documentation as outlined in 
Section C 14 of the SOW 
• Fully tested and 
debugged 
MOCAS system .... 
No. 8 Production Complete Evidence for payment per 
Event contract: "Completion of the 
delivery and acceptance of 
Estimated Payment CLINOO 1 in the Production 
Request Date 12/1/06 environment ... ,, 
• Acceptance of CLINOO 1 in 
the Production environment 
and completion of all tasks 
in the SOW including: 
0 
MOCAS Rehosted 
System installed in the 
Production Environment 
0 
A complete set of final 
documentation as 
outlined in Section C 14 
ofthe SOW 
0 
Delivery of the MOCAS 
Rehosted System and 
Migration Programs 
0 
The sequential 
migration of the three 
AS-IS MOCAS 
databases to the new 
MOCAS Production 
System 
52 

0 
Signed off Production 
System 
0 
Updated Milestone 
Payment Event Delivery 
Report .... 
(R4, tab 3 at 848, 856-60) Mod. No. P00006 included a mutual release stating that both 
parties "acknowledge full and final settlement for all past conditions leading to and 
culminating with the release of this contract modification" (R4, tab 3 at 850). 
50. Mod. No. P00005, also dated 9 January 2006, accepted AEON's ECP-1, 
increased the contract price by $70,633.00 and further extended the contract completion 
date to 9 June 2006 (R4, tab 3 at 839; see also supp. R4, tab 106 at 9). 
51. AEON subcontractor CSC employee Krajnak (finding 42) testified that, at 
some point in the project, AEON had not paid CSC for seven months of work (see finding 
62). As a result, seven CSC employees including Krajnak were notified by CSC that they 
were free to take employment elsewhere. Krajnak was approached by AEON to become 
an AEON employee; after considering it over the weekend, on 21 May 2006, Krajnak 
declined AEON's offer. (Tr. 4/861-66) Instead, he accepted employment with DCMA in 
support of the MOCAS project (supp. R4, tab 77). 
6. WBS 6, DOCUMENTATION 
52. WBS 6 correlated to Payment Event 7 A, the required tasks for which included 
"User Acceptance event identified by moving software from QA/Test environment to 
User Acceptance environment for start of User Acceptance Testing ... and 
Documentation" (findings 21, 49). AEON's 29 December 2006 MOCAS Rehost Project 
Plan showed that WBS 6 was started on 13 September 2004 and the documentation for 
the Rehosted MOCAS was reported to be 99% complete as of the date of the report 
(app. supp. R4, tab 172 at 5). 
53. On 19 September 2005 CO Gladski notified AEON by letter that: "Aeon is 
also hereby notified that ... milestone payment 6 will be delayed as milestone payment 
6 remains contingent on the delivery of all documentation" (R4, tab 16). Milestone 
payment 6 was later subdivided and reconfigured numerous times (findings 49, 54, 63, 
65, 70). 
53 

7. WBS 7, AEON'S QA/TEST; DELIVERY OF DOCUMENTATION 
AND REHOSTED MOCAS FOR GT&E; POST-GT&E DELIVERY COMPLETION 
54. WBS 7 correlated to Payment Event 7. AEON's 29 December 2006 MOCAS 
Rehost Project Plan showed that WBS 7 was started on 19 July 2004 (the official start of 
the entire project) and was completed on 20 October 2006, a period of 32 months 
(R4, tab 106 at 1; app. supp. R4, tab 172 at 5). Because of the complexity and length of 
time required to complete all of these tasks, Payment Event 7 was later subdivided into 
7Al, 7A2, 7A3 and 7B (findings 49, 70). Payment Event 7Al required the completion of 
AEON's QA/Test (except what was specified for completion in Payment Event 7A2 
below), delivery of the Rehosted MOCAS for GT &E and delivery of all documentation 
except that specified to be delivered under Payment Events 7 A2 and 7 A3 (R4, tab 3 at 
921-22). Payment Event 7 A2 required delivery of the Software Design Description 
(SDD) documentation and Completion of AEON's Level II Functionality Testing for 
Contract Transfers, LUW 16 (R4, tab 3 at 923). Payment Event 7A3 required delivery of 
remaining documentation (id.). Payment Event 7B required that, by the end of the 
180-day GT&E government testing period (finding 18), AEON had migrated all three 
MOCAS databases (i.e. MOCs) into production and had delivered a ''[f]ully tested and 
debugged MOCAS system" with complete updated documentation (R4, tab 3 at 924; 
tr. 3/411, 417). 
a. AEON'S QA/TEST 
55. AEON's PMP included the following section pertaining to testing: 
2.9 Test and Evaluation Management 
To provide comprehensive testing and deliver high quality 
results, testing has been grouped into [the] following ten 
major categories: 
• Unit Testing - The objective of unit testing is to 
ensure that each program is fully tested by the 
conversion team prior to handoffto the test team. 
• Functional Testing- The objective of the functional 
testing is to ensure that the rehosted MOCAS System 
with the 
converted databases on the new hardware 
environment has 100% of the functionality (screen 
emulation, screen layout, order of fields, edits, error 
messages, help button, reports, and interfaces) of the 
current MOCAS System including the online, batch 
and the database. 
54 

• Technical System Testing- The objective of 
technical testing is to ensure that the rehosted MOCAS 
System is in 100% compliance with the relevant 
MOCAS technical and architectural characteristics, 
internal control, etc. 
• Performance Testing- The objective of performance 
testing is to ensure that the rehosted system will have 
the same or improved system response time, batch 
windows, capacity for ongoing operations, 
performance under high transaction volumes and other 
performance characteristics as compared to the current 
MOCAS System. Further, users who access the system 
from various locations worldwide can continue to do 
the same with the rehosted system, with the same or 
improved performance[.] 
• Security Testing- The objective of the security 
testing is to ensure that the rehosted system will have 
the same security accreditation as the current MOCAS 
System which is Certification and Accreditation 
Level 2, in accordance with DoDI 5200.40, DoD 
Information Technology Security and Accreditation 
Process and DoDD 5200.28, Security Requirement for 
Automated Information. 
• Conversionffrial Migration Testing - The objective 
of trial migration testing is to test the conversion of the 
three "as-is" MOCAS databases to the one "target" 
database test environment to ensure that all the data is 
converted, the conversion processes are optimized and 
will take place well within the prescribed conversion 
time frame. 
• Regression Testing - The objective of regression 
testing is to provide fast, automated and high quality 
means of re-testing the software after corrections have 
been applied to software problem fixes. Regression 
files are created from test cases and used for final 
functionality verification. 
55 

• Integration/End-to-End Testing - The objective of 
integration/end-to-end testing is to ensure that the 
rehosted MOCAS System with the converted databases 
on the new hardware environment correctly integrates 
all MOCAS System components to perform an 
end-to-end system transaction in exactly the same 
manner as the current MOCAS System. Specifically, 
the new system can perform a business transaction 
from its inception 
on the rehosted MOCAS System 
through the internal and external interfaces and provide 
the same results as obtained with the current MOCAS 
system. 
The test plans will be initially executed against the baseline 
system. The test plans will then be re-executed in the QA 
target region. The baseline results will be compared to the 
target results, corrections made and tests re-executed as 
appropriate. Refer to the Software Test Plan for the details 
associated with all the testing to be performed. The fully 
tested target chunk will then be moved to the staging 
environment. The Repository is updated with test completion 
and staging activity completion dates. A final reconciliation 
of the Repository and the actual components by chunk take 
place to reconfirm that all life cycle activities have taken 
place. 
AEON is sensitive to the Government's performance 
expectations that were defined in the MOCAS Rehost As-Is 
Documentation, MOCAS Rehost As-Is Attachments. When 
we are ready to execute performance testing, we will create a 
"production-like" environment with the same priority level as 
production. We will run tests against the baseline 
environment, rerun the same tests against the target 
environment, compare the results, make adjustments and 
rerun as appropriate until the same or better performance is 
received in the target environment. 
(R4, tab 25 at 1191-92) 
56 

56. Unit testing is "fundamental" (tr. 7/1202) and "is the most intense testing 
performed" (tr. 5/902). 
(Tr. 4/662) 
[E]ach individual program is tested by itself, and then it gets 
further integrated into kind of a group of programs that will 
perform their function, which is integration testing. And then 
that rolls up to even greater as the whole, the system 
testing .... and then user acceptance testing. 
57. The record reflects that, by 8 June 2005, AEON management had made "a 
change in direction to skip unit testing" and that some of AEON's employees were 
"questioning [AEON's] intent to deliver a functional system" (supp. R4, tabs 55, 56). 
AEON's lead programmer, CSC subcontract employee Krajnak (findings 42, 46), testified 
that: 
[AEON' s] initial direction with the unit testing was that the 
programmers were allowed to use normal processes to work 
through the code, and to basically bring it up to the state 
where it should be given over to the testers for testing. 
[To skip unit testing] was a change in direction and the 
staff was pretty upset about it, and that they were then told 
that they could no longer look at the logic of the old 
programs. 
That they had to just take the programs and get them 
compiled cleanly, and send them over the fence to the testing 
unit, basically bypassing what I would expect the normal unit 
testing by the programmers [to be]. 
In my understanding [normal unit testing] would be 
when the program has been looked at and run through some 
preliminary test scenarios so that the programmer knows that 
this program is going to fulfill the function that it was written 
for, and that it will initiate and not end, and do the correct 
database points. 
57 

It is not an in-depth program that is going to test all the 
functionality, but it is basically a check on the critical nature 
of the program so that it is close enough so that it can be sent 
for rigorous testing by the testers. 
That was our instruction, [that the unit testing was not 
going to be done], not at the time to effectively unit test the 
programs, and like I stated earlier, we were told to just get the 
programs compiled cleanly out of the back end of the 
translator, and to make sure that they could be started without 
ending, and then give those over to the testing team for 
quality testing. 
You take the old program, and you run that through a 
test, where 
you look at the screen from the database calls, and 
you see what behavior it exhibits, and you test that versus 
what the new program does, and you compare the results, and 
you expect it to behave the same way. 
It is also involved with something called system 
testing, which is the integration of individual programs, and 
that is a later phase, that all the programs interact with each 
other correctly so that the whole application works properly. 
[Unit testing] is on a program by program basis .... 
[Quality testing is a] more functional test. ... [Integration 
testing] is where you take large units of programs and you 
verify that they will all play well together. 
I don't know for sure [why unit testing was skipped], 
but it appeared that the schedule was in jeopardy, and that this 
was a way to get us back on schedule with the work plan that 
would say that we had so many programs done by X-amount 
of time .... 
58 

... AEON was under contract to convert the MOCAS 
system. There is a work schedule put out, and by we, I meant 
the programming staff was instructed to convert so many 
programs per week to get this done to meet the schedule. 
And we were behind schedule, and my understanding 
is that this was an attempt to get them back on schedule, but 
in doing so, you are going to lose the quality of the programs, 
and it is going to take more testing time in the QA area. 
So you might meet the numbers, in terms of getting the 
correct number of programs compiled, and over to the test 
team, but it lessens the likelihood that the programs will pass 
testing . 
... [I]t needs to pass both the functional and the 
integration testing. So I was suggesting that because this was 
rushed, what that basically did is that it made more pressure 
on the test team, and in my estimation, more risk to the whole 
project . 
. . . What we were asked to do was sidestepping the 
normal process. 
It was a hurried up approach, and I felt that it had great 
risk, and that is why I was so outspoken about it. 
(Tr. 4/845-50, 853, 855-56; see also R4, tab 38 at 1268-71; finding 46) COR Hecker 
testified: 
I believe at some point, and it might have been trying 
to save some time in testing, [AEON] abandoned the formal 
sense of unit testing, and after the code was converted, instead 
of having unit testing, I think they sent it straight to their 
quality assurance group for testing. 
59 

.. .I think early on that their test plan called for unit 
testing, and I believe they followed it. They did the unit 
testing, but later on either they felt it wasn't necessary through 
their experience, or they decided that they didn't need it. 
... Unit testing is normally done by a programmer, 
and ... at some point, they decided to not have the programmer 
do the unit testing, and send the program straight over to the 
[quality assurance] test team to test. 
They did more of what I would call an integrated test 
or almost a system test. More of a functional test.... They 
were testing a group of programs at that point, like a contract 
input function, or an input of a DD-250, and the inputting 
process of a DD-250, a shipping and acceptance document. 
It is at a higher level than a unit test in the program. 
They are testing an integrated product at that point. 
(Tr. 4/662-64) CM/SEI's Foreman, the only witness offered by AEON at the hearing, 
(findings 94, 110, 122), testified that a common factor to "troubled programs" is a 
decision by the developer to "make up ... time" by failing to perform unit testing 
(tr. 7 /1202). 
Because if you skip unit testing, what you end up doing 
is that you are going to be doing integration testing at the next 
level. Well, if I don't know that the small pieces work, how 
am I going to have any traceability or tracking to where the 
errors may be if I am testing at a larger component level ... ? 
So now I have jammed together a bunch of modules 
and units, and I am testing against those, and I am getting 
errors and crazy things going on, et cetera, et cetera, that may 
actually affect other parts of the system. 
Where ... do I figure out where in that composite do I 
have the problem[?] 
(Tr. 7/1248-49) 
60 

58. On 23 June 2005, Krajnak included the following in his weekly status report 
internal to AEON: 
Issues/Problems/Concerns (include suggested 
resolution -- if 
known) 
* Dysfunctional management team. Employees have lost 
faith that the project will be completed on time and are 
starting to look for other employment. The resolution is 
install a new onsite manager that the client and employees 
trust. ... 
* Lack of communication among team members. Have 
weekly staff meetings were [sic] issues are discussed. 
* The PSR should stop presenting falsehoods and show 
the project as at risk (yellow). We will not be able to deliver 
working 
programs and documentation by 12/31/05. 
Resolution is to delay UA T for 3 months. 
(Supp. R4, tab 57; tr. 4/850-52, 874-76) 
59. On 15 July 2005 Krajnak sent an email to the AEON test team supervisor: 
I am seeing many defects for the online QA testing that have 
to do with programs not properly transferring to each other. 
Many of these should be caught and fixed before being sent 
up for QA testing. This is caused by the lack of integration 
testing between the programs created by different 
programmers. Each programmer tests only his program and 
does not test the flow to all the other programs in the group. 
This is a waste of the QA testers time and prevents any real 
logic testing (since the program abends [see n.29] before 
doing anything productive). It is simple to solve if we would 
be allowed to do integration testing. 
I suggest that someone (maybe the team leader) do integration 
testing between all the programs in a group before sending the 
programs to QA for testing. How do we get Shirin to allow 
this? 
(Supp. R4, tab 59) At the hearing he testified that: 
61 

The purpose of this document was basically to report 
what I saw in terms of the on-line programs for failing and 
going over to the QA side. As I indicated here, I thought that 
many of these things should have been caught prior to sending 
these programs over to be tested. 
And what we are basically seeing is what I am calling 
or what I stated as chum, is that we would prematurely send 
programs over to the testing team. They would send them 
through their automated scripts. They would fail. 
They would then come back to the programming staff 
with defects, and then the programming team would then have 
to fix those defects one at a time, and send them back over the 
fence to the testing team. 
What I thought should have happened, and what my 
experience shows me, is that if you spend more time up front 
with making sure that you have quality code, and that you are 
doing a robust unit testing prior to giving it over to, to do the 
more functional tests, that these errors would not be 
occurring, and that you would get results better. 
(Tr. 4/856-57; see also findings 46, 47) 
60. On 24 February 2006 AEON reported being 100% complete with Level I 
testing of five modules. On 3 March 2006, in accordance with FAR 52.246-4, Inspection 
of Services, the government exercised its right to inspect and test the services required by 
the contract to be performed by AEON. On 10 March 2006 CO Gladski notified AEON 
that the government's inspection had "involved a simple testing of the commonly used 
functions in [one] module" and raised concerns about the adequacy of AEON's testing. 
CO Gladski listed 8 specific examples of "problems" identified during the government's 
inspection and: 
As a result of our small sample, we are very concerned as to 
the adequacy of Aeon's Testing and Quality Assurance 
programs to detect these anomalies. Further, deepening the 
concern was the [government] testers were unable to perform 
even the most rudimentary business functions of entering an 
invoice, entering a disbursement, or editing a contract 
payment notice. 
62 

(R4, tab 20) 
Based on the unsatisfactory Government findings during this 
review, Aeon is requested to provide access to, and submit for 
Government review all modules as they are identified as being 
100% complete with Level 1 or Level 2 testing. The authority 
for this request is found in section nine of the Statement Of 
Work and FAR 52-246.4(c) [sic]. In addition, due to the 
concerns raised by this review as to the adequacy of Aeon's 
Testing and Quality assurance programs and the status of 
testing being reported, Aeon is hereby notified that 
acceptance of the services associated with achieving the 
events tied to milestone payment [6B] may be delayed while 
the Government performs inspection of the converted 
software modules as outlined by FAR 52-246.4 [sic] and 
section four of the SOW. Toward this end, the Government is 
willing to consider any changes you have made or 
alternatively, any changes you plan to make to your Testing 
and Quality Assurance programs to prevent reoccurrence of 
problems with the adequacy of testing in the future, so as to 
shorten the time it would take the Government to complete 
this task. 
61. After reporting to the government that it was 100% complete with functional 
testing, AEON advised in a 17 March 2006 email that: 
AEON has successfully performed thousands of tests on the 
rehosted MOCAS program code meaning that a lot of the 
system operates as expected... . We do not deny that the 
rehosted system is not yet fully tested and that there are many 
bugs to be discovered and fixed. This is business as usual in a 
systems project especially one of this nature when the 
underlying technologies are so vastly different from the 
legacy environment. 
(Supp. R4, tab 74) The government responded: 
Government testing at this stage is to independently verify 
what is being reported as having been completed by Aeon. 
We are not performing 100% structured testing of any items, 
we are performing ad-hoc testing of the logical units of work 
63 

Aeon reports as being 100% complete with functional testing. 
The Government does not want this testing to be a 'life-long 
proposition' and if Aeon knows that the functionality 
associated with these modules is not fully tested, than [sic] 
they should not be reported as being 100% complete. 
(Supp. R4, tab 74) In particular, the government inspection testing: 
[W]as just ad hoc testing and 
broad based just to get a feel. 
[The tester, John,l22l] wasn't testing any one particular 
function, one particular process. He was just trying to get a 
feel that ... these systems are out there, and the input screens 
are out there. The stuff is starting to work . 
. . . He would just say that I am having problems, or often times 
he would say I am having lots of problems, and I would say 
just make sure that you are reporting them to AEON so they 
can fix them. 
(Tr. 4/671-75, see also tr. 5/934-35, 941-47) 
62. In the spring of2006 DFAS requested a DCAA audit to determine AEON's 
financial well-being after it was reported that AEON had missed a payroll and had not 
paid its subcontractors (see finding 51 ). The resulting audit found no evidence that 
AEON was financially unable to complete the MOCAS Rehost project. (Supp. R4, 
tab 106 at 21) 
63. Mod. No. P00007 dated 5 May 2006 further subdivided Payment Event 6B, 
determined to be "highly complex and lengthy in terms of time to complete," into 6B-l, 
6B-2 and 6B-3 to permit faster payments to AEON during the performance of tasks 
associated with Payment Event 6B (R4, tab 3 at 861-76). In the process of approving the 
subdivision of Payment Event 6B the PMO commented that the subdivision was 
requested due to "possible government caused delays" resulting in delayed payments and 
financial difficulty for AEON (id. at 869). The modification made reference to ongoing 
negotiations of an REA (finding 64) and included "[b ]y signing this modification, the 
Contractor does not waive any claims that arose after 08 January 2006" (id. at 861 ). 
22 John Sharer was a DFAS functional systems analyst with 29 years experience with the 
MOCAS system (tr. 5/937-39). 
64 

64. On 14 April 2006 AEON submitted a Request for Equitable Adjustment and 
Schedule Extension Proposal (REA). Thereafter AEON submitted several revisions to 
the REA which 
were audited by DCAA (R4, tab 22; supp. R4, tab 106 at 13-14). On 
23 May 2006 AEON submitted a final revised REA seeking compensation in time 
(9 weeks) and dollars ($978,3 86) for various alleged government-caused delays to the 
critical path of its performance under the contract in the period from 9 January 2006 
through 17 March 2006 and to provide additional time in the QA/Test Phase schedule.23 
The cost reimbursement sought was for: 
• Added calendar work time to make up for the AEON 
team's lost productivity associated with work on the 
project's critical path tasks. The lost productivity is 
directly attributable to the ( 1) instability of the 
mainframe development and testing environments 
(including loss of environment due to erroneous lay 
down of data), (2) downtime related to the upgrading 
of PC workstations under the Desktop Management 
Initiative (DMI), and (3) unavailability of the 
TestDirector software, the AEON testing tool, during 
the above timeframe, and 
• Additional 
time needed to address the increasing level 
of program code complexity. 
(R4, tab 21at1063, see also R4, tab 21at1082) The requested costs of$978,386 were 
broken down as $620,093 for "Environmental Instability," $291,808 for "Increased Code 
Complexity" and $66,485 for "Other Costs" (R4, tab 21 at 1064). The requested 
nine-week schedule extension of the QA/Test Phase was: 
• To accomplish the work that was delayed due to the 
impact of the mainframe availability/usability, DMI 
upgrade problems, unavailability of test management 
system (TestDirector), and changes in the support 
levels due to revised security policies and procedures, 
and 
23 The DCAA audit notes that there was another subsequent REA submission dated 
12 June 2006 that sought the increased amount of $992,378 (R4, tab 22 at 1103), 
but it is not in the record before us. 
65 

• For expanded QA/Test and defect management 
activities due to higher than 
planned complexity of the 
MOCAS System program code. 
• To complete the technical documentation work that is 
dependent on the completion of the QA/Test Phase 
activities. 
(R4, tab 21at1063, see also R4, tab 21at1067-79, 1083-97) The parties reached a 
negotiated agreement on 8 August 2006 (R4, tab 24; tr. 1/93) which was memorialized in 
Mod. No. P00012 (finding 67). 
65. Mod. No. P00009, dated 12 June 2006, further amended the subdivision of 
Payment Event 6B from three subdivisions to four subdivisions (6B-l through 6B-4) (R4, 
tab 3 at 880-92). The record shows that AEON was paid for Payment Event 6A on 
9 January 2006, Payment Event 6Bl on 28 April 2006, Payment Event 6B2 on 15 June 
2006 and Payment Event 6B3 on 8 September 2006 (app. supp. R4, tab 172 at 8). 
66. Mod. No. POOO 10, dated 20 June 2006, extended the contract completion date 
to allow time for an audit and negotiation of AEON's REA (finding 64) (R4, tab 3 at 
892-96, tab 78). On 5 July 2006 Mod. No. POOOl l (R4, tab 3 at 897-01) obligated funds 
in the amount of $300,000.00: 
[A]s partial equitable adjustment under FAR 52.242-17 for 
what the Government considers to be a 
3 .5-week Government 
delay of work involving certain "Environmental Instabilities" 
as asserted in [AEON's REA], as revised May 23, 2006. This 
[amount] is granted solely with respect to elements of 
"Environmental Instabilities" delay assertions in the revised 
REA for the period of January 9 through March 17, 2006. 
This partial equitable adjustment represents a good faith 
action on the part of [DF AS] that provides cash flow to 
[AEON] to meet immediate expenses. The Government does 
not concede that entitlement to adjustment exists for the 
"Complexity Factor" elements of the REA, or for all of the 
"Environmental Instabilities" sub-elements set forth in the 
REA. Final equitable adjustment cannot be made 
until the 
Principal [CO] receives the requested DCAA audit report of 
the REA proposal. Fact finding and negotiation of the REA 
proposal between the Government and [AEON] will occur 
after receipt of the DCAA audit report. 
66 

(R4, tab 3 at 899; see also supp. R4, tab 106 at 13-14, 18) 
67. Mod. No. P00012, dated 18 August 2006, reflected the parties' negotiated 
settlement of AEON's 14 April 2006 REA (finding 64). Specifically: 
4. An $825,000.00 negotiated settlement of the REA was 
reached on August 08, 2006. That settlement, 
implemented herein, adjusts compensation and schedule 
for Government-caused delays and Environmental 
Instabilities and disruptions from January 9, 2006 to 
March 17, 2006. That settlement includes additional 
monetary compensation that the Government will 
provide in consideration of AEON's release of the 
Government from further equitable adjustments and 
claims under the contract based on the "complexity" of 
the as-is MOCAS code, with the exception that AEON 
has not released the Government from rights to equitable 
adjustment or additional compensation involving 
changes and/or additions to the as-is MOCAS code 
which occur or may have occurred after March 17, 2006, 
that increase code complexity. 
5. In considering the REA, the Government found that 
AEON's REA and subsequent REA negotiations did not 
establish entitlement for the MOCAS code complexity 
contentions set forth in the REA. However, the 
Government offered to provide, and AEON accepted, 
additional monetary compensation in exchange for the 
limited release described above. 
6. This negotiated settlement includes other costs including 
travel, software, and Facility cost of capital from 
January 9, 2006 to March 17, 2006. 
7. This negotiated settlement includes adjustment of the 
delivery of the following CLIN dates to September 10, 
2006: 
a. CLIN 0001 AA 
b. CLIN 0004 
8. In good faith, DF AS, agreed to make a partial payment 
on this REA to help alleviate AEON's financial issues. 
67 

DFAS obligated $300,000.00 in POOOl 1 [finding 66] 
toward a partial equitable adjustment of this REA. Thus, 
DFAS has already paid $300,000 of the $825,000 
leaving a balance of $525,000.00 to be paid. This 
contract action obligates the remaining $525,000.00 for a 
total settlement obligation of $825,000.00. 
(R4, tab 3 at 903-05) The breakdown of the negotiated amount was recorded as: 
Cate2orv Proposed Cost Ne2otiated Cost 
Environmental Instabilities $620,093 
Code Complexity $291,808 
Other Direct Costs 
Travel $16,595 
Software Licenses $31,729 
Cost of Money $31,390 
Total Cost $99 l ,6 l 5L24l 
(R4, tab 24 at 1151) The modification included the following release language: 
CONTRACTOR"S [sic] STATEMENT OF RELEASE: 
In consideration for the modifications agreed to herein as 
complete equitable adjustment for AEON's REA, submitted 
on April 14, 2006, revised on May 23, 2006 and updated on 
June 12, 2006, and in consideration for additional 
compensation for that qualified code complexity release from 
AEON's provided for under paragraph 4 
above, AEON 
hereby releases the Government from any and all liability 
under this contract for further equitable adjustment: 
a. Attributable to such facts and circumstances giving rise 
to the REA; and 
b. Any and all claims or equitable adjustments under the 
contract based on the "complexity" of the as-is 
MOCAS code, with the exception that AEON has not 
released the Government from rights to equitable 
adjustment or additional compensation for any changes 
$604,590 
$187,589 
$17,358 
$10,768 
$4,695 
$825,000 
24 The document does not explain the $763 difference between this proposed amount and 
the proposed amount of $992,3 78 stated earlier in the same document (see R4, 
tab 24 at 43). 
68 

and/or additions to the as-is MOCAS code that 
increase its complexity which occur or may have 
occurred 
after March 17, 2006. 
(R4, tab 3 at 904; see also R4, tab 24; tr. 2/259-64) 
68. In mid-August 2006, AEON started Interface Testing: 
Interface Testing validates that data is passed correctly 
between two systems and can be processed accurately. As a 
term of the contract, it was acknowledged by the Government 
that the contractor would require Government assistance in 
performing these tests. Although an AEon responsibility, the 
PMO coordinated testing with AEon and the support 
organizations for other DFAS systems. Because of the 
Government involvement, this testing stage provided the 
Government the first chance to see how AEon was 
progressing in obtaining I 00% functionality of the As-Is 
system. 
Interface Testing started in mid-August of 2006, at that time, 
less than a month before GT &E was scheduled to begin. 
Scheduled to last only four days, AEon was not able to 
run/complete a batch cycle for ten days, compared to an eight 
hour window used for production [in the as-is system]. A 
batch cycle was critical for creating the data files to be passed 
to the interfacing systems. AEon's delay was due to 
numerous program problems and JCL errors, which should 
not have occurred if the system was fully functioning. The 
length of time required and the number of problems 
encountered was an indication to the Government that AEon 
had not previously run a complete cycle, a critical test for 
Integration Testing. This indication raised significant concern 
by the Government, due to the point of time within the 
project. With less than a month before the scheduled GT &E, 
the Government anticipated that AEon would have had a 
more mature system and, at a minimum, would have been able 
to run a [batch] cycle. However, showing good faith, the 
Government permitted AEon to complete their testing and 
reserved judgment until after GT &E commenced. 
69 

Unfortunately, it was not until GT &E commenced that it was 
realized that AEon had bypassed several jobs that had 
abnormally terminated, rather than fixing the problems and 
successfully run the jobs. Instead, the Government entered 
into GT &E assuming cycles were capable of running to 
completion without manual intervention. Once GT &E began 
and the TS0[ 25l took responsibility for running the cycles, the 
extent of the problems with the batch cycle was discovered. 
(Supp. R4, tab 106 at 19-20) 
69. Mod. No. P00013 dated 11 September 2006 extended the delivery date for 
subCLIN 000 lAA to 25 September 2006 in exchange for consideration from AEON (R4, 
tab 3 at 908-11; supp. R4, tab 106 at 19). 
70. Mod. No. P00014 further subdivided the CLIN 0001 tasks to be completed by 
AEON to successfully qualify for each payment event after 20 October 2006 (R4, tab 3 at 
912-25; tr. 3/394-96). The modification revised the "Event Based Payment Schedule for 
Payment Events 6B4 and 7 A" which were described as "highly complex and lengthy in 
terms of time to complete" (id. at 914-15). Event 6B4 and Event 7A were removed and 
replaced with Events 7A-l, 7A-2 and 7A-3 (R4, tab 3 at 921-23). The change "aligns 
progress of contract deliverable performance and related payment event dates with actual 
work progress thereby assuring the Government of Contractor's continued viability" 
(R4, tab 3 at 915). 
71. On 22 September 2006, just days before the amended contractual delivery date 
of25 September 2006 for subCLIN OOOlAA (finding 69), AEON submitted its "Final" 
Project Management Plan (PMP) (finding 11; R4, tab 25) The PMP stated: 
1.4 System Functionality and Scope 
The rehosted MOCAS System will have all of the 
functionality, produce the same output and will look, feel and 
respond to the users exactly as it does today. Therefore the 
users will not recognize that the system has been touched. In 
addition, all interfaces will provide the same data in the same 
format. No obsolete programs or dead code will be removed 
without the express written permission of the [COR] .... 
The scope of the effort also includes the development of all 
technical, project and user documentation as defined in 
25 Technical Services Office (finding 79). 
70 

Section C, Descriptions and Specifications, item 14, 
Documentation. The repair services of the rehosted MOCAS 
System are an optional scope item beginning with installation 
of the rehosted MOCAS System on the production platform 
and continuing for one year thereafter. DFAS intends to 
make a decision on this optional scope item at a later date. 
(R4, tab 25 at 1159) 
72. In a 22 September 2006 letter CO Gladski 
expressed concern about AEON's 
performance of the contract and requested "reasonable assurances" that AEON would be 
able to complete the contract. In particular, CO Gladski expressed concern about "the 
quality and completeness of your QA test and automated test scripts." (R4, tab 26; 
tr. 1/93-94) AEON responded in a letter dated 26 September 2006: 
We are at the end of the project. The QA/test is 99% 
complete. With very few exceptions - all other tasks are 
complete. Therefore, we were very confused and 
disappointed by your letter. We have consistently taken every 
step to assure DF AS that AEON is fully capable of and 
committed to completing the MOCAS Rehost project. 
While this project continues to be more complex than 
originally expected, we feel confident that we will complete 
the project with the highest quality possible for a project with 
its unique attributes. 
1. Schedule Issue - Start of GT &E schedule changed 
from 9/25/06 to 10/2/06 
[AEON explained that the requested one-week extension 
to the delivery date for subCLIN 0001 AA was due to 
DFAS/DCMA's recent provision of long-requested 
information on 8/31/06, 916106, 9112106] 
2. Technical Performance Issues 
We are not aware of any technical performance issues. To 
71 

the best of our knowledge the technical performance of the 
project has been successfully presented and accepted. The 
performance under the Rehost is substantially faster than 
under the current technical environment. If there are other 
specific concerns, please let us know and we will respond 
accordingly. 
3. Quality and completeness of QA tests and automated 
scripts as evidenced by inspection results 
AEON is totally committed to producing the highest 
quality MOCAS Rehost product. As you know, MOCAS 
was a very difficult and complex system to convert due to 
its age (evolved over more than 40 years), lack of 
standards and consistency, use of multiple coding 
techniques for coding the same functions in the same 
program and lack of documentation to provide 
explanations. For such a system: 
- It is highly unrealistic to expect that a subject matter 
expert or a knowledgeable system user perform tests 
on a major system prior to or during the user testing 
(GT &E) and finds no defects. The purpose of the user 
acceptance testing is to test the system from a user 
perspective and correct any defects prior to moving the 
system into production. The amount of defects 
discovered during the user acceptance testing is 
directly proportional to the level of customer 
involvement throughout the project. The systems with 
more customer participation will yield less defects 
during the user acceptance testing than those with little 
or no customer participation. 
The consequence of DF AS and DCMA not actively 
participating in the project for a system that has no 
documentation and has gone through 40 years of 
changes of content as well as ownership is the 
possibility of discovering more defects during the 
GT &E. We explicitly identified this fact as a risk for 
this project in our proposal. Risk# 10 in our Risk 
72 

Management section highlighted "The stated lack of 
government involvement throughout the project life 
cycle" as a "High" probability risk with "High" 
impacts on "Cost, Schedule and Performance". 
While we implemented the proposed mitigation plan of 
management and peer review and hired several team 
members with MOCAS experience, these actions, as 
stated in the risk management plan, did not fully 
eliminate the risk and its impact. Further, we have 
worked diligently and have asked to receive and 
execute user test scripts in order to minimize this 
impact. 
A subject matter expert 
can test a complex system, 
even an operational system, and can identify defects. 
This is evidenced by the fact that we were able to 
identify 19 defects in the current MOCAS system 
which has been in production for over 40 years. 
Therefore, the quality of AEON's performance can not 
be based solely on the lack of defects during 
Government inspection. 
The quality indicator should be based on the severity of 
the defect as well as how quickly the defect can be 
corrected during the inspection and GT &E. The 
defects that were discovered by the TSO team during 
the inspection process were not numerous and were 
fixed and resolved immediately. The larger number of 
defects discovered by the TSO was associated with 
early testing support that we had requested from TSO 
and not during 
inspection testing. 
In conclusion, AEON is fully capable and committed to 
complete the MOCAS Rehost project with high quality. 
When we started the project our conversion team was not 
familiar and experienced in the MOCAS code. 
Through diligence and hard work the team is now very 
knowledgeable and experienced and can resolve any problem 
quickly. We also believe that our team has become even 
more 
73 

(R4, tab 27) 
knowledgeable in the Rehost system than most TSO 
members. 
73. On 27 September 2006 and 2-13 October 2006, the government performed 
inspection (see finding 16) in the form of some testing of various areas of the MOCAS 
rehosted system (R4, tab 38 at 1270-71; tr. 3/432-33, 573). 
74. As of 5 October 2006 AEON and the government had agreed to start GT&E 
on 13 October 2006. However, by email dated 11 October 2006, COR Hecker proposed 
to delay the start of GT &E until 30 October 2006 due to difficulty in assembling the 
government test team and also proposed for AEON's consideration further changes in the 
payment milestones. By reply email the same day, AEON responded: 
The proposed GT &E schedule is unacceptable to AEON for 
the following reasons: 
1. The Government has been conducting inspection testing 
which is very similar to GT &E rather than a high level 
inspection. We believe there has been sufficient testing and 
retesting done to assess the start of GT &E. Three DCMA 
testers and two resources from DF AS have been involved in 
inspection testing 
and validation. 
2. Per our conversation of Thursday, 10/5/06, we agreed on a 
plan to start GT&E preparation on Wednesday, 10/11/06 with 
a GT &E start date of 10/13/06. The following steps were 
agreed upon: 
o AEON would fix all defects by 10/9/06 
o Client would input their data on Tuesday, 
10/10/06 
o AEON would run a cycle with client input on 
Tuesday night, 10/10106 
o Client would verify the results, 10/ 11 /06 
o If there were no show stoppers found, GT &E 
prep would start on Wednesday, 10/11/06 
74 

3. We were told in the TIPT[261 meeting today that the client 
did not find any show stoppers that would preclude us from 
going to GT &E and in fact a key client was very excited 
about the results of the testing. During today's IPR 
John Sharer also stated that there were no show stoppers for 
the start of GT &E. 
4. All identified defects with the exception of a few lower 
priority defects have been fixed. We have demonstrated that 
we can very quickly resolve any problems encountered. 
5. It is commonly understood that defects will be identified 
during GT &E due [to] the depth of operational knowledge of 
the client testers. Therefore extending inspection to continue 
the testing process will not eliminate GT &E test defects. 
6. We believe that AEON has met its obligation and has 
supported the inspection process required prior to the start of 
GT&E (start date of 10/13/06). Since this is a fixed price 
contract 
any further testing prior to GT &Eis an unnecessary 
hardship on AEON that we cannot accept. If the client wishes 
to pay for the extension of the start of GT &E to October 30th 
we would be more than happy to discuss it. 
Carl [Hecker]: We are totally committed to this project as 
evidenced by all personal and business risks that we have 
gladly accepted in order to have a successful project. 
However, any delays in the start of GT &E and major changes 
to our payment schedule are unacceptable to AEON because 
they would have severe impacts to the company. 
(App. supp. R4, tab 151) 
75. On 12 October 2006 AEON submitted a second REA ("REA2") in which it 
sought compensation in the amount of $629,550 for government-caused delays to its 
performance of contract work from 18 March 2006 through 2 October 2006 (app. supp. 
R4, tab 152 at 1, 4-5). After multiple revisions, the 15 February 2007 version ofREA2 
26 Test Integrated Product Team (gov't br. at 36). 
75 

sought $548,866 (app. supp. R4, tab 189 at 6-7). The record shows that AEON was paid 
for Payment Event 7A1 on 20 October 2006 ( app. supp. R4, tab 172 at 8). 
76. On 20 October 2006 an internal AEON email announced: "Team: All the 
reports are in balance. All the client defects have been fixed. We are going forward with 
GT&E!!" (App. supp. R4, tab 155 at 2) 
b. GT&E 
77. On 23 October 2006 AEON delivered the Rehosted MOCAS database for 
GT &E (R4, tabs 30, 34, 38), having 
certified in its 20 October 2006 MOCAS Rehost 
System Quality Report that to the best of its knowledge the MOCAS system was ready to 
perform the functions of the As-Is MOCAS (supp. R4, tab 106 at 19, 22, 27). The 
government approved AEON's report of delivery for GT &E and on 1 December 2006 
released to AEON performance-based payments for Payment Event 7 A2 (app. supp. R4, 
tab 172 at 8). 
78. GT&E commenced on 24 October 2006. It was the government's expectation 
that the product delivered for testing should be "99.9 percent capable of performing the 
function of the as-is MOCAS, and look like the as-is MOCAS, and do everything that the 
as-is MOCAS was doing" with only a small amount of test failures that would require 
"minor tweaks" (tr. 1/87, 98, 102-03, 109). 
I would say that we expected the system to be delivered with 
minor cosmetic changes that were needed to be made, 
whether the screens were not operating properly, or the 
wording was incorrect. 
We did not look for what I would call critical errors or 
we would not 
expect critical errors or defects when they 
delivered the system to us .... 
(Tr. 3/418; see also tr. 3/607, 4/804) 
79. Specifically, the DFAS Government Test and Evaluation Plan identified the 
following details of the DF AS' GT &E effort: 
SECTION 1 - GENERAL 
I. I Test Objective 
76 

The Defense Finance and Accounting Service (DF AS) 
Commercial Pay Business Line (CPBL), Chief Information 
Office (CIO), Central Design Agency-Technical Services 
Office (TSO), Defense Contract Management Agency 
(DCMA) Central Design Agency/Technical Information 
Center (DTIC), Defense Information Systems Agency (DISA) 
OGDEN and the Contractor (AEON LLC) will jointly 
coordinate and support a Government Test and Evaluation 
(GT&E) of the Mechanization of Contract Administration 
Services (MOCAS) Re-host (DB2 environment) System. 
Parallel testing will consist of testing all online and batch 
processes as well as the interfaces functionality developed 
within the Mechanization of Contract Administration Systems 
(MOCAS) Re-host (DB2) system environment (MUJ) and 
MOCAS (SUPRA) production system environment (MUB). 
Testing will be conducted 
during the period of 11 Sept06 
through 30Nov06. 
1.2 Purpose of the Test 
This document identifies and defines the requirements that 
will be tested in parallel systems during the GT &E. And will 
determine ifthe MOCAS Rehost (DB2) System (MUJ) 
provides the same level of interface capabilities, functionality 
and processes that exist in the current production MOCAS 
(SUPRA) system (MUB). To include validating AEON 
provided user's manual. Numerous online, batch and 
interface transactions will be processed through 
each Logical 
Partitioning (LP AR). And through comparative analysis 
performed by the test cadre, a validation of each screen and 
data field and data field requirement will be performed to 
ensure the online, batch and interface transactions are 
mirrored, with results documented to reflect demonstrated 
functionality or lack thereof. Specifically, this Government 
Test & Evaluation Plan: 
• Confirm MOCAS Rehost (MUJ) system consists of 
the same screen layouts, interface(s), online input, 
online input validation and batch functionality as the 
current MOCAS (MUB) production environment. 
• Confirm Entitlement Automation System (EAS) 
interface functionality 
77 

• Confirm Contract Reconciliation System/Standard 
Contract Reconciliation Tool (CRS) interface 
functionality 
• Confirm Electronic Document Management (EDM) 
system interface functionality 
• Confirm Payment Prevalidation Module (PPVM) 
system interface functionality 
• Confirm [SDW] system interface functionality 
• Confirm Wide Area Workflow - Receipt & 
Acceptance (WA WF-RA) system interface 
functionality 
1.2.1 Assumptions 
The MOCAS Rehost DB2 (MUJ) will provide the same 
screen layouts, interface capabilities, online input, batch 
functionality and processes that exist in the current production 
MOCAS (SUPRA) system. And will perform validations 
consistent with the current MOCAS production environment 
which supports online and batch processes. 
The outbound file transmissions to include all 
system-generated reports will provide the same format and 
data from the MOCAS Rehost DB2 (MUJ) system as in the 
current production MOCAS SUPRA (MUB) system. All 
DF AS reports will be viewed utilizing the Online Report 
Viewer (OLRV). 
4.3 Test Evaluation 
a. All test conditions must process 100°/o as 
predicted for the GT &E to be accepted and 
certified. Any test conditions not processing as 
predicted must be identified and successful 
resolution agreed to jointly by the contractor and 
test cadre (if applicable). Test conditions results 
for which agreement is in dispute will be 
forwarded to the technical representatives for 
analysis and resolution. Each MOCAS Rehost 
78 

region will be tested independently and for its 
interdependencies. 
4.3.1 Test Conclusion 
a. The test will conclude when 100°/o of all valid 
test conditions are adequately tested and found 
acceptable and outstanding problems are 
verified as fixed and retested. This will result in 
a recommendation for either a 
certification/non-certification. 
b. Parallel testing of a single MOCAS region vs. all 
three (3) will result in a recommendation for 
certification that must 
stipulate the following 
caveat: Certification of the MOCAS Rehost DB2 
environment resident on the (MUJ) LP AR was 
accomplished utilizing only one parallel MOCAS 
region for comparison, thus ensures operability of 
each region and not their interoperability. 
c. Based on successful completion of test 
conditions/scenarios and outstanding problems, 
MOCAS Rehost, [PMO] will coordinate with the 
Designated Approving Authority (DAA), 
Information Assurance Officer (IAO) and DF AS 
Chief Information Officer (CIO) to discuss 
whether or 
not any outstanding problem(s) 
discovered during testing will have an adverse 
affect/impact ('showstopper') on DFAS and/or 
DCMA business processes. 
(Supp. R4, tab 61 at A009710, A009721) (Emphasis added) The DCMA Government 
Test and Evaluation Plan was essentially identical and was developed by DCMA test lead 
Turner (supp. R4, tab 67; tr. 4/795-00, 802-04). With 
respect to Problem 
Identification/Resolution, the DF AS and DCMA Test and Evaluation Plans specified the 
following categories of problems: 
79 

Category DFAS (4.2.2) DCMA (4.2.3.1) 
A Critical/Fix Immediately Must be corrected before test can 
proceed. 
B Major/Fix before Test Completion Must be corrected before end oftest. 
c Fix before Deployment Must be corrected before deployment. 
D New Requirement(s)/Requires an New Requirement( s )/Requires an 
Automated Work Request (A WR) Automated Work Request (A WR) 
/Contract Assessment Form (CAF) Because it significantly changes 
-Because it significantly changes the management requirement. 
the management requirement 
E Real World Production problems Real World Production problems 
F User Defined User Defined 
G No Impact to MOCAS/Rehost [not used] 
H Reserved [not used] 
(Supp. R4, tab 61 at A009720, tab 67 at A009693; tr. 3/536-37, 553-56, 5/954, 1025) 
With respect to Category E, Real World Production problems: 
[The government] recognized that there are some problems in 
the [As-Is] MOCAS system today [and] the system is still able 
to function, but they are there, and they are cosmetic. 
So if they are there in the system now, they would still 
be in the system when we converted it. 
(Tr. 3/450, see also tr. 5/954-55; finding 72 [19 defects found in As-Is MOCAS]) 
80. GT&E was performed by 33 government testers, all with decades of 
experience with the existing As-Is MOCAS (tr. 3/582-84, 604-05, 4/752-54, 828-29, 
5/937, 956-63, 982-84, 5/1017-102, 1021, 1038; supp. R4, tab 61 at A009722 (lists 
44 names for DFAS), tab 67 at A009695-96 (lists 15 names for DCMA)). 
80 

We had people from each of the different areas. We 
had DB2 people there and they were represented, and we had 
people there that put in invoices every day, and they were 
represented, and they had people from contract input there, 
and they were represented, and entitlement, Tier 2. There 
were individuals from each area that were involved. 
From each area, there was probably two to three 
people, and you have to realize that the data was phased, and 
so each day you would bring in different people. They 
wouldn't all be there at one time. 
(Tr. 3/435-36) 
81. In the first several weeks of GT &E the government testers encountered 
numerous failures of critical, basic and necessary functions of the Rehosted MOCAS to 
perform like the As-Is MOCAS (tr. 1/87, 3/584-08, 5/899-00; supp. R4, tabs 95, 123). 
DF AS test lead Thompson testified that: 
In October of 2006 we started, and it was a very trying time, I 
had our testers in the lab and we were ready to go, but the 
product itself for a simple task as far as the users logging in 
and going to a library which holds how you process data, they 
would get [database] errors. [271 They would try to do simple 
tasks such as input an invoice and update the database and 
they would get errors, and it got to a point where it got quite 
frustrating because simple tasks that have to be done daily 
were unable to be completed. So I believe we were in it for 
maybe two to three weeks before we stopped the initial 
GT&E. 
Just to name a few very critical [functions], unable to 
input invoices and update MOCAS, we would receive 
[database] errors. Whenever a shipment would come in a 
27 Ms. Thompson used the phrase "Oracle errors" in her direct testimony, which she 
changed on cross-examination to "database errors" as the more correct terminology 
(tr. 5/1058-59). 
81 

DD-250 would have to be input into MOCAS, and there were 
major problems with, it's called a basic PF3 summary edit [in] 
the system, and for whatever reason it would say that it 
already existed and it wouldn't allow the 
person to add that 
particular document or any document, and this posed a lot of 
problems. And also with our electronic feeds the majority of 
our invoices come in electronically, and whenever these 
would come in they would not update MOCAS correctly, so 
the general ledger would show that our obligation receipts 
were never correct, and that is critical in our world. 
(Tr. 5/1023-24) Thompson further testified that, in her 10 years of testing software, she 
had never encountered a product so not ready for testing (tr. 511031-32). 
Kathleen Schreiber, a DCMA tester with 29Yi years experience with MOCAS and whose 
regular job involved testing software for DCMA, testified: 
Q ... [D]id the rehosted MOCAS system have the 
same 100 percent functionality as the as-is MOCAS system? 
A ... No. We couldn't get the contracts in, and we 
couldn't move them through their lifecycle, and we couldn't 
process transactions against them. 
We couldn't close them and we couldn't reopen them, 
and we couldn't get those transactions to our [S]hared [D]ata 
[W]arehouse successfully, repeatedly, consistently. 
Q In your opinion was the rehosted MOCAS 
system ready for testing, Government test and evaluation? 
A In my opinion, no. 
Q Why? 
A Well, I do test software all the time. . . . When 
you go to test an application, you don't expect it to be error 
free. You expect to find things. That's your job. 
But you don't expect to find anything major where you 
can't do your normal basic functionality. You don't expect to 
find just about everywhere you tum that something doesn't 
work. 
82 

Q ... What type of problems did you basically 
think you would encounter when you started testing? 
A Well, like some cosmetic stuff. Maybe some 
weird error messages on the screen, but I certainly expected 
that it would have been tested and proven that you could get 
contracts in, and MODS in, and shipments in, and things like 
that, and cycles run. 
Q How important was it to run your monthly and 
nightly batch cycles? 
A Oh, it was extremely important because the only 
way we get in electronic documents like contract MODS, 
shipments, and invoices, is through a batch cycle .... 
(Tr. 3/606-07) The DCMA testers summarized the initial GT &E period as: 
[U]nsuccessful attempts to complete a monthly cycle along 
with continued system problems such as inability to Summary 
Edit contract/modification input, numerous SQL system 
errors, erroneous rejection of the EDI 850's and 860's 
transactions, problems with automatic CAR section 
movement, DD Form 250 processing and SDW not being 
100% completed .... 
(Supp. R4, tab 113) 
[It] happened quite frequently, that we would get a problem 
back and fixed by AEON, and then we would retest it. 
And then you would go on to do your next piece on 
that particular document that you were working on, and ... , 
hey, this is broken. This was just working days ago. So it 
was kind of like unstable, and so you could not rely on it 
consistently to act the same. 
(Tr. 3/597, accord tr. 5/1025-26) 
83 

The Government personnel went in and started testing. 
We started writing up about problems, and we provided 
screen prints, and we gave them to 
AEON. The first cycle 
took a lot [of] time for them to run. They had problems with 
the cycles and programs. 
We got through the second cycle, and then I think it 
was the third cycle where they came to us and said that they 
were stuck on a program, and they couldn't get it fixed until 
maybe 4 or 5 days before they could get it fixed. 
And at that time that's when the testers were getting 
upset, and that's when I met with [CO 
Gladski] at the time, 
and said that it looks like we are having problems, and a lot of 
defects in their stuff. 
That's when we met, and the final recommendation 
really, and we met as a group and came to the consensus that 
we thought it was best to stop GT &E because we couldn't 
seem to get past the work stoppage, and the program, and 
continuing to fix things. We couldn't run cycles and we 
couldn't do any [testing] work. 
Well, the program that they had, they had a whole lot 
of difficulty fixing it, and if I am not mistaken, it was the cash 
management program that they were stuck with. 
And they were having trouble getting it to work, to run 
in a cycle, and so until they repaired that program, we were 
unable to continue on because we were just at a work 
stoppage. 
So that was a critical program .... 
(Tr. 3/437-38) 
84 

It was our recommendation based on the number of 
defects received, and the difficulty that they had with 
repairing the critical programs that they had to go back and do 
more testing, more unit testing, or whatever they needed to do 
to deliver so that it didn't have as many defects as when they 
first delivered it. 
I think it was something like 200. I am not sure of the 
exact number, but there were quite a few defects . 
... [W]e were having trouble getting through the 
different cycles, and the input that was being entered, we 
couldn't get through most of the screens. 
There were several issues, and that was not a fully 
functional system. We needed a system that would work at 
that point, and it was broke at that point, and we could not 
completely enter contracts. 
(Tr. 3/439-40) 
82. On 2 November 2006 the government suspended GT&E (supp. R4, tab 106 at 
28). From the time of the suspension until 18 December 2006, DFAS testers went back to 
their regular jobs and DCMA testers maintained contact with AEON to clarify or explain 
200 trouble reports submitted prior to the suspension (supp. R4, tabs 113, 123; tr. 3/457, 
tr. 4/750, 759, 791-92, 813-16, 5/948-49, 1022-23, 1033). 
83. At a meeting on 8 November 2006 (R4, tab 28), it became apparent that the 
parties were in basic disagreement as to the level of functionality required to be present in 
the Rehosted MOCAS delivered for GT &E. It was AEON's position that the 90-day 
GT &E period was user acceptance testing in order "to resolve defects" (tr. 3/532). The 
government insisted that the contract required that the Rehosted MOCAS have 100% 
functionality when it was delivered for GT &E. 
Under CLIN-1 that represented the whole MOCAS program, 
the rehost. When everything worked correctly, then that 
CLIN-1 would have been delivered. We had no partial 
delivery of anything under CLIN-1, and our expectation[] was 
100 percent functionality when the system was operating. 
85 

(Tr. 1/113) 
It may have defects, but a defect should not impact the 
functionality of the system, and in this case the defects did 
impact the functionality of the system .... But we weren't 
talking about bugs. We were talking about major defects that 
did not allow the functionality of the system to be proven 
out. ... 
(Tr. 2/317-18) 
We expected AEON to deliver a fully functional 
system, and that is totally different than a defect free system. 
To deliver a system where we can input invoices, input 
shipments, and that means being able to get from - if it takes 
you five screens, and you have to go from A, B, C, D, and E 
to completely put in the shipment, we expect to get through 
all of that. 
We don't expect that minor defects with the system, 
whether like if wording on the screen wordings were 
incorrect, or anything, we still expected it to be fully 
functional. Those are the types of defects that we expected to 
see. 
(Tr. 3/441-42) 
84. On 15 November 2006 the government formally rejected the Rehosted 
MOCAS delivered by AEON and suspended GT&E: 
The memorandum, however, gave AEon the opportunity to 
deliver a product that performed basic system functionalities, 
to include Summary Edit, complete daily/monthly cycles, 
accurate Automatic Payment of Invoices (API) process, 
Invoice History updates, full Contingent Liability Record 
(CLR), accurate financial/invoice updates, etc. 
(Supp. R4, tab 106 at 28; tr. 1/104-06, 2/312-14, 3/539; see also R4, tabs 28, 30-31, 
38-40, 49) 
86 

85. In a 29 November 2006 letter, counsel for AEON notified DFAS 
CO Gomolak 28 that AEON considered the government's position to be contrary to 
contract requirements, arguing that the 
purpose of GT &E was identification and 
correction of defects which, he argued, anticipated that the Rehosted MOCAS was not 
expected to have 100% of the functionality of the As-Is MOCAS at the time it was 
delivered. Counsel further asserted that the government had no right to suspend GT &E 
and that the suspension of GT &E was an "attempt[] to revoke its prior acceptance of the 
MOCAS system." (R4, tab 29) 
86. On 28 December 2006, CO Gomolak took issue with AEON counsel's letter 
in two separate letters to 
AEON. In the first letter, with the referenced subject of 
"Government Test & Evaluation Issues," CO Gomolak stated: 
On November 15, 2006, AEon was notified that due to 
deficiencies in the "Rehosted" MOCAS database delivered to 
the Government, that the Government was rejecting 
CLIN 0001 and suspending [GT&E]. The letter further stated 
that until such time as the deficiencies were corrected and the 
Rehost application meets the 100% "as-is" functionality 
requirement specified in the contract [SOW], GT &E would 
remain in a suspended status. Furthermore, we acknowledge 
receipt of the November 29, 2006 letter written by [AEON's 
counsel] disputing the Government's right to reject 
CLIN 0001 and to suspend GT&E .... 
However, from reading [counsel's] letter it is evident 
the parties have a difference of opinion as to what AEON is 
required to deliver under CLIN 0001. It is AEon' s opinion 
that the Government should accept a program that can not 
perform the most basic transactions the old MOCAS system 
performs 
and to use the entire GT &E period detailing to 
AEON what is broken so that those items can be fixed. The 
Government does not share the same view of AEON's 
responsibilities under the Contract. 
The Government's position concerning the CLIN 0001 
delivery is this: the 
product AEon delivers is required to 
28 At the time of his testimony Normand G. Gomolak, Jr., had been a warranted CO with 
DF AS since August 2006 and had many years of prior corporate and military 
contracting experience since 1986 (tr. 2/306-09). He first worked on the MOCAS 
Rehost contract in spring 2006 as CO Gladski's contract specialist (tr. 2/310). 
87 

comply with the SOW. We have been inspecting the product 
under our right to inspect as set forth in the inspection clause 
and we have determined that the product as it currently exists 
does not comply with the SOW. Specifically, errors have 
been discovered that reveal your product does not comply 
with SOW§ 6 (system development), or§ 7 (functionality) 
etc. It is our position that your obligations undertaken with 
CLIN 0001 of this Contract are to deliver to DF AS a rehosted 
MOCAS and migration programs, both with full 
documentation that can perform exactly like the old MOCAS 
system. Until such time as your product meets the standards 
set forth in the contract, you will not have completed your 
obligations under CLIN 0001 and consequently, the 
Government will not move into the GT &E phase. 
On December 7, 2006, members ofDFAS, DCMA and 
the DF AS Rehost PMO met to discuss the Rehost application 
and to determine if, in their opinion, the product currently 
meets all SOW requirements. Their conclusion is that your 
product fails to meet specifications required in the Contract. 
At the request of the PMO, the team has identified the 
following violations of SOW § 7 functionality requirements 
and these requirements must be present before CLIN 0001 
will be accepted for recommencement of GT &E. 
[l] Closed Contract Data Base (CCDB)- There are problems 
with all aspects ofthe CCDB (e.g., viewing contracts in the 
CCDB, moving closed contracts into the CCDB, re-opening 
contracts from the CCDB, etc.). 
[2] REOPENs - Reopening contracts both on-line and from 
the CCDB is not functioning properly. 
[3] Program UNAA71 - Contract control data changes (e.g. 
PIIN I SPIIN changes, CAO org code changes) are not 
working properly. 
[4] Reports - There are many problems applicable to reports 
such as ( 1) data not appearing, reports not being produced 
when requested, data appearing the [sic] in wrong format I 
order etc. These problems are most prevalent in the UYF A04 
88 

& UYFDO 1 programs, but the problems are widespread 
across the database. 
[5] Section moves - Contracts are not moving properly after 
month-end cycles are run (e.g., contracts are not moving from 
CAR Section 5 to Section 8). 
[6] DD 250 processing- Not all DD Form 250 actions can be 
accomplished (such as Quantity corrections without errors). 
The major DD250 processes impacted are: 
• The Shipment Weight is not updating properly 
• Information entered is being incorrectly displayed on 
the screen after it has been input. 
• SQL errors are displaying after summary edits 
While 
the above issues are the most prevalent, the entire 
DD250 process is suspect. 
[7] Fall back (YCD4)- This module is not working properly 
as it does not allow rejected EDI I MILSCAP documents to be 
processed. 
[8] Progress Payments - Files are not reflecting correct 
amounts (e.g., cumulative progress payments paid) and 
consequently affect the ability to pay and appropriately 
monitor them. Both the payment and tracking 
side of the 
process must be working. 
[9] EDI Contracts (850s)- Transactions are not correctly 
updated. Incoming data is not populating (i.e., the effective 
date of the contract and date of signature). Other contract 
corrections cannot be made until date fields are manually 
inserted. Error Code "252 -
F IC-Appropriation Unmatched" 
is wrong for a number of the contracts because the data is on 
the APRs. 
[10] ACO Mod Module - interface, Openlink is not working 
properly as it does not consistently extract all ACRNs for a 
given PIIN I SPIIN. During the interface test, this problem 
appeared to be corrected. However, this same problem 
occurred during the Quality Review period. 
89 

[11] Shared Data Warehouse -All changes made in MOCAS 
(i.e. additions, deletes, changes) should be received in the 
proper order so that SDW data is current and correct. There 
have been numerous issues with data transfer rates, 
sequencing (i.e., incorrect sorting) and database records or 
tables not coming across with SDW. 
[12] JCL/Cycles - GT&E Q/A has only executed three cycles 
- Monthly, Daily and 1st Daily; although the "baseline" cycle, 
the Daily, is one of the three. To date, no cycle has run 
uninterrupted from beginning to end without experiencing 
ABENDS[291 requiring program mods, data manipulation, JCL 
and/or control cards' changes. Additionally, there are 
multiple "flavors" (i.e., slightly different variations) of the 
Daily cycle that will need to be tested. These cycles are 
dependent upon the work day or calendar day of the month-
2nd13r<l;4th/10th work day of the month and 7th;9th/10th calendar 
day of the month. 
[13] Month-end Invoice Process - Month-end Invoice 
Process is not updating the Invoice History (YDF 1) for 
payments made in the month end cycle. 
DF AS contracting and PMO personnel are working 
closely with AEon to ensure that all contractual requirements 
of CLIN 0001 are present before restarting GT &E. 
Specifically, AEon is required to correct the critical defects 
discussed above and to demonstrate the execution of the 
required functions stated in the contract. 
(R4, tab 31) In the second 28 December 2006 letter, with the referenced subject of 
"Suspension of Government Test & Evaluation," CO Gomolak stated: 
29 A program "ABENDS" when it experiences an abnormal ending caused by a problem 
or error beyond which it cannot proceed (tr. 2/225, 4/761, 5/949-50; supp. R4, 
tab 106 at 14). A list of various "ABENDS" that occurred during testing of daily 
and monthly cycles in the two GT &E periods, compiled by and distributed among 
the government testers, is contained in the record at supp. Rule 4, tab I 09 and 
contains 28 cycles (of a total of 32 cycles attempted) that experienced 
"[ABENDS]," 9 of whic,h could not be completed and were cancelled as a result. 
90 

The first factual discrepancy ... is the assertion that "the 
government has attempted to 
revoke its prior acceptance of 
the MOCAS system." This statement implies that the 
Government has accepted the delivery of CLIN 0001 and that 
has not happened. AEon delivered a product on October 23, 
2006 and the Government started testing to determine if the 
product meets the contractual requirements. As our previous 
letter indicated, the system currently does not meet 
contractual requirements and as such, we have rejected the 
product you delivered in accordance with our right in [SOW 
~ 11, Acceptance/Rejection] of the contract. 
The second factual discrepancy .. .is the claim DF AS 
can not suspend and restart GT &E as this would render 
meaningless an entire section of the MOCAS Contract. In 
making this argument, [AEON's counsel] appears to equate 
the [PMP] as being part of the Contract. He implies that the 
PMP established the Contract's schedule 
and would have one 
believe that the PMP submitted with the contractor's proposal 
(technical volume) would supersede the Contract and 
modification to the Contract. The PMP is a Contract 
[requirement in SOW~ 4] and does not in any manner modify 
the rights and obligations under the contract. 
The [PMP], along with all other deliverables required 
under the Contract [under CLIN 0001] never became part of 
the Contract. Neither the Contract, nor any modification, ever 
incorporated AEon's proposal. Furthermore, at the top of 
page 6 (end of line 8) in our SOW it states, "[t]he above 
reports (PMP and others) and IPRs do not relieve the 
contractor from the terms of the contract." Therefore, the 
idea the rules of contract interpretation give AEon's PMP 
more weight than the Contract is inaccurate. Our exercise of 
the right to reject CLIN 0001 is clear and unambiguously 
contained 
in [SOW~ 11, Acceptance/Rejection] and nothing 
in the Contract modifies this right. 
The third item ... state[d] is that "the Contract does not 
require AEon to deliver a defect-free system prior to GT &E." 
DFAS disagrees with [the] statement. Any interpretation of 
the contract as allowing AEon to deliver something less than a 
fully working MoCAS system has no factual basis and is an 
91 

attempt to unilaterally change AEon' s performance 
obligations required under the contract. 
The fourth assertion .. .is "[t]he contract's [PMP] and 
Schedule further provide 
that after the completion of user 
acceptance, both the production support phase and the repair 
phase will include the correction of "bugs" by contractor 
AEON." This assertion is also incorrect. Implicit in [the] 
argument is the assumption that DF AS is going to accept a 
MOCAS system that does not completely perform as the old 
system does. This assumption is inaccurate and brings us 
back to a point that is persistent in [counsel's] letter. 
This point relates back to the invalid premises both 
AEon and [counsel] have articulated, that AEon can deliver a 
product that has defects and DF AS has no other right but to 
accept a defective product and allow AEon to resolve the 
"bugs" over the next year. This interpretation would render 
meaningless the fact that CLIN 0003 is an option CLIN. 
Moreover, the use of the terminology "defect" and "defect 
free" in describing the performance requirements is a 
misleading use of words. Those terms should never be used 
to describe AEon's performance obligations under the 
contract. 
The contract is very clear on AEon' s performance 
obligation. Under CLIN 0001, AEon must deliver a 
rehosted 
MOCAS database that has 100% functionality of the "as-is" 
database. Using terms such a[s] "defect" has no place in the 
discussion of AEon's performance obligation. Its use 
distracts everyone from the true objective and obligation of 
AEon. That obligation remains a rehosted MOCAS system 
that mirrors 100% the actions and functionality of the old 
MOCAS system. 
By DF AS pointing out defects to be fixed, we merely 
were attempting to aid AEon in completing their obligations 
under the contract. The fact that discrepancies exist between 
the old system and the rehosted system provides evidenced 
[sic] that the system AEon delivered with CLIN 0001 has yet 
to achieve its required performance obligation. 
92 

As of this date, DFAS still awaits AEon delivery of a 
fully functional rehosted MOCAS system. DF AS has noted a 
host of issues that must be fixed or corrected in the rehosted 
MOCAS system. 
For example, in paragraph 14 of the SOW,f3°1 AEon 
was required to provide a [PMP]. For whatever reason, this 
has become the [PMP], the last of which (dated September 22, 
2006) was delivered to the Government as a final document 
(v9). Despite this designation as a final document, page 33 
indicates that several of the Work Breakdown Structures 
(WBS) are less than 40% complete. 
Yet, the rehosted database was delivered portending 
to 
have 100% functionality of the "as-is" database. This 
discrepancy raises many questions, including how could 
AEon perform several of the functional tests as part of their 
Quality Assurance testing when the several WBS are 
incomplete? In the September 22, 2006 PMP document, 
Section 6 "Schedule" states, "[t]he Work Breakdown 
Schedule and Project Plan for all phases of the MOCAS 
Rehost Project are updated at the end of each phase and as 
appropriate between the parties." This implies that your WBS 
is up to date, but less than 40% complete. 
DF AS has every right to demand and expect AEon to 
fulfill the obligations they have incurred to perform this 
contract. DF AS wrote this contract so that it was clear what 
the contractor had to do to complete performance. This was 
not the development of a new computer system, but rather 
translating an old programming language into a newer 
programming language. It is AEon's responsibility to 
produce a rehosted MoCAS that "works." That is, the 
Rehosted MoCAS must perform exactly the wa[y] the as-is 
system does. 
(R4, tab 30; tr. 2/316-17) (Footnotes omitted) 
30 We believe this is a typographical error as the PMP is required by SOW i! 4. 
93 

87. By letter dated 16 January 2007 counsel for AEON again took issue with 
CO Gomolak's expressed reasons for halting GT &E. In particular, he reiterated the 
argument that 
the contract contemplated that the Rehosted MOCAS delivered for GT &E 
would contain deficiencies: 
Further, the Contract required AEON to deliver a 
system with 100 percent functionality. The "functionality" 
requirement applicable to the re-hosted system, however, is 
not tied to the discrepancies the parties expected the 
sophisticated Government test experts to identify. Instead, 
"functionality" examines whether the system AEON delivered 
for GT &E has the same functions as the original system. 
Without a definition of functionality in the MOCAS Contract, 
the parties must rely on industry standard. In this industry, as 
you know, functionality concerns overall system 
performance-not the presence or absence of resolvable 
discrepancies .... 
(R4, tab 32; see also supp. R4, tab 121 at A012613-14). We find that the preponderance 
of the record is directly contrary to counsel's assertion that the contract did not define 
functionality; in fact the SOW devoted several pages to the specific definition of 
functionality (finding 14). It is that contractual definition upon which the government 
solicited proposals, AEON submitted a proposal and AEON executed a contract. Further, 
AEON's own PMP expressed its understanding that the Rehosted MOCAS was to 
perform exactly like the As-Is MOCAS (findings 55, 71). We do, however, find 
counsel's statement that "functionality concerns overall system performance" and not the 
presence or absence of specific defects or discrepancies to be in accord with the contract 
and the preponderance of the record (see also finding 87 in this regard). AEON counsel's 
letter continued to argue that the government's rejection of the Rehosted MOCAS was 
premature and that: 
You have yet to identify a single function contained in the 
original system that is missing from the rehosted system 
AEON furnished for GT &E. The reason? The systems have 
the exact same functionality.£311 
In any event, AEON has resolved all of the alleged 
deficiencies. Ms. Shirin Javid notified you by email dated 
December 29 that AEON has "fixed all client defects and 
31 Apparently counsel had not considered CO Gomolak's list of 13 violations of the 
functionality, i.e. functional failures, required by SOW ,-i 7 (finding 86). 
94 

(R4, tab 32) 
there are no 'open' defects." AEON has yet to receive any 
response to this notice. Your agency has not restarted GT &E. 
Your agency has not given AEON credit for the days of 
GT &E conducted by the parties even though the Government 
successfully completed some of its testing. Moreover, you 
have not communicated any date at which GT &E will resume 
or, alternatively, provided any rationale as to why it should 
not resume immediately. Further, the Government's 
undertaking of testing resolved defects has been minimal and 
slow. The MOCAS Contract does not contemplate such 
unreasonable Government 
delays, which have forced AEON, 
a small company, into a position of maintaining its work force 
in place at considerable cost while it awaits Government 
action. Your failure to respond constitutes compensable delay 
for which AEON could submit a [REA]. 
88. On 19 January 2007 AEON expressed its desire to complete the MOCAS 
Rehost project: 
[W]e do not want to walk away. We would strongly prefer to 
complete the Rehost project. We have formed a strong 
relationship with you, our client. We are dedicated to the 
work. We feel ownership in the 
project. We want to see the 
project to its fruition, which, if well managed and performed, 
should be only a few months away. To reach this goal, 
however, we need a commitment from DF AS which 
demonstrates that DF AS likewise shares the goal that AEON 
complete what it has started. 
As we have 
discussed, there are three major categories 
of work which require compensation. First we submitted an 
REA in October 2006 in the amount of $643,714 [see 
finding 75]. Second, we have an Engineering Change 
Proposal [ECP] outstanding, in the amount of $621,514. £321 
Third, the work associated with GT &E is valued by the 
32 The referenced ECP-2 was proposed by AEON in November 2006. AEON stated in 
the proposal that "No impact to the current MOCAS Rehost Project effort is 
expected." (App. supp. R4, tabs 162, 163; see also supp. R4, tab 106 at 23) As 
such, ECP-2 is irrelevant to the issues before us. 
95 

MOCAS Rehost Contract at $928,082. These three categories 
amount to $2,193,310. We believe we 
are immediately 
entitled to the entire amount of our REA and the entire 
amount of our ECP. In addition, had the parties performed 
GT &E in the manner described in our Contract, AEON would 
have been entitled to the 
$928,082 associated with GT &E on 
the 90th day of that period, which is today (January 19, 
2007).l33l 
Your decision to delay the REA, ECP and GT &E has 
damaged AEON. Under normal circumstances, we would 
have been compensated for the REA and ECP. Under normal 
circumstances, we would have been 
entitled to invoice 
$928,082 associated with GT &E on January 19th. In the 
interests of putting "normal circumstances" behind us and 
settling these issues, we want to compromise. To 
compromise, however, we will require immediate action from 
your agency. You claim not to have the funds to pay us for 
the REA, ECP or advance any portion of GT &E at this time. 
We understand that if your agency lacks those funds, you will 
be in violation of the Anti-Deficiency Act. Accordingly, we 
will assume you have the funds associated with these 
"buckets. "l34l 
Here is what we propose. We will re-start GT&E on 
Monday. In return, you agree to fund $386,228.40 of our 
REA immediately, which [sic] the remainder subject to 
negotiation. You also agree to fund $372,908.40 of the 
outstanding ECP immediately, with the remainder subject to 
negotiation. In addition, you agree to restructure the 
payments associated with GT &E in such a manner that 
facilitates payment in the amount of $556,849.20 to AEON 
now, with the remainder payable at the successful conclusion 
of GT &E. In order to restart work on Monday, we will 
require your commitment to pay the amounts listed in this 
paragraph by February 1, 2007. 
33 We note here that AEON would only be entitled to the GT&E payment it seeks here if, 
at the end of the initial 90-day GT &E functional testing period, the Re hosted 
MOCAS passed GT &E and was ready to be put into production in the second 
90-day GT &E period (see findings 11, 49). 
34 There is nothing in the record to corroborate this allegation by AEON. 
96 

As stated in this letter, we want to continue work in 
spite of what we consider material breaches. In return, 
however, we simply ask that the Government treat us fairly. 
Ifwe reach agreement, we will commence GT&E on Monday. 
Ifwe do not reach agreement, we reserve all rights. 
(R4, tab 33) There is no evidence in the record that the government paid AEON any of 
the three amounts sought by AEON as a necessary prerequisite to its continued 
performance under the contract. 
89. On 19 January 2007 AEON again certified that the Rehosted MOCAS met 
contract requirements and was ready for GT &E. The government restarted GT &E on 
22 January 2007 (R4, tabs 33, 34, 40, 49). 
[T]he Government agreed 
to resume GT&E due to AEon's 
assertions that all system problems had been fixed. Results 
from the Government inspection/validation during the 
suspension did not support AEon's position that the system 
quality of the system had matured and it met the requirements 
of the SOW. The Government acting in good faith resumed 
GT &E based on AEon's representation. 
(Supp. R4, tab 106 at 28; see also R4, tab 35) Taking into account the nine days of 
GT&E conducted from 24 October 2006 through 2 November 2006 (findings 77, 82), the 
expiration of the 90-day contractual GT &E functional testing period was now 10 April 
2007 (see also findings 95, 99). 
90. As of CO Gomolak's 6 February 2007 letter to AEON 15 days after the restart 
of GT &E, the government testers were still finding problems with critical "must 
function" modules: 
While AEon continues to report that defects have been 
fixed, government validation testing has determined 
that the 
identified defects still exist and additional defects are being 
found. This situation leads the Government to seriously 
question the adequacy of AEon's quality assurance testing 
relative to the correction of these deficiencies. You have 
indicated you did not run any complete batch cycles during 
your validation of the corrected deficiencies. Because a 
number of critical defects depend on a cycle being run to 
validate their correction, this further demonstrates the 
97 

Government's beliefthat when addressing defects, AEon is 
only focusing on correcting the specific problems identified 
rather than ensuring the overall function works properly. 
This issue remains a Government concern due to the 
fact that when inspecting problems reported as being fixed, 
DF AS & DCMA testers are unable to test the overall process 
function. Since the Government has resumed GT &E, there 
are still enough critical defects that prevent testing the entire 
end-to-end process. We have not been able to process EDI 
DD250's which resulted in a cancelled cycle. Progress 
Payment, SDW, Fallback and Contract Closeout continue to 
be a problem. There has been some improvement in contract 
input in which the tester can summary edit a contract, but the 
process is not consistent. SDW processing is still a problem 
in that files are not being sent across to the SDW test server. 
The Government testers have stated they can get beyond the 
original problem only to immediately have a new problem 
arise on a subsequent screen. Thus, the Government reiterates 
its position that AEon has not yet met the conditions specified 
in the SOW for delivery of CLIN 0001. By this, we mean that 
Re-hosted MOCAS program must function like the "as-is" 
program functions. 
(R4, tab 35) The letter provided a non-inclusive list of nine "new problems that have 
been 
encountered." DCMA test 
lead Turner described what the testers found upon 
restarting GT &E: 
Well, there was still a lot of problems with the testing, 
and significant problems with areas such as interface tools, 
S[D]W, MOCAS, contract closeout as far as movement from 
section to section. 
And by that I mean just like the lifecycle of the 
contract, and like contract administration reports, and sections 
describe what phase its in .... 
But that wasn't happening, and it was supposed to be a 
kind of an automatic process, and when you ran a monthly, 
those things weren't moving the way they should have been. 
98 

And that was one of the big areas, and you had 
payment problems, and quality assurance problems, and 
management information system problems. We had problems 
with transfers .... 
(Tr. 4/769-70, 5/900-01) 
91. On 7 February 2007, AEON's President and CEO sent letters to two Ohio 
Congressional representatives seeking assistance in getting payment from the 
government. In the letters, AEON characterized the government's suspension and 
subsequent restart ofGT&E as a failure on the government's part to "fully commit to this 
phase and ... not provide the resources required to successfully complete it": 
The Government's actions ... have exposed AEON financially 
to over $3M in debt. I have borrowed money and have even 
obtained a second loan on my home to meet AEON' s 
financial obligations. Unfortunately, we no longer have the 
funds to make payroll. We have already missed one payroll 
and will probably miss the next payroll also. We expect 
that 
our employees will leave in the next few days. They will be 
without a job and be forced to file for unemployment. 
In conclusion, the Government through its actions is forcing a 
competent and qualified woman owned small business into 
bankruptcy and causing unemployment for Columbus. 
(R4, tab 36; see also app. supp. R4, tab 190) There is no evidence in the record of a 
response to either letter. COR Thrower observed: 
In the end, they realized that they were at risk because 
they had employees that had left, because the employees were 
working and not getting paid. So they were losing staff. 
They only had like maybe five or six people left, and 
the people that were left were retired government employees, 
and so they had a good check coming in. 
So the ones that left, you know, that didn't have 
another source of income, they left. They knew that they 
didn't have enough staff to be able to continue the project at 
that point in time. 
99 

(Tr. 3/471-72) 
92. In a 14 February 2007 letter AEON denied many of the allegations made in 
CO Gomolak's 6 February 2007 letter. In particular: 
We are very concerned because of the lack of information 
about the overall GT &E testing process. We do not know the 
Government's GT &E test plan, test approach, what has been 
tested, what works ... etc. Since this is a fixed price contract 
we are entitled to know what the Government is testing, how 
many tests are conducted daily, what issues exist and what 
works. The only information that we continuously receive is 
that nothing works. We have a real problem with this 
approach. 
(R4, tab 37 at 1260-62) AEON again repeated this position in a 19 March 2007 letter in 
which it took the position that the government's failure to share specifics of the GT &E 
process with AEON was a breach of its duty of good faith and fair dealing under a 
firm-fixed-price contract (R4, tab 39). We find nothing in the contract or the concept of a 
firm-fixed-price contract that obligated the government to share the specifics of its GT&E 
process with AEON. The GT&E process was a final inspection of delivered product and 
conducted for the benefit of the government, not AEON and was not intended to be part 
of AEON's quality assurance program. 
93. On 27 February 2007 CO Gomolak responded to the 16 January 2007 letter 
from AEON's counsel (finding 87): 
[T]he contract did not contemplate AEon turning over a 
system for GT &E that could not perform the most basic and 
essential processes the "as-is" system could perform. 
Clause 9 of the SOW requires unit testing, integration testing 
(which includes testing the rehosted MoCAS functionality), 
performance testing and a trial migration. The purpose of this 
testing was to ensure that the Contractor bore the risk and 
responsibility to deliver a working product. Furthermore, the 
Contractor was required to certify that their product was 
working like the "as-is' prior to handing it over to the 
Government for GT &E. 
The deficiencies we identified were of such a 
magnitude that complete end-to-end cycle testing could not be 
100 

conducted. For example, the rehosted MoCAS system could 
not process a DD250 form so as to allow an invoice to be 
paid. Processing a DD250 is a very basic transaction in 
MoCAS. Because the system AEon delivered had trouble 
processing a basic transaction, our testers' time and efforts 
were unproductively lost. Thus, the Government's decision to 
return the system to AEon and thereby allow AEon an 
opportunity to correct the plethora of discrepancies uncovered 
was a very reasonable course of action. 
Moreover, we indicated that as soon as you had 
corrected the errors we found and were able to provide a fully 
functioning system, we would restart GT &E. This is a very 
reasonable approach considering the circumstances. To 
AEon' s credit, since re-starting GT &E on January 19, 2007, 
several successful cycles have been completed with minor 
technical issues (i.e., no abends). However, on January 22 
and 24, cycles had to be cancelled in "mid-test" because 
critical path programs would not run and could not be fixed in 
a timely manner. Furthermore, some fiscal appropriation data 
was not aligning properly, if at all, to the contract line item 
under which the funds were obligated. The system can't 
automatically transfer data to SDW, which is integral to the 
system and remains an issue. 
These are just a few examples of the critical 
discrepancies which still exist today that should have been 
uncovered during AEon's QA testing. The Government is 
justified in expecting that a properly run QA test would have 
uncovered such conditions. [AEON]'s decision to collapse 
testing and do everything in parallel prevented it from 
properly performing the testing required of it. AEon never 
ran all cycles in the system during its testing, so it never 
performed a proper integration testing. Attached to this letter 
is a memorandum which details more precisely AEon's failure 
to follow industry standards and contractual requirements 
during the QA test phase. Because AEon did not conduct 
proper testing as required in the contract, AEon was unable to 
deliver a product, which conformed to contractual standards 
at the start of GT &E. AEon' s failure has lead to the 
Government uncovering fundamental problems that were not 
101 

contemplated by the Government to be "discovered" during 
the 90-day GT&E period. 
As to (AEON counsel]'s discussion on functionality, 
we would agree that the Re-hosted (to-be) database must 
duplicate the functionality of the "as-is" database. However, 
our contention is that several critical functions have yet to be 
tested because the contractually required functionality is not 
present; i.e., these functions simply do not work. Considering 
the system did not work, AEon never should have certified it 
was ready for GT &E and correspondingly AEon's entitlement 
to payment for milestone 7 A. Thus, the Government 
exercised its right to properly reject 
the CLIN 0001 delivery 
until such time as all functionalities of the Rehosted MOCAS 
database functioned in accordance with the terms of the 
contract. 
As pointed out above, what was delivered by AEon 
confirms the Government's belief that AEon did not 
satisfactorily perform all the required steps of their QA test; 
steps that industry standards would require to be completed. 
More distressing is the fact that AEon has represented the 
rehosted system had the functionality and worked like the "as­
is" when it certified the system 
was ready for GT &E. Thus, 
CLIN 0001 was delivered to the government before the 
system was performing like the "as-is." It was delivered 
before AEon had completed required portions of a proper QA 
testing period. 
It's possible we are arguing semantics when it comes 
to software deficiencies and functionality. (AEON counsel] 
argues that all the functionality is present, but that there are 
software deficiencies contemplated under the contract that 
would be revealed during the "sophisticated" Government 
testing process. The fact of the matter is there are many, 
many software deficiencies that have degraded required 
functionalities to the point that certain functions are not 
present in the Rehosted MOCAS database. The 
Government's conclusion, the 100% functionality 
requirement set forth in paragraph 7 of the SOW, simply 
stated, has not been met. 
102 

(R4, tab 38) 
94. In early March 2007, about halfway through the re-started 90-day GT&E 
functional testing 
period, the PMO contacted four organizations, including Software 
Engineering Institute at Carnegie Mellon (CM/SEl), 35 and inquired of them as to their 
interest in providing Independent Verification and Validation (IV & V) Support to DF AS 
of the Rehosted MOCAS delivered by AEON for GT&E (app. supp. R4, tabs 211, 216, 
222-23, 286; tr. 7/1160-62). The PMO described CM/SEI's proposal as "start[ing] out at 
a 
very high level and appeared to be focused on management processes. After several 
discussions with DF AS, they seemed to comprehend the technical nature of the request." 
(App. supp. R4, tab 223) As of 23 April 2007, after weeks of discussion with the four 
organizations, the PMO was ready to engage CM/SEI (id.). The initial request from the 
PMO to CM/SEI was very specific that its request was time-sensitive and that the primary 
focus was to be on whether the product delivered by AEON was "salvageable," defined 
as "can the product be repaired to a fully functioning system in a reasonable time period." 
The request further specifically stated: 
Task 3. Follow-on elements: 
While DF AS is open to any and all recommendations about 
the project in general and possible future course of action(s), 
process improvements, etc., DFAS wants to reiterate the 
immediate and technical nature of this request. DF AS 
recognizes that management and development strategies will 
be useful and necessary, but only if the technical assessment 
determines the product is viable. 
(App. supp. R4, tab 290) The "initial items of concentration" were identified by CM/SEI 
as: 
Determine whether the MOCAS re-host project is salvageable 
and maintainable 
Determine ifthe MOCAS re-host project code is adequately 
functional and useable 
Identify areas of the system that may need re-work 
35 CM/SEI is a Federally Funded Research and Development Center (FFRDC) chartered 
in the mid- l 980s to focus on software-related issues for the DoD. CM/SEI 
provides its services to many Federal agencies, including the DoD and Department 
of Homeland Security. (Tr. 711150) 
103 

Determine resources appropriate for completing the MOCAS 
re-host project and the difficulties that may be encountered 
Estimate how long it will take to complete the MOCAS 
re-host project 
(App. supp. R4, tab 258 at 10; tr. 5/1107-08, 7/1163) CM/SEI's proposed Independent 
Technical Assessment ( ITA) was to take place over a period of time not to exceed two 
months, at the end of which CM/SEI would present an "annotated briefing which will 
contain the team's findings and actionable recommendations" to DFAS (app. supp. R4, 
tab 290; tr. 711162, 1251-52). 
An independent technical assessment is a 
technique that 
[CM/SEI] uses to look at a program when it has been 
identified that it is in serious trouble. 
Usually those requests for this kind of an examination 
come from a senior DoD official, usually a very senior 
program manager or a PEO, which is somebody who has 
cognizance over many problems, or it comes from a level of 
the service acquisition executive, who has cognizance over 
everything. 
And basically what we are asked typically to do here is 
to look at the program, and try and figure out what is wrong, 
and what could be done to fix the situation, or in some cases, 
we have actually recommended that a program be terminated. 
And the Government uses us in this context from the 
perspective of being an honest broker, having no skin in the 
game at all, and trying to provide a programmatic wide 
perspective, and what I mean by that is that an IT A looks at 
management. It looks at people. It looks at program offices, 
and it looks at the technology, and things like that. 
And that is the way that we have to approach it, 
because the program is in trouble, and we are trying to help it 
get better, or in some cases - I mean, some programs are 
better off being terminated and restarted. 
104 

(Tr. 7 /1178- 79) The record does not indicate when DF AS and CM/SEI reached 
agreement on the performance of an assessment of the Rehosted MOCAS. CO Gladski 
was involved in discussions about having an independent assessment performed and was 
aware that the PMO had contacted CM/SEI but was not involved in the details of the 
engagement (tr. 1/142-43, 2/165, 168-76). 
95. On 22 March 2007, 71 days into the 90-day GT&E functional testing period, 
CO Gladski issued a Cure Notice in which AEON was notified that the government 
considered AEON's failure to make adequate progress in correcting code deficiencies 
during GT&E and AEON's failure to consistently pay its employees as conditions that 
endangered performance of the contract (R4, tabs 26, 40, 45; tr. 11121-22). The failure to 
make adequate progress was identified by the government as the failure of AEON to 
deliver a system with 100% functionality of the "as-is" system as defined in Section 7 of 
the SOW. 
There were so many deficiencies that were discovered, 
and at that point in time the PMO said that it would be next to 
impossible for GT &E to be successfully completed. 
GT &E testing ... was never successfully completed. 
The test scripts could never be run from end to end because 
there always seemed to be another deficiency that would 
occur in the process, and that was a great, great area of 
frustration to the testers, because they could never get a full 
end-to-end. 
Something would be identified as a defect, and it 
would be corrected, and you would get through that, and you 
may end up having something else fail that had previously 
been fixed. 
And once you got that fixed, something else would 
happen. So it was just a never ending situation of failure 
upon failure. 
(Tr. 11122, 124) More specifically, COR Thrower described what occurred: 
Regression testing is when you have a defect that is 
reported, and you go in and you test it. And you have a report 
105 

that Problem A works, and you go in and test A, and it works. 
You try to go to B. B doesn't work. 
And I'm talking about screens, okay? So B doesn't 
work, but then you report that problem, and they fix B. So 
you go back in to test, and now A doesn't work, and where it 
worked the first time. 
So every time you go back in, you are testing the same 
stuff over and so you are regressing testing, and you are not 
getting further along in your tests. 
(Tr. 3/389-91, see also tr. 4/763) Specifically, six MOCAS functions were identified in 
the Cure Notice as critical and which were not 
functioning correctly in the Rehosted 
MOCAS: 
• Military Standard Contract Administration Procedures 
(MILSCAP) and Electronic Document Interchange (EDI) 
Process: 
Contracts received electronically through MILSCAP or 
EDI are erroneously being rejected for accounting line 
errors (appropriations errors) when in fact the line of 
accounting is correct and the appropriation is on the 
master appropriation file. In addition, electronically 
received contract modifications, invoices, and 
receiving and acceptances are also rejecting for 
erroneous "NO CAD" or "NO PINY" error messages, 
meaning that No Contract Administration Data is on 
file or No Contract (PINY) is on file, when in fact the 
contract has been processed and already resides on the 
database. 
• FallBack Process: 
Contracts received electronically through MILSCAP or 
EDI that are rejected and placed in the FallBack system 
for manual review and processing can not be processed 
due to numerous SQL error messages. In addition, in 
those instances where a contract or modification is 
successfully processed through FallBack (i.e. 
successfully Summary Edited), not all the individual 
106 

contract data elements are updating the database files, 
resulting in problems with missing data later. 
• Material Acceptance and Receiving Report (DD250): 
Shipment and acceptance reports received 
electronically through EDI are being erroneously 
rejected and placed in the recycle file 
for manual 
review and processing because the system is not 
recognizing that there is a valid contract on file. In 
addition, the system is erroneously creating, or 
allowing the creation of, duplicate shipment records 
resulting in subsequent shipments/acceptances to 
erroneously reject. 
• Automatic Payment of Invoices (API): 
The API process disbursed funds against the wrong 
appropriation, Material Acceptance Account Payable 
Reports (MAAPRs) show notebook entries which are 
on the contract, system generates a manual MAAPR, 
indicating an invoice requires manual review and 
processing by a voucher examiner, but erroneously 
continues to try to process the payment automatically; 
invoices that should pay automatically are being 
rejected for insufficient funds when sufficient funds 
are available. 
• Progress Payments: 
Data elements input during the entry of progress 
payments are not updating the database properly, 
which causes erroneous payments and the on-line 
screens and batch reports to display incorrect dollar 
amounts. 
• Shared Data Warehouse 
(SDW): 
Daily jobs to archive files, build SDW bridge 
(interface) logs, and update the bridge matrix have 
failed through most of the GT&E. The problems 
prevent or delay the sending of transactions to SDW. 
107 

We have identified these particular critical processes in this 
Cure Notice from among the numerous deficient processes in 
the rehosted code previously identified to AEon. Thus, these 
conditions are materially contributing to AEon' s failure to 
progress in making timely code corrections during GT &E I 
Event !Phase 7. 
Please be advised that curing these processes alone 
will not satisfy AEon's ultimate contractual obligation to 
provide the re-hosted database and code with 100-percent 
of the functionality of the As-Is MOCAS required by 
section 7 of the SOW. The purpose of GT &E Event/Phase 7 
testing is for the Government to determine whether the code 
and re-hosted database are contractually acceptable. If, at the 
end of the GT &E period, AEon still has failed to deliver a 
code which meets the functionality requirements contained in 
the SOW, the Government will have 
"failure to deliver" as an 
additional ground for termination for default. Based on the 
90-day period, this GT &E Event/Phase 7 testing period runs 
through April 10, 2007 .1 
1 Initial Event/Phase 7 testing by the Government in 
October and November 2006 exposed that the code was not at 
the maturity level certified by AEon at the conclusion of 
Event 6. The Government suspended testing events on 
November 15, 2006, via written 
notification, because the 
product could not perform basic system functionalities. In 
that letter, the Government rejected tender of the re-hosted 
MOCAS code and advised AEon that it stood ready to 
recommence testing upon AEon's satisfaction of its 
contractual responsibility of resolving problems sufficient to 
establish basic core functionality. In good faith, upon Aeon's 
affirmation that the system was once again sufficiently mature 
and ready for testing, the Government during the January 18, 
2007 GT &E status meeting elected to accommodate AEon's 
request to recommence Event/Phase 7 testing. Event/Phase 7 
testing recommenced on 22 January 2007. In the period 
since, AEon continues to fail to make adequate progress 
through Event/Phase 7 in correcting the MoCAS [sic] code, 
108 

which remains incapable of being executed as an entire 
end-to-end process and does not meet contractual 
requirements. 
(R4, tab 40) (Emphasis added) We find CO Gladski's testimony, almost 
three years after 
issuance of the Cure Notice and almost two years after his retirement (finding 15), that he 
understood the list of six "critical functions" in the Cure Notice to be "reflective of every 
defect that was known at that time" (R4, tabs 26, 40; supp. R4, tab 106 at 25; tr. 1/123, 
125) to be inconsistent with the express language of the Cure Notice, quoted and 
emphasized just above, as well as elsewhere in the contemporaneous record evidence that 
the six areas identified in the cure notice were "only a few of the numerous deficient 
processes in the rehosted system" (see also supp. R4, tab 106 at 29). Within just the six 
categories of functions listed in the Cure Notice, there were a total of 99 specific 
deficiencies identified by the government and provided to AEON (supp. R4, tabs 96, 97; 
tr. 11125-26, 2/219-23). AEON was given 20 days within which to cure these six 
functional failures and the government stated that failure to do so may result in a 
termination for default of the contract (R4, tab 40; supp. R4, tab 106 at 29). 
96. On 3 April 2007 AEON responded to the Cure Notice advising that, of the 
99 specific deficiencies provided by the government in a list on 28 March 2007, 96 had 
been corrected and the remaining 3 would be corrected no later than 9 April 2007 
(R4, tab 41 ). There is no indication in the record that, just because the 96, or even 
99 deficiencies were allegedly fixed, the functions to which they pertained were then fully 
operational. 
97. DCMA test lead Turner, who had over 25 years experience using the existing 
MOCAS system, testified that "as far as the contract administration, and payment 
procedures" the Rehosted MOCAS had "too much missing to be able to function" 
(tr. 4/780). 
Q Overall what was your view of the performance 
of the rehosted MOCAS? 
A 
I don't think it was ready. 
Q And what do you mean by that? 
A I don't think we could have used it in a 
production environment. 
Q Do you have any idea as to how close it was to 
being ready? 
109 

A I think we had just started scratching the 
surface. I would say maybe a third. 
Q And what do you mean by that, that you had just 
started scratching the surface? 
A We could get to the first phase of doing the 
function, and we can't get to the next step, and there was 
areas that we didn't really get to delve into because of some 
of the problems there were that we found, and in such areas as 
QA Miss, which was a quality information management 
system, we needed to hit that a little harder, and we weren't 
able to do that. 
We were able to do internal transfers, which we still 
have problems with, but we were not able to do an external 
transfer. The idea initially was that we were going to start off 
with one MOC and gradually pull in the other two MOCs. 
And by that I mean MOCAS is divided up into three 
different areas. They are a copy of the same thing, but one 
has contracts for the west region of the United States, and one 
had them for the northeast, and one has them for the south. 
The one that has the south is MOCG, and that has the 
fewest contracts. So we started using the data for MOCG, 
and then we were supposed to go to MOCH or something. I 
deal with doing external transfers, which is a big piece of our 
business, and we weren't able to do those types at all. 
In some of the areas, if you can't set up and stage 
things, and you find problems between, then you can't get to 
the next phase of what you are trying to complete. 
That's why I am saying that we had just scratched the 
surface on some things in MOCAS. We didn't get down to 
the level that we needed to go to. 
(Tr. 4/784-86, 790-91, see also tr. 5/1031) AEON insisted that the failures were because 
the government did not load and retest fixes that AEON had made (R4, tab 39 at 1275). 
The government responded that: "We continued to test. The reason why so many test 
110 

cases may not have been tested is because they couldn't get further along in the testing. 
You can't test 
the next position if you can't move along in the screen." (Tr. 3/461, 
486-88, 506, 524-30, 5/1022-23, 1033) We find that the specific number of critical 
functions or defects is not indicative of whether the Rehosted MOCAS had 100% of the 
functionality of the As-Is MOCAS. If the Rehosted MOCAS could not perform exactly 
like the As-ls MOCAS, regardless of whether there were 6 problems or 60 or 600, the 
Rehosted MOCAS failed to meet the contract requirement of 100% functionality. 
98. On 5 April 2007 AEON submitted to a Congressional representative an 
"URGENT REQUEST FOR ASSISTANCE" in getting payment of $2.1 million it 
claimed was due and owing for successful GT &E, as well as its October 2006 REA and 
its November 2006 ECP (see finding 88) (R4, tab 42). In the submission AEON stated: 
AEON is committed to completing the contract and has, until 
very recently, paid its employees despite DFAS' refusal to 
make further payments.... DF AS' failure to pay anything this 
year has put this small business in debt over $3.0 million. 
Because borrowed funds have now [run] out, AEON has 
missed four biweekly payrolls. On Friday, March 23, it 
missed its fifth payroll. The company has never defaulted on 
its contract with DF AS but simply cannot continue 
performance without at least a partial payment from the 
government. 
(R4, tab 42) The record contains no evidence of a response to AEON's request. 
99. The 90-day GT&E functional testing period ended on 10 April 2007 
(supp. R4, tab 103 at A005698; findings 89, 95). The government continued to test fixes 
uploaded by AEON through the week of 18 April 2007 and wrote up problem reports as 
late as 27 April 2007 (tr. 3/469-80 [tested for two weeks after AEON stopped making 
changes], 4/770-72, 834-35, 5/905, 956, 1050; see also, R4, tab 45 [5of6 cure notice 
issues still a problem]; supp. R4, tabs 106 at 29, 108, 111, 113). 
100. On 24 April 2007, two weeks after the end of the 90-day GT &E functional 
testing period, the DF AS and DCMA testers circulated among themselves their comments 
on the status of multiple "significant" outstanding "Cure Items" at the close of GT &E 
(supp. R4, tab 108; tr. 4/779-81 ). On the same date the DF AS MOCAS Rehost - GT &E 
Final Test Report was issued in which it was reported that only 46% of the total test 
conditions had been performed "in part due to regression 
testing [see findings 55, 95] and 
persistent system problems" (app. supp. R4, tab 224; supp. R4, tab 111 [306 test 
conditions not 
even tested]; tr. 51965, 975-76, 1028-29). 
111 

[W]e still had a large volume of critical A [see finding 79] 
fixes outstanding .... 
Just under 50 percent, maybe like 40 percent or so of 
[MOCG] the testers were able to test. 
If [the rehosted MOCAS] had all the functionality we 
wouldn't have encountered the numerous errors that we 
encountered. If we had this product in real world today we 
would be a mission failure, if we can't input mods and 
contracts and pay invoices .... 
[The total test conditions reported to be completed] 
[l]ooks like 46 percent. Our concern going forward was 
MOCG was probably one of the smaller MOCs as far as 
complexity. We have foreign currency on MOCH, very 
complex programming, we hadn't even gotten to that point. 
So even though the numbers look like we're halfway there, 
there [was] very important testing that we didn't even get to. 
(Tr. 511039-43, 1045) 
101. The government testers determined that the MOCAS interface with the 
Shared Data Warehouse (SDW), a critical function for DCMA, was not functional at all. 
"It would never do anything. It wasn't even able to be tested." (Tr. 3/534-35) 
The shared data warehouse is not MOCAS. 
It is a different system. The MOCAS interface is what 
AEON was committed to produce the same interface files that 
the as-is generated for the shared data warehouse. That was 
the extent that they needed to develop the same interface files 
to the share[ d] data warehouse. 
112 

(Tr. 4/736; see findings 5, 14, 39, 48) 
Shared [D]ata [W]arehouse is one of our critical 
applications in DCMA.... It is refreshed daily through 
MOCAS sending the notices to SDW. 
And it basically is the guts of every web application 
that we have in DCMA. We rely on that MOCAS data to pass 
to SDW, and 
be updated and current. So when SDW doesn't 
work, our agency is like in deep trouble, because none of our 
web applications work as well. 
And what this problem sheet was saying is that we 
were having a hard time. We weren't capturing updates. We 
were not capturing new contracts. We were having a hard 
time. SDW wasn't functioning basically at all with the new 
rehost database. 
(Tr. 3/598, see also tr. 5/988-96; supp. R4, tab 123-J) DCMA tester Jackson testified that 
the SDW interface was not functioning correctly: 
Oh no, absolutely not. 
I have been involved in a lot of 
type tests, and generally we are shaking out the system and 
you do find some bugs. In this case, it didn't work at all for 
us, and it was almost as if we were in the development and 
design stage, it worked not at all. So no, it was not ready in 
any way, shape, or form. 
(Tr. 5/997) Jackson further testified that, even at the end of GT &E: 
We still had lots of errors, other than what the ticket 
sheets show, as you put in a ticket, as things were resolved, 
more errors were found at different layers, it just seemed to 
keep cascading. As we would uncover one error and resolve 
it, you would then have another error or sometimes you'd go 
back and have an error that you hadn't seen before .... And so 
the improvement that we saw was, things were lined up, but at 
that point the errors were deeper into the architecture and it 
became apparent that the problems were just so deeply 
embedded we weren't even sure why things were being 
113 

generated the way it was being generated, there was missing 
data, it was just kind of unfolding. 
[The rehosted MOCAS bridge 
to the SDW did not 
work like the as-is MOCAS bridge.] The system as in place is 
highly dependable, we have extremely high rate and our 
depend [sic] on the integrity of that system. If we had failures 
we reload that system, and normally we don't have calls to 
reload it. In this case it could never have stood up to the 
rigors and to the users, they would have lost confidence 
immediately in the system because there were so many 
inaccuracies, we could have never deployed this as it was at 
that time. 
[Putting the rehosted MOCAS bridge to the SDW into 
production] would have been disastrous, the number of errors 
and problems .... So we had data that was incorrect, data that 
was missing, and we had no way to track back where it 
was .... And for a[n] information system that people depend 
on for producing reports of money, of contractor activity, you 
can't have it in that much error, and the errors were extremely 
high. 
Well I heard [from AEON] that throughout the tests 
that it was just, you know, a few things to fix, just a few 
things to fix, and we kept going and going and going, and 
seeing that the further that we got into it the more 
problematic. I mean initially when we were curing things, 
were realigning fields, I was hopeful. When we started seeing 
problems that we had no idea what was generating, that some 
of the programs were developed by different people who 
didn't work the same way, this log analyzer that they were 
using seemed undependable, seemed to be very buggy maybe, 
I don't know. It was obvious that this was not going to work 
no matter what we did. 
114 

(Tr. 51996-00; see also supp. R4, tab 113) DCMA test lead Turner summarized the SDW 
issues as: 
SDW - The Mocas Rehost process of sending updated 
transactions from Mocas to SDW continued to be 
error-ridden. At GT &E conclusion, a percentage of 
transactions continued to fail the SDW database commit 
process. The contractor process to identify and send 
transactions to SDW became operational a few weeks prior to 
GT &E close, but did not reliably function. Functional testers 
examining transactions that were successfully relayed and 
committed to SDW found numerous errors in data and data 
relationships. 
(Supp. R4, tab 108; see also finding 106) 
102. The PMO made the determination that: 
Based on the number of outstanding critical system problems, 
inconsistent processing results, and continued challenges in 
completing nightly cycles, especially monthly cycles, the 
Government testers could not certify nor recommend 
deployment of the rehosted MOCAS to production. These 
results, AEon's failure to deliver a system with functionality 
mature enough for user testing and AEon' s inability to cure 
system areas with significant deficiencies, led the PMO to end 
all Government testing activities. If continued, the PMO 
determined, with concurrence from the Government testers, 
that the process in which the Government was required to find 
the defects for Aeon to resolve (i.e. find and fix process) 
would continue indefinitely. 
(Supp. R4, tab I 06 at 30) 
8. WBS 8, GOVERNMENT ACCEPTANCE/REJECTION 
103. WBS 8 correlated to Payment Event 8. The required tasks to be completed 
by AEON for Payment Event 8 were identified in the contract 
as "Completion of the 
delivery and acceptance of CLIN 000 I in the Production environment" (finding 21 ). In 
other words, in order for AEON to qualify for Payment Event 8 the Rehosted MOCAS 
had to pass the initial 90-day GT &E functional testing process, pass the second 90-day 
production testing period of GT &E in which the MOCs would be put into full production 
115 

and, finally, the Rehosted MOCAS had to be accepted by the government. AEON's 
29 December 2006 MOCAS Rehost Project Plan showed that WBS 8/Payment Event 8 
was started on 11 October 2006 and, as the Rehosted MOCAS was rejected by the 
government 
(findings 104, 117, 119) and never accepted, Payment Event 8 was never 
completed. AEON's own MOCAS Rehost Project Plan reports that WBS 8 was just 14% 
complete as of 19 January 2007 (app. supp. R4, tab 172 at 5). 
104. On 25 April 2007 CO Gladski issued a Show 
Cause notice advising AEON 
that it had "failed to perform ... within the time prescribed" and had not successfully cured 
the conditions endangering performance which were described in the Cure Notice 
(finding 95). Specifically, CO Gladski determined that as of 11 April 2007 the Rehosted 
MOCAS database "still does not perform significant basic system functionalities" and 
that the government was considering termination of the contract for default. AEON was 
given 10 days within which to respond. (R4, tab 43; see also, supp. R4, tab 106 at 30; R4, 
tab 45) 
105. On 28 April 2007 DF AS secured funding for CM/SEI to perform an 
evaluation of the Rehosted MOCAS delivered by AEON (app. supp. R4, tab 234 at 2 of 4, 
tab 255). 
106. On 30 April 2007 the DCMA testers issued their GT &E Final Test Report, a 
copy of which was provided to the PMO: 
During the period between 22 Jan 07 and 10 Apr 07, DCMA 
prepared conditions and expected results for 455 test 
conditions: 
116 conditions passed/closed, 9 canceled, 9 partially 
tested, 22 failed, and 299 were not tested; 34% 
completion rate). 
However, during the entire testing period from Oct 06 thru 
Apr 07, DCMA generated and performed regression testing 
on the following Test Deficiency Report totals: 
411 deficiency reports were issued applicable to the GT &E: 
204 Category A 
> Critical/Fix Immediately 
191 Category B >Major/Fix before Test Completion 
14 Category C > Fix Before Deployment 
1 Category D >New Requirement 
1 Category E > Problem Exist in Production 
116 

At GT &E conclusion, the government continued to experience 
inconsistent test results. For example, there were still problems with 
contract close-out.. .. There were also problems with the internal 
transfer .... An external transfer of contracts was not conducted, 
since only one database was used for GT &E. 
The Mocas Rehost interface to SDW never achieved a successful 
level of accuracy or dependability. DCMA staff assisted AEon on 
numerous occasions throughout the testing. However, at GT &E 
closure, a number of transactions continued to fail the SDW 
commitment process. The numbers and types of transactional errors 
varied over the course of GT &E, but full success was never 
accomplished. 
The load process which synchronizes the SDW database with 
[MOCAS] continued to have errors through the last week of GT &E 
testing. There were findings of erroneous and corrupted data and 
incomplete data relationships within SDW. At no time did testers 
conclude the SDW was in complete synchronization with the Rehost 
Mocas database. 
There were only two attempts made to run QAMIS Monthly cycles. 
Abends in the QA MIS area occurred in multiple cycles. A fix was 
eventually promoted for cycles to successfully process, but the 
DCMA Team was not able to sufficiently test QA-MIS. 
During GT &E, there were 36 cycle abends and 9 canceled cycles due 
to program/JCL problems. The DF AS-TSO office processed nightly 
cycles and confirmed with respect to cycle abends that problems 
were not due to data used for testing. 
Based on the number of outstanding critical system problems, 
inconsistent processing results, and continued challenges in 
completing nightly cycles, DCMA does not certify nor recommend 
deployment ofMOCASR MUJ MOC G to production. 
(Supp. R4, tab 113; tr. 4/835-36) 
107. On 4 May 2007 AEON responded to the show cause notice. It's first stated 
response was that there was no valid basis for termination for default. It further argued in 
117 

the alternative that, even if grounds for default existed, "they are individually and 
collectively attributable to causes beyond the control and without the fault or negligence 
of AEon, and therefore excusable" under FAR 52.249-8(c). (R4, tab 44) 
108. Sometime after 4 May 2007 the PMO replied to AEON's response to the 
show cause notice: 
It is the government's position that AEon delivered a rehosted 
MOCAS system with significant discrepancies between the 
functionality of the rehosted MOCAS and the as-is MOCAS. 
Additionally, AEon was unable to increase 
the maturity level 
of the system significantly enough during the five and a half 
month time period following the initial delivery, to 
demonstrate that they have sufficient competency to complete 
the rehost effort. The GT &E results and a final inspection of 
the system found numerous and severe discrepancies that 
warrant the Government's rejection of the delivered system. 
It is also the Government's position that AEon did not meet 
earlier Milestone objectives under the contract to include: 
~ Ascertain the functionality of the current, as-is 
MOCAS 
~ Ensure that the rehosted MOCAS has 100% of the 
functionality of the as-is MOCAS system 
~ Perform testing to include unit testing and integration. 
~ Perform Project Management 
~ Higher Level of Quality Assurance as defined by the 
ISO 9001 standard. 
Based on the GT &E results, AEon did not ensure that the 
rehosted MOCAS had 100% of the functionality of the as-is 
MOCAS system. Several processes did not function as they 
do on the as-is system. Therefore, it can be concluded that 
they did not adequately perform testing. AEon has admitted 
in several pieces of correspondence and during the In Process 
Reviews (IPR) that they limited their unit testing to ensuring 
that the program could run, not if it would function correctly. 
They also admitted that they performed only representative 
118 

testing[361 during their integration testing. As a result, they 
missed the opportunity to test the system as a single product. 
They also did not perform in accordance with industry 
standards (e.g. ISO 9001) and best 
practices. In other words, 
they did not perform complete unit testing or integration as 
defined by industry standards and best practices to ensure all 
program changes were fully tested. 
Although AEon failed to perform the tasks prior to GT &E 
and could not cure the system problems during GT &E, it is 
more important to note that they do not indicate that they have 
insight into the magnitude of defects in the system; what 
might have caused them (e.g. conversion process); and, most 
importantly, what it would take to resolve them. To date, 
AEon has not presented a "Get Well" Plan that could be used 
to move the project forward. A Get Well Plan would identify 
the method in which AEon could move toward achieving the 
100% functionality and provide a means for measuring and 
monitoring their progress. 
Instead they assert that it is the Government's responsibility to 
perform the required testing and identify the defects in the 
system. They also assert that it is the Government's 
responsibility 
to assist in analyzing the defects. Based on 
their correspondence and actions during GT &E, they see their 
responsibility as fixing the defects identified by the 
Government. Therefore, they have indicated that they do not 
have ownership of achieving objectives of the contract. 
Finally, it is the Government's position that AEon does not 
have the capability to achieve the contract requirements 
within a reasonable time frame. With the combination of the 
number and severity of discrepancies between the rehosted 
MOCAS and as-is MOCAS, and AEon's lack of method for 
obtaining the MOCAS Rehost contract's objectives, 
the 
Government has no other option but to terminate the contract. 
36 "Representative testing" was described by government tester Malthaner as "tak[ing] a 
handful of data and process[ ing] it through the system [so] you would not 
necessarily have a full range of what the [actual] data may be" (tr. 5/903). 
119 

(R4, tab 45 at 2-3; tr. 5/901-07; see also supp. R4, tab 106) 
109. A CM/SEI Kick-off meeting was held on 9 May 2007 with representatives of 
CM/SEI and DFAS PMO (app. supp. R4, tab 234; tr. 7/1166-67). Mr. John Foreman, a 
chief engineer at CM/SEI, was tasked with forming a 
team to perform the IT A 
(tr. 7/1153-54, 1157-58; app. supp. R4, tab 258 at 32). On 11May2007 the MOCAS 
Rehost ITA Weekly Status stated: 
9 May- SEI ITA Kick-off meeting held. SEI presented an 
[ITA] brief followed by DFAS PMO presenting a MOCAS 
Rehost Program historical background brief. In the afternoon, 
DF AS CP Operations provided SEI team with a system 
demonstration followed by an open discussion between SEI, 
CP Ops, TSO, DCMA, and PMO, including functional and 
technical staff involved in the GT &E. 
SEI presented 3 concerns: 
** DFAS PMO's attempt to limit scope to technical code 
audit may lead to expectations gap. 
* * Lack of access to AEon personnel may lead to 
incomplete/skewed evaluation. 
* * SEI' s use of an automated code analysis tool may not be 
sufficient and SEI may require additional technical resources. 
PMO and TSO both expressed concern that SEI was still 
indicating the intention to review/evaluate 
information/evidence that was not necessary (in our opinion) 
for the desired technical assessment (i.e. review of the 
Contract/Mods to determine if AEon met the terms of the 
Contract, review of the Congressional inquiries, etc.) SEI did 
respond that their output would provide DF AS with enough 
technical detail as requested to be able to make an informed 
program decision. 
(App. supp. R4, tab 234 at 1-2) On 10 May 2007 the following guidance was provided by 
DF AS TSO relative to information to be provided to CM/SEI for use in its performance 
of the ITA: 
Below is guidance when providing SEI with documentation, 
artifacts, or resources for their IT A. If asked to provide 
something not covered in one of the lists, please let me know 
120 

or send it through me or [COR Thrower]. Thank you for your 
help and assistance. 
Documentation/ Artifact/Resource allowed list: 
* All AEon SLCM document deliverables 
* All AEon IPRIPSR reports and supplemental notes 
* All (3) TSO code review evaluation reports 
* Access to DF AS/DCMA functional/technical staff 
* AEon RFP proposal 
* Statement of Work 
*Access to/copy of PM O's TDR tracking database 
*Access to/copy of CP Ops' Test Logs database 
*Access to/copy ofDCMA's Test Logs database 
* Access to SUPRA/MANTIS DB MS/code 
* Access to DB2/CICS/COBOL RDBMS/code 
Documentation/Artifact/Resource not allowed list: (until 
justification provided or appropriately sanitized) 
*All REA related documents/emails 
*All Congressional inquiry related documents/emails 
*All Cure/Show Cause related documents/emails 
* Access to current AEon management staff 
* Access to current AEon technical staff 
* Access to former AEon staff: Mike Krajnak, Jim Conerly 
*Access to former AEon staff: Phil Cramer, Scott Love, 
Aaron Martin 
* Access to AEon' s Test Director database 
* Original Contract and Contract Mods 
*Access to AEon's Source Safe project repository 
* Permission to contact: TMGi, NP Gen, CSC 
(App. supp. R4, tab 234 at 3) (Emphasis added) With respect to CM/SEl's concerns 
quoted above, CM/SEl's Foreman testified that: 
When we do an independent technical assessment ... we 
were trying to be an honest broker, which means that we try to 
look at as many facets of an issue as we possibly can, because 
that is the charter of SEI and FFRDC, not to be biased one 
way or the other, and to tell as much truth as we can possibly 
find. 
121 

The concern that was being raised here was that 
nothing other than -- well, one conversation that we had with 
folks was them trying to understand that we would be broad 
and to look at issues beyond just the technical code quality 
into how would the project move ahead, and continue, and 
those kinds of things. 
And then there was times where DF AS seemed that 
they only wanted to have us look and work on a code audit. 
Well, if you want the truth as to the quality of the code, you 
also have to look at how it was developed, and how the teams 
work together, and how the government was managing it, and 
a bunch of other things, especially if you are going to ask the 
question what do I do with this .... 
[T]here was some attempt to restrict access to talking 
to AEON folks, and when we do an IT A, we typically will try 
to talk with the government folks, as well as the development 
contractor, because you have to get a 
total picture of what is 
gomg on. 
[The restriction on access to individuals and 
documents] is probably where we started to have some [of] 
our own concerns about this particular [IT A]. 
(Tr. 7/1168-70) 
110. On 22-24 May 2007 CM/SEI conducted 21 staff interviews and began 
artifact (i.e. documentation, database design, source code, etc.) review and analysis 
(app. supp. R4, tabs 240, 258 at 2; tr. 7/1179-80, 1236-39). 
Interviews were conducted with AP Operations and DCMA 
testers, TSO and DCMA technical personnel, PMO and AEon 
personnel. SEI was provided with requested artifacts, to 
include copies of the MOCAS As-Is and AEon's rehosted 
code. Their plan is to perform artifact and code review and 
122 

analysis over the next several weeks with a proposed report 
date of30 June 2007. 
(App. supp. R4, tab 255) Neither 
CO Gladski nor CO Gomolak were interviewed nor 
otherwise contacted by CM/SEI in the course of its performance of the ITA (app. supp. 
R4, tab 242; tr. 2/303-04, 326-27, 711171). 
111. On 25 May 2007 the government issued unilateral Mod. No. P00015, a stop 
work order 
for 90 days under FAR 52.242-15 (R4, tab 3 at 926-29, tab 46). The attached 
letter stated: 
As indicated in our May 22, 2007, telephone 
conversation, a stop-work order is a contractual mechanism 
for addressing interim contractor status prior to a 
termination 
decision. 
In that same conversation, I extended an opportunity to 
AEon for DF AS to consider additional matters prior to 
making a termination decision. 
Given the different positions concerning the reasons 
for the failure to successfully complete the MoCAS Rehost 
project, before making a final termination decision DF AS is 
willing to meet with AEon to explore whether an outcome is 
possible that avoids a protracted dispute between the parties. 
(R4, tab 3 at 926-27, tab 46; tr. 1/139, 2/197-99) On 29 May 2007 AEON 
acknowledged 
receipt of the stop work order and "accept[ ed the] offer to host a meeting to discuss the 
different positions of the parties regarding the status of contract performance and the 
Government's termination considerations" (R4, tab 47). The only evidence in the record 
on this subject indicates that the meeting was convened but was not attended by AEON; 
instead an individual characterized as a lobbyist came to the meeting in AEON's place 
(tr. 2/180-81). 
112. The MOCAS Rehost SEI ITA Weekly Status reported that from 11-15 June 
2007: 
123 

[AEON President and CEO] S.Javid contacted SEI and 
offered to meet with SEI (also offered D.Overby and 
J.Conerly). After her meeting, she requested to know the 
nature of SEI's tasking. SEI concurred with the PMO's 
direction that she has no right or need to this information and 
is not to provide any information. They will comply. 
(App. supp. R4, tab 255) CM/SEI's Foreman testified that whether or 
not the contents of 
an IT A are shared with a contractor is entirely the decision of the agency who engaged 
CM/SEI's services. 
When we do an [IT A] the out-brief goes to the sponsor. It 
does not go to the contractor or anybody else that is involved. 
It only goes to the sponsor because they are the ones that paid 
for it. 
.. .I think that everybody kind of knows that the rules 
are that we are not going to show the out-brief to the 
contractor, unless the sponsor asks for the contractor to be 
there. 
(Tr. 7/1173-74) 
113. On 18 June 2007 the PMO determined that AEON's responses to the 
government's concerns were inadequate, that AEON had demonstrated its inability to 
deliver the contractually-required Rehosted MOCAS and recommended to the CO that the 
contract be terminated for default (tr. 5/1104-07; R4, tab 48). 
114. On 16 July 2007 CM/SEI presented its ITA (dated 28 June 2007) in the form 
of a slide briefing to DFAS (app. supp. R4, tabs 258, 264; tr. 7/1156, 1175-76, 1210).37 
The record contains notes (author not identified) of the briefing and states that 
representatives from "MOCAS Rehost PMO, DF AS Contracting, DF AS General Council 
[sic], DFAS Operations, TSO, and DCMA were in attendance" (app. supp. R4, tab 264). 
CO Gomolak was in attendance at the briefing (tr. 2/327-29, 353). CO Gladski testified 
he was not aware of, nor present for, the briefing by CM/SEI (tr. 1/143, 2/168-76; 
app. supp. R4, tab 272). However, the record establishes that CO Gladski was aware of 
the existence of the CM/SEI briefing no later than 19 July 2007 when he requested a 
37 Mr. Foreman testified that a few days before this briefing CM/SEI did an out-brief 
"for an executive committee" ofDFAS in Washington, DC (tr. 7/1176, 1208-09). 
124 

"soft" copy; he was informed by COR Hecker at that time that the PMO did not have one 
and that the PMO had "rejected the content" of the briefing and had asked CM/SEI to 
redo the briefing without the programmatic, as opposed to the technical, findings 
(app. supp. R4, tabs 272, 283). According to the PMO: 
The goal of the [Rehost] program was to simply get MOCAS 
on a platform that was maintainable, THEN, enhancements 
could be incrementally introduced by [the government 
workforce] [see finding 2]. Judgments on why DoD chose 
this path [were] not within the scope of our SOW [with 
CM/SEI]. 
(App. supp. R4, tab 283 at 3) CM/SEI declined to amend its briefing as it considered 
both technical and programmatic findings inherent in its ITA process (app. supp. R4, 
tab 283; tr. 7/1220-22, 1232-34). In its ITA, CM/SEI assumed that DFAS would continue 
the MOCAS rehost project "in some form" (app. supp. R4, tab 258 at 6-7, 21-28, 31), 
however, from our review of CM/SEI's findings and recommendations it is apparent that 
CM/SEI believed that the approach to the project going forward should be significantly 
different from the approach taken in the existing 
contract. In particular, CM/SEI stated 
repeatedly that it believed the government should "follow a 
risk-managed modernization 
approach to upgrade MOCAS," that included significant involvement by the government 
throughout the process, rather than the incremental re-host approach taken in the existing 
contract (app. supp. R4, tab 258 at 30, tab 264 at 1). In CM/SEI's opinion the hands-off 
approach taken by the government created a lack of collaboration/cooperation in the 
creation of the Rehosted MOCAS and, because of this position taken by CM/SEI, it stated 
that the government contributed to the "current ... mess" (app. supp. R4, tab 258 at 30; 
tr. 7/1205-06, 1211-15). We find that CM/SEI's technical findings and recommendations 
regarding whether the Rehosted MOCAS delivered by AEON met contract requirements 
is relevant. However, we find that CM/SEI's recommended programmatic collaborative 
approach was very different from the rehost contract and fixed-price, hands-off approach 
the government had specifically decided to take in the existing 
contract and the approach 
that AEON specifically proposed to accept based on what it presented as its experience 
with exactly the work and terms contained in the contract as awarded (findings 7-8). We 
therefore find that CM/SEI's recommendations of a different approach going forward are 
irrelevant to our determination of whether AEON was in default of the terms of the 
contract it executed and which is now at issue. 
115. CM/SEI found in its summary that neither the As-Is MOCAS (referred to as 
the "Legacy System") nor AEON's Rehosted MOCAS were "ready to move into the 2151 
century" (app. supp. R4, tab 258 at 30). The summary included the following chart 
showing how the As-Is MOCAS compared to AEON's Rehosted MOCAS and how both 
125 

systems compared to the average of 70 systems previously tested by CM/SEI using its 
SQAI tool: 
~,.... ... 11 .... 
am8ir~ A'llAlllt .............. ............ 
hdilr 
cm·•q 65..5'1. M.O'I. 24..0% 
lld!paldl!ID! 71lA'lo 13.,5,;, G.S'lt 
.... ..., l:l.3'ti 33.0'I. ... O'll. 
~ .. 7..5'1. 7.0'll. 12.0'll. 
51!1FD1!5Qiplil BIE!515 65..7'1. 16,5,; 27.0'll. 
Jmlliily Caflol 53.3' 20.,5,; X.O'll. 
Ol!5i!Pt Sinpli;il)' 95..n. '2.5,; SZ.O"A. 
_., Allillllllll 
llllilllilillillliliil/ 6!l1'1o 225,; 32..0"A. 
E'l'lllWilDilily 72.4'1. 16.,5,; 35.0'll. 
POdillililr 71.5'1. 16,5,; 35.5% 
Dl!!ScliplH mess ~ 16.5'1. ,~ 
(App. supp. R4, tab 258 at 31; tr. 7 /1204-05) The summary further stated in response to 
the government's specific requests when engaging CM/SEI (finding 94): 
Determine whether the MOCAS re-host project is salvageable 
and maintainable 
• Portions of the re-host project may be 
salvageable but this is not recommended 
• The re-host project is not maintainable 
Determine if the MOCAS re-host project code is adequately 
functional and usable 
• The current re-host configuration renders it 
unusable due to the differences between the 
legacy (hierarchical) database and the new 
relational database 
• This renders the re-host system non-functional 
in its present form 
126 

Identify areas of the system that may need re-work 
• Re-host code naming conventions, data element 
usage, displays, error handling, and return code 
errors require Government intervention to 
resolve issues in system 
• A new Integrated Product Team (IPT) 
should be 
created 
Determine resources appropriate for completing the MOCAS 
re-host project and the difficulties that may be encountered 
• Depends on the modernization approach used 
and available human and financial resources 
• Resources should include IPT members, such as 
stakeholders, government and developer 
contractors 
• Improved program office insight and oversight 
Estimate how long it will take to complete the MOCAS 
re-host project 
• Dependent on the Program Office following 
recommended technical approach 
• Rough estimates show between 24 and 36 
months to achieve a transitioned, operational 
system 
• Create a Program Objective Memorandum 
(DoD PPBS) for out-year funding and 
continuing modernization 
(App. supp. R4, tab 258 at 29-30; tr. 7/1241-44) Project Manager Castrillo testified: 
127 

[I]t was mainly a tutorial how it could have been done better . 
... [W]e were looking at where do we go from here 
more so than where had we been, and it didn't really give us 
any, you know, where do we go from here .... To me it was 
unfortunately just a bunch of interviews and somebody's 
opinion as to how things could have been done differently. 
I don't think it added much value, I mean it didn't 
really add any value . 
.. .I didn't ask for a program management review, I 
asked for a technical review. 
(Tr. 511108-10, 1114, 1120-21) The record contains notes from the CM/SEI briefing, 
apparently authored by unidentified government personnel, stating: 
~ Key observations made by SEI: 
• Rehost was not built 
on a mirror image of Production, 
limiting AEon' s capability to perform integration 
testing. The PMO commented on the fact that AEon 
had control over the configuration of the development 
environment and could have created the appropriate 
environment. 
• AEon did not due [sic] an adequate job of code testing 
and integration testing at the code level (i.e. between 
programs). 
• AEon' s test scripts were inadequate. 
• Testing was schedule driven and not event completion 
driven. 
• There was a lack of exit criteria for each phase. DF AS 
noted that the contract was event driven and that AEon 
defined the exit criteria. For each Milestone, AEon 
certified that they had completed all tasks required. 
This included a certification that the system was ready 
128 

to enter into GT &E. The Government could not 
validate AEon's certification until they went into 
GT&E. 
• AEon did not utilize the As-Is to get to know the 
system and fully build an automated test. 
---. [CM/SEI's] Recommendation 
• [CM/SEI] recommends that Rehost be scrapped 
and the project restarted from scratch. 
• Outdated Documentation was sited [sic] as a 
Programmatic Issue. Documentation should have been 
done first and reviewed to ensure it met the 
Stakeholders needs. If done in this sequence the 
project may have been more successful. [CM/SEI] 
recommends that if the project is redone, Legacy 
Documentation should be created first. Data flow, 
functional flow diagrams would be used to ensure it is 
recreated on Rehost system. The PMO commented 
that AEon indicated that this information could have 
been extracted using their conversion tool. 
• [CM/SEI] commented that 
Increment 2 of their 
approach would give you more bang for the buck. The 
[first] increment would rehost on a new platform, with 
some improvements (e.g. normalization) made. 
• SMEs need to be involved in developing the automated 
testing. 
---. [CM/SEI] indicated that it was possible to continue with 
the current Rehost code. However, it would require an 
extensive evaluation and they could not comment on how 
long it would take. 
(App. supp. R4, tab 264) (Received in evidence without objection). 
Although the information provided in the slides is interesting, 
it does not show a true assessment of our options. Instead of 
indicating why we should not continue (i.e. risks), they simply 
indicate that we should start over. 
129 

(App. supp. R4, tab 275) We find CM/SEI's recommended different approach going 
forward to be of little help in our consideration of whether the Rehosted MOCAS 
delivered by AEON met the terms of the contract it executed (app. supp. R4, tab 258, 
see also app. supp. R4, tab 264). 
D. Termination for Default and Appeal 
116. On 7 August 2007 CO Gladski prepared a Determination & Finding (D&F) 
in which he reduced to 
writing his analysis of FAR 49.402-3(f) factors and his ultimate 
decision to terminate the contract for default (supp. R4, tab 120; tr. 11140-42, 2/292-99). 
CO Gladski testified he did not consider anything from CM/SEI in reaching his decision 
to terminate the contract because he never received a report from them38 and the stop 
work order was going to expire on 23 August 2007 (tr. 11143, 21166-83; findings 111, 
114). 
117. On 9 August 2007 CO Gladski issued Mod. No. POOO 16 which terminated 
the contract for default under FAR 52.249-8, DEFAULT (FIXED-PRICE SUPPLY AND 
SERVICE) (R4, tab 3 at 930-35, tab 49; tr. 1140-41, 143-45, 2/164-65). 
The contract's amended delivery schedule ... required 
completion of performance through payment event 6 by 
September 25, 2006, to be followed by a 90-day User 
Acceptance I [GT &E] period . 
... DFAS has paid AEon in full the contract's liquidated 
performance based payment amounts that AEon would be 
entitled to for acceptable performance by and through 
payment event 6 code conversion, documentation and 
functionality testing events. However, the software converted 
by AEon failed to pass User Acceptance I GT &E during 
payment event 7, and AEon failed to adequately correct or 
cure all of the deficiencies identified in the DF AS Cure 
Notice. Those failures lead to this default termination .... 
38 We note that the last information CO Gladski had, according to the record before us, 
was that the PMO had rejected the content of the 28 June 2007 CM/SEI report and 
requested an amended briefing with just the technical findings and 
recommendations (finding 114). 
130 

Default termination is justified and appropriate because the 
rehosted 
MOCAS failed payment event 7 GT &E user 
acceptance testing due to clear lack of requisite functionality 
in critical areas. Under this fixed priced contract, the 
Government is not required to authorize or fund continued 
performance under payment event 7, nor is it appropriate to 
authorize initiation of payment event 8 performance. 
Performance-based payments through payment event 6 have 
been liquidated. 
I conclude that the performance failure was not beyond the 
control or without AEon's fault or negligence. Default under 
event 7 is the determinative issue. AEon has received 
liquidated payments for performance through payment 
event 6 .... 
After thoughtful consideration of all of the pertinent facts in 
conjunction with FAR 49.402-3(f), I, the undersigned 
Contracting Officer, hereby find and determine that AEon has 
failed to complete the requirements of the MOCAS Rehost 
contract within the time required by the terms of the contract, 
failed to successfully cure some items identified in my Cure 
Notice, and that AEon failed to deliver a Rehosted MOCAS 
database with the requisite functionality of the MOCAS 
"as-is" database as prescribed by the SOW. 
(R4, tab 49, iii! 2, 3, 9-11; tr. 2/184-86) At the time of the termination for default by 
CO Gladski, the government had approved AEON's performance-based progress 
payments in the amount of$12,905,117.22 39 (R4, tab 49; tr. 1/153-54; finding 21). 
CO Gladski further testified that the performance-based progress payment 
events/milestones were not subCLINs of CLIN 00001 and that, upon AEON's failure to 
deliver the contractually required CLIN 00001, the previously liquidated 
progress 
payments became unliquidated: 
If the contractor failed to deliver, then any of those 
previous items that I had liquidated, after obtaining legal 
counsel on this, determined that it didn't matter. 
39 The parties do not dispute the amount paid to AEON under the contract. 
131 

That I would be entitled to recover that if the 
contractor failed to deliver the full system because I was 
accepting the CLIN on a 
whole, and not on a piece basis. 
(Tr. 11146, 154-56) As of the close of the record before us there had been no 
reprocurement of the MOCAS Rehost project and the existing As-Is MOCAS was still in 
use (tr. 2/232-33, 310, 4/687). 
118. In a letter dated 13 August 2007 AEON filed its notice of appeal from the 
termination for default which was docketed as ASBCA No. 56142 (R4, tab 50). 
119. On 9 November 2007, three months after the termination for default, 
CO Gladski issued a second final decision in which he stated: 
2. The contract provided for performance-based payments 
under "Performance-Based Payments," FAR 52.232-32 (FEB 
2002). In the event of default, the contractor is obligated to 
repay payments that were not liquidated based on conforming 
delivery item performance. Under this contract, all 
performance based payments were made on a whole contract 
basis. FAR 52.232-32( d). 
3. DF AS has not been delivered a workable rehosted 
MOCAS System that contains the same functionality of the 
present MOCAS System. I have determined that, AEon did 
not successfully complete contract work defined by 
CLIN 0001 for which they received payments identified in 
events #I through #7 as delineated in contract 
HQ0423-04-C-0003. There has been no acceptance of 
CLIN 0001. Therefore, demand is hereby made upon The 
AEon Group, LLC, to pay DFAS the sum of$12,905,l 17.22 
which represents all payments made to date by DF AS for 
contract HQ0423-04-C-0003. 
(Supp. R4, tab 122; 
tr. 11146-47) 
120. In a letter dated 15 November 2007 AEON filed its notice of appeal from the 
government's demand for repayment of alleged unliquidated performance payments 
which was docketed as ASBCA No. 56251. 
121. On 5 March 2009 AEON submitted its REA No. 3 in which it sought 
compensation in the amount of $1,531,701 for government-caused delays to its 
132 

performance of contract work from 29 September 2006 through 25 May 2007 (app. supp. 
R4, tab 285). There is no indication in the record that the government provided any sort 
of response to REA No. 3 and it is not before us in these appeals. 
122. During the government's case-in-chief, counsel for appellant promised that 
the testimony of various witnesses would be offered in its own case-in-chief to rebut 
certain of the government's evidence. However, appellant offered no testimony from any 
individual involved in the preparation of AEON's proposal or AEON's performance of 
the contract (tr. 6/1139). The single witness offered by AEON in its case-in-chief was 
CM/SEI's Foreman, the head of the CM/SEI ITA team involved after all performance by 
AEON had stopped and who had no first-hand knowledge of anything that took place 
during the actual performance of the MOCAS Rehost contract (tr. 7/1254; findings 94, 
109). 
DECISION 
AEON appeals from the government's termination of its contract for default, 
asking us to hold that the termination was not justified and to convert it to a termination 
for the convenience of the government (ASBCA No. 56142). AEON further requests 
that, even if we uphold the termination for default, we find the government is not entitled 
to the return of performance-based payments made to AEON in the amount of 
$12,905,117.23 (ASBCA No. 56251). 
I. ASBCA No. 56142-Termination for Default 
A termination for default is a type of forfeiture and is strictly construed. Lisbon 
Contractors, Inc. v. United States, 828 F.2d 759, 764 (Fed. Cir. 1987). The government 
bears the burden of proving that its termination of AEON's contract was justified under 
the terms of the contract. Ensil International Corp., ASBCA Nos. 57297, 57445, 12-1 
BCA if 34,942 at 171,800. If the government has met its burden, the contractor has the 
burden of going forward to prove any allegations that its default was due to causes 
beyond its control or without its fault or negligence. ADT Construction Group, Inc., 
ASBCA No. 55358, 13 BCA if 35,307 at 173,309. 
A. Grounds for Termination for Default 
The Default clause of the contract, FAR 52.249-8, FIXED-PRICE SUPPLY AND 
SERVICE (APR 1984), establishes the possible grounds for a termination for default which 
include failure to deliver by the contractual due date and failure to make progress so as to 
endanger timely performance (finding 25). In the 9 August 2007 termination for default, 
CO Gladski articulated the following reasons' for the termination: 
133 

After thoughtful consideration of all of the pertinent facts in 
conjunction with FAR 49.402-3(f), I, the undersigned 
Contracting Officer, hereby find and determine that AEon has 
failed to complete the requirements of the MOCAS Rehost 
contract within the time required by the terms of the contract, 
failed to successfully cure some items identified in my Cure 
Notice, and that AEon failed to deliver a Rehosted MOCAS 
database with the requisite functionality of the MOCAS 
"as-is" database as prescribed by the SOW. 
(Finding 117) In a second final decision dated 9 November 2007, CO Gladski restated 
his determination 
that AEON had failed to deliver a contractually-compliant Rehosted 
MOCAS by the contract delivery date and further demanded that AEON return 
$12,905, 117 .22 in what he determined to be unliquidated performance-based payments 
(finding 119). 
AEON argues that the government has failed to meet its burden of proof as to the 
grounds for the termination for default which were articulated in the CO's final decisions 
and, further, that we cannot consider grounds other than those specifically articulated in 
the final decisions (app. br. at 5, 49-53). We find AEON's argument that we may not 
consider the government's allegedly later-articulated basis of failure to make progress to 
be unavailing for two reasons. First, while the CO's final decisions do not specifically 
use the term "failure to make progress," they do specifically cite FAR 52.249-8 as the 
authority under which the termination was made. That clause includes both failure to 
meet the contract's delivery date and failure to make progress so as to endanger timely 
performance. Further, the CO's final decision terminating the contract for default 
specifically articulated that a basis for the default was AEON's failure to "successfully 
cure some items identified in my [22 March 2007] Cure Notice" (findings 95, 117). A 
Cure Notice is only required to be issued prior to a termination for failure to make 
progress. FAR 52.249-6(a)(2). It is not required prior to a termination for failure to make 
timely delivery. Further, the express language of the Cure Notice states: 
If, at the end of the GT &E period, AEon still has failed to 
deliver a code which meets the functionality requirements 
contained in the SOW, the Government will have "failure to 
deliver" as an additional ground for termination for default. 
(Finding 95) (Emphasis added) Clearly, the Cure Notice put AEON on notice that the 
government was considering two bases for termination for default: failure to make 
progress and failure to deliver by the contractual delivery date. 
134 

Second, even if the government had not articulated two bases for default 
termination, it is well-established that an unarticulated basis that is supported by the 
totality of the circumstances existing at the time of the termination is valid. 
Our decisions have consistently approved default 
terminations where the contracting officer's ground for 
termination was not sustainable if there was another existing 
ground for a default termination, regardless of whether that 
ground was known to the contracting officer at the time of the 
termination. See, e.g., Kelso v. Kirk Bros. Mech. Contractors, 
Inc., 16 F.3d 1173, 1175 (Fed. Cir. 1994) ("This court 
sustains a default termination if justified by the circumstances 
at the time of termination, regardless of whether the 
Government originally removed the contractor for another 
reason."); Joseph Morton Co. v. United States, 757 F.2d 1273, 
1277 (Fed. Cir. 1985); Pots Unlimited, Ltd. v. United States, 
220 Ct.Cl. 405, 600 F.2d 790, 793 (1979) ("[I]t is settled law 
that a party can justify a termination if there existed at the 
time an adequate cause, even ifthen unknown."). Thus, the 
subjective knowledge of the contracting officer .. .is irrelevant, 
and the government is not required to establish that the 
contracting officer conducted the analysis necessary to sustain 
a default under the alternative theory. 
Empire Energy Management Systems, Inc. v. Roche, 362 F.3d 1343, 1357 (Fed. Cir. 
2004 ). We will therefore consider the totality of the circumstances existing at the time of 
the termination in reaching our determination of whether the termination of the MOCAS 
Rehost contract 
for default was justified. 
The express contract terms unambiguously require that delivery of CLIN 0001, 
Rehost MOCAS System, began when AEON presented the Rehosted MOCAS system to 
the government for 90 days of GT &E functionality testing and that delivery was not 
complete until the end of the second 90-day GT &E period in which the Rehosted 
MOCAS 
was put into production and passed the government's production testing. 
Thereafter, the government had 30 days to accept or reject 
the Rehosted MOCAS that had 
been delivered (findings 17, 18).40 The contract also expressly provided that: "At any 
time prior to final acceptance, any discrepancy between the functionality of the rehosted 
MOCAS and the as-is MOCAS, or any other failure to meet the requirements of this 
solicitation, may be a basis for rejection" (finding 18) (emphasis added). The parties 
4° CLIN 0003, Repairs, was never exercised (finding 10) so any time allotted to it in the 
contract is irrelevant to the matters before us. 
135 

disagree as to the level of completion of the Rehosted MOCAS that was required to be 
delivered at the beginning of GT &E and what was to take place thereafter. 
The government takes the position that, while it expected minor issues of a 
"cosmetic" (finding 78) nature to arise during GT &E functionality testing, AEON was 
required to deliver for GT &E the Rehosted MOCAS, fully tested and certified by AEON 
as fully compliant with the contract requirement of 100% functionality, i.e. that the 
Rehosted MOCAS delivered for GT&E was to perform exactly like the existing As-Is 
MOCAS (findings 2, 14-15, 55, 71, 86). The record reflects that, at the time it delivered 
the Rehosted MOCAS for GT &E, AEON certified it to be a Rehosted MOCAS fully 
compliant with the contract requirements (findings 77, 89, 93, 115). The government 
contends that, contrary to AEON's certification, the Rehosted MOCAS delivered for 
GT &E did not perform exactly like the As-Is MOCAS as defined in the contract 
(finding 14). 
AEON disagrees with the government as to 
what was required by the contract to 
be delivered for GT &E. First, despite its written words of certification to compliance 
with the contract definition of 100% functionality, AEON seized upon its own 
non-contractual definition of 100% functionality, its counsel even claiming the contract 
did not define functionality (finding 87). By its own non-contractual definition, AEON 
argues that the Rehosted MOCAS delivered by AEON for GT &E was 100% functional 
because the system contained every function category. AEON posits that the presence of 
a function is all that is required, arguing that there could not be defects in a function if the 
function did not exist in the system, and that whether a function actually worked is 
irrelevant (findings 85, 87). The government in its brief analogized AEON's definition of 
"100% functionality" as follows: 
[By AEON's definition], the system did not have to 
"function" at all. All the 
parts just had to be present. So, for 
instance, if the Government had been purchasing an 
automobile instead of a rehosted MOCAS, it would have 
"100% functionality" if all of its parts were present, engine, 
drive train, frame and body, even if it could not start or drive. 
If a test were performed and indicated the pistons were there 
but could not be made to go up and down, in accordance with 
Appellant's arguments, the automobile would still have 
"100% functionality." 
(Gov't hr. at 90) 
In direct contrast to appellant's arguments in this regard, the contract includes, as 
did the Solicitation before it, a lengthy definition of the functionality the Rehosted 
136 

MOCAS was to possess in order to meet contractual requirements. The contractual 
definition clearly expresses that the Rehosted MOCAS was to perform exactly like the 
As-Is MOCAS in every way possible and we have so found. (Finding 14) Further, the 
record contains ample evidence that AEON understood that this was the definition of 
functionality to which it was required to perform (findings 7-8, 55, 71). We find AEON's 
arguments in this appeal to the contrary unpersuasive and reject them. 
AEON next argues that, regardless of the definition of functionality, it is 
unreasonable to find that it was required to deliver a Rehosted MOCAS with 100% 
functionality at the beginning of GT &E (app. br. at 57-59). It is clear to us from the 
record that GT&E was a final inspection by the governrnent of the Rehosted MOCAS to 
assure that 
it met contract requirements by functioning exactly like the As-Is MOCAS 
before the system was rolled out and put into production for world-wide use by DF AS, 
DCMA and other governrnent agencies (see, e.g., findings 4, 5, 18, 79, 100, 101, 106). It 
follows logically that the Rehosted MOCAS delivered at the beginning of GT &E was to 
be AEON's final product which was certified by it to fully meet contract requirements. 
Further supporting the interpretation that the delivered Rehosted MOCAS was to perform 
at 100% functionality compared to the As-Is MOCAS is the contractual requirement that 
the final documentation for the Rehosted MOCAS was also to be submitted at the 
beginning ofGT&E (findings 2, 4, 10, 14, 15, 18, 19, 49, 52-55, 71). AEON's arguments 
that the contract required it to deliver a less-than-100%-functional Rehosted MOCAS 
would redefine GT &E to nothing more than a testing/QC exercise prior to AEON's 
completion of the contract requirements. Pre-GT&E testing and QC were specific 
contract requirements to be completed by AEON, not the governrnent, and they were to 
have been completed by AEON prior to delivery of the Rehosted MOCAS. (Id.) 
Submission of defective items to the governrnent for acceptance as a method of a 
contractor quality control program is not an acceptable practice. Skip Kirchdorfer, Inc., 
ASBCA Nos. 32637, 35074, 91-1 BCA ~ 23,380 at 117,314, ajf'd, 944 F.2d 912 
(Fed. Cir.) (table), cert. denied, 502 U.S. 1033 (1992). 
On the basis of the foregoing, we hold that the Rehosted MOCAS delivered for 
GT &E was required by the express contract terms to be fully tested 
and certified by 
AEON to meet contract requirements, including the contract requirement for 
100% functionality such that the Rehosted MOCAS delivered for GT &E by AEON was 
to perform exactly like the As-Is MOCAS, no better and no worse. 
AEON delivered the Rehosted MOCAS to the government for GT &E twice: once 
in October 2006; and, again in January 2007. On 22 September 2006, just before its 
initial delivery of the Rehosted MOCAS for GT&E, AEON's "final" PMP stated 
AEON's understanding and intent that the Rehosted MOCAS: 
137 

[W]ill have all the functionality, produce the same output and 
will look, feel and respond to the users exactly as it does 
today. Therefore the users will not recognize that the system 
has been touched. In addition, all interfaces will provide the 
same data in the same format. 
(Finding 71) (Emphasis added) On 23 October 2006 AEON delivered the Rehosted 
MOCAS to the government for GT &E functionality testing and certified that the 
Rehosted MOCAS met contract requirements (finding 77). As had been made known 
since before contract award, the As-Is MOCAS was 
used as the benchmark against which 
the Rehosted MOCAS was tested (finding 6). After just nine (9) days ofGT&E 
functionality testing, it was apparent to the government testers, individuals from DF AS 
and DCMA with many years of As-Is MOCAS experience (finding 80), that the Rehosted 
MOCAS delivered by AEON did not perform like the As-Is MOCAS and GT&E 
was 
suspended (findings 81, 82). 
AEON argues that the government had no right to suspend GT &E. The 
government argues that AEON was in technical default of the contract and that it would 
have been justified in terminating the contract for default at that time (gov't br. at 92-93). 
As we have already held, the failure of the Rehosted MOCAS to perform exactly like the 
As-Is MOCAS was a failure to meet contract requirements and the contract's express 
terms provided for rejection of the Rehosted MOCAS at any time between delivery and 
final acceptance that it was determined it did not meet contract requirements (finding 18). 
Nevertheless, the government gave AEON the opportunity to continue work on the 
Rehosted MOCAS to make it perform exactly like the As-Is MOCAS. On 19 January 
2007 AEON again delivered the Rehosted MOCAS to the government for GT &E 
functionality testing and again certified that it met contract requirements (finding 89). 
The government proceeded to continue performance of GT &E, however, the government 
testers again experienced numerous failures of the Rehosted MOCAS to perform even 
basic functions like the As-Is MOCAS. At the conclusion of the full 90-day GT &E 
functional testing period, the government had only been able to test approximately 46% of 
one database (identified as the least complex of the three databases (MOCs) contained in 
the Rehosted MOCAS delivered by AEON (finding 100)) and was never able to perform 
a full end-to-end test of the system (findings 89-90, 93, 95, 97-102). On this basis, we 
find unpersuasive AEON' s argument that the number of defects identified at the end of 
the GT&E period was evidence of the functionality of the entire Rehosted MOCAS 
(app. br. at 59-65). CO Gladski issued the 25 April 2007 Show 
Cause Notice advising 
AEON that it had "failed to perform ... within the time prescribed" and that, as of 11 April 
2007, the end of the 90-day GT&E functionality testing period, the Rehosted MOCAS 
database "still does not perform significant basic system functionalities" (finding 104). 
The independent evaluation of the Rehosted MOCAS performed by CM/SEI after the 
138 

Show Cause Notice confirmed that the delivered Rehosted MOCAS was not functional, 
was not maintainable and was "unusable" (finding 115). 
AEON also argues that CO Gladski's decision to terminate the contract was 
arbitrary and capricious because he did not specifically consider the CM/SEI report 
(findings 114-16; app. br. at 4-5). As we stated above, in reaching our decision as to the 
propriety of the termination for default we consider the totality of the circumstances 
existing at the time of the termination, whether the CO had subjective knowledge of them 
or not. In this regard: 
[W]e are less concerned about the label of the contracting 
officer's action so long as, in fulfilling his duty, the 
contracting officer exercised reasoned judgment and did not 
act arbitrarily .... 
"[A] court's review of a default justification does not turn on 
the contracting officer's subjective beliefs, but rather requires 
an objective inquiry." McDonnell Douglas XII, 323 F.3d at 
1016. In this regard, the facts in the record are sufficient for 
the court, in a de novo review, to sustain the default 
termination. See Joseph Morton Co. v. United States, 757 
F.2d 1273, 1277 (Fed. Cir. 1985) ("It is settled law that a 
party can justify a termination if there existed at the time an 
adequate cause, even ifthen unknown."). 
McDonnell Douglas Corp. v. United States, 567 F.3d 1340, 1354-55 (Fed. Cir. 2009). 
The record before us amply supports the government's decision to terminate the contract 
on the ground that AEON failed 
to deliver a Rehosted MOCAS that met contract 
requirements and we find no evidence to support appellant's allegation 
that the decision 
was arbitrary and capricious. 
On the basis of the foregoing we find that AEON's failure to deliver for GT&E a 
Rehosted MOCAS that met contract requirements to perform 100% of the functionality of 
the As-Is MOCAS constituted a failure to make timely delivery under the contract and we 
find that the termination of the contract for default was justified on this basis. 
DayDanyon Corporation, ASBCA No. 57611 et al., 14-1BCAiJ35,507 
(no contract-compliant delivery by the due date is primafacie evidence of default). We, 
therefore, need not reach the additional basis of termination for default for failure to make 
progress such that timely completion was put out of AEON's reach. 
139 

B. AEON allegations that the default was without its fault or negligence 
Having held that AEON was in default, we now tum to arguments made by AEON 
in support of its allegation that its default was excused because it was without AEON's 
fault or negligence (app. br. at 65; FAR 52.249-8(c)). Appellant has the burden of 
proving that its default was actually caused by its alleged excuses. Beekman 
Industries, Inc., ASBCA No. 30280, 87-3 BCA ~ 20,118. 
1. Defective Specifications 
AEON argues that it conducted "adequate," "robust and time-consuming testing" 
and that there is no evidence that it did otherwise. Yet, it also claims the opposite: that it 
was unable to do adequate testing due to defective specifications. (App. br. at 53-55, 
66-6941 ) The record does not support appellant's allegations on either count. 
The government expressed its concerns that the failure of the Rehosted MOCAS to 
perform exactly like the As-Is MOCAS was apparently due 
to inadequate 
contractually-required testing on AEON's part (findings 47, 81, 93, 108; gov't br. at 
65-68). We understand the government's argument to be that, had AEON actually done 
the testing it claims to have done, AEON should have discovered the same problems 
during its QA/Test that the government discovered during GT &E; problems that AEON 
then should have corrected before delivering 
the Rehosted MOCAS for GT &E and 
certifying that it met the contract requirement of 100% functionality. We note that 
nowhere in the record before us does AEON claim, much less actually demonstrate, that 
the problems discovered by the government during GT &E did not occur when AEON 
performed its own tests. We must 
conclude then that, for the depth and breadth of 
problems encountered in GT &E to have occurred as demonstrated in the record before us, 
AEON either did not adequately test the Rehosted MOCAS before delivering it or it 
tested it, experienced problems and, desperate for payment (discussed further below), 
certified and delivered it for GT &E anyway. 
Further, contrary to its argument in this appeal (app. br. at 56), the 
contemporaneous record shows that when AEON made the internal decision to no longer 
perform unit testing in June 2005, all indications are that it did so to make up for the 
extended time taken to convert the code after the TMGi tool failed to perform as 
anticipated (findings 46, 47, 57, 59). It did not notify the government at that time that it 
was no longer doing the unit testing which was required by the contract (findings 16, 21, 
41, 49, 56) and included by AEON in its own PMP (finding 55). Only later, after 
requesting an extension of time within which to complete its contractually-required 
41 We note that AEON's arguments in this portion of its brief contain relatively sparse 
supporting citations to the record. 
140 

QA/Test and responding to the government's query as to the reason for the extension, did 
AEON take its current position that unit testing was impossible without detailed design 
specs (app. br. at 55). We find this to be in direct contrast to AEON's own demonstrated 
understanding on 9 November 2005 when it stated in writing to the government that: 
For conversion projects such as MOCAS Rehost there usually 
are no 
business or systems requirements and no design or 
program specifications. Further, the programs are partially or 
fully converted using a tool. 
(Supp. R4, tab 68 at 2) (Emphasis added) Even though AEON expressed its 
understanding in writing that it was not usual to have design or program specifications in 
a project such as this one, in the case of the Rehosted MOCAS contract, AEON was 
provided with a copy of the full As-Is MOCAS, including the full production data 
existing at the point in time the copy was made, as well as a discovery period so AEON 
could determine 
the specific functionality of the As-Is MOCAS in order to replicate it in 
the Rehosted MOCAS. The specification information AEON now claims was missing 
was exactly the information that AEON proposed, and the contract required and paid 
AEON, to discern in the discovery period of the contract (findings 6, 12, 21, 31-35, 108). 
We have considered the following: (1) AEON's own expressed understanding in 
projects such as this that the specifications it now claims were missing were not usually 
provided, nor apparently were they needed where a conversion tool was used like AEON 
proposed to and did use here; (2) that AEON was provided with a full copy of the As-Is 
MOCAS and given time and compensation to fully explore it (findings 3, 10, 12, 14); and, 
(3) that both AEON (for its QA/Test (findings 16, 55)) and the government (for GT&E 
(finding 6)) intended to use the As-Is MOCAS as the "benchmark" against which the 
Rehosted MOCAS would be tested. We find no support for AEON' s argument that 
performing the contractually-required testing was impossible due to defective 
specifications. 
2. Superior Knowledge 
AEON argues that the government possessed two categories of information 
essential to AEON's performance of the contract work that it did not provide to AEON: 
documentation in the form of detailed existing specifications; and, the government's test 
plans (app. br. at 69-70). In order to prevail on a claim of superior knowledge AEON 
must prove the following elements: 
( 1) [It undertook] to perform without vital knowledge of a 
fact that affects performance costs or duration, (2) the 
government was aware [it] had no knowledge of and had no 
141 

reason to obtain such information, (3) any contract 
specification supplied misled [it] or did not put it on notice to 
inquire, and ( 4) the government failed to provide the relevant 
information. 
CAE USA, Inc., ASBCA No. 58006, 13 BCA ii 35,323 at 173,390. 
With respect to the first category of alleged superior knowledge (documentation in 
the form of detailed existing specifications), AEON cites to the testimony of John Sharer 
that he had been "creating design specification changes on a regular basis for 25 years," 
from which AEON implies that the government possessed detailed specifications for the 
As-Is MOCAS 
and knowingly withheld such specifications as part of the documentation 
of the As-Is MOCAS misleading AEON as to their existence (app. br. at 69). AEON's 
argument fails to mention, however, that immediately after the testimony it cited, 
Mr. Sharer continued upon cross-examination by AEON counsel: 
Q And you have an understanding then that the 
detailed specification for MOCAS are current? 
A No, the paperwork is not current, the paperwork 
for MOCAS is not current. The system is basically over 40 
years old, and during that time a lot of the changes that were 
made and everything, the paperwork on them were lost. 
Q Right, you understand that DF AS does the best 
job it can to update its baseline specification, correct? 
A As we make changes we try to baseline what 
changes we are making, but no, as I am right now we do not 
have a good set of baseline documentation for the whole 
MOCAS system. 
(Tr. 5/984) Mr. Sharer's testimony is consistent with the record evidence of repeated 
representations made by the government in the solicitation, contract and during contract 
performance that the existing documentation for the As-Is MOCAS was incomplete 
(findings 1, 5, 12, 14, 15), that all documentation in the government's possession was 
provided to AEON (finding 12), and that AEON understood these conditions and based 
its proposal upon them (findings 7-8). The fact of incomplete/poor existing 
documentation was why the government provided, at significant expense, a full 
production copy of the As-Is MOCAS to AEON (finding 3), paid AEON to perform 
significant discovery of the As-Is MOCAS (findings 10, 12), and paid AEON to provide 
documentation for the Rehosted MOCAS (findings 10, 19). We find ample support in the 
142 

record that AEON was aware at the time of its proposal that the existing documentation 
of the As-Is MOCAS was not something that could be relied upon (findings 7-8). In 
Bruce E. Zoeller, ASBCA No. 56578, 13 BCA i! 35,353 at 173,521-22, we held that, 
where the contractor was aware of the risk when it entered into the contract and where it 
has "failed to show evidence that the contract specifications misled [it] or did not put [it] 
on notice to inquire, as required by the superior knowledge doctrine," the contractor will 
not have met its burden of proof. Likewise, we find here that AEON has not met its 
burden of proof with respect to the first category of alleged superior knowledge. 
The second category of superior knowledge alleged by AEON is that the 
government withheld its GT &E test plans from AEON. Neither the solicitation nor the 
contract stated that the test plans would be provided to AEON (finding 20). In fact, 
AEON was specifically on notice that the government's test plans would not be provided 
(findings 2, 6). Rather, the contract required AEON to perform its own QA/Test and to 
develop its own test plan and test scripts (finding 16). AEON proposed to do so with the 
knowledge that the government's test plans would not be provided (findings 7-8). We 
therefore find that the government's test plans were not vital knowledge necessary to 
AEON's performance of the contract work and, therefore, AEON has not met its burden 
of proof with respect to the second category of alleged superior knowledge. 
3. Lack of Good Faith and Fair Dealing 
Both parties to a contract have a duty of good faith and fair dealing that neither 
will conduct themselves in a way that will hinder or delay the contractual performance of 
the other and failure to fulfill that duty constitutes a breach of contract. Metcalf 
Construction Co. v. United States, 742 F.3d 984, 991 (Fed. Cir. 2014). However, the 
implied duty may not "expand a party's contractual duties beyond those in the express 
contract or create duties inconsistent with the contract's provisions." Id. 
AEON alleges that the government failed to meet its duty of good faith and fair 
dealing in several respects: (1) the government did not provide subject matter experts 
(SMEs) to assist AEON; (2) the government's suspension ofGT&E resulted in financial 
hardship for AEON; (3) DCMA was not involved in the contract until GT&E; (4) the 
government allegedly "reneged on its agreement to restart GT &E" as quickly as AEON 
wanted; (5) the government "violated" its GT &E test plans by not meeting with AEON 
regularly during GT &E; ( 6) the government failed to provide to AEON an alleged list of 
"what works" in the Rehosted MOCAS; and, (7) the CM/SEI report found that the lack of 
a collaborative approach by the government had contributed to AEON' s failure to deliver 
a contractually-compliant Rehosted MOCAS (app. br. at 70-76). 
Allegations (1) and (3)-AEON's post-hearing brief opens with counsel's 
accusation that the government "[p ]reyed on the inexperience and un-sophistication of 
143 

a small business performing its first federal Government contract" (app. br. at 1). 
However, in its proposal AEON held itself out as very experienced in exactly the kind of 
work sought to be performed under this contract and listed 11 previous contracts, six in 
detail, including several performed for DFAS (finding 7). Later in contract performance, 
AEON stated that its employees/subcontractors had more depth of understanding of the 
MOCAS system than DFAS' own TSO (finding 72). Nevertheless, AEON now 
complains that the government breached its duty of good faith and fair dealing by not 
providing AEON with SMEs, especially DCMA SMEs, during 
contract performance. 
The record shows, however, that AEON and all other prospective bidders were put on 
notice that they would not 
have SMEs available to assist in performance of the contract 
(finding 6) and neither the solicitation nor the contract contain any representation 
otherwise. AEON's proposal demonstrated its understanding of this fact, analyzed the 
risk and included "several million dollars" in its proposal to cover this and other risks it 
had identified. AEON's proposal also specifically stated that it believed it had made 
staffing decisions that further minimized this risk. (Finding 8) 
Allegations (2) and (4}-AEON claims that the government's suspension of 
GT &E created financial hardship for it. The first instance of financial difficulty reflected 
in the record is in the spring of 2006 when AEON missed a payroll and was not paying its 
subcontractors (finding 62). This was approximately six months before GT &E was 
started in October 2006 and certainly before GT &E was suspended in November 2006. 
The weight of the record indicates that AEON's financial troubles originated when its 
TMGi conversion tool proved to not perform as planned, which impacted AEON's 
scheduled performance and delayed conversion of the code and unit testing which had a 
domino effect on later performance milestones and payment events which followed 
conversion (findings 30, 43, 57). AEON proposed the eight performance-based payment 
events to provide it with a payment of 12.5% of the contract price for CLIN 0001 (or 
$1,856, 164.50) approximately once every quarter throughout the original two-year 
performance period. AEON was originally scheduled to complete Payment Event 6 
(code conversion and unit testing) and receive payment at the end of the 5th quarter of 
performance (approximately July 2005). (Finding 21) However, the record shows that, 
because of the TMGi issues and related delays, the tasks associated with Payment Event 6 
took almost two years and were not reported complete until 11 October 2006 (findings 30, 
41-49, 59). The government was not responsible for the TMGi issues and the first time 
AEON notified the government that AEON's schedule was slipping was in October 2005 
(finding 45). The delays associated with the code conversion and any unit testing 
performed (or not performed) caused AEON to be unable to report completion of 
Payment Event 6. Without completion of the Milestone/Payment Event, AEON could not 
seek payment for an extended period of time, during which employees and subcontractors 
were not paid (findings 51, 58, 62), a situation which prompted the government several 
times to agree to allow the Milestone/Payment Events to be further subdivided in order to 
get funding to AEON (findings 49, 63, 
65, 70). AEON first delivered the Rehosted 
144 

MOCAS to the government for GT &E functionality testing in October 2006, certified that 
the Rehosted MOCAS met contract requirements and requested payment for Payment 
Event 7 A2 (finding 77). However, after just nine (9) days of GT &E functionality testing, 
the government testers determined that the Rehosted MOCAS delivered by AEON had so 
many significant problems that GT &E was suspended (findings 77, 81-84 ). Nevertheless, 
the government gave AEON time to correct the deficiencies in the Rehosted MOCAS and 
re-certify and re-deliver it when AEON determined it to be ready for GT &E to 
recommence (findings 84). Upon AEON's notification of readiness in January 2007, we 
find that the government took a 
reasonable amount of time to gather the government 
testers to continue GT &E (findings 88-89). While the record shows that the government 
took responsibility for 3Yz weeks of delay prior to GT &E (finding 66), the vast majority 
of the many months of delay described above were attributable to AEON, not the 
government. 
Allegation (5}-AEON's arguments in this regard appear to us to take the position 
that the GT&E process was somehow an extension of the contract's QA/Test phase to be 
performed by AEON. In this context, AEON argues that the government should have 
worked with AEON as a testing partner during GT &E, keeping AEON in constant 
communication as to the tests run and the results on a daily basis. We disagree. AEON's 
obligation under the QA/Test phase of the contract was to fully test the Rehosted 
MOCAS against the As-Is MOCAS to make sure the Rehosted MOCAS functioned just 
like the As-Is MOCAS. This phase was to be completed prior to AEON certifying that 
the Rehosted MOCAS met the contract requirement of 100% functionality and delivering 
the Rehosted MOCAS to the government for GT &E functionality testing by experienced 
government users ofthe As-Is MOCAS. (Finding 16) GT&E was to be performed solely 
by the government (finding 18) and we find that any testing done by the government 
under GT &E was in the nature of a final inspection and was for the government's benefit, 
not AEON's. Therefore, whether the government followed or did not follow its test plans 
to the letter, the government had no contractual obligation or duty to AEON in that 
regard. AEON had no contractual role in the GT &E process except to the extent the 
government elected to make it aware of any results. We find no contractual obligation on 
the part of the government to permit AEON to attempt correction during the GT &E 
period of deficiencies discovered in GT &E. To the extent the government did so, we 
consider it to be reasonable attempts on the government's part to mitigate the impact of 
AEON's failure to provide a Rehosted MOCAS that performed exactly like the As-Is 
MOCAS. 
Allegation (6}-The record does not contain the "what works" document 
referenced by AEON. The first mention of the possible existence of such a document was 
at the hearing and there was no indication at, prior to or since the hearing that AEON 
requested such a document in discovery or moved to compel the production of such a 
document, if it even existed. The record contains ample evidence of significant portions 
145 

of the Rehosted MOCAS that did not work, resulting in a failure of the Rehosted 
MOCAS to meet the contractual requirement that it perform exactly like the As-Is 
MOCAS. Because the contractually-required 100% functionality was not achieved, it is 
immaterial whether 5% or 50% or some other unidentified percentage less than 100% of 
it did work. 
Allegation (7)-We previously found that CM/SEI's programmatic 
recommendations as to type of contract and conduct of contract administration were 
inconsistent with the contract now before us and, therefore, irrelevant to our consideration 
of the rights and obligations of the parties under the contract executed by AEON 
(finding 114). The government has broad discretion in determining what type of contract 
will best promote its interests. American Tel. and Tel. Co. v. United States, 307 F .3d 
1374, 1379 (Fed. Cir. 2002). Here the government determined 
that a firm-fixed-price 
contract would best suit its goals for the Rehosted MOCAS. AEON submitted a 
firm-fixed-price proposal to perform the solicited work. One of the hallmarks of a 
firm-fixed-price contract is that the government is not to interfere with a contractor's 
performance of the contract work, particularly where there are performance specifications 
(see findings 3, 47) because the method of performance is a factor in cost incurrence 
which is at the contractor's risk, not the government's: 
[I]n a cost-reimbursement contract, the Government retains 
the right to minimize its risk by supervising closely the 
contractor's performance. By performing the ... contract on a 
fixed-price basis, [the contractor] avoided the costs of more 
intrusive government supervision. These tradeoffs between 
Government oversight and contractor autonomy are 
fundamental to any agreement on price or contract type. 
Moreover, unlike money, these bargained for rights are not 
reallocable after performance .... 
. . . The proper time ... to have raised the issues ... was at 
the time of contract [formation], when effective remedy was 
available. 
American Tel. and Tel., 307 F.3d at 1381. As the Court stated in American Tel. and Tel., 
we are "not inclined to change the rules and the scoring after the game has been played." 
Id. 
146 

On the basis of the foregoing, we find that AEON has failed to meet its burden of 
proving that its default of the contract is excused by any of its seven (7) allegations of a 
lack of good faith and fair dealing by the government. 
4. Alleged Failure to Upload Fixes 
AEON argues that it had corrected every defect identified by the government in 
GT &E, but the government failed or refused to upload the corrections to the Rehosted 
MOCAS (app. br. at 76-77). The government counters that it was AEON's responsibility 
to upload any corrections (gov't br. at 42) and that all corrections were loaded and tested 
for several weeks after the end of the contractual GT&E period which resulted in even 
more deficiencies (finding 99; gov't reply br. at 26-28). Regardless of who was 
responsible for uploading corrections near the end of the GT&E period, the weight of the 
evidence demonstrates that any corrections made were in response to deficiencies 
identified by the government in GT &E. Since the government was only able to test 
approximately 46% of the one least complex database of the three databases in the 
Rehosted MOCAS, we find that any corrections late in the GT &E period would not have 
changed the fact that the majority of the Rehosted MOCAS had not been able to be tested 
in GT &E. We further find that there is no basis in the record before us to believe that the 
untested majority of the Rehosted MOCAS would have somehow miraculously sailed 
through 
GT &E without problems. 
C. Summary 
On the basis of the foregoing, we find that the government was justified in 
terminating the contract for default for the failure of AEON to deliver a Rehosted 
MOCAS that met contract requirements and that AEON has failed to meet its burden of 
proving that its default was excused. 
IL ASBCA No. 56251-DF AS Demand for Alleged Unliquidated Performance-Based 
Payments 
In a second final decision dated 9 November 2007, three months after the 
termination for default, CO Gladski demanded repayment by AEON of all 
performance-based payments paid to it under the contract in the amount of 
$12,905,117.22: 
2. The contract provided for performance-based payments 
under 
"Performance-Based Payment," FAR 52.232-32 (FEB 
2002). In the event of default, the contractor is obligated to 
repay payments that were not liquidated based on conforming 
delivery item performance. Under this contract, all 
147 

performance based payments were made on a whole contract 
basis. FAR 52.232-32(d). 
3. DF AS has not been delivered a 
workable rehosted 
MOCAS System that contains the same functionality of the 
present MOCAS System. I have determined that, AEon did 
not successfully complete contract work 
defined by 
CLIN 0001 for which they received payments identified in 
events # 
1 through #7 as delineated in contract 
HQ0423-04-C-0003. There has been no acceptance of 
CLIN 0001. Therefore, demand is hereby made upon the 
AEon Group, LLC, to pay DFAS the sum of $12,905,117.22 
which represents all payments made to date by DF AS for 
contract HQ0423-04-C-0003. 
(Finding 119) AEON 
appeals from the government's demand for the return of all 
performance-based payments made under the contract. The government has the burden of 
proving its claim for repayment of alleged unliquidated performance-based payments. 
Commissioning Solutions Global, LLC, ASBCA Nos. 57429, 57494, 13 BCA ii 35,355 at 
173,527. 
When a contract is terminated for default, FAR 49.402-2(a) provides that: "the 
Government is not liable for the contractor's costs on undelivered work and is entitled to 
the repayment of advance and progress payments, if any, applicable to that work." The 
Rehosted MOCAS contract provided for advance payments in the form of 
performance-based payments as proposed by AEON (finding 21). Further, 
performance-based payments are the preferred method of contract financing. They are 
"contract financing payments that are not payment for accepted items," and are "fully 
recoverable, in the same manner as progress payments, in the event of default" 
(finding 23). FAR 52.232-320) provides that 
"[b]ecause performance-based payments 
represent the accomplishment of milestones and not the achievement of CLINs, the 
Government may demand that the Contractor •repay to the Government the amount of 
unliquidated-performance[-]based payments"' (app. br. at 78). What the parties dispute is 
whether the performance-based payments made to AEON were liquidated or 
unliquidated. 
It is the government's position that none of the performance-based payments made 
to AEON were liquidated because all performance-based payments were made to AEON 
on a 
whole contract basis given that CLIN 0001, the Rehosted MOCAS, was the single 
priced deliverable in the contract (gov't br. at 22-23, 31, 101-07). AEON argues that the 
performance-based payments made to it were made on a deliverable item basis and were 
liquidated when paid (app. br. at 80). 
148 

The FAR defines deliverable items for the purpose of performance-based 
payments as: 
Financing payments to be made on a deliverable item basis 
are applicable to a specific individual deliverable item. (A 
deliverable item for these purposes is a separate item with a 
distinct unit price. Thus, a contract line item for 10 airplanes, 
with a unit price of $1,000,000 each, has 10 deliverable 
items-the separate planes. A contract line item for 1 lot of 
10 airplanes, with a lot price of $10,000,000 has only one 
deliverable item-the lot.) 
(Finding 23) The MOCAS Rehost contract contained one deliverable, CLIN 0001, with 
one price. There was no contractual basis for delivery or acceptance of something less 
than the complete CLIN 0001 (finding 10). Further, the performance-based payments 
were based on the total contract price for CLIN 0001 which accounted for all but $50,000 
(for a 
non-deliverable CLIN for government-ordered travel) of the $14,849,316.00 
contract price. They did not include payment for any tasks other than those identified 
with CLIN 0001. (Finding 
21) Nevertheless, AEON argues that the enumerated tasks 
associated with the Milestones/Payment Events (see findings 21, 49) were separate 
deliverables, and therefore the payments were made on a deliverable item basis 
(app. br. at 77-84). We cannot agree as there was no contractual delivery date, nor 
contract price associated with the various Milestones/Payment Events. On the basis of 
the foregoing, we find that the performance-based payments were made on a whole 
contract basis. 
The contract provided that if the performance-based payments were made on a 
whole contract basis, liquidation was to be by either predesignated liquidation amounts or 
a liquidation percentage (finding 22). It is undisputed that the contract contained no 
liquidation schedule (finding 21 ), nor do we find any mention of liquidation anywhere in 
the solicitation, AEON's proposal or the contract and its modifications. The government 
argues that no liquidation schedule was required because there was only one deliverable, 
one delivery date and one item to be accepted or rejected, so there was no basis for 
liquidation prior to the government's acceptance of CLIN 0001. (Gov't reply br. at 
38-42) AEON argues that, in the absence of a liquidation schedule, we must find that, as 
each performance-based payment was made, there was a commensurate amount of 
liquidation (app. br. at 79-80). The contract, however, provided in FAR 52.232-32(c)(3) 
that: "[t]he approval by the [CO] of a request for performance-based payment does not 
constitute an acceptance by the Government and does not excuse the Contractor from 
performance of obligations under this contract" (finding 22). Given the absence of 
something in the contract to demonstrate a meeting of the minds of the parties on the 
149 

subject of sequenced liquidation as argued by AEON, we find that the only reasonable 
interpretation is that the payments would not be liquidated until the one deliverable was 
accepted by the government. 
AEON also points out that, in the first CO's final decision terminating the contract 
for default, CO Gladski stated multiple times that the payments made under the contract 
were liquidated; but, in the second final decision demanding the return of the payments, 
CO Gladski specifically 
stated they were not liquidated. Given the inconsistency, AEON 
argues that the government should be bound by the first final decision. It is 
well-established that our findings and determinations are de nova. England v. Sherman R. 
Smoot Corp., 388 F.3d 844 (Fed. Cir. 2004); Wilner v. United States, 24 F.3d 1397, 1402 
(Fed. Cir. 1994) (en bane); Assurance Co. v. United States, 813 F.2d 1202, 1206 
(Fed. Cir. 1987). We reject AEON's argument that, presented with the CO's inconsistent 
determinations of liquidation, that it may pick and choose the one determination it likes. 
We are also not persuaded by AEON's final argument that the government is not 
entitled to the return of performance-based payments made to AEON prior to 9 January 
2006 because the release language 
contained in Mod. No. P00006 closed the door on any 
claims by either party based on events that occurred prior to that date (app. br. at 83). We 
have found that the liquidation or non-liquidation of the performance-based payments 
was dependent upon whether or not the government accepted CLIN 0001. Under the 
contract, acceptance could not take place prior to the performance of 180 days of GT &E 
(finding 18), which could not have occurred prior to 90 days after the 10 April 2007 end 
of the 90-day GT&E functional testing period (findings 18, 89, 99), or 21July2007. 
However, the Rehosted MOCAS, CLIN 0001, delivered by AEON for GT &E failed to 
pass the 90 days of GT&E functionality testing and there was no acceptance of 
CLIN 0001. We find that the earliest possible date the government knew it was not going 
to accept CLIN 0001, and the performance-based payments were unliquidated, was 
10 April 2007. This was the event upon which the government's claim of repayment of 
performance-based payments was based and it did not occur prior to 9 January 2006. 
Therefore, the release language in Mod. No. P00006 is irrelevant to the government's 
claim in ASBCA No. 56251. 
On the basis of the foregoing we find that the performance-based payments made 
to AEON during contract performance were made on a whole contract basis and would be 
liquidated only upon acceptance of CLIN 0001 by the government. As AEON' s delivery 
of a Rehosted MOCAS, CLIN 0001, was rejected by the government and there was no 
acceptance, the government was entitled to demand repayment from AEON of 
unliquidated performance-based payments in the amount of $12,905, 117 .22. 
150 

CONCLUSION 
AEON's appeal from the termination for default is denied (ASBCA No. 56142). 
AEON's appeal from the government's demand for repayment ofunliquidated 
performance-based payments in the amount of $12,905,117.22 is also denied (ASBCA 
No. 56251). 
Dated: 6 August 2014 
I concur 
Adminis ative Judge 
Armed ervices Board 
of Contract Appeals 
I concur 
&MARK~N. STEMP~LE~R~ ·--~-~ __ f: ____ f~~-\............+--+~-+---/1-~ --... MONROE E. FREEMAN, JR.Jrf 
Administrative Judge Administrative Judge 
Acting Chairman Acting Vice Chairman 
Armed Services Board Armed Services Board 
of Contract Appeals of Contract Appeals 
I certify that the foregoing is a true copy of the Opinion and Decision of the Armed 
Services Board of Contract Appeals in ASBCA Nos. 56142, 56251, Appeals of AEON 
Group, LLC, rendered in conformance with the Board's Charter. 
Dated: 
151 
JEFFREY D. GARDIN 
Recorder, Armed Services 
Board of Contract Appeals