SecureCorpAISign in →
HybridRAG · BM25 + Dense · Reranked

Authorization happens before retrieval.

SecureCorp AI answers questions over enterprise documents and structured records — with hybrid search, cross-encoder reranking, and server-validated citations. Evidence is filtered by who’s asking, never after the fact. Unauthorized chunks reaching the model: 0.

example request

>What is the remote work policy?

user=alice (hr, employee)
tenant=nexacore_main
authz=PASS
route=DOCUMENT_RAG
cache=MISS
evidence=5 chunks
cites=[3, 1, 2, 5]
Observed e2e run · 2026-08-12
275documents ingested§9b · from 260 Markdown files
450retrieval chunks§9b · one BM25 + dense corpus
124,472body tokens (exact)§9b · MiniLM tokenizer
6application roles§11 · RBAC
The path

What actually happens to a query

Every request runs the same pipeline: authenticate, authorize, then route to hybrid document search, an authorized SQL path, or a safe refusal — before any evidence reaches the model. This is the real component the chat surface animates live.

Request pipeline — authorization before retrieval

idle

Authorization is enforced before retrieval, SQL, and generation.

Retrieval

Hybrid search, not just vectors

Dense retrieval alone misses exact identifiers — invoice numbers, policy codes, employee IDs. BM25 catches them. The two ranked lists fuse with Reciprocal Rank Fusion, then a cross-encoder reranks the bounded candidate set.

Hybrid pipeline

1
BM25

Exact identifiers, policy codes, acronyms

2
Dense

Semantic similarity over 384-dim vectors

3
RRF

Reciprocal Rank Fusion by unique chunk_id, k=60

4
Rerank

Cross-encoder on the bounded candidate set

RRF k=60·BM25 k1=1.5 b=0.75·384-dim cosine

Why BM25 earns its place

Diagnostic probe

Probing all 40 identifiers that occur in exactly one chunk — asking each retriever for the chunk containing it:

BM25 hit@140/40
Dense hit@14/40

Diagnostic probe over 40 single-chunk identifiers — not the Phase 8 evaluation.

Security

Authorization at the boundary

Roles and tenants are enforced in application code and the data-access layer — never inferred by the LLM. The client-supplied role is never trusted; the authenticated identity comes from a verified server-side token.

The invariant

0

unauthorized chunks reach the model context. Authorization is enforced at the data-access boundary — before retrieval, SQL, and generation — never by trusting the LLM.

§5 · Architecture invariants

Role-based access

employeemanagerhrfinanceitadmin

Six application roles, plus attribute rules (ownership, manager scope) layered on top. A document’s allowed_roles and classification travel with every chunk.

Tenant isolation

Enforced
nexacore_main
nexacore_global

Every row and chunk carries a tenant_id; the structured query path filters on it at the boundary. A query for another tenant’s record resolves to not found, not a leak.

Evidence

Answers you can trace back

Citations are validated server-side and resolve to real indexed chunks or structured records. Structured questions take the SQL route; document questions take hybrid retrieval. Both return evidence you can open.

Citations resolve to evidence

The model may cite only evidence IDs the application supplied. Every returned citation is validated server-side and must resolve to an indexed chunk — unknown IDs are rejected. If evidence is insufficient, the system abstains instead of fabricating.

[3]HR-003:v1:0000
structured query · example

>What is the total of invoice INV-2026-0108?

user=bob (finance, employee)
authz=PASS
route=STRUCTURED_SQL
cache=MISS
db=PostgreSQL (template SQL)
answer=The total of invoice INV-2026-0108 is $8,869.26.
Observed e2e run · 2026-08-12

Sign in and ask it something.

Six pre-seeded demo accounts, one per role. Watch the request pipeline animate live as your question is authorized, routed, retrieved, and cited.

Or sign in instantly as a demo user

Loading demo accounts…