CORTEX
Enterprise AI Knowledge Platform
One intelligent layer across your organization's knowledge.
Let your team ask questions of everything the company knows and get answers they can actually check.
- Hybrid retrieval
- Reranking
- Knowledge graph
- Entitlement filtering
- Groundedness eval
Document ingestion, retrieval and a knowledge graph behind an answer engine that cites its sources and respects the permissions of whoever asked.
What the product is built around.
CORTEX is built around the retrieval problem rather than the generation problem. Documents are parsed structurally, permissions are enforced at retrieval time per user, and every claim in an answer traces back to the passage that supports it. If the corpus does not support an answer, the system says so.
Citations are mandatory
Claims are grounded in retrieved passages. An unsupported sentence is flagged rather than shipped, and the user can open the exact source span.
Permissions at retrieval, not display
The retrieval set is filtered by the asker's entitlements before the model sees anything, so the model cannot leak what the user cannot read.
Graph plus vectors
Entity relationships supplement semantic similarity, so 'which policy supersedes this' is answerable — a question pure vector search cannot handle.
What makes this hard.
An organisation's knowledge is spread across a wiki nobody updates, a drive nobody can search, six years of tickets and a lot of PDFs. General-purpose assistants make this worse: they answer confidently from the wrong document, or from no document, and they have no idea who is allowed to see what.
- 01
Answers cannot be trusted because there is no way to check where they came from
- 02
Retrieval returns the most similar chunk, not the most authoritative one
- 03
Permissions are enforced on the file store but not on the AI that read it
- 04
Superseded documents are retrieved alongside current policy with equal weight
- 05
Nobody can tell whether answer quality is improving or getting worse
What the system does.
CORTEX is built around the retrieval problem rather than the generation problem. Documents are parsed structurally so tables and headings survive, entitlements are applied as a retrieval filter per user before the model sees anything, and every claim traces back to the passage that supports it. When the corpus does not support an answer, the system says so instead of guessing.
Span-level citations on every claim, with the source openable in one click
Permissions enforced at retrieval, so the model cannot leak what a user cannot read
Hybrid dense and lexical retrieval with reranking and recency weighting
Knowledge graph answers supersession questions pure vector search cannot
Explicit refusal below a groundedness threshold, measured by an eval suite
CORTEX, as working interface.
Rendered UI, not a mockup — real tables, charts, filters and states. Try ⌘K for the command palette.
Documents
48,291
Active agents
24
Queries (30D)
12,842
Groundedness
96.4%
Answer — grounded with span-level citations
What is our current data-retention requirement for customer support transcripts, and did it change this year?
Retrieval trace
Hybrid retrieval · 42 candidates from 3 collections
Permission filter · 6 documents excluded (Legal-restricted)
Reranked to 8 passages · recency weighting applied
Graph lookup · supersession edge found on DRP-v3 → DRP-v4
Support transcripts must be retained for 24 months from the date of the last customer interaction, then deleted within a 30-day window 1. This replaced the previous 36-month requirement in March 2.
Two exceptions apply. Transcripts attached to an open dispute are retained until the dispute closes plus 12 months 1, and EU-resident transcripts follow the regional annex, which caps retention at 18 months 3.
The change was driven by the revised regional annex rather than a policy preference, so the 24-month figure is a ceiling, not a target 3.
Sources
- [1]Data Retention Policy v4 — §4.2 Support recordsp. 11 · current
- [2]Policy changelog — DRP v3 → v4Mar 2026
- [3]Regional Annex EU — §2.1 Retention capsp. 4 · current
Retrieval trace
- Candidates
- 42
- Permission-filtered
- 6 excluded
- Reranked to
- 8 passages
- Graph hops
- 1 (supersession)
- Groundedness
- 0.98
- Unsupported claims
- 0
- Latency
- 1.42s
- Model
- reasoning · tools off
Source systems
| Source | Type | Documents | Chunks | Last sync | Coverage | Permissions | Status |
|---|---|---|---|---|---|---|---|
| Company Drivedrive.internal | Files | 21,480 | 418,204 | 4 min ago | 98% | Inherited | Healthy |
| Engineering Wikiwiki.internal | Wiki | 8,942 | 164,880 | 11 min ago | 100% | Inherited | Healthy |
| Support Desktickets.internal | Tickets | 12,604 | 241,208 | 2 min ago | 94% | Scoped | Healthy |
| Legal Repositorylegal.internal | Files | 3,182 | 88,410 | 1 h ago | 100% | Restricted | Healthy |
| Product Specsspecs.internal | Wiki | 1,842 | 42,180 | 18 min ago | 91% | Inherited | Healthy |
| Shared Mailboxesmail.internal | 241 | 6,104 | 6 h ago | 44% | Scoped | Degraded |
Coverage is the share of documents successfully parsed and embedded · counts shown for illustration
Knowledge graph — policy supersession
1-hop from DRP v4- Current policy
- Superseded
- Annex
- Referencing doc
Evaluation suite
last run 9 min ago- Groundedness96.4%
- Retrieval hit@591.2%
- Citation precision94.1%
- Refusal correctness88.6%
- Permission leakage0 / 4,200
Query intent mix
30DAnswer quality over time
groundedness · 90DIngestion queue
- Q3 board pack.pdfParsed · 84 pages · 12 tables preservedindexed
- Vendor MSA (scan).pdfOCR required · layout confidence 0.71processing
- Architecture review.docxParsed · 4 diagrams captioned by vision modelindexed
- pricing-model.xlsx12 sheets · formulas resolved to valuesindexed
- onboarding.mp4Unsupported type · transcription not enabledskipped
- Runbook v8.mdSupersedes v7 · graph edge createdindexed
Retrieval configuration
yamlretrieval: strategy: hybrid # dense + BM25, fused with RRF dense: top_k: 40 min_score: 0.62 lexical: top_k: 40 rerank: model: cross-encoder keep: 8 recency: half_life_days: 180 # policy docs decay slowly graph_expansion: enabled: true edges: [supersedes, annex_of, references] max_hops: 1answering: require_citations: true refuse_below_groundedness: 0.70 max_context_passages: 8Permission enforcement log
- 6 documents excluded14:02:11
Legal Repository · asker lacks legal-restricted entitlement
- Entitlements resolved14:02:11
Engineering · L4 · 3 groups · inherited from source systems
- Refusal issued13:58:40
Groundedness 0.41 below threshold · no answer generated
- Entitlement change synced13:41:22
User removed from finance-read · retrieval scope narrowed immediately
- Evaluation gate passed12:20:05
Reranker config change · 0 permission leaks across 4,200 probes
Interface states
UI statesNo sources connected
Connect a drive, wiki or ticketing system to build your knowledge layer.
Add sourceEmpty stateCannot answer from available sources
Retrieved passages scored 0.41 groundedness, below the 0.70 threshold. No answer was generated rather than guessing.
How it is put together.
Permission filtering happens before the model sees anything. It is a retrieval concern, never a post-processing step.
- 01
Data Sources
Drives, wikis, ticketing, email and object storage with entitlement metadata.
- Connectors
- OAuth
- Incremental sync
- 02
Ingestion
Change detection, deduplication, OCR routing and rate-limited crawling.
- Python
- Queue
- Content hashing
- 03
Parsing
Layout-aware extraction preserving tables, headings and reading order.
- Layout models
- OCR
- Structured chunking
- 04
Embeddings
Chunk embedding with versioned models and lexical index construction.
- Embedding models
- BM25
- Batch pipeline
- 05
Vector + Graph Store
ANN index alongside an entity graph of relationships and supersession.
- pgvector
- Graph store
- Hybrid index
- 06
Retrieval
Entitlement filtering, hybrid fusion, reranking and graph expansion.
- RRF
- Cross-encoder
- Entitlement filter
- 07
LLM
Constrained generation over retrieved passages with citation binding.
- LLM
- Structured output
- Grounding check
- 08
Answer + Citations
Span-level citations, groundedness score and explicit refusal path.
- Span alignment
- Evaluation
- Feedback loop
What the product does.
The capability set the demonstration is built around.
Document ingestion
Connectors for drives, wikis, ticketing and email with incremental sync.
Structural parsing
Layout-aware extraction preserving tables, headings and document hierarchy.
Hybrid retrieval
Dense and lexical retrieval with reranking and recency-aware scoring.
Knowledge graph
Entity and relationship extraction enabling multi-hop and supersession queries.
Permissions
Entitlement-aware retrieval inherited from the source system per user.
Cited answers
Span-level citations with confidence and an explicit refusal when unsupported.
Evaluation
Groundedness, retrieval hit rate and regression suites on every config change.
Challenges, and the MaatX approach.
The problems that actually decide whether a system like this survives production — and how we address each one.
Hallucination control — the model will answer even with nothing to go on
Answers are constrained to retrieved passages and scored for groundedness before delivery. Below threshold the system refuses and says what it could not find, which is a better product than a confident guess.
Permissions must hold without duplicating every ACL
Entitlements are synced from source systems and applied as a retrieval filter per request. The index is shared; the visible slice is per user, so there is one copy of the data and no second ACL to drift.
Semantic similarity retrieves the most similar chunk, not the right one
Hybrid retrieval fuses dense and lexical results, then a cross-encoder reranks. Recency weighting and supersession edges push current policy above the superseded version that reads almost identically.
Chunking destroys the structure that made the document readable
Parsing is layout-aware and chunks respect section boundaries, keeping tables and headings intact. A chunk carries its heading path so the model knows where it sits in the document.
Nobody can tell whether a config change made answers better or worse
A labelled evaluation set runs on every change, measuring groundedness, retrieval hit rate, citation precision and permission leakage. Regressions block rollout.
The stack behind it.
Source connectors
- Connectors
- OAuth 2.0
- Incremental sync
- Content hashing
- Deduplication
- Object storage
- Queue workers
Parsing & enrichment
- Layout models
- OCR
- Vision captioning
- Structured chunking
- Heading-path metadata
- Entity extraction
- Relationship extraction
Index & storage
- Embedding models
- Versioned embeddings
- Batch re-embedding
- BM25 lexical index
- PostgreSQL
- pgvector
- Graph store
Retrieval & ranking
- Hybrid retrieval
- Reciprocal rank fusion
- Cross-encoder reranking
- Entitlement filtering
- Recency half-life weighting
- Graph expansion
- Supersession edges
Grounded answering
- LLM
- Structured output
- Span alignment
- Citation binding
- Groundedness scoring
- Refusal threshold
Evaluation & feedback
- Labelled eval sets
- Retrieval hit@k
- Citation precision
- Permission-leakage probes
- Regression gating
- Answer feedback loop
Platform & workspace
- Python
- Node.js
- Kubernetes
- Next.js
- React
- TypeScript
- Streaming UI
How it grows with the business.
The same system at three stages. Most products should not start at the third — but the architecture should not have to be thrown away to get there.
One source, one team, with citations and refusal working from the start.
- Single source connector
- Structural parsing and chunking
- Dense retrieval with citations
- Groundedness threshold and refusal
Organisation-wide knowledge with permissions and measured quality.
- Multiple connectors with incremental sync
- Entitlement-aware retrieval
- Hybrid retrieval plus cross-encoder reranking
- Evaluation suite gating config changes
Governed deployment with graph reasoning and agentic research.
- Knowledge graph with supersession edges
- Agentic research over sub-queries
- Self-hosted deployment for regulated environments
- Proactive briefings when a depended-on policy changes
Where it could go next.
Directions this system would extend into.
- 01
Agentic research mode that decomposes a question into sub-queries
- 02
Answer-level feedback loop that retrains reranking on real usage
- 03
Multi-modal retrieval over diagrams, screenshots and recordings
- 04
Proactive briefings when a policy a team depends on changes
- 05
Self-hosted deployment for regulated environments
Need answers from internal documents that cite their evidence and respect who is allowed to see what?
We built CORTEX to work through exactly this. Tell us where you are and we will tell you what we would do differently for your constraints.