# \[RFC\] Native Data Provenance & Fact Mapping for Discourse

**URL:** https://meta.discourse.org/t/rfc-native-data-provenance-fact-mapping-for-discourse/392842
**Category:** Community Building
**Tags:** rfc
**Created:** [January 7, 2026, 4:34am UTC](https://meta.discourse.org/t/rfc-native-data-provenance-fact-mapping-for-discourse/392842 "2026-01-07T04:34:06Z")
**Posts on this page:** 1
**Showing post:** 1

<div class="post-metadata">

### Author: ![Thefacto](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/thefacto/32/537948_2.png) [@Thefacto](https://meta.discourse.org/u/Thefacto)
#### Post date: [January 7, 2026, 4:34am UTC](https://meta.discourse.org/t/rfc-native-data-provenance-fact-mapping-for-discourse/392842/1 "2026-01-07T04:34:06Z")

</div>

Hello Discourse Community,

I’d like to introduce myself — I’m a system designer currently exploring the Discourse ecosystem. While I’m not yet an expert in Discourse’s internal architecture, I chose this platform for my upcoming project because of its strong data model, extensibility, and community-driven governance.

I’m currently preparing a proposal to present to my supervisor for development approval. By sharing this here, my goal is to gather feedback, insights, and constructive criticism from people who know Discourse best — particularly around feasibility, overlap with core features, and alignment with Discourse best practices.

> **Note:** The proposal below is fairly detailed and technical.  
> I may not be able to reply immediately, but I will read and respond to every comment as soon as possible.

* * *

## Plain-Language Overview (Quick Context)

**The problem:**  
In many community discussions — especially around news, public policy, science, or controversial topics — claims are frequently challenged, corrected, or refined over time. While Discourse excels at discussion, it is still difficult to clearly see:

- where a claim originally came from,
- how it evolved through replies and quotes,
- which posts support, correct, or contradict it,
- and how confidence in that claim changes as the discussion grows.

**The idea:**  
This project explores a plugin that turns discussion threads into **transparent evidence graphs** , helping communities perform **collective fact-checking** without relying on a single authority or binary “true/false” labels.

Instead of declaring facts, the system focuses on **traceability, structure, and signals** — allowing readers and moderators to judge credibility based on how information is sourced, challenged, and verified within the community.

**Who might benefit:**

- **Moderators & admins:**
  - Supporting fair, evidence-based moderation decisions
  - Identifying corrections, disputes, and unstable claims more quickly

- **Fact-checkers & researchers:**
  - Tracing claim lineage and verification paths inside discussions

- **Community members:**
  - Engaging in debates with clearer context and shared references

- **Readers:**
  - Understanding _why_ a claim is trusted or disputed without reading every reply

 ![Gaph1767782834732](https://global.discourse-cdn.com/meta/original/4X/3/7/c/37c052d9a9a04bac1af4f4f4133a478c0980d12d.jpeg)

### [Facto Map]

This is an example of how I imagine the graph could look in practice.

It is intended for **specialized use cases** or for **topics with overwhelming amounts of replies** , where manually tracking, verifying, and understanding all arguments becomes impractical.

The Facto Map helps visualize claims, evidence, contradictions, and verification paths, making it easier for communities to **fact-check** , **assess credibility** , and **conduct structured debates** without losing context.

What follows is a **technical specification / RFC-style proposal** focused on architecture and feasibility.

* * *

# Technical Specification

**Project Title:** Discourse OriginGraph & Facto-Mapper  
**Subtitle:** Native Data Provenance Tracking & Reliability Analysis System  
**Version:** 1.0.0 (Proposal)

* * *

## 1. Executive Summary

In an era of rapid information dissemination, discussion platforms like Discourse excel at structured argumentation but lack native tools for **data provenance analysis** , **claim evolution tracking** , and **transparent fact-checking workflows**.

**Discourse OriginGraph & Facto-Mapper** is a plugin designed to augment Discourse with a **community-driven fact-mapping layer**. Rather than enforcing absolute truth, it provides visual and statistical tools that help communities **prove, challenge, and contextualize claims** through structured discussion.

The system emphasizes:

- traceability over authority,
- confidence signals over verdicts,
- and collective reasoning over centralized judgment.

* * *

## 2. Technical Objectives

- **Traceability:**  
Directed Acyclic Graph (DAG) for Source → Expansion → Verification → Correction

- **Fact-Checking Support:**  
Provide structural evidence for claims, rebuttals, and corrections without labeling content as true or false

- **Visualization:**  
Interactive “Facto Maps” embedded directly in topic views

- **Heuristic Analysis:**  
Weighted confidence-based scoring derived from discussion structure and verification patterns

- **Performance:**  
Asynchronous processing via Sidekiq

- **Integration:**  
Strict adherence to Discourse plugin architecture (Rails / Ember.js)

* * *

## 3. Scope of Work

### 3.1 In-Scope

- Intra-topic relationship graphing (reply, quote, mention, correction, contradiction)
- Signal extraction from cooked HTML and reply metadata
- Configurable Origin / Stability / Dispute scores
- Governance via Discourse Trust Levels
- Moderator-visible fact-checking signals (non-authoritative)

### 3.2 Out-of-Scope

- Automated truth classification (no true/false labels)
- NLP / LLM semantic analysis (Phase 1)
- Global search replacement
- Cross-instance federation

* * *

## 4. System Architecture

### 4.1 Technology Stack

- **Backend:** Ruby on Rails (Discourse Core), Sidekiq
- **Frontend:** Ember.js, D3.js or Cytoscape.js
- **Database:** PostgreSQL 13+, Redis
- **Data Interchange:** Internal JSON API

### 4.2 Conceptual Architecture Diagram

```
[Client: Ember.js] <-- JSON --> [Controller: Rails]
       | |
(Interactive Facto Map) (Request Validation)
       | |
       v v
[Visualizer Library] [Sidekiq Worker Pool]
                                          |
                                 +--------+--------+
                                 | |
                          [Graph Engine] [Scoring Engine]
                                 | |
                                 +--------+--------+
                                          |
                                    [PostgreSQL]
                           (Edges / Snapshots / Logs)

```

* * *

## 5. Data Model (Schema Design)

### 5.1 Table: provenance\_edges

| Column | Type | Index | Description |
| --- | --- | --- | --- |
| id | BigInt | PK | Unique edge ID |
| topic\_id | Integer | IDX | Topic reference |
| source\_post\_id | Integer | IDX | Origin node |
| target\_post\_id | Integer | IDX | Destination node |
| relation\_type | Enum | | reply, quote, ref, correction, contradiction |
| weight | Float | | Edge strength |
| metadata | JSONB | | Context data |

### 5.2 Table: facto\_graph\_snapshots

| Column | Type | Index | Description |
| --- | --- | --- | --- |
| id | BigInt | PK | Snapshot ID |
| topic\_id | Integer | UNIQUE | Associated topic |
| version | Integer | | Graph version |
| graph\_payload | JSONB | | Nodes & edges |
| computed\_at | Datetime | | Generated time |
| is\_public | Boolean | | Visibility flag |

### 5.3 Redis Keys

- facto:quota:user:{id}:daily
- facto:job:topic:{id}:status

* * *

## 6. Internal API Specification

### POST /facto/analyze

- Auth: TL1+
- Params: topic\_id, force\_recalc
- Response: job\_id, status = queued

### GET /facto/graph/:topic\_id

```
version: 5
nodes:
  - id: 101
    group: source
    score: 0.8
edges:
  - source: 101
    target: 105
    type: verification

```

* * *

## 7. Algorithms & Logic

### 7.1 Signal Extraction Logic

- Iterate all posts in topic
- reply\_to\_post\_number → Reply edge
- Parse cooked HTML → Quote edge
- Regex @username → Mention edge
- Moderator annotations → Correction / Contradiction edges

### 7.2 Scoring Algorithm

Weighted centrality (PageRank-style):

```
Score(P) = (1 - d) + d × Σ((Score(Pi) × Weight(Ei,P)) / OutDegree(Pi))

```

Negative or contradictory edges apply penalty multipliers rather than binary rejection.

* * *

## 8. UX / UI

- Entry point: “Graph View” button in topic map
- Fullscreen modal Facto Map
- Hover node: post snippet + author + confidence signals
- Click node: scroll to post
- Filters: show/hide corrections, contradictions, or only verified paths

* * *

## 9. Security & Governance

- Rate limiting via Discourse RateLimiter
- JSONB sanitization to prevent XSS
- Private topics inherit Discourse ACL
- No automated moderation actions — signals are advisory only

* * *

## 10. Development Roadmap

- **Phase 1:** MVP graph extraction + basic visualization
- **Phase 2:** Advanced confidence scoring + moderator annotations
- **Phase 3:** External fact-checking API & research exports

---

_[View the full topic](https://meta.discourse.org/t/rfc-native-data-provenance-fact-mapping-for-discourse/392842)._