Expose conflict and review state in the supported RDF read contract

[ansonnmm]

Summary

Following the clarification in #550 that RDF export is Utopia's supported machine-readable integration boundary, there is one remaining gap that seems important for downstream readers:

the export contains the assertions themselves, but not the conflict / review state Utopia has already established about those assertions.

This means an external system can recover two evidence-backed facts, their provenance, validity and history, but cannot reliably tell from the supported contract that Utopia considers them currently contested.

Context

As clarified in #550:

• RDF export is the supported machine-readable read contract;
• MCP is the agent-facing surface;
• /api/v1 is UI-internal and is not a compatibility promise.

The RDF export already preserves the important epistemic lineage:

entity
→ assertion
→ world time
→ record time
→ correction / supersession
→ evidence quote
→ source document
→ derivation / rule / premises

The missing piece is conflict and review state.

Example

Suppose the knowledge base contains two evidence-backed assertions such as:

Acme revenue = 100M
Acme revenue = 130M

and Utopia has already detected that they form a conflict.

Internally, Utopia can preserve both assertions and surface the conflict for review.

A downstream reader of the RDF export currently sees both assertions, but does not receive the epistemic fact that:

these assertions are contested

Without that state, the integration has two undesirable options:

1. treat both assertions as ordinary independent facts; or
2. rebuild Utopia's conflict-detection logic downstream.

The second would duplicate logic that Utopia already owns, while the first loses part of Utopia's epistemic model.

Desired property

The supported machine-readable contract should make it possible to determine that an exported assertion participates in an unresolved or otherwise relevant conflict/review state.

I am not suggesting a particular RDF vocabulary or storage model.

The minimum useful information seems to be equivalent to:

Conflict {
  id
  kind
  status
  affected_fact_ids[]
}

or RDF relationships carrying the same semantics.

The important invariants are:

• the conflict has a stable machine-addressable identity, if Utopia treats it as an addressable object;
• affected assertions can be joined to it through their existing stable IRIs/UUID-derived identities;
• conflict kind is machine-readable;
• current resolution/review status is machine-readable;
• a downstream reader does not need to reconstruct conflict detection from the exported assertions.

Scope

This issue is about exporting Utopia's existing epistemic judgment that facts are contested.

It is not asking the RDF consumer to receive the entire Review UI model, queue presentation state, or reviewer workflow unless those are necessary to express the semantic state.

The key distinction is:

fact exists

versus:

fact exists, but Utopia currently considers it contested

That distinction should survive the supported machine-readable boundary.

Questions

A few design questions are intentionally left to the project:

1. Should conflict/review state be represented directly on the affected statements, as separate conflict resources, or both?
2. Which statuses are part of the durable epistemic model versus UI workflow state?
3. Should resolved historical conflicts remain present in RDF for audit/history, or should the export expose only current conflict state?

Suggested acceptance criteria

A regression fixture could establish the external invariant:

1. Create two assertions that Utopia recognizes as conflicting.
2. Export the base as Turtle or JSON-LD.
3. Both assertions remain present with their normal evidence/provenance.
4. The export also contains enough structured information to identify that the assertions are part of the conflict.
5. The conflict kind and current state can be read without depending on /api/v1 or database tables.
6. After the conflict is resolved, the export reflects the intended durable resolution semantics.

Related

#550 clarified that this missing conflict/review information should become its own issue.

The goal here is to keep the supported RDF boundary epistemically complete enough that downstream integrations do not need to reimplement Utopia's conflict semantics.