graph-extraction

name	graph-extraction
description	Extract the shared-graph ontology from a chat's batched inputs — people, threads, GitHub objects, topics, interest edges, and commitments — recording honestly, not certainly.

Graph extraction

Observe each batch of inputs and record what a later reader will actually use. You are not a write-time matcher: when unsure, write a low-confidence fact rather than nothing, and let confidence carry the ambiguity.

This policy is derived from MEMORY-STATE-SPEC §4 (extraction & resolution) and §9 (commitment lifecycle).

Resolve keyed types by convergence, keyless by phrasing

• People, agents, threads, and GitHub objects have natural keys — record them again whenever seen; re-recording converges on the key and raises confidence. Do not merge by hand unless two nodes are provably the same.
• Topics and commitments have no key. Reuse a node only on the same exact phrasing. Otherwise record a NEW node at reduced confidence — a value that says "I might be duplicating this." Never invent a normalized key to force a match; duplicates are resolved later, socially and by consolidation.

Extract only what a consumer will read

• Record mentions liberally — it is a cheap, low-stakes signal.
• Record discusses and interested_in conservatively — they feed proactive speaking, where a false positive is spam. Only when the interest is clearly expressed.

Record commitments passively, with two gates

A commitment is a keyless entity you extract with record_entity({ commitment }) during normal processing. "Hold me to that" is the same call at confidence 1.0.

• Owner gate (structural): a commitment needs exactly one owner (made_by). An utterance with no resolvable owner ("someone should look at this") is NOT a commitment — do not write it. An implicit owner ("we'll get to it") is written low-confidence with a best-guess made_by flagged uncertain.
• Surface floor (θ ≈ 0.5): phrasing sets confidence. "will", "I'll", "by " → high, above the floor. "should", "could", "ought" → below the floor: still written, but low. Borderline promises are recorded low, not dropped.

Turn finished jobs into graph facts

When a batch carries a finished-job result for a chat's work, record the earned edges works_on (author → issue/PR) and resolves (PR → issue). Do not restate the PR's labels or body — GitHub already serves those. These edges are idempotent, so a later duplicate webhook only raises confidence. In the same pass, if a commitment's about target is an issue/PR that merged or closed, flip that commitment open → done.

See the tool descriptions for the eleven entity and relation types and their keys.