Target-specific stance and support-or-attack relations

Last updated: 6 Oct 20265 min read

tutorial

A stance belongs to a speaker, target and time. Represent disagreement explicitly instead of substituting sentiment or treating every objection as opposition to the whole proposal.

Bind stance to an explicit target

“The latency result is good, but the rollback plan is unsafe” has positive language about one result and opposition to a different plan. Store stance toward a specific proposal or claim ID, speaker, source span and time. Labels can include support, oppose, mixed, neutral and unresolved under a documented policy. Sentiment is not a reliable shortcut for stance: criticism of a failure can support a proposed fix. Aspect sentiment supplies a related target notion but answers a different question.

Keep relation direction and scope

A premise may attack a subclaim without rejecting the top-level change. Connect typed unit IDs using directed support or attack edges and record which target each edge addresses. Distinguish an author’s own argument from a quoted opponent or hypothetical case. If a sentence names two services, do not transfer its stance from gateway-west to gateway-east. Argument units establish stable source spans for those relations.

Handle disagreement and change

Two reviewers may disagree on whether “needs more tests” is opposition or conditional support. Keep the disputed label and rationale rather than manufacturing consensus. A speaker can change position after new incident evidence; time and revision belong in the record. A later support statement should not erase earlier opposition from the audit. Disagreement policy helps separate unclear writing from inconsistent annotator instructions.

Evaluate the map

Measure target identification, stance by target, edge precision and attribution errors. Slice by quoted speech, negation, multi-target sentences and implicit premises. Review every proposed support edge that would be used in an automated decision summary. The project gates a change-review summary on a map that identifies who argued for what, why and under which runbook revision.

Implementation

def record_stance(speaker_id, target_claim_id, stance, source_unit_id,
                  observed_at):
    allowed = {"support", "oppose", "mixed", "neutral", "unresolved"}
    if stance not in allowed:
        raise ValueError("unknown stance")
    if not all((speaker_id, target_claim_id, source_unit_id, observed_at)):
        raise ValueError("stance needs speaker, target, source and time")
    return {"speaker_id": speaker_id, "target_claim_id": target_claim_id,
            "stance": stance, "source_unit_id": source_unit_id,
            "observed_at": observed_at}

latency_view = record_stance("reviewer-47", "latency-claim-82", "support",
                             "unit-91", "2026-09-27T09:00:00Z")
rollback_view = record_stance("reviewer-47", "rollback-claim-82", "oppose",
                              "unit-92", "2026-09-27T09:00:00Z")
assert latency_view["stance"] != rollback_view["stance"]
assert latency_view["target_claim_id"] != rollback_view["target_claim_id"]

Performance and operating cost

Creating one validated stance record is O(1) time and space for fixed-size references. Building a graph for u units and e relations takes O(u + e) storage and at least O(u + e) ingestion time. The example enforces identity fields; a reviewer must still establish whether the source span expresses the recorded position.

Common Mistakes

Using whole-document sentiment as stance on a particular claim.
Turning a criticism of one premise into opposition to every proposal.
Dropping quotation and speaker attribution.
Overwriting an earlier stance when a reviewer changes position later.