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
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
NSPE Code Provisions Referenced
Section I. Fundamental Canons 1 53 entities

Hold paramount the safety, health, and welfare of the public.

Applies To (53)
Role
Engineer A Autonomous Vehicle Risk Assessment Team Engineer Engineer A must hold paramount public safety when evaluating autonomous vehicle risk scenarios for the manufacturer.
Role
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
Obligation
Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation Holding paramount public safety directly requires active participation in harm minimization evaluation.
Obligation
Engineer A AV Risk Assessment Third-Party Safety Consideration Obligation Holding paramount public safety requires explicitly identifying and assessing third-party safety risks.
Obligation
Engineer A AV Further Study Recommendation Before Deployment Obligation Holding paramount public safety requires recommending further study before deploying potentially unsafe AV technology.
Obligation
Engineer A Autonomous Vehicle Do No Harm Obligation The paramount safety provision directly underpins the obligation to strive to do no harm.
Obligation
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.
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.
State
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.
State
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.
State
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.
State
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.
State
Present Case Autonomous System Harm Allocation Design Designing harm-allocation decision logic must be governed by the paramount obligation to protect public safety.
State
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.
Resource
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.
Resource
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.
Resource
Autonomous Vehicle Operating System Safety Standard Holding public safety paramount requires adherence to safety standards governing autonomous vehicle operating systems.
Resource
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.
Action
Recommend Additional Safety Testing Holding public safety paramount directly governs recommending further safety testing before deployment.
Action
Actively Participate in Risk Assessment Paramount duty to public safety requires active engagement in identifying and assessing risks.
Action
Unambiguously Express Safety Concerns Holding public safety paramount obligates engineers to clearly voice safety concerns.
Action
Propose Further Study Before Deployment Prioritizing public welfare governs proposing additional study to ensure safe deployment.
Event
Safety-Critical Software Identified Identifying safety-critical software directly invokes the paramount duty to protect public safety.
Event
Unavoidable Crash Scenario Identified An unavoidable crash scenario directly threatens public safety and welfare, triggering the paramount obligation.
Event
Algorithmic Ethics Gap Recognized A gap in algorithmic ethics in an AV system poses a direct risk to public health and safety.
Event
Financial Pressure on Testing Allowing financial pressure to compromise testing undermines the paramount duty to protect public safety.
Capability
Engineer A AV Public Transparency Advocacy Capability Holding public safety paramount requires transparency about moral frameworks encoded in AV algorithms that affect public welfare.
Capability
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.
Capability
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.
Capability
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.
Capability
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.
Capability
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.
Capability
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.
Capability
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
Engineer A AV Further Study Before Deployment Constraint Paramount public safety requires recommending further study before deploying an AV system with unresolved safety concerns.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
Engineer A AV Active Participation Concern Expression Constraint Holding public safety paramount obligates active rather than passive participation in safety processes affecting the public.
Constraint
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.
Section II. Rules of Practice 3 120 entities

Engineers shall hold paramount the safety, health, and welfare of the public.

Applies To (56)
Role
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.
Role
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
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.
Obligation
Engineer A AV Risk Assessment Third-Party Safety Consideration Obligation Holding paramount public welfare requires explicitly considering third-party safety impacts in risk assessments.
Obligation
Engineer A AV Further Study Recommendation Before Deployment Obligation Holding paramount public safety requires recommending further study before AV deployment if risks remain unresolved.
Obligation
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.
Obligation
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.
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.
State
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.
State
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.
State
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.
State
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.
State
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.
State
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.
State
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.
Resource
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.
Resource
ISO 26262 Automotive Functional Safety Standard Holding public safety paramount in automotive engineering requires conformance with ISO 26262 as the governing functional safety standard.
Resource
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.
Resource
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.
Resource
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.
Action
Recommend Additional Safety Testing The duty to hold public safety paramount governs recommending additional testing to mitigate risks.
Action
Actively Participate in Risk Assessment Engineers must hold public safety paramount, which requires active participation in risk assessment processes.
Action
Unambiguously Express Safety Concerns This provision obligates engineers to clearly express safety concerns to protect the public.
Action
Propose Further Study Before Deployment Holding public welfare paramount governs proposing further study before a potentially unsafe deployment.
Event
Safety-Critical Software Identified Engineers must hold public safety paramount when safety-critical software issues are discovered in AV development.
Event
Unavoidable Crash Scenario Identified Engineers are obligated to prioritize public welfare when a crash scenario with potential harm is identified.
Event
Algorithmic Ethics Gap Recognized Recognizing an ethics gap in AV algorithms requires engineers to uphold public safety above other interests.
Event
Financial Pressure on Testing Engineers must hold public safety paramount even when facing financial pressure to reduce testing rigor.
Capability
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.
Capability
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.
Capability
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.
Capability
Engineer A AV Harm Minimization Risk Management Participation Full participation in risk management directly fulfills the engineer's duty to hold public safety paramount.
Capability
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.
Capability
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.
Capability
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.
Capability
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.

Engineers shall approve only those engineering documents that are in conformity with applicable standards.

Applies To (32)
Role
Engineer A Autonomous Vehicle Risk Assessment Team Engineer Engineer A should only approve engineering documents for the autonomous vehicle that conform to applicable standards.
Role
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
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.
Obligation
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.
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.
State
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.
State
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.
State
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.
Resource
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.
Resource
Autonomous Vehicle Operating System Safety Standard Engineer A may only approve engineering documents if the autonomous vehicle operating system conforms to applicable safety standards.
Resource
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.
Resource
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.
Resource
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.
Action
Prepare Transparent Technical Report Engineers must approve only documents conforming to applicable standards, governing the preparation of accurate and transparent technical reports.
Action
Recommend Additional Safety Testing Approving only conforming engineering documents governs recommending testing to ensure standards compliance.
Event
Draft Safety Standards Emerge Engineers should only approve engineering documents and designs that conform to the emerging applicable safety standards.
Event
Safety-Critical Software Identified Engineers must ensure safety-critical software documentation conforms to applicable standards before approval.
Event
Autonomous Vehicle AV OS Development Initiated The initiation of AV OS development requires that all engineering documents conform to applicable standards.
Capability
Engineer A AV Crash Scenario Technical Safety Analysis Capability Approving only conforming engineering documents requires technical analysis of crash scenarios against applicable safety standards.
Capability
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.
Capability
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.
Capability
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.
Capability
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.

Engineers may express publicly technical opinions that are founded upon knowledge of the facts and competence in the subject matter.

Applies To (32)
Role
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.
Role
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
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.
Obligation
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.
Obligation
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.
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.
State
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.
State
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.
State
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.
Resource
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.
Resource
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.
Action
Prepare Transparent Technical Report Expressing technical opinions publicly must be founded on facts and competence, directly governing transparent technical reporting.
Action
Unambiguously Express Safety Concerns This provision governs public expression of safety concerns, requiring they be grounded in knowledge and competence.
Event
Unavoidable Crash Scenario Identified Engineers may publicly express technical opinions about unavoidable crash scenarios based on their factual knowledge and competence.
Event
Algorithmic Ethics Gap Recognized Engineers with competence in AV systems may publicly express opinions about identified algorithmic ethics gaps.
Event
Draft Safety Standards Emerge Engineers may publicly comment on emerging draft safety standards when they have relevant knowledge and expertise.
Capability
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.
Capability
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.
Capability
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.
Capability
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Section III. Professional Obligations 1 41 entities

Engineers shall advise their clients or employers when they believe a project will not be successful.

Applies To (41)
Role
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.
Role
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
Principle
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.
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.
Obligation
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.
Obligation
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.
Obligation
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.
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.
State
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.
State
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.
State
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.
State
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.
Resource
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.
Resource
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.
Resource
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.
Resource
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.
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.
Action
Explore Additional Technical Mitigation Options Advising clients of project risks governs exploring mitigation options to address identified deficiencies.
Action
Propose Further Study Before Deployment The duty to advise clients when a project will not be successful governs proposing further study before deployment.
Event
Financial Pressure on Testing Engineers must advise employers when financial pressure on testing will likely cause the project to fail or be unsafe.
Event
Safety-Critical Software Identified Engineers should advise clients or employers when identified safety-critical software issues indicate the project will not succeed safely.
Event
Unavoidable Crash Scenario Identified Engineers are obligated to advise employers when an unavoidable crash scenario signals the project cannot succeed as planned.
Event
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.
Capability
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.
Capability
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.
Capability
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.
Capability
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.
Capability
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
Constraint
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.
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 48% 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 43% Facts Similarity 22% Discussion Similarity 61% Provision Overlap 56% 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 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
Questions & Conclusions
View Extraction
Each question is shown with its corresponding conclusion(s). Board questions are expanded by default.
Decisions & Arguments
View Extraction
Causal-Normative Links 6
Fulfills
  • Engineer A AV Further Study Recommendation Before Deployment Obligation
  • Engineer A BER 96-4 Additional Testing Recommendation Obligation
  • New Draft Standard Awareness Additional Testing Recommendation Obligation
  • Autonomous Vehicle Further Study Recommendation Before Deployment Obligation
  • Engineer A AV Further Study Recommendation Before Deployment Obligation
Violates None
Fulfills
  • Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation
  • Engineer A Autonomous Vehicle Risk Assessment Active Participation Obligation
  • Autonomous Vehicle Risk Assessment Active Participation and Concern Expression Obligation
Violates None
Fulfills
  • Engineer A AV Further Study Recommendation Before Deployment Obligation
  • Engineer A Autonomous Vehicle Further Study Recommendation Obligation
  • Autonomous Vehicle Further Study Recommendation Before Deployment Obligation
  • Engineer A AV Faithful Agent Informed Decision Enablement Obligation
  • Engineer A Autonomous Vehicle Do No Harm Obligation
  • Autonomous Vehicle Third-Party Harm Minimization Safety Consideration Obligation
  • Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation
  • Engineer A Autonomous Vehicle Risk Assessment Active Participation Obligation
  • Autonomous Vehicle Risk Assessment Active Participation and Concern Expression Obligation
  • Technical Recommendation Business Pressure Non-Subordination Obligation
Violates None
Fulfills
  • Engineer A BER 96-4 Technical Report Preparation Obligation
  • Autonomous Vehicle Harm Minimization Algorithm Completeness Disclosure Obligation
  • Autonomous Vehicle Moral Framework Public Transparency Disclosure Obligation
  • Engineer A AV Moral Framework Public Transparency Recommendation Obligation
  • Engineer A AV Faithful Agent Informed Decision Enablement Obligation
  • Safety-Critical Software Informed Employer Decision Enablement Obligation
Violates None
Fulfills
  • Autonomous Vehicle Risk Assessment Active Participation and Concern Expression Obligation
  • Engineer A Autonomous Vehicle Risk Assessment Active Participation Obligation
  • Engineer A AV Risk Assessment Third-Party Safety Consideration Obligation
  • Autonomous Vehicle Third-Party Harm Minimization Safety Consideration Obligation
  • Engineer A Autonomous Vehicle Do No Harm Obligation
  • Engineer A BER 96-4 Public Welfare Paramount Safety-Critical Software Obligation
Violates None
Fulfills
  • Engineer A AV Further Study Recommendation Before Deployment Obligation
  • Autonomous Vehicle Further Study Recommendation Before Deployment Obligation
  • Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation
  • Technical Recommendation Business Pressure Non-Subordination Obligation
  • Engineer A BER 96-4 Business Pressure Non-Subordination Obligation
Violates None
Decision Points 6

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:
Formally Document Concerns, Recommend Further Study Board's choice 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.
Complete Evaluation Without Escalating Concerns 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.
Flag Concerns Verbally, Defer Written Escalation 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.
Toulmin Summary:
Warrants I.1 II.1 II.1.b III.1.b

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.

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:
Disclose Ethical Framework Publicly in Report Board's choice 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.
Present Both Frameworks Without Endorsing Either 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.
Disclose Framework Internally, Recommend Ethics Review 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.
Toulmin Summary:
Warrants II.2 II.3 III.2.b

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.

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:
Formally Notify Manufacturer of Fatal Risk Board's choice 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.
Document Disagreement, Treat Escalation as Complete 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.
Recommend Independent Ethics Review Before Deployment 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.
Toulmin Summary:
Warrants I.1 II.1.b II.1.c III.1.b

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.

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:
Actively Advocate Harm-Minimization in Writing Board's choice 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.
Present Options and Defer to Team 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.
Accept Passenger-Priority as Legitimate Policy 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.
Toulmin Summary:
Warrants I.1 II.1 II.1.b

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.

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:
Disclose Utilitarian Basis to Manufacturer Fully Board's choice 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.
Disclose Internally, Limit Consumer Transparency 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.
Frame as Professional Judgment, Omit Label 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.
Toulmin Summary:
Warrants II.2 II.3 III.1.b

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.

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:
Decline to Certify Passenger-Priority System Board's choice 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.
Document Concern, Continue Technical Participation 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.
Withdraw Silently Without Formal Documentation 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.
Toulmin Summary:
Warrants I.1 II.1.b II.1.c III.1.b

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.

12 sequenced 6 actions 7 events
Action (volitional) Event (occurrence) Associated decision points
DP3
Engineer A's residual obligations when the automobile manufacturer overrides the...
Formally Notify Manufacturer of Fatal Ri... Document Disagreement, Treat Escalation ... Recommend Independent Ethics Review Befo...
Full argument
DP4
Engineer A's core obligation to recommend harm minimization for the least number...
Actively Advocate Harm-Minimization in W... Present Options and Defer to Team Accept Passenger-Priority as Legitimate ...
Full argument
DP6
Engineer A's residual obligations when the automobile manufacturer overrides the...
Decline to Certify Passenger-Priority Sy... Document Concern, Continue Technical Par... Withdraw Silently Without Formal Documen...
Full argument
DP2
Engineer A's obligation to disclose to the automobile manufacturer that the harm...
Disclose Ethical Framework Publicly in R... Present Both Frameworks Without Endorsin... Disclose Framework Internally, Recommend...
Full argument
DP5
Engineer A's obligation to disclose to the automobile manufacturer that the harm...
Disclose Utilitarian Basis to Manufactur... Disclose Internally, Limit Consumer Tran... Frame as Professional Judgment, Omit Lab...
Full argument
3 Safety-Critical Software Identified Circa 1996, early in BER Case 96-4 timeline, prior to Engineer A's recommendation
4 Draft Safety Standards Emerge Circa 1996, concurrent with BER Case 96-4 development phase
5 Financial Pressure on Testing Circa 1996, during BER Case 96-4, prior to Engineer A's recommendation
DP1
Engineer A's core obligation to actively participate in the risk assessment team...
Formally Document Concerns, Recommend Fu... Complete Evaluation Without Escalating C... Flag Concerns Verbally, Defer Written Es...
Full argument
7 Explore Additional Technical Mitigation Options Present case, during risk assessment team deliberations, pre-development phase
8 Propose Further Study Before Deployment Present case, prospective: to be undertaken if risk assessment reveals unresolved safety concerns, pre-deployment phase
9 Autonomous Vehicle AV OS Development Initiated Present case, early development/assessment phase
10 Unavoidable Crash Scenario Identified Present case, during risk assessment phase, prior to deployment
11 Precedent Case Principles Activated Present case, at the point when Engineer A's role in AV risk assessment begins
12 Algorithmic Ethics Gap Recognized Present case, during risk assessment phase
Causal Flow
  • Recommend Additional Safety Testing Prepare Transparent Technical Report
  • Prepare Transparent Technical Report Actively Participate in Risk Assessment
  • Actively Participate in Risk Assessment Unambiguously Express Safety Concerns
  • Unambiguously Express Safety Concerns Explore Additional Technical Mitigation Options
  • Explore Additional Technical Mitigation Options Propose Further Study Before Deployment
  • Propose Further Study Before Deployment Safety-Critical_Software_Identified
Opening Context
View Extraction

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.

From the perspective of Engineer A Autonomous Vehicle Risk Assessment Team Engineer
Characters (5)
protagonist

A professional engineer who designed and tested specialized software for public-safety-critical facilities and was placed in the ethically precarious position of recommending whether costly additional testing was necessary to meet emerging safety standards.

Motivations:
  • To provide an honest, technically grounded recommendation that upholds public safety and professional integrity, even when doing so conflicts with the financial interests of the employing software company and its clients.
  • To bring a commercially viable and legally defensible autonomous vehicle to market while managing reputational, regulatory, and liability risks associated with algorithmic decisions that directly determine human harm outcomes.
  • To fulfill paramount public safety obligations by ensuring that algorithmic crash outcome logic is rigorously evaluated, transparently documented, and does not unjustly prioritize passenger safety over vulnerable third-party road users.
stakeholder

The automobile manufacturer retains Engineer A as a consultant and has assembled an engineering risk assessment team to evaluate scenarios for a driverless/autonomous vehicle operating system under development, including crash outcome decision logic with direct public safety implications for third parties.

protagonist

Designed specialized software for public-safety-critical facilities, conducted extensive testing, became aware of new draft standards the software might not meet, and was asked by the company to recommend whether additional costly testing was required.

stakeholder

A software development firm that employs Engineer A to produce safety-critical systems and faces competing pressures between client satisfaction and cost containment on one side, and genuine software safety assurance on the other.

Motivations:
  • To protect the company's financial position and client relationships while avoiding the legal, ethical, and reputational consequences of deploying software that fails to meet evolving public-safety standards.
stakeholder

The automobile manufacturer in the present case that employs or retains Engineer A as part of an engineering risk management team to evaluate the autonomous vehicle operating system, bearing authority over deployment decisions and subject to Engineer A's paramount public safety obligations.

Ethical Tensions (9)

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

Obligation Vs Constraint
Affects: Engineer A Autonomous Vehicle Risk Assessment Team Engineer
Moral Intensity (Jones 1991):
Magnitude: high Probability: high near-term direct diffuse

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

Obligation Vs Constraint
Affects: Engineer A 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

Obligation Vs Constraint
Affects: Engineer A Autonomous Vehicle Risk Assessment Team Engineer

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

Obligation Vs Constraint
Affects: Engineer
Moral Intensity (Jones 1991):
Magnitude: high Probability: high near-term direct diffuse

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

Obligation Vs Constraint
Affects: Engineer A Autonomous Vehicle Risk Assessment Team Engineer

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

Obligation Vs Constraint
Affects: Engineer A Autonomous Vehicle Risk Assessment Team Engineer

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.

Obligation Vs Constraint
Affects: Engineer A Autonomous Vehicle Risk Assessment Team Engineer Automobile Manufacturer Autonomous Vehicle Developer Client Automobile Manufacturer Autonomous Vehicle Developer
Moral Intensity (Jones 1991):
Magnitude: high Probability: high near-term direct diffuse

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.

Obligation Vs Constraint
Affects: Engineer A Autonomous Vehicle Risk Assessment Team Engineer Automobile Manufacturer Autonomous Vehicle Developer Automobile Manufacturer Autonomous Vehicle Developer Client
Moral Intensity (Jones 1991):
Magnitude: high Probability: medium near-term indirect diffuse

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.

Obligation Vs Obligation
Affects: Engineer A Autonomous Vehicle Risk Assessment Team Engineer Engineer A Safety-Critical Software Design Engineer (Case 96-4) Automobile Manufacturer Autonomous Vehicle Developer Client Software Company Employer
Moral Intensity (Jones 1991):
Magnitude: high Probability: high immediate direct concentrated
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
Key Takeaways
  • 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.