DEV Community

Seyed Alireza Alhosseini
Seyed Alireza Alhosseini

Posted on

Building a Causal Work Graph for AI-Native Engineering Teams

#ai #softwaredevelopment #development #algorithms

Modern engineering organizations have an unusual problem.

They have too much context.

Slack contains the discussion.

Jira contains the issue.

GitHub contains the implementation.

Notion contains the specification.

Customer-support systems contain the original complaint.

The information is there.

What disappears is the thread connecting them.

A few months later, someone asks:

Why was this feature built?

The answer may require opening six systems, searching dozens of messages, reading an old Jira ticket, examining commits, and asking someone who remembers the original decision.

This is not primarily a search problem.

It is a lineage problem.

ThreadWeaver v3 explores a different architecture:

The Causal Work Graph

A graph designed not merely to represent what entities are related, but to represent how work evolved across organizational systems — while preserving evidence and uncertainty.

1. The Problem: Context Is Fragmented, Relationships Decay

Consider a simple product decision.

Customer complaint
        ↓
Slack discussion
        ↓
PM decision
        ↓
Jira issue
        ↓
GitHub implementation
        ↓
Production release
Enter fullscreen mode Exit fullscreen mode

Every artifact exists independently.

But the organizational meaning exists in the relationships.

The customer complaint explains the discussion.

The discussion explains the decision.

The decision explains the ticket.

The ticket explains the implementation.

The implementation explains the release.

Remove those connections and the organization retains data but loses history.

This creates a particularly expensive question:

"Why did we do this?"

2. The Core Thesis

ThreadWeaver is based on a deliberately narrow hypothesis:

Enterprise AI is becoming increasingly good at retrieving related information. A harder problem remains: reconstructing the causal lineage of work across the systems where organizational decisions actually occur.

This is not a claim that existing enterprise search systems cannot build graphs.

Modern enterprise AI systems increasingly use semantic graphs, connectors, relationships, and organizational context.

The distinction ThreadWeaver explores is narrower:

Can we create an evidence-backed, traversable history of decisions and their consequences, rather than merely retrieving related knowledge?

That distinction is important.

It changes the primitive from:

Search → Documents
Enter fullscreen mode Exit fullscreen mode

to:

Question → Subgraph → Evidence → Lineage
Enter fullscreen mode Exit fullscreen mode

3. From Knowledge Graph to Causal Work Graph

A conventional knowledge graph might represent:

Customer
   │
   ├── owns → Account
   │
   └── opened → Ticket
Enter fullscreen mode Exit fullscreen mode

A Causal Work Graph represents transitions in work:

Customer Complaint
       │
       │ influenced
       ▼
Slack Discussion
       │
       │ informed
       ▼
PM Decision
       │
       │ created
       ▼
Jira Issue
       │
       │ implemented_by
       ▼
Git Commit
       │
       │ shipped_as
       ▼
Release
Enter fullscreen mode Exit fullscreen mode

The graph therefore contains two different kinds of information:

Nodes

Things that happened or existed.

Message
Decision
Ticket
Commit
Release
Customer
Feature
Enter fullscreen mode Exit fullscreen mode

Edges

Relationships between those things.

mentions
follows
references
influenced
resulted_in
implemented_by
validated_by
superseded_by
Enter fullscreen mode Exit fullscreen mode

The edge is not merely a connection.

It is a claim about the relationship between two events.

4. The Edge Is a First-Class Data Object

This is one of the most important design decisions in ThreadWeaver.

Instead of storing:

A → B
Enter fullscreen mode Exit fullscreen mode

we store:

Edge
├── source
├── target
├── relation
├── timestamp
├── actor
├── confidence
├── evidence
├── provenance
└── causal_status
Enter fullscreen mode Exit fullscreen mode

Example:

{
  "source": "slack:msg_1842",
  "target": "jira:issue_392",
  "relation": "resulted_in",
  "timestamp": "2026-07-21T14:32:00Z",
  "actor": "user:pm_17",
  "confidence": 0.91,
  "causal_status": "inferred",
  "evidence": [
    "slack:msg_1842",
    "jira:comment_992"
  ]
}
Enter fullscreen mode Exit fullscreen mode

This creates a fundamental rule:

No causal edge without provenance.

The system should always be able to answer:

Why do you believe these two events are connected?

5. Similarity Is Not Causality

This distinction prevents one of the most dangerous failure modes of AI graph systems.

Suppose:

Slack:

"Customers are reporting CSV import failures."

Jira:

"Improve CSV import reliability."
Enter fullscreen mode Exit fullscreen mode

An embedding model may produce a high similarity score.

That tells us:

semantic similarity ≈ high
Enter fullscreen mode Exit fullscreen mode

It does not prove:

causal relationship = true
Enter fullscreen mode Exit fullscreen mode

The Jira issue might have existed months earlier.

Therefore ThreadWeaver separates:

Semantic
Temporal
Reference
Causal
Enter fullscreen mode Exit fullscreen mode

relationships.

For example:

related_to
mentions
follows
references
influenced
resulted_in
implemented_by
validated_by
Enter fullscreen mode Exit fullscreen mode

The system must never silently transform:

similar
Enter fullscreen mode Exit fullscreen mode

into:

caused
Enter fullscreen mode Exit fullscreen mode

6. Causal Status

Real organizations produce incomplete evidence.

Therefore every causal relationship should have an explicit status.

EXPLICIT
INFERRED
PROBABLE
UNKNOWN
REJECTED
Enter fullscreen mode Exit fullscreen mode

For example:

PM Decision
     │
     │ EXPLICIT
     ▼
Jira Ticket
Enter fullscreen mode Exit fullscreen mode

is stronger than:

Slack Discussion
     │
     │ PROBABLE
     ▼
Jira Ticket
Enter fullscreen mode Exit fullscreen mode

A possible data model:

{
  "relation": "influenced",
  "causal_status": "probable",
  "confidence": 0.73
}
Enter fullscreen mode Exit fullscreen mode

This is not just metadata.

It is part of the product's trust model.

7. Evidence-Backed Lineage

Imagine asking:

Why was Jira #392 created?

Instead of generating a paragraph, ThreadWeaver returns:

Jira #392
    ↑
    │ created_after
    │
Slack Discussion #1842
    ↑
    │ references
    │
Customer Complaint #771
Enter fullscreen mode Exit fullscreen mode

Then:

Evidence

✓ Slack message #1842
✓ Jira creation timestamp
✓ PM comment
✓ Customer support ticket #771
Enter fullscreen mode Exit fullscreen mode

The user can inspect every source.

This produces:

Lineage
+
Evidence
+
Confidence
+
Provenance
Enter fullscreen mode Exit fullscreen mode

rather than:

LLM-generated explanation
Enter fullscreen mode Exit fullscreen mode

That distinction is critical for enterprise systems.

8. The Graph Schema

A minimal graph can be represented with five primary object types.

Entity 

Entity {
    id
    type
    source
    source_id
    canonical_id
    metadata
}
Enter fullscreen mode Exit fullscreen mode

Examples:

Customer
Person
Project
Feature
Repository
Enter fullscreen mode Exit fullscreen mode

Event 

Event {
    id
    type
    timestamp
    actor
    source
    source_id
}
Enter fullscreen mode Exit fullscreen mode

Examples:

SlackMessage
Decision
TicketCreated
Commit
Release
Enter fullscreen mode Exit fullscreen mode

Edge 

Edge {
    id
    source
    target
    relation
    timestamp
    confidence
    causal_status
}
Enter fullscreen mode Exit fullscreen mode

Evidence 

Evidence {
    id
    edge_id
    source
    pointer
    excerpt_hash
    permission_context
}
Enter fullscreen mode Exit fullscreen mode

Permission 

Permission {
    principal
    resource
    action
    source
}
Enter fullscreen mode Exit fullscreen mode

This separation allows the graph to preserve relationships without necessarily copying the underlying content.

9. Source Data Should Stay Where It Lives

ThreadWeaver should not become a second enterprise data warehouse.

A safer architecture is:

Slack ───────────────┐
Jira ────────────────┤
GitHub ──────────────┤
Notion ──────────────┤
Support ─────────────┤
                     │
                     ▼
              ThreadWeaver
                     │
              stores primarily
                     │
       ┌─────────────┼─────────────┐
       ▼             ▼             ▼
    pointers      metadata       graph
                                  edges
Enter fullscreen mode Exit fullscreen mode

Raw content remains in the source system whenever possible.

The graph stores:

IDs
Pointers
Relationships
Metadata
Embeddings
Evidence references
Permission metadata
Enter fullscreen mode Exit fullscreen mode

This reduces duplication and makes governance easier.

10. Entity Resolution

A graph is only as good as its identity resolution.

The same person might appear as:

Alice Smith
alice@company.com
alice-dev
@alice
Alice S.
Enter fullscreen mode Exit fullscreen mode

ThreadWeaver should use a three-stage strategy.

Stage 1 — Deterministic 

email
account ID
ticket ID
repository ID
Slack user ID
GitHub user ID
Enter fullscreen mode Exit fullscreen mode

Stage 2 — Probabilistic

Embedding or similarity-based matching for ambiguous cases.

Stage 3 — Human Confirmation

For high-impact uncertain matches:

Possible match:

Slack: Alice
GitHub: alice-dev

Confidence: 0.84

Confirm?
[ Yes ] [ No ]
Enter fullscreen mode Exit fullscreen mode

The principle is:

Deterministic first. Probabilistic second. Human confirmation when ambiguity matters.

11. Integration Architecture

The first MVP should intentionally support only three systems:

Slack
Jira
GitHub
Enter fullscreen mode Exit fullscreen mode

The architecture:

              ┌─────────┐
              │  Slack  │
              └────┬────┘
                   │
              ┌────▼────┐
              │   MCP   │
              └────┬────┘
                   │
┌─────────┐   ┌────▼────┐   ┌──────────┐
│  Jira   ├──►│ Ingest  │◄──┤  GitHub  │
└─────────┘   └────┬────┘   └──────────┘
                   │
                   ▼
            Entity Resolution
                   │
                   ▼
            Event Extraction
                   │
                   ▼
          Relationship Detection
                   │
                   ▼
           Causal Work Graph
Enter fullscreen mode Exit fullscreen mode

MCP is useful here as an integration interface.

But MCP is not the moat.

The moat, if one emerges, comes from:

Entity Resolution
+
Temporal Modeling
+
Causal Relationship Modeling
+
Evidence
+
Organizational History
Enter fullscreen mode Exit fullscreen mode

12. Graph Storage

The first implementation does not require an exotic infrastructure stack.

Two reasonable approaches are:

Option A — PostgreSQL 

PostgreSQL
├── entities
├── events
├── edges
├── evidence
├── permissions
└── pgvector
Enter fullscreen mode Exit fullscreen mode

Advantages:

  • mature
  • operationally simple
  • transactional
  • easy deployment
  • vector search available
  • relational queries for permissions

Option B — Graph Database

A graph database becomes attractive when traversal complexity becomes dominant.

For example:

Customer
 → Discussion
 → Decision
 → Ticket
 → Commit
 → Release
Enter fullscreen mode Exit fullscreen mode

can be traversed naturally.

The MVP should therefore optimize for:

minimum operational complexity

rather than choosing a graph database simply because the product is called a graph.

13. Graph-Bounded Retrieval

ThreadWeaver should not retrieve an entire organization's context.

Instead:

User Question
      ↓
Entity Detection
      ↓
Relevant Subgraph
      ↓
Evidence Retrieval
      ↓
LLM Reasoning
      ↓
Answer + Graph
Enter fullscreen mode Exit fullscreen mode

Example:

Question:

"Why was CSV Import v2 released?"
Enter fullscreen mode Exit fullscreen mode

Entity resolution finds:

Feature: CSV Import v2
Enter fullscreen mode Exit fullscreen mode

Then graph traversal retrieves:

Feature
├── customer requests
├── Slack discussions
├── decisions
├── Jira tickets
├── commits
└── releases
Enter fullscreen mode Exit fullscreen mode

Only this bounded subgraph becomes the LLM context.

This reduces:

  • context size
  • latency
  • irrelevant retrieval
  • hallucination surface
  • inference cost

14. The LLM Should Not Own the Graph

This is another critical architectural rule.

Do not let the LLM become the database.

The graph should be deterministic infrastructure.

The LLM should operate on top of it.

             Causal Graph
                  │
                  ▼
             Retrieval
                  │
                  ▼
            Evidence Set
                  │
                  ▼
                 LLM
                  │
                  ▼
          Natural-language answer
Enter fullscreen mode Exit fullscreen mode

The LLM can explain.

It can summarize.

It can help classify.

It can propose relationships.

But the authoritative state should remain outside the model.

15. Causal Edge Scoring

A useful edge-scoring system can combine multiple signals.

For example:

CausalScore =
    w1 * explicit_reference
  + w2 * direct_link
  + w3 * temporal_proximity
  + w4 * semantic_similarity
  + w5 * actor_continuity
  + w6 * artifact_dependency
Enter fullscreen mode Exit fullscreen mode

But there is an important constraint:

A high score should not automatically mean "caused."

Instead:

score ≥ threshold_A
    → candidate causal edge

score ≥ threshold_B
+ explicit evidence
    → stronger causal classification
Enter fullscreen mode Exit fullscreen mode

The final state should preserve both:

score
Enter fullscreen mode Exit fullscreen mode

and:

causal_status
Enter fullscreen mode Exit fullscreen mode

16. Temporal Reasoning

Time is a powerful signal.

A plausible sequence might be:

Customer complaint
2026-07-01

Slack discussion
2026-07-02

Jira ticket
2026-07-03

Commit
2026-07-07

Release
2026-07-10
Enter fullscreen mode Exit fullscreen mode

But time alone cannot establish causality.

Therefore:

Temporal evidence
≠
Causal proof
Enter fullscreen mode Exit fullscreen mode

It is simply one component of the inference model.

17. Reverse Traversal

One of the most useful features is reverse traversal.

Starting from a release:

Release 4.2
     ↑
Git Commit
     ↑
Jira Ticket
     ↑
PM Decision
     ↑
Slack Discussion
     ↑
Customer Request
Enter fullscreen mode Exit fullscreen mode

The system can answer:

Why does this release contain this change?

This is organizational version history.

Git answers:

How did the source code evolve?

A Causal Work Graph attempts to answer:

How did the work evolve?

18. Forward Traversal

The reverse direction is equally important.

Start with:

Customer Complaint #771
Enter fullscreen mode Exit fullscreen mode

and ask:

What did this cause?

The graph may return:

Customer Complaint
        ↓
Support escalation
        ↓
PM decision
        ↓
Jira #392
        ↓
12 commits
        ↓
Release 4.2
        ↓
3 affected accounts
Enter fullscreen mode Exit fullscreen mode

Now the system is not merely retrieving information.

It is traversing organizational consequences.

19. The UI Should Start With a Question

ThreadWeaver does not need to begin with a complicated dashboard.

The primary interaction can be extremely simple:

┌──────────────────────────────────────┐
│ Why was CSV Import v2 built?         │
└──────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Then:

Customer Request
       ↓
Slack Discussion
       ↓
PM Decision
       ↓
Jira #392
       ↓
7 Git Commits
       ↓
Release 4.2
Enter fullscreen mode Exit fullscreen mode

Every edge is inspectable.

Every inference has a confidence level.

Every important claim has evidence.

20. Explicit Triggers First

Earlier versions of the concept considered implicit intent detection:

mouse movement
scrolling
pauses
cursor behavior
Enter fullscreen mode Exit fullscreen mode

That creates unnecessary technical and privacy risk.

The MVP should use:

hover
click
select
ask
Enter fullscreen mode Exit fullscreen mode

For example:

Hover:

Acme Corp
Enter fullscreen mode Exit fullscreen mode

ThreadWeaver shows:

Acme Corp
│
├── complaints
├── product discussions
├── decisions
├── tickets
└── releases
Enter fullscreen mode Exit fullscreen mode

No behavioral surveillance is required.

21. Permissions Are Graph Data

Enterprise context systems cannot treat authorization as an afterthought.

If a Slack message is private, an edge derived from that message must inherit its visibility constraints.

Conceptually:

Edge
  │
  ├── Evidence A → permission A
  ├── Evidence B → permission B
  └── Evidence C → permission C
Enter fullscreen mode Exit fullscreen mode

The effective visibility of the edge should respect the underlying evidence.

A fundamental invariant becomes:

The graph must never reveal more than the user is authorized to see in the source systems.

22. Security Model

The MVP should use:

OAuth per integration
+
scoped permissions
+
encrypted credentials
+
audit logs
+
source-level authorization
Enter fullscreen mode Exit fullscreen mode

Write operations should initially be disabled.

Version 1 should be:

READ
Enter fullscreen mode Exit fullscreen mode

not:

READ + WRITE
Enter fullscreen mode Exit fullscreen mode

The product should first prove:

"We can reconstruct valuable organizational context."

Only then should it attempt:

"We can modify organizational systems."

23. The MVP Contract

A disciplined MVP could have exactly one promise:

Given a feature or issue, reconstruct the most likely chain of events that explains why it exists.

Input:

Feature / Jira Issue
Enter fullscreen mode Exit fullscreen mode

Output:

Origin
↓
Discussion
↓
Decision
↓
Implementation
↓
Release
Enter fullscreen mode Exit fullscreen mode

Every edge includes:

relationship
confidence
evidence
source
timestamp
Enter fullscreen mode Exit fullscreen mode

That is enough for a first product.

24. The 60-Second Validation Test

The best demo is not:

"Look at our beautiful graph."

It is:

User:

Why did we build CSV Import v2?
Enter fullscreen mode Exit fullscreen mode

ThreadWeaver:

3 customer requests
        ↓
2 Slack discussions
        ↓
1 PM decision
        ↓
1 Jira issue
        ↓
7 commits
        ↓
Release 4.2
Enter fullscreen mode Exit fullscreen mode

User clicks:

PM decision
Enter fullscreen mode Exit fullscreen mode

ThreadWeaver shows:

Confidence: 94%

Evidence:
• Slack #product
• Jira comment #992
• Customer ticket #771
Enter fullscreen mode Exit fullscreen mode

Then the user asks:

What did this decision cause?
Enter fullscreen mode Exit fullscreen mode

The graph traverses forward.

If the experience is compelling without a five-minute explanation, the architecture is doing its job.

25. Measuring Success

The product should avoid generic productivity claims.

Instead, define measurable graph-specific metrics.

Time-to-Why

How long does it take to reconstruct the origin of a decision?

Before: 18 min
After: 42 sec
Enter fullscreen mode Exit fullscreen mode

Lineage Reconstruction Accuracy

How accurately can the system reproduce known historical chains?

Ground truth:
A → B → C → D

System:
A → B → C → D

Accuracy: 100%
Enter fullscreen mode Exit fullscreen mode

Evidence Coverage

Percentage of causal edges backed by inspectable evidence.

False Causality Rate

Percentage of causal claims later judged incorrect.

For this system, minimizing false causality may be more important than maximizing graph completeness.

26. The Hardest Problem Is Not Retrieval

The hardest part is:

Causal inference under incomplete evidence.

Real organizations are messy.

People forget links.

Decisions happen in meetings.

Slack messages disappear into threads.

Tickets are created long after conversations.

Requirements change.

Multiple independent events can produce the same outcome.

Therefore the system must be comfortable saying:

Unknown.
Enter fullscreen mode Exit fullscreen mode

That is not a failure.

It is a trust feature.

A trustworthy lineage system should prefer:

"Insufficient evidence."
Enter fullscreen mode Exit fullscreen mode

over:

"Here is a confident fictional explanation."
Enter fullscreen mode Exit fullscreen mode

27. What Could Become the Moat?

Not the LLM.

Not MCP.

Not PostgreSQL.

Not the UI.

The durable advantage, if the product succeeds, could become:

Organizational Event History
+
Entity Resolution
+
Relationship Ontology
+
Evidence Graph
+
Decision History
+
Outcome History
Enter fullscreen mode Exit fullscreen mode

Over time, ThreadWeaver could accumulate a structured representation of:

What happened
Why it happened
Who decided
What evidence existed
What was implemented
What changed afterward
Enter fullscreen mode Exit fullscreen mode

That is considerably more valuable than a collection of isolated documents.

28. A New Kind of Organizational Memory

Most enterprise knowledge systems answer:

What does the organization know?

ThreadWeaver aims at a different question:

How did the organization arrive here?

That distinction matters.

Knowledge is largely about state.

Lineage is about transition.

And organizations are not static databases.

They are processes.

Problem
   ↓
Discussion
   ↓
Decision
   ↓
Action
   ↓
Outcome
   ↓
New Problem
Enter fullscreen mode Exit fullscreen mode

A Causal Work Graph models that process.

29. ThreadWeaver vs. Traditional RAG

Traditional RAG:

Question
   ↓
Vector Search
   ↓
Documents
   ↓
LLM
   ↓
Answer
Enter fullscreen mode Exit fullscreen mode

ThreadWeaver:

Question
   ↓
Entity Resolution
   ↓
Graph Traversal
   ↓
Evidence Retrieval
   ↓
Causal Constraints
   ↓
LLM
   ↓
Answer + Lineage + Evidence
Enter fullscreen mode Exit fullscreen mode

The difference is not that ThreadWeaver eliminates RAG.

It constrains retrieval with structure.

30. ThreadWeaver vs. a Generic Knowledge Graph

A knowledge graph answers:

What entities are connected?
Enter fullscreen mode Exit fullscreen mode

A Causal Work Graph asks:

What happened?
What happened before it?
What influenced it?
What did it cause?
What evidence supports the relationship?
How confident are we?
Enter fullscreen mode Exit fullscreen mode

The graph becomes a temporal and evidentiary structure rather than merely a collection of semantic relationships.

31. The Architecture in One Picture 

                 SOURCE SYSTEMS

     Slack      Jira      GitHub      Support
       │          │          │           │
       └──────────┴──────────┴───────────┘
                         │
                         ▼
                  Integration Layer
                       MCP/API
                         │
                         ▼
                 Entity Resolution
                         │
                         ▼
                  Event Extraction
                         │
                         ▼
             Relationship Classification
                         │
             ┌───────────┴───────────┐
             ▼                       ▼
        Temporal Edges          Causal Edges
             │                       │
             └───────────┬───────────┘
                         ▼
                 CAUSAL WORK GRAPH
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼
          Traversal   Evidence   Permissions
              │          │          │
              └──────────┼──────────┘
                         ▼
                  Graph-Bounded RAG
                         │
                         ▼
                         LLM
                         │
                         ▼
              Lineage + Explanation
Enter fullscreen mode Exit fullscreen mode

32. The Bigger Idea

The internet gave organizations searchable information.

SaaS gave them specialized systems.

APIs connected those systems.

AI made the information conversational.

The next architectural question may be:

Can AI preserve the relationships that explain how the information became meaningful?

That is the problem ThreadWeaver explores.

Not another universal inbox.

Not another chatbot.

Not another vector database.

A layer for reconstructing organizational causality.

Conclusion

The most valuable context in an organization is often not the document itself.

It is the relationship between events.

A customer complaint becomes a conversation.

A conversation becomes a decision.

A decision becomes a ticket.

A ticket becomes code.

Code becomes a release.

And the release changes the product.

That chain is the organization's operational memory.

ThreadWeaver v3 proposes treating that chain as a first-class computational object:

The Causal Work Graph

Its core principles are simple:

1. Model events, not just documents.
2. Treat edges as first-class objects.
3. Separate similarity from causality.
4. Preserve provenance for every important relationship.
5. Represent uncertainty explicitly.
6. Keep source data under source-system permissions.
7. Bound LLM retrieval by graph structure.
8. Start read-only.
9. Validate with real historical chains.
10. Prefer "unknown" over fabricated causality.
Enter fullscreen mode Exit fullscreen mode

The ultimate question is not:

"Can AI find the information?"

We are increasingly solving that.

The harder question is:

"Can AI reconstruct why the organization moved from one state to another — and show the evidence behind that reconstruction?"

If the answer is yes, organizational memory stops looking like a pile of documents.

It starts looking like a graph of decisions, consequences, and evidence.

And that is the thread ThreadWeaver is trying to weave.

created by Seyed Alireza Alhosseini Almodarresieh

Top comments (0)