Active Risk Assessment Team Participation Obligation Invoked by Engineer A
Autonomous vehicle operating system safety evaluation
Engineering risk management team deliberations
Engineer A must fully and actively participate in the automobile manufacturer's engineering risk management team, clearly and unambiguously express all concerns about the autonomous vehicle operating system's safety, and explore additional technical options that could mitigate identified risks — passive or hedged participation is insufficient
Full and active participation requires Engineer A to articulate concerns about harm-distribution algorithms with specificity and clarity, not merely note them in passing, and to actively propose technical alternatives rather than deferring to team consensus
Engineer A Autonomous Vehicle Risk Assessment Team Engineer
Active Risk Assessment Team Participation Obligation
Engineer A has a responsibility to fully and actively participate as a member of the engineering risk management team, clearly and unambiguously express any and all concerns he has regarding the safety of the proposed autonomous vehicle operation system, and explore additional potential technical options that could mitigate the risks identified in the proposed autonomous vehicle operating system.
Individual professional obligation to express concerns clearly and explore mitigation options is not subordinated by team membership or employer pressure
Algorithmic Ethics Gap Recognized (Event 7) → Propose Further Study Before Deployment (Action 6)
Algorithmic Harm Distribution Ethics Invoked in Autonomous Vehicle Case
Autonomous vehicle operating system harm-distribution algorithm
Automobile manufacturer's commercial interests
Engineer A's participation in the autonomous vehicle risk assessment team requires explicit analysis of how the autonomous vehicle operating system allocates harm among affected parties — pedestrians, passengers, and bystanders — when harm is unavoidable, recognizing that these harm-distribution choices embed moral values requiring professional ethical scrutiny
The risk assessment team's evaluation of autonomous vehicle scenarios is not merely a technical exercise but an ethical one — the choice of harm-distribution framework must be subjected to professional ethical scrutiny and clearly expressed concerns must be raised when the framework is inadequate
Algorithmic Harm Distribution Ethics in Autonomous Systems
New technologies often introduce new uncertainties and sometimes significant risk.
Ethical scrutiny of harm-distribution algorithms is a professional obligation that cannot be subordinated to deployment schedule or commercial interests
Automobile Manufacturer Autonomous Vehicle Developer
{'entity_type': 'Private automobile manufacturing company', 'product': 'Driverless/autonomous vehicle operating system', 'decision_authority': 'Product development scope and deployment decisions'}
The automobile manufacturer retains Engineer A as a consultant and has assembled an engineering risk assessment team to evaluate scenarios for a driverless/autonomous vehicle operating system under development, including crash outcome decision logic with direct public safety implications for third parties.
{'type': 'retains', 'target': 'Engineer A Autonomous Vehicle Risk Assessment Team Engineer'}
{'type': 'subject_to_public_safety_obligations_of', 'target': 'Engineer A Autonomous Vehicle Risk Assessment Team Engineer'}
Automobile Manufacturer Autonomous Vehicle Developer Client
Engineer A is a professional engineer working as a consultant to an automobile manufacturer that is considering the development of a driverless/autonomous vehicle operating system
Automobile Manufacturer Autonomous Vehicle Developer Client (Present Case)
{'type': 'Automobile manufacturer', 'product': 'Autonomous vehicle operating system', 'decision_authority': 'Deployment of autonomous vehicle system'}
The automobile manufacturer in the present case that employs or retains Engineer A as part of an engineering risk management team to evaluate the autonomous vehicle operating system, bearing authority over deployment decisions and subject to Engineer A's paramount public safety obligations.
{'type': 'employs_or_retains', 'target': 'Engineer A Autonomous Vehicle Risk Assessment Team Engineer'}
Engineer A should propose that further study be undertaken by the company before the autonomous vehicle operating system is utilized
explore additional potential technical options that could mitigate the risks identified in the proposed autonomous vehicle operating system
Autonomous System Moral Framework Transparency Obligation Invoked in AV Design
Autonomous vehicle crash-avoidance algorithm
Engineer A's risk assessment team bears an obligation to ensure that the moral framework embedded in the autonomous vehicle's crash-avoidance algorithm — whichever framework the manufacturer ultimately adopts — is transparently disclosed to regulators, the public, and prospective vehicle purchasers, rather than being obscured within the technical specifications of the software system
The choice between passenger-protective and harm-minimizing algorithms is a moral choice that affects the public — prospective vehicle purchasers, pedestrians, cyclists, and motorcyclists all have a legitimate interest in knowing which framework governs the vehicle's behavior in unavoidable crash scenarios; professional integrity requires that this choice be made visible
Autonomous System Moral Framework Transparency Obligation
Client confidentiality interests in proprietary algorithm design must yield to the public's interest in knowing the moral framework governing autonomous systems that operate in shared public spaces
does the vehicle's system choose the outcome that will likely result in the greatest potential for safety for the vehicle's passengers or does the vehicle's software system instead choose an option in which the least amount of potential harm is done to any of those involved in an accident
Autonomous Vehicle AV OS Development Initiated
Autonomous Vehicle Ethics Regulatory Standards Vacuum
Ongoing at time of Engineer A's assignment; persists until applicable standards are enacted
Regulatory Standards Vacuum for Novel Product State
Absence of applicable regulatory or industry standards governing autonomous vehicle harm-allocation decision logic
Enactment of applicable national, governmental, or industry standards for autonomous vehicle ethical decision algorithms
members are being asked to make a recommendation relating to potential situations that could arise in connection with the operation of driverless/autonomous vehicles
Risk assessment team tasked with recommending harm-allocation logic in the absence of governing standards
Autonomous Vehicle Harm Allocation Design Assignment
From Engineer A's assignment to the risk assessment team through submission of the team's recommendation to the automobile manufacturer
Engineer A is assigned to an engineering risk assessment team whose members are being asked to make a recommendation relating to potential situations that could arise in connection with the operation of driverless/autonomous vehicles
Autonomous System Harm Allocation Design State
Engineer A's assignment to evaluate and recommend harm-allocation decision logic for autonomous vehicle operating system
Formal submission of risk assessment team recommendation to automobile manufacturer client
Engineer A assigned to engineering risk assessment team tasked with recommending decision logic for unavoidable crash scenarios in driverless vehicles
Autonomous Vehicle Operating System Safety Standard
SAE International, ISO, NHTSA, and automotive engineering professional bodies
Technical and Regulatory Standards Governing Autonomous Vehicle Operating System Design and Safety
automobile manufacturer that is considering the development of a driverless/autonomous vehicle operating system
Engineer A and the engineering risk assessment team in evaluating design options
Technical standards and professional norms governing the design of autonomous vehicle operating systems, including acceptable risk thresholds, software decision logic requirements, and safety benchmarks applicable to the automobile manufacturer's development project
NSPE Board of Ethical Review Case 96-4: Software Design Testing and Public Safety
One example of this was BER Case 96-4, which involved software design testing.
According to the Board of Ethical Review, Engineer A's ethical obligations in Case 96-4 involved balancing a variety of ethical and other business considerations and making a recommendation based solely on technical finding (and not business considerations) to permit the company to make an informed decision about the need for additional testing in furtherance of the public health, safety, and welfare.
Although the facts in the present case are somewhat different than those in Case 96-4, the Board of Ethical Review believes that several points discussed in the previous case are pertinent to the case at hand.
In BER Case 96-4, Engineer A's ethical concerns in the case were not related directly to the safety of the software, but instead to the availability of a new draft safety testing standard that might require additional scrutiny of the software.
NSPE Board of Ethical Review in reasoning about Engineer A's obligations in the autonomous vehicle context
Cited as the primary analogical precedent for the present autonomous vehicle case, establishing the principle that engineers must recommend additional testing when new draft safety standards may not be met, and must balance technical findings separately from business considerations to enable informed employer decision-making in furtherance of public health, safety, and welfare
BER Case 96-4 Completed Safety Testing with Residual Concern
From completion of testing confirming compliance with existing standards through employer's informed decision on additional testing
Although the tests demonstrated that the software was safe to use under existing standards, Engineer A was aware of new draft standards that were about to be released by a standard setting organization—standards that the newly designed software might not meet
Completed Safety Testing with Residual Concern State
Engineer A's residual concern about forthcoming standards after software passed existing standard testing
Employer's informed decision after receiving Engineer A's technical report on current results and forthcoming standards
Engineer A generally believed that the software designed by his company was safe, but he had become aware of a new testing procedure that was likely to demonstrate results that might cast a cloud over the software's viability
Testing demonstrated software safe under existing standards, but Engineer A became aware of forthcoming standards the software might not meet
BER Case 96-4 Emerging Software Standard Pre-Adoption Gap
From Engineer A's awareness of new draft standards through employer's informed decision on additional testing
Public (nuclear, air quality, water quality facility users)
Engineer A was aware of new draft standards that were about to be released by a standard setting organization—standards that the newly designed software might not meet
Emerging Standard Pre-Adoption Safety Gap State
Engineer A's awareness of forthcoming draft testing standards for safety-critical software
Employer's informed decision regarding additional testing after receiving Engineer A's technical report
Although the tests demonstrated that the software was safe to use under existing standards, Engineer A was aware of new draft standards
Engineer A became aware of new draft standards about to be released by a standard-setting organization that the newly designed software might not meet
BER Case 96-4 Multi-Factor Business-Safety Balancing
From software company's request for Engineer A's recommendation through delivery of technical report
Engineer A needed to balance a variety of factors
Multi-Factor Business-Safety Balancing Obligation State
Engineer A's obligation to formulate a technical recommendation amid significant financial pressures
Engineer A's delivery of technical report separating technical findings from business considerations
The financial pressures that existed, including the financial impact on his company, the client, and the public, as well as the potential loss of jobs and delays if additional testing were to be pursued, were clearly important factors
delaying implementation would mean the state's public service commission utility rates would rise significantly
these nontechnical considerations were factors that needed to be given weight separate and apart from the decision as to whether the additional testing should be recommended by Engineer A
Software company requested Engineer A's recommendation on the need for additional testing while multiple financial pressures were present
BER Case 96-4 Public Safety at Risk from Safety-Critical Software
From Engineer A's awareness of forthcoming standards through employer's informed decision on additional testing
The industries using the software—water, air, and nuclear—clearly have an enormous impact on the public health, safety, and welfare
Public health and safety risk from potential deployment of software not meeting forthcoming standards in nuclear, air quality, and water quality facilities
Additional testing confirming compliance, redesign, or informed employer decision to defer deployment
Engineer A needed to be certain that the information imparted to his employer and to the employer's clients was clear, accurate, and direct
Software designed for safety-critical public facilities (nuclear, air quality, water quality) may not meet forthcoming draft standards
BER Case 96-4 (precedent case) before present autonomous vehicle case
CausalLink_Actively Participate in Risk A
CausalLink_Explore Additional Technical M
CausalLink_Prepare Transparent Technical
CausalLink_Propose Further Study Before D
CausalLink_Recommend Additional Safety Te
CausalLink_Unambiguously Express Safety C
Client Relationship — Engineer A and Automobile Manufacturer
From commencement of consulting engagement through conclusion of risk assessment assignment
Active consulting relationship between Engineer A and automobile manufacturer, with associated obligations of faithful agency, competent service, and paramount public safety duty
Conclusion of consulting engagement or Engineer A's withdrawal
Engineer A retained as consultant to automobile manufacturer for autonomous vehicle operating system development
Competing Duties — Passenger Safety vs. Aggregate Harm Minimization
From assignment to risk assessment team through submission of recommendation
Engineer A's competing professional duties: duty as consultant to client (automobile manufacturer seeking passenger-protective system) vs. paramount duty to protect public health, safety, and welfare (including third-party road users)
Recommendation submitted; Engineer A withdraws; or client adopts harm-minimizing standard
Engineer A asked to recommend between passenger-protective and harm-minimizing algorithms, creating direct tension between client service obligations and public welfare obligations
Competing Public Goods Balancing Invoked in Passenger vs. Third-Party Safety Trade-Off
Autonomous vehicle crash-avoidance algorithm recommendation
Engineer A's risk assessment team faces a genuine conflict between two legitimate public goods — passenger safety (protecting vehicle occupants) and third-party safety (protecting pedestrians, cyclists, and motorcyclists) — requiring the team to present both goods and their trade-offs fully and objectively to the automobile manufacturer rather than resolving the conflict unilaterally in favor of one value
Both passenger safety and third-party safety are legitimate public welfare values; the engineering risk assessment team's role is to present the trade-offs between them objectively and completely, enabling the manufacturer and ultimately regulators and the public to make an informed policy determination about which framework should govern autonomous vehicle design
Competing Public Goods Balancing in Engineering Advisory Roles
The principle requires that the recommendation not resolve the conflict unilaterally but instead present both frameworks with their ethical, legal, and public welfare implications, leaving the ultimate policy choice to appropriate decision-making authorities
having the car crash into a stationary object (e.g., telephone pole, etc.) with the probability of causing some passengers serious but non-life-threatening injuries instead of striking and potentially causing a fatal injury to a pedestrian, cyclist, or motorcycle rider
Completeness and Non-Selectivity in Advisory Opinions Invoked by Engineer A Risk Assessment Team
Risk assessment recommendation to Automobile Manufacturer Autonomous Vehicle Developer Client (Present Case)
Faithful Agent Obligation Within Ethical Limits
Engineer A's risk assessment team must present both harm-distribution frameworks — passenger-protective and total-harm-minimizing — completely and objectively to the automobile manufacturer client, rather than selectively presenting only the framework that aligns with the manufacturer's commercial interests in selling vehicles to consumers who may prefer passenger-protective systems
The client is a non-engineer decision-maker who lacks independent capacity to evaluate the completeness of the ethical analysis — Engineer A's obligation is to present both moral frameworks and their full implications, including the legal, reputational, and public welfare implications of each choice, rather than filtering the analysis to favor the commercially preferred option
Completeness and Non-Selectivity in Professional Advisory Opinions
The completeness obligation requires full presentation of both frameworks; the faithful agent obligation is satisfied by presenting the complete analysis and then deferring to the client's ultimate decision within ethical limits
Beyond the Board's finding that Engineer A must recommend minimizing harm to the least number of persons, Engineer A bears an additional obligation to explicitly disclose to the automobile manufacturer that this recommendation is grounded in a utilitarian ethical framework rather than in any established regulatory or industry standard. Because no applicable national or industry standards governing autonomous vehicle harm-allocation decision logic currently exist, Engineer A cannot represent the harm-minimization recommendation as a technically mandated or universally accepted engineering norm. Presenting it as such would violate the completeness and non-selectivity obligation that governs Engineer A's advisory role. Engineer A must therefore clearly communicate to the automobile manufacturer that the recommendation reflects a specific moral philosophy — one that reasonable engineers and ethicists might contest — so that the manufacturer can make a genuinely informed deployment decision. This disclosure obligation is heightened, not relieved, by the regulatory standards vacuum, because the absence of external standards places the full burden of ethical transparency on Engineer A as the professional advisor.
The Board's conclusion that Engineer A must recommend harm minimization for the least number of persons does not fully resolve what Engineer A's obligations become if the automobile manufacturer overrides that recommendation and elects to program the vehicle to prioritize passenger safety above third-party welfare. In that scenario, Engineer A's ethical obligations do not terminate upon delivery of the initial recommendation. Engineer A must first pursue graduated internal escalation within the risk assessment team and up the manufacturer's organizational hierarchy, clearly documenting the safety concern and its basis in the public welfare paramount principle. If internal escalation fails to produce a design that Engineer A can professionally certify as consistent with the obligation to hold paramount the safety, health, and welfare of the public — including pedestrians, cyclists, and motorcyclists who are third parties to the client relationship — Engineer A must consider whether continued participation in the project constitutes implicit endorsement of a harm-allocation algorithm that foreseeably causes fatal injury to third parties. At that threshold, refusal to certify the system or withdrawal from the engagement may be required. The consultant relationship does not diminish this obligation; the NSPE Code's public welfare paramount duty applies equally to consultants and employees, and the absence of a direct employment relationship does not reduce the enforceability of Engineer A's professional ethical duties.
The Board's harm-minimization conclusion, while sound as a first-order ethical directive, does not adequately account for the possibility that a technically superior mitigation option — such as a sensor-based dynamic crash evaluation system capable of real-time scenario assessment rather than pre-committed algorithmic harm-allocation logic — could dissolve or substantially reduce the binary ethical dilemma between passenger safety and third-party harm minimization. Engineer A's obligation to explore additional technical mitigation options before accepting the dilemma as irreducible is itself an ethical duty, not merely a technical preference. Analogous to the reasoning in BER Case 96-4, where Engineer A was obligated to recommend further study and additional testing before deployment of safety-critical software, Engineer A in the present case must recommend that the risk assessment team investigate whether the harm-allocation decision can be made dynamically rather than pre-committed, thereby potentially achieving better outcomes for all parties across a wider range of crash scenarios. Recommending harm minimization without first exhausting technically feasible alternatives that could reduce the need for any pre-committed harm allocation would itself be an incomplete discharge of Engineer A's professional competence and public welfare obligations. If such alternatives are found to be technically infeasible, Engineer A must document that finding transparently so that the manufacturer's deployment decision is fully informed.
The Board's conclusion that Engineer A must recommend minimizing harm to the least number of persons implicitly adopts a utilitarian ethical framework — specifically, an aggregate harm-minimization calculus — without acknowledging that this represents one among several defensible moral philosophies rather than a universally accepted engineering standard. A deontological framework, for instance, might prohibit the vehicle from actively redirecting harm toward any third party regardless of aggregate outcome, treating each person's life as inviolable rather than as a unit in a welfare sum. Because Engineer A is advising an automobile manufacturer on a design decision that will be embedded in a consumer product affecting the public, Engineer A has an affirmative obligation under the principle of Completeness and Non-Selectivity in Advisory Opinions to disclose to the manufacturer that the harm-minimization recommendation reflects a specific moral philosophy, that alternative frameworks exist and yield different algorithmic outcomes, and that the selection among them is not a purely technical determination. Failure to make this disclosure would present the manufacturer with an incomplete picture of the decision it is actually making, impairing its ability to give informed consent to the embedded ethical framework and potentially exposing it to legal and reputational consequences it did not knowingly accept.
In the absence of applicable regulatory or industry standards governing autonomous vehicle harm-allocation decision logic, Engineer A has an affirmative obligation to recommend that the automobile manufacturer publicly disclose the ethical framework embedded in the vehicle's operating system to prospective consumers before deployment. This obligation arises from the convergence of three independent sources: first, the Public Welfare Paramount principle, which requires that the public be protected not only from physical harm but from material deception about the nature of products that affect their safety; second, the Autonomous System Moral Framework Transparency Obligation, which recognizes that when an algorithm pre-commits to a harm-allocation outcome on behalf of a user who cannot intervene in real time, that user and affected third parties have a legitimate interest in knowing the decision logic governing their fate; and third, the regulatory standards vacuum itself, which — as the Board recognized analogously in BER Case 96-4 — heightens rather than relieves Engineer A's disclosure obligations precisely because no external regulatory body has yet stepped in to mandate transparency. The absence of a legal requirement to disclose does not extinguish the professional ethical duty to recommend disclosure. Engineer A's recommendation should therefore include not only the harm-minimization algorithm design but also a specific advisory that the manufacturer implement pre-sale consumer disclosure of the vehicle's decision logic as a condition of ethically responsible deployment.
If the automobile manufacturer, after receiving Engineer A's recommendation to minimize aggregate harm, decides to override that recommendation and program the vehicle to prioritize passenger safety above all others, Engineer A's ethical obligations do not terminate at the point of initial recommendation. Engineer A retains at minimum three residual obligations. First, under the principle of Graduated Internal Escalation Before External Reporting, Engineer A must formally document the disagreement and communicate to the manufacturer's decision-makers — in writing — that the passenger-priority algorithm creates a foreseeable risk of fatal harm to third parties that Engineer A regards as ethically unjustifiable, ensuring that the override decision is made with full awareness of its consequences rather than by default or inattention. Second, Engineer A must assess whether the resulting system design crosses the threshold from a debatable design choice into a design that Engineer A cannot in good conscience certify as safe for public deployment; if it does, Engineer A must decline to approve or certify the system under Code provision II.1.b., which prohibits approval of engineering documents not in conformity with sound engineering principles protective of public safety. Third, if internal escalation fails and Engineer A concludes that deployment of the passenger-priority algorithm poses an unreasonable risk of fatal harm to identifiable third-party classes — pedestrians, cyclists, motorcycle riders — Engineer A must evaluate whether external reporting obligations are triggered, recognizing that the NSPE Code's public welfare paramount obligation is not discharged merely by voicing concern internally when that concern is overridden and the harmful design proceeds.
Engineer A's role as a consultant rather than a direct employee does not diminish the substantive scope of his ethical obligations under the NSPE Code, but it does affect the procedural mechanisms available to discharge them. The Code's public welfare paramount obligation applies with equal force to consultants and employees; Engineer A cannot invoke the consultant relationship as a basis for providing a narrower or more deferential safety assessment than an employee engineer would be required to provide. However, the consultant relationship does affect how far Engineer A must press concerns before his professional duty is satisfied in one specific respect: a consultant who has formally documented a safety concern, communicated it clearly to the client's responsible decision-makers, and been overruled has discharged the internal escalation component of his obligation more rapidly than an employee embedded in a hierarchical organization with multiple escalation tiers. The consultant's professional independence — which is itself a resource that the client engaged — means that Engineer A's obligation to provide an honest, complete, and unvarnished assessment of third-party harm risks is if anything stronger than that of an employee who might face internal organizational pressure to soften findings. Accordingly, Engineer A's consultant status heightens the independence and completeness obligations while compressing the internal escalation sequence, and does not create any basis for a reduced or qualified duty of care toward third-party public safety.
The tension between the Faithful Agent Obligation — requiring Engineer A to serve the automobile manufacturer's interests — and the Third-Party Non-Client Welfare Consideration is real but resolvable within the NSPE Code's hierarchy of obligations. The Code does not treat these duties as co-equal: the public welfare paramount obligation is explicitly primary, and the faithful agent duty operates only within the ethical limits that the paramount obligation defines. This means that when the manufacturer's commercial interest in a passenger-protective algorithm conflicts with the safety of pedestrians, cyclists, and motorcycle riders, Engineer A is not required to balance these interests as if they were of equal weight. Instead, Engineer A must first satisfy the third-party safety obligation — by recommending the harm-minimization approach — and may then, within that constraint, seek to serve the manufacturer's interests by identifying technical solutions that minimize passenger harm within the harm-minimization framework. The faithful agent obligation does not authorize Engineer A to recommend a design that foreseeably causes fatal harm to third parties in order to protect the manufacturer's commercial position. What it does require is that Engineer A present the harm-minimization recommendation in a manner that is constructive, professionally grounded, and attentive to the manufacturer's legitimate interests in developing a commercially viable and legally defensible product — not that Engineer A suppress or soften the recommendation to accommodate those interests.
From a deontological perspective, Engineer A has an obligation that is stronger than — and not fully captured by — the Board's utilitarian harm-minimization conclusion. The categorical imperative, applied to the autonomous vehicle harm-allocation problem, yields a distinct constraint: Engineer A must not recommend a design that treats any class of persons — whether passengers or third parties — as mere instruments for the benefit of another class. A passenger-priority algorithm that systematically redirects lethal force toward pedestrians treats pedestrians as means to passenger safety ends, which a Kantian analysis would prohibit regardless of aggregate welfare outcomes. Conversely, a pure harm-minimization algorithm that in specific scenarios sacrifices a single passenger to save multiple pedestrians may itself treat the passenger as a means to aggregate welfare ends. The deontological implication for Engineer A is not simply to recommend harm minimization, but to recommend that the design team explore whether any algorithm can be constructed that avoids pre-committing to the instrumental use of any person's life — for example, by designing for crash avoidance rather than crash outcome optimization, or by ensuring that the system's decision logic does not systematically disadvantage any identifiable class. Engineer A's obligation under this framework includes flagging to the manufacturer that the entire framing of the harm-allocation problem as a binary choice between passenger priority and aggregate minimization may itself embed morally problematic assumptions that warrant further study before deployment.
From a virtue ethics standpoint, Engineer A demonstrates the professional integrity and moral courage required of a virtuous engineer precisely by actively and unambiguously expressing concerns about harm-allocation algorithms within the risk assessment team, even when facing commercial pressure to prioritize passenger safety. Virtue ethics evaluates not only the content of Engineer A's recommendation but the manner and disposition with which it is made. A virtuous engineer in Engineer A's position would not merely file a technically correct recommendation and withdraw; he would engage substantively with the team's deliberations, articulate the moral stakes of the design decision in terms accessible to non-engineer stakeholders, and persist in raising concerns through appropriate channels if the initial recommendation is dismissed. The virtue of practical wisdom — phronesis — is particularly relevant here: it requires Engineer A to recognize that the harm-allocation problem is not purely technical, that the risk assessment team's composition and mandate may not be adequate to resolve the embedded ethical questions, and that recommending further interdisciplinary study before deployment is itself an expression of professional integrity rather than a failure to provide a definitive answer. A virtuous engineer does not manufacture false certainty about genuinely contested moral questions in order to satisfy a client's desire for a clean recommendation.
If Engineer A had remained silent or provided only a partial assessment of third-party harm risks within the risk assessment team, the automobile manufacturer would not have had sufficient information to make an ethically informed deployment decision, and Engineer A's silence would have constituted a violation of both the faithful agent obligation and the public welfare paramount obligation. The faithful agent obligation requires Engineer A to provide the manufacturer with complete, accurate, and professionally grounded information relevant to the design decision — including information that is commercially inconvenient. Partial disclosure that omits the third-party harm implications of a passenger-priority algorithm would deprive the manufacturer of the ability to make an informed choice about the ethical and legal risks it is assuming. Simultaneously, Engineer A's silence would violate the public welfare paramount obligation by allowing a design to proceed toward deployment without the safety concerns having been formally raised, documented, and considered. The Code provision at III.1.b. — requiring engineers to advise clients when a project will not be successful — applies by analogy: a harm-allocation algorithm that foreseeably causes fatal harm to third parties in a predictable class of scenarios is not a successful engineering outcome, and Engineer A is obligated to say so. Silence in the face of a known, foreseeable, and serious public safety risk is not a neutral act under the NSPE Code; it is a breach of the engineer's professional duty.
If the automobile manufacturer had already established a firm design policy prioritizing passenger safety above all third-party considerations before Engineer A joined the risk assessment team, Engineer A's ethical obligations would shift materially — from recommendation toward escalation and, if necessary, refusal to certify. Under these circumstances, Engineer A's initial obligation to recommend the harm-minimization approach would remain, but its character would change: rather than being a prospective design input, it would function as a formal objection to an existing policy. Engineer A would be required to document that objection in writing, communicate it to the manufacturer's responsible decision-makers, and make clear that the existing passenger-priority policy creates foreseeable fatal risks to third parties that Engineer A regards as inconsistent with the public welfare paramount obligation. If the manufacturer declined to reconsider the policy after receiving this formal objection, Engineer A would face the question of whether to continue participating in the project. Continued participation in the design and certification of a system that Engineer A has formally identified as posing an unreasonable risk of fatal harm to third parties would be difficult to reconcile with the Code's prohibition on approving engineering documents not in conformity with sound engineering principles. Engineer A would therefore be obligated to decline to certify or approve the system, and to evaluate whether the severity and foreseeability of the third-party harm risk triggers any external reporting obligation under the public welfare paramount principle.
Had established national or industry standards governing autonomous vehicle harm-allocation decision logic existed at the time of Engineer A's assessment — analogous to the draft standards emerging in BER Case 96-4 — Engineer A's obligation to recommend further study before deployment would have been qualitatively different in character, though not necessarily stronger in absolute terms. The existence of applicable standards would have provided Engineer A with an external, professionally validated benchmark against which to evaluate the manufacturer's proposed algorithm, reducing the degree to which Engineer A's recommendation rested on Engineer A's individual ethical judgment. This would have made the recommendation more defensible, more actionable, and more likely to be accepted by the manufacturer. However, the absence of such standards does not weaken Engineer A's substantive obligation; it merely changes its epistemic basis. In the regulatory vacuum that actually exists, Engineer A's obligation to recommend further study is grounded in the recognition — itself drawn from the BER Case 96-4 analogy — that the absence of applicable standards is itself a safety-relevant fact that the manufacturer must be made aware of before deployment. The regulatory gap heightens the disclosure obligation and strengthens the case for recommending further interdisciplinary study, because it means that no external body has yet validated any harm-allocation approach as meeting a minimum standard of public safety. Engineer A's recommendation in the absence of standards must therefore be more explicitly provisional, more clearly flagged as reflecting one among several defensible approaches, and more strongly oriented toward recommending that deployment await the development of at least preliminary industry consensus.
If Engineer A had proposed and the team had successfully identified a technical mitigation option — such as a sensor-based system capable of dynamically evaluating crash scenarios in real time rather than relying on pre-committed algorithmic harm-allocation logic — the core ethical dilemma between passenger safety and third-party harm minimization would be substantially but not fully dissolved. A dynamic real-time evaluation system would eliminate the most ethically troubling feature of pre-committed harm-allocation logic: the systematic, categorical pre-assignment of fatal risk to identifiable classes of persons based on their mode of transportation rather than on the actual circumstances of a specific crash. However, Engineer A would retain significant residual ethical obligations even if such a system were technically feasible. First, Engineer A would be obligated to assess and disclose the reliability limitations of the dynamic evaluation system — including sensor failure modes, edge cases where real-time evaluation is impossible, and the possibility that the system's dynamic decisions might themselves embed implicit harm-allocation biases through the weighting of its input variables. Second, Engineer A would be obligated to recommend that the dynamic system's decision logic be made transparent to consumers and regulators, since the ethical concerns about algorithmic opacity do not disappear merely because the algorithm operates in real time rather than through pre-commitment. Third, Engineer A would be obligated to recommend that the dynamic system undergo further study and testing before deployment, since the novelty of the technology means that its real-world performance across the full range of crash scenarios cannot be validated through design analysis alone. The identification of a technical mitigation option reduces but does not eliminate Engineer A's public safety obligations.
That being said, to address the specific question posed in the case, Engineer A has an obligation to state that the prime ethical obligation of the vehicle operation is to minimize harm to affect the least number of persons.
The tension between the Faithful Agent Obligation Within Ethical Limits and the Third-Party Non-Client Welfare Consideration is resolved in this case by treating the automobile manufacturer's commercial interest in a passenger-protective algorithm as categorically subordinate to the welfare of pedestrians, cyclists, and motorcyclists who bear the fatal risk of the vehicle's pre-committed harm-allocation logic. The Board's conclusion that Engineer A must recommend minimizing harm to the least number of persons effectively establishes a lexical ordering: Public Welfare Paramount operates as a side-constraint on the faithful agent role, not merely as one factor to be weighed against client interest. This means Engineer A's duty to serve the automobile manufacturer does not extend to endorsing an algorithm that systematically transfers lethal risk onto non-consenting third parties in order to protect paying passengers. The case teaches that when client interest and third-party safety are genuinely zero-sum — as they are in a pre-committed harm-allocation algorithm — the NSPE Code resolves the tension by collapsing the faithful agent role at the boundary where client service would require engineering complicity in foreseeable third-party fatalities.
The Competing Public Goods Balancing principle — which acknowledges that vehicle passengers hold legitimate safety interests — does not neutralize the Public Welfare Paramount principle in this case; rather, the two principles interact to produce a qualified rather than absolute harm-minimization mandate. The Board's conclusion that Engineer A must recommend minimizing harm to the least number of persons implicitly acknowledges that passenger safety is a genuine public good, not merely a commercial preference, but treats aggregate harm reduction across all affected parties as the governing metric when those goods conflict. This resolution carries an important teaching: the Competing Public Goods Balancing principle functions as a corrective against naive utilitarian aggregation that would ignore passenger welfare entirely, while Public Welfare Paramount prevents that corrective from being weaponized to justify algorithms that predictably sacrifice a greater number of third-party lives to protect a smaller number of passengers. The net effect is that Engineer A's recommendation must be grounded in a harm-minimization calculus that counts all lives equally, resisting both pure passenger-priority logic and any framing that treats third-party lives as infinitely more valuable than passenger lives.
The interaction between the Autonomous System Moral Framework Transparency Obligation and the Regulatory Gap Safety Escalation Obligation — both activated by the absence of established national or industry standards governing autonomous vehicle harm-allocation ethics — produces a compounded disclosure duty that is stronger than either principle would generate in isolation. In the software testing context of BER Case 96-4, the regulatory gap triggered an obligation to flag the absence of standards as itself a safety concern and to recommend further study before deployment. Transposed to the autonomous vehicle harm-allocation context, that same gap-triggered escalation obligation combines with the transparency obligation to require Engineer A not only to recommend further study but also to affirmatively disclose to the automobile manufacturer that the harm-allocation recommendation rests on a specific moral framework — utilitarian harm minimization — rather than on a settled engineering standard. The Completeness and Non-Selectivity in Advisory Opinions principle reinforces this synthesis: because any recommendation Engineer A makes in a regulatory vacuum will necessarily reflect contestable ethical assumptions, selective silence about those assumptions would itself be a form of incomplete and potentially misleading professional advice. The case therefore teaches that regulatory vacuums do not relieve disclosure obligations; they intensify them, because the engineer's judgment substitutes for the absent standard and must therefore be rendered fully transparent.
Consumer Product Safety Testing Standard for Autonomous Vehicles
Consumer product safety standards bodies and automotive regulatory agencies
Consumer Product Safety Testing Policies and Standards Applicable to Autonomous Vehicle Systems
Consumer Product Safety Testing Standard
engineering risk assessment team whose members are being asked to make a recommendation relating to potential situations that could arise in connection with the operation of driverless/autonomous vehicles
Engineer A and the engineering risk assessment team
General product safety testing standards and policies governing the safety evaluation of autonomous vehicle systems as consumer products prior to market release, providing a baseline professional benchmark for the risk assessment team's deliberations
How should Engineer A discharge his obligations as a member of the automobile manufacturer's risk assessment team when the crash-avoidance algorithm's harm-distribution logic raises unresolved ethical and safety questions — specifically, whether to actively express concerns and recommend further study before deployment, or to defer to the team's commercial orientation and provide a narrower assessment?
Engineer A's core obligation to actively participate in the risk assessment team, unambiguously express safety concerns about the harm-allocation algorithm, and recommend further study before deployment of the autonomous vehicle operating system
Actively participate in all risk assessment team deliberations, formally document and unambiguously express concerns about the harm-allocation algorithm's third-party safety implications in writing, recommend that the manufacturer commission further interdisciplinary study — including ethical framework analysis and technical mitigation investigation — before deploying the operating system
Participate in the risk assessment team's technical evaluation, raise third-party harm concerns verbally during team deliberations, and provide a written recommendation that identifies the harm-minimization approach as preferable — without separately recommending that deployment be delayed for further study, on the ground that the team's collective judgment and the manufacturer's business timeline should govern the deployment decision once the technical recommendation has been delivered
Participate in the risk assessment team's evaluation, recommend harm minimization as the preferred algorithm design, and separately recommend that the manufacturer explore technical mitigation options — such as dynamic real-time crash evaluation systems — as a means of reducing the need for pre-committed harm-allocation logic, framing further study as a technical improvement opportunity rather than a deployment prerequisite
Engineer A — Autonomous Vehicle Risk Assessment Team Member
Given that no applicable national or industry standards govern autonomous vehicle harm-allocation decision logic, must Engineer A affirmatively disclose to the automobile manufacturer that the harm-minimization recommendation is grounded in a utilitarian ethical framework rather than a technically mandated norm — and must Engineer A further recommend that the manufacturer publicly disclose the algorithm's embedded moral framework to prospective consumers before deployment?
Engineer A's obligation to disclose to the automobile manufacturer that the harm-minimization recommendation reflects a specific moral framework rather than a universally accepted engineering standard, and to recommend public disclosure of the embedded ethical framework to prospective consumers before deployment — particularly in the absence of applicable regulatory or industry standards
Explicitly identify in the written risk assessment report that the harm-minimization recommendation is grounded in a utilitarian ethical framework, present the deontological alternative framework and its different algorithmic implications with equal completeness, and include a specific advisory that the manufacturer implement pre-sale public disclosure of the vehicle's harm-allocation decision logic before deployment
Present both the passenger-priority and harm-minimization frameworks objectively in the risk assessment report — including their respective advantages and disadvantages — without characterizing either as utilitarian or deontological, and recommend that the manufacturer consult legal counsel and ethics advisors regarding consumer disclosure obligations, treating the philosophical labeling and public disclosure questions as outside the scope of the engineering risk assessment mandate
Identify the philosophical basis of the harm-minimization recommendation in the internal risk assessment report delivered to the manufacturer, recommend that the manufacturer seek interdisciplinary ethics review before finalizing the algorithm design, but decline to recommend specific consumer-facing public disclosure on the ground that disclosure strategy is a legal and business decision within the manufacturer's exclusive authority as client
Engineer A — Autonomous Vehicle Risk Assessment Team Member and Consultant
If the automobile manufacturer overrides Engineer A's harm-minimization recommendation and proceeds with a passenger-priority algorithm that foreseeably creates fatal risk for pedestrians, cyclists, and motorcycle riders, what actions must Engineer A take — and does Engineer A's consultant status affect the scope or sequence of those obligations?
Engineer A's residual obligations when the automobile manufacturer overrides the harm-minimization recommendation and elects to program the vehicle to prioritize passenger safety — including whether Engineer A must pursue graduated internal escalation, decline to certify the system, or evaluate external reporting obligations
Formally document the safety disagreement in writing addressed to the manufacturer's responsible decision-makers, clearly stating that the passenger-priority algorithm creates foreseeable fatal risk to third parties inconsistent with the public welfare paramount obligation; assess whether the system crosses the certification threshold under Code II.1.b and decline to certify if it does; and evaluate whether the severity and foreseeability of third-party harm triggers external reporting obligations if internal escalation fails
Formally document the safety disagreement in writing, deliver it to the manufacturer's project lead, and — upon being overruled — treat the internal escalation obligation as discharged given the compressed escalation sequence available in a consultant relationship; continue participating in the project in an advisory capacity without certifying the system, on the ground that declining to certify without an applicable regulatory standard to anchor the refusal would exceed the scope of the consultant's professional mandate
Document the safety disagreement in the final risk assessment report, recommend that the manufacturer obtain an independent ethics and safety review of the passenger-priority algorithm before deployment, and withdraw from the consulting engagement if the manufacturer proceeds without that review — treating withdrawal as the appropriate professional response that preserves Engineer A's integrity without triggering external reporting obligations that the NSPE Code reserves for more severe and imminent public safety threats
Engineer A — Consultant to Automobile Manufacturer
Should Engineer A recommend that the autonomous vehicle's operating system minimize harm to the least number of persons, and actively express that concern within the risk assessment team even under commercial pressure to prioritize passenger safety?
Engineer A's core obligation to recommend harm minimization for the least number of persons and to actively participate in the risk assessment team by unambiguously expressing safety concerns about the harm-allocation algorithm
Formally recommend that the harm-allocation algorithm minimize harm to the least number of persons, actively express this position within the risk assessment team, document the recommendation in writing, and propose further interdisciplinary study and exploration of dynamic real-time mitigation alternatives before deployment
Present the harm-minimization approach as one among several technically defensible design options, defer to the risk assessment team's collective judgment on which framework to adopt, and limit Engineer A's formal output to a balanced technical summary of competing approaches without a personal recommendation
Recommend harm minimization internally within the risk assessment team but accept the manufacturer's passenger-priority preference as a legitimate design policy choice within the manufacturer's authority, confining Engineer A's role to optimizing the passenger-priority algorithm's technical implementation rather than contesting the underlying policy
Must Engineer A affirmatively disclose to the automobile manufacturer that the harm-minimization recommendation is grounded in a utilitarian ethical framework rather than an established regulatory or industry standard, and must Engineer A further recommend that the manufacturer publicly disclose the vehicle's embedded ethical decision logic to consumers before deployment?
Engineer A's obligation to disclose to the automobile manufacturer that the harm-minimization recommendation reflects a specific moral philosophy rather than a universally accepted engineering standard, and to recommend pre-sale public disclosure of the embedded ethical framework to prospective consumers
Explicitly disclose to the automobile manufacturer in the technical report that the harm-minimization recommendation reflects a utilitarian moral philosophy rather than an established engineering standard, identify deontological and other alternative frameworks that yield different outcomes, and affirmatively recommend that the manufacturer implement pre-sale consumer disclosure of the vehicle's harm-allocation decision logic as a condition of ethically responsible deployment
Disclose the philosophical basis of the harm-minimization recommendation to the manufacturer's engineering and legal teams as part of the confidential consulting deliverable, but limit the consumer disclosure recommendation to a general advisory that the manufacturer consult legal counsel about disclosure obligations, leaving the public transparency decision to the manufacturer's business judgment
Present the harm-minimization recommendation as Engineer A's professional judgment grounded in the NSPE Code's public welfare paramount obligation without characterizing it as utilitarian or labeling its philosophical foundations, on the basis that the Code itself — rather than a contested moral philosophy — provides the normative authority for the recommendation, and defer consumer disclosure questions to the manufacturer and its regulatory counsel
If the automobile manufacturer overrides Engineer A's harm-minimization recommendation and programs the vehicle to prioritize passenger safety above third-party welfare, what actions must Engineer A take — and does Engineer A's consultant status alter the scope or sequence of those obligations?
Engineer A's residual obligations when the automobile manufacturer overrides the harm-minimization recommendation — including graduated internal escalation, assessment of whether to certify the system, and evaluation of whether external reporting is triggered — and how the consultant relationship affects the scope and sequence of those obligations
Formally document the safety disagreement in writing to the manufacturer's responsible decision-makers, decline to certify or approve the passenger-priority system if it cannot be reconciled with the public welfare paramount obligation, and evaluate whether the foreseeability and severity of third-party fatal harm triggers an external reporting obligation beyond the consulting engagement
Document the safety concern in the consulting deliverable, communicate the disagreement verbally to the manufacturer's project lead, and continue participating in the technical optimization of the passenger-priority system while treating the manufacturer's policy override as a legitimate business decision within the client's authority — on the basis that Engineer A's professional duty is satisfied by having raised the concern and that the manufacturer bears ultimate design responsibility
Withdraw from the consulting engagement upon the manufacturer's override without formal written documentation of the specific certification threshold crossed, on the basis that the consultant relationship does not obligate Engineer A to pursue multi-tier internal escalation through an organization in which Engineer A holds no employment standing, and that withdrawal itself constitutes a sufficient professional signal of non-endorsement
Do No Harm Obligation Invoked by Engineer A in Autonomous Vehicle Case
Autonomous vehicle operating system deployment recommendation
Automobile manufacturer's commercial deployment interests
Engineer A's obligation to propose further study of the autonomous vehicle operating system before deployment is grounded in the do no harm principle — the uncertainties and risks identified in the system's harm-distribution algorithms create a harm-avoidance obligation to recommend additional study rather than proceeding with deployment
In the autonomous vehicle context, do no harm requires Engineer A to propose further study when the risk assessment reveals unresolved uncertainties about how the system will distribute harm among affected parties
Do No Harm Obligation in Professional Engineering Services
In light of the fact that engineers should strive to seek to do no harm in the performance of their professional services, if necessary, Engineer A should propose that further study be undertaken by the company before the autonomous vehicle operating system is utilized.
Do no harm obligation requires proposing further study as a precondition to deployment when risks are not adequately resolved
Do No Harm Obligation Invoked by Engineer A in Software Testing Case
Public-safety-critical facility software deployment
In BER Case 96-4, Engineer A's ethical obligation to recommend additional software testing was grounded in the principle that engineers must strive to do no harm — the possibility that the software might not meet new draft standards created a harm-avoidance obligation to recommend testing even at significant financial cost
The do no harm principle required Engineer A to recommend additional testing despite financial pressures, because proceeding without testing created a foreseeable risk of harm to public-safety-critical facilities
Engineer A Safety-Critical Software Design Engineer (Case 96-4)
Implicit in Case 96-4 is the notion that in seeking to fulfill one's ethical obligations, engineers should strive to do no harm in the performance of their professional services.
Do no harm obligation required the testing recommendation to be made on technical grounds, with business considerations addressed separately by the employer
Draft Safety Testing Standard for Autonomous Vehicle Operating Systems (referenced but unnamed)
Engineer A and the engineering risk management team in evaluating autonomous vehicle system safety
Represents the emerging technical standard that the autonomous vehicle operating system may not meet, triggering Engineer A's obligation to recommend further study and risk assessment before deployment; analogous to the new draft standards in BER Case 96-4
Engineer A AV Active Participation Concern Expression Constraint
Engineer A was a consultant to an automobile manufacturer serving on an engineering risk assessment team. The autonomous vehicle operating system's harm-allocation decision logic raised unresolved safety concerns regarding third-party harm to pedestrians, cyclists, and motorcycle riders.
Autonomous Vehicle Risk Management Active Participation Constraint
Engineer A was constrained from passive participation or silence about identified safety concerns in the autonomous vehicle risk management process, and was required to fully and actively participate as a member of the engineering risk management team, clearly and unambiguously expressing all concerns regarding the safety of the proposed autonomous vehicle operating system.
NSPE Code of Ethics; BER Case 16-5; present BER case
Engineer A has a responsibility to fully and actively participate as a member of the engineering risk management team, clearly and unambiguously express any and all concerns he has regarding the safety of the proposed autonomous vehicle operation system
Throughout Engineer A's participation on the automobile manufacturer's engineering risk management team
The overriding ethical responsibility of a professional engineer is to hold paramount the safety, health, and welfare of the public.
Engineer A AV Client Interest Third-Party Safety Priority Constraint
The automobile manufacturer has a commercial interest in a passenger-protective algorithm, while Engineer A's paramount obligation to public safety requires consideration of the fatal harm that such an algorithm may cause to third parties.
Client Loyalty vs. Public Safety Priority Constraint
Engineer A was constrained by the priority rule establishing that when obligations to the automobile manufacturer client — including the client's commercial interest in a passenger-protective algorithm — conflict with obligations to public safety, including the safety of pedestrians, cyclists, and motorcycle riders who may be fatally harmed by a passenger-priority algorithm, the public safety obligation takes precedence, prohibiting Engineer A from fulfilling client directives that would compromise public welfare.
NSPE Code of Ethics Section II.1; Client Loyalty vs. Public Safety Priority Constraint
Throughout Engineer A's consulting engagement with the automobile manufacturer
striking and potentially causing a fatal injury to a pedestrian, cyclist, or motorcycle rider
Engineer A AV Crash Scenario Technical Safety Analysis Capability
Unavoidable Crash Scenario Technical Safety Analysis Capability
Engineer A possessed the technical capability to analyze the specific unavoidable crash scenarios presented to the risk assessment team — including estimating injury probability and severity for passengers and third parties under alternative crash trajectories — and to produce a technically grounded comparative safety analysis informing the harm minimization algorithm design recommendation.
The risk assessment team scenario required technical analysis of crash outcome probabilities and injury severity comparisons to inform the harm minimization algorithm design recommendation.
Analysis of the specific scenario involving a vehicle choosing between crashing into a stationary object (causing serious but non-life-threatening passenger injuries) versus striking a pedestrian, cyclist, or motorcycle rider (potentially causing fatal injury), requiring technical assessment of outcome probabilities and severity distributions.
In the event of an unavoidable crash, does the vehicle's system choose the outcome that will likely result in the greatest potential for safety for the vehicle's passengers
Engineer A AV Do No Harm Deployment Constraint
Engineer A was a consultant to an automobile manufacturer serving on an engineering risk assessment team evaluating an autonomous vehicle operating system whose harm-allocation decision logic pre-commits to outcomes affecting passengers and third parties including pedestrians, cyclists, and motorcycle riders.
Do No Harm Professional Services Constraint
Engineer A was constrained by the 'do no harm' principle from recommending deployment of the autonomous vehicle operating system without first exploring all available technical options to mitigate identified risks and, if necessary, recommending further study before the system is utilized.
NSPE Code of Ethics; BER Case 96-4 (analogical precedent); present BER case
Throughout Engineer A's participation on the autonomous vehicle engineering risk management team
in light of the fact that engineers should strive to seek to do no harm in the performance of their professional services, if necessary, Engineer A should propose that further study be undertaken by the company before the autonomous vehicle operating system is utilized.
Engineer A AV Do No Harm Design Obligation Safety Constraint
The autonomous vehicle operating system's harm-allocation algorithm pre-commits to causing harm to either passengers or third parties in unavoidable crash scenarios, requiring Engineer A to apply the 'do no harm' principle in formulating the recommendation.
Engineer A was constrained by the 'do no harm' principle in autonomous system design — requiring that the harm-allocation algorithm recommendation minimize foreseeable harm to all persons who may be affected by the autonomous vehicle system, including third parties such as pedestrians, cyclists, and motorcycle riders — prohibiting Engineer A from recommending a system design that foreseeably maximizes harm to identifiable third-party classes as a pre-committed algorithmic outcome.
NSPE Code of Ethics Section II.1; BER Case 16-5; ISO 26262 Automotive Functional Safety Standard
During Engineer A's evaluation and recommendation of harm-allocation decision logic
Engineer A AV Ethical Framework Selection Capability
Autonomous Vehicle Harm Minimization Algorithm Ethical Framework Selection Capability
Engineer A, as a professional engineer and consultant to the automobile manufacturer assigned to the engineering risk assessment team, possessed the capability to identify and evaluate competing ethical frameworks for encoding harm minimization decisions into the autonomous vehicle operating system — including the passenger-priority approach versus the least-harm-to-all approach — and to recommend a defensible ethical framework to the manufacturer.
Engineer A was assigned to evaluate the specific scenario of unavoidable crash decision logic for an autonomous vehicle operating system, requiring selection among competing ethical frameworks for algorithm design.
Assignment to and participation in the engineering risk assessment team evaluating the unavoidable crash scenario, including deliberation about whether the vehicle system should prioritize passenger safety or minimize total harm to all parties including pedestrians, cyclists, and motorcycle riders.
Engineer A is assigned to an engineering risk assessment team whose members are being asked to make a recommendation relating to potential situations that could arise in connection with the operation of driverless/autonomous vehicles.
Engineer A AV Faithful Agent Informed Decision Enablement Obligation
Engineer A serves as a consultant to the automobile manufacturer and is assigned to the engineering risk assessment team, creating a faithful agent relationship in which the engineer owes the manufacturer complete and honest advisory services within the bounds of professional ethics.
Engineer A, as a consultant to the automobile manufacturer, was obligated to act as a faithful agent by providing the manufacturer with a diligent, competent, and complete risk assessment — including all material findings about both harm-distribution frameworks — so that the manufacturer could make a fully informed decision about the crash-avoidance algorithm's design, while remaining bound by the paramount obligation to protect public health, safety, and welfare.
Throughout the risk assessment engagement
Engineer A AV Further Study Before Deployment Constraint
The risk assessment team is evaluating harm-allocation decision logic in the absence of established national or industry standards governing autonomous vehicle harm-allocation ethics, creating a regulatory standards vacuum that heightens the obligation to recommend further study.
Further Study Recommendation Before Unreliable System Deployment Constraint
Engineer A was constrained to recommend that further study be conducted before the autonomous vehicle operating system — including its harm-allocation decision logic — is deployed, given the absence of established regulatory or industry standards governing autonomous vehicle harm-allocation ethics, the unresolved moral and safety trade-offs between passenger-priority and harm-minimization algorithms, and the foreseeable risk of fatal harm to third parties.
NSPE Code of Ethics Section II.1; BER Case 16-5; BER Case 20-4; Further Study Recommendation Before Unreliable System Deployment Constraint
Prior to any deployment recommendation for the autonomous vehicle operating system
Engineer A AV Further Study Recommendation Before Deployment Obligation
The risk assessment team is evaluating a scenario involving unavoidable crashes where the algorithm must choose between passenger safety and third-party harm minimization — a question with unresolved ethical dimensions that may require further study before deployment.
Autonomous Vehicle Further Study Recommendation Before Deployment Obligation
Engineer A, as a member of the automobile manufacturer's engineering risk assessment team, was obligated to recommend that further study be conducted before the autonomous vehicle operating system is deployed for public use, if material ethical, safety, or technical questions regarding the crash-avoidance algorithm's harm-distribution logic remained unresolved at the time of the team's recommendation.
At the time of preparing and delivering the risk assessment team's recommendation to the automobile manufacturer, if unresolved questions remain
In the event of an unavoidable crash, does the vehicle's system choose the outcome that will likely result in the greatest potential for safety for the vehicle's passengers or does the vehicle's software system instead choose an option in which the least amount of potential harm is done to any of those involved in an accident
Engineer A AV Further Study Recommendation Capability
Further Study Recommendation Before Unreliable Energy System Deployment Capability
Engineer A possessed the capability to recognize when unresolved safety concerns about the autonomous vehicle operating system's harm minimization algorithm — including unresolved questions about the ethical framework for crash decision logic — warranted a recommendation that further study be conducted before the operating system is deployed, and to communicate this recommendation clearly and unambiguously to the automobile manufacturer as a professional obligation.
Engineer A's obligation to recommend further study before deployment when safety concerns remain unresolved is directly analogous to the existing capability class, which was itself derived from BER 16-5 — the same case type as the present case.
Obligation to recommend further study before deployment of the autonomous vehicle operating system when safety concerns about the harm minimization algorithm remain unresolved, by analogy to the BER 16-5 autonomous vehicle precedent.
Engineer A AV Further Study Recommendation Constraint
Engineer A identified unresolved safety concerns about the autonomous vehicle operating system's harm-allocation decision logic. The system operated in a regulatory standards vacuum. The 'do no harm' principle required that further study be recommended if concerns could not be resolved through available mitigation options.
Engineer A was constrained from remaining silent about the need for further study when identified safety concerns about the autonomous vehicle operating system had not been adequately resolved, and was required to propose that further study be undertaken by the company before the autonomous vehicle operating system is utilized.
NSPE Code of Ethics; BER Case 16-5; BER Case 96-4; present BER case
if necessary, Engineer A should propose that further study be undertaken by the company before the autonomous vehicle operating system is utilized.
If, after active participation and expression of concerns and exploration of mitigation options, safety concerns remained unresolved prior to deployment
New technologies often introduce new uncertainties and sometimes significant risk. The overriding ethical responsibility of a professional engineer is to hold paramount the safety, health, and welfare of the public.
Engineer A AV Good Faith Safety Concern Objective Testimony Constraint
No established standards exist governing autonomous vehicle harm-allocation ethics, meaning Engineer A's concerns — while professionally grounded — cannot be characterized as violations of non-existent standards.
Good Faith Safety Concern Without Demonstrable Violation Escalation Boundary Constraint
Engineer A was constrained, in the absence of established regulatory or industry standards governing autonomous vehicle harm-allocation ethics, to distinguish between a confirmed safety violation (which would trigger mandatory external reporting) and a good-faith professional concern about the moral and safety implications of the harm-allocation algorithm (which permits but does not mandate external regulatory testimony), and was prohibited from overstating the certainty or severity of unconfirmed concerns in any public or regulatory forum.
NSPE Code of Ethics Section II.3; BER Case 96-4; Good Faith Safety Concern Without Demonstrable Violation Escalation Boundary Constraint
Throughout Engineer A's participation in the risk assessment team and any subsequent regulatory engagement
Engineer A AV Harm Allocation Algorithm Completeness Disclosure Constraint
Engineer A must recommend between two morally distinct algorithmic approaches — passenger-priority and harm-minimization — each of which pre-commits the autonomous vehicle to causing harm to an identifiable class of persons in unavoidable crash scenarios.
Autonomous Vehicle Harm Allocation Algorithmic Pre-Commitment Ethical Constraint
Engineer A was constrained from recommending a harm-allocation algorithm for the autonomous vehicle operating system without ensuring that the risk assessment team's report fully discloses the moral framework embedded in the algorithm — including the trade-offs between passenger safety and third-party harm minimization — prohibiting Engineer A from treating the harm-allocation decision as a purely technical matter and requiring that the ethical premises of the recommended algorithm be surfaced, disclosed, and subjected to public and regulatory scrutiny.
NSPE Code of Ethics Sections II.1, II.4, III.6.b, II.4.a; BER Case 16-5; Autonomous Vehicle Harm Allocation Algorithmic Pre-Commitment Ethical Constraint
During Engineer A's formulation and submission of recommendations to the risk assessment team and the automobile manufacturer
Engineer A AV Harm Allocation Moral Framework Non-Deception Public Disclosure Constraint
The harm-allocation algorithm pre-commits the autonomous vehicle to a moral choice — either prioritizing passenger safety or minimizing aggregate harm — that will affect third parties who have no knowledge of or consent to the embedded moral framework.
Autonomous Vehicle Moral Framework Undisclosed Pre-Commitment Non-Deception Constraint
Engineer A was constrained from permitting the autonomous vehicle operating system to be deployed with an undisclosed moral framework embedded in its harm-allocation decision logic — whether passenger-priority or harm-minimization — without recommending that the automobile manufacturer publicly disclose that moral framework to consumers and regulators, prohibiting Engineer A from treating the moral pre-commitment as a proprietary design detail exempt from public disclosure obligations.
NSPE Code of Ethics Section II.4 (non-deception); NSPE Code Section II.1 (paramount public safety); BER Case 16-5
During Engineer A's formulation of recommendations to the risk assessment team and the automobile manufacturer
Engineer A AV Harm Minimization Risk Management Participation
Autonomous Vehicle Harm Minimization Risk Management Participation Capability
Engineer A, as a member of the automobile manufacturer's engineering risk assessment team, possessed the capability to fully and actively participate in the engineering risk management process for harm minimization — including clearly and unambiguously expressing concerns regarding the safety of the operating system, contributing to deliberation about harm minimization outcomes in unavoidable crash scenarios, and recommending further study before the operating system is deployed when safety concerns remain unresolved.
Engineer A was assigned to the engineering risk assessment team and obligated to participate fully in deliberations about harm minimization in unavoidable crash scenarios for the autonomous vehicle operating system.
Active participation in the risk assessment team's evaluation of unavoidable crash scenarios and formulation of recommendations to the automobile manufacturer regarding harm minimization algorithm design.
The following scenario is among the situations that are being considered by the engineering risk assessment team
Engineer A AV Informed Employer Decision Enablement Constraint
Engineer A was a consultant to an automobile manufacturer. The manufacturer needed complete information about the autonomous vehicle operating system's safety concerns and available mitigation options to make an informed decision about deployment. Engineer A's role as faithful agent required enabling that informed decision.
Safety-Critical Software Informed Employer Decision Enablement Obligation
Engineer A was constrained from withholding or obscuring material safety information from the automobile manufacturer, and was required to ensure that the manufacturer had complete, clear, accurate, and direct information about identified safety concerns and available mitigation options to enable an informed deployment decision.
NSPE Code of Ethics Sections III.6.b and II.4.a; BER Case 96-4 (analogical precedent); present BER case
Engineer A was in a strong position to assist his employer, and ultimately his employer's client, in carefully evaluating all of the appropriate facts and circumstances in order to take a course of action.
the company could make an informed decision about the need for additional testing and its effects on the public health, safety, and welfare.
Engineer A AV Moral Framework Public Transparency Recommendation Obligation
The risk assessment team is evaluating the ethical framework to be embedded in the autonomous vehicle's crash-avoidance algorithm, a decision with significant public welfare implications that the public has a legitimate interest in understanding.
Autonomous Vehicle Moral Framework Public Transparency Disclosure Obligation
Engineer A, as a member of the automobile manufacturer's engineering risk assessment team, was obligated to recommend that the automobile manufacturer publicly disclose the moral framework embedded in the crash-avoidance algorithm — including whether the system prioritizes passenger safety or total-harm minimization — so that the public, regulators, and prospective purchasers can make informed decisions about the autonomous vehicle system.
At the time of preparing and delivering the risk assessment team's recommendation to the automobile manufacturer, and before public deployment of the operating system
Engineer A AV Passenger Priority Algorithm Third-Party Fatal Harm Non-Subordination Constraint
The risk assessment team scenario explicitly presents the binary choice between a passenger-protective algorithm and a harm-minimization algorithm, with the harm-minimization option potentially causing serious but non-life-threatening injuries to passengers while avoiding fatal injury to pedestrians, cyclists, or motorcycle riders.
Autonomous Vehicle Third-Party Fatal Harm Passenger Priority Non-Subordination Constraint
Engineer A was constrained from recommending or acquiescing in a harm-allocation algorithm that categorically prioritizes passenger safety over the safety of third parties — including pedestrians, cyclists, and motorcycle riders — when the foreseeable consequence of that prioritization is fatal or serious injury to those third parties, requiring Engineer A to at minimum recommend further study, public disclosure of the moral framework, and regulatory engagement before any such algorithm is deployed.
NSPE Code of Ethics Section II.1 (paramount public safety); BER Case 16-5; Autonomous Vehicle Risk Management Active Participation Constraint
During Engineer A's evaluation and recommendation of harm-allocation decision logic for the autonomous vehicle operating system
Engineer A AV Public Transparency Advocacy Capability
Autonomous Vehicle Moral Algorithm Public Transparency Advocacy Capability
Engineer A possessed the capability to recognize that the moral framework encoded in the autonomous vehicle's harm minimization algorithm constitutes information of significant public interest, and to recommend that the automobile manufacturer publicly disclose the ethical framework and decision logic embedded in the operating system to enable informed consumer and regulatory decision-making.
Engineer A's role on the risk assessment team included the obligation to recommend that the manufacturer publicly disclose the ethical framework embedded in the AV operating system, consistent with professional transparency obligations.
Obligation to recommend public disclosure of the moral framework underlying the harm minimization algorithm as part of the risk assessment team's recommendations to the automobile manufacturer.
Engineer A AV Regulatory Standards Vacuum Escalation Permissibility Constraint
No established national or industry standards govern autonomous vehicle harm-allocation decision logic ethics, creating a regulatory standards vacuum that shapes the permissible form and content of Engineer A's escalation.
Regulatory Standards Vacuum Heightened Escalation Permissibility Constraint
Engineer A was constrained by the absence of applicable governmental or industry standards governing autonomous vehicle harm-allocation ethics — a regulatory standards vacuum — which did not eliminate Engineer A's ability to escalate safety concerns to regulatory authorities, but simultaneously constrained the form of that escalation by requiring that Engineer A clearly communicate the absence of applicable standards, the basis for the professional concern, and the distinction between the absence of standards and the identified residual ethical and safety risk.
NSPE Code of Ethics Section II.1; BER Case 96-4; Regulatory Standards Vacuum Heightened Escalation Permissibility Constraint
Throughout Engineer A's assignment to the risk assessment team and any subsequent escalation actions
Engineer A AV Regulatory Standards Vacuum Heightened Disclosure Constraint
No established national or industry standards governed autonomous vehicle harm-allocation ethics at the time of Engineer A's engagement. The regulatory standards vacuum meant that Engineer A could not rely on external standards compliance as a proxy for safety adequacy, heightening the obligation to apply independent professional judgment.
Engineer A was constrained by the absence of applicable regulatory or industry standards governing autonomous vehicle harm-allocation decision logic from treating regulatory silence as permission to proceed without further study, and was required to apply heightened professional judgment and recommend further study when the regulatory standards vacuum left unresolved safety concerns without an external benchmark for adequacy.
Engineer A AV Risk Assessment Active Participation Capability
Engineer A possessed the capability to fully and actively participate in the automobile manufacturer's engineering risk management team, clearly and unambiguously express concerns regarding the safety of the autonomous vehicle operating system, and contribute to deliberation about harm minimization outcomes in unavoidable crash scenarios.
Engineer A served as a consultant on the automobile manufacturer's engineering risk assessment team evaluating scenarios for a driverless vehicle operating system
Active participation in the engineering risk assessment team evaluating harm minimization scenarios for the driverless vehicle operating system, including expressing concerns and exploring additional technical options to mitigate identified risks
Engineer A AV Risk Assessment Active Participation Constraint
Engineer A is assigned to an engineering risk assessment team evaluating harm-allocation decision logic for an autonomous vehicle operating system, including the scenario of unavoidable crash outcomes affecting passengers versus third parties.
Engineer A, as a member of the automobile manufacturer's engineering risk assessment team, was constrained to fully and actively participate in the risk management process — including expressing clearly and unambiguously any concerns regarding the safety of the autonomous vehicle operating system's harm-allocation decision logic — and was prohibited from passive participation or silence about identified safety concerns, including concerns about the moral and safety implications of a passenger-priority versus harm-minimization algorithm.
NSPE Code of Ethics; BER Case 16-5; NSPE Code Section II.1 (paramount public safety obligation)
Throughout Engineer A's assignment to the engineering risk assessment team
Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation
Engineer A is a professional engineer serving as a consultant to an automobile manufacturer and assigned to an engineering risk assessment team evaluating scenarios for a driverless/autonomous vehicle operating system, including the scenario of how the system should handle unavoidable crashes involving passengers versus third parties.
Autonomous Vehicle Harm Minimization Risk Management Participation Obligation
Engineer A, as a member of the automobile manufacturer's engineering risk assessment team, was obligated to fully and actively participate in the evaluation of the crash-avoidance algorithm's harm-distribution logic, to express clearly and unambiguously any concerns regarding the safety of the operating system's harm-minimization framework, and if necessary to recommend further study before the operating system is deployed for public use.
During the risk assessment process, before any recommendation is finalized and before the operating system is deployed
Engineer A AV Risk Assessment Third-Party Safety Consideration Obligation
The risk assessment scenario explicitly juxtaposes passenger welfare against the welfare of pedestrians, cyclists, and motorcycle riders who could be fatally injured if the algorithm prioritizes passenger safety over total-harm minimization.
Autonomous Vehicle Third-Party Harm Minimization Safety Consideration Obligation
Engineer A, as a member of the automobile manufacturer's engineering risk assessment team, was obligated to explicitly identify, assess, and present the welfare of third parties — including pedestrians, cyclists, and motorcycle riders — as a material safety consideration in the team's recommendation, recognizing that the paramount duty to protect public health, safety, and welfare extends beyond the vehicle's passengers to all persons foreseeably affected by the autonomous system's operation in unavoidable crash scenarios.
At the time of preparing and delivering the risk assessment team's recommendation to the automobile manufacturer
Engineer A AV Risk Mitigation Option Exploration Constraint
Engineer A identified safety concerns about the autonomous vehicle operating system's harm-allocation decision logic, including risks to third parties such as pedestrians, cyclists, and motorcycle riders. The system operated in a regulatory standards vacuum with no established national or industry standards governing autonomous vehicle harm-allocation ethics.
Risk Mitigation Option Exploration Before Deployment Recommendation Constraint
Engineer A was constrained from recommending deployment of the autonomous vehicle operating system without first exploring all additional potential technical options that could mitigate the risks identified in the proposed system, and was required to present those options to the risk management team as part of his active participation.
During Engineer A's participation on the autonomous vehicle engineering risk management team, prior to any deployment recommendation
Engineer A AV Third-Party Harm Weighting Capability
Third-Party Stakeholder Harm Weighting in Safety-Critical Algorithm Design Capability
Engineer A possessed the capability to explicitly identify, assess, and present the welfare interests of third parties — including pedestrians, cyclists, and motorcycle riders — as distinct and morally significant considerations in the autonomous vehicle harm minimization algorithm design deliberations, ensuring that third-party harm was not systematically subordinated to passenger interests without ethical justification.
The risk assessment scenario explicitly required Engineer A to consider the interests of pedestrians, cyclists, and motorcycle riders as distinct from passenger interests in the harm minimization algorithm design.
Participation in risk assessment team deliberations that explicitly considered the scenario of a vehicle striking a pedestrian, cyclist, or motorcycle rider versus crashing into a stationary object, requiring explicit weighing of third-party harm against passenger harm.
does the vehicle's software system instead choose an option in which the least amount of potential harm is done to any of those involved in an accident
Engineer A Autonomous Vehicle Do No Harm Novel Technology Application Capability
Do No Harm Principle Application in Novel Technology Risk Assessment Capability
Engineer A possessed the capability to recognize and apply the do-no-harm principle to the autonomous vehicle operating system risk assessment, including the ability to identify when unresolved safety concerns about harm minimization algorithms required recommending further study before deployment.
Engineer A served as a consultant on an automobile manufacturer's engineering risk assessment team evaluating harm minimization scenarios for a driverless vehicle operating system
Fully and actively participating in the engineering risk management team, clearly expressing concerns about the autonomous vehicle operating system's safety, and proposing further study before deployment if necessary
Engineer A Autonomous Vehicle Do No Harm Obligation
The do-no-harm principle, identified as implicit in BER Case 96-4, is applied by the Board to the autonomous vehicle case to ground Engineer A's obligation to propose further study before deployment of an operating system with unresolved harm-distribution questions.
Engineer A (Present Case — Autonomous Vehicle)
Engineer A is obligated, in seeking to fulfill his ethical obligations as a member of the autonomous vehicle risk assessment team, to strive to do no harm in the performance of his professional services — including by ensuring that the autonomous vehicle operating system does not create foreseeable harm to passengers, pedestrians, or third parties that could be avoided through further study or technical mitigation.
Implicit in Case 96-4 is the notion that in seeking to fulfill one's ethical obligations, engineers should strive to do no harm in the performance of their professional services
Throughout the risk assessment process and before any deployment recommendation
Similarly, in the present case, Engineer A has a responsibility to fully and actively participate as a member of the engineering risk management team
Engineer A Autonomous Vehicle Further Study Recommendation Obligation
Engineer A's risk assessment team has identified unresolved questions about the crash-avoidance algorithm's harm-distribution logic, including whether the system should prioritize passenger safety or total-harm minimization. The do-no-harm principle requires that unresolved safety concerns be addressed before deployment.
Engineer A is obligated, if necessary after active participation and expression of concerns, to propose that further study be undertaken by the automobile manufacturer before the autonomous vehicle operating system is utilized, so that all foreseeable safety and ethical risks are identified and addressed before the system is released for public use.
in seeking to fulfill one's ethical obligations, engineers should strive to do no harm in the performance of their professional services
If unresolved safety or ethical concerns remain after active team participation and concern expression, before deployment recommendation is finalized
if necessary, Engineer A should propose that further study be undertaken by the company before the autonomous vehicle operating system is utilized
Engineer A Autonomous Vehicle Risk Assessment Active Participation Obligation
Engineer A serves as a consultant to an automobile manufacturer and is assigned to an engineering risk assessment team evaluating crash-avoidance algorithm scenarios for a driverless vehicle operating system, including scenarios involving unavoidable harm to passengers or third parties.
Autonomous Vehicle Risk Assessment Active Participation and Concern Expression Obligation
Engineer A is obligated to fully and actively participate as a member of the automobile manufacturer's engineering risk management team, clearly and unambiguously express all concerns regarding the safety of the proposed autonomous vehicle operating system, and explore additional technical options that could mitigate the identified risks.
Engineer A has a responsibility to fully and actively participate as a member of the engineering risk management team, clearly and unambiguously express any and all concerns he has regarding the safety of the proposed autonomous vehicle operation system, and explore additional potential technical options that could mitigate the risks identified in the proposed autonomous vehicle operating system
Throughout the risk assessment team's deliberations and before any deployment recommendation is finalized
{'license': 'Professional Engineer', 'employment_type': 'Consultant to automobile manufacturer', 'team_role': 'Risk assessment team member', 'specialty': 'Autonomous vehicle systems risk assessment'}
Engineer A is a professional engineer serving as a consultant to an automobile manufacturer and assigned to an engineering risk assessment team evaluating scenarios for autonomous vehicle operating systems, including algorithmic crash outcome decision logic that implicates trade-offs between passenger safety and third-party (pedestrian, cyclist, motorcyclist) safety.
{'type': 'consultant_to', 'target': 'Automobile Manufacturer Autonomous Vehicle Developer Client'}
{'type': 'public_responsibility', 'target': 'General Public including pedestrians, cyclists, and motorcyclists'}
{'type': 'team_member', 'target': 'Engineering Risk Assessment Team'}
Autonomous Vehicle Risk Assessment Team Engineer
Engineer A is a professional engineer working as a consultant to an automobile manufacturer
Engineer A BER 96-4 Additional Testing Recommendation Obligation
Engineer A's software passed existing standards but new draft standards were about to be released that the software might not meet. Testing was expensive and would delay implementation by at least six months, causing competitive disadvantage and significant financial cost.
New Draft Standard Awareness Additional Testing Recommendation Obligation
Engineer A was obligated to recommend to the software company that additional testing be undertaken, explaining why such testing was required, so that the company could make an informed decision about the need for additional testing and its effects on public health, safety, and welfare — notwithstanding the financial costs, competitive delay, and client pressure to proceed.
Engineer A had a professional obligation under the Code of Ethics to explain why additional testing was required and to recommend to his company that it be undertaken
Upon becoming aware of the new draft standards, before the employer's deployment decision
the company could make an informed decision about the need for additional testing and its effects on the public health, safety, and welfare
Engineer A BER 96-4 Business Pressure Non-Subordination Obligation
The software company faced significant financial pressure from clients eager to proceed, competitive disadvantage from delay, and potential public utility rate increases. Engineer A needed to balance these nontechnical factors without allowing them to distort his technical recommendation.
Technical Recommendation Business Pressure Non-Subordination Obligation
Engineer A was obligated to make his recommendation about additional testing based solely on technical findings, keeping the financial pressures — including financial impact on the company, the client, the public, potential job loss, and competitive disadvantage — separate and apart from the technical determination of whether additional testing was required.
At the time of formulating and delivering the technical recommendation to the employer
Engineer A's ethical obligations in Case 96-4 involved balancing a variety of ethical and other business considerations and making a recommendation based solely on technical finding (and not business considerations) to permit the company to make an informed decision
Engineer A BER 96-4 Business Pressure Technical Separation Constraint
Engineer A was employed by a software company designing safety-critical software for nuclear, air quality, and water quality facilities. Testing was extremely costly, clients were eager to proceed, and delay would cause competitive disadvantage and utility rate increases. Engineer A was asked to recommend whether additional testing was needed.
Business Pressure Technical Recommendation Separation Constraint
Engineer A was constrained from incorporating financial pressures — including costs to the software company, its clients, competitive disadvantage, job losses, and utility rate increases — into his technical recommendation about additional testing, and was required to formulate his recommendation based solely on technical findings, leaving business considerations to be weighed separately by the employer.
NSPE Code of Ethics Sections III.6.b and II.4.a; BER Case 96-4
it would seem that these nontechnical considerations were factors that needed to be given weight separate and apart from the decision as to whether the additional testing should be recommended by Engineer A.
At the time Engineer A was asked to make his recommendation about additional testing
The financial pressures that existed, including the financial impact on his company, the client, and the public, as well as the potential loss of jobs and delays if additional testing were to be pursued, were clearly important factors and needed to be addressed in some manner.
making a recommendation based solely on technical finding (and not business considerations) to permit the company to make an informed decision about the need for additional testing in furtherance of the public health, safety, and welfare.
Engineer A BER 96-4 Emerging Standard Technical Report Disclosure Constraint
Engineer A was aware of new draft standards about to be released by a standard-setting organization that the newly designed software might not meet, even though existing testing demonstrated the software was safe under current standards.
Emerging Standard Awareness Technical Report Disclosure Constraint
Engineer A was constrained from remaining silent about the new draft testing standards recently reported in professional literature that the designed software might not meet, and was required to reference those forthcoming standards in a technical report to his employer so that the employer could make an informed decision about additional testing.
Engineer A was aware of new draft standards that were about to be released by a standard setting organization—standards that the newly designed software might not meet.
At the time Engineer A prepared his recommendation and technical report
the Board noted that Engineer A would be well advised to prepare a technical report explaining the current testing analysis and results, as well as referencing the new testing procedure that had been recently reported in the professional literature, so that the engineer's employer could make an informed decision regarding additional testing (see Code Sections III.6.b. and II.4.a.).
Engineer A BER 96-4 Public Safety Paramount Safety-Critical Software Constraint
The software was designed for facilities with enormous impact on public health, safety, and welfare — nuclear, air quality control, and water quality control. Engineer A was aware of forthcoming standards the software might not meet, creating a potential public safety risk if deployed without additional testing.
Engineer A was constrained by the paramount public safety obligation from proceeding with a recommendation that prioritized business considerations — including client eagerness, competitive disadvantage, and utility rate increases — over the safety implications of deploying software that might not meet forthcoming standards in nuclear, air quality, and water quality facilities.
The industries using the software—water, air, and nuclear—clearly have an enormous impact on the public health, safety, and welfare, and therefore, Engineer A needed to be certain that the information imparted to his employer and to the employer's clients was clear, accurate, and direct.
At the time Engineer A formulated his recommendation about additional testing
Engineer A BER 96-4 Public Welfare Paramount Safety-Critical Software Obligation
Engineer A's software was designed for use in nuclear, air quality control, and water quality control facilities. The Board emphasized that these industries have an enormous impact on public health, safety, and welfare, heightening the engineer's obligation to ensure complete and accurate information.
Engineer A was obligated to hold paramount the safety, health, and welfare of the public in making his recommendation about additional software testing, recognizing that the industries using the software — water, air, and nuclear — have an enormous impact on public health, safety, and welfare, and that the information imparted to the employer and clients must be clear, accurate, and direct.
The industries using the software—water, air, and nuclear—clearly have an enormous impact on the public health, safety, and welfare, and therefore, Engineer A needed to be certain that the information imparted to his employer and to the employer's clients was clear, accurate, and direct
Throughout the design, testing, and recommendation process
The overriding ethical responsibility of a professional engineer is to hold paramount the safety, health, and welfare of the public
Engineer A BER 96-4 Technical Report Preparation Obligation
Engineer A designed specialized software for nuclear, air quality, and water quality facilities. The software passed existing standards but Engineer A became aware of new draft standards it might not meet. Testing was costly and clients were eager to proceed.
Engineer A was obligated to prepare a technical report explaining current testing analysis and results, and referencing the new testing procedure reported in professional literature, so that the software company employer could make an informed decision about the need for additional testing in furtherance of public health, safety, and welfare.
Engineer A would be well advised to prepare a technical report explaining the current testing analysis and results, as well as referencing the new testing procedure that had been recently reported in the professional literature, so that the engineer's employer could make an informed decision regarding additional testing (see Code Sections III.6.b. and II.4.a.)
Upon becoming aware of the new draft standards and before the employer's deployment decision
Engineer A Cross-Case Analogical Transfer BER 96-4 to AV Case Capability
Cross-Case Ethical Precedent Analogical Transfer Capability
The NSPE Board of Ethical Review demonstrated the capability to recognize that the ethical principles established in BER Case 96-4 (safety-critical software, new draft standards) were analogically transferable to the autonomous vehicle harm minimization case, identifying the shared normative structure — new technology uncertainty, public welfare paramountcy, do-no-harm obligation, and informed employer decision-making — and applying those transferable principles to reach justified conclusions in the novel autonomous vehicle context.
The Board applied BER Case 96-4 software testing principles to the autonomous vehicle harm minimization scenario, recognizing shared ethical structure across different technology domains
Explicitly identifying BER Case 96-4 as pertinent to the autonomous vehicle case despite different technology domains, and applying its principles to determine Engineer A's obligations in the AV risk assessment context
Engineer A / NSPE Board of Ethical Review
Similarly, in the present case, Engineer A has a responsibility to fully and actively participate as a member of the engineering risk management team...
Engineer A Ethical Dilemma — Harm Allocation Recommendation
Engineer A's obligation to recommend between two morally distinct algorithmic approaches, each of which causes harm to an identifiable class of persons
Recommendation submitted to automobile manufacturer
Risk assessment team asked to recommend harm-allocation logic for unavoidable autonomous vehicle crash scenarios
Engineer A Faithful Agent Informed Decision Enablement Capability
Informed Decision-Making Process Facilitation Capability
Engineer A, as a consultant to the automobile manufacturer, possessed the capability to structure and present professional analysis of the harm minimization algorithm scenarios in a manner that facilitated an informed decision-making process by the manufacturer — including presenting complete comparative information about all ethical framework options, identifying non-obvious consequences of each option (such as third-party harm and public transparency implications), and ensuring that the manufacturer had all material information needed to make a genuinely informed choice about the autonomous vehicle operating system design.
Engineer A's faithful agent obligation to the automobile manufacturer required facilitating an informed decision-making process about the harm minimization algorithm design, including presenting all material considerations about competing ethical frameworks and their public welfare implications.
Obligation to act as a faithful agent by providing the manufacturer with a diligent, complete, and objective analysis of the harm minimization scenarios, enabling the manufacturer to make an informed decision about the operating system design.
Engineer A is a professional engineer working as a consultant to an automobile manufacturer that is considering the development of a driverless/autonomous vehicle operating system.
Engineer A is assigned to an engineering risk assessment team whose members are being asked to make a recommendation
Engineer A Public Welfare Paramountcy Safety-Critical Software Capability
Public Welfare Paramountcy Recognition Capability
Engineer A possessed the capability to recognize that the industries using the safety-critical software — water, air, and nuclear — had an enormous impact on public health, safety, and welfare, and that this paramountcy required ensuring that information imparted to his employer and clients was clear, accurate, and direct, overriding business and financial considerations in the technical recommendation.
Engineer A recognized that safety-critical software for nuclear, air quality, and water quality facilities created heightened public welfare obligations that could not be subordinated to business considerations
Holding paramount public health, safety, and welfare in making his recommendation about additional software testing, despite significant financial pressures on the company, its clients, and the public
Engineer A Regulatory Gap Safety Escalation Software Standards Capability
Regulatory Gap Safety Escalation Recognition Capability
Engineer A possessed the capability to recognize that the existence of a new draft testing standard — not yet formally adopted — heightened rather than diminished his professional obligation to recommend additional testing, understanding that the gap between existing standards compliance and emerging standard requirements amplified the duty to report concerns and enable informed employer decision-making.
Engineer A's software passed existing standards but he became aware of new draft standards that the software might not meet, creating a regulatory gap situation
Recognizing that compliance with existing standards did not discharge the obligation to address the implications of the new draft standard, and recommending additional testing accordingly
Although the tests demonstrated that the software was safe to use under existing standards, Engineer A was aware of new draft standards that were about to be released by a standard setting organization—standards that the newly designed software might not meet.
Engineer A generally believed that the software designed by his company was safe, but he had become aware of a new testing procedure that was likely to demonstrate results that might cast a cloud over the software's viability.
{'license': 'Professional Engineer (implied)', 'specialty': 'Safety-critical software design and testing', 'domain': 'Nuclear, air quality control, water quality control facilities'}
Designed specialized software for public-safety-critical facilities, conducted extensive testing, became aware of new draft standards the software might not meet, and was asked by the company to recommend whether additional costly testing was required.
{'type': 'employee_of', 'target': 'Software Company Employer'}
{'type': 'serves_clients_of', 'target': 'Software Company Client'}
Safety-Critical Software Design Engineer
Engineer A was employed by a software company and was involved in the design of specialized software in connection with the operations of facilities affecting the public health and safety
Engineer A was aware of new draft standards that were about to be released
The software company requested Engineer A's recommendation on the need for additional testing
Engineer A Safety-Critical Software Informed Employer Decision Enablement Capability
Safety-Critical Software New Draft Standard Ethical Balancing Capability
Engineer A possessed the capability to prepare a technical report explaining current testing analysis and results, referencing the new draft testing procedure reported in professional literature, so that his employer could make an informed decision regarding additional testing and its effects on public health, safety, and welfare.
Engineer A needed to communicate the significance of new draft standards to his employer in a manner that separated technical findings from business considerations and enabled informed decision-making
Preparing a technical report that clearly communicated both existing test results and the implications of the new draft standard, enabling the software company to make an informed decision
The Board noted that Engineer A would be well advised to prepare a technical report explaining the current testing analysis and results, as well as referencing the new testing procedure that had been recently reported in the professional literature, so that the engineer's employer could make an informed decision regarding additional testing.
Engineer A needed to be certain that the information imparted to his employer and to the employer's clients was clear, accurate, and direct.
Engineer A's risk assessment team participation (present case) before autonomous vehicle operating system deployment
Explore Additional Technical Mitigation Options
Faithful Agent Obligation Within Ethical Limits Invoked for Engineer A Consultant Role
Third-Party Non-Client Welfare Consideration in Autonomous System Design
Engineer A, as a consultant to the automobile manufacturer, bears a faithful agent obligation to provide the manufacturer with a diligent, competent risk assessment recommendation — but this obligation is bounded by the ethical limits imposed by public welfare paramount and the obligation to consider third-party welfare, such that Engineer A cannot recommend a purely passenger-protective algorithm without disclosing its implications for third-party safety
The faithful agent obligation requires diligent service to the manufacturer's legitimate interests in developing a commercially viable autonomous vehicle system, but does not authorize Engineer A to suppress or minimize the public welfare implications of the harm-distribution choice in order to favor the manufacturer's commercial interests
The faithful agent obligation is satisfied by providing a complete, objective, and technically competent risk assessment that presents both frameworks and their implications — not by advocating for the commercially preferred framework at the expense of public welfare analysis
Financial Pressure on Testing (Event 3) → Unambiguously Express Safety Concerns (Action 4)
Good Faith Safety Concern Threshold Invoked in Software Testing Case
In BER Case 96-4, Engineer A's awareness of new draft standards that the software might not meet — even without confirmed failures — was sufficient to trigger a professional obligation to recommend additional testing, establishing that a good faith professional concern grounded in awareness of emerging standards is sufficient to generate a reporting and recommendation obligation
The good faith threshold for triggering a safety recommendation obligation does not require confirmed failures or demonstrated non-compliance — awareness of emerging standards that the system might not meet is sufficient
Good Faith Safety Concern Threshold for External Reporting
Good faith professional concern based on awareness of draft standards triggers the recommendation obligation even without confirmed non-compliance
A series of tests proposed by Engineer A would likely result in a decision whether to move forward with the use of the software.
Graduated Internal Escalation Before External Reporting Invoked in Software Testing Case
Software company employer's decision-making process
In BER Case 96-4, Engineer A's ethical obligation was to first exhaust internal escalation — recommending additional testing to the employer and preparing a technical report — before any consideration of external reporting, recognizing that the employer deserved the opportunity to make an informed decision about additional testing before external regulatory consequences were triggered
The graduated escalation principle required Engineer A to provide the employer with complete technical information and a clear recommendation before escalating further — the employer's informed decision was the appropriate first step in the escalation sequence
Graduated Internal Escalation Before External Reporting Obligation
In deciding that Engineer A had a professional obligation under the Code of Ethics to explain why additional testing was required and to recommend to his company that it be undertaken, the Board noted that if he did so, the company could make an informed decision about the need for additional testing and its effects on the public health, safety, and welfare.
Internal escalation through technical recommendation and report was the appropriate first step; further escalation would be required only if the employer failed to act on adequate information
ISO 26262 Automotive Functional Safety Standard
International Organization for Standardization
ISO 26262: Road Vehicles — Functional Safety
Engineering risk assessment team evaluating autonomous vehicle operating system design
Technical standard governing functional safety requirements for automotive electrical and electronic systems, including autonomous vehicle operating systems, providing a professional benchmark against which the risk assessment team's recommendations must be evaluated
Informed Decision-Making Enablement Obligation Invoked for Automobile Manufacturer Client
Engineer A's risk assessment team must ensure that the automobile manufacturer — as the non-engineer decision-making body that will ultimately determine the algorithm's design — receives all information relevant and pertinent to the harm-distribution decision, including the ethical, legal, reputational, and public welfare implications of each framework, so that the manufacturer can exercise genuinely informed judgment
The manufacturer is a non-engineer decision-maker who may not independently recognize the full ethical and public welfare implications of the algorithmic choice — Engineer A's obligation is to ensure that the recommendation enables genuinely informed decision-making by presenting all material considerations, not merely the technical optimization analysis
Informed Decision-Making Enablement Obligation
The informed decision-making enablement obligation reinforces rather than conflicts with the faithful agent obligation — serving the client well requires ensuring the client has complete information
Informed Decision-Making Enablement Obligation Invoked in Software Testing Case
Software company employer's decision about additional testing
Engineer A's obligation in BER Case 96-4 was to prepare a technical report explaining current testing results and referencing new testing procedures so that the employer could make an informed decision about additional testing — the engineer's role was to enable informed organizational decision-making, not to make the business decision itself
The informed decision-making enablement obligation required Engineer A to provide complete, accurate, and direct technical information — including reference to new draft standards — so that the employer could evaluate all relevant facts before deciding whether to proceed
The engineer's obligation is to enable informed decision-making by providing complete technical information; the employer then makes the business decision with full knowledge of the technical landscape
National Society of Professional Engineers
Engineer A in deliberating ethical obligations during autonomous vehicle risk assessment
Primary normative authority governing Engineer A's professional obligations as a consultant to an automobile manufacturer conducting risk assessment on autonomous vehicle systems, including obligations to hold public safety paramount and to act with objectivity and integrity
NSPE Code of Ethics for Engineers, Sections III.6.b. and II.4.a.
The Board noted that Engineer A would be well advised to prepare a technical report explaining the current testing analysis and results, as well as referencing the new testing procedure that had been recently reported in the professional literature, so that the engineer's employer could make an informed decision regarding additional testing (see Code Sections III.6.b. and II.4.a.).
NSPE Board of Ethical Review in analyzing Engineer A's obligations
Cited by the Board of Ethical Review as the basis for Engineer A's obligation to prepare a technical report explaining testing analysis and results, and to provide clear, accurate, and direct information to employer and clients regarding public health, safety, and welfare implications
Passenger Safety vs. Third-Party Harm Minimization Algorithm Conflict
From identification of the binary algorithm choice through submission of the risk assessment recommendation
Client-Interest vs. Third-Party Safety Algorithmic Pre-Commitment State
Structural conflict between automobile manufacturer's commercial interest in passenger-protective algorithms and Engineer A's obligation to minimize aggregate public harm
Recommendation submitted; client adopts a harm-allocation standard; or Engineer A withdraws from engagement
Risk assessment team presented with binary choice between passenger-protective algorithm and harm-minimizing algorithm for unavoidable crash scenarios
Precedent Case Principles Activated (Event 6) → Actively Participate in Risk Assessment (Action 3) + Prepare Transparent Technical Report (Action 2)
Present Case Autonomous System Harm Allocation Design
From Engineer A's engagement on autonomous vehicle operating system through deployment decision
Engineer A has a responsibility to fully and actively participate as a member of the engineering risk management team
Engineer A's design of autonomous vehicle operating system decision logic pre-committing harm allocation
Company's informed deployment decision after Engineer A's complete technical assessment and risk management participation
clearly and unambiguously express any and all concerns he has regarding the safety of the proposed autonomous vehicle operation system
Engineer A engaged to design autonomous vehicle operating system requiring pre-programmed harm allocation decisions
Present Case Autonomous Vehicle Do No Harm Design Obligation
From Engineer A's engagement on the autonomous vehicle operating system through resolution of identified safety concerns or pre-deployment study recommendation
Do No Harm Autonomous System Design Obligation State
Engineer A's obligation to apply 'do no harm' principle in autonomous vehicle operating system design
Engineer A's complete expression of safety concerns, exploration of mitigation options, and recommendation of further study if needed; followed by company's informed deployment decision
engineers should strive to do no harm in the performance of their professional services
Engineer A engaged to design or evaluate autonomous vehicle operating system with pre-committed harm allocation logic and identified residual safety risks
Present Case Client-Interest vs Third-Party Safety Algorithmic Pre-Commitment
Throughout Engineer A's design and evaluation of the autonomous vehicle operating system
Engineer A's obligation to recommend autonomous vehicle decision logic balancing passenger and third-party safety
Engineer A's complete technical recommendation after exploring all mitigation options and expressing all safety concerns
Engineer A required to recommend algorithmic decision rules permanently pre-committing autonomous vehicle harm allocation between passengers and third parties
Present Case Regulatory Standards Vacuum for Autonomous Vehicle Ethics
Throughout Engineer A's engagement on the autonomous vehicle operating system design
New technologies often introduce new uncertainties and sometimes significant risk
Regulatory Standards Vacuum for Autonomous Vehicle Ethics State
Absence of established national or industry standards governing autonomous vehicle harm allocation ethics
Adoption of applicable national, governmental, or industry-specific standards governing autonomous vehicle harm allocation
Engineer A tasked with making recommendations about autonomous vehicle ethical decision logic in absence of established standards
Professional Competence in Risk Assessment Invoked for Autonomous Vehicle Scenario
Autonomous vehicle crash-avoidance algorithm risk assessment
Engineer A's risk assessment team must apply specialized professional competence to identify, assess, and characterize the risks associated with each harm-distribution framework — including the probability and magnitude of harm to passengers versus third parties under each scenario — providing the automobile manufacturer with a technically grounded risk analysis rather than a purely philosophical opinion
Professional competence in risk assessment requires Engineer A to quantify — to the extent possible — the probability and severity of harm under each algorithmic framework, including the likelihood of unavoidable crash scenarios, the distribution of injury severity between passengers and third parties, and the systemic public safety implications of each approach
Professional Competence in Risk Assessment
Technical risk assessment competence and ethical analysis are complementary obligations — the risk assessment must be both technically rigorous and ethically complete
Public Safety at Risk — Autonomous Vehicle Third-Party Harm
From identification of the crash scenario through deployment of autonomous vehicles with the recommended algorithm
Risk of fatal or serious injury to pedestrians, cyclists, and motorcycle riders arising from autonomous vehicle harm-allocation algorithm design choices
Adoption of harm-minimizing algorithm; regulatory prohibition of passenger-only protective algorithms; or abandonment of autonomous vehicle development
Risk assessment team identifies that one algorithmic option results in potential fatal injury to pedestrians, cyclists, or motorcycle riders
Public Welfare Paramount Invoked in Autonomous Vehicle Crash Algorithm Design
Autonomous vehicle crash-avoidance algorithm design recommendation
Engineer A's risk assessment team must evaluate whether the autonomous vehicle's crash-avoidance algorithm should prioritize passenger safety or minimize total harm to all involved parties — including pedestrians, cyclists, and motorcyclists — with the public welfare obligation requiring that the welfare of all affected persons, not merely vehicle occupants, be held paramount in the recommendation
In this context, public welfare paramount requires Engineer A to advocate for a harm-minimization framework that gives weight to the lives and safety of third-party non-passengers, not merely to the commercial interests of the automobile manufacturer or the preferences of vehicle purchasers who might prefer passenger-protective algorithms
Public welfare paramount does not resolve the trolley-problem dilemma definitively, but it requires that the recommendation not categorically subordinate third-party welfare to passenger welfare without explicit ethical justification and stakeholder deliberation
Public Welfare Paramount Invoked in Autonomous Vehicle Risk Assessment
Autonomous vehicle operating system deployment decision
Engineer A's overriding ethical responsibility as a member of the autonomous vehicle risk assessment team is to hold paramount the safety, health, and welfare of the public — including third parties who may be harmed by the autonomous vehicle's harm-distribution decisions — above the automobile manufacturer's commercial interests in deploying the system
In the autonomous vehicle context, holding public welfare paramount requires Engineer A to fully express safety concerns, explore technical mitigation options, and propose further study before deployment — the public welfare obligation is not discharged by passive team participation or acquiescence to business pressure
Public welfare paramount overrides business and schedule considerations in determining whether Engineer A must recommend further study — the Board affirms that the overriding ethical responsibility is public welfare
Qualitative Risk Assessment Methodology for Autonomous Vehicle Crash Scenarios
Engineering risk assessment team / automobile manufacturer
Risk Assessment Framework for Unavoidable Crash Scenarios in Autonomous Vehicle Systems
Structured professional methodology for estimating and communicating the likelihood and magnitude of potential harm to passengers, pedestrians, cyclists, and motorcyclists in unavoidable crash scenarios, used by the engineering risk assessment team to evaluate competing design options for the vehicle's decision logic
What are Engineer A’s ethical obligations?
Does the Board's conclusion that Engineer A must recommend minimizing harm to the least number of persons implicitly adopt a utilitarian ethical framework, and if so, is Engineer A obligated to disclose to the automobile manufacturer that this recommendation reflects a specific moral philosophy rather than a universally accepted engineering standard?
In the absence of applicable regulatory or industry standards governing autonomous vehicle harm-allocation decision logic, does Engineer A have an affirmative obligation to recommend that the automobile manufacturer publicly disclose the ethical framework embedded in the vehicle's operating system to prospective consumers before deployment?
If the automobile manufacturer, after receiving Engineer A's recommendation to minimize aggregate harm, decides to override that recommendation and program the vehicle to prioritize passenger safety above all others, what are Engineer A's remaining ethical obligations — including whether Engineer A must refuse to continue consulting on the project or escalate concerns externally?
Does Engineer A's role as a consultant to the automobile manufacturer — rather than a direct employee — alter the scope or enforceability of his ethical obligations under the NSPE Code, particularly with respect to how far he must press concerns about harm-allocation design before his professional duty is satisfied?
Does the Faithful Agent Obligation Within Ethical Limits — which requires Engineer A to serve the automobile manufacturer's interests — conflict with the Third-Party Non-Client Welfare Consideration, which demands that Engineer A weight the safety of pedestrians, cyclists, and motorcyclists equally or above the client's commercial interest in a passenger-protective algorithm?
Does the Competing Public Goods Balancing principle — which acknowledges legitimate safety interests of vehicle passengers — conflict with the Public Welfare Paramount principle when the algorithm that best protects passengers is the same algorithm most likely to cause fatal harm to third parties, and if so, which principle should govern Engineer A's recommendation?
Does the Autonomous System Moral Framework Transparency Obligation — requiring Engineer A to disclose the ethical assumptions embedded in the harm-allocation algorithm — conflict with the Informed Decision-Making Enablement Obligation owed to the automobile manufacturer client, insofar as full public transparency about the algorithm's moral logic could expose the manufacturer to legal liability or competitive disadvantage that the client has not consented to accept?
Does the Regulatory Gap Safety Escalation Obligation — which in the software testing case required Engineer A to flag the absence of applicable standards as itself a safety concern warranting further study — conflict with the Completeness and Non-Selectivity in Advisory Opinions principle when the regulatory vacuum surrounding autonomous vehicle harm-allocation ethics means that any recommendation Engineer A makes will necessarily be incomplete, potentially leading to selective or premature guidance that could itself cause harm?
From a deontological perspective, does Engineer A have an absolute duty to recommend harm minimization for third parties regardless of the automobile manufacturer's commercial interests, and does this duty derive from the categorical imperative that engineers must never treat third-party lives as mere means to passenger safety ends?
From a consequentialist perspective, does the Board's conclusion that Engineer A must recommend minimizing harm to the least number of persons adequately account for the aggregate welfare calculus across all possible crash scenarios, including cases where passenger sacrifice might produce net societal harm through reduced adoption of safer autonomous vehicles overall?
From a virtue ethics standpoint, does Engineer A demonstrate the professional integrity and moral courage required of a virtuous engineer when actively expressing concerns about harm-allocation algorithms within a risk assessment team that may face significant commercial pressure to prioritize passenger safety over third-party welfare?
From a deontological perspective, does Engineer A's obligation to disclose the moral framework embedded in the autonomous vehicle's harm-allocation algorithm to the public constitute a perfect duty under professional ethics codes, and does the absence of applicable regulatory standards heighten rather than relieve that disclosure duty?
If Engineer A had remained silent or provided only a partial assessment of the third-party harm risks within the risk assessment team, would the automobile manufacturer have had sufficient information to make an ethically informed deployment decision, and would Engineer A's silence have constituted a violation of the faithful agent obligation?
What if the automobile manufacturer had already established a firm design policy prioritizing passenger safety above all third-party considerations before Engineer A joined the risk assessment team — would Engineer A's ethical obligations shift from recommendation to escalation or refusal to certify the system?
Had established national or industry standards governing autonomous vehicle harm-allocation decision logic existed at the time of Engineer A's assessment — analogous to the draft standards emerging in BER Case 96-4 — would Engineer A's obligation to recommend further study before deployment have been stronger, weaker, or qualitatively different in character?
If Engineer A had proposed and the team had successfully identified a technical mitigation option — such as a sensor-based system capable of dynamically evaluating crash scenarios in real time rather than relying on pre-committed algorithmic harm-allocation logic — would the core ethical dilemma between passenger safety and third-party harm minimization have been dissolved, and what residual ethical obligations would Engineer A retain regarding transparency about the system's remaining limitations?
Regulatory Gap Safety Escalation Obligation Invoked in Software Testing Case
Draft safety standards for public-safety-critical software
In BER Case 96-4, Engineer A's awareness of new draft standards that the software might not meet — standards not yet in force — created an obligation to escalate the concern through internal channels (recommending additional testing) rather than treating the absence of currently applicable standards as justification for proceeding without further scrutiny
The existence of draft standards not yet in force created a regulatory gap that heightened rather than diminished Engineer A's professional responsibility to recommend testing — the gap between current standards and emerging standards is itself a risk factor requiring professional attention
Regulatory Gap Safety Escalation Obligation
Regulatory gap heightens rather than diminishes the obligation to recommend additional scrutiny
Safety-Critical Software Identified (Event 1) → Recommend Additional Safety Testing (Action 1)
{'type': 'Private software company', 'domain': 'Safety-critical software for public infrastructure', 'pressure': 'Client eagerness, competitive disadvantage, financial cost of delay'}
A software company that employs Engineer A to design safety-critical software, faces financial and client pressure to avoid additional testing, but also wants to ensure software safety, and ultimately requests Engineer A's recommendation on additional testing.
{'type': 'employer_of', 'target': 'Engineer A Safety-Critical Software Design Engineer (Case 96-4)'}
{'type': 'serves', 'target': 'Software Company Client'}
The software company was eager to satisfy its clients; but, at the same time, management wanted to be sure that the software was safe to use
New Draft Safety Testing Standard for Safety-Critical Software (nuclear, air quality, water quality) referenced in BER Case 96-4
The Board noted that Engineer A would be well advised to prepare a technical report explaining the current testing analysis and results, as well as referencing the new testing procedure that had been recently reported in the professional literature
Engineer A in BER Case 96-4; cited analogically by the Board in the present case
The existence of a new draft standard that existing software might not meet was the triggering condition for Engineer A's ethical obligation to recommend additional testing in BER Case 96-4, providing the analogical basis for the autonomous vehicle case
Technical Recommendation Independence from Business Considerations Invoked in Software Testing Case
Employer informed decision-making process
In BER Case 96-4, Engineer A's recommendation about additional software testing was required to be based solely on technical findings — the financial pressures on the company, client competitive disadvantage, and public utility rate impacts were factors to be addressed separately by the employer in making its business decision, not inputs to Engineer A's technical recommendation
The principle requires strict methodological separation: Engineer A provides an uncontaminated technical recommendation; the employer then applies business judgment to that recommendation in deciding whether to proceed with testing
Technical Recommendation Independence from Business Considerations
Engineer A's ethical obligations in Case 96-4 involved balancing a variety of ethical and other business considerations and making a recommendation based solely on technical finding (and not business considerations) to permit the company to make an informed decision about the need for additional testing in furtherance of the public health, safety, and welfare.
Business considerations are not inputs to the technical recommendation but are addressed separately in the employer's decision-making process after receiving the technical recommendation
The financial pressures that existed, including the financial impact on his company, the client, and the public, as well as the potential loss of jobs and delays if additional testing were to be pursued, were clearly important factors and needed to be addressed in some manner. However, said the Board of Ethical Review, it would seem that these nontechnical considerations were factors that needed to be given weight separate and apart from the decision as to whether the additional testing should be recommended by Engineer A.
Third-Party Non-Client Welfare Consideration Invoked in Autonomous Vehicle Case
Autonomous vehicle operating system risk assessment
Engineer A's risk assessment obligations extend to the welfare of pedestrians, bystanders, and other third parties who are not clients or passengers of the autonomous vehicle but who are foreseeably exposed to risk from the system's harm-distribution decisions — these third parties' welfare must be explicitly considered in the risk assessment
The public welfare obligation in the autonomous vehicle context specifically encompasses non-client third parties who bear the risk of harm from the system's decisions — their welfare is not subordinate to the interests of the automobile manufacturer or vehicle passengers
Third-party welfare must be given explicit and affirmative consideration in the risk assessment, not treated as secondary to client or passenger interests
Engineer A has a responsibility to fully and actively participate as a member of the engineering risk management team, clearly and unambiguously express any and all concerns he has regarding the safety of the proposed autonomous vehicle operation system.
Third-Party Non-Client Welfare Consideration Invoked in Autonomous Vehicle Design
Autonomous vehicle crash-avoidance algorithm design
Pedestrians, cyclists, and motorcycle riders as affected third parties
The risk assessment scenario explicitly juxtaposes passenger welfare against the welfare of pedestrians, cyclists, and motorcycle riders — third parties who are not clients, not passengers, and have no contractual relationship with the manufacturer — requiring Engineer A to give affirmative and explicit consideration to these third parties' welfare in formulating the recommendation
Pedestrians, cyclists, and motorcyclists who may be struck by an autonomous vehicle are paradigmatic examples of third parties who have no voice in the system's design but are foreseeably exposed to potentially fatal risk from its algorithmic decisions — Engineer A's public welfare obligation is strongest precisely with respect to these voiceless affected parties
The principle requires that third-party welfare be an explicit and weighted parameter in the recommendation, not merely an afterthought to passenger-protective design
Unavoidable Crash Scenario Identified (Event 5) → Algorithmic Ethics Gap Recognized (Event 7)
additional proposed testing (BER Case 96-4) before software deployment/use
additional proposed testing (BER Case 96-4) meets six-month delay period
existing software testing (BER Case 96-4) before new draft standards release
financial pressure considerations (BER Case 96-4) during Engineer A's recommendation process (BER Case 96-4)
further study (present case) before autonomous vehicle operating system utilization
new draft standards awareness (BER Case 96-4) overlaps Engineer A's recommendation process (BER Case 96-4)
new engineering breakthroughs before new ethical uncertainties/risks
six-month delay period before software deployment/use