Second Amended Complaint - Page
Second Amended Complaint - Page
John B. Hughes, Chief of the Civil Division, U.S. Attorney’s Office in Connecticut, quoted in
March 25, 2009 U.S. Department of Justice press release, “Sikorsky Aircraft Pays $2.9
Million to Settle False Claims Act Allegations,” available at
http://www.usdoj.gov/opa/pr/2009/March/09-civ-273.html, attached hereto as Exhibit O.
“The United States alleged that from 1991 to 2006, Sikorsky knowingly installed armored
plates . . . that had not been ballistically tested as required under the contract.” Id. "This
settlement sends a message that fraud, especially when it concerns the safety of our men
and women in uniform, cannot and will not be tolerated in Government contracts," said
Michael F. Hertz, Acting Assistant Attorney General for the Department of Justice’s Civil
Division. "As demonstrated here, the Department . . .[is] committed to rooting out such
fraud and prosecuting it." Id. 1
1 See also, e.g., “Northrop Agrees to Pay $325 Million to Settle Suit,” by Andy Pasztor, Wall Street Journal,
April 3, 2009, available at http://online.wsj.com/article/SB123871451033784579.html, attached hereto as
The United States of America, by and through qui tam Relator, Sylvester Davis,
brings this action under 31 U.S.C. §§ 3729-3732 (the “False Claims Act”) to recover all
damages, penalties and other remedies established by the False Claims Act on behalf of
the United States and himself and would show the following:
PARTIES
and a resident of the State of Texas. He was an employee of Defendant Lockheed Martin
Maryland corporation with its principal place of business at 6801 Rockledge Drive,
Bethesda, MD 20817. More relevant to the events herein, is the Lockheed Martin
Corporation offices located at 1 Lockheed Street, Fort Worth, Texas 76108. Through such
offices, the relevant Joint Strike Force Program and other similar programs were managed
in relevant part. The software development process, its quality control and its compliance
evaluations for the F-35 and other programs occurred under the auspices of these offices.
Lockheed’s agent for service of process is Frances J. Frizzell, 6801 Rockledge Drive,
Bethesda, MD 20817.
3. Jurisdiction and venue are proper in this Court for the following reasons:
a. Jurisdiction for this Court exists pursuant to the False Claims Act (31 U.S.C.
§ 3730(b)(1) and 31 U.S.C. § 3732(a)), because Relator’s claims seek
Exhibit P: “In a release Thursday [April 2, 2009], the Justice Department said that investigators concluded that
between 1992 and 2002, TRW [which was acquired by Northrop in 2002] ‘failed to properly test parts’ and
‘made misrepresentations’ to the government about their reliability.”
GENERAL BACKGROUND
services in the United States and internationally. Its aeronautics segment produces military
aircraft, including the relevant F-35 Joint Strike Fighter and the F-16 Fighter, F/A-22 Air
Dominance, Attack and Combat Aircraft, C-130J Tactical Airlift Aircraft, C-5 Airlift Aircraft,
and the F-117 Stealth Fighter. There are a number of acronyms that are utilized
throughout the Complaint and a list of those acronyms and their definitions is attached as
shipboard, land and airborne applications. The Electronic Systems’ products include
missiles and fire control systems, air and theater missile defense systems, surface ship and
marine combat systems, anti-submarine and undersea warfare systems, radars, platform
security and information technology (IT) solutions, simulation and training systems, and
systems, both airborne and missile defense technologies, fleet ballistics missiles and
launch services.
segment in this False Claims Act case. That segment develops, integrates and manages
net-centric solutions. The segment also provides technology in the areas of software and
Technology Services also offers engineering, science and information services, research,
8. Recognizing the increasingly critical role software plays in its systems, the
DOD established the Software Engineering Institute to advance the practice of software
engineering and to help ensure software is produced on schedule, on budget and to the
highest quality standards. SEI is a federally funded research and development center
sponsored by the DOD through the Office of the Undersecretary of Defense for Acquisition
and Technology. The SEI management contract was competitively awarded to Carnegie
professionals from government, industry and academia. The SEI mission is to provide
9. The Lockheed Martin Software Safety Working Group, established during the
Concept Development Phase (CDP) and including representatives from U.S. and U.K. software
suppliers, defined the software safety certification process known in the Air System Software
Development Plan (“AS SDP”) as Safety Evidence Assurance Levels (SEALs) along with the
corresponding process elements to achieve the required safety assurance. SEAL requirements
were added to the AS SDP in version 2 on April 24, 2002. SEAL describes the category
of required evidence needed to assure stakeholders that the system is sufficiently safe.
SEALs are for components that collaborate to fulfill requirements (e.g., architecture,
design, coding, testing). Therefore, the lower the SEAL level the more activities you have to
perform and documentation you have to create in order to provide Evidence Assurance that
10. SEAL can trace it roots to the DO-178B and is related to it in both definition
and purpose. Section 2.2, of DO-178B defines the software level. The software level,
11. The “Condition” indicated in the table is the result that will occur if a “Level” x
item is not mitigated. For example, if a Level A risk is not mitigated it will cause
12. You could also make a convincing argument that the SEAL requirements as
described in the AS SDP satisfy the requirements of MIL STD 882D as it relates system
13. Either way the necessity of the practices described in Appendix C of the AS
SDP cannot be disputed. Just as SEI has replaced DoD-Std-2167 as it relates to the
concepts and principles of DO-178B/MIL STD 882D. Therefore saying that SEAL is
not necessary for a military aircraft would be the equivalent of saying that DO-178B
is not necessary for commercial aircraft. As described in the Joint Strike Fighter (JSF)
Air System (AS) Software Development Plan (SDP) SEALs are derived from the AS Hazard
Risk Index (HRI). The HRI determines the SEAL level in the same way that the condition
“C.2.3 SEAL 1
This level of assurance is required for hazards that have a HRI that lies in the range
1 to 3. This range is sometimes referred to as ‘safety critical’. These hazards are
normally under the full control of software. Failure of the software item leads directly
to a hazard’s occurrence. Since the HRI lies in this range, there are additional
activities required in order to ensure that there is the highest level of confidence that
the safety goals have been achieved. “
14. It is important to note that section C.3.2 of the AS SDP states “Software of
different SEALs must not be mixed in the same address space. Architectural design must
ensure that software of different SEALs is kept physically apart, preferably using an
operating system with computer hardware support.” This means that if one application
within the same address space is not following SEAL 1 process; for example, Flight Control
Redundancy Management (FCRM) which resides within the Flight Control System; then the
entire system which includes Flight Control Application, (FCA), and Air Data (ADA) is not
residing within the same address space does not alleviate another application from
The same principle applies to SEI requirements for the same reasons; the applications
16. Compliance to SEI level 4 and SEAL 1 is a two step process. Step 1, is to
define a process in the Software Development Plan (SDP), which if followed would produce
SEI and SEAL 1 compliant software. Step 2 is to follow the process while developing the
software and generate the documents which will validate that the process defined in the
SDP was followed. Documents include but are not limited to Software Product Evaluation
(SPE) data, unit and formal test cases and reports, and metrics. If step 1 is not performed,
step 2 is irrelevant.
compliance to SEI and SEAL 1 standards is not merely alleged, it is a documented and
admitted fact by Lockheed Martin. On two occasions; April 6, 2004 and July 28, 2004; the
Lockheed Martin Software Management Team (SMT) determined that the FCA IPT
software was not being developed in an SEI and SEAL 1 compliant manner. See Exhibit
M, April 6, 2004 Rejection, and Exhibit N, July 28, 2004 Rejection. The software crash
of the System Integrity Manager (SIM) software which occurred November 3, 2004 also
18. In their December 17th 1999 press release announcing the Lockheed Martin
Tactical Aircraft Systems earning SEI level 4 status, Lockheed Martin stated
19. The Defendant has published guidelines for any Software developed by
development:
All software relevant to this Qui Tam is characterized as SEAL 1 (Safety Critical, the
Lockheed Martin Aeronautics that had been merged into the organization made May 1,
2002 Philip C. Gould, Senior Manager, Software Process Branch, Software Engineering
Center, Lockheed Martin Aeronautics Company announced the decision to standardize the
division on the existing Fort Worth Software development process which consist of:
The rationale given in the presentation was “process known to produce Level 4 behavior
when properly implemented.” See Exhibit C, One Company, One Team …Coast to
Coast.
21. As part of the stated Single Process Initiative (SPI) he indicated that all
existing US military contracts would be modified to invoke CBM 4004 and indicates that
presentation, PM 4001, which is the source of SEI level 4, provides the working level details
for CBM 4004. This establishes a direct contractual link between SEI and the JSF
program.
Worth Division representatives with being required to comply with SEI, he recounts what
would be excuses used by the Defendants to not comply which the same requirements that
by the Defendants:
within Lockheed Martin as indicated in this presentation, the Defendant acknowledged that
the excuses that would be given for not complying with SEI and SEAL 1 requirements on
the JSF program are not valid and have no merit. It further demonstrates Lockheed Martin’s
propensity to promote for its own benefit processes and procedures that it was not
following.
26. The District Court is requested to take judicial notice of the Defendant’s vast
experience in military contractor projects and its awareness of the appropriate standards
and protocols by which it is expected to perform services for the benefit of the United
States of America. Further, the District Court is requested to take judicial notice of the
several False Claims Act cases in which this same Defendant has been required to pay
27.. While Relator’s primary focus herein has been upon the Defendant’s FCA
violations regarding the ongoing F-35 Program, Relator has also provided notice, not later
than March 2006, to the DOJ and its associated federal agents and attorneys in this case
about Defendants’ plant-wide failures to develop and test software products according to
required SEI and SEAL I, II and III, where required by contract with the U.S. Relator
disclosed, first internally to Defendant, that it was not performing its software development
and testing obligations for any of its military contracts under the required SEI and SEAL
standards. Defendant, while recognizing Relator with an award for bringing this important
compliance for the F-35 flight controls to address greater risks. See Exhibit D
attached hereto. However, Defendant paid only lip service to the problem and refused to
remedy the past corruption of software in its military contracts, nor did Defendant make the
necessary effort to implement the necessary changes in software development, testing and
compliance in order to comply with its obligation to the U.S. to ensure that software was
being developed, tested and in compliance with SEI and SEAL I standards on the F-35, F-
22 and other systems requiring such reliability levels for software products. Thus, the
Program. The national, if not international, defense is now at risk, as a result of the
Defendant’s corrupt software development performance for the F-35 Vehicle Systems.
Other systems, such as the F-35 Mission Systems, have reportedly suffered similar
28. The F-35 JSF Program is a joint program with no lead service; that is, it is
staffed by Air Force, Navy and Marine Corp personnel. The Program Executive Officer
position alternates between the Departments of Navy and Air Force, and that person
JSF Information
29. The Joint Strike Fighter (JSF) Program, formerly the Joint Advanced Strike
Technology (JAST) Program, is the Department of Defense’s focal point for defining
affordable, next generation strike weapon systems for the Navy, Air Force, Marines and a
growing number of U.S. allies, all of whom remain uninformed regarding this corrupt
weapons system. The focus of the program is affordability – reducing the development
cost, production cost and cost of ownership of the JSF family of aircraft. Lockheed is the F-
35 prime contractor, while Northrop Grumman and BAE Systems are principal partners in
the project.
strike fighter aircraft that will have a 70 to 90 percent commonality factor for all the variants,
operational aircraft was anticipated for fiscal 2008. That delivery did not occur as
31. During the current Systems Development and Demonstration (SDD) phase
awarded October 26, 2001, the program was supposed to be focused upon developing a
family of strike aircraft that significantly reduces lifecycle cost, while meeting the operational
affordability, lethality, survivability and supportability. The program will use a phased block
approach that addresses aircraft and weapons integration and provides a validated and
verified air system for the Service Initial Operational Capability requirements.
32. During SDD, the team planned to build a total of twenty-two (22) test aircraft.
Fourteen (14) were proposed to undergo flight testing, seven were to be used for non-
airborne test activities, and one was to be used to evaluate the F-35’s radar signature
[stealth].
33. Final assembly of the F-35 will take place at Defendant’s location in Fort
Worth, Texas. Northrop Grumman Corporation in Palmdale and El Segundo, California will
manufacture the center-fuselage and the aft fuselage, and tails will be manufactured by
BAE systems in Samlesbury, England. Defendant in Fort Worth will manufacture the
34. Flight-testing will be conducted at Fort Worth, Edwards Air Force Base, and
Naval Air Station Patuxent River. Additionally, the STOVL and CV variants will undergo
sea trials aboard American, British and Italian aircraft carriers. First flight of the
Conventional Take-Off and Landing (CTOL) version of the aircraft was scheduled for the
35. The JSF program is intended to fulfill stated Service needs as follows:
complement F-A-18E/F;
c. U.S. Marine Corps STOVL aircraft to replace the AV-8B and F/A-18 as
d. United Kingdom Royal Navy & Royal Air Force STOVL aircraft to
36. The F-35 Program is managed via various Integrated Product Teams (IPTs).
37. The original project schedule for the various milestones was as follows:
International Partners
38. The mission of the International Directorate (ID) is to lead the integration of
international participation within the framework of the program office. The core JSF
(9) partner nations: United States, United Kingdom, Italy, The Netherlands, Turkey,
armaments cooperation and R&D and acquisition of weapon systems and defense
Cooperative Participation (SCP) approach with Israel and Singapore. Future opportunities
will be coordinated with the respective international Project offices within the Defense
Security Cooperation Agency, Air Force and Navy to ensure that the USG strategy for
40. The cumulative JSF Partnership Participation Cost contributed by the nine
partner nations exceeded $4.525 billion. In that regard, Israel and Singapore have also
41. The cumulative cost/value for the aircraft contemplated under the contract
exceeds $140.8 billion. With this sort of investment, honesty in the Defendant’s rendition of
services for payment by the government is critical, and that critical reliance by the United
42. The False Claims Act Complaint herein concerns the knowing and intentional
United States in connection with required standards for (1) software development, (2)
software testing and (3) software development process compliance, all of which has
defrauded the United States out of significant sums of money; likely, in the hundreds of
millions of dollars.
43. The JSF Software Management team reviews and approves all JSF Software
Development Plans (SDPs), reviews monthly metric data to ensure compliance to all
Lockheed Martin and JSF software process requirements. Approval of the SDP is the
representation of Defendant's compliance with all required: (1) software development, (2)
44. The JSF Software Management team in conjunction with AV IPT will review
and approve product SDPs for conformance to JSF-specific software development and
management, system safety, and system security engineering representatives must review
the product-level SDPs for content relating to their disciplines. These reviews will ensure
that:
acceptable.
45. A Prime Team SDP is also reviewed and approved by LM-Aero Software
Engineering Process Group (SEPG) except when such requirement has been waived.
46. The following is a hierarchy visual of the IPTs relevant to this case:
Air System
Air Vehicle
Vehicle Systems
WBS 1300
Flight Control
Application S/W
WBS 1332
System Integrity
Manger S/W
WBS 1333
Flight Control
Hardware
WBS 13334
48. The air system IPTs that are most relevant to this Qui Tam action include:
49. Air System Integration IPT. It is the mission of the Air System Integration to
establish and execute the framework and forums to accomplish program-wide integration
consistent with program visions statement. In working toward that goal the Air System
Integration team is responsible for ensuring all products and activities of JSF Program
50. Air System Engineering IPT. The Air System Engineering IPT will foster
In order to complete their mission the Air System Engineering team is responsible for:
Disciplines;
51. Air System Requirements IPT. Air System Requirements IPT centrally
manages Air System Requirements across the JSF program. The team is the owner of the
Air System Concept of operations, JSF Operational Requirements Document, Leader of the
JSF Operation Advisory Group, and is the owner of the Lethality Pillar. Overall the Air
Requirement Document.
Roadmaps;
52. The overall goal of the Air Vehicle is through teaming with the contractor to
production ready and sustainable JSF Air Vehicle within SDD cost and schedule for the
warfighter. The Air Vehicle Team accepts the total system performance and integration
responsibility for the JSF Air Vehicle that satisfies SDD production affordability/risk
53. The Air Vehicle System Engineering Integration IPT cuts across the Air
Vehicle to ensure integration at all levels. The team is also responsible for the following
IPT is responsible for a wide variety of systems in the air craft such as the Flight Control
System Hardware and Software; Utility Systems (Electrical, Thermal, Hydraulic, Landing
Arresting, Fuel, Fire Protect, Ice Detection, etc.); Onboard Vehicle Systems Processing
Vehicle Systems PHM Area Manager/Software; and the overall propulsion system
integration.
Systems IPT is responsible for all hardware and software required to process and convert
stick and throttle commands into effector (flaperons, ailerons, etc.) commands in order to
System Integrity Manager (SIM) IPT provides fault detection, isolation and annunciation to
the pilot for both the Flight Control and Air Data. Additional Flight Control Redundancy
PHM, Crash Survivable Memory Unit (CSMU) Manager, Ground Collision, Avoidance,
System and fault isolation during maintenance operations and ensure flight control systems
57. SIM IPT designs and develops the FCRM and Flight Control Initiated Built-In-
generates commands for the Air Vehicle control effectors, lift fan doors, nose wheel
steering, and commanded engine thrust and provides fault tolerant air data, correcting the
raw, sensed air data parameters, and computing the required standard air data parameters
59. The FCA SW IPT designs and develops the Control Law (CLAW) and Air
Data CSCIs.
60. Air Data (ADA) CSCI Overview. The ADA CSCI provides the current state of
the aircraft relative to the surrounding air mass, properties of the surrounding air mass and
61. The ADA correct the raw air data inputs, monitors the true air data inputs,
selects the best available air data inputs, and calculates the air data output signals.
62. The ADA CSCI primarily interfaces with the four Air Data Sensors (left & right
Multi-Function Probes and left & right Flush Ports) and the two other Flight Control
Applications (FCRM and CLAW). Its outputs are also consumed by the DMC (Display
63. A Multi-Function Probe is mounted on each side of the fuselage. Each probe
supports two sensor packages. The sensors packages proved measured static and total
pressure (Ps & Pt), and measured angle of attack (AOA). These raw Air Data parameters
are affected by various factors, including but not limited to: the placement of the probes on
the airframe, configuration of the air vehicle (open doors, externally loaded stores, etc.),
attitude of the air vehicle with respect to the surrounding air mass, velocities, turns,
rotations, etc. Thus, the raw Air Data parameters must be corrected using empirical data
from wind tunnel testing to obtain the true Air Data inputs. Each package also contains a
heating element. Each package produces a message that is transmitted through the
Vehicle System network to one of the VMCs. The transmitted messages are then Cross-
Channel Data linked to the other two VMCs; thus, each instantiation of the ADA has access
64. A Flush Port is mounted on each side of the fuselage. Each port supports two
sensor packages. The sensor packages provide measured static pressure (Ps). This raw
Air Data parameter is affected by various factors, including but not limited to: the placement
of the ports on the airframe, configuration of the air vehicle (open doors, externally loaded
stores, etc.) attitude of the air vehicle with respect to the surrounding air mass, velocities,
turns rotations, etc. Thus, the raw Air Data parameter must be corrected using empirical
data from wind tunnel testing to obtain the true Air data input. Each package also contains
a heating element. Each package produces a message that is transmitted through the
Vehicle System network to one of the VMCs. The transmitted messages are then Cross-
Channel Data linked to the other two VMCs; thus each instantiation of the ADA has access
65. The FCRM CSCI provides the attitude, performance and configuration data
needed by the ADA CSCI to perform corrections. It also provides and maintains the DST
(Device Status Table) information to perform the monitoring of the Air Data signals. This
information is required to perform the monitoring of the Air Data signals. This information is
required because the ADA CSCI does not maintain the status of all Air Data System
components from frame to frame of execution. The FCRM CSCI consumes the failure
66. The purpose of the CLAW CSCI is to stabilize the aircraft in all flight regimes
while allowing the pilot to direct the aircraft to achieve mission performance. The CLAW
method of control implements a feedback design using pilot inputs and sensor feedbacks to
compute effector commands. The software computations are inherently physics based
67. Relator, until very recent, had the Job Title in the JSF Program of “Software
Lead and Software Product Manager (SPM) for the JSF Flight Control Application (FCA)
Software Integrated Product Team (IPT)”. Relator’s job grade was: Embedded Software
68. Relator’s responsibilities were several. First, Realtor was responsible for
defining a software development process that met the overall objectives of the JSF
b. Joint Strike Fighter (JSF) Air System Software Development Plan (SDP); and,
Plan which would document the Flight Control Application (FCA) Software (SW) Integrated
70. Third, Relator was responsible for ensuring that all FCA SW IPT CSCI
software is developed in a manner compliant with all Lockheed Martin and JSF Program
71. Fourth, Relator was responsible for managing, technically, a staff of six (6)
engineers.
72. Fifth, Relator was responsible for performing and/or managing the following
activities:
(SRS) Document;
e. Configuration Management (CM) of all the FCA CSCI Software and their
h. Tool development;
n. Tool analysis.
73. It is in the conduct of these responsibilities that Relator became aware of the
initial oversights or disregard of the software process, testing and compliance review which
regarding the development of the software, the testing of the software and the compliance
of the process with the SEAL 1 and related standards regarding the F-35 Program and
others, including the F-22 and other software products on which such standards were
Introduction
by the Department of Defense (DOD). Prior to March 1995 software quality programs for
governed by DOD-STD-2168.
75. These documents described the software and quality processes for all
defense contracts involving software. If software was developed under a military contract
you were required to develop it in a manner compliant with these DOD standards.
76. With the evolution of commercial industry standards these military standards
became redundant and were cancelled. Currently the acquisition, development, or support
of mission-critical software systems and their associated software quality plans are
77. In order for contractors to receive a defense contract their internal software
processes must have been determined to be designated at a certain SEI/CMM level and in
the case of flight critical software additional requirements are stipulated by SEAL Level 1.
In addition to these requirements it is of course expected that Lockheed will develop its
software in a manner compliant with its own internal software development processes and
78. All Lockheed developed software must meet the specific requirements of the
defined in CBM 4004 and PM 4001 with approved tailoring. The Lockheed Aero Ft. Worth
software development process was assessed at SEI CMM Level 4 on December 17, 1999.
Additionally all JSF software must meet the requirements defined for their associated
Software Evidence Assurance Level as defined in the Air System SDP. All software
relevant to this Qui Tam is characterized as SEAL 1 (Safety Critical, the most stringent
characterization).
Scope of Violations
79. The Lockheed JSF contract stipulates that the software must be developed in
a manner compliant with SEI/CMM Level 4 and that Flight Control System (FCS) Software
must meet SEAL 1 requirements. These requirements are knowingly not being followed by
Defendant. This document details this violation of the contract. Defendant, along with
unsafe software which needlessly compounded the danger to any pilot who
Management Team (SMT) and the JSF Program Office (JPO) on multiple
occasions the VS, FCS, and FCA software safety and process compliance
c. Concealed the accurate software safety and process status from the SMT
Appendix C of the AS SDP are very specific as to what type and degree of testing must be
performed. It does not leave any gray area. Specific improper actions taken by Defendant
methodology, the test will never fail, but the intended purpose of the testing is
not achieved;
b. Performing formal qualifications test using software models that are not
c. Refusing to comply with software safety and process standards even after a
and process requirements that would have caused loss of the aircraft had it
g. Retaliating against any team member who pursued software safety and/or
then misrepresenting to the JPO that the software was being developed in a
i. Coaching team members on methods to mislead the SMT and/or JPO when
81. It is important to note while reviewing this document that germane to this
claim are the contractual requirements for the development of the software, not whether
any or all members of the JPO or Lockheed Martin think what is being done is OK.
Defendant has policies and procedures in place to request, when appropriate, a waiver or
“tailoring” of software safety and process requirements. Such waivers were not requested
by anyone associated with this claim. In fact not requesting waivers or tailorings was a
substantial component of the coverup process. The Relator suggested, if not professionally
insisted, on multiple occasions that the Defendants request waivers or tailorings when
SEI/CMM and SEAL standards, but was rebuffed—even reprimanded. Had management
submitted a request as required, the request, itself, would have operated as an express
disclosure of Defendant’s failures, all of which was contrary to the Defendant’s concealment
82. Relator made extensive efforts over several years to influence Defendant’s
upper management to acknowledge and utilize the proper software process, testing and
acknowledged the problems and recognized and rewarded Relator. See Exhibit D
attached hereto. Later, however, when Relator continued to remind management that it
was not addressing the identified software related problems, management’s responses
of the U.S. government, as Defendant’s unlawful conduct was clearly conscious and willful
in regard to the defective development, testing and compliance standards for software
products. Defendant knew that it was obligated to abide by SEI and SEAL I standards in
developing software for the F-35, F-22 and related programs, but it refused to do so for
“money and scheduling reasons.” Because Relator attempted to ensure that the relevant
software was properly developed as required by the Defendant’s contract with the
government, Relator was rebuffed, retaliated against, was reassigned to a different, less
willingness to lawfully perform his assigned tasks on the very critical F-35 Program. After
Relator’s constructive termination from the JSF Program, he confirmed that the F-35’s
Mission Systems had similar software compliance issues, and Relator reported that
mandatory software processing, testing and compliance review standards, the software
now contains substantial corruption which has multiplied significantly the risks that the
software will not operate as intended, resulting in increased probabilities of: (1) the loss of
life and/or aircraft; (2) the pervasive failure of a major weapons system; and (3) major
84. Relator believes, after review, that the government has paid hundreds of
millions of dollars as of this date for the development of the software aspect of the
F-35 Program, as well as substantial money for similar software development for the
F-22 and related programs at its plants. However, the aircraft programs do not have
which has been properly developed, tested and has satisfied compliance review
government does not have software that the U.S. can safely utilize in the JSF Program.
The risks to pilots, troops on the ground, unintended targets and the federal budget is far
85. Respectfully, the Relator urges the Department of Justice and the U.S.
Attorney’s office to timely press this matter in order to prevent the huge, continuing waste of
funds in the continued development of a software using a corrupt software process, one
which has inherent risks far above what would be tolerated by the applicable standards in
86. According to an SEI expert on such defense programs, the JSF software
substantial resources and to avoid the serious risks outlined above. All software
development and testing that has not been processed according to required SEI/CMM or
SEAL standards must be revisited in order to provide a non-corrupted software system that
will operate the F-35 as intended. All past efforts are not a complete loss, but the
corruption is not susceptible to being surgically extracted, if the disobedience has been
pervasive. As the Relator knows that Defendant’s unlawful conduct was pervasive, the
process must cease, be re-commenced and must proceed according to the contractual and
applicable SEI and SEAL I software processing standards which Defendant has
completely false.
87. The Defendant, solely to maximize its profits, has taken illicit software
development, testing and compliance shortcuts in order to circumvent the applicable SEAL
I software process and reliability requirements. The certain results are corrupted F-35
software systems which cannot be utilized with confidence within the acceptable ranges of
risk. Much of the hundreds of millions of dollars spent, thus far, have been wasted because
program will further compound the waste that has resulted from the Defendant’s unlawful
conduct. The SEI expert has confirmed that the continued, prospective building of
software on top of corrupted software will compound the ultimate financial cost of
88. The U.S. should require Defendant to assign qualified software development
and compliance personnel to the rebuilding of the software system of the Flight Systems
and Mission Systems. The U.S. should also closely monitor whether the Defendant
properly abides by the required SEI/CMM and SEAL I standards, as applicable, all at the
costs of the Defendant. To allow the Defendant to retain in place those persons
responsible for this huge waste of government funding will continue to endanger the
development of the F-35 and set poor public policy which would do nothing to discourage
conduct in future national contracts such as the JSF Program. To fail to hold the culpable
managers responsible for the unlawful conduct that they willingly allowed on their watch
89. This is an action which has alleged violations of the Federal False Claims Act,
31 U.S.C. §§ 3729-3732, seeking damages and civil penalties on behalf of the United
States and the Relator as a result of the Defendant’s false statements and claims.
90. The False Claims Act provides that any person who knowingly submits or
causes to be submitted to the United States for payment or approval a false or fraudulent
claim is liable to the Government for a civil penalty of not less than $5500 and not more
than $11,000 for each such claim, plus three (3) times the amount of damages sustained
91. The False Claims Act allows any person having knowledge of a false or
fraudulent claim against the Government to bring an action in Federal District Court for
himself and for the United States Government and to share in any recovery as authorized
the United States as qui tam Relator/Plaintiff is, on information and belief, the first to file
and, in any event the original source for the complaints in this action.
92. Based on these provisions, the Relator on behalf of the United States
Government seeks through this action to recover damages and civil penalties arising from
the Defendants’ submission of false claims for payment or approval. In this case, such
claims were submitted to Government entities for payment for software processing, testing
and ostensible compliance when such process was corrupted by the Defendant’s
management which disregarded mandatory safety and reliability standards. Qui tam
Relator/Plaintiff believes the United States has suffered significant damages, likely in the
93. As required under the False Claims Act, qui tam Relator/Plaintiff has
previously provided the Department of Justice, the offices of the Attorney General of the
United States a disclosure statement of material evidence and information related to this
disclosures, supports the claims of wrongdoing, virtually all of which were presented to
Defendant’s management which, after conceding the violations, rejected the Relator’s
requests that the software process be conducted in accordance with the contract, industry
Contractor Requirements
94. The government’s Request for Proposal (RFP) seeking contractor bids for the
Joint Strike Fighter (JSF) Contract required that to be eligible to submit a proposal, the
contractor must be certified to have defined and documented software processes and
procedures that meet the SEI level 4 criteria; that is, the contractor must have in place a
software development process that has been certified as compliant with the standards of
SEI level 4 and have documented proof that it follows those processes Lockheed had such
certification and bid on the contract. Lockheed was awarded the contract on October 21,
2001. In order for Lockheed to demonstrate the Flight Readiness of the aircraft which was
required by contract, Safety Evidence Assurance Level (SEAL) requirements were added
for the Air System (AS) Integrated Product Team (IPT) with concurrence from the JSF
Program Office. The software relative to this claim was to be evaluated at SEAL 1, the
highest level of criticality. Relator began working for Lockheed on this contract on January
21, 2002, very early in the program. The Joint Strike Fighter (JSF) contract documents
specifically, or by reference or implication require that the contractor maintain its SEI/SEAL
compliant status and, of course, that it implement and follow SEI/SEAL compliant
procedures in the course of its performance of the Joint Strike Fighter (JSF) contract.
Because Lockheed had SEI/SEAL certified software development processes and failed to
use them, every claim for payment under this contract based on or related to software
95. Relator joined Lockheed early in the Joint Strike Fighter (JSF) Program, in
2002. As early as February 26th 2002, (See Exhibit E, FCA SW Development Process
contractually required SEI and SEAL 1 level software quality assurance procedures. He
raised such concerns in Technical Interface Meetings (TIMs) and in other meetings and
contended there were no express written requirements to comply with SEI and SEAL 1
standards; on other occasions, Buddy Denham and Theresa Giles, among others,
acknowledged Lockheed’s obligation to comply with Level 1 of the SEAL standards (“SEAL
1”).
96. On January 21, 2003, John Robb, senior manager of Lockheed’s JSF Vehicle
Systems Engineering Integration Team (VS SEIT) team (See Exhibit F, FYI FOR ACTION
JSEP development in critical status 01 21 2003) sent an e-mail to Lockheed officials and
employees and Joint Strike Fighter Program Office (JPO) officers expressing serious safety
concerns related to the lack of formal, SEI and SEAL compliant software development
procedures for the Joint Strike Fighter (JSF) program. Robb described the state of the
program as “the worst software disaster I’ve ever seen.” There were no safety critical
procedures. The following day, January 22, 2003, Mr. Robb sent a follow-up e-mail,
apologizing for and retracting the statements in the January 21, 2003 e-mail. In a complete
Bob Fookes, Teresa Giles, Stephen Gotch, Gary Gross, Kim Harrison, Paula Hooper, Joe
Kraumaker, and Carol Lopez received these communications. The retraction e-mail
constitutes a false record or statement used to obtain payment of a false claim. See
97. A Preliminary Design Review was conducted February 5, 2003. The first
version of the Software Design Plan was produced after the Preliminary Design Review on
98. On or about August 25, 2003, a Technical Interface Meeting (TIM) was held
and a TIM checklist, or “report card,” presented to the Government. Greg Walker prepared
this Technical Interface Meeting (TIM) report card, which expressly affirmed SEAL
compliance. This is a false statement or record used to obtain payment of false claims
99. On October 4, 2003, Buddy Denham sent an e-mail to Greg Walker inquiring
about the question of whether Lockheed was writing inadequate requirements, which were
not testable. Greg Walker responded on October 8, 2003, stating that the use of Autocode
software development software was the same as having in place and following SEAL1 and
SEI procedures and would produce SEAL1 and SEI compliant end products. This was a
knowing false statement on which the Government relied in paying all of Lockheed’s
subsequent claims for payment in the Joint Strike Fighter program. The statement is not
true because SEAL1 and SEI are standards for software development, applicable to the
software development process, designed to ensure that the software can be tested.
saying that because I am using Microsoft Word I do not have to check my spelling. You
could add a process step that required that spellcheck be run before documents are
submitted. This was not done. The reason this was not done is that, with the simple-to-
use Autocode tool, engineers who were not degreed or even formally trained software
engineers were used to create the software. These non-software engineers did not know
of or understand the software engineering processes and practices which the SEAL 1
requirements for software described in the AS SDP reflected and those which define SEI
Level 4. Therefore, they refused to implement the required SEI and SEAL 1 requirements.
100. Software that is not developed using SEAL 1 and SEI procedures is simply by
definition not SEAL1 or SEI compliant. Test cases for the software developed using
Autocode were formally tested by generating the expected results by executing the
Autocode generated software. This is the practical employment of the logical fallacy of
begging the question—the conclusion is the premise, and is proved by the assertion of
itself. The proof is circular and proves nothing beyond the fact that the adherent has
asserted it.
101. Software development engineers keep daily time records, which are the basis
for billings to the Government. Every daily time record in which an engineer on the
program indicating that the engineer was engaged in software development constitutes a
false record used to obtain payment of a false claim from the Government, because none
of the software development work was performed in accordance with the SEAL and SEI
standards that were the sine qua non of the software development to be performed under
the contract.
compliance with the required standards, about 1-1/2 years into the program, Lockheed’s
Santi Bulnes and Greg Walker called for an “Independent Review” (IR)—an ostensibly
103. The ostensibly “Independent” Review (IR) was initially to be conducted at one
or more meetings among the Joint Strike Fighter Program Office (JSFPO or JPO),
Lockheed Software Management Team (SMT), JSF Flight Control Systems (FCS) team,
JSF Systems Engineering (SE) team, and flight control staff from other Lockheed
programs. The Software Management Team (SMT) is a Lockheed group responsible for
ensuring that all Lockheed software complies with specific contractual requirements and
with all general Lockheed requirements. Both the Joint Strike Fighter contract and
Lockheed’s general standards require compliance with SEI and SEAL1. Relator, as
Software Product Manager for Flight Control Applications (FCA) and Gwen Goffney, as
Test Lead for Flight Control Application (FCA) software Integrated Product Team (IPT)
were to present charts at the Independent Review (IR). Relator and Gwen Goffney were
pressured prior to the Independent Review (IR) meeting to change charts they had
prepared for the meeting. These charts showed a summary of Joint Strike Fighter (JSF)
specific software requirements and Lockheed general software requirements, and showed
there was no SEI process in place for these software requirements and thus no SEI
104. To avoid disclosing this information to the Joint Strike Fighter Program Office
(JSFPO or JPO) and Lockheed’s Software Management Team (SMT), on November 19,
2003, the day before the scheduled Independent Review (IR) meeting, FCS Manager, Santi
Bulnes and Greg Walker sent an e-mail (sent by Greg Walker’s secretary Ruie Whitley on
Greg Walker’s behalf) to all participants cancelling the meeting, stating that presenting
persons were not yet ready. See Exhibit I, Cancellation of Independent Review. Later
the same day, another e-mail was sent to all participants except Joint Strike Fighter
Program Office (JPO) and Software Management Team (SMT), rescheduling the
meeting for the same, previously cancelled, date and time—Thursday November 20, 2003
from 1:00-5:30 p.m. The cancellation was a false statement or material omission intended
to mislead the Joint Strike Fighter Program Office (JPO) and the Government by
ostensibly “Independent” Review (IR) became a sham. Relator presented the negative
attendance list were kept for this meeting. However, Sylvia Godoy was assigned an action
item—to take the two-column document provided by the Realtor with the first column listing
the SEAL 1 and SEI requirements, and indicate in the second column how Lockheed was
complying with SEAL 1 and SEI standards. After the meeting, Relator provided the
document to Ms. Godoy via email with the first column filled in. This document was never
Nevertheless, after the meeting, Greg Walker and/or Santi Bulnes specifically and
expressly reported to Buddy Denham, of the Joint Strike Fighter Program Office (JPO), on
or about December 4, 2003, that the question had been reviewed and that it had been
determined that the software was in compliance. The Joint Strike Fighter Program Office
(JPO) reported to SD that Lockheed had reported that all of the software development was
compliant. This report by Lockheed is another false statement upon which the Government
105. Relator provided to Greg Walker on December 11, 2003, a Flight Systems
Applications (FCA) software “report card” checklist for submission with Deliverables in
advance of the January, 2004 Critical Design Review. This checklist indicated that the
Flight Systems Application software development was not SEAL/SEI compliant. Greg
Walker stated that he would not submit this report to the Government. Greg Walker instead
submitted to the Government records failing to disclose that the program’s software
development was not SEAL/SEI compliant, although he had no knowledge regarding these
standards. These submissions were false records or statements used to obtain payment of
106. A Critical Design Review (CDR), like a Preliminary Design Review (PDR), is a
payment is conditioned upon completion of the CDR. The Critical Design Review (CDR) is
a several-day meeting between the government and the contractor. There is a Critical
Design Review for each subsystem piece of software which is called a “Computer Software
Configuration Item” (CSCI) and each higher level system. The subsystem CDRs preceed
the CDRs for their higher level systems. “Deliverables” are typically due 30 to 60 days
before the CDR meeting. “Deliverables” are required products and/or documents which are
delivered to the JPO who represents the government which form the basis for the CDR
approval process The Critical Design Review (CDR) is not completed, or “closed,” and
payment is not made, until the government is satisfied that the contractually required
milestones have been met and any Request for Information (RFIs) have been resolved.
Review (CDR). The Critical Design Review is a precondition of a big payday for the
107. The Deliverables submitted to Joint Strike Fighter Program Office (JPO) 30
days in advance of the January 2004 Critical Design Review (CDR) contained the first
formal false statements and records provided to the Government regarding compliance.
Among the Deliverables was the SIM (System Integrity Manager) Software Development
Plan (SDP). The SIM (System Integrity Manager) Software Development Plan (SDP)
expressly and falsely stated that the software was in compliance with the required software
development standards. The SIM (System Integrity Manager) Software Development Plan
(SDP), version 3, dated October 31, 2003 was a Deliverable in advance of the January
2004 Critical Design Review (CDR). Section 3.2.2.5.2 of this SIM (System Integrity
Manager) SDP falsely indicated SIM IPT SEAL 1 compliance. This constituted a false
record or statement used to obtain payment of a false claim from the Government. The
Vehicle Systems CDR readiness checklist submitted to the Government in advance of the
Critical Design Review (CDR) also falsely affirmed compliance. The Flight Control Systems
(FCS) Systems Engineering Integration Team (SEIT) Software Development Plan (SDP)
advance of the Critical Design Review (CDR) also falsely affirmed compliance.
108. In January 2004, a Critical Design Review (CDR) was conducted; the Flight
Control Applications (FCA) portion of the CDR was conducted January 20-23, 2004. As
Software Product Manager (SPM) for Flight Control Applications (FCA), Relator Sylvester
Davis attended the Critical Design Review (CDR) meeting and gave a substantial
presentation regarding the status of the development of software for Flight Control
Applications (FCA). In his presentation, Relator addressed SEI and SEAL compliance in a
graph, which simply stated “yes” or “no” as to whether Lockheed was following SEI and
SEAL procedures. For approximately 8-10 items, his indication regarding SEI and SEAL
compliance was “no.” Representatives of the Joint Strike Fighter Program Office (JSFPO
or JPO), Lockheed managers and directors, and government/military officers attended the
presentation. Although there had been considerable verbal and e-mail communication
regarding whether the program was SEAL and SEI compliant for nearly three years,
Relator’s presentation at this Critical Design Review (CDR) was the first clear and concise
RFI 19
109. After the spring 2004 Critical Design Review meeting (CDR), the government
issued to Lockheed Request for Information (RFI) 19. Request for Information (RFI) 19
was the government’s first RFI regarding SEI and SEAL compliance. Request for
Information (RFI) 19 requested that Lockheed “Prior to CDR closure get concurrence from
safety (SMT) that the unit testing approach identified in the FCA SDP section 3.2.2.5.2.
(See Unit Test slides 5-22) meets the SEAL requirements identified in the AS SDP. There
should be an emphasis on those SEAL “In other words required Lockheed to affirm that
Flight Control Application (FCA) software was in compliance with the required SEI and
SEAL standards. The Critical Design Review (CDR) could not be completed and payment
could not be made until all Requests for Information were closed. Thus, to complete the
Critical Design Review (CDR), Lockheed had to be in compliance and so affirm in response
110. If the Deliverables and the Critical Design (CDR) meeting give rise to
questions, the Government submits them to the contractor in “Requests for Information
(RFI). All Requests for Information (RFIs) must be satisfactorily answered and closed
before the Critical Design Review (CDR) is complete and payment made. Given that the
SMT had not made their determination and that when they did they did not affirm, RFI 19
should not have been closed and payment should not have been made.
Problem Anomaly Reports (SPAR). This database was accessible to the Government, so
that it could be informed of problems and their resolution. When a problem was resolved
and the SPAR removed, this information and the reason were recorded in the SPAR
system. SPAR 1256 submitted by Gerald F. Waid on August 25, 2004, regarding the
absence of range checking, a SEI SEAL1 requirement, stated that it was not clear which
department was responsible for verifying range checking. SEAL compliant procedures
would actually require redundant range checking verification by multiple departments. This
SPAR was closed by Richard Bonnett on August 31, 2004, indicating that there was no
range checking problem—with no indication of the answer to the question posed in the
SPAR. This closing of SPAR 1256 was thus a false record or statement used to obtain
112. On September 30, 2004, Relator was expelled from a meeting, attended by
regarding software safety. JPO personnel attended this meeting, for which the topic was
SEAL 1 requirements fulfillment. Relator disagreed with false statements that flagged
SEAL1 software defects were “all ok” and not safety issues, and that it was not necessary
for personnel to report defects as they were found. The false statements and the
suppression of Relator’s true statement are false statements or records used to obtain
113. On November 3, 2004, the flight control software crashed during flight
simulation due to a “triple channel reset.” This means that had the aircraft been in the air, it
would have crashed because its flight control software would have failed, meaning it was
impossible for a pilot to control the aircraft; the pilot could not steer right or left, direct the
nose up or down, or exercise any control whatsoever over the aircraft. It simply would fall
from the sky like a rock. Edith (Jo) Holtzman was Manager of the SIM IPT, which was
November 4, 2004, the cause of the crash was determined. It was clear that range
checking was needed. Relator opened SPAR 1637 on November 10, 2004. SPAR 1637
identified the need for System Integrity Manager (SIM) to do range checking pursuant to
CO1, pointing to the crash as demonstrating the problem. On November 4, 2004 at 2:14
p.m., after a series of e-mail communications regarding this matter, Ms. Holtzman sent an
e-mail to all Lockheed employees who had been communicating regarding the problem
instructing them that there were to be no further responses or discussions regarding the
matter coming from her staff. By January 2005, this SPAR had been closed without
explanation other than “no problem.” Jane Gardner, a lead engineer in SIM (System
Integrity Manager) recommended that SPAR 1637 be rejected. On January 19, 2005, this
SPAR was changed to “rejected.” The closing and rejection of SPAR 1637 constitute false
114. In a January 25, 2005 SPAR board meeting, Chuck Neppach asked whether
SPAR 1256 needed to be reopened in light of the triple channel reset episode. Edith
Holtzman stated she was waiting for guidance from Rich Bonnett. The Government
attends SPAR board meetings. Ms. Holtzman opened SPAR 1968 regarding range
checking verification on January 27, 2005; SPAR 1968 was the same as SPAR 1256,
SMT Investigation
responsible for ensuring that all Lockheed software complies with specific contractual
requirements and with all general Lockheed requirements, conducted an investigation into
CO1 and SEI compliance. Relator was ostensibly included in this investigation. CO1 and
SEI define the processes used to develop software. Compliant software is developed in
process. First, it is determined whether the developer has a defined process that will result
in CO1 and SEI if followed. Second, it is determined whether the developer is following the
process. Relator expressed concerns repeatedly that the first step was not fulfilled—there
this effect. SMT rejected the software twice. Nonetheless, Lockheed management simply
SMT team members. Relator learned, after he was removed from the program by
Lockheed, that the unchanged documentation was subsequently passed by SMT although
there still was no CO1/SEI compliant process in place and thus, no such process being
followed.
and planning the creation of false records and statements to cover the lack of SEAL1/SEI
compliance in the program. Deaun Dawson sent an e-mail on behalf of Lockheed director
Opie W. White to John Robb, with several other Lockheed personnel copied, including
2004. See Exhibit L, FW FOR ACTION Please include me . . . . In this e-mail he stated
that he did “not support releasing the SEI as now written,” complaining that the written SEI
requirements “make[s] us and our supplier base non-compliant.” This related to software
“[t]he software teams are going to have to get on the same page as the rest of the program
and define what we can do with what we have.” Don Kotzer responded in an e-mail of
December 1, 2005, 11:51 a.m., instructing Lockheed personnel, “[p]lease edit the
had been accomplished, rather than reflecting contract requirements against which results
would be measured. By analogy, one might create a yardstick the length of one’s arm,
then measure one’s arm with the yardstick and conclude that the arm is, indeed, a yard in
length. Lockheed not only agreed in these e-mail communications to create the false
engineering specifications. This was done because, with the safety requirements in place,
not load on the aircraft; the requirements software interface would prevent it from loading
because it did not fulfill the requirements. To permit the program to move forward without
going back and developing the software in compliance with SEI/SEAL1 and related safety
standards, Lockheed simply changed the requirements so that its software would pass the
test and successfully load onto the aircraft. These changed requirements permitted the
development of readiness reviews—documents representing that the aircraft was ready for
arbitrarily and without analysis, that the aircraft was mature, and flight test ready. The
aircraft was reported ready. Such readiness reviews and reports and the underlying
documents all constitute false statements or records used to obtain payment of false
delivered to the Government and used to obtain payment of false claims from the
Government.
117. In 2005, Lockheed gave Relator a special award recognizing his contribution
continued unabated.
Government. This checklist affirmed SEAL/SEI compliance and thus was a false record or
the Government. This status report affirmed SEAL/SEI compliance and thus was a false
120. After RFI 19 and two rejections, an investigation was conducted. Relator
attended a May 23, 2005 meeting. Pam Thompson, Lockheed’s overall director of software
engineering raised concerns regarding the software for the program; Thompson was forced
121. Between April and June of 2005, Chuck Neppach, the Government’s JPO
software liaison, left the program because he was not willing to sign a flight test readiness
review; Neppach contended the aircraft was not ready for its first flight based on defined
CO1 criteria.
122. On our about June 20, 2005, Ricky Stanford scheduled a CO1 assessment
pre-meeting to discuss “how to pass the [CO1] assessment.” Relator declined to attend,
because he had made his position clear on the subject—that Lockheed should have been
complying with CO1 in the software development process all along and that compliance
123. In October of 2005, Relator was on medical leave. An internal CO1 audit was
undertaken by the Integrated Product Team (IPT). Three Lockheed employees, Amit
Diggikan, James Ricky Stanford, and Mike Bridges, presented information at an October
25, 2005 meeting stating that the CO1 audit confirmed compliance. This information was
followed up with one or more documents confirming CO1 compliance. These affirmations
of CO1 compliance are false records or statements used to obtain payment of false claims.
124. From and after Relator became aware of management’s intention to seek to
circumvent admitted safety and reliability standards in the software process for the JSF
which he should have attended in view of his responsibilities, ridiculed and ultimately the
Relator was forced from his F-35 position in Defendant’s effort to restrict Relator’s
knowledge of future violations, assigned to a different job with the Defendant and,
125. Relator was mistreated, seriously and often. He suffered mental distress from
contemplated and required by law on the JSF Program. The Relator has provided the
United States Government with documentation of the Defendant’s improper conduct toward
him which occurred solely because he demanded that safety measures be honored as
required by the contracts, industry standards and the law. The Relator attempted to work
through the Defendant’s obstinacy on these issues, but he failed to persuade the Defendant
to perform lawfully. His initial belief that Defendant’s upper management would realize the
evidenced more concern about continuing to bypass the time and expense required for
SEAL I compliance, than ensuring that the necessary time and expenditures were
dedicated to the software process, so that the tasks were safely performed as required.
Ultimately, the Realtor was forced from his very important F-35 position, and he was
objectives; that is, Defendant’s conscious disregard of its contractual responsibilities to the
U.S. and other governments of the JSF Program, as well as its arrogant disregard of its
126. As a result of the Defendant’s unlawful conduct and its retaliation against
the Relator/Plaintiff, the Relator/Plaintiff is entitled to recover under the False Claims Act,
31 U.S.C. § 3730(h).
CAUSES OF ACTION
127. Qui tam Relator/Plaintiff realleges and hereby incorporates by reference each
and every allegation contained in preceding paragraphs numbered 1 through 126 of this
Complaint.
128. Based on the acts described above, Defendant knowingly violated one or
129. The United States Government and its allied partners in the JSF Program
were unaware of the falsity of these claims, records, and/or statements made by the
Defendant and, in reliance on the accuracy thereof, paid the Defendant for the fraudulent
claims.
Government has not received the contractual value, to which it was entitled by law, as
contemplated in the JSF Program, all of which is in violation of the False Claims Act.
131. Due to the Defendant’s unlawful conduct, the United States Government has
132. Qui tam Relator/Plaintiff realleges and hereby incorporates by reference each
and every allegation contained in preceding paragraphs numbered 1 through 131 of this
Complaint.
132. In violation of the False Claims Act § 3730(h), the Defendant took negative
Defendant’s management about Defendant’s continuing False Claims Act violations. The
employment consequences and has suffered damages. He seeks damages for the
Defendant’s unlawful conduct in the form of retaliation against him, solely because Relator
protect members of the armed forces, unintended targets and the U.S. Treasury.
RELIEF
134. The Relator/Plaintiff seeks to receive, on his own behalf, all monetary
against him. In addition, the Relator/Plaintiff seeks punitive damages on his own behalf.
PRAYER
behalf of the Plaintiffs and against the Defendant for the following:
a. Damages in the amount of three (3) times the actual damages suffered by
the United States Government as a result of the Defendant’s unlawful
conduct;
b. Civil penalties against the Defendant equal to $11,000 for each violation of 31
U.S.C. 3729;
d. Qui tam Relator/Plaintiff be awarded all costs and expenses of this litigation,
including attorneys’ fees and costs of court;
Respectfully submitted:
________/s/____________
David M. Nissman, Esq.
The McChain Nissman Law Group, LLC
53A Company Street
Christiansted, BI 00820
(340) 719-0601 phone
(340) 719-0602 fax
_______/s/_____________
Samuel L. Boyd
Catherine C. Jobe
Boyd & Associates
6440 North Central Expressway
Suite 600
Dallas, Texas 75206-4101
Telephone (214) 696-2300
Facsimile (214) 363-6856
CO-COUNSEL FOR RELATOR/PLAINTIFF
Veretta Frazier
West & Gooden
320 S R L Thornton Fwy # 300
Dallas, Texas 75203 6440
Telephone (214) 941-1881
CO- COUNSEL FOR RELATOR/PLAINTIFFS
CERTIFICATE OF SERVICE
_______/s/__________________________
Samuel L. Boyd P.C.