Step 4: Full View

Entities, provisions, decisions, and narrative

Public Health, Safety, and Welfare—Driverless/Autonomous Vehicle
Step 4 of 5

247

Entities

5

Provisions

1

Precedents

17

Questions

18

Conclusions

Stalemate

Transformation
Stalemate Competing obligations remain in tension without clear resolution
The Board produces a layered stalemate in which Engineer A is simultaneously bound by at least five non-collapsible obligations — harm-minimization recommendation, utilitarian framework disclosure, technical mitigation exploration, graduated escalation if overridden, and potential refusal to certify — that cannot all be fully discharged within the consultant engagement as structured. The manufacturer retains the legal authority to override Engineer A's recommendation, Engineer A retains the professional duty to object and potentially withdraw, and third parties retain their exposure to fatal risk regardless of Engineer A's actions. No single party is relieved of its stake in the outcome, and the ethical dilemma between passenger-priority and aggregate harm-minimization persists as an unresolved tension embedded in the design decision itself, with the Board explicitly noting that alternative moral frameworks yield different algorithmic outcomes and that no universally accepted engineering standard exists to adjudicate between them.
Full Entity Graph
Loading...
Context: 0 Normative: 0 Temporal: 0 Synthesis: 0
Filter:
Building graph...
Entity Types
Synthesis Reasoning Flow
Shows how NSPE provisions inform questions and conclusions - the board's reasoning chain

The board's deliberative chain: which code provisions informed which ethical questions, and how those questions were resolved. Toggle "Show Entities" to see which entities each provision applies to.

Nodes:
Provision (e.g., I.1.) Question: Board = board-explicit, Impl = implicit, Tens = principle tension, Theo = theoretical, CF = counterfactual Conclusion: Board = board-explicit, Resp = question response, Ext = analytical extension, Synth = principle synthesis Entity (hidden by default)
Edges:
informs answered by applies to
Provisions (5)
View Extraction
I.1. Hold paramount the safety, health, and welfare of the public.
How this applies in the case (showing 3 of 53)
Obligation
Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation
Holding paramount public safety directly requires active participation in harm minimization evaluation.
Action
Recommend Additional Safety Testing
Holding public safety paramount directly governs recommending further safety testing before deployment.
State
Engineer A Ethical Dilemma, Harm Allocation Recommendation
Engineer A's obligation to hold public safety paramount directly shapes the ethical dilemma of choosing between harm-allocating algorithms.
Obligation (5)
  • Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation
    Holding paramount public safety directly requires active participation in harm minimization evaluation.
  • Engineer A AV Risk Assessment Third-Party Safety Consideration Obligation
    Holding paramount public safety requires explicitly identifying and assessing third-party safety risks.
  • Engineer A AV Further Study Recommendation Before Deployment Obligation
    Holding paramount public safety requires recommending further study before deploying potentially unsafe AV technology.
  • Engineer A Autonomous Vehicle Do No Harm Obligation
    The paramount safety provision directly underpins the obligation to strive to do no harm.
  • Engineer A BER 96-4 Public Welfare Paramount Safety-Critical Software Obligation
    This obligation explicitly mirrors the paramount safety provision in the context of safety-critical software testing.
Action (4)
  • Recommend Additional Safety Testing
    Holding public safety paramount directly governs recommending further safety testing before deployment.
  • Actively Participate in Risk Assessment
    Paramount duty to public safety requires active engagement in identifying and assessing risks.
  • Unambiguously Express Safety Concerns
    Holding public safety paramount obligates engineers to clearly voice safety concerns.
  • Propose Further Study Before Deployment
    Prioritizing public welfare governs proposing additional study to ensure safe deployment.
State (7)
  • Engineer A Ethical Dilemma, Harm Allocation Recommendation
    Engineer A's obligation to hold public safety paramount directly shapes the ethical dilemma of choosing between harm-allocating algorithms.
  • Present Case Client-Interest vs Third-Party Safety Algorithmic Pre-Commitment
    Holding public safety paramount requires Engineer A to weigh third-party safety against client commercial interests in algorithm design.
  • Public Safety at Risk. Autonomous Vehicle Third-Party Harm
    The provision directly addresses the risk of fatal or serious injury to pedestrians and cyclists from algorithm design choices.
  • Competing Duties. Passenger Safety vs. Aggregate Harm Minimization
    The paramount duty to public safety is the governing principle in resolving Engineer A's competing professional duties.
  • Present Case Autonomous Vehicle Do No Harm Design Obligation
    The do no harm design obligation is a direct expression of the paramount duty to hold public safety above all other considerations.
  • Present Case Autonomous System Harm Allocation Design
    Designing harm-allocation decision logic must be governed by the paramount obligation to protect public safety.
  • BER Case 96-4 Public Safety at Risk from Safety-Critical Software
    The risk to the public from deploying safety-critical software not meeting forthcoming standards directly implicates the paramount safety duty.
Constraint (12)
  • Engineer A AV Harm Allocation Moral Framework Non-Deception Public Disclosure Constraint
    Holding public safety paramount requires not deploying an AV with an undisclosed moral framework that could harm the public.
  • Engineer A AV Good Faith Safety Concern Objective Testimony Constraint
    Paramount public safety obligation requires Engineer A to disclose safety concerns in good faith even absent established standards.
  • Engineer A AV Do No Harm Design Obligation Safety Constraint
    The do no harm design obligation directly flows from the paramount duty to protect public safety and welfare.
  • Engineer A BER 96-4 Public Safety Paramount Safety-Critical Software Constraint
    This constraint explicitly invokes the paramount public safety obligation over business considerations in safety-critical software.
  • Engineer A AV Regulatory Standards Vacuum Heightened Disclosure Constraint
    Absence of standards heightens rather than diminishes the paramount duty to protect the public from AV harm-allocation risks.
  • Engineer A AV Passenger Priority Algorithm Third-Party Fatal Harm Non-Subordination Constraint
    Holding public safety paramount prohibits algorithms that categorically sacrifice third-party lives, as the public includes non-passengers.
  • Engineer A AV Further Study Before Deployment Constraint
    Paramount public safety requires recommending further study before deploying an AV system with unresolved safety concerns.
  • Engineer A AV Client Interest Third-Party Safety Priority Constraint
    The paramount public safety duty establishes that third-party safety takes priority over client commercial interests.
  • Engineer A AV Do No Harm Deployment Constraint
    The do no harm deployment constraint is a direct expression of the paramount obligation to protect public safety before deployment.
  • Engineer A AV Risk Mitigation Option Exploration Constraint
    Paramount public safety requires exhausting all risk mitigation options before recommending deployment of a potentially harmful AV system.
  • Engineer A AV Active Participation Concern Expression Constraint
    Holding public safety paramount obligates active rather than passive participation in safety processes affecting the public.
  • Engineer A AV Further Study Recommendation Constraint
    Paramount public safety duty requires Engineer A to vocalize the need for further study when safety concerns remain unresolved.
Principle (7)
  • Public Welfare Paramount Invoked in Autonomous Vehicle Crash Algorithm Design
    I.1 directly embodies the paramount public welfare obligation that governs the crash algorithm design decision.
  • Public Welfare Paramount Invoked in Autonomous Vehicle Risk Assessment
    I.1 is the foundational provision that establishes Engineer A's overriding responsibility to hold public safety paramount in the risk assessment.
  • Third-Party Non-Client Welfare Consideration Invoked in Autonomous Vehicle Design
    I.1 requires holding paramount the welfare of all members of the public, including third parties such as pedestrians and cyclists.
  • Third-Party Non-Client Welfare Consideration Invoked in Autonomous Vehicle Case
    I.1 extends the paramount safety obligation to pedestrians and bystanders who are not clients or passengers.
  • Do No Harm Obligation Invoked by Engineer A in Autonomous Vehicle Case
    I.1 grounds the do no harm obligation by requiring engineers to prioritize public safety before deployment.
  • Competing Public Goods Balancing Invoked in Passenger vs. Third-Party Safety Trade-Off
    I.1 requires balancing competing public goods since both passenger and third-party safety fall under the paramount public welfare mandate.
  • Algorithmic Harm Distribution Ethics Invoked in Autonomous Vehicle Case
    I.1 requires that the distribution of harm embedded in the algorithm be evaluated against the standard of paramount public welfare.
Role (2)
  • Engineer A Autonomous Vehicle Risk Assessment Team Engineer
    Engineer A must hold paramount public safety when evaluating autonomous vehicle risk scenarios for the manufacturer.
  • Engineer A Safety-Critical Software Design Engineer (Case 96-4)
    Engineer A must hold paramount public safety when designing software for public-safety-critical facilities.
Event (4)
  • Safety-Critical Software Identified
    Identifying safety-critical software directly invokes the paramount duty to protect public safety.
  • Unavoidable Crash Scenario Identified
    An unavoidable crash scenario directly threatens public safety and welfare, triggering the paramount obligation.
  • Algorithmic Ethics Gap Recognized
    A gap in algorithmic ethics in an AV system poses a direct risk to public health and safety.
  • Financial Pressure on Testing
    Allowing financial pressure to compromise testing undermines the paramount duty to protect public safety.
Resource (4)
  • NSPE Code of Ethics
    I.1 is a foundational canon of the NSPE Code of Ethics directly governing Engineer A's paramount obligation to public safety.
  • Qualitative Risk Assessment Methodology for Autonomous Vehicle Crash Scenarios
    Holding public safety paramount requires Engineer A to apply rigorous risk assessment methodology to identify potential harms to passengers and pedestrians.
  • Autonomous Vehicle Operating System Safety Standard
    Holding public safety paramount requires adherence to safety standards governing autonomous vehicle operating systems.
  • Draft_AV_Safety_Testing_Standard
    The emerging draft standard represents the current threshold for public safety protection that Engineer A must consider when holding safety paramount.
Capability (8)
  • Engineer A AV Public Transparency Advocacy Capability
    Holding public safety paramount requires transparency about moral frameworks encoded in AV algorithms that affect public welfare.
  • Engineer A AV Third-Party Harm Weighting Capability
    Holding public safety paramount directly requires assessing and weighing the welfare interests of third parties such as pedestrians and cyclists.
  • Engineer A AV Crash Scenario Technical Safety Analysis Capability
    Holding public safety paramount requires technical analysis of unavoidable crash scenarios to protect the public from harm.
  • Engineer A AV Harm Minimization Risk Management Participation
    Active participation in risk assessment is a direct expression of holding public safety paramount in AV development.
  • Engineer A Autonomous Vehicle Do No Harm Novel Technology Application Capability
    The do-no-harm principle is a direct operationalization of holding public safety and welfare paramount.
  • Engineer A AV Risk Assessment Active Participation Capability
    Fully participating in risk management to clearly articulate safety concerns is required by the obligation to hold public safety paramount.
  • Engineer A Public Welfare Paramountcy Safety-Critical Software Capability
    Recognizing the enormous public impact of safety-critical software industries directly reflects the requirement to hold public welfare paramount.
  • Engineer A Regulatory Gap Safety Escalation Software Standards Capability
    Recognizing that a regulatory gap heightens safety obligations is a direct application of holding public safety paramount.
II.1. Engineers shall hold paramount the safety, health, and welfare of the public.
How this applies in the case (showing 3 of 56)
Obligation
Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation
Holding paramount public safety, health, and welfare requires full participation in harm minimization assessments.
Action
Recommend Additional Safety Testing
The duty to hold public safety paramount governs recommending additional testing to mitigate risks.
State
Engineer A Ethical Dilemma, Harm Allocation Recommendation
The professional duty to hold public safety paramount is the central ethical obligation framing Engineer A's dilemma.
Obligation (5)
  • Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation
    Holding paramount public safety, health, and welfare requires full participation in harm minimization assessments.
  • Engineer A AV Risk Assessment Third-Party Safety Consideration Obligation
    Holding paramount public welfare requires explicitly considering third-party safety impacts in risk assessments.
  • Engineer A AV Further Study Recommendation Before Deployment Obligation
    Holding paramount public safety requires recommending further study before AV deployment if risks remain unresolved.
  • Engineer A Autonomous Vehicle Do No Harm Obligation
    The obligation to hold public welfare paramount directly supports the duty to strive to do no harm.
  • Engineer A BER 96-4 Public Welfare Paramount Safety-Critical Software Obligation
    This obligation is a direct application of the paramount public welfare provision to safety-critical software decisions.
Action (4)
  • Recommend Additional Safety Testing
    The duty to hold public safety paramount governs recommending additional testing to mitigate risks.
  • Actively Participate in Risk Assessment
    Engineers must hold public safety paramount, which requires active participation in risk assessment processes.
  • Unambiguously Express Safety Concerns
    This provision obligates engineers to clearly express safety concerns to protect the public.
  • Propose Further Study Before Deployment
    Holding public welfare paramount governs proposing further study before a potentially unsafe deployment.
State (8)
  • Engineer A Ethical Dilemma, Harm Allocation Recommendation
    The professional duty to hold public safety paramount is the central ethical obligation framing Engineer A's dilemma.
  • Present Case Client-Interest vs Third-Party Safety Algorithmic Pre-Commitment
    This provision requires Engineer A to prioritize third-party safety over the client's preference for passenger-protective algorithms.
  • Autonomous Vehicle Harm Allocation Design Assignment
    Engineer A's assignment to evaluate harm-allocation logic must be conducted under the overriding duty to protect public safety.
  • Public Safety at Risk. Autonomous Vehicle Third-Party Harm
    The provision directly governs Engineer A's response to the identified risk of harm to pedestrians and cyclists.
  • Competing Duties. Passenger Safety vs. Aggregate Harm Minimization
    This provision establishes that public welfare is paramount and must take precedence when Engineer A's duties conflict.
  • Present Case Autonomous Vehicle Do No Harm Design Obligation
    The do no harm obligation is a direct application of the duty to hold public safety paramount in system design.
  • Present Case Autonomous System Harm Allocation Design
    The design of autonomous harm-allocation logic must conform to the overriding professional duty to protect public safety.
  • BER Case 96-4 Public Safety at Risk from Safety-Critical Software
    Deployment of safety-critical software posing public risk directly triggers the paramount duty under this provision.
Constraint (12)
  • Engineer A AV Harm Allocation Moral Framework Non-Deception Public Disclosure Constraint
    Paramount public safety obligation requires disclosure of embedded moral frameworks that could affect public welfare in AV deployment.
  • Engineer A AV Good Faith Safety Concern Objective Testimony Constraint
    The duty to hold public safety paramount requires objective good-faith testimony about safety concerns regardless of regulatory gaps.
  • Engineer A AV Do No Harm Design Obligation Safety Constraint
    The paramount safety obligation underpins the do no harm design requirement for autonomous vehicle systems.
  • Engineer A BER 96-4 Public Safety Paramount Safety-Critical Software Constraint
    This constraint directly references the paramount public safety obligation as overriding business pressures in safety-critical software decisions.
  • Engineer A AV Regulatory Standards Vacuum Heightened Disclosure Constraint
    The paramount safety duty is heightened, not diminished, when regulatory standards are absent for AV harm-allocation logic.
  • Engineer A AV Passenger Priority Algorithm Third-Party Fatal Harm Non-Subordination Constraint
    Paramount public safety encompasses third parties, prohibiting algorithms that categorically subordinate their lives to passengers.
  • Engineer A AV Further Study Before Deployment Constraint
    The paramount safety obligation requires recommending further study before deploying an AV system with unresolved harm-allocation concerns.
  • Engineer A AV Client Interest Third-Party Safety Priority Constraint
    Paramount public safety establishes that third-party safety supersedes client commercial interests when they conflict.
  • Engineer A AV Do No Harm Deployment Constraint
    The do no harm deployment constraint is grounded in the paramount duty not to expose the public to preventable AV-related harm.
  • Engineer A AV Risk Mitigation Option Exploration Constraint
    Paramount public safety requires exploring all risk mitigation options before recommending deployment of a potentially unsafe AV system.
  • Engineer A AV Active Participation Concern Expression Constraint
    The paramount safety duty requires active expression of safety concerns rather than passive silence in risk management processes.
  • Engineer A AV Further Study Recommendation Constraint
    Paramount public safety obligates Engineer A to recommend further study when unresolved safety concerns exist about the AV system.
Principle (8)
  • Public Welfare Paramount Invoked in Autonomous Vehicle Crash Algorithm Design
    II.1 reiterates the paramount public safety obligation directly applicable to the crash algorithm design evaluation.
  • Public Welfare Paramount Invoked in Autonomous Vehicle Risk Assessment
    II.1 is the operative code provision establishing Engineer A's overriding ethical responsibility in the risk assessment context.
  • Third-Party Non-Client Welfare Consideration Invoked in Autonomous Vehicle Design
    II.1 mandates holding paramount the welfare of the public, which explicitly includes third parties beyond the client relationship.
  • Third-Party Non-Client Welfare Consideration Invoked in Autonomous Vehicle Case
    II.1 extends the paramount safety duty to all members of the public including pedestrians and bystanders.
  • Do No Harm Obligation Invoked by Engineer A in Autonomous Vehicle Case
    II.1 supports the do no harm obligation by requiring engineers to prioritize public safety before system deployment.
  • Competing Public Goods Balancing Invoked in Passenger vs. Third-Party Safety Trade-Off
    II.1 requires that both passenger and third-party welfare be weighed under the paramount public safety standard.
  • Algorithmic Harm Distribution Ethics Invoked in Autonomous Vehicle Case
    II.1 requires that harm distribution decisions in the algorithm be evaluated against the paramount public welfare obligation.
  • Active Risk Assessment Team Participation Obligation Invoked by Engineer A
    II.1 requires Engineer A to actively participate and clearly express views to ensure public safety is held paramount within the team.
Role (2)
  • Engineer A Autonomous Vehicle Risk Assessment Team Engineer
    Engineer A is professionally obligated to prioritize public safety, health, and welfare in the autonomous vehicle risk assessment.
  • Engineer A Safety-Critical Software Design Engineer (Case 96-4)
    Engineer A must hold paramount public safety when aware that safety-critical software may not conform to new draft standards.
Event (4)
  • Safety-Critical Software Identified
    Engineers must hold public safety paramount when safety-critical software issues are discovered in AV development.
  • Unavoidable Crash Scenario Identified
    Engineers are obligated to prioritize public welfare when a crash scenario with potential harm is identified.
  • Algorithmic Ethics Gap Recognized
    Recognizing an ethics gap in AV algorithms requires engineers to uphold public safety above other interests.
  • Financial Pressure on Testing
    Engineers must hold public safety paramount even when facing financial pressure to reduce testing rigor.
Resource (5)
  • NSPE Code of Ethics
    II.1 is a direct provision of the NSPE Code of Ethics establishing Engineer A's core professional obligation to public safety.
  • ISO 26262 Automotive Functional Safety Standard
    Holding public safety paramount in automotive engineering requires conformance with ISO 26262 as the governing functional safety standard.
  • Qualitative Risk Assessment Methodology for Autonomous Vehicle Crash Scenarios
    Engineer A's obligation to hold public safety paramount necessitates use of structured risk assessment methodology to evaluate crash scenarios.
  • Consumer Product Safety Testing Standard for Autonomous Vehicles
    Holding public safety paramount requires Engineer A to consider applicable consumer product safety testing standards before market release.
  • BER_Case_96-4
    This precedent case establishes the principle that holding safety paramount obligates engineers to recommend additional testing when safety standards may not be met.
Capability (8)
  • Engineer A AV Public Transparency Advocacy Capability
    Engineers must hold public welfare paramount, which includes advocating transparency about AV harm minimization algorithms affecting the public.
  • Engineer A AV Third-Party Harm Weighting Capability
    Holding public welfare paramount requires explicitly identifying and assessing harm to third parties who are members of the public.
  • Engineer A AV Crash Scenario Technical Safety Analysis Capability
    Engineers must hold public safety paramount, requiring rigorous technical analysis of crash scenarios that could harm the public.
  • Engineer A AV Harm Minimization Risk Management Participation
    Full participation in risk management directly fulfills the engineer's duty to hold public safety paramount.
  • Engineer A Autonomous Vehicle Do No Harm Novel Technology Application Capability
    Applying the do-no-harm principle to AV systems is a direct expression of the duty to hold public welfare paramount.
  • Engineer A AV Risk Assessment Active Participation Capability
    Active and clear participation in risk assessment is required to fulfill the duty to hold public safety paramount.
  • Engineer A Public Welfare Paramountcy Safety-Critical Software Capability
    Recognizing the public impact of safety-critical software is directly tied to the duty to hold public welfare paramount.
  • Engineer A Regulatory Gap Safety Escalation Software Standards Capability
    Escalating safety concerns when regulatory standards are absent reflects the duty to hold public safety paramount.
II.1.b. Engineers shall approve only those engineering documents that are in conformity with applicable standards.
How this applies in the case (showing 3 of 32)
Obligation
Engineer A BER 96-4 Technical Report Preparation Obligation
Approving only conforming engineering documents relates directly to the obligation to prepare a technically sound report referencing applicable testing standards.
Action
Prepare Transparent Technical Report
Engineers must approve only documents conforming to applicable standards, governing the preparation of accurate and transparent technical reports.
State
Autonomous Vehicle Ethics Regulatory Standards Vacuum
The absence of applicable standards creates a direct challenge to Engineer A's obligation to approve only conforming engineering documents.
Obligation (2)
  • Engineer A BER 96-4 Technical Report Preparation Obligation
    Approving only conforming engineering documents relates directly to the obligation to prepare a technically sound report referencing applicable testing standards.
  • Engineer A AV Faithful Agent Informed Decision Enablement Obligation
    Ensuring engineering documents conform to applicable standards supports providing the manufacturer with diligent and complete information for informed decisions.
Action (2)
  • Prepare Transparent Technical Report
    Engineers must approve only documents conforming to applicable standards, governing the preparation of accurate and transparent technical reports.
  • Recommend Additional Safety Testing
    Approving only conforming engineering documents governs recommending testing to ensure standards compliance.
State (4)
  • Autonomous Vehicle Ethics Regulatory Standards Vacuum
    The absence of applicable standards creates a direct challenge to Engineer A's obligation to approve only conforming engineering documents.
  • Present Case Regulatory Standards Vacuum for Autonomous Vehicle Ethics
    The lack of established national or industry standards means Engineer A cannot confirm conformity with applicable standards for harm-allocation logic.
  • BER Case 96-4 Emerging Software Standard Pre-Adoption Gap
    Engineer A's awareness of forthcoming but not yet adopted standards raises the question of which standards engineering documents must conform to.
  • BER Case 96-4 Completed Safety Testing with Residual Concern
    Passing existing standards while forthcoming standards remain unadopted creates ambiguity about whether engineering documents are fully conforming.
Constraint (5)
  • Engineer A AV Harm Allocation Algorithm Completeness Disclosure Constraint
    Approving only conforming engineering documents requires that the harm-allocation algorithm recommendation be complete and fully disclosed to the risk assessment team.
  • Engineer A BER 96-4 Emerging Standard Technical Report Disclosure Constraint
    The obligation to conform to applicable standards requires disclosing newly reported draft testing standards that the AV system may not meet.
  • Engineer A AV Regulatory Standards Vacuum Heightened Disclosure Constraint
    The absence of applicable standards creates a heightened disclosure obligation rather than permitting approval of documents without conformity review.
  • Engineer A AV Good Faith Safety Concern Objective Testimony Constraint
    Approving only conforming engineering documents requires objective disclosure of safety concerns when no applicable standards exist to confirm conformity.
  • Engineer A AV Do No Harm Design Obligation Safety Constraint
    The requirement to approve only conforming documents supports the do no harm design obligation by preventing approval of non-conforming harm-allocation designs.
Principle (4)
  • Regulatory Gap Safety Escalation Obligation Invoked in Software Testing Case
    II.1.b requires conformity with applicable standards, directly grounding the obligation to escalate when new draft standards may not be met.
  • Do No Harm Obligation Invoked by Engineer A in Software Testing Case
    II.1.b supports the do no harm obligation by prohibiting approval of documents that do not conform to applicable standards.
  • Good Faith Safety Concern Threshold Invoked in Software Testing Case
    II.1.b establishes that awareness of potential non-conformity with standards is sufficient to trigger an obligation to act.
  • Autonomous System Moral Framework Transparency Obligation Invoked in AV Design
    II.1.b requires that engineering documents and designs conform to applicable standards, supporting transparency about the moral framework embedded in the system.
Role (2)
  • Engineer A Autonomous Vehicle Risk Assessment Team Engineer
    Engineer A should only approve engineering documents for the autonomous vehicle that conform to applicable standards.
  • Engineer A Safety-Critical Software Design Engineer (Case 96-4)
    Engineer A must ensure the safety-critical software design conforms to applicable standards including newly emerging draft standards.
Event (3)
  • Draft Safety Standards Emerge
    Engineers should only approve engineering documents and designs that conform to the emerging applicable safety standards.
  • Safety-Critical Software Identified
    Engineers must ensure safety-critical software documentation conforms to applicable standards before approval.
  • Autonomous Vehicle AV OS Development Initiated
    The initiation of AV OS development requires that all engineering documents conform to applicable standards.
Resource (5)
  • ISO 26262 Automotive Functional Safety Standard
    II.1.b requires approval only of documents conforming to applicable standards, directly implicating ISO 26262 as the governing automotive safety standard.
  • Autonomous Vehicle Operating System Safety Standard
    Engineer A may only approve engineering documents if the autonomous vehicle operating system conforms to applicable safety standards.
  • Consumer Product Safety Testing Standard for Autonomous Vehicles
    Engineering documents must conform to applicable consumer product safety testing standards before Engineer A can approve them.
  • Draft_AV_Safety_Testing_Standard
    The draft standard represents an applicable standard that engineering documents must conform to, triggering Engineer A's obligation under II.1.b.
  • Software_Safety_Testing_Standard_BER96-4_Context
    The existence of a new draft standard that existing software may not meet directly triggers the conformity requirement under II.1.b.
Capability (5)
  • Engineer A AV Crash Scenario Technical Safety Analysis Capability
    Approving only conforming engineering documents requires technical analysis of crash scenarios against applicable safety standards.
  • Engineer A Safety-Critical Software Informed Employer Decision Enablement Capability
    Preparing a technical report referencing draft testing protocols directly relates to approving documents in conformity with applicable standards.
  • Engineer A Regulatory Gap Safety Escalation Software Standards Capability
    Recognizing that a new draft testing standard exists and affects approval obligations directly relates to conformity with applicable standards.
  • Engineer A Cross-Case Analogical Transfer BER 96-4 to AV Case Capability
    Applying established ethical principles from prior cases to AV software standards supports the requirement to conform engineering documents to applicable standards.
  • Engineer A Public Welfare Paramountcy Safety-Critical Software Capability
    Recognizing industry-specific safety standards for safety-critical software is relevant to the obligation to approve only conforming engineering documents.
II.3.b. Engineers may express publicly technical opinions that are founded upon knowledge of the facts and competence in the subject matter.
How this applies in the case (showing 3 of 32)
Obligation
Engineer A Autonomous Vehicle Risk Assessment Active Participation Obligation
Expressing technical opinions founded on knowledge and competence supports the obligation to clearly articulate concerns during risk management participation.
Action
Prepare Transparent Technical Report
Expressing technical opinions publicly must be founded on facts and competence, directly governing transparent technical reporting.
State
Engineer A Ethical Dilemma, Harm Allocation Recommendation
Engineer A's recommendation must be grounded in factual knowledge and subject-matter competence, as required by this provision.
Obligation (3)
  • Engineer A Autonomous Vehicle Risk Assessment Active Participation Obligation
    Expressing technical opinions founded on knowledge and competence supports the obligation to clearly articulate concerns during risk management participation.
  • Engineer A AV Moral Framework Public Transparency Recommendation Obligation
    Publicly expressing technically founded opinions relates to recommending transparency about the AV moral framework to the public.
  • Engineer A BER 96-4 Technical Report Preparation Obligation
    Expressing technically founded opinions supports the obligation to prepare a report grounded in current testing analysis and results.
Action (2)
  • Prepare Transparent Technical Report
    Expressing technical opinions publicly must be founded on facts and competence, directly governing transparent technical reporting.
  • Unambiguously Express Safety Concerns
    This provision governs public expression of safety concerns, requiring they be grounded in knowledge and competence.
State (4)
  • Engineer A Ethical Dilemma, Harm Allocation Recommendation
    Engineer A's recommendation must be grounded in factual knowledge and subject-matter competence, as required by this provision.
  • Present Case Client-Interest vs Third-Party Safety Algorithmic Pre-Commitment
    Engineer A's public or professional expression of a technical opinion on algorithm design must be founded on competence and facts.
  • Autonomous Vehicle Harm Allocation Design Assignment
    Engineer A's evaluation and recommendation on harm-allocation logic constitutes a technical opinion requiring competence and factual grounding.
  • BER Case 96-4 Multi-Factor Business-Safety Balancing
    Formulating a technical recommendation amid financial pressures must still be grounded in competence and knowledge of the facts.
Constraint (6)
  • Engineer A AV Good Faith Safety Concern Objective Testimony Constraint
    Expressing technical opinions founded on knowledge and competence directly supports the obligation to provide objective good-faith testimony about AV safety concerns.
  • Engineer A AV Harm Allocation Moral Framework Non-Deception Public Disclosure Constraint
    The provision permits Engineer A to publicly express technically grounded opinions about the undisclosed moral framework embedded in the AV system.
  • Engineer A BER 96-4 Emerging Standard Technical Report Disclosure Constraint
    Expressing competence-based technical opinions supports the obligation to disclose newly reported draft standards relevant to the AV system.
  • Engineer A AV Regulatory Standards Vacuum Escalation Permissibility Constraint
    The provision supports Engineer A's permissibility to escalate concerns publicly when no regulatory standards exist and internal processes are insufficient.
  • Engineer A AV Active Participation Concern Expression Constraint
    The provision grounds the obligation to actively express safety concerns by requiring that such expressions be founded on knowledge and competence.
  • Engineer A AV Further Study Recommendation Constraint
    Expressing technically founded opinions supports the obligation to recommend further study when competence-based assessment identifies unresolved safety concerns.
Principle (6)
  • Completeness and Non-Selectivity in Advisory Opinions Invoked by Engineer A Risk Assessment Team
    II.3.b requires that publicly expressed technical opinions be founded on knowledge and competence, supporting the obligation to present both frameworks completely and objectively.
  • Professional Competence in Risk Assessment Invoked for Autonomous Vehicle Scenario
    II.3.b requires that technical opinions be grounded in competence in the subject matter, directly applicable to the risk assessment team's specialized analysis.
  • Informed Decision-Making Enablement Obligation Invoked for Automobile Manufacturer Client
    II.3.b supports the obligation to provide technically founded opinions that enable the manufacturer to make an informed decision.
  • Informed Decision-Making Enablement Obligation Invoked in Software Testing Case
    II.3.b supports Engineer A's obligation to prepare a technically grounded report enabling informed decision-making by the employer.
  • Technical Recommendation Independence from Business Considerations Invoked in Software Testing Case
    II.3.b requires that technical opinions be founded on knowledge and competence, not on financial or business considerations.
  • Autonomous System Moral Framework Transparency Obligation Invoked in AV Design
    II.3.b supports the obligation to transparently communicate the moral framework embedded in the system based on competence and factual knowledge.
Role (2)
  • Engineer A Autonomous Vehicle Risk Assessment Team Engineer
    Engineer A may publicly express technical opinions on autonomous vehicle risks based on their knowledge and competence from the risk assessment work.
  • Engineer A Safety-Critical Software Design Engineer (Case 96-4)
    Engineer A may publicly express technical opinions on software safety standards based on their expertise and testing experience.
Event (3)
  • Unavoidable Crash Scenario Identified
    Engineers may publicly express technical opinions about unavoidable crash scenarios based on their factual knowledge and competence.
  • Algorithmic Ethics Gap Recognized
    Engineers with competence in AV systems may publicly express opinions about identified algorithmic ethics gaps.
  • Draft Safety Standards Emerge
    Engineers may publicly comment on emerging draft safety standards when they have relevant knowledge and expertise.
Resource (2)
  • Qualitative Risk Assessment Methodology for Autonomous Vehicle Crash Scenarios
    Expressing founded technical opinions requires Engineer A to base public statements on competent risk assessment methodology and factual analysis.
  • NSPE_Code_of_Ethics_Sections_III6b_II4a
    The Board cited related Code sections requiring Engineer A to prepare a technical report, which supports the competence-based public expression required by II.3.b.
Capability (4)
  • Engineer A AV Public Transparency Advocacy Capability
    Publicly advocating transparency about AV algorithms constitutes expressing a technical opinion that must be founded on knowledge and competence.
  • Engineer A AV Crash Scenario Technical Safety Analysis Capability
    Expressing technical opinions about crash scenarios publicly requires the competence and factual knowledge mandated by this provision.
  • Engineer A AV Ethical Framework Selection Capability
    Publicly expressing opinions about the ethical framework encoded in AV systems requires competence in the subject matter as required by this provision.
  • Engineer A AV Further Study Recommendation Capability
    Recommending further study publicly on unresolved safety concerns constitutes a technical opinion that must be grounded in knowledge and competence.
III.1.b. Engineers shall advise their clients or employers when they believe a project will not be successful.
How this applies in the case (showing 3 of 41)
Obligation
Engineer A Autonomous Vehicle Further Study Recommendation Obligation
Advising clients when a project will not be successful directly supports the obligation to propose further study when concerns remain unresolved.
Action
Unambiguously Express Safety Concerns
Engineers must advise clients when a project will not be successful, governing the unambiguous expression of safety concerns to employers.
State
Passenger Safety vs. Third-Party Harm Minimization Algorithm Conflict
Engineer A must advise the automobile manufacturer client when the preferred passenger-protective algorithm conflicts with broader safety obligations.
Obligation (4)
  • Engineer A Autonomous Vehicle Further Study Recommendation Obligation
    Advising clients when a project will not be successful directly supports the obligation to propose further study when concerns remain unresolved.
  • Engineer A BER 96-4 Additional Testing Recommendation Obligation
    Advising the client that additional testing is required aligns with the obligation to recommend further testing and explain why it is needed.
  • Engineer A BER 96-4 Business Pressure Non-Subordination Obligation
    Advising clients based on technical findings rather than financial pressures directly supports the obligation not to subordinate recommendations to business pressure.
  • Engineer A AV Faithful Agent Informed Decision Enablement Obligation
    Acting as a faithful agent by providing complete information enables the client to make informed decisions, consistent with advising them when a project may not succeed.
Action (3)
  • Unambiguously Express Safety Concerns
    Engineers must advise clients when a project will not be successful, governing the unambiguous expression of safety concerns to employers.
  • Explore Additional Technical Mitigation Options
    Advising clients of project risks governs exploring mitigation options to address identified deficiencies.
  • Propose Further Study Before Deployment
    The duty to advise clients when a project will not be successful governs proposing further study before deployment.
State (5)
  • Passenger Safety vs. Third-Party Harm Minimization Algorithm Conflict
    Engineer A must advise the automobile manufacturer client when the preferred passenger-protective algorithm conflicts with broader safety obligations.
  • Client Relationship. Engineer A and Automobile Manufacturer
    The active consulting relationship creates a direct obligation for Engineer A to advise the client when the project direction raises safety concerns.
  • BER Case 96-4 Multi-Factor Business-Safety Balancing
    Engineer A's obligation to advise the client about safety concerns applies even when significant financial pressures favor a different course.
  • BER Case 96-4 Completed Safety Testing with Residual Concern
    Engineer A's residual concern about forthcoming standards triggers the duty to advise the client that the project may not meet future requirements.
  • Competing Duties. Passenger Safety vs. Aggregate Harm Minimization
    When client interests conflict with public safety obligations, Engineer A must advise the client of the concern rather than silently comply.
Constraint (8)
  • Engineer A AV Informed Employer Decision Enablement Constraint
    The duty to advise clients when a project will not be successful requires ensuring the automobile manufacturer has full material safety information to make informed decisions.
  • Engineer A AV Further Study Before Deployment Constraint
    Advising the client when a project will not be successful requires recommending further study before deployment when safety concerns remain unresolved.
  • Engineer A AV Further Study Recommendation Constraint
    The obligation to advise clients of project concerns directly requires Engineer A to recommend further study rather than remain silent about identified safety issues.
  • Engineer A AV Risk Assessment Active Participation Constraint
    Advising the client of project concerns requires full active participation in the risk assessment process to provide complete and accurate counsel.
  • Engineer A AV Harm Allocation Algorithm Completeness Disclosure Constraint
    Advising the client when a project will not be successful requires complete disclosure of the harm-allocation algorithm's limitations to enable informed client decisions.
  • Engineer A BER 96-4 Business Pressure Technical Separation Constraint
    The duty to advise clients honestly about project success requires separating technical safety assessments from financial pressures when counseling the employer.
  • Engineer A AV Client Interest Third-Party Safety Priority Constraint
    Advising the client when a project will not be successful includes informing them when client commercial interests conflict with third-party safety obligations.
  • Engineer A AV Do No Harm Deployment Constraint
    The obligation to advise clients of project concerns supports the constraint against recommending deployment without first addressing do no harm requirements.
Principle (6)
  • Faithful Agent Obligation Within Ethical Limits Invoked for Engineer A Consultant Role
    III.1.b establishes the faithful agent duty to advise clients honestly, which bounds Engineer A's consultant obligation within ethical limits.
  • Informed Decision-Making Enablement Obligation Invoked for Automobile Manufacturer Client
    III.1.b directly requires Engineer A to advise the manufacturer client when the project may not be successful, enabling informed decision-making.
  • Graduated Internal Escalation Before External Reporting Invoked in Software Testing Case
    III.1.b supports the obligation to first advise the employer internally about project concerns before considering external escalation.
  • Active Risk Assessment Team Participation Obligation Invoked by Engineer A
    III.1.b requires Engineer A to clearly advise the client or employer of concerns, supporting the obligation to fully and unambiguously participate in the risk management team.
  • Do No Harm Obligation Invoked by Engineer A in Autonomous Vehicle Case
    III.1.b supports the do no harm obligation by requiring Engineer A to advise the manufacturer if the autonomous vehicle system is not ready for safe deployment.
  • Regulatory Gap Safety Escalation Obligation Invoked in Software Testing Case
    III.1.b requires advising the client or employer when a project may not succeed, directly applicable when new standards may not be met.
Role (2)
  • Engineer A Autonomous Vehicle Risk Assessment Team Engineer
    Engineer A must advise the automobile manufacturer if the autonomous vehicle project or specific scenarios present unacceptable risks or will not be successful.
  • Engineer A Safety-Critical Software Design Engineer (Case 96-4)
    Engineer A must advise the software company employer if the software project will not meet safety standards and therefore will not be successful.
Event (4)
  • Financial Pressure on Testing
    Engineers must advise employers when financial pressure on testing will likely cause the project to fail or be unsafe.
  • Safety-Critical Software Identified
    Engineers should advise clients or employers when identified safety-critical software issues indicate the project will not succeed safely.
  • Unavoidable Crash Scenario Identified
    Engineers are obligated to advise employers when an unavoidable crash scenario signals the project cannot succeed as planned.
  • Algorithmic Ethics Gap Recognized
    Engineers must advise their employer when a recognized algorithmic ethics gap indicates the AV project will not be successful or safe.
Resource (4)
  • Qualitative Risk Assessment Methodology for Autonomous Vehicle Crash Scenarios
    Engineer A's obligation to advise the client of project failure risk is grounded in the risk assessment findings that indicate potential safety shortfalls.
  • Draft_AV_Safety_Testing_Standard
    The draft standard's requirements that the system may not meet constitute the basis for advising the client that the project may not be successful.
  • BER_Case_96-4
    This precedent establishes that engineers must advise clients to conduct additional testing when a new standard may not be met, directly supporting III.1.b.
  • Software_Safety_Testing_Standard_BER96-4_Context
    The triggering condition of a new draft standard the software may not meet is precisely the situation requiring Engineer A to advise the client under III.1.b.
Capability (5)
  • Engineer A Faithful Agent Informed Decision Enablement Capability
    Structuring and presenting professional analysis to the manufacturer directly fulfills the duty to advise clients when a project may not be successful.
  • Engineer A AV Further Study Recommendation Capability
    Recommending further study when safety concerns are unresolved is a form of advising the employer that the project may not be successful as currently designed.
  • Engineer A Safety-Critical Software Informed Employer Decision Enablement Capability
    Preparing a technical report on testing analysis and results to inform the employer directly fulfills the duty to advise clients about project concerns.
  • Engineer A AV Risk Assessment Active Participation Capability
    Clearly articulating unresolved safety concerns within the risk management team constitutes advising the employer that the project may not be successful.
  • Engineer A Regulatory Gap Safety Escalation Software Standards Capability
    Advising the employer that a regulatory gap heightens safety obligations is a direct application of the duty to inform clients of potential project failure.
Cross-Case Connections
View Extraction
Explicit Board-Cited Precedents 1

Cases explicitly cited by the Board in this opinion. These represent direct expert judgment about intertextual relevance.

Principle Established:

Engineers have a professional obligation to recommend additional testing or study when public health, safety, and welfare may be at risk, and must make recommendations based solely on technical findings rather than business considerations, so that employers can make informed decisions.

Citation Context:

The Board cited this case to establish that engineers must balance technical safety obligations against business pressures, and that the overriding ethical responsibility is to hold paramount the safety, health, and welfare of the public. It is used as an analogous precedent for Engineer A's obligations in the autonomous vehicle context.

Relevant Excerpts
discussion: "One example of this was BER Case 96-4 , which involved software design testing. In that case, Engineer A was employed by a software company and was involved in the design of specialized software"
discussion: "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."
discussion: "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"
Implicit Similar Cases 10 Similarity Network

Cases sharing ontology classes or structural similarity. These connections arise from constrained extraction against a shared vocabulary.

Component Similarity 50% Facts Similarity 42% Discussion Similarity 55% Provision Overlap 60% Outcome Alignment 100% Tag Overlap 56%
Shared provisions: I.1, II.1, II.1.a, III.1.b, III.2, III.5 Same outcome True View Synthesis
Component Similarity 51% Facts Similarity 42% Discussion Similarity 64% Provision Overlap 56% Outcome Alignment 100% Tag Overlap 30%
Shared provisions: I.1, II.1, II.1.a, III.1.b, III.2 Same outcome True View Synthesis
Component Similarity 53% Facts Similarity 52% Discussion Similarity 53% Provision Overlap 50% Outcome Alignment 100% Tag Overlap 30%
Shared provisions: I.1, II.1, II.1.a, III.1.b, III.2 Same outcome True View Synthesis
Component Similarity 54% Facts Similarity 48% Discussion Similarity 57% Provision Overlap 40% Outcome Alignment 100% Tag Overlap 50%
Shared provisions: I.1, II.1, II.1.a, III.1.b Same outcome True View Synthesis
Component Similarity 45% Facts Similarity 25% Discussion Similarity 63% Provision Overlap 50% Outcome Alignment 100% Tag Overlap 56%
Shared provisions: I.1, II.1, II.1.a, III.1.b, III.2.b Same outcome True View Synthesis
Component Similarity 46% Facts Similarity 29% Discussion Similarity 60% Provision Overlap 50% Outcome Alignment 100% Tag Overlap 44%
Shared provisions: I.1, II.1, II.1.a, III.1.b, III.2 Same outcome True View Synthesis
Component Similarity 57% Facts Similarity 44% Discussion Similarity 59% Provision Overlap 41% Outcome Alignment 100% Tag Overlap 21%
Shared provisions: I.1, I.2, II.1, II.1.a, II.2, III.1.b, III.2 Same outcome True View Synthesis
Component Similarity 48% Facts Similarity 42% Discussion Similarity 51% Provision Overlap 50% Outcome Alignment 100% Tag Overlap 30%
Shared provisions: I.1, I.2, III.1.b, III.2, III.5 Same outcome True View Synthesis
Component Similarity 46% Facts Similarity 32% Discussion Similarity 60% Provision Overlap 44% Outcome Alignment 100% Tag Overlap 40%
Shared provisions: I.1, II.1.a, III.1.b, III.2.b Same outcome True View Synthesis
Component Similarity 38% Facts Similarity 26% Discussion Similarity 38% Provision Overlap 60% Outcome Alignment 100% Tag Overlap 27%
Shared provisions: I.1, II.1, II.1.a, II.2, III.1.b, III.2 Same outcome True View Synthesis
Questions & Conclusions (1 board)
View Extraction
Board Board question 1

What are Engineer A’s ethical obligations?

Board conclusion 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.
Implicit (4)

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?

AnalyticalBeyond 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.
AnalyticalThe 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, 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?

AnalyticalIn 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, what are Engineer A's remaining ethical obligations - including whether Engineer A must refuse to continue consulting on the project or escalate concerns externally?

AnalyticalThe 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.
AnalyticalIf 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.

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?

AnalyticalEngineer 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.
Cross-cutting analytical questions (12)

These questions consider the case as a whole rather than a specific board question above.

Principle tension (4)

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?

AnalyticalThe 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.
AnalyticalThe 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.

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?

AnalyticalThe 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.

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?

AnalyticalThe 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.

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?

Theoretical (4)

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?

AnalyticalFrom 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 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?

AnalyticalFrom 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.

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?

Counterfactual (4)

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?

AnalyticalIf 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.

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?

AnalyticalIf 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 - would Engineer A's obligation to recommend further study before deployment have been stronger, weaker, or qualitatively different in character?

AnalyticalHad 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 - 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?

AnalyticalThe 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.
AnalyticalIf 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.
Decisions & Arguments (6)
View Extraction

Should Engineer A actively participate in the risk assessment team and formally express safety concerns about the harm-allocation algorithm, recommending further study before deployment, or should he limit his involvement to completing the technical evaluation without escalating those concerns?

Options considered:
O1 Actively participate in all risk assessment team deliberations, unambiguously express concerns about the harm-allocation algorithm's third-party safety implications in writing, and formally recommend that deployment be deferred pending further study of the ethical and safety questions. Board's choice
O2 Participate in the technical evaluation and deliver a competent risk assessment report, but treat the harm-allocation design choices as policy decisions outside the engineer's professional scope and refrain from formally recommending further study or deferral.
O3 Raise third-party harm concerns verbally during team deliberations to satisfy a minimal participation obligation, but stop short of a formal written recommendation for further study, leaving the decision to escalate to the manufacturer's discretion.
Argument structure:
Warrants

Three clusters of competing obligations bear on this decision. First, the AV Risk Assessment Team Harm Minimization Participation Obligation and the Faithful Agent Informed Decision Enablement Obligation jointly require Engineer A to fully and actively participate, express concerns clearly and unambiguously, and provide the manufacturer with a complete risk assessment. Second, the Do No Harm Obligation and the Autonomous Vehicle Third-Party Harm Minimization Safety Consideration Obligation require Engineer A to ensure that the welfare of pedestrians, cyclists, and motorcyclists is explicitly identified and presented as a material safety consideration: not subordinated to passenger-protective commercial interests. Third, the Technical Recommendation Business Pressure Non-Subordination Obligation and the Further Study Recommendation Before Deployment Obligation require Engineer A to base the recommendation solely on technical and ethical findings, and to recommend further study if material questions remain unresolved, regardless of financial impact, competitive delay, or client pressure.

Rebuttals

Uncertainty arises on two fronts. First, the absence of regulatory standards governing autonomous vehicle harm-allocation logic means no external authority resolves which obligation is paramount or what 'further study' must encompass, leaving the scope of Engineer A's duty to recommend further study potentially indeterminate. Second, a plausible rebuttal holds that Engineer A's role as consultant, rather than certifying engineer, limits how far he must press concerns before his professional duty is satisfied, and that actively recommending further study over the team's objection may exceed the scope of a consultant's mandate and create adversarial dynamics that reduce rather than increase the manufacturer's receptivity to safety concerns.

Grounds

Engineer A is a licensed professional engineer serving as a consultant on an automobile manufacturer's risk assessment team evaluating a driverless/autonomous vehicle operating system. The team has identified unavoidable crash scenarios in which the vehicle's pre-committed harm-allocation algorithm must choose between protecting passengers and minimizing harm to third parties: pedestrians, cyclists, and motorcycle riders. No applicable national or industry standards governing autonomous vehicle harm-allocation decision logic currently exist. The team faces commercial pressure to deliver a deployment-ready recommendation. Engineer A has recognized an algorithmic ethics gap and is aware of analogous precedent from BER Case 96-4 requiring further study before deployment of safety-critical software.

Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation / Autonomous Vehicle Further Study Recommendation Before Deployment Obligation Engineer A AV Client Interest Third-Party Safety Priority Constraint

Should Engineer A explicitly disclose in the risk assessment report that the harm-minimization recommendation is grounded in a utilitarian ethical framework and recommend pre-sale public disclosure to consumers, or should Engineer A present the recommendation without labeling its philosophical basis?

Options considered:
O1 Explicitly identify in the written risk assessment report that the harm-minimization recommendation is grounded in a utilitarian ethical framework, present the deontological alternative and its trade-offs, and recommend that the manufacturer publicly disclose the embedded ethical framework to prospective consumers before sale. Board's choice
O2 Present both the passenger-priority and harm-minimization frameworks objectively in the risk assessment report, including their respective advantages and disadvantages, without labeling either as utilitarian or deontological, and without recommending consumer-facing disclosure.
O3 Identify the philosophical basis of the harm-minimization recommendation in the internal report delivered to the manufacturer, but limit the disclosure to the client relationship and recommend that the manufacturer seek interdisciplinary ethics review rather than affirmatively advocating for consumer-facing disclosure.
Argument structure:
Warrants

Four obligations converge on the disclosure question. First, the Completeness and Non-Selectivity in Advisory Opinions principle requires Engineer A not to present a recommendation grounded in a specific moral philosophy as though it were a technically mandated norm, selective silence about the utilitarian basis of the recommendation would itself be a form of incomplete and potentially misleading professional advice. Second, the Informed Decision-Making Enablement Obligation requires that the manufacturer be able to give genuine informed consent to the embedded ethical framework, which is impossible if Engineer A does not identify the framework's philosophical basis and acknowledge that alternative frameworks exist and yield different algorithmic outcomes. Third, the Autonomous System Moral Framework Transparency Obligation requires public disclosure of the decision logic governing the fate of users and third parties who cannot intervene in real time. Fourth, the Regulatory Gap Safety Escalation Obligation, drawn from BER Case 96-4, establishes that the absence of applicable standards is itself a safety-relevant fact that heightens rather than relieves the professional advisor's disclosure obligations.

Rebuttals

Two rebuttals create genuine uncertainty. First, Engineer A's role is consultant to the manufacturer rather than a regulator or public advocate, raising the question of whether his duty to recommend public disclosure extends beyond advising the client to encompass affirmative advocacy for consumer-facing transparency that the manufacturer has not requested and may regard as legally or competitively harmful. Second, the NSPE Code contains no provision that explicitly requires engineers to label the philosophical foundations of technical recommendations, leaving open the argument that Engineer A satisfies his completeness obligation by presenting both harm-distribution frameworks objectively without characterizing either as utilitarian or deontological, and that the philosophical labeling obligation, if it exists, is a matter of professional judgment rather than a codified duty.

Grounds

Engineer A has been asked to make a recommendation regarding the crash-avoidance algorithm's harm-distribution logic for an autonomous vehicle operating system. The board's harm-minimization conclusion implicitly adopts a utilitarian ethical framework, aggregate harm reduction across all affected parties, without acknowledging that this represents one among several defensible moral philosophies. A deontological framework would yield different algorithmic constraints. No applicable national or industry standards currently govern autonomous vehicle harm-allocation decision logic, meaning Engineer A cannot represent the harm-minimization recommendation as a technically mandated or universally accepted engineering norm. The regulatory vacuum means that Engineer A's professional judgment substitutes for the absent standard and must therefore be rendered fully transparent to both the manufacturer and, ultimately, the public.

Autonomous Vehicle Harm Minimization Algorithm Completeness Disclosure Obligation / Autonomous Vehicle Moral Framework Public Transparency Disclosure Obligation Engineer A AV Regulatory Standards Vacuum Escalation Permissibility Constraint

Should Engineer A formally notify the manufacturer's responsible decision-makers of the foreseeable fatal risk and, if unresolved, decline to certify the passenger-priority system, or should Engineer A document the disagreement without further escalation, or recommend an independent ethics review as an alternative to certification refusal?

Options considered:
O1 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, and decline to certify or approve the system if the manufacturer does not reconcile the algorithm with public safety obligations, with external reporting as a further step if internal escalation fails. Board's choice
O2 Formally document the safety disagreement in writing and deliver it to the manufacturer's project lead, but upon being overruled treat the internal escalation obligation as discharged and take no further action, neither declining to certify nor considering external reporting.
O3 Document the safety disagreement in the final risk assessment report and recommend that the manufacturer obtain an independent ethics and safety review of the passenger-priority algorithm before deployment, treating that recommendation as a substitute for Engineer A's own certification refusal or external escalation.
Argument structure:
Warrants

Three sequenced obligations govern Engineer A's response to a manufacturer override. First, the Graduated Internal Escalation Before External Reporting principle requires Engineer A to formally document the disagreement in writing and communicate it to the manufacturer's responsible decision-makers, ensuring the override is made with full awareness of its third-party safety consequences rather than by default or inattention. Second, the prohibition on approving engineering documents not in conformity with sound engineering principles, Code II.1.b, requires Engineer A to assess whether the passenger-priority system crosses the threshold from a debatable design choice into a design Engineer A cannot professionally certify as safe for public deployment; if it does, Engineer A must decline to certify or approve the system. Third, the Public Welfare Paramount obligation is not discharged by internal voicing of concern alone when that concern is overridden and a harmful design proceeds, if internal escalation fails and the severity and foreseeability of third-party harm risk is sufficient, Engineer A must evaluate whether external reporting obligations are triggered.

Rebuttals

Genuine uncertainty arises on two dimensions. First, the NSPE Code's graduated escalation framework, drawn from BER Case 96-4, was developed in the context of a direct employment relationship with multiple organizational tiers; it is unclear whether that framework maps cleanly onto a consultant relationship where Engineer A has fewer escalation tiers available and less organizational leverage. A plausible rebuttal holds that a consultant who has formally documented a safety concern and been overruled has discharged the internal escalation component more rapidly than an employee, and that the threshold for external reporting is therefore reached sooner, but this reading is contested. Second, the pre-committed passenger-priority algorithm may be characterized as a debatable design choice within the range of defensible engineering judgment rather than a design that crosses the threshold requiring refusal to certify, particularly if the manufacturer can demonstrate that the algorithm meets all currently applicable safety standards, leaving Engineer A's certification refusal potentially unsupported by an objective technical standard.

Grounds

After receiving Engineer A's harm-minimization recommendation, the automobile manufacturer overrides it and elects to program the autonomous vehicle to prioritize passenger safety above third-party welfare. The passenger-priority algorithm foreseeably creates fatal risk for pedestrians, cyclists, and motorcycle riders in a predictable class of crash scenarios. Engineer A is a consultant rather than a direct employee, which affects the procedural mechanisms available for escalation but, under the NSPE Code, does not diminish the substantive scope of the public welfare paramount obligation. No applicable regulatory standards exist that would independently mandate or prohibit either design choice. The graduated internal escalation framework from BER Case 96-4 is the closest applicable precedent.

Engineer A AV Faithful Agent Informed Decision Enablement Obligation / Technical Recommendation Business Pressure Non-Subordination Obligation Engineer A AV Passenger Priority Algorithm Third-Party Fatal Harm Non-Subordination Constraint

Should Engineer A formally advocate within the risk assessment team that the harm-allocation algorithm minimize harm to the least number of persons, even under commercial pressure to prioritize passenger safety, or should Engineer A defer to the manufacturer's preferred passenger-priority framework?

Options considered:
O1 Formally recommend that the harm-allocation algorithm minimize harm to the least number of persons, actively express this position within the risk assessment team, and document the recommendation in writing so the manufacturer's decision-makers have a clear record of the safety concern. Board's choice
O2 Present harm-minimization as one among several technically defensible design options without advocating for it as the professionally required choice, and defer to the risk assessment team's collective judgment on which framework to adopt.
O3 Treat the manufacturer's passenger-priority preference as a legitimate design policy choice within the manufacturer's authority, and complete the risk assessment without formally contesting the harm-allocation framework on public-welfare grounds.
Argument structure:
Warrants

The Public Welfare Paramount obligation (NSPE Code I.1, II.1) requires Engineer A to hold paramount the safety, health, and welfare of the public, including third parties not party to the client relationship. The Aggregate Harm Minimization principle directs that when lives cannot all be protected, the ethical directive is to minimize the total number of persons harmed. The Third-Party Non-Client Welfare Consideration requires that pedestrians, cyclists, and motorcyclists be afforded professional protection. The Active Risk Assessment Team Participation Obligation requires Engineer A to engage substantively rather than passively. The Technical Recommendation Business Pressure Non-Subordination Obligation prohibits Engineer A from softening or suppressing safety findings to accommodate commercial preferences. Competing against these is the Faithful Agent Obligation Within Ethical Limits, which requires Engineer A to serve the manufacturer's interests, but only within the bounds the paramount obligation defines.

Rebuttals

Uncertainty arises because passengers are also members of the public whose welfare counts, meaning the Public Welfare Paramount principle does not straightforwardly resolve the passenger-versus-third-party tension without additional normative work. A consequentialist rebuttal holds that a passenger-sacrifice algorithm might so severely depress autonomous vehicle adoption that aggregate lives saved over time would favor passenger-priority logic. A deontological rebuttal holds that any pre-committed harm-allocation algorithm, including harm minimization, treats some class of persons as instrumental means, meaning the binary framing itself may be ethically problematic. The absence of regulatory standards means no external authority validates the harm-minimization recommendation as a technically mandated norm rather than one among several defensible moral philosophies.

Grounds

An automobile manufacturer has initiated development of an autonomous vehicle operating system. Engineer A, serving as a consultant on the risk assessment team, has identified an unavoidable crash scenario in which the vehicle's pre-committed harm-allocation logic must choose between protecting passengers and minimizing harm to third parties (pedestrians, cyclists, motorcyclists). No applicable national or industry standards governing autonomous vehicle harm-allocation decision logic currently exist. The risk assessment team faces commercial pressure to prioritize passenger safety. Engineer A has recognized an algorithmic ethics gap and has the technical expertise to evaluate the safety implications of competing design choices.

Engineer A Autonomous Vehicle Do No Harm Obligation and Risk Assessment Active Participation Obligation Engineer A AV Client Interest Third-Party Safety Priority Constraint

Should Engineer A fully disclose to the automobile manufacturer that the harm-minimization recommendation reflects a utilitarian moral philosophy and recommend pre-sale consumer disclosure, partially disclose only to the manufacturer without advocating for consumer transparency, or present the recommendation as professional judgment without labeling its philosophical basis?

Options considered:
O1 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, and recommend that the manufacturer publicly disclose the embedded ethical framework to prospective consumers before sale. Board's choice
O2 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 stop short of recommending consumer-facing disclosure, treating the client relationship as the boundary of Engineer A's advisory obligation.
O3 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 no code provision explicitly requires engineers to identify the moral framework underlying a technical recommendation.
Argument structure:
Warrants

The Completeness and Non-Selectivity in Advisory Opinions principle requires Engineer A not to present a recommendation grounded in a specific moral philosophy as though it were a technically mandated or universally accepted engineering norm. The Informed Decision-Making Enablement Obligation requires that the manufacturer be able to give genuine informed consent to the embedded ethical framework it is adopting. The Autonomous System Moral Framework Transparency Obligation recognizes that users and affected third parties have a legitimate interest in knowing the pre-committed decision logic governing their fate. The Regulatory Gap Safety Escalation principle, drawn from BER Case 96-4, establishes that the absence of external standards heightens rather than relieves the professional advisor's disclosure obligations, because Engineer A's judgment substitutes for the absent standard and must therefore be rendered fully transparent. The Public Welfare Paramount principle extends protection from physical harm to protection from material deception about the nature of safety-affecting products.

Rebuttals

The disclosure obligation is complicated by the absence of any NSPE Code provision explicitly requiring engineers to label the philosophical foundations of technical recommendations. A rebuttal condition holds that Engineer A's role is consultant to the manufacturer rather than a regulator or public advocate, raising the question of whether the duty to recommend public consumer disclosure exceeds the scope of the consulting engagement. 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, potentially conflicting with the faithful agent obligation. A further rebuttal holds that the perfect-duty characterization of the disclosure obligation is weakened if disclosure of the harm-allocation algorithm's moral framework would compromise legitimate proprietary interests without a counterbalancing public safety benefit that could not be achieved through less disclosure-intensive means.

Grounds

Engineer A has identified an algorithmic ethics gap: no applicable national or industry standards govern autonomous vehicle harm-allocation decision logic. The harm-minimization recommendation Engineer A is prepared to make is grounded in a utilitarian aggregate-harm calculus, a specific moral philosophy that reasonable engineers and ethicists might contest. Alternative frameworks (deontological, virtue-based) yield different algorithmic outcomes. The manufacturer is preparing to embed a harm-allocation framework in a consumer product that will affect the safety of passengers, pedestrians, cyclists, and motorcyclists who cannot intervene in real time. Prospective consumers and affected third parties have no current mechanism to learn what decision logic governs the vehicle's behavior in unavoidable crash scenarios.

Autonomous Vehicle Moral Framework Public Transparency Recommendation Obligation and Completeness and Non-Selectivity in Advisory Opinions Engineer A AV Harm Allocation Moral Framework Non-Deception Public Disclosure Constraint

Should Engineer A formally document the safety disagreement and decline to certify the passenger-priority system unless the public safety conflict is resolved, continue technical participation while documenting the concern, or withdraw from the engagement without formal certification refusal?

Options considered:
O1 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 public safety obligations, and treat consultant status as not diminishing the graduated escalation duty, including potential external reporting if internal escalation fails. Board's choice
O2 Document the safety concern in the consulting deliverable and communicate the disagreement to the manufacturer's project lead, but continue participating in the technical optimization of the passenger-priority system on the basis that the consultant relationship limits Engineer A's escalation obligations to advisory disclosure rather than certification refusal.
O3 Withdraw from the consulting engagement upon the manufacturer's override without formal written documentation of the specific safety threshold crossed, treating the consultant relationship as relieving Engineer A of the graduated escalation and certification obligations that would apply in a direct employment context.
Argument structure:
Warrants

The Public Welfare Paramount obligation (NSPE Code I.1, II.1) is not extinguished by client disagreement and applies with equal force to consultants and employees. The Graduated Internal Escalation Before External Reporting principle, drawn from BER Case 96-4, requires Engineer A to formally document disagreement in writing and communicate it to the manufacturer's responsible decision-makers before considering withdrawal or external reporting. The Code prohibition on approving engineering documents not in conformity with sound engineering principles (II.1.b) requires Engineer A to decline to certify a passenger-priority system if it crosses the threshold of unjustifiable third-party risk. The consultant's professional independence, which the client engaged as a resource, strengthens rather than weakens the obligation to provide honest, complete, and unvarnished safety assessments, while compressing the internal escalation sequence because fewer organizational tiers exist. The Faithful Agent Obligation Within Ethical Limits does not authorize Engineer A to implicitly endorse a harmful design through continued participation.

Rebuttals

Uncertainty arises because the NSPE Code's graduated escalation framework requires internal escalation before external reporting, but it is unclear whether that framework, developed in an employment context, maps cleanly onto a consultant relationship with a compressed organizational hierarchy. A rebuttal condition holds that a consultant who has formally documented a safety concern and been overruled has discharged the internal escalation component more rapidly than an employee, potentially triggering external reporting obligations sooner. A further rebuttal holds that continued participation in the project, even with documented objections, may or may not constitute implicit endorsement depending on whether Engineer A's role involves certification or approval of the final system. The threshold at which the pre-committed passenger-priority policy crosses from a debatable design choice into a design Engineer A cannot certify is itself contested and fact-dependent.

Grounds

Engineer A has delivered a harm-minimization recommendation to the automobile manufacturer. The manufacturer has overridden that recommendation and elected to program the vehicle to prioritize passenger safety above third-party welfare. Engineer A is a consultant rather than a direct employee, meaning fewer organizational escalation tiers exist through which concerns can be pressed. The passenger-priority algorithm creates a foreseeable risk of fatal harm to identifiable third-party classes, pedestrians, cyclists, motorcycle riders, in a predictable class of unavoidable crash scenarios. No applicable regulatory standards exist to provide an external benchmark for evaluating whether the manufacturer's override decision is professionally certifiable.

Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation and Graduated Internal Escalation Before External Reporting Engineer A AV Passenger Priority Algorithm Third-Party Fatal Harm Non-Subordination Constraint
13 sequenced 6 actions 7 events
Case timeline
The software under development at Engineer A's company is recognized as safety-critical, meaning defects could directly cause harm or loss of life. This classification triggers heightened professional and ethical obligations.
Relevant draft standards for safety-critical software are published or circulated during the period of development, creating an evolving regulatory and professional context that Engineer A must navigate without the clarity of finalized rules.
Business and financial pressures within the software company create institutional resistance to additional safety testing, placing Engineer A in direct conflict between employer interests and professional safety obligations.
Engineer A chose to recommend costly additional software testing to his company despite significant financial and competitive pressures, fulfilling his professional obligation to prioritize public safety over business convenience.
Fulfills (4)
  • Hold paramount the safety, health, and welfare of the public (NSPE Code Section II.4.a.)
  • Provide technically honest and accurate information to employer (NSPE Code Section III.6.b.)
  • Base safety recommendations solely on technical findings, not business considerations
  • Strive to do no harm in the performance of professional services
Engineer A prepared a technical report clearly documenting current testing analysis, results, and the new testing procedure reported in professional literature, so that his employer could make a fully informed decision regarding additional testing.
Fulfills (5)
  • Issue public statements in an objective and truthful manner (NSPE Code Section III.6.b.)
  • Act in such a manner as to uphold and enhance the honor, integrity, and dignity of the engineering profession (NSPE Code Section II.4.a.)
  • Provide clear, accurate, and direct information to employer and client
  • Enable informed decision-making in furtherance of public health, safety, and welfare
  • Strive to do no harm in performance of professional services
An automobile manufacturer begins early development and assessment of an autonomous vehicle operating system, creating a new safety-critical engineering context that requires prospective ethical analysis before deployment.
The ethical principles established in BER Case 96-4, specifically regarding the primacy of public safety over financial considerations and the obligation to recommend additional scrutiny when safety is uncertain, become directly applicable to the present AV case, creating a normative bridge between the two scenarios.
Engineer A chose to fully and actively participate as a member of the engineering risk assessment team evaluating ethical and safety scenarios for the autonomous vehicle operating system, rather than adopting a passive or deferential role within the team.
At stake (2)
  • Hold paramount the safety, health, and welfare of the public
  • Strive to do no harm in the performance of professional services
Fulfills (2)
  • Fulfill professional responsibility as a member of a safety-critical engineering team
  • Contribute technical expertise to inform employer decision-making on public safety matters
During risk assessment, the team identifies that the AV operating system will inevitably encounter crash scenarios where harm to some party is unavoidable, requiring the software to encode a priority ordering of harm outcomes, a fundamentally ethical decision embedded in code.
The risk assessment process reveals that existing engineering ethics frameworks, professional codes, and technical standards do not provide clear, actionable guidance for encoding moral priority orderings in autonomous vehicle software, creating a normative vacuum at the precise moment design decisions must be made.
Engineer A chose to clearly and unambiguously express any and all concerns regarding the safety of the proposed autonomous vehicle operating system within the risk assessment team, rather than moderating or suppressing concerns due to business or team pressures.
At stake (2)
  • Hold paramount the safety, health, and welfare of the public
  • Strive to do no harm in performance of professional services
Fulfills (2)
  • Provide honest and complete professional judgment to employer
  • Act in such a manner as to uphold and enhance the honor, integrity, and dignity of the engineering profession
Engineer A chose to actively explore additional potential technical options that could mitigate the risks identified in the proposed autonomous vehicle operating system, going beyond simply identifying problems to proactively seeking engineering solutions.
At stake (2)
  • Hold paramount the safety, health, and welfare of the public
  • Strive to do no harm in performance of professional services
Fulfills (2)
  • Contribute technical expertise constructively to employer decision-making
  • Fulfill professional responsibility as a risk assessment team member
Engineer A chose, where necessary, to propose that further study be undertaken by the manufacturer before the autonomous vehicle operating system is utilized, prioritizing thoroughness of safety validation over development speed.
Fulfills (4)
  • Hold paramount the safety, health, and welfare of the public
  • Strive to do no harm in performance of professional services
  • Provide honest and complete professional judgment to employer even when financially inconvenient
  • Fulfill obligation to recommend technically sound safety measures independent of business considerations
Narrative (1 main characters)
View Extraction
Opening Context

Written in second person from the engineer's point of view, so you read the case as the professional experienced it. Underlined names link to the character's profile below.

You are Engineer A, a professional engineer working as a consultant to an automobile manufacturer that is evaluating the development of a driverless autonomous vehicle operating system. You have been assigned to an engineering risk assessment team tasked with analyzing potential situations that could arise during autonomous vehicle operation. One scenario under review asks whether, in the event of an unavoidable crash, the vehicle's software should prioritize the safety of its own passengers or instead minimize total harm to all parties, including pedestrians, cyclists, and motorcycle riders who may be at risk. No established national or industry standards currently govern how harm-allocation decision logic should be designed or disclosed in autonomous vehicle systems. The recommendations your team produces will directly inform the manufacturer's development decisions. You must now work through the technical, ethical, and professional obligations that apply to your role in this process.

Main characters (1)

Each card shows the roles a person holds and the tensions those roles raise for them. A single person may carry several roles in the case, and a tension between obligations can implicate more than one person at once. Click Show all tensions for the full list.

Engineer A Roles in this case: Autonomous Vehicle Risk Assessment Team Engineer

Tension between Engineer A AV Faithful Agent Informed Decision Enablement Obligation / Technical Recommendation Business Pressure Non-Subordination Obligation and Engineer A AV Passenger Priority Algorithm Third-Party Fatal Harm Non-Subordination Constraint

Tension between Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation and Graduated Internal Escalation Before External Reporting and Engineer A AV Passenger Priority Algorithm Third-Party Fatal Harm Non-Subordination Constraint

Engineer A has a dual obligation: to refuse subordination of technical safety recommendations to business pressure, and simultaneously to act as a faithful agent enabling the employer/client to make informed decisions. These obligations pull in opposing directions when the client's informed decision—made with full knowledge of Engineer A's safety concerns—is nonetheless to proceed with deployment. If the client is fully informed yet still chooses deployment, the faithful-agent obligation is technically satisfied, but the non-subordination obligation may require Engineer A to escalate or refuse participation, going beyond mere disclosure. Conversely, limiting action to enabling informed decisions without further resistance could be construed as tacit subordination of safety judgment to business outcomes. The tension is between respecting client autonomy after disclosure and maintaining independent professional integrity.

Tension between Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation / Autonomous Vehicle Further Study Recommendation Before Deployment Obligation and Engineer A AV Client Interest Third-Party Safety Priority Constraint

Tension between Engineer A Autonomous Vehicle Do No Harm Obligation and Risk Assessment Active Participation Obligation and Engineer A AV Client Interest Third-Party Safety Priority Constraint

Engineer A is obligated to recommend further study before deployment of the autonomous vehicle system, yet the client (automobile manufacturer) has strong commercial interests in proceeding to market. The constraint demands that third-party safety must take priority over client interests, but acting on this constraint by insisting on further study directly conflicts with the client's deployment timeline and business objectives. Fulfilling the obligation faithfully may require Engineer A to resist client pressure in ways that jeopardize the professional relationship, while yielding to client interest violates the safety-priority constraint. This creates a genuine dilemma between professional loyalty to the client as faithful agent and paramount duty to public safety.

Tension between Autonomous Vehicle Harm Minimization Algorithm Completeness Disclosure Obligation / Autonomous Vehicle Moral Framework Public Transparency Disclosure Obligation and Engineer A AV Regulatory Standards Vacuum Escalation Permissibility Constraint

Engineer A is obligated to recommend that the moral framework embedded in the AV harm-minimization algorithm be disclosed publicly so that consumers and society can make informed decisions. However, the algorithmic pre-commitment ethical constraint recognizes that encoding a fixed harm-allocation decision in advance—and then disclosing it—raises profound ethical problems: public disclosure of a pre-committed framework (e.g., passenger-over-pedestrian priority) may itself be ethically impermissible if that framework encodes morally objectionable trade-offs. Fulfilling the transparency obligation by disclosing the framework validates and entrenches a potentially unjust pre-commitment, while suppressing disclosure violates the transparency obligation. The engineer cannot simultaneously satisfy full transparency and avoid legitimizing an ethically contested algorithmic moral stance.

Tension between Autonomous Vehicle Moral Framework Public Transparency Recommendation Obligation and Completeness and Non-Selectivity in Advisory Opinions and Engineer A AV Harm Allocation Moral Framework Non-Deception Public Disclosure Constraint

Other people involved in the case but not central to the opening narrative.

Engineer A has a dual obligation: to refuse subordination of technical safety recommendations to business pressure, and simultaneously to act as a faithful agent enabling the employer/client to make informed decisions. These obligations pull in opposing directions when the client's informed decision—made with full knowledge of Engineer A's safety concerns—is nonetheless to proceed with deployment. If the client is fully informed yet still chooses deployment, the faithful-agent obligation is technically satisfied, but the non-subordination obligation may require Engineer A to escalate or refuse participation, going beyond mere disclosure. Conversely, limiting action to enabling informed decisions without further resistance could be construed as tacit subordination of safety judgment to business outcomes. The tension is between respecting client autonomy after disclosure and maintaining independent professional integrity.

Engineer A is obligated to recommend further study before deployment of the autonomous vehicle system, yet the client (automobile manufacturer) has strong commercial interests in proceeding to market. The constraint demands that third-party safety must take priority over client interests, but acting on this constraint by insisting on further study directly conflicts with the client's deployment timeline and business objectives. Fulfilling the obligation faithfully may require Engineer A to resist client pressure in ways that jeopardize the professional relationship, while yielding to client interest violates the safety-priority constraint. This creates a genuine dilemma between professional loyalty to the client as faithful agent and paramount duty to public safety.

Engineer A is obligated to recommend that the moral framework embedded in the AV harm-minimization algorithm be disclosed publicly so that consumers and society can make informed decisions. However, the algorithmic pre-commitment ethical constraint recognizes that encoding a fixed harm-allocation decision in advance—and then disclosing it—raises profound ethical problems: public disclosure of a pre-committed framework (e.g., passenger-over-pedestrian priority) may itself be ethically impermissible if that framework encodes morally objectionable trade-offs. Fulfilling the transparency obligation by disclosing the framework validates and entrenches a potentially unjust pre-commitment, while suppressing disclosure violates the transparency obligation. The engineer cannot simultaneously satisfy full transparency and avoid legitimizing an ethically contested algorithmic moral stance.

Engineer A has a dual obligation: to refuse subordination of technical safety recommendations to business pressure, and simultaneously to act as a faithful agent enabling the employer/client to make informed decisions. These obligations pull in opposing directions when the client's informed decision—made with full knowledge of Engineer A's safety concerns—is nonetheless to proceed with deployment. If the client is fully informed yet still chooses deployment, the faithful-agent obligation is technically satisfied, but the non-subordination obligation may require Engineer A to escalate or refuse participation, going beyond mere disclosure. Conversely, limiting action to enabling informed decisions without further resistance could be construed as tacit subordination of safety judgment to business outcomes. The tension is between respecting client autonomy after disclosure and maintaining independent professional integrity.

Opening States (10)
Autonomous System Harm Allocation Design State Engineer A Ethical Dilemma - Harm Allocation Recommendation Emerging Standard Pre-Adoption Safety Gap State Present Case Client-Interest vs Third-Party Safety Algorithmic Pre-Commitment Regulatory Standards Vacuum for Autonomous Vehicle Ethics State Client-Interest vs. Third-Party Safety Algorithmic Pre-Commitment State Autonomous Vehicle Harm Allocation Design Assignment Autonomous Vehicle Ethics Regulatory Standards Vacuum Passenger Safety vs. Third-Party Harm Minimization Algorithm Conflict Public Safety at Risk - Autonomous Vehicle Third-Party Harm
Summary
  • When regulatory frameworks have not yet caught up to emerging technology, engineers bear a heightened personal obligation to surface ethical concerns rather than defaulting to compliance silence.
  • The prime directive of harm minimization cannot be subordinated to client commercial interests or passenger-priority algorithms when third-party fatal harm is a foreseeable outcome.
  • A stalemate resolution signals that the board identified irreconcilable competing duties, meaning the engineer's obligation defaults to the most protective principle — public safety — as the irreducible floor.