REGENT: Recursive Evidence Graph Engine

Implement remaining non-functional requirements (fault tolerance, scalability, model agnosticism, reproducibility, privacy, idempotency)

Failure while processing one source must not corrupt the existing graph (fault tolerance). Support growing numbers of sources, nodes, relationships, graphs, and research sessions (scalability). System should not permanently depend on one LLM provider (model agnosticism). Retain enough metadata to reproduce important graph mutations (reproducibility). Keep private research data isolated according to permissions (privacy). Processing the same source multiple times should not unnecessarily duplicate knowledge, via source/passage/claim fingerprinting and mutation deduplication (idempotency).

Build observability and processing metrics

Monitor: source processing time, extraction latency, graph mutation count, node creation rate, merge rate, conflict rate, failed mutations, model usage, token consumption, retrieval latency, graph size, query latency.

Implement security requirements (auth, tenant isolation, encryption, audit logs)

Support: authentication, authorization, tenant isolation, encrypted storage where appropriate, encrypted transport, access-controlled graphs, source-level permissions, audit logs, secure API access. Private enterprise sources must not become visible to unauthorized users.

Explore Dynamic Research, Enterprise Knowledge OS, and Agent Memory use cases

Continuously update the graph as new information appears (Dynamic Research). Longer-term: Enterprise Knowledge OS (continuously evolving evidence-backed organizational knowledge) and Agent Memory (persistent long-term knowledge for AI agents). Also expose Knowledge Graph APIs so other applications can consume REGENT's graph.

Explore Multi-Agent Research capability

Different agents investigate different graph branches in parallel.

Build Knowledge Gap Detection

Detect: missing entities, missing relationships, unsupported claims, single-source claims, unresolved conflicts, outdated information, contradictory metrics, incomplete branches. Example: if a competitor has known pricing, features, and customer segment but enterprise adoption is unknown, mark enterprise adoption as a research gap.

Build Autonomous Research Loop

Loop: Research objective → Construct initial graph → Identify knowledge gaps → Generate search queries → Retrieve new sources → Process sources → Expand graph → Detect unresolved conflicts → Identify weak evidence → Search again → Repeat until stopping criteria are met. Turns REGENT from a graph builder into a research engine.

Implement learning-from-human-decisions mechanism

Learn from accepted merges, rejected merges, corrected relationships, conflict resolutions, node restructuring, and ontology changes. Human corrections must never silently rewrite historical evidence — they should create explicit graph decisions.

Build human review workflow for high-impact graph decisions

Example: Candidate Operation MERGE, Existing Node "Automated RCA", New Candidate "AI-powered RCA", Confidence 0.86, Evidence Source A/B, Human: Approve/Reject/Modify. Human decisions become part of the audit trail.

FR-024 / FR-025: Identify unsupported and single-source knowledge

FR-024: Identify unsupported knowledge. FR-025: Identify single-source knowledge. Related to Knowledge Gap Detection: missing entities, missing relationships, unsupported claims, single-source claims, unresolved conflicts, outdated information, contradictory metrics, incomplete branches.

FR-023: Show source contributions

FR-022: Compare graph versions

FR-021: Audit mutations

Implement full evaluation metric suite

Metrics: Evidence Coverage (% relevant source claims represented), Provenance Coverage (% graph claims with source traceability), Duplicate Rate, False Merge Rate, False Split Rate, Conflict Recall, Conflict Precision, Mutation Accuracy, Retrieval Accuracy, Answer Grounding (% generated statements supported by graph evidence), Order Stability (similarity between graphs from different source orders).

Define and build Graph API surface

API surface: Create Graph, Add Source, Process Source, Get Graph, Get Node, Get Evidence, Get Provenance, Find Related Nodes, Resolve Node, Get Conflicts, Get Graph Diff, Query Graph, Generate Answer, Explain Claim, Explain Relationship, Get Source Contribution, Reprocess Source, Rollback Mutation.

Implement MVP end-to-end user experience flow

User flow: create a research graph, give it a title, define the research objective, add Source 1, watch the graph form, add Source 2, see what Source 2 contributed, see which existing nodes were expanded, see newly discovered nodes, see conflicts, inspect source provenance, ask questions against the graph, generate a final research report.

Build MVP output surfaces (graph viz, summary, conflict report, provenance inspector)

MVP output scope: graph visualization, source-backed summary, conflict report, provenance inspection. User should be able to observe the graph evolve (see what each new source contributed, expanded nodes, newly discovered nodes, conflicts) rather than receiving only a final answer.

FR-020: Build Answer Generation pipeline (graph-grounded, with citations)

FR-020: Generate reports, summaries, answers, and other outputs from graph evidence. Pipeline: User Question → Graph Query → Relevant Subgraph → Evidence Collection → Conflict Detection → Reasoning → Answer → Citation/Provenance. Raw documents don't need to be passed wholesale to the final model when the graph already represents the required evidence.

FR-018: Build natural-language and structured Query Engine

FR-018: Support structured and natural-language queries, e.g. "What do we know about Company X?", "What evidence supports this claim?", "Which sources disagree about pricing?", "What information was introduced by Source 7?", "Show all claims about Product X.", "Which conclusions depend on this claim?", "What changed after adding the latest source?", "Which claims have only one supporting source?", "What important information has low confidence?"

Build graph-aware retrieval and traversal

Combine semantic similarity, graph neighborhood, node type, relationships, provenance, source reliability, temporal filters, confidence, and research scope. Must support traversal: Node → Relationship → Node → Evidence → Source.

Implement conflict resolution factor scoring

Resolution factors: source authority, source type, publication date, last-updated date, primary vs secondary source, specificity, directness, evidence quality, temporal context, scope, confidence. Must distinguish conflict resolution from conflict suppression. Apparent conflicts may later resolve as temporal or scope differences; if a conflict can't be reliably resolved, both claims remain visible.

Build Conflict Engine (first-class conflict objects)

Represent conflicts as first-class graph objects. If one source says a product supports 1M-token context and another says 2M in beta, the graph retains both claims, their sources, dates, and applicable conditions, rather than automatically selecting one.

Validate order invariance of recursive graph construction

Processing A → B → C → D should produce substantially equivalent knowledge to D → C → B → A, except where differences are justified by temporal information, source weighting, or other explicit factors. Order stability should be a major evaluation criterion.

Build Research Timeline reconstruction

Reconstruct what the system knew after each source, e.g. Source 1 → 12 nodes; Source 2 → +7 nodes, +4 relationships, 1 conflict; Source 3 → +5 nodes, 3 qualifications. Makes the research process observable.

FR-017: Build graph versioning (diffs, mutation history, rollback, audit trail)

FR-017: Version graph state. Support: current graph, previous graph, graph diff, mutation history, source contribution, rollback, audit trail. Every significant graph mutation should be versioned.

Implement temporal knowledge support (versioned attribute history)

Graph must support changing information. Historical values must not automatically overwrite current values. Example: Product X → Price → $100 valid from Jan 2026; Product X → Price → $120 valid from Sept 2026. Both states remain recoverable.

Implement contextual source reliability model

Source reliability is contextual, not absolute — a source may be authoritative for one claim type but weak for another. Support contextual source reliability based on source type and claim type.

Implement multi-level confidence model

Confidence exists at multiple levels: extraction confidence, resolution confidence, relationship confidence, source confidence, conclusion confidence. These should not be collapsed into one universal number.

Implement Derived Knowledge epistemic status classification

Distinguish Observed, Extracted, Normalized, Inferred, Derived, Speculative. Users should be able to see the epistemic status of knowledge.

Implement three-layer evidence architecture (Evidence / Knowledge / Reasoning graphs)

Three conceptual layers must remain distinguishable: Layer 1 Evidence Graph (Source → Passage → Claim → Entity), Layer 2 Knowledge Graph (normalized concepts/relationships), Layer 3 Reasoning Graph (derived interpretations/conclusions). A generated conclusion must never appear indistinguishable from a source-derived fact.

FR-019: Build "Explain this" explainability operation

FR-019: Explain why nodes, relationships, and conclusions exist. Traceable chain: Answer statement → Supporting graph node → Supporting relationship → Evidence claim → Source passage → Original source. Support an "Explain this" operation for nodes, relationships, claims, and conclusions.

FR-016: Build provenance record schema and navigable chain

FR-016: Maintain provenance for graph-derived knowledge. Provenance record fields: Source ID, source type, source title, source URL/identifier, document location, page number, section, paragraph, passage ID, extraction timestamp, extraction method, model used, confidence, transformation history. Navigable chain: Claim → Evidence → Passage → Document → Source.

FR-015: Implement graph integrity validation rules

FR-015: Preserve unresolved conflicting claims (never auto-select one). After mutations, validate: orphan nodes, invalid relationships, circular relationships where prohibited, duplicate nodes, duplicate claims, missing provenance, unsupported claims, impossible hierarchy, inconsistent entity types, unresolved conflicts, provenance gaps. A graph is not valid merely because it was successfully written to storage.

FR-014: Implement contradiction detection, DUPLICATE and IGNORE operations

FR-014: Detect potential contradictions. DUPLICATE: identify redundant candidate. IGNORE: reject information that's irrelevant, duplicate, below threshold, outside scope, or structurally unusable — record the reason where useful.

Implement CONTRADICT, LINK, UPDATE mutation operations

CONTRADICT: new source conflicts with existing claim — never silently overwrite the earlier claim. LINK: connect existing nodes through a newly discovered relationship. UPDATE: update mutable attributes while preserving historical values and provenance.

FR-012 / FR-013: Implement QUALIFY and EXTEND against existing knowledge

FR-012: Extend existing knowledge. FR-013: Qualify claims with limitations, conditions, scope, or exceptions.

Implement CREATE, MERGE, EXTEND mutation operations

CREATE: new node. MERGE: same underlying concept/entity — merge normalized identity while preserving all provenance. EXTEND: new source adds info without changing original knowledge.

Support nested/hierarchical knowledge structures

Example: AI SRE → Incident Management → Root Cause Analysis → Automated RCA → Evidence Correlation → Log Correlation. Avoid unnecessary nesting — a child node should represent a meaningful conceptual subdivision, not just another noun in a sentence.

Define extensible relationship ontology

Initial types: IS_A, PART_OF, HAS, USES, PROVIDES, SUPPORTS, REQUIRES, DEPENDS_ON, CAUSED_BY, RELATED_TO, COMPETES_WITH, CONTRADICTS, QUALIFIES, SUPPORTED_BY, DERIVED_FROM, CREATED_BY, USED_BY.

FR-011: Merge nodes with provenance preservation

Implement entity relationship classification (same/alias/parent-child/subtype/related/similar/unrelated)

E.g. "OpenAI" and "OpenAI, Inc." may resolve to the same entity, while "Root Cause Analysis" and "Automated RCA" may be related but not identical.

Build Similarity Engine

Combine lexical similarity, embedding similarity, entity overlap, contextual similarity, relationship similarity, source context, ontology compatibility, temporal compatibility, and semantic classification. Must not rely exclusively on embeddings.

Implement Node Granularity Algorithm (avoid graph explosion)

Evaluate semantic independence, reusability, query usefulness, relationship potential, evidence independence, hierarchical relevance. Not every sentence should become a node — info without meaningful graph value stays an attribute, claim, or evidence item. Optimize for useful semantic granularity.

FR-010: Create nodes when appropriate

FR-009: Resolve candidate identity

FR-008: Retrieve relevant existing graph context

Implement node creation decision framework

For every candidate node evaluate: exact match, alias match, semantic match, entity match, context match, relationship compatibility, evidence compatibility, temporal context, specificity. Semantic similarity is a candidate-generation signal only, never sufficient proof of identity on its own.

Build Node Creation Engine pipeline

Pipeline: Source → Parse → Segment → Extract candidate evidence → Extract entities → Extract concepts → Extract claims → Extract relationships → Search existing graph → Identify related nodes → Calculate similarity/context → Determine graph operation → Commit mutation. The LLM proposes candidate nodes; the graph engine decides whether they become actual graph nodes.

Apply cost-optimized extraction routing

Minimize LLM calls via deterministic preprocessing, caching, embeddings for candidate retrieval, smaller models for simple extraction, larger models only for ambiguous reasoning, source fingerprints, and incremental processing. Core design principle: never give the model more context than it needs to make the current graph decision — pass relevant passage plus relevant neighboring nodes/relationships/provenance, not the whole source collection or whole graph.

FR-007: Identify candidate relationships

FR-006: Identify claims

FR-005: Identify candidate entities

FR-004: Identify meaningful evidence units (segmentation)

Implement Research Session object

Each research session maintains: objective, scope, sources, graph, mutations, questions, conclusions, final outputs.

Implement source fingerprinting

Stable source identity via canonical URL, document hash, content hash, publisher, publication date, version, retrieved timestamp. Must distinguish source identity from source version for mutable web pages. Supports idempotency: reprocessing the same source should not duplicate knowledge (passage/claim fingerprints, mutation deduplication).

FR-003: Parse supported source formats

MVP input: text, PDFs, web pages. Parsing extracts text, headings, tables, metadata, page boundaries, sections, and supported figures.

FR-002: Add sources to an existing graph

Select and abstract graph storage layer

Evaluate Neo4j, Memgraph, ArangoDB, PostgreSQL with graph extensions, or a custom graph store. Prioritize correctness and dev speed for the initial implementation; abstract storage so the backing graph database can be swapped later (storage agnosticism NFR).

Define initial node ontology

Initial node types: ROOT, SOURCE, ENTITY, CONCEPT, CLAIM, FACT. Extensible ontology to include Person, Organization, Product, Technology, Event, Metric, Problem, Solution, Requirement, Location, Document, Regulation, Conclusion, Conflict.

Define core data objects

Independently addressable objects: Graph, Node, Edge, Source, Passage, Claim, Evidence, Provenance Record, Conflict, Mutation, Graph Version, Research Session, Conclusion.

FR-001: Create a graph with a root node

Root node represents the research objective/domain (e.g. "AI SRE Market Landscape"). Root metadata: graph title, research objective, description, graph ID, owner, creation date, research scope, optional research questions/constraints.