PASS 3: Temporal Dynamics
Case 165: Public Health, Safety, and Welfare—Driverless/Autonomous Vehicle
Timeline Overview
OWL-Time Temporal Structure 10 relations time: = w3.org/2006/time
Extracted Actions (6)
Volitional professional decisions with intentions and ethical contextDescription: Engineer A chose to recommend costly additional software testing to his company despite significant financial and competitive pressures, fulfilling his professional obligation to prioritize public safety over business convenience.
Temporal Marker: BER Case 96-4, circa 1996, post-design pre-release phase
Mental State: deliberate
Intended Outcome: Ensure software safety compliance with emerging draft standards and enable informed decision-making by employer regarding public health, safety, and welfare
Fulfills Obligations:
- 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
Guided By Principles:
- Public safety paramount
- Technical integrity independent of financial pressures
- Informed decision-making by employer
- Transparency in professional reporting
Required Capabilities:
Scenario Metadata
Pedagogical context for interactive teaching scenariosCharacter Motivation: Engineer A recognized that emerging draft standards and existing professional literature signaled unresolved safety risks in the software, and felt a primary obligation to protect public welfare even when doing so conflicted with the company's financial and competitive interests. The precedent case context suggests he had already internalized that safety obligations are non-negotiable professional duties, not optional considerations.
Ethical Tension: Professional duty to prioritize public safety (NSPE Code of Ethics, Canon 1) versus organizational loyalty and financial stewardship — the company faced real competitive disadvantage and cost burdens if additional testing was mandated, yet cutting corners risked harm to end users who had no voice in the decision.
Learning Significance: Illustrates that ethical engineering decisions often carry tangible financial costs, and that professional integrity requires engineers to make recommendations based on technical merit and safety evidence rather than business convenience. Establishes that recommending unpopular but necessary actions is itself a core professional competency, not insubordination.
Stakes: Immediate financial cost and competitive delay for the company; potential liability exposure if software fails post-release; public safety risk if defective software reaches market; Engineer A's professional reputation and employment security if recommendation is unwelcome.
Decision Point: Yes - Story can branch here
- Remain silent and defer to management's implicit preference to avoid additional costs
- Recommend only the minimum testing already planned, noting the new literature as a footnote without escalating its significance
- Privately flag concerns to a senior colleague but avoid formally recommending additional testing
Narrative Role: inciting_incident
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Action_Recommend_Additional_Safety_Testing",
"@type": "proeth:Action",
"proeth-scenario:alternativeActions": [
"Remain silent and defer to management\u0027s implicit preference to avoid additional costs",
"Recommend only the minimum testing already planned, noting the new literature as a footnote without escalating its significance",
"Privately flag concerns to a senior colleague but avoid formally recommending additional testing"
],
"proeth-scenario:characterMotivation": "Engineer A recognized that emerging draft standards and existing professional literature signaled unresolved safety risks in the software, and felt a primary obligation to protect public welfare even when doing so conflicted with the company\u0027s financial and competitive interests. The precedent case context suggests he had already internalized that safety obligations are non-negotiable professional duties, not optional considerations.",
"proeth-scenario:consequencesIfAlternative": [
"Silence/deference: Software proceeds without additional testing; if a safety failure later occurs, Engineer A bears moral and potentially legal culpability for knowing of the risk and not acting; sets a precedent of subordinating safety to business pressure.",
"Minimum testing with footnote: Creates a paper trail that acknowledges risk without forcing a decision, but effectively buries the concern; management may later claim ignorance; public harm risk remains unaddressed; ethically evasive rather than transparent.",
"Private flagging only: Diffuses personal responsibility but fails the professional obligation to formally advocate for safety; the concern may be ignored without documentation; does not constitute fulfillment of the engineer\u0027s duty to hold public safety paramount."
],
"proeth-scenario:decisionSignificance": "Illustrates that ethical engineering decisions often carry tangible financial costs, and that professional integrity requires engineers to make recommendations based on technical merit and safety evidence rather than business convenience. Establishes that recommending unpopular but necessary actions is itself a core professional competency, not insubordination.",
"proeth-scenario:ethicalTension": "Professional duty to prioritize public safety (NSPE Code of Ethics, Canon 1) versus organizational loyalty and financial stewardship \u2014 the company faced real competitive disadvantage and cost burdens if additional testing was mandated, yet cutting corners risked harm to end users who had no voice in the decision.",
"proeth-scenario:isDecisionPoint": true,
"proeth-scenario:narrativeRole": "inciting_incident",
"proeth-scenario:stakes": "Immediate financial cost and competitive delay for the company; potential liability exposure if software fails post-release; public safety risk if defective software reaches market; Engineer A\u0027s professional reputation and employment security if recommendation is unwelcome.",
"proeth:description": "Engineer A chose to recommend costly additional software testing to his company despite significant financial and competitive pressures, fulfilling his professional obligation to prioritize public safety over business convenience.",
"proeth:foreseenUnintendedEffects": [
"Six-month deployment delay causing competitive disadvantage to client",
"Significant financial cost to software company and client",
"Rising public utility rates during delay period",
"Potential job losses associated with delayed implementation"
],
"proeth:fulfillsObligation": [
"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"
],
"proeth:guidedByPrinciple": [
"Public safety paramount",
"Technical integrity independent of financial pressures",
"Informed decision-making by employer",
"Transparency in professional reporting"
],
"proeth:hasAgent": "Engineer A (Professional Engineer / Software Company Consultant, BER Case 96-4)",
"proeth:hasCompetingPriorities": {
"@type": "proeth:CompetingPriorities",
"proeth:priorityConflict": "Public safety obligation versus financial and competitive harm to multiple stakeholders",
"proeth:resolutionReasoning": "Engineer A separated technical obligations from business considerations, determining that the recommendation to test must be grounded solely in technical findings; nontechnical financial factors were acknowledged but treated as matters for employer decision-making rather than reasons to suppress the safety recommendation"
},
"proeth:hasMentalState": "deliberate",
"proeth:intendedOutcome": "Ensure software safety compliance with emerging draft standards and enable informed decision-making by employer regarding public health, safety, and welfare",
"proeth:requiresCapability": [
"Software safety analysis",
"Knowledge of existing and emerging safety standards",
"Risk assessment for safety-critical systems",
"Technical report preparation",
"Professional judgment in balancing safety and business factors"
],
"proeth:temporalMarker": "BER Case 96-4, circa 1996, post-design pre-release phase",
"proeth:withinCompetence": true,
"rdfs:label": "Recommend Additional Safety Testing"
}
Description: Engineer A prepared a technical report clearly documenting current testing analysis, results, and the new testing procedure reported in professional literature, so that his employer could make a fully informed decision regarding additional testing.
Temporal Marker: BER Case 96-4, circa 1996, concurrent with or following recommendation for additional testing
Mental State: deliberate
Intended Outcome: Provide employer with clear, accurate, and direct information necessary to make an informed decision about additional testing and its implications for public health, safety, and welfare
Fulfills Obligations:
- 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
Guided By Principles:
- Transparency and honesty in professional communication
- Public safety paramount
- Technical objectivity independent of business pressures
- Professional integrity
Required Capabilities:
Scenario Metadata
Pedagogical context for interactive teaching scenariosCharacter Motivation: Engineer A understood that his professional role was not to make the business decision for the company, but to ensure that whoever did make that decision had complete, accurate, and unambiguous technical information. Transparency in reporting was both an ethical obligation and a practical mechanism for shifting informed decision-making authority appropriately to management while preserving his own professional integrity.
Ethical Tension: Completeness and transparency versus the temptation to frame or filter information to steer a preferred outcome — even well-intentioned selective reporting undermines informed consent and organizational autonomy. There is also tension between technical communication clarity and the risk that full disclosure accelerates unwanted scrutiny or regulatory attention.
Learning Significance: Demonstrates that ethical engineering practice requires not only identifying problems but communicating them with full fidelity. Teaches students that a technically accurate but strategically incomplete report is itself an ethical failure. Highlights the engineer's role as an honest information broker within organizational decision-making hierarchies.
Stakes: Quality of organizational decision-making depends entirely on report accuracy; a misleading or incomplete report could cause management to approve inadequate testing in good faith; professional credibility of Engineer A is on the line; if the report is later found to have omitted material information, legal and reputational consequences follow.
Decision Point: Yes - Story can branch here
- Prepare a report that emphasizes the costs and feasibility challenges of additional testing, downplaying the safety literature findings
- Submit only raw data without interpretive analysis, leaving management to draw their own conclusions without engineering guidance
- Verbally brief management rather than producing a formal written report, reducing the documentary record
Narrative Role: rising_action
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Action_Prepare_Transparent_Technical_Report",
"@type": "proeth:Action",
"proeth-scenario:alternativeActions": [
"Prepare a report that emphasizes the costs and feasibility challenges of additional testing, downplaying the safety literature findings",
"Submit only raw data without interpretive analysis, leaving management to draw their own conclusions without engineering guidance",
"Verbally brief management rather than producing a formal written report, reducing the documentary record"
],
"proeth-scenario:characterMotivation": "Engineer A understood that his professional role was not to make the business decision for the company, but to ensure that whoever did make that decision had complete, accurate, and unambiguous technical information. Transparency in reporting was both an ethical obligation and a practical mechanism for shifting informed decision-making authority appropriately to management while preserving his own professional integrity.",
"proeth-scenario:consequencesIfAlternative": [
"Biased framing: Management makes a cost-optimized decision without fully understanding the safety risk; Engineer A has technically reported but has violated the spirit of transparent professional communication; creates moral hazard.",
"Raw data only: Management lacks the technical expertise to interpret findings correctly; the engineer abdicates his interpretive responsibility; the report technically exists but fails its purpose of enabling informed decision-making.",
"Verbal briefing only: No formal record exists of the safety concern being raised; if harm occurs, there is no evidence of due diligence; Engineer A loses the protective documentation that demonstrates he fulfilled his professional duty; organizational accountability is undermined."
],
"proeth-scenario:decisionSignificance": "Demonstrates that ethical engineering practice requires not only identifying problems but communicating them with full fidelity. Teaches students that a technically accurate but strategically incomplete report is itself an ethical failure. Highlights the engineer\u0027s role as an honest information broker within organizational decision-making hierarchies.",
"proeth-scenario:ethicalTension": "Completeness and transparency versus the temptation to frame or filter information to steer a preferred outcome \u2014 even well-intentioned selective reporting undermines informed consent and organizational autonomy. There is also tension between technical communication clarity and the risk that full disclosure accelerates unwanted scrutiny or regulatory attention.",
"proeth-scenario:isDecisionPoint": true,
"proeth-scenario:narrativeRole": "rising_action",
"proeth-scenario:stakes": "Quality of organizational decision-making depends entirely on report accuracy; a misleading or incomplete report could cause management to approve inadequate testing in good faith; professional credibility of Engineer A is on the line; if the report is later found to have omitted material information, legal and reputational consequences follow.",
"proeth:description": "Engineer A prepared a technical report clearly documenting current testing analysis, results, and the new testing procedure reported in professional literature, so that his employer could make a fully informed decision regarding additional testing.",
"proeth:foreseenUnintendedEffects": [
"Report could trigger employer decision to pursue costly testing",
"Transparent documentation of safety uncertainty could expose company to regulatory or legal scrutiny",
"Report could create a formal record obligating the company to act on the findings"
],
"proeth:fulfillsObligation": [
"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"
],
"proeth:guidedByPrinciple": [
"Transparency and honesty in professional communication",
"Public safety paramount",
"Technical objectivity independent of business pressures",
"Professional integrity"
],
"proeth:hasAgent": "Engineer A (Professional Engineer / Software Company Consultant, BER Case 96-4)",
"proeth:hasCompetingPriorities": {
"@type": "proeth:CompetingPriorities",
"proeth:priorityConflict": "Complete technical transparency versus protection of company business interests",
"proeth:resolutionReasoning": "Technical accuracy and public safety obligations required full disclosure of all relevant testing information and emerging standards; business protection interests were subordinate to the engineer\u0027s duty to provide honest, complete technical reporting"
},
"proeth:hasMentalState": "deliberate",
"proeth:intendedOutcome": "Provide employer with clear, accurate, and direct information necessary to make an informed decision about additional testing and its implications for public health, safety, and welfare",
"proeth:requiresCapability": [
"Technical writing and documentation",
"Software safety testing analysis",
"Knowledge of current and draft safety standards",
"Ability to communicate complex technical findings clearly to non-technical decision-makers"
],
"proeth:temporalMarker": "BER Case 96-4, circa 1996, concurrent with or following recommendation for additional testing",
"proeth:withinCompetence": true,
"rdfs:label": "Prepare Transparent Technical Report"
}
Description: Engineer A chose to fully and actively participate as a member of the engineering risk assessment team evaluating ethical and safety scenarios for the autonomous vehicle operating system, rather than adopting a passive or deferential role within the team.
Temporal Marker: Present case, pre-development/assessment phase of autonomous vehicle operating system
Mental State: deliberate
Intended Outcome: Contribute meaningfully to the team's evaluation of safety and ethical scenarios so that the autonomous vehicle operating system, if developed, adequately addresses public safety concerns
Fulfills Obligations:
- Hold paramount the safety, health, and welfare of the public
- Fulfill professional responsibility as a member of a safety-critical engineering team
- Strive to do no harm in the performance of professional services
- Contribute technical expertise to inform employer decision-making on public safety matters
Guided By Principles:
- Public safety paramount
- Professional responsibility and engagement
- Do no harm
- Technical integrity
Required Capabilities:
Scenario Metadata
Pedagogical context for interactive teaching scenariosCharacter Motivation: Engineer A recognized that passive participation in a risk assessment team — attending meetings but deferring all substantive judgments to others — would be a form of ethical abdication. His technical expertise was the reason he was placed on the team, and withholding active engagement would deprive the team of precisely the informed engineering perspective the process required. Active participation was an expression of professional responsibility, not merely a procedural role.
Ethical Tension: Individual professional agency versus deference to collective team dynamics or hierarchical authority — engineers on multidisciplinary teams often face pressure to defer to dominant voices, senior members, or non-engineering stakeholders. There is also tension between collaborative humility and the obligation to ensure technical safety concerns are not lost in group consensus processes.
Learning Significance: Teaches that participation in ethics and safety review processes is itself an ethical act requiring genuine engagement. Students learn that 'showing up' is insufficient — professional responsibility demands substantive contribution. Also introduces the concept of diffusion of responsibility in team settings, where individuals may assume others will raise concerns.
Stakes: If Engineer A is passive, critical technical safety insights may never surface in team deliberations; group decisions may be made without adequate engineering input; the risk assessment process itself loses integrity; Engineer A becomes complicit in any resulting oversight failures through his silence.
Decision Point: Yes - Story can branch here
- Participate minimally — attend meetings, respond when directly asked, but avoid volunteering concerns or analysis
- Defer entirely to the team lead or senior engineers, treating his role as administrative or observational
- Participate actively only in areas outside the most controversial ethical dilemmas, avoiding the algorithmic harm prioritization questions
Narrative Role: rising_action
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Action_Actively_Participate_in_Risk_Assessment",
"@type": "proeth:Action",
"proeth-scenario:alternativeActions": [
"Participate minimally \u2014 attend meetings, respond when directly asked, but avoid volunteering concerns or analysis",
"Defer entirely to the team lead or senior engineers, treating his role as administrative or observational",
"Participate actively only in areas outside the most controversial ethical dilemmas, avoiding the algorithmic harm prioritization questions"
],
"proeth-scenario:characterMotivation": "Engineer A recognized that passive participation in a risk assessment team \u2014 attending meetings but deferring all substantive judgments to others \u2014 would be a form of ethical abdication. His technical expertise was the reason he was placed on the team, and withholding active engagement would deprive the team of precisely the informed engineering perspective the process required. Active participation was an expression of professional responsibility, not merely a procedural role.",
"proeth-scenario:consequencesIfAlternative": [
"Minimal participation: Engineer A\u0027s specific technical knowledge never enters the deliberation; the team may reach conclusions that a more engaged participant would have challenged; Engineer A retains plausible deniability but has failed his professional duty.",
"Full deference: The team loses independent technical perspective; groupthink risk increases; if the senior engineer is wrong or has conflicting interests, no corrective voice exists; ethical responsibility cannot be fully delegated.",
"Selective participation: The most ethically complex and consequential questions \u2014 precisely those requiring rigorous engineering input \u2014 are left to non-engineers or less-informed voices; the algorithmic harm prioritization decisions may be made without adequate technical grounding."
],
"proeth-scenario:decisionSignificance": "Teaches that participation in ethics and safety review processes is itself an ethical act requiring genuine engagement. Students learn that \u0027showing up\u0027 is insufficient \u2014 professional responsibility demands substantive contribution. Also introduces the concept of diffusion of responsibility in team settings, where individuals may assume others will raise concerns.",
"proeth-scenario:ethicalTension": "Individual professional agency versus deference to collective team dynamics or hierarchical authority \u2014 engineers on multidisciplinary teams often face pressure to defer to dominant voices, senior members, or non-engineering stakeholders. There is also tension between collaborative humility and the obligation to ensure technical safety concerns are not lost in group consensus processes.",
"proeth-scenario:isDecisionPoint": true,
"proeth-scenario:narrativeRole": "rising_action",
"proeth-scenario:stakes": "If Engineer A is passive, critical technical safety insights may never surface in team deliberations; group decisions may be made without adequate engineering input; the risk assessment process itself loses integrity; Engineer A becomes complicit in any resulting oversight failures through his silence.",
"proeth:description": "Engineer A chose to fully and actively participate as a member of the engineering risk assessment team evaluating ethical and safety scenarios for the autonomous vehicle operating system, rather than adopting a passive or deferential role within the team.",
"proeth:foreseenUnintendedEffects": [
"Active participation may surface difficult ethical tradeoffs that complicate or delay development",
"Raising concerns may create friction with team members or manufacturer management prioritizing development speed"
],
"proeth:fulfillsObligation": [
"Hold paramount the safety, health, and welfare of the public",
"Fulfill professional responsibility as a member of a safety-critical engineering team",
"Strive to do no harm in the performance of professional services",
"Contribute technical expertise to inform employer decision-making on public safety matters"
],
"proeth:guidedByPrinciple": [
"Public safety paramount",
"Professional responsibility and engagement",
"Do no harm",
"Technical integrity"
],
"proeth:hasAgent": "Engineer A (Professional Engineer / Consultant to Automobile Manufacturer, present case)",
"proeth:hasCompetingPriorities": {
"@type": "proeth:CompetingPriorities",
"proeth:priorityConflict": "Individual ethical responsibility to surface concerns versus collaborative team membership norms",
"proeth:resolutionReasoning": "Full and active participation was determined to be both a professional obligation and the most effective means of ensuring safety concerns were heard; passive participation would have constituted an abdication of professional responsibility in a safety-critical context"
},
"proeth:hasMentalState": "deliberate",
"proeth:intendedOutcome": "Contribute meaningfully to the team\u0027s evaluation of safety and ethical scenarios so that the autonomous vehicle operating system, if developed, adequately addresses public safety concerns",
"proeth:requiresCapability": [
"Risk assessment methodology",
"Software systems engineering",
"Ethical analysis of algorithmic decision-making",
"Autonomous vehicle technology knowledge",
"Collaborative technical team participation"
],
"proeth:temporalMarker": "Present case, pre-development/assessment phase of autonomous vehicle operating system",
"proeth:withinCompetence": true,
"rdfs:label": "Actively Participate in Risk Assessment"
}
Description: Engineer A chose to clearly and unambiguously express any and all concerns regarding the safety of the proposed autonomous vehicle operating system within the risk assessment team, rather than moderating or suppressing concerns due to business or team pressures.
Temporal Marker: Present case, during risk assessment team deliberations, pre-development phase
Mental State: deliberate
Intended Outcome: Ensure that all safety concerns are formally on record within the team's deliberations, enabling the manufacturer to make fully informed decisions about the autonomous vehicle operating system before development proceeds
Fulfills Obligations:
- Hold paramount the safety, health, and welfare of the public
- Provide honest and complete professional judgment to employer
- Strive to do no harm in performance of professional services
- Act in such a manner as to uphold and enhance the honor, integrity, and dignity of the engineering profession
Guided By Principles:
- Public safety paramount
- Honesty and transparency in professional communication
- Do no harm
- Technical integrity independent of business pressures
Required Capabilities:
Scenario Metadata
Pedagogical context for interactive teaching scenariosCharacter Motivation: Engineer A understood that ambiguous, hedged, or softened safety concerns are functionally equivalent to silence in high-stakes decision-making contexts. Business and competitive pressures create powerful incentives to moderate the expression of concerns — to frame them as minor, speculative, or already addressed — and Engineer A recognized that yielding to these pressures would corrupt the integrity of the safety assessment process and ultimately betray the public whose safety depended on honest engineering judgment.
Ethical Tension: Professional candor and completeness versus social and organizational pressures to maintain team harmony, avoid conflict, and support the project's momentum. Engineers may also face implicit threats to their employment or advancement for being perceived as obstructionist. There is further tension between expressing uncertainty (which is honest) and the risk that uncertainty will be used by others to dismiss legitimate safety concerns.
Learning Significance: Central teaching moment about the ethics of voice within organizations. Illustrates that ethical courage is not merely about identifying the right answer but about expressing it clearly under pressure. Connects to whistleblowing literature and the concept of 'psychological safety' — and what happens when it is absent. Students learn that moderated or softened safety concerns can be more dangerous than silence, because they create false confidence.
Stakes: If concerns are suppressed or softened, the risk assessment reaches flawed conclusions with apparent engineering endorsement; decision-makers believe safety has been adequately vetted when it has not; the autonomous vehicle system may be deployed with known but undisclosed risks; public harm is the ultimate downstream consequence; Engineer A bears professional and moral responsibility.
Decision Point: Yes - Story can branch here
- Express concerns privately to the team lead but agree to present a unified, concern-free position to senior management
- Frame concerns as hypothetical or low-probability to avoid appearing obstructionist while technically having raised them
- Raise concerns once, then withdraw them if met with resistance to preserve team relationships and project momentum
Narrative Role: climax
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Action_Unambiguously_Express_Safety_Concerns",
"@type": "proeth:Action",
"proeth-scenario:alternativeActions": [
"Express concerns privately to the team lead but agree to present a unified, concern-free position to senior management",
"Frame concerns as hypothetical or low-probability to avoid appearing obstructionist while technically having raised them",
"Raise concerns once, then withdraw them if met with resistance to preserve team relationships and project momentum"
],
"proeth-scenario:characterMotivation": "Engineer A understood that ambiguous, hedged, or softened safety concerns are functionally equivalent to silence in high-stakes decision-making contexts. Business and competitive pressures create powerful incentives to moderate the expression of concerns \u2014 to frame them as minor, speculative, or already addressed \u2014 and Engineer A recognized that yielding to these pressures would corrupt the integrity of the safety assessment process and ultimately betray the public whose safety depended on honest engineering judgment.",
"proeth-scenario:consequencesIfAlternative": [
"Private concern, unified front: Management receives a false picture of engineering consensus; the team lead becomes the sole filter for safety information; if the team lead is wrong or conflicted, no independent check remains; Engineer A has outsourced his professional responsibility.",
"Hypothetical framing: Concerns are technically on record but practically dismissed; decision-makers rationally discount low-probability framings; the safety issue is buried in probabilistic language that obscures its actual significance; a false sense of due diligence is created.",
"Single expression then withdrawal: The concern appears in meeting minutes but is not pursued; organizational pressure has effectively silenced the engineer; the pattern signals to the team that safety concerns can be managed away through social pressure rather than technical resolution."
],
"proeth-scenario:decisionSignificance": "Central teaching moment about the ethics of voice within organizations. Illustrates that ethical courage is not merely about identifying the right answer but about expressing it clearly under pressure. Connects to whistleblowing literature and the concept of \u0027psychological safety\u0027 \u2014 and what happens when it is absent. Students learn that moderated or softened safety concerns can be more dangerous than silence, because they create false confidence.",
"proeth-scenario:ethicalTension": "Professional candor and completeness versus social and organizational pressures to maintain team harmony, avoid conflict, and support the project\u0027s momentum. Engineers may also face implicit threats to their employment or advancement for being perceived as obstructionist. There is further tension between expressing uncertainty (which is honest) and the risk that uncertainty will be used by others to dismiss legitimate safety concerns.",
"proeth-scenario:isDecisionPoint": true,
"proeth-scenario:narrativeRole": "climax",
"proeth-scenario:stakes": "If concerns are suppressed or softened, the risk assessment reaches flawed conclusions with apparent engineering endorsement; decision-makers believe safety has been adequately vetted when it has not; the autonomous vehicle system may be deployed with known but undisclosed risks; public harm is the ultimate downstream consequence; Engineer A bears professional and moral responsibility.",
"proeth:description": "Engineer A chose to clearly and unambiguously express any and all concerns regarding the safety of the proposed autonomous vehicle operating system within the risk assessment team, rather than moderating or suppressing concerns due to business or team pressures.",
"proeth:foreseenUnintendedEffects": [
"Expressing concerns may slow or complicate the development timeline",
"Unambiguous expression of concerns may create professional tension with team members or manufacturer management",
"Documented concerns could expose the manufacturer to liability if concerns are not addressed and harm later occurs"
],
"proeth:fulfillsObligation": [
"Hold paramount the safety, health, and welfare of the public",
"Provide honest and complete professional judgment to employer",
"Strive to do no harm in performance of professional services",
"Act in such a manner as to uphold and enhance the honor, integrity, and dignity of the engineering profession"
],
"proeth:guidedByPrinciple": [
"Public safety paramount",
"Honesty and transparency in professional communication",
"Do no harm",
"Technical integrity independent of business pressures"
],
"proeth:hasAgent": "Engineer A (Professional Engineer / Consultant to Automobile Manufacturer, present case)",
"proeth:hasCompetingPriorities": {
"@type": "proeth:CompetingPriorities",
"proeth:priorityConflict": "Individual professional safety obligations versus team cohesion and manufacturer business interests",
"proeth:resolutionReasoning": "Unambiguous expression of safety concerns was determined to be a non-negotiable professional obligation; the potential for concerns to create business friction or delay was acknowledged but treated as insufficient justification for moderating or suppressing technically grounded safety concerns"
},
"proeth:hasMentalState": "deliberate",
"proeth:intendedOutcome": "Ensure that all safety concerns are formally on record within the team\u0027s deliberations, enabling the manufacturer to make fully informed decisions about the autonomous vehicle operating system before development proceeds",
"proeth:requiresCapability": [
"Safety risk identification and articulation",
"Ethical analysis of algorithmic decision systems",
"Professional communication of technical concerns to non-technical stakeholders",
"Courage and professional independence in expressing dissenting safety views"
],
"proeth:temporalMarker": "Present case, during risk assessment team deliberations, pre-development phase",
"proeth:withinCompetence": true,
"rdfs:label": "Unambiguously Express Safety Concerns"
}
Description: Engineer A chose to actively explore additional potential technical options that could mitigate the risks identified in the proposed autonomous vehicle operating system, going beyond simply identifying problems to proactively seeking engineering solutions.
Temporal Marker: Present case, during risk assessment team deliberations, pre-development phase
Mental State: deliberate
Intended Outcome: Identify technical design alternatives or safeguards that could reduce the ethical and safety risks inherent in the autonomous vehicle operating system's harm-prioritization algorithms, potentially enabling development to proceed on a safer basis
Fulfills Obligations:
- 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
Guided By Principles:
- Public safety paramount
- Do no harm
- Constructive professional contribution
- Technical innovation in service of safety
Required Capabilities:
Scenario Metadata
Pedagogical context for interactive teaching scenariosCharacter Motivation: Engineer A recognized that identifying a problem without attempting to solve it is an incomplete fulfillment of professional responsibility in an engineering context. His role was not merely to audit and critique but to contribute engineering creativity and expertise toward resolving safety challenges. Proactively exploring technical mitigations also demonstrated good faith — that his safety concerns were oriented toward enabling a safe product, not obstructing development.
Ethical Tension: Thoroughness and proactive problem-solving versus scope creep and the risk of overstepping team or organizational boundaries. There is also tension between the desire to find a technical fix (which may create pressure to deploy prematurely once a mitigation is proposed) and the honest acknowledgment that some risks may not be technically mitigable to an acceptable level. Additionally, exploring mitigations requires time and resources that may conflict with project timelines.
Learning Significance: Teaches students that ethical engineering is constructive, not merely critical. Illustrates the difference between a 'problem identifier' and a 'problem solver' orientation in professional ethics. Also raises the important question of whether technical mitigation options, once identified, can be used to rationalize deployment of systems that remain fundamentally unsafe — the limits of engineering solutionism.
Stakes: If no mitigation options are explored, the only available recommendation is halt or deploy as-is, eliminating middle-ground solutions; if mitigation options are found, they may enable responsible deployment; if mitigation options are proposed prematurely or incompletely, they may create false confidence and accelerate unsafe deployment.
Decision Point: Yes - Story can branch here
- Limit his role strictly to identifying and documenting risks, leaving mitigation design to other teams or future phases
- Propose a single mitigation option quickly to satisfy the expectation of constructive contribution without deep analysis
- Argue that the ethical dilemmas identified (harm prioritization algorithms) are not technical problems and therefore have no technical mitigation — refusing to engage in mitigation exploration
Narrative Role: falling_action
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Action_Explore_Additional_Technical_Mitigation_Options",
"@type": "proeth:Action",
"proeth-scenario:alternativeActions": [
"Limit his role strictly to identifying and documenting risks, leaving mitigation design to other teams or future phases",
"Propose a single mitigation option quickly to satisfy the expectation of constructive contribution without deep analysis",
"Argue that the ethical dilemmas identified (harm prioritization algorithms) are not technical problems and therefore have no technical mitigation \u2014 refusing to engage in mitigation exploration"
],
"proeth-scenario:characterMotivation": "Engineer A recognized that identifying a problem without attempting to solve it is an incomplete fulfillment of professional responsibility in an engineering context. His role was not merely to audit and critique but to contribute engineering creativity and expertise toward resolving safety challenges. Proactively exploring technical mitigations also demonstrated good faith \u2014 that his safety concerns were oriented toward enabling a safe product, not obstructing development.",
"proeth-scenario:consequencesIfAlternative": [
"Risk identification only: The team has a complete problem statement but no engineering pathway forward; management may interpret this as an impasse requiring project termination or may override concerns without technical counterweight; Engineer A has fulfilled a narrow version of his role but not its full scope.",
"Superficial single mitigation: A mitigation option exists on paper but has not been rigorously evaluated; it may be adopted by management as sufficient without further analysis; the appearance of a solution substitutes for an actual solution; safety risk is repackaged rather than resolved.",
"Refusal to engage on technical mitigation: While philosophically arguable for certain ethical dilemmas, this position may be correct in some cases but forecloses potentially valuable engineering contributions; it may also be perceived as a retreat from professional engagement; the team loses the benefit of engineering creativity applied to hard problems."
],
"proeth-scenario:decisionSignificance": "Teaches students that ethical engineering is constructive, not merely critical. Illustrates the difference between a \u0027problem identifier\u0027 and a \u0027problem solver\u0027 orientation in professional ethics. Also raises the important question of whether technical mitigation options, once identified, can be used to rationalize deployment of systems that remain fundamentally unsafe \u2014 the limits of engineering solutionism.",
"proeth-scenario:ethicalTension": "Thoroughness and proactive problem-solving versus scope creep and the risk of overstepping team or organizational boundaries. There is also tension between the desire to find a technical fix (which may create pressure to deploy prematurely once a mitigation is proposed) and the honest acknowledgment that some risks may not be technically mitigable to an acceptable level. Additionally, exploring mitigations requires time and resources that may conflict with project timelines.",
"proeth-scenario:isDecisionPoint": true,
"proeth-scenario:narrativeRole": "falling_action",
"proeth-scenario:stakes": "If no mitigation options are explored, the only available recommendation is halt or deploy as-is, eliminating middle-ground solutions; if mitigation options are found, they may enable responsible deployment; if mitigation options are proposed prematurely or incompletely, they may create false confidence and accelerate unsafe deployment.",
"proeth:description": "Engineer A chose to actively explore additional potential technical options that could mitigate the risks identified in the proposed autonomous vehicle operating system, going beyond simply identifying problems to proactively seeking engineering solutions.",
"proeth:foreseenUnintendedEffects": [
"Exploration of alternatives may reveal that no technically adequate mitigation exists, strengthening the case for further study or halting development",
"Proposed mitigations may add complexity and cost to the system",
"Alternative technical options may raise new ethical or safety concerns not previously identified"
],
"proeth:fulfillsObligation": [
"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"
],
"proeth:guidedByPrinciple": [
"Public safety paramount",
"Do no harm",
"Constructive professional contribution",
"Technical innovation in service of safety"
],
"proeth:hasAgent": "Engineer A (Professional Engineer / Consultant to Automobile Manufacturer, present case)",
"proeth:hasCompetingPriorities": {
"@type": "proeth:CompetingPriorities",
"proeth:priorityConflict": "Constructive problem-solving to enable development versus honest acknowledgment of potentially irresolvable ethical tradeoffs",
"proeth:resolutionReasoning": "Active exploration of mitigations was chosen as consistent with professional responsibility to contribute constructively, while the obligation to recommend further study if adequate mitigations cannot be identified preserved the integrity of the safety assessment"
},
"proeth:hasMentalState": "deliberate",
"proeth:intendedOutcome": "Identify technical design alternatives or safeguards that could reduce the ethical and safety risks inherent in the autonomous vehicle operating system\u0027s harm-prioritization algorithms, potentially enabling development to proceed on a safer basis",
"proeth:requiresCapability": [
"Autonomous vehicle systems engineering",
"Algorithmic safety design",
"Risk mitigation analysis",
"Ethical analysis of technical design choices",
"Knowledge of safety-by-design principles for autonomous systems"
],
"proeth:temporalMarker": "Present case, during risk assessment team deliberations, pre-development phase",
"proeth:withinCompetence": true,
"rdfs:label": "Explore Additional Technical Mitigation Options"
}
Description: Engineer A chose, where necessary, to propose that further study be undertaken by the manufacturer before the autonomous vehicle operating system is utilized, prioritizing thoroughness of safety validation over development speed.
Temporal Marker: Present case, prospective — to be undertaken if risk assessment reveals unresolved safety concerns, pre-deployment phase
Mental State: deliberate
Intended Outcome: Prevent premature deployment of an autonomous vehicle operating system with unresolved safety risks, ensuring that the public is not exposed to foreseeable harm from inadequately validated algorithmic harm-prioritization decisions
Fulfills Obligations:
- 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
Guided By Principles:
- Public safety paramount
- Do no harm
- Technical integrity independent of business pressures
- Precautionary principle in safety-critical system deployment
Required Capabilities:
Scenario Metadata
Pedagogical context for interactive teaching scenariosCharacter Motivation: Engineer A understood that the pressure to deploy — driven by competitive timelines, sunk development costs, and market expectations — is one of the most powerful forces that leads to premature release of unsafe systems. Where his assessment concluded that existing knowledge was insufficient to validate safety, recommending further study was the only intellectually honest and professionally responsible position, even if it was organizationally unwelcome. He prioritized the integrity of the safety validation process over the convenience of the deployment schedule.
Ethical Tension: Thoroughness of safety validation versus development velocity and competitive market pressures. There is deep tension between the engineer's epistemic humility (acknowledging what is not yet known) and organizational culture that may interpret calls for further study as indefinite delay tactics. There is also the broader societal tension between the potential benefits of autonomous vehicles (reduced accidents overall) and the risks of premature deployment before edge cases are adequately understood.
Learning Significance: Culminating teaching moment about the ethics of deployment decisions under uncertainty. Introduces students to the precautionary principle in engineering ethics and its limits. Raises the question of what constitutes 'sufficient' safety validation — a question with no clean technical answer. Also illustrates the engineer's role in shaping deployment decisions even when final authority rests with management or regulators. Connects the precedent case (additional testing recommendation) to the present case (further study before deployment) as a thematic resolution.
Stakes: Premature deployment of an autonomous vehicle system with unresolved ethical and safety questions risks public harm at scale; the manufacturer faces catastrophic liability, reputational damage, and regulatory consequences if a foreseeable failure occurs; further study delays time-to-market and may cede competitive advantage; Engineer A risks being labeled as obstructionist if the recommendation is unpopular; the broader autonomous vehicle industry's public trust is at stake if high-profile failures occur.
Decision Point: Yes - Story can branch here
- Recommend conditional deployment with monitoring — allow limited release while ongoing study continues, accepting residual risk as manageable
- Defer to regulatory bodies, arguing that if the system meets current regulatory standards, further study is not the engineer's responsibility to mandate
- Recommend deployment on schedule, documenting his reservations in an internal memo to protect himself while not formally blocking the project
Narrative Role: resolution
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Action_Propose_Further_Study_Before_Deployment",
"@type": "proeth:Action",
"proeth-scenario:alternativeActions": [
"Recommend conditional deployment with monitoring \u2014 allow limited release while ongoing study continues, accepting residual risk as manageable",
"Defer to regulatory bodies, arguing that if the system meets current regulatory standards, further study is not the engineer\u0027s responsibility to mandate",
"Recommend deployment on schedule, documenting his reservations in an internal memo to protect himself while not formally blocking the project"
],
"proeth-scenario:characterMotivation": "Engineer A understood that the pressure to deploy \u2014 driven by competitive timelines, sunk development costs, and market expectations \u2014 is one of the most powerful forces that leads to premature release of unsafe systems. Where his assessment concluded that existing knowledge was insufficient to validate safety, recommending further study was the only intellectually honest and professionally responsible position, even if it was organizationally unwelcome. He prioritized the integrity of the safety validation process over the convenience of the deployment schedule.",
"proeth-scenario:consequencesIfAlternative": [
"Conditional deployment: May be a legitimate middle-ground in some cases, but risks using real-world users as de facto test subjects without their informed consent; monitoring may not detect harm before it occurs; the \u0027condition\u0027 may be quietly dropped once deployment momentum builds.",
"Regulatory deference: Abdicates professional judgment to a compliance framework that may lag behind the actual state of the technology; current standards may not adequately address novel algorithmic ethics questions; the engineer\u0027s expertise exists precisely to identify gaps between regulatory requirements and actual safety needs.",
"Deploy with internal memo: A classic case of ethical self-protection without ethical action \u2014 the memo creates a personal record but does nothing to prevent harm; Engineer A has documented his concern while simultaneously enabling the outcome he identified as unsafe; this is professionally and morally insufficient."
],
"proeth-scenario:decisionSignificance": "Culminating teaching moment about the ethics of deployment decisions under uncertainty. Introduces students to the precautionary principle in engineering ethics and its limits. Raises the question of what constitutes \u0027sufficient\u0027 safety validation \u2014 a question with no clean technical answer. Also illustrates the engineer\u0027s role in shaping deployment decisions even when final authority rests with management or regulators. Connects the precedent case (additional testing recommendation) to the present case (further study before deployment) as a thematic resolution.",
"proeth-scenario:ethicalTension": "Thoroughness of safety validation versus development velocity and competitive market pressures. There is deep tension between the engineer\u0027s epistemic humility (acknowledging what is not yet known) and organizational culture that may interpret calls for further study as indefinite delay tactics. There is also the broader societal tension between the potential benefits of autonomous vehicles (reduced accidents overall) and the risks of premature deployment before edge cases are adequately understood.",
"proeth-scenario:isDecisionPoint": true,
"proeth-scenario:narrativeRole": "resolution",
"proeth-scenario:stakes": "Premature deployment of an autonomous vehicle system with unresolved ethical and safety questions risks public harm at scale; the manufacturer faces catastrophic liability, reputational damage, and regulatory consequences if a foreseeable failure occurs; further study delays time-to-market and may cede competitive advantage; Engineer A risks being labeled as obstructionist if the recommendation is unpopular; the broader autonomous vehicle industry\u0027s public trust is at stake if high-profile failures occur.",
"proeth:description": "Engineer A chose, where necessary, to propose that further study be undertaken by the manufacturer before the autonomous vehicle operating system is utilized, prioritizing thoroughness of safety validation over development speed.",
"proeth:foreseenUnintendedEffects": [
"Further study will delay development and increase costs for the manufacturer",
"Recommendation may be resisted or overridden by manufacturer management prioritizing time-to-market",
"Delay may cede competitive advantage to other autonomous vehicle developers",
"Further study may ultimately confirm that certain ethical tradeoffs cannot be resolved technically, requiring policy or regulatory resolution rather than engineering solutions"
],
"proeth:fulfillsObligation": [
"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"
],
"proeth:guidedByPrinciple": [
"Public safety paramount",
"Do no harm",
"Technical integrity independent of business pressures",
"Precautionary principle in safety-critical system deployment"
],
"proeth:hasAgent": "Engineer A (Professional Engineer / Consultant to Automobile Manufacturer, present case)",
"proeth:hasCompetingPriorities": {
"@type": "proeth:CompetingPriorities",
"proeth:priorityConflict": "Public safety obligation requiring further study versus manufacturer\u0027s business interest in timely deployment",
"proeth:resolutionReasoning": "Further study recommended as necessary when safety concerns remain unresolved, applying the principle from BER Case 96-4 that technical safety recommendations must be separated from business considerations; the manufacturer retains the decision-making authority but must make that decision with full knowledge of the unresolved safety concerns documented by Engineer A"
},
"proeth:hasMentalState": "deliberate",
"proeth:intendedOutcome": "Prevent premature deployment of an autonomous vehicle operating system with unresolved safety risks, ensuring that the public is not exposed to foreseeable harm from inadequately validated algorithmic harm-prioritization decisions",
"proeth:requiresCapability": [
"Safety risk assessment for autonomous systems",
"Professional judgment about adequacy of safety validation",
"Ability to communicate safety concerns and recommendations clearly to employer",
"Knowledge of autonomous vehicle safety standards and regulatory landscape",
"Professional independence and courage to recommend unpopular but necessary safety measures"
],
"proeth:temporalMarker": "Present case, prospective \u2014 to be undertaken if risk assessment reveals unresolved safety concerns, pre-deployment phase",
"proeth:withinCompetence": true,
"rdfs:label": "Propose Further Study Before Deployment"
}
Extracted Events (7)
Occurrences that trigger ethical considerations and state changesDescription: The software under development at Engineer A's company is recognized as safety-critical, meaning defects could directly cause harm or loss of life. This classification triggers heightened professional and ethical obligations.
Temporal Marker: Circa 1996, early in BER Case 96-4 timeline, prior to Engineer A's recommendation
Activates Constraints:
- SafetyCritical_Classification_Constraint
- Professional_Competence_Obligation
Scenario Metadata
Pedagogical context for interactive teaching scenariosEmotional Impact: Engineer A feels the weight of heightened responsibility; management may feel anxiety about cost and schedule implications; other team members may be uncertain about scope of obligations
- engineer_a: Professional obligations intensify; potential conflict with employer's financial interests becomes foreseeable
- software_company: Faces increased cost and timeline pressure if safety-critical standards are applied rigorously
- end_users_public: Potential beneficiaries of safer software; harmed if classification is ignored
- standards_bodies: Emerging draft standards become directly relevant to project decisions
Learning Moment: Students learn that the classification of a product as safety-critical is itself a morally significant event that reshapes the ethical landscape for engineers — it is not merely a technical label but a trigger for heightened duties.
Ethical Implications: Reveals tension between commercial timelines and safety obligations; raises questions about who defines 'safety-critical' and whether engineers must self-impose higher standards even absent regulatory mandate
- At what threshold should software be classified as safety-critical, and who bears responsibility for making that determination?
- How should an engineer respond when their employer has not formally acknowledged a safety-critical classification that the engineer believes applies?
- Does the existence of only draft (not finalized) standards reduce an engineer's obligation to follow them?
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Event_Safety-Critical_Software_Identified",
"@type": "proeth:Event",
"proeth-scenario:crisisIdentification": false,
"proeth-scenario:discussionPrompts": [
"At what threshold should software be classified as safety-critical, and who bears responsibility for making that determination?",
"How should an engineer respond when their employer has not formally acknowledged a safety-critical classification that the engineer believes applies?",
"Does the existence of only draft (not finalized) standards reduce an engineer\u0027s obligation to follow them?"
],
"proeth-scenario:dramaticTension": "medium",
"proeth-scenario:emotionalImpact": "Engineer A feels the weight of heightened responsibility; management may feel anxiety about cost and schedule implications; other team members may be uncertain about scope of obligations",
"proeth-scenario:ethicalImplications": "Reveals tension between commercial timelines and safety obligations; raises questions about who defines \u0027safety-critical\u0027 and whether engineers must self-impose higher standards even absent regulatory mandate",
"proeth-scenario:learningMoment": "Students learn that the classification of a product as safety-critical is itself a morally significant event that reshapes the ethical landscape for engineers \u2014 it is not merely a technical label but a trigger for heightened duties.",
"proeth-scenario:narrativePacing": "slow_burn",
"proeth-scenario:stakeholderConsequences": {
"end_users_public": "Potential beneficiaries of safer software; harmed if classification is ignored",
"engineer_a": "Professional obligations intensify; potential conflict with employer\u0027s financial interests becomes foreseeable",
"software_company": "Faces increased cost and timeline pressure if safety-critical standards are applied rigorously",
"standards_bodies": "Emerging draft standards become directly relevant to project decisions"
},
"proeth:activatesConstraint": [
"SafetyCritical_Classification_Constraint",
"Professional_Competence_Obligation"
],
"proeth:causesStateChange": "Software project re-categorized as safety-critical; professional obligations of Engineer A escalate; financial and schedule pressures now in tension with safety duties",
"proeth:createsObligation": [
"Conduct_Adequate_Safety_Testing",
"Disclose_Risks_To_Employer",
"Engage_Applicable_Standards"
],
"proeth:description": "The software under development at Engineer A\u0027s company is recognized as safety-critical, meaning defects could directly cause harm or loss of life. This classification triggers heightened professional and ethical obligations.",
"proeth:emergencyStatus": "high",
"proeth:eventType": "exogenous",
"proeth:temporalMarker": "Circa 1996, early in BER Case 96-4 timeline, prior to Engineer A\u0027s recommendation",
"proeth:urgencyLevel": "high",
"rdfs:label": "Safety-Critical Software Identified"
}
Description: Relevant draft standards for safety-critical software are published or circulated during the period of development, creating an evolving regulatory and professional context that Engineer A must navigate without the clarity of finalized rules.
Temporal Marker: Circa 1996, concurrent with BER Case 96-4 development phase
Activates Constraints:
- Emerging_Standards_Awareness_Constraint
- Professional_Competence_Obligation
Scenario Metadata
Pedagogical context for interactive teaching scenariosEmotional Impact: Engineer A experiences uncertainty and professional pressure; management may feel frustration at moving goalposts; standards bodies may be unaware of real-world timing conflicts their drafts create
- engineer_a: Must navigate ambiguity between current practice and anticipated future standards; professional judgment under scrutiny
- software_company: Faces uncertain compliance costs; may resist applying draft standards to avoid premature expense
- regulatory_bodies: Draft standards create real-world effects even before finalization
- public: Protection gaps exist during the period between recognized need and finalized standards
Learning Moment: Engineers must engage with evolving standards even when not yet mandatory; the precautionary principle suggests that known emerging requirements should inform current practice, especially in safety-critical domains.
Ethical Implications: Exposes the gap between legal compliance and ethical obligation; raises questions about whether engineers should lead or follow regulatory development; highlights the precautionary principle as a professional norm
- Should engineers be obligated to follow draft standards that have not yet been formally adopted? Why or why not?
- How does the existence of draft standards affect an engineer's defense if harm occurs before those standards are finalized?
- What is the ethical difference between 'not yet required' and 'not yet known to be necessary'?
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Event_Draft_Safety_Standards_Emerge",
"@type": "proeth:Event",
"proeth-scenario:crisisIdentification": false,
"proeth-scenario:discussionPrompts": [
"Should engineers be obligated to follow draft standards that have not yet been formally adopted? Why or why not?",
"How does the existence of draft standards affect an engineer\u0027s defense if harm occurs before those standards are finalized?",
"What is the ethical difference between \u0027not yet required\u0027 and \u0027not yet known to be necessary\u0027?"
],
"proeth-scenario:dramaticTension": "medium",
"proeth-scenario:emotionalImpact": "Engineer A experiences uncertainty and professional pressure; management may feel frustration at moving goalposts; standards bodies may be unaware of real-world timing conflicts their drafts create",
"proeth-scenario:ethicalImplications": "Exposes the gap between legal compliance and ethical obligation; raises questions about whether engineers should lead or follow regulatory development; highlights the precautionary principle as a professional norm",
"proeth-scenario:learningMoment": "Engineers must engage with evolving standards even when not yet mandatory; the precautionary principle suggests that known emerging requirements should inform current practice, especially in safety-critical domains.",
"proeth-scenario:narrativePacing": "slow_burn",
"proeth-scenario:stakeholderConsequences": {
"engineer_a": "Must navigate ambiguity between current practice and anticipated future standards; professional judgment under scrutiny",
"public": "Protection gaps exist during the period between recognized need and finalized standards",
"regulatory_bodies": "Draft standards create real-world effects even before finalization",
"software_company": "Faces uncertain compliance costs; may resist applying draft standards to avoid premature expense"
},
"proeth:activatesConstraint": [
"Emerging_Standards_Awareness_Constraint",
"Professional_Competence_Obligation"
],
"proeth:causesStateChange": "Regulatory ambiguity introduced; Engineer A must exercise professional judgment in absence of finalized guidance; employer\u0027s financial calculations complicated by uncertain compliance requirements",
"proeth:createsObligation": [
"Monitor_Evolving_Standards",
"Apply_Best_Available_Knowledge",
"Disclose_Standards_Uncertainty_To_Employer"
],
"proeth:description": "Relevant draft standards for safety-critical software are published or circulated during the period of development, creating an evolving regulatory and professional context that Engineer A must navigate without the clarity of finalized rules.",
"proeth:emergencyStatus": "high",
"proeth:eventType": "exogenous",
"proeth:temporalMarker": "Circa 1996, concurrent with BER Case 96-4 development phase",
"proeth:urgencyLevel": "medium",
"rdfs:label": "Draft Safety Standards Emerge"
}
Description: Business and financial pressures within the software company create institutional resistance to additional safety testing, placing Engineer A in direct conflict between employer interests and professional safety obligations.
Temporal Marker: Circa 1996, during BER Case 96-4, prior to Engineer A's recommendation
Activates Constraints:
- PublicSafety_Paramount
- Conflict_Of_Interest_Constraint
- Employer_Loyalty_vs_Safety_Tension
Scenario Metadata
Pedagogical context for interactive teaching scenariosEmotional Impact: Engineer A feels professionally isolated and morally conflicted; management feels defensive about cost decisions; team members may feel caught between loyalty to employer and professional ethics
- engineer_a: Professional integrity challenged; risk of retaliation if safety concerns are escalated
- software_company: Short-term financial benefit at potential long-term legal and reputational risk
- public: Exposed to increased risk if financial pressure results in inadequate testing
- engineering_profession: Precedent set for how financial pressures are handled in safety-critical contexts
Learning Moment: This event illustrates the classic ethics case structure: a professional faces institutional pressure to compromise safety for financial benefit. Students must recognize that financial pressure is never an ethically valid reason to reduce safety-critical testing.
Ethical Implications: Reveals the structural vulnerability of engineers embedded in commercial organizations; tests the limits of employer loyalty; demonstrates why engineering codes of ethics prioritize public safety over employer interests
- When an employer's financial interests conflict with public safety, what options does an engineer have beyond simply complying or resigning?
- How should Engineer A document and communicate safety concerns to protect both the public and their own professional standing?
- Is there a point at which financial pressure on safety decisions becomes an ethical violation by management, not just an ethical dilemma for the engineer?
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Event_Financial_Pressure_on_Testing",
"@type": "proeth:Event",
"proeth-scenario:crisisIdentification": true,
"proeth-scenario:discussionPrompts": [
"When an employer\u0027s financial interests conflict with public safety, what options does an engineer have beyond simply complying or resigning?",
"How should Engineer A document and communicate safety concerns to protect both the public and their own professional standing?",
"Is there a point at which financial pressure on safety decisions becomes an ethical violation by management, not just an ethical dilemma for the engineer?"
],
"proeth-scenario:dramaticTension": "high",
"proeth-scenario:emotionalImpact": "Engineer A feels professionally isolated and morally conflicted; management feels defensive about cost decisions; team members may feel caught between loyalty to employer and professional ethics",
"proeth-scenario:ethicalImplications": "Reveals the structural vulnerability of engineers embedded in commercial organizations; tests the limits of employer loyalty; demonstrates why engineering codes of ethics prioritize public safety over employer interests",
"proeth-scenario:learningMoment": "This event illustrates the classic ethics case structure: a professional faces institutional pressure to compromise safety for financial benefit. Students must recognize that financial pressure is never an ethically valid reason to reduce safety-critical testing.",
"proeth-scenario:narrativePacing": "escalation",
"proeth-scenario:stakeholderConsequences": {
"engineer_a": "Professional integrity challenged; risk of retaliation if safety concerns are escalated",
"engineering_profession": "Precedent set for how financial pressures are handled in safety-critical contexts",
"public": "Exposed to increased risk if financial pressure results in inadequate testing",
"software_company": "Short-term financial benefit at potential long-term legal and reputational risk"
},
"proeth:activatesConstraint": [
"PublicSafety_Paramount",
"Conflict_Of_Interest_Constraint",
"Employer_Loyalty_vs_Safety_Tension"
],
"proeth:causesStateChange": "Ethical conflict crystallized between professional safety duties and employer financial interests; Engineer A\u0027s independence and integrity placed under institutional pressure",
"proeth:createsObligation": [
"Clearly_Communicate_Safety_Risks_To_Management",
"Document_Safety_Concerns_Formally",
"Refuse_To_Endorse_Unsafe_Shortcuts"
],
"proeth:description": "Business and financial pressures within the software company create institutional resistance to additional safety testing, placing Engineer A in direct conflict between employer interests and professional safety obligations.",
"proeth:emergencyStatus": "high",
"proeth:eventType": "exogenous",
"proeth:temporalMarker": "Circa 1996, during BER Case 96-4, prior to Engineer A\u0027s recommendation",
"proeth:urgencyLevel": "high",
"rdfs:label": "Financial Pressure on Testing"
}
Description: An automobile manufacturer begins early development and assessment of an autonomous vehicle operating system, creating a new safety-critical engineering context that requires prospective ethical analysis before deployment.
Temporal Marker: Present case, early development/assessment phase
Activates Constraints:
- SafetyCritical_Classification_Constraint
- Prospective_Risk_Assessment_Obligation
- PublicSafety_Paramount
Scenario Metadata
Pedagogical context for interactive teaching scenariosEmotional Impact: Engineer A may feel both excitement about cutting-edge technology and apprehension about the ethical complexity ahead; manufacturer stakeholders feel competitive pressure and optimism; public remains largely unaware of decisions being made on their behalf
- engineer_a: Enters a novel ethical domain with fewer established precedents; carries lessons from BER Case 96-4 into new context
- automobile_manufacturer: Assumes significant legal and ethical responsibility for algorithmic decisions embedded in product
- future_av_users: Will be subject to decisions made during this development phase without their direct input
- general_public: Road users who are not AV passengers will also be affected by AV crash-priority algorithms
- regulatory_bodies: AV regulation still evolving, creating familiar pattern of standards lag
Learning Moment: AV development represents a paradigm shift: ethical decisions are now embedded in algorithms before deployment, making prospective ethical analysis a core engineering responsibility rather than an afterthought.
Ethical Implications: Raises questions about algorithmic moral agency, democratic legitimacy of embedded ethical choices, and whether engineers can or should make life-and-death decisions on behalf of society through design
- How does the prospective nature of AV ethical dilemmas differ from traditional post-design safety reviews, and what new obligations does this create?
- Who should have a voice in deciding how an AV algorithm prioritizes harm in unavoidable crash scenarios?
- What lessons from BER Case 96-4 are directly applicable to the AV development context, and where do the analogies break down?
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Event_Autonomous_Vehicle_AV_OS_Development_Initiated",
"@type": "proeth:Event",
"proeth-scenario:crisisIdentification": false,
"proeth-scenario:discussionPrompts": [
"How does the prospective nature of AV ethical dilemmas differ from traditional post-design safety reviews, and what new obligations does this create?",
"Who should have a voice in deciding how an AV algorithm prioritizes harm in unavoidable crash scenarios?",
"What lessons from BER Case 96-4 are directly applicable to the AV development context, and where do the analogies break down?"
],
"proeth-scenario:dramaticTension": "medium",
"proeth-scenario:emotionalImpact": "Engineer A may feel both excitement about cutting-edge technology and apprehension about the ethical complexity ahead; manufacturer stakeholders feel competitive pressure and optimism; public remains largely unaware of decisions being made on their behalf",
"proeth-scenario:ethicalImplications": "Raises questions about algorithmic moral agency, democratic legitimacy of embedded ethical choices, and whether engineers can or should make life-and-death decisions on behalf of society through design",
"proeth-scenario:learningMoment": "AV development represents a paradigm shift: ethical decisions are now embedded in algorithms before deployment, making prospective ethical analysis a core engineering responsibility rather than an afterthought.",
"proeth-scenario:narrativePacing": "slow_burn",
"proeth-scenario:stakeholderConsequences": {
"automobile_manufacturer": "Assumes significant legal and ethical responsibility for algorithmic decisions embedded in product",
"engineer_a": "Enters a novel ethical domain with fewer established precedents; carries lessons from BER Case 96-4 into new context",
"future_av_users": "Will be subject to decisions made during this development phase without their direct input",
"general_public": "Road users who are not AV passengers will also be affected by AV crash-priority algorithms",
"regulatory_bodies": "AV regulation still evolving, creating familiar pattern of standards lag"
},
"proeth:activatesConstraint": [
"SafetyCritical_Classification_Constraint",
"Prospective_Risk_Assessment_Obligation",
"PublicSafety_Paramount"
],
"proeth:causesStateChange": "New safety-critical project initiated; ethical obligations arise at design stage rather than post-design; Engineer A\u0027s role shifts to prospective risk assessment",
"proeth:createsObligation": [
"Conduct_Comprehensive_Risk_Assessment",
"Identify_Ethical_Dilemmas_In_Design",
"Engage_Multidisciplinary_Review"
],
"proeth:description": "An automobile manufacturer begins early development and assessment of an autonomous vehicle operating system, creating a new safety-critical engineering context that requires prospective ethical analysis before deployment.",
"proeth:emergencyStatus": "high",
"proeth:eventType": "exogenous",
"proeth:temporalMarker": "Present case, early development/assessment phase",
"proeth:urgencyLevel": "medium",
"rdfs:label": "Autonomous Vehicle AV OS Development Initiated"
}
Description: During risk assessment, the team identifies that the AV operating system will inevitably encounter crash scenarios where harm to some party is unavoidable, requiring the software to encode a priority ordering of harm outcomes — a fundamentally ethical decision embedded in code.
Temporal Marker: Present case, during risk assessment phase, prior to deployment
Activates Constraints:
- Algorithmic_Ethics_Constraint
- PublicSafety_Paramount
- Informed_Consent_Consideration
- Transparency_In_Design_Constraint
Scenario Metadata
Pedagogical context for interactive teaching scenariosEmotional Impact: Engineer A may feel moral vertigo at being asked to encode life-and-death decisions; team members may feel discomfort or denial; manufacturer leadership may feel exposed to liability; ethicists and philosophers may feel their domain has been invaded by engineers
- engineer_a: Faces the most acute ethical dilemma of the case — must advocate for resolution before deployment, not after
- automobile_manufacturer: Faces potential legal liability for any priority ordering chosen; also faces liability for not choosing
- av_passengers: Will be subject to algorithm without necessarily knowing its priority logic
- pedestrians_other_road_users: May be deprioritized by algorithm without consent or knowledge
- society: Fundamental question raised about who has authority to make collective life-and-death decisions
Learning Moment: The identification of unavoidable crash scenarios is the ethical core of the AV case. Students must understand that encoding a priority ordering is itself a moral act — there is no neutral or purely technical solution. The engineer's obligation is to surface this, not resolve it unilaterally.
Ethical Implications: Exposes the limits of purely technical solutions to ethical problems; raises questions of democratic legitimacy, informed consent, and distributive justice in algorithmic systems; challenges the boundary between engineering design and moral philosophy
- Is it ethically permissible for engineers to encode moral priority orderings in AV software without broader public deliberation? Why or why not?
- If no priority ordering is ethically defensible to all stakeholders, does that mean AV deployment should be halted until societal consensus is reached?
- How does the embedded, pre-programmed nature of AV ethical decisions differ morally from split-second human driver decisions in the same scenario?
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Event_Unavoidable_Crash_Scenario_Identified",
"@type": "proeth:Event",
"proeth-scenario:crisisIdentification": true,
"proeth-scenario:discussionPrompts": [
"Is it ethically permissible for engineers to encode moral priority orderings in AV software without broader public deliberation? Why or why not?",
"If no priority ordering is ethically defensible to all stakeholders, does that mean AV deployment should be halted until societal consensus is reached?",
"How does the embedded, pre-programmed nature of AV ethical decisions differ morally from split-second human driver decisions in the same scenario?"
],
"proeth-scenario:dramaticTension": "high",
"proeth-scenario:emotionalImpact": "Engineer A may feel moral vertigo at being asked to encode life-and-death decisions; team members may feel discomfort or denial; manufacturer leadership may feel exposed to liability; ethicists and philosophers may feel their domain has been invaded by engineers",
"proeth-scenario:ethicalImplications": "Exposes the limits of purely technical solutions to ethical problems; raises questions of democratic legitimacy, informed consent, and distributive justice in algorithmic systems; challenges the boundary between engineering design and moral philosophy",
"proeth-scenario:learningMoment": "The identification of unavoidable crash scenarios is the ethical core of the AV case. Students must understand that encoding a priority ordering is itself a moral act \u2014 there is no neutral or purely technical solution. The engineer\u0027s obligation is to surface this, not resolve it unilaterally.",
"proeth-scenario:narrativePacing": "crisis",
"proeth-scenario:stakeholderConsequences": {
"automobile_manufacturer": "Faces potential legal liability for any priority ordering chosen; also faces liability for not choosing",
"av_passengers": "Will be subject to algorithm without necessarily knowing its priority logic",
"engineer_a": "Faces the most acute ethical dilemma of the case \u2014 must advocate for resolution before deployment, not after",
"pedestrians_other_road_users": "May be deprioritized by algorithm without consent or knowledge",
"society": "Fundamental question raised about who has authority to make collective life-and-death decisions"
},
"proeth:activatesConstraint": [
"Algorithmic_Ethics_Constraint",
"PublicSafety_Paramount",
"Informed_Consent_Consideration",
"Transparency_In_Design_Constraint"
],
"proeth:causedByAction": "http://proethica.org/cases/165#Action_Actively_Participate_in_Risk_Assessment",
"proeth:causesStateChange": "Risk assessment moves from technical to ethical domain; design decisions now carry explicit moral weight; Engineer A\u0027s role expands beyond technical risk to ethical advocacy",
"proeth:createsObligation": [
"Formally_Document_Ethical_Dilemma",
"Seek_Multidisciplinary_Input",
"Propose_Deferral_If_Unresolved",
"Disclose_Dilemma_To_Manufacturer_Leadership"
],
"proeth:description": "During risk assessment, the team identifies that the AV operating system will inevitably encounter crash scenarios where harm to some party is unavoidable, requiring the software to encode a priority ordering of harm outcomes \u2014 a fundamentally ethical decision embedded in code.",
"proeth:emergencyStatus": "critical",
"proeth:eventType": "automatic_trigger",
"proeth:temporalMarker": "Present case, during risk assessment phase, prior to deployment",
"proeth:urgencyLevel": "critical",
"rdfs:label": "Unavoidable Crash Scenario Identified"
}
Description: The ethical principles established in BER Case 96-4 — specifically regarding the primacy of public safety over financial considerations and the obligation to recommend additional scrutiny when safety is uncertain — become directly applicable to the present AV case, creating a normative bridge between the two scenarios.
Temporal Marker: Present case, at the point when Engineer A's role in AV risk assessment begins
Activates Constraints:
- Precedent_Informed_Professional_Judgment
- Consistency_Of_Ethical_Standards_Constraint
Scenario Metadata
Pedagogical context for interactive teaching scenariosEmotional Impact: Engineer A may feel the weight of consistency — prior ethical stances create expectations; students observing the case may feel the satisfaction of seeing ethical principles applied across contexts; there may also be tension if the present case is more complex than the precedent
- engineer_a: Prior ethical positions create professional accountability; cannot easily retreat from safety-first stance without reputational and ethical cost
- automobile_manufacturer: Benefits from Engineer A's established track record of principled safety advocacy
- engineering_profession: Demonstrates that ethical principles have durability across technological generations
- students_observers: See that ethical reasoning is cumulative and consistent, not situationally convenient
Learning Moment: Ethical principles established in one case carry forward as normative constraints in analogous future cases. Professional integrity requires consistency — an engineer cannot advocate for safety-first in one context and financial pragmatism in another without justification.
Ethical Implications: Illustrates the principle of ethical consistency and the cumulative nature of professional moral commitments; raises questions about whether precedent-based reasoning in ethics is analogous to legal precedent and whether it should be
- To what extent should prior ethical decisions in one case constrain an engineer's options in a later, structurally similar case?
- Are there morally relevant differences between the BER Case 96-4 context and the AV case that might justify different ethical conclusions?
- How does the evolution from reactive (post-design) to prospective (pre-design) ethical analysis change the nature of the engineer's obligations?
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Event_Precedent_Case_Principles_Activated",
"@type": "proeth:Event",
"proeth-scenario:crisisIdentification": false,
"proeth-scenario:discussionPrompts": [
"To what extent should prior ethical decisions in one case constrain an engineer\u0027s options in a later, structurally similar case?",
"Are there morally relevant differences between the BER Case 96-4 context and the AV case that might justify different ethical conclusions?",
"How does the evolution from reactive (post-design) to prospective (pre-design) ethical analysis change the nature of the engineer\u0027s obligations?"
],
"proeth-scenario:dramaticTension": "low",
"proeth-scenario:emotionalImpact": "Engineer A may feel the weight of consistency \u2014 prior ethical stances create expectations; students observing the case may feel the satisfaction of seeing ethical principles applied across contexts; there may also be tension if the present case is more complex than the precedent",
"proeth-scenario:ethicalImplications": "Illustrates the principle of ethical consistency and the cumulative nature of professional moral commitments; raises questions about whether precedent-based reasoning in ethics is analogous to legal precedent and whether it should be",
"proeth-scenario:learningMoment": "Ethical principles established in one case carry forward as normative constraints in analogous future cases. Professional integrity requires consistency \u2014 an engineer cannot advocate for safety-first in one context and financial pragmatism in another without justification.",
"proeth-scenario:narrativePacing": "slow_burn",
"proeth-scenario:stakeholderConsequences": {
"automobile_manufacturer": "Benefits from Engineer A\u0027s established track record of principled safety advocacy",
"engineer_a": "Prior ethical positions create professional accountability; cannot easily retreat from safety-first stance without reputational and ethical cost",
"engineering_profession": "Demonstrates that ethical principles have durability across technological generations",
"students_observers": "See that ethical reasoning is cumulative and consistent, not situationally convenient"
},
"proeth:activatesConstraint": [
"Precedent_Informed_Professional_Judgment",
"Consistency_Of_Ethical_Standards_Constraint"
],
"proeth:causedByAction": "http://proethica.org/cases/165#Action_Actively_Participate_in_Risk_Assessment",
"proeth:causesStateChange": "Engineer A\u0027s professional conduct in the present case is now normatively constrained by the precedent established in BER Case 96-4; deviation from those principles would constitute ethical inconsistency",
"proeth:createsObligation": [
"Apply_BER_96_4_Principles_To_Present_Case",
"Maintain_Consistency_Between_Past_And_Present_Ethical_Positions"
],
"proeth:description": "The ethical principles established in BER Case 96-4 \u2014 specifically regarding the primacy of public safety over financial considerations and the obligation to recommend additional scrutiny when safety is uncertain \u2014 become directly applicable to the present AV case, creating a normative bridge between the two scenarios.",
"proeth:emergencyStatus": "high",
"proeth:eventType": "automatic_trigger",
"proeth:temporalMarker": "Present case, at the point when Engineer A\u0027s role in AV risk assessment begins",
"proeth:urgencyLevel": "medium",
"rdfs:label": "Precedent Case Principles Activated"
}
Description: The risk assessment process reveals that existing engineering ethics frameworks, professional codes, and technical standards do not provide clear, actionable guidance for encoding moral priority orderings in autonomous vehicle software — creating a normative vacuum at the precise moment design decisions must be made.
Temporal Marker: Present case, during risk assessment phase
Activates Constraints:
- Precautionary_Principle_Constraint
- Duty_To_Seek_Expert_Consultation
- PublicSafety_Paramount
Scenario Metadata
Pedagogical context for interactive teaching scenariosEmotional Impact: Engineer A may feel professionally stranded — trained to apply standards that don't exist for this problem; team may feel frustrated or anxious; manufacturer may feel exposed; ethicists may feel vindicated that their discipline is needed
- engineer_a: Must exercise independent professional judgment in absence of clear guidance — highest-risk professional position
- automobile_manufacturer: Cannot rely on standards compliance as ethical defense; must make substantive moral choices
- standards_bodies: Implicitly called upon to develop new frameworks urgently
- public_policymakers: Gap reveals need for regulatory intervention before widespread AV deployment
- public: Exposed to products making life-and-death decisions without adequate ethical oversight
Learning Moment: When established frameworks are insufficient, engineers must recognize the gap rather than paper over it with pseudo-technical solutions. The appropriate response is escalation, consultation, and — if necessary — recommending delay, not unilateral resolution.
Ethical Implications: Reveals the limits of code-based professional ethics in rapidly evolving technological domains; raises questions about the relationship between engineering ethics and broader moral philosophy; demonstrates why interdisciplinary collaboration is an ethical requirement, not merely a best practice
- When professional codes and standards are silent on a novel ethical dilemma, what sources of moral guidance should engineers turn to?
- Is it ever appropriate for an engineer to deploy a system whose ethical implications cannot be fully resolved by existing frameworks? Under what conditions?
- What responsibility do individual engineers have for advocating to standards bodies when they identify normative gaps in their domain?
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"proeth-scenario": "http://proethica.org/ontology/scenario#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#",
"time": "http://www.w3.org/2006/time#"
},
"@id": "http://proethica.org/cases/165#Event_Algorithmic_Ethics_Gap_Recognized",
"@type": "proeth:Event",
"proeth-scenario:crisisIdentification": true,
"proeth-scenario:discussionPrompts": [
"When professional codes and standards are silent on a novel ethical dilemma, what sources of moral guidance should engineers turn to?",
"Is it ever appropriate for an engineer to deploy a system whose ethical implications cannot be fully resolved by existing frameworks? Under what conditions?",
"What responsibility do individual engineers have for advocating to standards bodies when they identify normative gaps in their domain?"
],
"proeth-scenario:dramaticTension": "high",
"proeth-scenario:emotionalImpact": "Engineer A may feel professionally stranded \u2014 trained to apply standards that don\u0027t exist for this problem; team may feel frustrated or anxious; manufacturer may feel exposed; ethicists may feel vindicated that their discipline is needed",
"proeth-scenario:ethicalImplications": "Reveals the limits of code-based professional ethics in rapidly evolving technological domains; raises questions about the relationship between engineering ethics and broader moral philosophy; demonstrates why interdisciplinary collaboration is an ethical requirement, not merely a best practice",
"proeth-scenario:learningMoment": "When established frameworks are insufficient, engineers must recognize the gap rather than paper over it with pseudo-technical solutions. The appropriate response is escalation, consultation, and \u2014 if necessary \u2014 recommending delay, not unilateral resolution.",
"proeth-scenario:narrativePacing": "escalation",
"proeth-scenario:stakeholderConsequences": {
"automobile_manufacturer": "Cannot rely on standards compliance as ethical defense; must make substantive moral choices",
"engineer_a": "Must exercise independent professional judgment in absence of clear guidance \u2014 highest-risk professional position",
"public": "Exposed to products making life-and-death decisions without adequate ethical oversight",
"public_policymakers": "Gap reveals need for regulatory intervention before widespread AV deployment",
"standards_bodies": "Implicitly called upon to develop new frameworks urgently"
},
"proeth:activatesConstraint": [
"Precautionary_Principle_Constraint",
"Duty_To_Seek_Expert_Consultation",
"PublicSafety_Paramount"
],
"proeth:causedByAction": "http://proethica.org/cases/165#Action_Actively_Participate_in_Risk_Assessment",
"proeth:causesStateChange": "Engineering team cannot resolve ethical dilemma through technical means alone; problem must be escalated beyond engineering domain; deployment timeline potentially affected",
"proeth:createsObligation": [
"Recommend_Multidisciplinary_Ethics_Review",
"Propose_Deployment_Deferral_Until_Resolved",
"Document_Gap_For_Standards_Bodies"
],
"proeth:description": "The risk assessment process reveals that existing engineering ethics frameworks, professional codes, and technical standards do not provide clear, actionable guidance for encoding moral priority orderings in autonomous vehicle software \u2014 creating a normative vacuum at the precise moment design decisions must be made.",
"proeth:emergencyStatus": "high",
"proeth:eventType": "outcome",
"proeth:temporalMarker": "Present case, during risk assessment phase",
"proeth:urgencyLevel": "high",
"rdfs:label": "Algorithmic Ethics Gap Recognized"
}
Causal Chains (5)
NESS test analysis: Necessary Element of Sufficient SetCausal Language: The software under development is recognized as safety-critical, meaning defects could cause serious harm — this recognition directly motivates Engineer A to recommend costly additional software testing despite institutional resistance
Necessary Factors (NESS):
- Recognition that software failures could cause serious harm or death
- Engineer A's awareness of the safety-critical classification
- Engineer A's professional obligation to prioritize public safety
- Existence of financial pressure creating a context requiring deliberate ethical choice
Sufficient Factors:
- Safety-critical classification + Engineer A's professional ethics awareness + financial pressure context = sufficient to trigger recommendation for additional testing
- The combination of known risk severity and professional duty created an ethical imperative that overrode institutional resistance
Responsibility Attribution:
Agent: Engineer A
Type: direct
Within Agent Control:
Yes
Causal Sequence:
-
Autonomous Vehicle AV OS Development Initiated (Event 4)
Automobile manufacturer begins AV operating system development, creating the engineering context in which safety-critical software is produced -
Safety-Critical Software Identified (Event 1)
The AV OS software is formally recognized as safety-critical, establishing the high-stakes nature of any defects or failures -
Financial Pressure on Testing (Event 3)
Business pressures create institutional resistance to additional testing, forcing Engineer A into an ethical decision point -
Recommend Additional Safety Testing (Action 1)
Engineer A, despite financial resistance, chooses to formally recommend additional software testing to protect public safety -
Prepare Transparent Technical Report (Action 2)
Engineer A documents the testing analysis and recommendations, creating an accountable record of the safety-critical findings
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#"
},
"@id": "http://proethica.org/cases/165#CausalChain_21c2280c",
"@type": "proeth:CausalChain",
"proeth:causalLanguage": "The software under development is recognized as safety-critical, meaning defects could cause serious harm \u2014 this recognition directly motivates Engineer A to recommend costly additional software testing despite institutional resistance",
"proeth:causalSequence": [
{
"proeth:description": "Automobile manufacturer begins AV operating system development, creating the engineering context in which safety-critical software is produced",
"proeth:element": "Autonomous Vehicle AV OS Development Initiated (Event 4)",
"proeth:step": 1
},
{
"proeth:description": "The AV OS software is formally recognized as safety-critical, establishing the high-stakes nature of any defects or failures",
"proeth:element": "Safety-Critical Software Identified (Event 1)",
"proeth:step": 2
},
{
"proeth:description": "Business pressures create institutional resistance to additional testing, forcing Engineer A into an ethical decision point",
"proeth:element": "Financial Pressure on Testing (Event 3)",
"proeth:step": 3
},
{
"proeth:description": "Engineer A, despite financial resistance, chooses to formally recommend additional software testing to protect public safety",
"proeth:element": "Recommend Additional Safety Testing (Action 1)",
"proeth:step": 4
},
{
"proeth:description": "Engineer A documents the testing analysis and recommendations, creating an accountable record of the safety-critical findings",
"proeth:element": "Prepare Transparent Technical Report (Action 2)",
"proeth:step": 5
}
],
"proeth:cause": "Safety-Critical Software Identified (Event 1)",
"proeth:counterfactual": "Without the safety-critical classification, additional testing would likely not have been recommended \u2014 standard testing protocols would have been deemed sufficient, and financial pressure would have prevailed",
"proeth:effect": "Recommend Additional Safety Testing (Action 1)",
"proeth:necessaryFactors": [
"Recognition that software failures could cause serious harm or death",
"Engineer A\u0027s awareness of the safety-critical classification",
"Engineer A\u0027s professional obligation to prioritize public safety",
"Existence of financial pressure creating a context requiring deliberate ethical choice"
],
"proeth:responsibilityType": "direct",
"proeth:responsibleAgent": "Engineer A",
"proeth:sufficientFactors": [
"Safety-critical classification + Engineer A\u0027s professional ethics awareness + financial pressure context = sufficient to trigger recommendation for additional testing",
"The combination of known risk severity and professional duty created an ethical imperative that overrode institutional resistance"
],
"proeth:withinAgentControl": true
}
Causal Language: During risk assessment, the team identifies that the AV operating system will inevitably encounter crash scenarios — this discovery reveals that existing engineering ethics frameworks and professional codes do not adequately address the algorithmic decision-making required in life-or-death situations
Necessary Factors (NESS):
- Active participation in risk assessment revealing the unavoidable crash scenario
- The genuine novelty of autonomous algorithmic decision-making in life-or-death contexts
- Existing ethics frameworks predating autonomous vehicle technology
- Engineer A's engagement deep enough to recognize the gap between existing codes and new requirements
Sufficient Factors:
- Identification of unavoidable crash scenario + existing framework inadequacy + active ethical reflection by Engineer A = sufficient to surface the algorithmic ethics gap
- The scenario's moral complexity (choosing between harm outcomes) exposed the limits of traditional engineering ethics codes
Responsibility Attribution:
Agent: Engineer A (primary); Risk Assessment Team (shared)
Type: shared
Within Agent Control:
Yes
Causal Sequence:
-
Autonomous Vehicle AV OS Development Initiated (Event 4)
AV OS development creates the technical context in which novel ethical dilemmas will emerge -
Actively Participate in Risk Assessment (Action 3)
Engineer A fully engages with the risk assessment team, creating the conditions under which the unavoidable crash scenario is surfaced and analyzed -
Unavoidable Crash Scenario Identified (Event 5)
Risk assessment reveals the AV OS will inevitably face scenarios requiring algorithmic choices between harmful outcomes -
Precedent Case Principles Activated (Event 6)
BER Case 96-4 principles are invoked, but their application reveals they do not fully resolve the algorithmic decision-making dilemma -
Algorithmic Ethics Gap Recognized (Event 7)
The risk assessment process conclusively surfaces that existing engineering ethics frameworks are inadequate for autonomous algorithmic life-or-death decisions
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#"
},
"@id": "http://proethica.org/cases/165#CausalChain_0a1b500e",
"@type": "proeth:CausalChain",
"proeth:causalLanguage": "During risk assessment, the team identifies that the AV operating system will inevitably encounter crash scenarios \u2014 this discovery reveals that existing engineering ethics frameworks and professional codes do not adequately address the algorithmic decision-making required in life-or-death situations",
"proeth:causalSequence": [
{
"proeth:description": "AV OS development creates the technical context in which novel ethical dilemmas will emerge",
"proeth:element": "Autonomous Vehicle AV OS Development Initiated (Event 4)",
"proeth:step": 1
},
{
"proeth:description": "Engineer A fully engages with the risk assessment team, creating the conditions under which the unavoidable crash scenario is surfaced and analyzed",
"proeth:element": "Actively Participate in Risk Assessment (Action 3)",
"proeth:step": 2
},
{
"proeth:description": "Risk assessment reveals the AV OS will inevitably face scenarios requiring algorithmic choices between harmful outcomes",
"proeth:element": "Unavoidable Crash Scenario Identified (Event 5)",
"proeth:step": 3
},
{
"proeth:description": "BER Case 96-4 principles are invoked, but their application reveals they do not fully resolve the algorithmic decision-making dilemma",
"proeth:element": "Precedent Case Principles Activated (Event 6)",
"proeth:step": 4
},
{
"proeth:description": "The risk assessment process conclusively surfaces that existing engineering ethics frameworks are inadequate for autonomous algorithmic life-or-death decisions",
"proeth:element": "Algorithmic Ethics Gap Recognized (Event 7)",
"proeth:step": 5
}
],
"proeth:cause": "Unavoidable Crash Scenario Identified (Event 5)",
"proeth:counterfactual": "Without identification of the unavoidable crash scenario, the ethics gap might have remained unrecognized during this development cycle; alternatively, without Engineer A\u0027s active participation, the gap might have been identified but not escalated as an ethical concern",
"proeth:effect": "Algorithmic Ethics Gap Recognized (Event 7)",
"proeth:necessaryFactors": [
"Active participation in risk assessment revealing the unavoidable crash scenario",
"The genuine novelty of autonomous algorithmic decision-making in life-or-death contexts",
"Existing ethics frameworks predating autonomous vehicle technology",
"Engineer A\u0027s engagement deep enough to recognize the gap between existing codes and new requirements"
],
"proeth:responsibilityType": "shared",
"proeth:responsibleAgent": "Engineer A (primary); Risk Assessment Team (shared)",
"proeth:sufficientFactors": [
"Identification of unavoidable crash scenario + existing framework inadequacy + active ethical reflection by Engineer A = sufficient to surface the algorithmic ethics gap",
"The scenario\u0027s moral complexity (choosing between harm outcomes) exposed the limits of traditional engineering ethics codes"
],
"proeth:withinAgentControl": true
}
Causal Language: The recognition that existing engineering ethics frameworks do not adequately address algorithmic decision-making in unavoidable crash scenarios directly necessitates Engineer A's choice to propose that further study be undertaken by the manufacturer before deployment
Necessary Factors (NESS):
- Recognition of the algorithmic ethics gap as a genuine unresolved problem
- Engineer A's professional obligation to not deploy systems with unresolved safety-critical ethical deficiencies
- The unavoidable crash scenario establishing that the gap has real-world life-or-death consequences
- Engineer A's authority and standing within the risk assessment process to make such a proposal
Sufficient Factors:
- Algorithmic ethics gap + unavoidable crash scenario with real harm potential + Engineer A's professional duty = sufficient to require proposal for further study
- The combination of identified gap and deployment risk created an ethical obligation that could not be discharged by existing frameworks alone
Responsibility Attribution:
Agent: Engineer A
Type: direct
Within Agent Control:
Yes
Causal Sequence:
-
Unavoidable Crash Scenario Identified (Event 5)
Risk assessment surfaces the scenario that will expose the ethics gap -
Algorithmic Ethics Gap Recognized (Event 7)
The team recognizes existing frameworks cannot resolve the algorithmic decision dilemma -
Unambiguously Express Safety Concerns (Action 4)
Engineer A clearly articulates the safety concerns arising from the unresolved ethics gap within the risk assessment process -
Explore Additional Technical Mitigation Options (Action 5)
Engineer A actively investigates whether technical solutions could bridge or bypass the ethics gap before concluding further study is necessary -
Propose Further Study Before Deployment (Action 6)
Finding technical mitigation insufficient, Engineer A formally proposes that the manufacturer undertake further study before deploying the AV OS
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#"
},
"@id": "http://proethica.org/cases/165#CausalChain_a328805f",
"@type": "proeth:CausalChain",
"proeth:causalLanguage": "The recognition that existing engineering ethics frameworks do not adequately address algorithmic decision-making in unavoidable crash scenarios directly necessitates Engineer A\u0027s choice to propose that further study be undertaken by the manufacturer before deployment",
"proeth:causalSequence": [
{
"proeth:description": "Risk assessment surfaces the scenario that will expose the ethics gap",
"proeth:element": "Unavoidable Crash Scenario Identified (Event 5)",
"proeth:step": 1
},
{
"proeth:description": "The team recognizes existing frameworks cannot resolve the algorithmic decision dilemma",
"proeth:element": "Algorithmic Ethics Gap Recognized (Event 7)",
"proeth:step": 2
},
{
"proeth:description": "Engineer A clearly articulates the safety concerns arising from the unresolved ethics gap within the risk assessment process",
"proeth:element": "Unambiguously Express Safety Concerns (Action 4)",
"proeth:step": 3
},
{
"proeth:description": "Engineer A actively investigates whether technical solutions could bridge or bypass the ethics gap before concluding further study is necessary",
"proeth:element": "Explore Additional Technical Mitigation Options (Action 5)",
"proeth:step": 4
},
{
"proeth:description": "Finding technical mitigation insufficient, Engineer A formally proposes that the manufacturer undertake further study before deploying the AV OS",
"proeth:element": "Propose Further Study Before Deployment (Action 6)",
"proeth:step": 5
}
],
"proeth:cause": "Algorithmic Ethics Gap Recognized (Event 7)",
"proeth:counterfactual": "If the algorithmic ethics gap had not been recognized \u2014 or if existing frameworks had been deemed adequate \u2014 Engineer A would likely not have proposed further study specifically on this dimension; standard risk mitigation would have been considered sufficient",
"proeth:effect": "Propose Further Study Before Deployment (Action 6)",
"proeth:necessaryFactors": [
"Recognition of the algorithmic ethics gap as a genuine unresolved problem",
"Engineer A\u0027s professional obligation to not deploy systems with unresolved safety-critical ethical deficiencies",
"The unavoidable crash scenario establishing that the gap has real-world life-or-death consequences",
"Engineer A\u0027s authority and standing within the risk assessment process to make such a proposal"
],
"proeth:responsibilityType": "direct",
"proeth:responsibleAgent": "Engineer A",
"proeth:sufficientFactors": [
"Algorithmic ethics gap + unavoidable crash scenario with real harm potential + Engineer A\u0027s professional duty = sufficient to require proposal for further study",
"The combination of identified gap and deployment risk created an ethical obligation that could not be discharged by existing frameworks alone"
],
"proeth:withinAgentControl": true
}
Causal Language: Business and financial pressures within the software company create institutional resistance to additional testing — this resistance makes it necessary for Engineer A to clearly and unambiguously express safety concerns, as ambiguity would allow financial interests to override safety considerations
Necessary Factors (NESS):
- Existence of institutional financial pressure creating a competing interest to safety
- Engineer A's recognition that ambiguous or soft expression of concerns would be insufficient against financial resistance
- Engineer A's professional duty under engineering ethics codes to hold public safety paramount
- The safety-critical nature of the software making silence or ambiguity professionally and ethically impermissible
Sufficient Factors:
- Financial pressure creating resistance + safety-critical stakes + professional duty = sufficient to require unambiguous expression
- The combination of institutional resistance and high-stakes safety context made clear expression not merely advisable but ethically obligatory
Responsibility Attribution:
Agent: Engineer A (for the action); Company Leadership (shared, for creating financial pressure context)
Type: direct
Within Agent Control:
Yes
Causal Sequence:
-
Safety-Critical Software Identified (Event 1)
Software is classified as safety-critical, establishing the stakes that make clear expression of concerns necessary -
Financial Pressure on Testing (Event 3)
Institutional financial resistance emerges, creating the adversarial context that demands unambiguous rather than routine expression of safety concerns -
Actively Participate in Risk Assessment (Action 3)
Engineer A's full participation in risk assessment provides the formal context and standing from which to express concerns authoritatively -
Unambiguously Express Safety Concerns (Action 4)
Engineer A deliberately chooses clarity and directness in expressing safety concerns, ensuring financial pressures cannot obscure or minimize them -
Prepare Transparent Technical Report (Action 2)
Engineer A documents concerns transparently, creating a formal record that reinforces and preserves the unambiguous expression of safety concerns
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#"
},
"@id": "http://proethica.org/cases/165#CausalChain_3c33bb10",
"@type": "proeth:CausalChain",
"proeth:causalLanguage": "Business and financial pressures within the software company create institutional resistance to additional testing \u2014 this resistance makes it necessary for Engineer A to clearly and unambiguously express safety concerns, as ambiguity would allow financial interests to override safety considerations",
"proeth:causalSequence": [
{
"proeth:description": "Software is classified as safety-critical, establishing the stakes that make clear expression of concerns necessary",
"proeth:element": "Safety-Critical Software Identified (Event 1)",
"proeth:step": 1
},
{
"proeth:description": "Institutional financial resistance emerges, creating the adversarial context that demands unambiguous rather than routine expression of safety concerns",
"proeth:element": "Financial Pressure on Testing (Event 3)",
"proeth:step": 2
},
{
"proeth:description": "Engineer A\u0027s full participation in risk assessment provides the formal context and standing from which to express concerns authoritatively",
"proeth:element": "Actively Participate in Risk Assessment (Action 3)",
"proeth:step": 3
},
{
"proeth:description": "Engineer A deliberately chooses clarity and directness in expressing safety concerns, ensuring financial pressures cannot obscure or minimize them",
"proeth:element": "Unambiguously Express Safety Concerns (Action 4)",
"proeth:step": 4
},
{
"proeth:description": "Engineer A documents concerns transparently, creating a formal record that reinforces and preserves the unambiguous expression of safety concerns",
"proeth:element": "Prepare Transparent Technical Report (Action 2)",
"proeth:step": 5
}
],
"proeth:cause": "Financial Pressure on Testing (Event 3)",
"proeth:counterfactual": "In the absence of financial pressure, safety concerns might have been expressed through normal technical channels without requiring the deliberate choice to be unambiguous; the institutional resistance is what elevates expression from routine to ethically significant action",
"proeth:effect": "Unambiguously Express Safety Concerns (Action 4)",
"proeth:necessaryFactors": [
"Existence of institutional financial pressure creating a competing interest to safety",
"Engineer A\u0027s recognition that ambiguous or soft expression of concerns would be insufficient against financial resistance",
"Engineer A\u0027s professional duty under engineering ethics codes to hold public safety paramount",
"The safety-critical nature of the software making silence or ambiguity professionally and ethically impermissible"
],
"proeth:responsibilityType": "direct",
"proeth:responsibleAgent": "Engineer A (for the action); Company Leadership (shared, for creating financial pressure context)",
"proeth:sufficientFactors": [
"Financial pressure creating resistance + safety-critical stakes + professional duty = sufficient to require unambiguous expression",
"The combination of institutional resistance and high-stakes safety context made clear expression not merely advisable but ethically obligatory"
],
"proeth:withinAgentControl": true
}
Causal Language: The ethical principles established in BER Case 96-4 — specifically regarding the primacy of public safety in engineering decision-making — are activated, providing the normative foundation that supports and directs Engineer A's active participation in risk assessment and preparation of transparent technical documentation
Necessary Factors (NESS):
- Engineer A's knowledge of and commitment to BER Case 96-4 principles
- The principles' applicability to the AV OS safety-critical context
- The risk assessment process providing a formal mechanism through which principles can be operationalized
- Engineer A's professional standing to participate meaningfully in the risk assessment
Sufficient Factors:
- Activated precedent principles + safety-critical context + formal risk assessment process = sufficient to direct Engineer A's professional conduct toward active participation and transparent documentation
- The precedent case provided both the ethical mandate (public safety primacy) and the professional model (transparent reporting) that shaped Engineer A's specific actions
Responsibility Attribution:
Agent: Engineer A
Type: direct
Within Agent Control:
Yes
Causal Sequence:
-
Autonomous Vehicle AV OS Development Initiated (Event 4)
AV OS development creates the engineering context in which established ethical precedents become relevant -
Precedent Case Principles Activated (Event 6)
BER Case 96-4 principles are recognized as applicable, establishing public safety primacy as the governing ethical framework -
Actively Participate in Risk Assessment (Action 3)
Guided by precedent principles, Engineer A chooses full rather than minimal participation, ensuring safety considerations are thoroughly surfaced -
Prepare Transparent Technical Report (Action 2)
Consistent with precedent principles of accountability and transparency, Engineer A documents findings clearly and completely -
Algorithmic Ethics Gap Recognized (Event 7)
The thorough participation and transparent documentation enabled by precedent principles ultimately surfaces the gap that existing frameworks — including the precedent case itself — cannot fully resolve
RDF JSON-LD
{
"@context": {
"proeth": "http://proethica.org/ontology/intermediate#",
"proeth-case": "http://proethica.org/cases/165#",
"rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
"rdfs": "http://www.w3.org/2000/01/rdf-schema#"
},
"@id": "http://proethica.org/cases/165#CausalChain_1ff070e3",
"@type": "proeth:CausalChain",
"proeth:causalLanguage": "The ethical principles established in BER Case 96-4 \u2014 specifically regarding the primacy of public safety in engineering decision-making \u2014 are activated, providing the normative foundation that supports and directs Engineer A\u0027s active participation in risk assessment and preparation of transparent technical documentation",
"proeth:causalSequence": [
{
"proeth:description": "AV OS development creates the engineering context in which established ethical precedents become relevant",
"proeth:element": "Autonomous Vehicle AV OS Development Initiated (Event 4)",
"proeth:step": 1
},
{
"proeth:description": "BER Case 96-4 principles are recognized as applicable, establishing public safety primacy as the governing ethical framework",
"proeth:element": "Precedent Case Principles Activated (Event 6)",
"proeth:step": 2
},
{
"proeth:description": "Guided by precedent principles, Engineer A chooses full rather than minimal participation, ensuring safety considerations are thoroughly surfaced",
"proeth:element": "Actively Participate in Risk Assessment (Action 3)",
"proeth:step": 3
},
{
"proeth:description": "Consistent with precedent principles of accountability and transparency, Engineer A documents findings clearly and completely",
"proeth:element": "Prepare Transparent Technical Report (Action 2)",
"proeth:step": 4
},
{
"proeth:description": "The thorough participation and transparent documentation enabled by precedent principles ultimately surfaces the gap that existing frameworks \u2014 including the precedent case itself \u2014 cannot fully resolve",
"proeth:element": "Algorithmic Ethics Gap Recognized (Event 7)",
"proeth:step": 5
}
],
"proeth:cause": "Precedent Case Principles Activated (Event 6)",
"proeth:counterfactual": "Without the normative grounding of BER Case 96-4 principles, Engineer A might still have participated in risk assessment, but the depth of engagement and the deliberate choice of transparency in reporting might have been less pronounced; the precedent case transforms routine professional activity into ethically directed action",
"proeth:effect": "Actively Participate in Risk Assessment (Action 3) + Prepare Transparent Technical Report (Action 2)",
"proeth:necessaryFactors": [
"Engineer A\u0027s knowledge of and commitment to BER Case 96-4 principles",
"The principles\u0027 applicability to the AV OS safety-critical context",
"The risk assessment process providing a formal mechanism through which principles can be operationalized",
"Engineer A\u0027s professional standing to participate meaningfully in the risk assessment"
],
"proeth:responsibilityType": "direct",
"proeth:responsibleAgent": "Engineer A",
"proeth:sufficientFactors": [
"Activated precedent principles + safety-critical context + formal risk assessment process = sufficient to direct Engineer A\u0027s professional conduct toward active participation and transparent documentation",
"The precedent case provided both the ethical mandate (public safety primacy) and the professional model (transparent reporting) that shaped Engineer A\u0027s specific actions"
],
"proeth:withinAgentControl": true
}
Allen Temporal Relations (10)
Interval algebra relationships with OWL-Time standard properties| From Entity | Allen Relation | To Entity | OWL-Time Property | Evidence |
|---|---|---|---|---|
| financial pressure considerations (BER Case 96-4) |
during
Entity1 occurs entirely within the duration of Entity2 |
Engineer A's recommendation process (BER Case 96-4) |
time:intervalDuring
http://www.w3.org/2006/time#intervalDuring |
The financial pressures that existed, including the financial impact on his company, the client, and... [more] |
| new engineering breakthroughs |
before
Entity1 is before Entity2 |
new ethical uncertainties/risks |
time:before
http://www.w3.org/2006/time#before |
New technologies often introduce new uncertainties and sometimes significant risk. |
| BER Case 96-4 (precedent case) |
before
Entity1 is before Entity2 |
present autonomous vehicle case |
time:before
http://www.w3.org/2006/time#before |
Although the facts in the present case are somewhat different than those in Case 96-4, the Board of ... [more] |
| existing software testing (BER Case 96-4) |
before
Entity1 is before Entity2 |
new draft standards release |
time:before
http://www.w3.org/2006/time#before |
Although the tests demonstrated that the software was safe to use under existing standards, Engineer... [more] |
| additional proposed testing (BER Case 96-4) |
before
Entity1 is before Entity2 |
software deployment/use |
time:before
http://www.w3.org/2006/time#before |
The tests were expensive and would delay the use of the software for at least six months. |
| additional proposed testing (BER Case 96-4) |
meets
Entity1 ends exactly when Entity2 begins |
six-month delay period |
time:intervalMeets
http://www.w3.org/2006/time#intervalMeets |
A series of tests proposed by Engineer A would likely result in a decision whether to move forward w... [more] |
| six-month delay period |
before
Entity1 is before Entity2 |
software deployment/use |
time:before
http://www.w3.org/2006/time#before |
would delay the use of the software for at least six months, which would put the client company at a... [more] |
| Engineer A's risk assessment team participation (present case) |
before
Entity1 is before Entity2 |
autonomous vehicle operating system deployment |
time:before
http://www.w3.org/2006/time#before |
Engineer A should propose that further study be undertaken by the company before the autonomous vehi... [more] |
| further study (present case) |
before
Entity1 is before Entity2 |
autonomous vehicle operating system utilization |
time:before
http://www.w3.org/2006/time#before |
if necessary, Engineer A should propose that further study be undertaken by the company before the a... [more] |
| new draft standards awareness (BER Case 96-4) |
overlaps
Entity1 starts before Entity2 and ends during Entity2 |
Engineer A's recommendation process (BER Case 96-4) |
time:intervalOverlaps
http://www.w3.org/2006/time#intervalOverlaps |
Engineer A was aware of new draft standards that were about to be released...The software company re... [more] |
About Allen Relations & OWL-Time
Allen's Interval Algebra provides 13 basic temporal relations between intervals. These relations are mapped to OWL-Time standard properties for interoperability with Semantic Web temporal reasoning systems and SPARQL queries.
Each relation includes both a ProEthica custom property and a
time:* OWL-Time property for maximum compatibility.