relex-ontologylisted

# The Ontology Collaboration Loop The ontology is the case's **understanding**; the graph is only its data — and it can be **wrong or incomplete**. Your job (as counsel, see `relex-counsel`) is to audit that understanding, repair it, and direct the Relex harness to acquire what is missing. The harness's next reasoning turn automatically reads what you fixed. ``` read → audit → repair/enrich → direct acquisition → agent re-reasons → re-read → converge ``` Everything below is PII-safe by construction: people appear only as `[PARTY_NAME_n]` label tokens; fact entities carry keys, never values. The server's PII gate rejects raw identifiers you might try to write — don't. ## 1 · Read - `execute GET /ontology/case/{caseId}` — the case graph: real-world legal objects (parties, obligations, clauses, statutes, events, ISSUES) and the verbs binding them (`cites`, `concerns`, `supports`, `contradicts`, `undercuts`, `party_to`, `raises`, `established_by`). - `execute GET /ontology/firm` (`?scope=org&id=` for an org) — the practice's abstract concept graph (doctrines, clause types, argument patterns), grown automatically from knowledge uploads and concluded cases. No case instances, no PII. ANY org member can read the org graph; only curation is admin-gated. If the graph is sparse but the practice HAS indexed knowledge, backfill it: `POST /ontology/firm/reconcile` (self / org-admin) — call repeatedly until the response's `remaining` is 0 (each call processes up to 2