Expertise-Calibrated Disclosure Obligation

Class
http://proethica.org/ontology/intermediate#Expertise-CalibratedDisclosureObligation
Class Hierarchy
Definition

Duty of an engineer to calibrate the form, content, and urgency of disclosures about potential violations or risks to the engineer's actual level of expertise in the relevant technical discipline, disclosing with greater directness and specificity when the engineer has domain expertise, and with greater caution and qualification when the engineer lacks expertise in the specific discipline involved.

Inherited from ConcernVersusFactDisclosureThresholdObligation

Duty of an engineer to distinguish between a preliminary concern that has not yet been substantiated by technical analysis and a finding that constitutes a technical fact, and to recognize that mandatory disclosure obligations under Code section II.3.b are triggered only when the engineer's assessment rises to the level of fact rather than unverified concern, while acknowledging that prudent voluntary disclosure of concerns may nonetheless be appropriate.

Case Provenance
Discovered in
This class was discovered during extraction of the case(s) above; the supporting verbatim quotes are in Source Evidence.
Properties
Confidence
0.82
Derived From Principle
Graduated Response Proportionality Principle
Enforcement Level
prima_facie
Monitoring Criteria
Disclosure content and form are consistent with the engineer's documented expertise in the relevant discipline and with the evidentiary basis for the concern.
Nspe Reference
I.1, II.2, II.3.b
Obligation Type
disclosure
Stakeholders Affected
Client
General public
Other engineers
Regulatory authorities
Violation Consequences
Failure to calibrate disclosures to expertise level may result in either under-disclosure of known violations by domain experts or over-disclosure of speculative findings by non-experts, both of which breach professional standards.
Property Structure
1 · Object and Data Properties rdfs:domain on this class or ancestor
PropertyRangeDescription
competesWith inherited Obligation Relates an obligation to another obligation with which it stands in normative tension within a case. Symmetric: if O1 competes with O2 then O2 competes with O1. Does not itself specify which obligation prevails; use prevailsOver for the directed resolution.
defeasibleUnder inherited State Relates an obligation to a State whose obtaining renders the obligation defeasible, that is, subject to override by a competing obligation with stronger normative support. The State specifies the context in which the obligation yields.
derivedFromPrinciple inherited Principle Relates an obligation to the principle or principles it operationalizes. The obligation gives concrete directive force to the more abstract value the principle expresses (Dennis et al. 2016).
establishedBy inherited CodeProvision Indicates which code provision establishes this ethical concept.
obligatedParty inherited Agent Relates an Obligation to the Agent that bears it (the by-whom slot of the Richardson 1990 specification scheme, adopted by Dennis et al. 2016). The duty-bearer of the obligation in the case scenario.
prevailsOver inherited Obligation Relates an obligation to another obligation that it defeats under the conditions of the case. The prevailing obligation retains its force; the defeated obligation is subordinated to it. Use together with defeasibleUnder to record the State that licenses the resolution.
requiresCapability inherited Capability Relates an obligation to a capability its discharge presupposes. An obligation can be discharged only by an agent that possesses the required capability, the ought-implies-can principle of deontic logic (Kant's dictum, whose computational analogue Stenseke 2024 develops as moral tractability); in this framework an agent that lacks the required capability leaves the obligation subject to override, recorded via defeasibleUnder.
2 · Definitional Attributes SHACL definitional shape
AttributeProperty (sh:path)Description
obligation typeobligationTypeThe controlled NSPE obligation category, which drives the subClassOf core:Obligation typing: disclosure, safety, competence, confidentiality, reporting, collegial, attribution, legal, ethical.
3 · Bearer Attributes SHACL property shape individual data
AttributeProperty (sh:path)Description
obligation statementobligationStatementThe concrete duty the obligation states (the operative 'shall' clause).
derived from principlederivedFromPrincipleThe principle the obligation derives from, via the O->P derivedFromPrinciple edge (the P side of R->P->O). Range: Principle.
obligated partyobligatedPartyThe agent who bears the obligation, via the obligatedParty edge. Range: Agent.
temporal scopetemporalScopeWhen the obligation is in force (the period or condition of applicability).
compliance statuscomplianceStatusWhether the obligation was met in the case: met, unmet, partial, or unclear.
4 · Referenced By rdfs:range on this class or ancestor
FromPropertyDescription
Action fulfillsObligation inherited Relates an action to obligations it fulfills. The action realizes the directive content of the obligation.
Action raisesObligation inherited Relates an action to an obligation it puts at stake without itself resolving it. The fulfillment or breach occurs at a downstream action in the same chain. This third predicate distinguishes an upstream choice that engages an obligation from the downstream action that satisfies or breaches it; without it the same obligation appears as both fulfilled and violated across adjacent steps.
Action violatesObligation inherited Relates an action to an obligation it breaches. The action fails to realize the directive content of the obligation, the negative counterpart of fulfillsObligation.
Code Provision establishes inherited Relates a code provision to the ethical concepts (principles, obligations, constraints) it establishes or defines.
Obligation competesWith inherited Relates an obligation to another obligation with which it stands in normative tension within a case. Symmetric: if O1 competes with O2 then O2 competes with O1. Does not itself specify which obligation prevails; use prevailsOver for the directed resolution.
Obligation prevailsOver inherited Relates an obligation to another obligation that it defeats under the conditions of the case. The prevailing obligation retains its force; the defeated obligation is subordinated to it. Use together with defeasibleUnder to record the State that licenses the resolution.
Role hasObligation inherited Relates a role to an obligation borne in that standing. The Role-wide domain enables the edge for any role without committing existence; obligation-generation is axiomatized on proeth:ProfessionalRole (subClassOf hasObligation some Obligation) in the intermediate layer, and a participant role may bear case-asserted obligations without profession-generated ones.
State activatesObligation inherited Relates a State to an Obligation that the obtaining of the State makes applicable. This is the forward, activating complement of defeasibleUnder (which records the State under which an obligation yields): a state such as hazard exposure or an undertaken commitment can bring an obligation into force for the role-bearers it concerns.
Source Evidence
Text references
Engineer A's evaluation was based upon general surmise and speculation about the cause of the structural failure of the wall, based entirely upon a visual inspection without anything more. In addition, as in BER Case No. 89-7, there was nothing noted in the facts to indicate that Engineer A had expertise in the specific discipline involved.
In addition, the engineer in BER Case No. 89-7 did not have any particular expertise in the technical areas (mechanical, electrical) involved in the matter at issue.
In contrast, the facts in the present case indicate a violation of the federal and state laws and regulations.
Those two cases involved a different set of factors that created a reasonable basis for an engineer to take a more measured approach to the situation.

Source text
In contrast, the facts in the present case indicate a violation of the federal and state laws and regulations.
Used in cases 1

Case ontologies that instantiate this class or one of its base-ontology descendants. Computed from each individual's type, so the list stays current as cases are extracted. The originating case is shown under Extraction details.

Case 86
@prefix core: <http://proethica.org/ontology/core#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix pcsh: <http://proethica.org/shapes/core#> . @prefix proeth: <http://proethica.org/ontology/intermediate#> . @prefix proeth-prov: <http://proethica.org/provenance#> . @prefix prov: <http://www.w3.org/ns/prov#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix sh: <http://www.w3.org/ns/shacl#> . @prefix skos: <http://www.w3.org/2004/02/skos/core#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . proeth:Expertise-CalibratedDisclosureObligation a owl:Class ; rdfs:label "Expertise-Calibrated Disclosure Obligation" ; proeth:confidence "0.82" ; proeth:derivedFromPrinciple "Graduated Response Proportionality Principle" ; proeth:enforcementLevel "prima_facie" ; proeth:monitoringCriteria "Disclosure content and form are consistent with the engineer's documented expertise in the relevant discipline and with the evidentiary basis for the concern." ; proeth:nspeReference "I.1, II.2, II.3.b" ; proeth:obligationType "disclosure" ; proeth:stakeholdersAffected "Client", "General public", "Other engineers", "Regulatory authorities" ; proeth:textReferences "Engineer A's evaluation was based upon general surmise and speculation about the cause of the structural failure of the wall, based entirely upon a visual inspection without anything more. In addition, as in BER Case No. 89-7, there was nothing noted in the facts to indicate that Engineer A had expertise in the specific discipline involved.", "In addition, the engineer in BER Case No. 89-7 did not have any particular expertise in the technical areas (mechanical, electrical) involved in the matter at issue.", "In contrast, the facts in the present case indicate a violation of the federal and state laws and regulations.", "Those two cases involved a different set of factors that created a reasonable basis for an engineer to take a more measured approach to the situation." ; proeth:violationConsequences "Failure to calibrate disclosures to expertise level may result in either under-disclosure of known violations by domain experts or over-disclosure of speculative findings by non-experts, both of which breach professional standards." ; proeth-prov:discoveredInCase 86 ; proeth-prov:discoveredInPass 2 ; proeth-prov:discoveredInSection "discussion" ; proeth-prov:firstDiscoveredAt "2026-06-04T17:34:19.889581+00:00"^^xsd:dateTime ; proeth-prov:firstDiscoveredInCase 86 ; proeth-prov:matchConfidence 0.75 ; proeth-prov:matchReasoning "This obligation overlaps substantially with the Concern Versus Fact Disclosure Threshold Obligation, which addresses the distinction between preliminary concerns and established facts as the trigger for mandatory disclosure. The expertise-calibration dimension adds a further nuance not fully captured by that class, but the core concept of calibrating disclosure to the evidentiary and competence basis is closely related, warranting a medium-confidence match." ; proeth-prov:matchedOntologyClass proeth:ConcernVersusFactDisclosureThresholdObligation ; proeth-prov:matchedOntologyLabel "Concern Versus Fact Disclosure Threshold Obligation" ; proeth-prov:matchesExisting true ; proeth-prov:sourceText "In contrast, the facts in the present case indicate a violation of the federal and state laws and regulations." ; rdfs:comment "Duty of an engineer to calibrate the form, content, and urgency of disclosures about potential violations or risks to the engineer's actual level of expertise in the relevant technical discipline, disclosing with greater directness and specificity when the engineer has domain expertise, and with greater caution and qualification when the engineer lacks expertise in the specific discipline involved." ; rdfs:subClassOf proeth:DisclosureObligation ; skos:definition "Duty of an engineer to calibrate the form, content, and urgency of disclosures about potential violations or risks to the engineer's actual level of expertise in the relevant technical discipline, disclosing with greater directness and specificity when the engineer has domain expertise, and with greater caution and qualification when the engineer lacks expertise in the specific discipline involved." ; skos:scopeNote "[ConcernVersusFactDisclosureThresholdObligation] Duty of an engineer to distinguish between a preliminary concern that has not yet been substantiated by technical analysis and a finding that constitutes a technical fact, and to recognize that mandatory disclosure obligations under Code section II.3.b are triggered only when the engineer's assessment rises to the level of fact rather than unverified concern, while acknowledging that prudent voluntary disclosure of concerns may nonetheless be appropriate." ; prov:generatedAtTime "2026-06-04T17:34:19.889581+00:00"^^xsd:dateTime ; prov:wasAttributedTo "Case 86 Extraction", "claude-sonnet-4-6" . pcsh:CaseAnnotationShape a sh:NodeShape ; rdfs:label "Shared per-case annotation schema (all nine components)"@en ; rdfs:comment "The cross-component annotation fields on committed case individuals: proeth:confidence (extraction confidence, decimal; all components except Action, whose Step-3 contract carries no confidence field), proeth:textReferences (verbatim supporting quotes, universal), proeth-prov sourceText (the source snippet, on the Step-1/2 provenance layers; Step-3 A/E individuals ground via textReferences only), and the involvement gloss (proeth:caseInvolvement on role individuals, proeth:caseContext on obligation, capability, and constraint individuals). Values are per-individual; the fields do not individuate any type."@en ; sh:property [ sh:description "Extraction confidence for this individual (0 to 1)." ; sh:name "confidence" ; sh:order 1 ; sh:path proeth:confidence ], [ sh:description "Verbatim case quotes supporting this individual." ; sh:name "text references" ; sh:order 2 ; sh:path proeth:textReferences ], [ sh:description "How this individual figures in the case narrative (role individuals; the same text is routed into rdfs:comment)." ; sh:name "case involvement" ; sh:order 3 ; sh:path proeth:caseInvolvement ], [ sh:description "Grounding context in this case (obligation, capability, and constraint individuals)." ; sh:name "case context" ; sh:order 4 ; sh:path proeth:caseContext ] ; sh:targetClass core:Action, core:Capability, core:Constraint, core:Event, core:Obligation, core:Principle, core:Resource, core:Role, core:State . pcsh:ObligationDefinitionShape a sh:NodeShape ; rdfs:label "Obligation definition schema (type-level, descriptive, field contract)"@en ; rdfs:comment "What individuates an obligation TYPE: its controlled NSPE category, which drives the subClassOf core:Obligation typing. The concrete duty statement and the temporal-scope/compliance-status literals are per-individual, as are the derivedFromPrinciple and obligatedParty edges; all are declared on ObligationPropertyShape, mirroring the Role/Principle Definition/Property split. Descriptive only (no validation result); obligation_type is a routing input, not stored as a literal."@en ; sh:property [ sh:description "The controlled NSPE obligation category, which drives the subClassOf core:Obligation typing: disclosure, safety, competence, confidentiality, reporting, collegial, attribution, legal, ethical." ; sh:name "obligation type" ; sh:order 1 ; sh:path proeth:obligationType ] ; sh:targetClass core:Obligation . pcsh:ObligationPropertyShape a sh:NodeShape ; rdfs:label "Obligation per-case schema (individual data, non-definitional)"@en ; rdfs:comment "What a given obligation INDIVIDUAL is described by in a specific case: the concrete duty it states, the principle it derives from and the party who bears it (both edges), and its temporal scope and compliance status. These do NOT individuate the obligation TYPE (that is ObligationDefinitionShape); their values are per-case, asserted on the individual. Descriptive only."@en ; sh:property [ sh:description "The concrete duty the obligation states (the operative 'shall' clause)." ; sh:name "obligation statement" ; sh:order 1 ; sh:path proeth:obligationStatement ], [ sh:description "The principle the obligation derives from, via the O->P derivedFromPrinciple edge (the P side of R->P->O). Range: Principle." ; sh:name "derived from principle" ; sh:order 2 ; sh:path core:derivedFromPrinciple ], [ sh:description "The agent who bears the obligation, via the obligatedParty edge. Range: Agent." ; sh:name "obligated party" ; sh:order 3 ; sh:path core:obligatedParty ], [ sh:description "When the obligation is in force (the period or condition of applicability)." ; sh:name "temporal scope" ; sh:order 4 ; sh:path proeth:temporalScope ], [ sh:description "Whether the obligation was met in the case: met, unmet, partial, or unclear." ; sh:name "compliance status" ; sh:order 5 ; sh:path proeth:complianceStatus ] ; sh:targetClass core:Obligation .
Metadata
Type
Class
Last Updated
2026-07-05 15:17
Discovered in case
86
Discovered in pass
2
Discovered in section
discussion
First discovered
2026-06-04T17:34:19.889581+00:00
First case
86
Match Confidence
0.75
Match Reasoning
This obligation overlaps substantially with the Concern Versus Fact Disclosure Threshold Obligation, which addresses the distinction between preliminary concerns and established facts as the trigger for mandatory disclosure. The expertise-calibration dimension adds a further nuance not fully captured by that class, but the core concept of calibrating disclosure to the evidentiary and competence basis is closely related, warranting a medium-confidence match.
Matched Ontology Label
Concern Versus Fact Disclosure Threshold Obligation
Matches Existing
true
Generated
2026-06-04T17:34:19.889581+00:00
Attributed to
['Case 86 Extraction', 'claude-sonnet-4-6']