Step 4: Full View
Entities, provisions, decisions, and narrative
Full Entity Graph
Loading...Entity Types
Synthesis Reasoning Flow
Shows how NSPE provisions inform questions and conclusions - the board's reasoning chainThe 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.
Provisions (5)
View Extraction-
Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation
Holding paramount public safety directly requires active participation in harm minimization evaluation.
-
Engineer A AV Risk Assessment Third-Party Safety Consideration Obligation
Holding paramount public safety requires explicitly identifying and assessing third-party safety risks.
-
Engineer A AV Further Study Recommendation Before Deployment Obligation
Holding paramount public safety requires recommending further study before deploying potentially unsafe AV technology.
-
Engineer A Autonomous Vehicle Do No Harm Obligation
The paramount safety provision directly underpins the obligation to strive to do no harm.
-
Engineer A BER 96-4 Public Welfare Paramount Safety-Critical Software Obligation
This obligation explicitly mirrors the paramount safety provision in the context of safety-critical software testing.
-
Recommend Additional Safety Testing
Holding public safety paramount directly governs recommending further safety testing before deployment.
-
Actively Participate in Risk Assessment
Paramount duty to public safety requires active engagement in identifying and assessing risks.
-
Unambiguously Express Safety Concerns
Holding public safety paramount obligates engineers to clearly voice safety concerns.
-
Propose Further Study Before Deployment
Prioritizing public welfare governs proposing additional study to ensure safe deployment.
-
Engineer A Ethical Dilemma, Harm Allocation Recommendation
Engineer A's obligation to hold public safety paramount directly shapes the ethical dilemma of choosing between harm-allocating algorithms.
-
Present Case Client-Interest vs Third-Party Safety Algorithmic Pre-Commitment
Holding public safety paramount requires Engineer A to weigh third-party safety against client commercial interests in algorithm design.
-
Public Safety at Risk. Autonomous Vehicle Third-Party Harm
The provision directly addresses the risk of fatal or serious injury to pedestrians and cyclists from algorithm design choices.
-
Competing Duties. Passenger Safety vs. Aggregate Harm Minimization
The paramount duty to public safety is the governing principle in resolving Engineer A's competing professional duties.
-
Present Case Autonomous Vehicle Do No Harm Design Obligation
The do no harm design obligation is a direct expression of the paramount duty to hold public safety above all other considerations.
-
Present Case Autonomous System Harm Allocation Design
Designing harm-allocation decision logic must be governed by the paramount obligation to protect public safety.
-
BER Case 96-4 Public Safety at Risk from Safety-Critical Software
The risk to the public from deploying safety-critical software not meeting forthcoming standards directly implicates the paramount safety duty.
-
Engineer A AV Harm Allocation Moral Framework Non-Deception Public Disclosure Constraint
Holding public safety paramount requires not deploying an AV with an undisclosed moral framework that could harm the public.
-
Engineer A AV Good Faith Safety Concern Objective Testimony Constraint
Paramount public safety obligation requires Engineer A to disclose safety concerns in good faith even absent established standards.
-
Engineer A AV Do No Harm Design Obligation Safety Constraint
The do no harm design obligation directly flows from the paramount duty to protect public safety and welfare.
-
Engineer A BER 96-4 Public Safety Paramount Safety-Critical Software Constraint
This constraint explicitly invokes the paramount public safety obligation over business considerations in safety-critical software.
-
Engineer A AV Regulatory Standards Vacuum Heightened Disclosure Constraint
Absence of standards heightens rather than diminishes the paramount duty to protect the public from AV harm-allocation risks.
-
Engineer A AV Passenger Priority Algorithm Third-Party Fatal Harm Non-Subordination Constraint
Holding public safety paramount prohibits algorithms that categorically sacrifice third-party lives, as the public includes non-passengers.
-
Engineer A AV Further Study Before Deployment Constraint
Paramount public safety requires recommending further study before deploying an AV system with unresolved safety concerns.
-
Engineer A AV Client Interest Third-Party Safety Priority Constraint
The paramount public safety duty establishes that third-party safety takes priority over client commercial interests.
-
Engineer A AV Do No Harm Deployment Constraint
The do no harm deployment constraint is a direct expression of the paramount obligation to protect public safety before deployment.
-
Engineer A AV Risk Mitigation Option Exploration Constraint
Paramount public safety requires exhausting all risk mitigation options before recommending deployment of a potentially harmful AV system.
-
Engineer A AV Active Participation Concern Expression Constraint
Holding public safety paramount obligates active rather than passive participation in safety processes affecting the public.
-
Engineer A AV Further Study Recommendation Constraint
Paramount public safety duty requires Engineer A to vocalize the need for further study when safety concerns remain unresolved.
-
Public Welfare Paramount Invoked in Autonomous Vehicle Crash Algorithm Design
I.1 directly embodies the paramount public welfare obligation that governs the crash algorithm design decision.
-
Public Welfare Paramount Invoked in Autonomous Vehicle Risk Assessment
I.1 is the foundational provision that establishes Engineer A's overriding responsibility to hold public safety paramount in the risk assessment.
-
Third-Party Non-Client Welfare Consideration Invoked in Autonomous Vehicle Design
I.1 requires holding paramount the welfare of all members of the public, including third parties such as pedestrians and cyclists.
-
Third-Party Non-Client Welfare Consideration Invoked in Autonomous Vehicle Case
I.1 extends the paramount safety obligation to pedestrians and bystanders who are not clients or passengers.
-
Do No Harm Obligation Invoked by Engineer A in Autonomous Vehicle Case
I.1 grounds the do no harm obligation by requiring engineers to prioritize public safety before deployment.
-
Competing Public Goods Balancing Invoked in Passenger vs. Third-Party Safety Trade-Off
I.1 requires balancing competing public goods since both passenger and third-party safety fall under the paramount public welfare mandate.
-
Algorithmic Harm Distribution Ethics Invoked in Autonomous Vehicle Case
I.1 requires that the distribution of harm embedded in the algorithm be evaluated against the standard of paramount public welfare.
-
Engineer A Autonomous Vehicle Risk Assessment Team Engineer
Engineer A must hold paramount public safety when evaluating autonomous vehicle risk scenarios for the manufacturer.
-
Engineer A Safety-Critical Software Design Engineer (Case 96-4)
Engineer A must hold paramount public safety when designing software for public-safety-critical facilities.
-
Safety-Critical Software Identified
Identifying safety-critical software directly invokes the paramount duty to protect public safety.
-
Unavoidable Crash Scenario Identified
An unavoidable crash scenario directly threatens public safety and welfare, triggering the paramount obligation.
-
Algorithmic Ethics Gap Recognized
A gap in algorithmic ethics in an AV system poses a direct risk to public health and safety.
-
Financial Pressure on Testing
Allowing financial pressure to compromise testing undermines the paramount duty to protect public safety.
-
NSPE Code of Ethics
I.1 is a foundational canon of the NSPE Code of Ethics directly governing Engineer A's paramount obligation to public safety.
-
Qualitative Risk Assessment Methodology for Autonomous Vehicle Crash Scenarios
Holding public safety paramount requires Engineer A to apply rigorous risk assessment methodology to identify potential harms to passengers and pedestrians.
-
Autonomous Vehicle Operating System Safety Standard
Holding public safety paramount requires adherence to safety standards governing autonomous vehicle operating systems.
-
Draft_AV_Safety_Testing_Standard
The emerging draft standard represents the current threshold for public safety protection that Engineer A must consider when holding safety paramount.
-
Engineer A AV Public Transparency Advocacy Capability
Holding public safety paramount requires transparency about moral frameworks encoded in AV algorithms that affect public welfare.
-
Engineer A AV Third-Party Harm Weighting Capability
Holding public safety paramount directly requires assessing and weighing the welfare interests of third parties such as pedestrians and cyclists.
-
Engineer A AV Crash Scenario Technical Safety Analysis Capability
Holding public safety paramount requires technical analysis of unavoidable crash scenarios to protect the public from harm.
-
Engineer A AV Harm Minimization Risk Management Participation
Active participation in risk assessment is a direct expression of holding public safety paramount in AV development.
-
Engineer A Autonomous Vehicle Do No Harm Novel Technology Application Capability
The do-no-harm principle is a direct operationalization of holding public safety and welfare paramount.
-
Engineer A AV Risk Assessment Active Participation Capability
Fully participating in risk management to clearly articulate safety concerns is required by the obligation to hold public safety paramount.
-
Engineer A Public Welfare Paramountcy Safety-Critical Software Capability
Recognizing the enormous public impact of safety-critical software industries directly reflects the requirement to hold public welfare paramount.
-
Engineer A Regulatory Gap Safety Escalation Software Standards Capability
Recognizing that a regulatory gap heightens safety obligations is a direct application of holding public safety paramount.
-
Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation
Holding paramount public safety, health, and welfare requires full participation in harm minimization assessments.
-
Engineer A AV Risk Assessment Third-Party Safety Consideration Obligation
Holding paramount public welfare requires explicitly considering third-party safety impacts in risk assessments.
-
Engineer A AV Further Study Recommendation Before Deployment Obligation
Holding paramount public safety requires recommending further study before AV deployment if risks remain unresolved.
-
Engineer A Autonomous Vehicle Do No Harm Obligation
The obligation to hold public welfare paramount directly supports the duty to strive to do no harm.
-
Engineer A BER 96-4 Public Welfare Paramount Safety-Critical Software Obligation
This obligation is a direct application of the paramount public welfare provision to safety-critical software decisions.
-
Recommend Additional Safety Testing
The duty to hold public safety paramount governs recommending additional testing to mitigate risks.
-
Actively Participate in Risk Assessment
Engineers must hold public safety paramount, which requires active participation in risk assessment processes.
-
Unambiguously Express Safety Concerns
This provision obligates engineers to clearly express safety concerns to protect the public.
-
Propose Further Study Before Deployment
Holding public welfare paramount governs proposing further study before a potentially unsafe deployment.
-
Engineer A Ethical Dilemma, Harm Allocation Recommendation
The professional duty to hold public safety paramount is the central ethical obligation framing Engineer A's dilemma.
-
Present Case Client-Interest vs Third-Party Safety Algorithmic Pre-Commitment
This provision requires Engineer A to prioritize third-party safety over the client's preference for passenger-protective algorithms.
-
Autonomous Vehicle Harm Allocation Design Assignment
Engineer A's assignment to evaluate harm-allocation logic must be conducted under the overriding duty to protect public safety.
-
Public Safety at Risk. Autonomous Vehicle Third-Party Harm
The provision directly governs Engineer A's response to the identified risk of harm to pedestrians and cyclists.
-
Competing Duties. Passenger Safety vs. Aggregate Harm Minimization
This provision establishes that public welfare is paramount and must take precedence when Engineer A's duties conflict.
-
Present Case Autonomous Vehicle Do No Harm Design Obligation
The do no harm obligation is a direct application of the duty to hold public safety paramount in system design.
-
Present Case Autonomous System Harm Allocation Design
The design of autonomous harm-allocation logic must conform to the overriding professional duty to protect public safety.
-
BER Case 96-4 Public Safety at Risk from Safety-Critical Software
Deployment of safety-critical software posing public risk directly triggers the paramount duty under this provision.
-
Engineer A AV Harm Allocation Moral Framework Non-Deception Public Disclosure Constraint
Paramount public safety obligation requires disclosure of embedded moral frameworks that could affect public welfare in AV deployment.
-
Engineer A AV Good Faith Safety Concern Objective Testimony Constraint
The duty to hold public safety paramount requires objective good-faith testimony about safety concerns regardless of regulatory gaps.
-
Engineer A AV Do No Harm Design Obligation Safety Constraint
The paramount safety obligation underpins the do no harm design requirement for autonomous vehicle systems.
-
Engineer A BER 96-4 Public Safety Paramount Safety-Critical Software Constraint
This constraint directly references the paramount public safety obligation as overriding business pressures in safety-critical software decisions.
-
Engineer A AV Regulatory Standards Vacuum Heightened Disclosure Constraint
The paramount safety duty is heightened, not diminished, when regulatory standards are absent for AV harm-allocation logic.
-
Engineer A AV Passenger Priority Algorithm Third-Party Fatal Harm Non-Subordination Constraint
Paramount public safety encompasses third parties, prohibiting algorithms that categorically subordinate their lives to passengers.
-
Engineer A AV Further Study Before Deployment Constraint
The paramount safety obligation requires recommending further study before deploying an AV system with unresolved harm-allocation concerns.
-
Engineer A AV Client Interest Third-Party Safety Priority Constraint
Paramount public safety establishes that third-party safety supersedes client commercial interests when they conflict.
-
Engineer A AV Do No Harm Deployment Constraint
The do no harm deployment constraint is grounded in the paramount duty not to expose the public to preventable AV-related harm.
-
Engineer A AV Risk Mitigation Option Exploration Constraint
Paramount public safety requires exploring all risk mitigation options before recommending deployment of a potentially unsafe AV system.
-
Engineer A AV Active Participation Concern Expression Constraint
The paramount safety duty requires active expression of safety concerns rather than passive silence in risk management processes.
-
Engineer A AV Further Study Recommendation Constraint
Paramount public safety obligates Engineer A to recommend further study when unresolved safety concerns exist about the AV system.
-
Public Welfare Paramount Invoked in Autonomous Vehicle Crash Algorithm Design
II.1 reiterates the paramount public safety obligation directly applicable to the crash algorithm design evaluation.
-
Public Welfare Paramount Invoked in Autonomous Vehicle Risk Assessment
II.1 is the operative code provision establishing Engineer A's overriding ethical responsibility in the risk assessment context.
-
Third-Party Non-Client Welfare Consideration Invoked in Autonomous Vehicle Design
II.1 mandates holding paramount the welfare of the public, which explicitly includes third parties beyond the client relationship.
-
Third-Party Non-Client Welfare Consideration Invoked in Autonomous Vehicle Case
II.1 extends the paramount safety duty to all members of the public including pedestrians and bystanders.
-
Do No Harm Obligation Invoked by Engineer A in Autonomous Vehicle Case
II.1 supports the do no harm obligation by requiring engineers to prioritize public safety before system deployment.
-
Competing Public Goods Balancing Invoked in Passenger vs. Third-Party Safety Trade-Off
II.1 requires that both passenger and third-party welfare be weighed under the paramount public safety standard.
-
Algorithmic Harm Distribution Ethics Invoked in Autonomous Vehicle Case
II.1 requires that harm distribution decisions in the algorithm be evaluated against the paramount public welfare obligation.
-
Active Risk Assessment Team Participation Obligation Invoked by Engineer A
II.1 requires Engineer A to actively participate and clearly express views to ensure public safety is held paramount within the team.
-
Engineer A Autonomous Vehicle Risk Assessment Team Engineer
Engineer A is professionally obligated to prioritize public safety, health, and welfare in the autonomous vehicle risk assessment.
-
Engineer A Safety-Critical Software Design Engineer (Case 96-4)
Engineer A must hold paramount public safety when aware that safety-critical software may not conform to new draft standards.
-
Safety-Critical Software Identified
Engineers must hold public safety paramount when safety-critical software issues are discovered in AV development.
-
Unavoidable Crash Scenario Identified
Engineers are obligated to prioritize public welfare when a crash scenario with potential harm is identified.
-
Algorithmic Ethics Gap Recognized
Recognizing an ethics gap in AV algorithms requires engineers to uphold public safety above other interests.
-
Financial Pressure on Testing
Engineers must hold public safety paramount even when facing financial pressure to reduce testing rigor.
-
NSPE Code of Ethics
II.1 is a direct provision of the NSPE Code of Ethics establishing Engineer A's core professional obligation to public safety.
-
ISO 26262 Automotive Functional Safety Standard
Holding public safety paramount in automotive engineering requires conformance with ISO 26262 as the governing functional safety standard.
-
Qualitative Risk Assessment Methodology for Autonomous Vehicle Crash Scenarios
Engineer A's obligation to hold public safety paramount necessitates use of structured risk assessment methodology to evaluate crash scenarios.
-
Consumer Product Safety Testing Standard for Autonomous Vehicles
Holding public safety paramount requires Engineer A to consider applicable consumer product safety testing standards before market release.
-
BER_Case_96-4
This precedent case establishes the principle that holding safety paramount obligates engineers to recommend additional testing when safety standards may not be met.
-
Engineer A AV Public Transparency Advocacy Capability
Engineers must hold public welfare paramount, which includes advocating transparency about AV harm minimization algorithms affecting the public.
-
Engineer A AV Third-Party Harm Weighting Capability
Holding public welfare paramount requires explicitly identifying and assessing harm to third parties who are members of the public.
-
Engineer A AV Crash Scenario Technical Safety Analysis Capability
Engineers must hold public safety paramount, requiring rigorous technical analysis of crash scenarios that could harm the public.
-
Engineer A AV Harm Minimization Risk Management Participation
Full participation in risk management directly fulfills the engineer's duty to hold public safety paramount.
-
Engineer A Autonomous Vehicle Do No Harm Novel Technology Application Capability
Applying the do-no-harm principle to AV systems is a direct expression of the duty to hold public welfare paramount.
-
Engineer A AV Risk Assessment Active Participation Capability
Active and clear participation in risk assessment is required to fulfill the duty to hold public safety paramount.
-
Engineer A Public Welfare Paramountcy Safety-Critical Software Capability
Recognizing the public impact of safety-critical software is directly tied to the duty to hold public welfare paramount.
-
Engineer A Regulatory Gap Safety Escalation Software Standards Capability
Escalating safety concerns when regulatory standards are absent reflects the duty to hold public safety paramount.
-
Engineer A BER 96-4 Technical Report Preparation Obligation
Approving only conforming engineering documents relates directly to the obligation to prepare a technically sound report referencing applicable testing standards.
-
Engineer A AV Faithful Agent Informed Decision Enablement Obligation
Ensuring engineering documents conform to applicable standards supports providing the manufacturer with diligent and complete information for informed decisions.
-
Prepare Transparent Technical Report
Engineers must approve only documents conforming to applicable standards, governing the preparation of accurate and transparent technical reports.
-
Recommend Additional Safety Testing
Approving only conforming engineering documents governs recommending testing to ensure standards compliance.
-
Autonomous Vehicle Ethics Regulatory Standards Vacuum
The absence of applicable standards creates a direct challenge to Engineer A's obligation to approve only conforming engineering documents.
-
Present Case Regulatory Standards Vacuum for Autonomous Vehicle Ethics
The lack of established national or industry standards means Engineer A cannot confirm conformity with applicable standards for harm-allocation logic.
-
BER Case 96-4 Emerging Software Standard Pre-Adoption Gap
Engineer A's awareness of forthcoming but not yet adopted standards raises the question of which standards engineering documents must conform to.
-
BER Case 96-4 Completed Safety Testing with Residual Concern
Passing existing standards while forthcoming standards remain unadopted creates ambiguity about whether engineering documents are fully conforming.
-
Engineer A AV Harm Allocation Algorithm Completeness Disclosure Constraint
Approving only conforming engineering documents requires that the harm-allocation algorithm recommendation be complete and fully disclosed to the risk assessment team.
-
Engineer A BER 96-4 Emerging Standard Technical Report Disclosure Constraint
The obligation to conform to applicable standards requires disclosing newly reported draft testing standards that the AV system may not meet.
-
Engineer A AV Regulatory Standards Vacuum Heightened Disclosure Constraint
The absence of applicable standards creates a heightened disclosure obligation rather than permitting approval of documents without conformity review.
-
Engineer A AV Good Faith Safety Concern Objective Testimony Constraint
Approving only conforming engineering documents requires objective disclosure of safety concerns when no applicable standards exist to confirm conformity.
-
Engineer A AV Do No Harm Design Obligation Safety Constraint
The requirement to approve only conforming documents supports the do no harm design obligation by preventing approval of non-conforming harm-allocation designs.
-
Regulatory Gap Safety Escalation Obligation Invoked in Software Testing Case
II.1.b requires conformity with applicable standards, directly grounding the obligation to escalate when new draft standards may not be met.
-
Do No Harm Obligation Invoked by Engineer A in Software Testing Case
II.1.b supports the do no harm obligation by prohibiting approval of documents that do not conform to applicable standards.
-
Good Faith Safety Concern Threshold Invoked in Software Testing Case
II.1.b establishes that awareness of potential non-conformity with standards is sufficient to trigger an obligation to act.
-
Autonomous System Moral Framework Transparency Obligation Invoked in AV Design
II.1.b requires that engineering documents and designs conform to applicable standards, supporting transparency about the moral framework embedded in the system.
-
Engineer A Autonomous Vehicle Risk Assessment Team Engineer
Engineer A should only approve engineering documents for the autonomous vehicle that conform to applicable standards.
-
Engineer A Safety-Critical Software Design Engineer (Case 96-4)
Engineer A must ensure the safety-critical software design conforms to applicable standards including newly emerging draft standards.
-
Draft Safety Standards Emerge
Engineers should only approve engineering documents and designs that conform to the emerging applicable safety standards.
-
Safety-Critical Software Identified
Engineers must ensure safety-critical software documentation conforms to applicable standards before approval.
-
Autonomous Vehicle AV OS Development Initiated
The initiation of AV OS development requires that all engineering documents conform to applicable standards.
-
ISO 26262 Automotive Functional Safety Standard
II.1.b requires approval only of documents conforming to applicable standards, directly implicating ISO 26262 as the governing automotive safety standard.
-
Autonomous Vehicle Operating System Safety Standard
Engineer A may only approve engineering documents if the autonomous vehicle operating system conforms to applicable safety standards.
-
Consumer Product Safety Testing Standard for Autonomous Vehicles
Engineering documents must conform to applicable consumer product safety testing standards before Engineer A can approve them.
-
Draft_AV_Safety_Testing_Standard
The draft standard represents an applicable standard that engineering documents must conform to, triggering Engineer A's obligation under II.1.b.
-
Software_Safety_Testing_Standard_BER96-4_Context
The existence of a new draft standard that existing software may not meet directly triggers the conformity requirement under II.1.b.
-
Engineer A AV Crash Scenario Technical Safety Analysis Capability
Approving only conforming engineering documents requires technical analysis of crash scenarios against applicable safety standards.
-
Engineer A Safety-Critical Software Informed Employer Decision Enablement Capability
Preparing a technical report referencing draft testing protocols directly relates to approving documents in conformity with applicable standards.
-
Engineer A Regulatory Gap Safety Escalation Software Standards Capability
Recognizing that a new draft testing standard exists and affects approval obligations directly relates to conformity with applicable standards.
-
Engineer A Cross-Case Analogical Transfer BER 96-4 to AV Case Capability
Applying established ethical principles from prior cases to AV software standards supports the requirement to conform engineering documents to applicable standards.
-
Engineer A Public Welfare Paramountcy Safety-Critical Software Capability
Recognizing industry-specific safety standards for safety-critical software is relevant to the obligation to approve only conforming engineering documents.
-
Engineer A Autonomous Vehicle Risk Assessment Active Participation Obligation
Expressing technical opinions founded on knowledge and competence supports the obligation to clearly articulate concerns during risk management participation.
-
Engineer A AV Moral Framework Public Transparency Recommendation Obligation
Publicly expressing technically founded opinions relates to recommending transparency about the AV moral framework to the public.
-
Engineer A BER 96-4 Technical Report Preparation Obligation
Expressing technically founded opinions supports the obligation to prepare a report grounded in current testing analysis and results.
-
Prepare Transparent Technical Report
Expressing technical opinions publicly must be founded on facts and competence, directly governing transparent technical reporting.
-
Unambiguously Express Safety Concerns
This provision governs public expression of safety concerns, requiring they be grounded in knowledge and competence.
-
Engineer A Ethical Dilemma, Harm Allocation Recommendation
Engineer A's recommendation must be grounded in factual knowledge and subject-matter competence, as required by this provision.
-
Present Case Client-Interest vs Third-Party Safety Algorithmic Pre-Commitment
Engineer A's public or professional expression of a technical opinion on algorithm design must be founded on competence and facts.
-
Autonomous Vehicle Harm Allocation Design Assignment
Engineer A's evaluation and recommendation on harm-allocation logic constitutes a technical opinion requiring competence and factual grounding.
-
BER Case 96-4 Multi-Factor Business-Safety Balancing
Formulating a technical recommendation amid financial pressures must still be grounded in competence and knowledge of the facts.
-
Engineer A AV Good Faith Safety Concern Objective Testimony Constraint
Expressing technical opinions founded on knowledge and competence directly supports the obligation to provide objective good-faith testimony about AV safety concerns.
-
Engineer A AV Harm Allocation Moral Framework Non-Deception Public Disclosure Constraint
The provision permits Engineer A to publicly express technically grounded opinions about the undisclosed moral framework embedded in the AV system.
-
Engineer A BER 96-4 Emerging Standard Technical Report Disclosure Constraint
Expressing competence-based technical opinions supports the obligation to disclose newly reported draft standards relevant to the AV system.
-
Engineer A AV Regulatory Standards Vacuum Escalation Permissibility Constraint
The provision supports Engineer A's permissibility to escalate concerns publicly when no regulatory standards exist and internal processes are insufficient.
-
Engineer A AV Active Participation Concern Expression Constraint
The provision grounds the obligation to actively express safety concerns by requiring that such expressions be founded on knowledge and competence.
-
Engineer A AV Further Study Recommendation Constraint
Expressing technically founded opinions supports the obligation to recommend further study when competence-based assessment identifies unresolved safety concerns.
-
Completeness and Non-Selectivity in Advisory Opinions Invoked by Engineer A Risk Assessment Team
II.3.b requires that publicly expressed technical opinions be founded on knowledge and competence, supporting the obligation to present both frameworks completely and objectively.
-
Professional Competence in Risk Assessment Invoked for Autonomous Vehicle Scenario
II.3.b requires that technical opinions be grounded in competence in the subject matter, directly applicable to the risk assessment team's specialized analysis.
-
Informed Decision-Making Enablement Obligation Invoked for Automobile Manufacturer Client
II.3.b supports the obligation to provide technically founded opinions that enable the manufacturer to make an informed decision.
-
Informed Decision-Making Enablement Obligation Invoked in Software Testing Case
II.3.b supports Engineer A's obligation to prepare a technically grounded report enabling informed decision-making by the employer.
-
Technical Recommendation Independence from Business Considerations Invoked in Software Testing Case
II.3.b requires that technical opinions be founded on knowledge and competence, not on financial or business considerations.
-
Autonomous System Moral Framework Transparency Obligation Invoked in AV Design
II.3.b supports the obligation to transparently communicate the moral framework embedded in the system based on competence and factual knowledge.
-
Engineer A Autonomous Vehicle Risk Assessment Team Engineer
Engineer A may publicly express technical opinions on autonomous vehicle risks based on their knowledge and competence from the risk assessment work.
-
Engineer A Safety-Critical Software Design Engineer (Case 96-4)
Engineer A may publicly express technical opinions on software safety standards based on their expertise and testing experience.
-
Unavoidable Crash Scenario Identified
Engineers may publicly express technical opinions about unavoidable crash scenarios based on their factual knowledge and competence.
-
Algorithmic Ethics Gap Recognized
Engineers with competence in AV systems may publicly express opinions about identified algorithmic ethics gaps.
-
Draft Safety Standards Emerge
Engineers may publicly comment on emerging draft safety standards when they have relevant knowledge and expertise.
-
Qualitative Risk Assessment Methodology for Autonomous Vehicle Crash Scenarios
Expressing founded technical opinions requires Engineer A to base public statements on competent risk assessment methodology and factual analysis.
-
NSPE_Code_of_Ethics_Sections_III6b_II4a
The Board cited related Code sections requiring Engineer A to prepare a technical report, which supports the competence-based public expression required by II.3.b.
-
Engineer A AV Public Transparency Advocacy Capability
Publicly advocating transparency about AV algorithms constitutes expressing a technical opinion that must be founded on knowledge and competence.
-
Engineer A AV Crash Scenario Technical Safety Analysis Capability
Expressing technical opinions about crash scenarios publicly requires the competence and factual knowledge mandated by this provision.
-
Engineer A AV Ethical Framework Selection Capability
Publicly expressing opinions about the ethical framework encoded in AV systems requires competence in the subject matter as required by this provision.
-
Engineer A AV Further Study Recommendation Capability
Recommending further study publicly on unresolved safety concerns constitutes a technical opinion that must be grounded in knowledge and competence.
-
Engineer A Autonomous Vehicle Further Study Recommendation Obligation
Advising clients when a project will not be successful directly supports the obligation to propose further study when concerns remain unresolved.
-
Engineer A BER 96-4 Additional Testing Recommendation Obligation
Advising the client that additional testing is required aligns with the obligation to recommend further testing and explain why it is needed.
-
Engineer A BER 96-4 Business Pressure Non-Subordination Obligation
Advising clients based on technical findings rather than financial pressures directly supports the obligation not to subordinate recommendations to business pressure.
-
Engineer A AV Faithful Agent Informed Decision Enablement Obligation
Acting as a faithful agent by providing complete information enables the client to make informed decisions, consistent with advising them when a project may not succeed.
-
Unambiguously Express Safety Concerns
Engineers must advise clients when a project will not be successful, governing the unambiguous expression of safety concerns to employers.
-
Explore Additional Technical Mitigation Options
Advising clients of project risks governs exploring mitigation options to address identified deficiencies.
-
Propose Further Study Before Deployment
The duty to advise clients when a project will not be successful governs proposing further study before deployment.
-
Passenger Safety vs. Third-Party Harm Minimization Algorithm Conflict
Engineer A must advise the automobile manufacturer client when the preferred passenger-protective algorithm conflicts with broader safety obligations.
-
Client Relationship. Engineer A and Automobile Manufacturer
The active consulting relationship creates a direct obligation for Engineer A to advise the client when the project direction raises safety concerns.
-
BER Case 96-4 Multi-Factor Business-Safety Balancing
Engineer A's obligation to advise the client about safety concerns applies even when significant financial pressures favor a different course.
-
BER Case 96-4 Completed Safety Testing with Residual Concern
Engineer A's residual concern about forthcoming standards triggers the duty to advise the client that the project may not meet future requirements.
-
Competing Duties. Passenger Safety vs. Aggregate Harm Minimization
When client interests conflict with public safety obligations, Engineer A must advise the client of the concern rather than silently comply.
-
Engineer A AV Informed Employer Decision Enablement Constraint
The duty to advise clients when a project will not be successful requires ensuring the automobile manufacturer has full material safety information to make informed decisions.
-
Engineer A AV Further Study Before Deployment Constraint
Advising the client when a project will not be successful requires recommending further study before deployment when safety concerns remain unresolved.
-
Engineer A AV Further Study Recommendation Constraint
The obligation to advise clients of project concerns directly requires Engineer A to recommend further study rather than remain silent about identified safety issues.
-
Engineer A AV Risk Assessment Active Participation Constraint
Advising the client of project concerns requires full active participation in the risk assessment process to provide complete and accurate counsel.
-
Engineer A AV Harm Allocation Algorithm Completeness Disclosure Constraint
Advising the client when a project will not be successful requires complete disclosure of the harm-allocation algorithm's limitations to enable informed client decisions.
-
Engineer A BER 96-4 Business Pressure Technical Separation Constraint
The duty to advise clients honestly about project success requires separating technical safety assessments from financial pressures when counseling the employer.
-
Engineer A AV Client Interest Third-Party Safety Priority Constraint
Advising the client when a project will not be successful includes informing them when client commercial interests conflict with third-party safety obligations.
-
Engineer A AV Do No Harm Deployment Constraint
The obligation to advise clients of project concerns supports the constraint against recommending deployment without first addressing do no harm requirements.
-
Faithful Agent Obligation Within Ethical Limits Invoked for Engineer A Consultant Role
III.1.b establishes the faithful agent duty to advise clients honestly, which bounds Engineer A's consultant obligation within ethical limits.
-
Informed Decision-Making Enablement Obligation Invoked for Automobile Manufacturer Client
III.1.b directly requires Engineer A to advise the manufacturer client when the project may not be successful, enabling informed decision-making.
-
Graduated Internal Escalation Before External Reporting Invoked in Software Testing Case
III.1.b supports the obligation to first advise the employer internally about project concerns before considering external escalation.
-
Active Risk Assessment Team Participation Obligation Invoked by Engineer A
III.1.b requires Engineer A to clearly advise the client or employer of concerns, supporting the obligation to fully and unambiguously participate in the risk management team.
-
Do No Harm Obligation Invoked by Engineer A in Autonomous Vehicle Case
III.1.b supports the do no harm obligation by requiring Engineer A to advise the manufacturer if the autonomous vehicle system is not ready for safe deployment.
-
Regulatory Gap Safety Escalation Obligation Invoked in Software Testing Case
III.1.b requires advising the client or employer when a project may not succeed, directly applicable when new standards may not be met.
-
Engineer A Autonomous Vehicle Risk Assessment Team Engineer
Engineer A must advise the automobile manufacturer if the autonomous vehicle project or specific scenarios present unacceptable risks or will not be successful.
-
Engineer A Safety-Critical Software Design Engineer (Case 96-4)
Engineer A must advise the software company employer if the software project will not meet safety standards and therefore will not be successful.
-
Financial Pressure on Testing
Engineers must advise employers when financial pressure on testing will likely cause the project to fail or be unsafe.
-
Safety-Critical Software Identified
Engineers should advise clients or employers when identified safety-critical software issues indicate the project will not succeed safely.
-
Unavoidable Crash Scenario Identified
Engineers are obligated to advise employers when an unavoidable crash scenario signals the project cannot succeed as planned.
-
Algorithmic Ethics Gap Recognized
Engineers must advise their employer when a recognized algorithmic ethics gap indicates the AV project will not be successful or safe.
-
Qualitative Risk Assessment Methodology for Autonomous Vehicle Crash Scenarios
Engineer A's obligation to advise the client of project failure risk is grounded in the risk assessment findings that indicate potential safety shortfalls.
-
Draft_AV_Safety_Testing_Standard
The draft standard's requirements that the system may not meet constitute the basis for advising the client that the project may not be successful.
-
BER_Case_96-4
This precedent establishes that engineers must advise clients to conduct additional testing when a new standard may not be met, directly supporting III.1.b.
-
Software_Safety_Testing_Standard_BER96-4_Context
The triggering condition of a new draft standard the software may not meet is precisely the situation requiring Engineer A to advise the client under III.1.b.
-
Engineer A Faithful Agent Informed Decision Enablement Capability
Structuring and presenting professional analysis to the manufacturer directly fulfills the duty to advise clients when a project may not be successful.
-
Engineer A AV Further Study Recommendation Capability
Recommending further study when safety concerns are unresolved is a form of advising the employer that the project may not be successful as currently designed.
-
Engineer A Safety-Critical Software Informed Employer Decision Enablement Capability
Preparing a technical report on testing analysis and results to inform the employer directly fulfills the duty to advise clients about project concerns.
-
Engineer A AV Risk Assessment Active Participation Capability
Clearly articulating unresolved safety concerns within the risk management team constitutes advising the employer that the project may not be successful.
-
Engineer A Regulatory Gap Safety Escalation Software Standards Capability
Advising the employer that a regulatory gap heightens safety obligations is a direct application of the duty to inform clients of potential project failure.
Cross-Case Connections
View ExtractionExplicit 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.
Implicit Similar Cases 10 Similarity Network
Cases sharing ontology classes or structural similarity. These connections arise from constrained extraction against a shared vocabulary.
Questions & Conclusions (1 board)
View ExtractionWhat are Engineer A’s ethical obligations?
Implicit (4)
Does the Board's conclusion that Engineer A must recommend minimizing harm to the least number of persons implicitly adopt a utilitarian ethical framework, and if so, is Engineer A obligated to disclose to the automobile manufacturer that this recommendation reflects a specific moral philosophy rather than a universally accepted engineering standard?
In the absence of applicable regulatory or industry standards governing autonomous vehicle harm-allocation decision logic, does Engineer A have an affirmative obligation to recommend that the automobile manufacturer publicly disclose the ethical framework embedded in the vehicle's operating system to prospective consumers before deployment?
If the automobile manufacturer, after receiving Engineer A's recommendation to minimize aggregate harm, decides to override that recommendation and program the vehicle to prioritize passenger safety above all others, what are Engineer A's remaining ethical obligations - including whether Engineer A must refuse to continue consulting on the project or escalate concerns externally?
Does Engineer A's role as a consultant to the automobile manufacturer - rather than a direct employee - alter the scope or enforceability of his ethical obligations under the NSPE Code, particularly with respect to how far he must press concerns about harm-allocation design before his professional duty is satisfied?
Cross-cutting analytical questions (12)
These questions consider the case as a whole rather than a specific board question above.
Show 12 cross-cutting questionsPrinciple tension (4)
Does the Faithful Agent Obligation Within Ethical Limits - which requires Engineer A to serve the automobile manufacturer's interests - conflict with the Third-Party Non-Client Welfare Consideration, which demands that Engineer A weight the safety of pedestrians, cyclists, and motorcyclists equally or above the client's commercial interest in a passenger-protective algorithm?
Does the Competing Public Goods Balancing principle - which acknowledges legitimate safety interests of vehicle passengers - conflict with the Public Welfare Paramount principle when the algorithm that best protects passengers is the same algorithm most likely to cause fatal harm to third parties, and if so, which principle should govern Engineer A's recommendation?
Does the Autonomous System Moral Framework Transparency Obligation - requiring Engineer A to disclose the ethical assumptions embedded in the harm-allocation algorithm - conflict with the Informed Decision-Making Enablement Obligation owed to the automobile manufacturer client, insofar as full public transparency about the algorithm's moral logic could expose the manufacturer to legal liability or competitive disadvantage that the client has not consented to accept?
Does the Regulatory Gap Safety Escalation Obligation - which in the software testing case required Engineer A to flag the absence of applicable standards as itself a safety concern warranting further study - conflict with the Completeness and Non-Selectivity in Advisory Opinions principle when the regulatory vacuum surrounding autonomous vehicle harm-allocation ethics means that any recommendation Engineer A makes will necessarily be incomplete, potentially leading to selective or premature guidance that could itself cause harm?
Theoretical (4)
From a deontological perspective, does Engineer A have an absolute duty to recommend harm minimization for third parties regardless of the automobile manufacturer's commercial interests, and does this duty derive from the categorical imperative that engineers must never treat third-party lives as mere means to passenger safety ends?
From a consequentialist perspective, does the Board's conclusion that Engineer A must recommend minimizing harm to the least number of persons adequately account for the aggregate welfare calculus across all possible crash scenarios, including cases where passenger sacrifice might produce net societal harm through reduced adoption of safer autonomous vehicles overall?
From a virtue ethics standpoint, does Engineer A demonstrate the professional integrity and moral courage required of a virtuous engineer when actively expressing concerns about harm-allocation algorithms within a risk assessment team that may face significant commercial pressure to prioritize passenger safety over third-party welfare?
From a deontological perspective, does Engineer A's obligation to disclose the moral framework embedded in the autonomous vehicle's harm-allocation algorithm to the public constitute a perfect duty under professional ethics codes, and does the absence of applicable regulatory standards heighten rather than relieve that disclosure duty?
Counterfactual (4)
If Engineer A had remained silent or provided only a partial assessment of the third-party harm risks within the risk assessment team, would the automobile manufacturer have had sufficient information to make an ethically informed deployment decision, and would Engineer A's silence have constituted a violation of the faithful agent obligation?
What if the automobile manufacturer had already established a firm design policy prioritizing passenger safety above all third-party considerations before Engineer A joined the risk assessment team - would Engineer A's ethical obligations shift from recommendation to escalation or refusal to certify the system?
Had established national or industry standards governing autonomous vehicle harm-allocation decision logic existed at the time of Engineer A's assessment - analogous to the draft standards emerging in BER Case 96-4 - would Engineer A's obligation to recommend further study before deployment have been stronger, weaker, or qualitatively different in character?
If Engineer A had proposed and the team had successfully identified a technical mitigation option - such as a sensor-based system capable of dynamically evaluating crash scenarios in real time rather than relying on pre-committed algorithmic harm-allocation logic - would the core ethical dilemma between passenger safety and third-party harm minimization have been dissolved, and what residual ethical obligations would Engineer A retain regarding transparency about the system's remaining limitations?
Decisions & Arguments (6)
View ExtractionShould 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?
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.
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.
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?
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.
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.
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?
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.
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.
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?
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.
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.
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?
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.
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.
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?
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.
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.
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.
Event Timeline (13)
Case timeline
- Hold paramount the safety, health, and welfare of the public (NSPE Code Section II.4.a.)
- Provide technically honest and accurate information to employer (NSPE Code Section III.6.b.)
- Base safety recommendations solely on technical findings, not business considerations
- Strive to do no harm in the performance of professional services
- Issue public statements in an objective and truthful manner (NSPE Code Section III.6.b.)
- Act in such a manner as to uphold and enhance the honor, integrity, and dignity of the engineering profession (NSPE Code Section II.4.a.)
- Provide clear, accurate, and direct information to employer and client
- Enable informed decision-making in furtherance of public health, safety, and welfare
- Strive to do no harm in performance of professional services
- Hold paramount the safety, health, and welfare of the public
- Strive to do no harm in the performance of professional services
- Fulfill professional responsibility as a member of a safety-critical engineering team
- Contribute technical expertise to inform employer decision-making on public safety matters
- Hold paramount the safety, health, and welfare of the public
- Strive to do no harm in performance of professional services
- Provide honest and complete professional judgment to employer
- Act in such a manner as to uphold and enhance the honor, integrity, and dignity of the engineering profession
- Hold paramount the safety, health, and welfare of the public
- Strive to do no harm in performance of professional services
- Contribute technical expertise constructively to employer decision-making
- Fulfill professional responsibility as a risk assessment team member
- Hold paramount the safety, health, and welfare of the public
- Strive to do no harm in performance of professional services
- Provide honest and complete professional judgment to employer even when financially inconvenient
- Fulfill obligation to recommend technically sound safety measures independent of business considerations
Narrative (1 main characters)
View ExtractionOpening Context
Written in second person from the engineer's point of view, so you read the case as the professional experienced it. Underlined names link to the character's profile below.
You are Engineer A, a professional engineer working as a consultant to an automobile manufacturer that is evaluating the development of a driverless autonomous vehicle operating system. You have been assigned to an engineering risk assessment team tasked with analyzing potential situations that could arise during autonomous vehicle operation. One scenario under review asks whether, in the event of an unavoidable crash, the vehicle's software should prioritize the safety of its own passengers or instead minimize total harm to all parties, including pedestrians, cyclists, and motorcycle riders who may be at risk. No established national or industry standards currently govern how harm-allocation decision logic should be designed or disclosed in autonomous vehicle systems. The recommendations your team produces will directly inform the manufacturer's development decisions. You must now work through the technical, ethical, and professional obligations that apply to your role in this process.
Main characters (1)
Each card shows the roles a person holds and the tensions those roles raise for them. A single person may carry several roles in the case, and a tension between obligations can implicate more than one person at once. Click Show all tensions for the full list.
Tension between Engineer A AV Faithful Agent Informed Decision Enablement Obligation / Technical Recommendation Business Pressure Non-Subordination Obligation and Engineer A AV Passenger Priority Algorithm Third-Party Fatal Harm Non-Subordination Constraint
Tension between Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation and Graduated Internal Escalation Before External Reporting and Engineer A AV Passenger Priority Algorithm Third-Party Fatal Harm Non-Subordination Constraint
Engineer A has a dual obligation: to refuse subordination of technical safety recommendations to business pressure, and simultaneously to act as a faithful agent enabling the employer/client to make informed decisions. These obligations pull in opposing directions when the client's informed decision—made with full knowledge of Engineer A's safety concerns—is nonetheless to proceed with deployment. If the client is fully informed yet still chooses deployment, the faithful-agent obligation is technically satisfied, but the non-subordination obligation may require Engineer A to escalate or refuse participation, going beyond mere disclosure. Conversely, limiting action to enabling informed decisions without further resistance could be construed as tacit subordination of safety judgment to business outcomes. The tension is between respecting client autonomy after disclosure and maintaining independent professional integrity.
Tension between Engineer A AV Risk Assessment Team Harm Minimization Participation Obligation / Autonomous Vehicle Further Study Recommendation Before Deployment Obligation and Engineer A AV Client Interest Third-Party Safety Priority Constraint
Tension between Engineer A Autonomous Vehicle Do No Harm Obligation and Risk Assessment Active Participation Obligation and Engineer A AV Client Interest Third-Party Safety Priority Constraint
Engineer A is obligated to recommend further study before deployment of the autonomous vehicle system, yet the client (automobile manufacturer) has strong commercial interests in proceeding to market. The constraint demands that third-party safety must take priority over client interests, but acting on this constraint by insisting on further study directly conflicts with the client's deployment timeline and business objectives. Fulfilling the obligation faithfully may require Engineer A to resist client pressure in ways that jeopardize the professional relationship, while yielding to client interest violates the safety-priority constraint. This creates a genuine dilemma between professional loyalty to the client as faithful agent and paramount duty to public safety.
Tension between Autonomous Vehicle Harm Minimization Algorithm Completeness Disclosure Obligation / Autonomous Vehicle Moral Framework Public Transparency Disclosure Obligation and Engineer A AV Regulatory Standards Vacuum Escalation Permissibility Constraint
Engineer A is obligated to recommend that the moral framework embedded in the AV harm-minimization algorithm be disclosed publicly so that consumers and society can make informed decisions. However, the algorithmic pre-commitment ethical constraint recognizes that encoding a fixed harm-allocation decision in advance—and then disclosing it—raises profound ethical problems: public disclosure of a pre-committed framework (e.g., passenger-over-pedestrian priority) may itself be ethically impermissible if that framework encodes morally objectionable trade-offs. Fulfilling the transparency obligation by disclosing the framework validates and entrenches a potentially unjust pre-commitment, while suppressing disclosure violates the transparency obligation. The engineer cannot simultaneously satisfy full transparency and avoid legitimizing an ethically contested algorithmic moral stance.
Tension between Autonomous Vehicle Moral Framework Public Transparency Recommendation Obligation and Completeness and Non-Selectivity in Advisory Opinions and Engineer A AV Harm Allocation Moral Framework Non-Deception Public Disclosure Constraint
Other people involved in the case but not central to the opening narrative.
Engineer A has a dual obligation: to refuse subordination of technical safety recommendations to business pressure, and simultaneously to act as a faithful agent enabling the employer/client to make informed decisions. These obligations pull in opposing directions when the client's informed decision—made with full knowledge of Engineer A's safety concerns—is nonetheless to proceed with deployment. If the client is fully informed yet still chooses deployment, the faithful-agent obligation is technically satisfied, but the non-subordination obligation may require Engineer A to escalate or refuse participation, going beyond mere disclosure. Conversely, limiting action to enabling informed decisions without further resistance could be construed as tacit subordination of safety judgment to business outcomes. The tension is between respecting client autonomy after disclosure and maintaining independent professional integrity.
Engineer A is obligated to recommend further study before deployment of the autonomous vehicle system, yet the client (automobile manufacturer) has strong commercial interests in proceeding to market. The constraint demands that third-party safety must take priority over client interests, but acting on this constraint by insisting on further study directly conflicts with the client's deployment timeline and business objectives. Fulfilling the obligation faithfully may require Engineer A to resist client pressure in ways that jeopardize the professional relationship, while yielding to client interest violates the safety-priority constraint. This creates a genuine dilemma between professional loyalty to the client as faithful agent and paramount duty to public safety.
Engineer A is obligated to recommend that the moral framework embedded in the AV harm-minimization algorithm be disclosed publicly so that consumers and society can make informed decisions. However, the algorithmic pre-commitment ethical constraint recognizes that encoding a fixed harm-allocation decision in advance—and then disclosing it—raises profound ethical problems: public disclosure of a pre-committed framework (e.g., passenger-over-pedestrian priority) may itself be ethically impermissible if that framework encodes morally objectionable trade-offs. Fulfilling the transparency obligation by disclosing the framework validates and entrenches a potentially unjust pre-commitment, while suppressing disclosure violates the transparency obligation. The engineer cannot simultaneously satisfy full transparency and avoid legitimizing an ethically contested algorithmic moral stance.
Engineer A has a dual obligation: to refuse subordination of technical safety recommendations to business pressure, and simultaneously to act as a faithful agent enabling the employer/client to make informed decisions. These obligations pull in opposing directions when the client's informed decision—made with full knowledge of Engineer A's safety concerns—is nonetheless to proceed with deployment. If the client is fully informed yet still chooses deployment, the faithful-agent obligation is technically satisfied, but the non-subordination obligation may require Engineer A to escalate or refuse participation, going beyond mere disclosure. Conversely, limiting action to enabling informed decisions without further resistance could be construed as tacit subordination of safety judgment to business outcomes. The tension is between respecting client autonomy after disclosure and maintaining independent professional integrity.
Opening States (10)
Summary
- When regulatory frameworks have not yet caught up to emerging technology, engineers bear a heightened personal obligation to surface ethical concerns rather than defaulting to compliance silence.
- The prime directive of harm minimization cannot be subordinated to client commercial interests or passenger-priority algorithms when third-party fatal harm is a foreseeable outcome.
- A stalemate resolution signals that the board identified irreconcilable competing duties, meaning the engineer's obligation defaults to the most protective principle — public safety — as the irreducible floor.