<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Arthit P.</title>
    <description>The latest articles on DEV Community by Arthit P. (@arthit_p_ee593ec801bb01a).</description>
    <link>https://dev.to/arthit_p_ee593ec801bb01a</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3796912%2Fb6ee609a-b024-42e4-89e9-ca01cc1b8153.png</url>
      <title>DEV Community: Arthit P.</title>
      <link>https://dev.to/arthit_p_ee593ec801bb01a</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/arthit_p_ee593ec801bb01a"/>
    <language>en</language>
    <item>
      <title>Governance First RAG</title>
      <dc:creator>Arthit P.</dc:creator>
      <pubDate>Sat, 25 Apr 2026 22:06:17 +0000</pubDate>
      <link>https://dev.to/arthit_p_ee593ec801bb01a/governance-first-rag-58ek</link>
      <guid>https://dev.to/arthit_p_ee593ec801bb01a/governance-first-rag-58ek</guid>
      <description>&lt;p&gt;&lt;a href="https://dev.tourl"&gt;&lt;/a&gt;Governance‑First! Before Retrieval? Most RAG pipelines are still built the old way: retrieve broadly → filter → hope nothing leaks&lt;/p&gt;

&lt;p&gt;That pattern is convenient, but in multi‑tenant or regulated workloads it’s structurally unsafe. Once the model has already seen unauthorised embeddings, you’ve lost the guarantee.&lt;/p&gt;

&lt;p&gt;TenantSage flips the pattern: , tenant scope, and legal‑hold rules are applied before retrieval, so restricted content never reaches the ranking step — and never touches the model.&lt;/p&gt;

&lt;p&gt;Why Post‑Filtering Fails in Multi‑Tenant RAG&lt;br&gt;
When filtering only happens after semantic retrieval, several predictable risks emerge:&lt;br&gt;
• Permission drift&lt;br&gt;
Embedding chunks don’t automatically update when source permissions change.&lt;br&gt;
• Cross‑tenant leakage&lt;br&gt;
Similarity search doesn’t respect tenant boundaries unless enforced upfront.&lt;br&gt;
• Legal‑hold exposure&lt;br&gt;
Restricted documents can still enter the candidate set before filtering removes them.&lt;br&gt;
• Weak auditability&lt;br&gt;
You can’t reliably prove why the model was allowed to see a given document.&lt;br&gt;
If you can’t prove it, you can’t certify it — which is a nonstarter for regulated workloads.&lt;/p&gt;

&lt;p&gt;The Shift: The Database Enforces Governance (Not the LLM)&lt;br&gt;
TenantSage pushes governance into the retrieval layer itself:&lt;br&gt;
• Identity‑derived scoping&lt;br&gt;
Tenant + role pulled directly from the auth token.&lt;br&gt;
• Policy predicates applied before ranking&lt;br&gt;
Only authorized content is even considered during retrieval.&lt;br&gt;
• Deterministic audit logs&lt;br&gt;
Every retrieval decision becomes explainable and reproducible.&lt;br&gt;
This moves safety from “application‑layer hopes and prayers” to data‑layer guarantees.&lt;/p&gt;

&lt;p&gt;Real-Time Inheritance: No More Chunk-Level Permissions&lt;br&gt;
A key design choice: chunks don’t carry their own authorization state.&lt;br&gt;
Instead:&lt;br&gt;
• Each chunk inherits visibility from its parent document at query time.&lt;br&gt;
• When the document’s policy changes, the retrieval view updates instantly.&lt;br&gt;
• No re‑indexing and no permission drift.&lt;br&gt;
This eliminates the classic “embedding index is out of sync with ACLs” problem.&lt;/p&gt;

&lt;p&gt;High‑Level Retrieval Path&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Authenticate
Derive tenant, role, and policy context from the identity token.&lt;/li&gt;
&lt;li&gt;Governed retrieval
Similarity search + policy rules execute in a single governed path:
• tenant scoping
• role‑based access
• retention and legal‑hold predicates
all applied before ranking&lt;/li&gt;
&lt;li&gt;Generate
The LLM only receives prompts assembled from the authorized set.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;What This Enables&lt;br&gt;
• Pre‑retrieval policy enforcement&lt;br&gt;
No more “retrieve then panic‑filter.”&lt;br&gt;
• Strong family tenant isolation&lt;br&gt;
Cross‑tenant retrieval returns zero results by design.&lt;br&gt;
• Legal‑hold quarantine&lt;br&gt;
Held documents stay stored but never retrievable.&lt;br&gt;
• No permission drift&lt;br&gt;
Authorization always reflects source‑of‑truth policies.&lt;br&gt;
• Audit‑ready behavior&lt;br&gt;
Deterministic logs ensure compliance and traceability.&lt;/p&gt;

&lt;p&gt;Family‑Tenant is TenantSage’s canonical multi‑tenant architecture pattern (Family → Child).&lt;/p&gt;

&lt;p&gt;Related repositories&lt;/p&gt;

&lt;p&gt;TenantSage core: &lt;a href="https://github.com/arty-hospitality/TenantSag_Canonical" rel="noopener noreferrer"&gt;https://github.com/arty-hospitality/TenantSag_Canonical&lt;/a&gt;&lt;/p&gt;

</description>
      <category>ai</category>
      <category>architecture</category>
      <category>rag</category>
      <category>governance</category>
    </item>
  </channel>
</rss>
