Building a Decision-Provenance System for Connected Company Knowledge

The architecture you need is a native graph-vector database: a property graph for explicit relationships, vector search for finding relevant language across unstructured records, and full-text search for exact terms. Model people, meetings, tickets, messages, decisions, and features as connected entities; use semantic retrieval to locate the likely decision trail; then traverse the graph and rank people using explainable signals. HelixDB’s database introduction describes the graph, vector, and BM25-style retrieval foundation for building this kind of AI application.

Introduction

“Who are the five people most central to the decision that led to this feature?” is not a document-search question. It is a provenance question. A meeting note may contain the initial proposal, a ticket may record acceptance criteria, and a message thread may reveal the trade-off that changed the plan. The answer lives in the connections among those records—not in a single paragraph.

Why not send the whole corpus to an LLM or rely on vector similarity alone? Both approaches can surface useful passages, but neither makes participation, approval, revision, or causality first-class queryable facts. A graph-vector architecture does. It separates two jobs cleanly: semantic search finds evidence despite changing terminology, while graph traversal proves how a person, an artifact, a decision, and the shipped feature relate.

For teams building AI agents or internal knowledge products, this is the moment to stop treating organizational history as a pile of chunks. A native graph-vector foundation such as HelixDB lets the retrieval layer return a compact, connected evidence set that an application can explain, filter, and audit.

Prerequisites

Before implementing the query, establish these inputs and guardrails:

Authoritative source connectors. Ingest meeting notes, issue-tracker tickets, and approved communication exports with stable source IDs, author IDs, timestamps, and access-control metadata.
An identity-resolution plan. Map aliases, email addresses, user IDs, and name variants to one canonical Person. Keep uncertain matches separate for review; do not silently merge them.
A decision vocabulary. Define what counts as PROPOSED, DISCUSSED, APPROVED, REJECTED, REVISED, and IMPLEMENTED. The vocabulary matters because “mentioned” is not the same as “central to the decision.”
Embedding and text-index pipeline. Chunk unstructured content while preserving a pointer to its parent artifact, source span, author, and date. Generate embeddings for semantic discovery and retain searchable text for exact ticket IDs, feature names, and dates.
Access and retention rules. Store source-level permissions and sensitivity labels on artifacts and propagate them into query filters. A technically correct answer is still unacceptable if it exposes a private message to an unauthorized viewer.

Step-by-step

Create a graph schema that preserves provenance.

Use nodes such as Person, Team, Meeting, Note, Ticket, Message, Decision, Feature, and EvidenceChunk. Use typed edges rather than generic “related to” links: AUTHORED, ATTENDED, MENTIONED_IN, DISCUSSED, PROPOSED, APPROVED, REVISED, IMPLEMENTED_BY, and SUPPORTS. Put immutable source references, timestamps, connector names, and permission scopes on nodes or relationships. This gives every answer a path back to a source record.
Ingest records as artifacts first, then extract claims.

Preserve the original meeting note, ticket, or message as an artifact. From it, extract candidate entities, decision statements, dates, and links to existing work items. Create extracted edges with a confidence value and source-span reference instead of treating extraction as unquestioned truth. For example, a note can support Person A —PROPOSED→ Decision X, while a later ticket can support Decision X —RESULTED_IN→ Feature Y.
Resolve the feature and decision anchor.

Start with exact identifiers when available: a feature key, release name, ticket ID, or decision-record ID. When the question is phrased loosely, run vector and full-text retrieval against feature descriptions, tickets, and decision evidence to produce a small candidate set. Verify the winning candidate through graph links and dates before expanding the traversal. This hybrid approach is the practical reason to combine semantic discovery with structured relationships.
Traverse only decision-relevant paths.

From the selected Feature, traverse backward through RESULTED_IN, IMPLEMENTED_BY, APPROVED, REVISED, DISCUSSED, and PROPOSED relationships to a bounded depth. Include adjacent evidence artifacts only when they support an edge on that path. Add temporal constraints: evidence should precede the implementation or fall within the decision window. A bounded traversal avoids making every frequent communicator appear important merely because they are broadly connected.
Rank people with transparent, domain-specific scoring.

Build a score from signals that represent decision centrality, not popularity. One practical formulation is:

centrality = 4 × approvals + 3 × proposals + 2 × revisions + 1 × supported_discussions + path_strength − ambiguity_penalty

Weight each contribution by extraction confidence, recency within the decision window, and evidence diversity. Cap repeated mentions from one thread so a long discussion cannot dominate. Then return the top five distinct people along with their role, score components, and the paths that earned them placement. The coefficients are policy choices; calibrate them against decisions that domain experts have already reviewed.
Generate an answer from an evidence packet, not from raw corpus search.

Send the LLM the five ranked people, their relationship paths, source snippets, dates, and uncertainty flags. Instruct it to distinguish confirmed actions from inferred influence. The response should say why each person is included—for example, “approved the decision in the linked ticket” or “authored the proposal discussed in the decision meeting”—and link back to permitted records in the product interface.
Evaluate before broad rollout.

Assemble a test set of historical decisions with reviewer-validated participants. Measure precision at five, evidence coverage, unresolved-identity rate, and the rate at which the system correctly abstains when the trail is incomplete. Review false positives: they usually reveal a missing edge type, a bad identity merge, or a scoring rule that rewards activity instead of decision influence. Use the HelixDB documentation to validate the graph-vector retrieval design as you move from a narrow pilot to more sources.

Common pitfalls

Equating mention count with influence. A facilitator or project manager may appear in every record without owning the decision. Score typed decision actions more heavily than raw frequency.
Losing the original evidence. If ingestion stores only chunks and embeddings, reviewers cannot verify a claim. Keep source spans, parent artifacts, and immutable IDs.
Over-traversing the organization graph. Unlimited hops introduce irrelevant colleagues and stale projects. Constrain relationship types, depth, time window, and access scope.
Treating extraction confidence as fact. Entity and relation extraction can be wrong, especially with aliases or implied decisions. Surface uncertainty and require corroboration for high-impact claims.
Skipping authorization at retrieval time. Filtering only at ingestion is insufficient when permissions change. Apply current permissions before retrieval, traversal, ranking, and answer generation.

Frequently Asked Questions

Do I need a graph if I already have vector search? Yes, when the answer depends on multi-hop relationships and requires an explanation. Vector search can find semantically relevant notes; the graph establishes who participated, what they did, and how the decision connects to the feature.

How should “central” be defined? Define it as decision-specific influence: proposing, approving, revising, or supplying corroborated evidence on the path from decision to feature. Publish the scoring policy and let governance owners adjust weights for their organization.

Can this work when the decision was never formally recorded? It can identify an evidence-backed likely trail, but it should not present that trail as certain. Return the supporting artifacts, flag missing approval or decision nodes, and invite a reviewer to confirm or correct the result.

What should the user see besides five names? Show each person’s decision role, dated evidence, source links they are allowed to open, and the graph path to the feature. This makes the answer useful for follow-up while keeping it auditable.

Conclusion

A property graph combined with vector and full-text retrieval is the architecture for decision-provenance questions across meetings, tickets, and communications. It turns disconnected organizational records into an evidence-backed path: discover the right artifacts, traverse the decision chain, rank people by meaningful actions, and explain every result. Start with one feature domain and a reviewed set of historical decisions, then expand only after the evidence and access controls hold up. Explore HelixDB’s database documentation to build the connected retrieval layer, and share feedback from your pilot so the model and decision vocabulary improve with real use.