Edit States Template

States v1

Viewer

Test Case:

Template

Preview

History

System prompt (optional)

You are an expert at extracting situational states from engineering-ethics cases using the ProEthica nine-component formalism and the professional-ethics literature (Berreby et al. Event-Calculus fluents; Jones moral intensity; Almpani context-driven obligation priorities). A state is classified by its content archetype, not by the obligation it activates. Follow the extraction methodology, matching rules, and output format given in the user message exactly, and return only the requested JSON (no prose, markdown, or code fences).

User prompt (template)

{{ state_definition }}

EXISTING STATES IN ONTOLOGY:
{{ existing_states_text }}

{{ pass_directive }}

CROSS-CONCEPT CONTEXT (entities already extracted in this case, when any exist at this stage; states extract first in the current pipeline, so this section is normally empty and the linkage fields are grounded at commit; do NOT re-extract them here):
{{ cross_concept_context }}

CASE TEXT:
{{ case_text }}

{{ state_schema }}

STATE EXTRACTION DIRECTIVES (rules the ontology enforces):
{{ state_boundary }}
{{ state_individuation }}
- state_category is the controlled content archetype and the load-bearing typing signal. Set exactly one of epistemic, risk, competence, emergency, conflict_of_interest, regulatory, temporal, resource, disclosure. It classifies the condition in the world (a RiskState is hazard exposure, an EpistemicState is an agent's knowledge condition), explicitly NOT the activatesObligation relation. The archetype becomes the rdfs:subClassOf typing at commit, so a wrong archetype collides with the disjointness axioms; it is a routing input, not stored as a literal. Do not invent an archetype outside this set.
- Use a canonical, short, reusable state label and REUSE an existing state class from the list above. A discovered compound class must chain through its archetype (e.g. "Tool Reliance State" is a CompetenceState; "Confidential Information State" is a DisclosureState), so a specific label still lands on one of the nine.
- Stative-label rule: a state is named for the condition that holds (for example Sealed Draft Report), never for the happening that produced it.
- A case yields one state individual per distinct condition even when the condition is narrated in several passages; a happening-shaped candidate routes to the Event pass.
- persistence_type records whether the state is an inertial or non-inertial fluent (Berreby): inertial states persist until terminated, non-inertial states hold only momentarily.
- urgency_level records the salience or acuteness of the state (Jones moral intensity): low, medium, high, or critical. It is an attribute of the state, not its kind.
- Edge-only linkage fields, converted to edges at commit and not stored as literals: obligation_activation names the obligations the state makes applicable (the activatesObligation edge); action_constraints names the constraints it activates; activation_conditions and termination_conditions are the class-level Event-Calculus fields; affected_parties names the agents the state affects (the affects edge).
- Kept-literal fields: triggering_event and terminated_by are stored verbatim on the individual AND resolved to the activatedByEvent/terminatedByEvent edges, and subject (what is in the state) is stored as a literal; all three later feed the defeasibility prompt as state context, so write full, readable phrases, not terse edge fodder. Provide every field where the text supports it.
- Do not assert obligation competition, defeat, or precedence here. The defeasibility relations are produced by a separate pass.

MATCH DECISION RULES:
For each state class, evaluate ONLY against the EXISTING STATES IN ONTOLOGY list above. The cross-concept section above is normally empty at the states stage; when populated it helps avoid duplicates, but do NOT reference those entities in match_decision; that field is strictly for matching against the ontology list above.
- If the extracted state IS the same concept as an existing class: match with HIGH confidence (0.85-1.0)
- If the extracted state is a SPECIALIZATION of an existing class: match to parent with MEDIUM confidence (0.70-0.85)
- If RELATED but distinct: do NOT match, it is a new concept
- If genuinely NEW with no close equivalent: match_decision.matches_existing = false

OUTPUT FORMAT:
Return a JSON object with TWO arrays: new_state_classes (reusable kinds of condition) and state_individuals (specific conditions holding in this case). A State Class is a general reusable condition (e.g. "Conflict Of Interest State"); a State Individual is a specific condition holding in the case. Each individual MUST reference a class via the state_class field.

CLASS LABEL CANONICALIZATION (with worked examples):
Drop case-specific detail (named actors, case identifiers, scenario chains) from the class label; put it in the definition and the individual record. Emit the short general right-hand form:
- "Engineer A's Conflict Between Client W and the Merger Party" -> "Conflict Of Interest State"
- "Public Endangered by the Suppressed Soil Report" -> "Public Safety Risk State"
- "Intern Assigned Work Beyond Their Training" -> "Out Of Competence State"
Test: if a label could only ever apply to THIS case, generalize it until another case could reuse it, while still chaining to one of the nine archetypes.

CLASS SCHEMA (new_state_classes array) -- each class is a JSON object:

  {
    "label": "Conflict Of Interest State",
    "definition": "A condition in which a professional's duty to one party is set against a competing interest, so that judgment owed to the first party may be compromised.",
    "state_category": "conflict_of_interest",
    "persistence_type": "inertial",
    "activation_conditions": ["Engineer A retained by two parties with opposing interests"],
    "termination_conditions": ["Engineer A withdraws from one engagement"],
    "obligation_activation": ["Disclosure Obligation"],
    "action_constraints": ["Confidentiality Constraint"],
    "principle_transformation": "The loyalty principle now requires disclosure of the dual engagement.",
    "text_references": ["Engineer A was engaged by both the owner and the contractor"],
    "confidence": 0.9,
    "match_decision": {
      "matches_existing": false,
      "matched_uri": null,
      "matched_label": null,
      "confidence": 0,
      "reasoning": "Conflict Of Interest State is the canonical ConflictOfInterestState archetype; no narrower existing class fits this dual-engagement condition."
    }
  }

INDIVIDUAL SCHEMA (state_individuals array) -- each individual is a JSON object:

  {
    "identifier": "Dual Engagement Conflict",
    "state_class": "Conflict Of Interest State",
    "subject": "Engineer A",
    "active_period": "From the second retention until withdrawal",
    "triggering_event": "Engineer A accepts the contractor's retention",
    "terminated_by": "Engineer A withdraws from the contractor engagement",
    "affected_parties": ["Owner", "Contractor"],
    "urgency_level": "high",
    "text_references": ["Engineer A was engaged by both the owner and the contractor"],
    "confidence": 0.92
  }

Keep each individual's identifier short (the short condition plus the case anchor, at most about 6 words); scenario detail belongs in the definition and the linkage fields, not the identifier (it becomes the URI).

FORMATTING: do not use em dashes or en dashes in output text, and do not dodge with stacked parentheticals or excessive colons/semicolons; use commas or split into two sentences.

Loading preview...

Version History

No version history yet. Save changes to create versions.

Saved

6997 chars

Reference

Template Variables

States are extracted in Step 1 and carry no cross-concept dependency, so this slot is empty for states; retained for template uniformity

State definitional/individual field schema, resolved live from the SHACL StateDefinitionShape (single source shared with the OntServe State entity page). state_category drives the archetype subClassOf typing; persistence_type and urgency_level are attributes; the linkage fields resolve to edges; none are stored as the conceptCategory literal

Per-pass directive; one body serves facts+discussion, differing only by this runtime slot

Governing definitional anchor: the ontology iao:0000115 definition plus the iao:0000116 extraction framing, citation-trimmed at injection (the generalized Role definition pattern)

The case text to analyze

Formatted list of existing state classes from ontology (plus the reuse-bias guidance block)

Output Schema

new_state_classes

label* string

confidence number

definition* string

match_decision* object

state_category* string

text_references* array

persistence_type string

action_constraints array

activation_conditions array

obligation_activation array

termination_conditions array

principle_transformation string

state_individuals

subject string

confidence number

identifier* string

state_class* string

active_period string

terminated_by string

urgency_level string

text_references* array

affected_parties array → Agent

triggering_event string

JSON Wrapper

Appended to the prompt by the extractor:

IMPORTANT: Wrap your response as a JSON object with exactly two keys:
{"new_state_classes": [...], "state_individuals": [...]}
If there are no individuals to report, use an empty array for "state_individuals".