Skip to content
Hybrid GraphRAG Wiki & Architecture

EvidenceGate Zero-Trust Security Filter

The Regulatory Problem

In regulated Life Sciences, injecting hallucinated or superseded text into an AI response can lead to critical compliance deviations:

  • A vector database may return an older version of an SOP (e.g. Revision 1.0) because its semantic vector is mathematically closer to the user’s query than Revision 3.0.
  • Unsynchronized vector collections might retain deleted or quarantined documents.
  • Standard RAG architectures have no mechanism to assert whether a retrieved chunk has been legitimately approved under 21 CFR Part 11.

EvidenceGate Architecture (src/retrieval/evidence_gate.py)

EvidenceGate is an active security filter that sits between the vector/graph retrieval layer and the large language model prompt assembly. Every candidate chunk must pass four strict verification checks before it is admitted to the agent’s context window:

[ Retrieved Candidate Chunk ]
             |
             v
+----------------------------+
| 1. Live Existence Check    | ---> Missing in PostgreSQL? ----> [ REJECT & LOG ]
+--------------+-------------+
               |
               v
+----------------------------+
| 2. Cryptographic Integrity | ---> Hash != Live SHA-256? ------> [ REJECT & LOG ]
+--------------+-------------+
               |
               v
+----------------------------+
| 3. Supersession Check      | ---> Status != EFFECTIVE? -------> [ REJECT & LOG ]
+--------------+-------------+
               |
               v
+----------------------------+
| 4. Signature & ACL Check   | ---> Missing Part 11 Signoff? ---> [ REJECT & LOG ]
+--------------+-------------+
               |
               v
  [ ADMITTED TO AGENT CONTEXT ]
  EvidenceGate Badge: VERIFIED

Verification Verification Checks

1. Live Relational Existence Check

The chunk identifier (chunk_id) and parent document identifier (doc_id) are queried directly against PostgreSQL inside an active transaction. If the record has been purged or quarantined, the chunk is dropped immediately.

2. SHA-256 Cryptographic Hash Check

The pre-computed chunk_hash stored in the Qdrant payload is compared against SHA256(chunk_text) computed from the live PostgreSQL relational record. Any discrepancy indicates data drift or vector corruption and triggers an immediate rejection.

3. Document Status & Supersession Filtering

The parent document’s status attribute is inspected in PostgreSQL:

  • EFFECTIVE: Permitted.
  • DRAFT: Permitted only if the user query is explicitly scoped to draft authoring workflows.
  • SUPERSEDED: Rejected. EvidenceGate logs a warning and optionally attempts to substitute the chunk with the corresponding section from the superseding revision.
  • WITHDRAWN: Rejected unconditionally.

4. Part 11 Digital Signature Assertion

For high-impact regulatory documents (Validation Plans, Protocols, Quality Policies), EvidenceGate verifies that an electronic signature record exists in electronic_signatures with is_valid = TRUE.

Telemetry and Audit Logging

Every rejection or admission decision made by EvidenceGate is logged:

  • PostgreSQL: Written to the evidence_gate_audit table.
  • Langfuse: Emits a guardrail span in the active trace, detailing the candidate chunk ID, parent document version, rejection reason, and latency.