Perspective · Architectural Comparison
RAG vs Axowl: Two Definitions of Integrity.
Axowl is designed as the default retrieval layer for enterprise data — deterministic, cryptographically integral, and AI-free at the engine. Retrieval-Augmented Generation (RAG) remains appropriate where paraphrase recall over open-ended natural-language queries is the primary value. This page makes the boundary explicit.
Talk to architecture team Read whitepaper
Compared RAG · Adaptive Chunking (LREC 2026) · Axowl
Audience Architecture · Data Platform · Retrieval
01 · Cost Asymmetry
Where each paradigm's costs come from
The cost structure of the two paradigms is fundamentally different. RAG's costs scale with corpus size, token volume, and the cadence of embedding-model upgrades — three multiplicative factors. Axowl's costs are I/O-bound, model-independent, and largely independent of corpus size.
RAG · Adaptive Chunking
Axowl
Indexing (per document)
Embedding API call — typically $0.02 to $0.13 per 1M tokens at provider list price (OpenAI text-embedding-3 family, 2026)
SHA-256 hash compute only — CPU, no external API
Re-indexing (model update)
Re-embed the entire corpus when the embedding model changes — recurring at every provider upgrade or vendor switch
None — chunking and sealing are model-independent
Storage
Vector blobs (typically 1,536–3,072 dimensions × 4 bytes per dimension) plus a vector database (Pinecone, Weaviate, pgvector, Qdrant)
Hash plus chunk metadata (typically under one hundred bytes per chunk ) in Postgres
Query (per query)
One embedding call per query plus vector-search compute
One LLM call for term expansion (General tier) plus Postgres FTS — or zero AI cost at Defense / Iron tiers
Infrastructure
Vector database hosting — managed (Pinecone Starter from $70/month) or self-hosted GPU / CPU pool
Existing Postgres — no additional infrastructure required
Vendor lock-in
Embedding-provider change requires full re-embed of the corpus
No vendor-specific embeddings; term expander is swappable per tier
Reproducibility across time
Requires archiving the exact embedding model version to reproduce a past result
Same input always yields the same Merkle root and the same retrieval result — by construction
For an illustrative corpus of 100,000 documents at an average of 1,000 tokens each, initial RAG indexing on the text-embedding-3-large model lists at roughly $13 in API charges, before storage and re-embeds; subsequent model upgrades multiply that figure by the number of upgrade cycles over the corpus lifetime. Axowl performs the same initial indexing without any external API call, and does not re-index when a model upgrade is announced.
Pricing references are taken from public provider list prices as of 2026 and are illustrative. Each deployment differs in token mix, query rate, and re-embed cadence. The architecture team can produce a corpus-specific comparison on request.
02 · Framing
Axowl is the enterprise default. RAG is a defined niche.
Axowl is designed as the default retrieval layer for enterprise data — datasets with stable terminology, reproducibility requirements, or integrity constraints. The pattern — deterministic chunking, cryptographic sealing, AI-free lexical retrieval — is not domain-bound. It handles the majority of enterprise retrieval workloads independently.
RAG is a six-year industry standard (Lewis et al., NeurIPS 2020). Adaptive Chunking (LREC 2026) is a recent optimization within it. RAG remains the appropriate choice where paraphrase recall over open-ended natural-language queries is the primary value — exploratory question answering, cross-document summarization, concept discovery.
This page makes the boundary explicit. Where RAG is appropriate, RAG is appropriate. The remainder — and it is most enterprise data — is Axowl territory.
Scope: this page documents two paradigms for retrieval over enterprise private corpora. External general-knowledge question answering ("what are the trends in this field?") is the domain of LLMs themselves and is outside the scope of this comparison — neither RAG nor Axowl is the appropriate tool for it.
03 · Definitions
Two definitions of "integrity"
The same English word denotes two unrelated properties in these two paradigms. Confusing them is the most common source of architectural error we observe.
RAG · Adaptive Chunking
Semantic Integrity
A chunk is "integral" when its internal text is semantically coherent and its cross-references resolve. Adaptive Chunking measures this with metrics such as Intrachunk Cohesion, Context Coherence, Block Integrity (structural), and Reference Error. The property is a function of meaning, evaluated by embedding similarity or structural parsing.
Axowl
Cryptographic Integrity
A chunk is "integral" when its bytes have not changed since it was stored. Axowl measures this with a Merkle root computed over deterministic leaves and compared in constant time. The property is a function of bit-identity, independent of meaning. A single bit flip is detectable; semantically equivalent rewording is not preserved.
04 · Side-by-Side
Where each paradigm answers a different question
RAG · Adaptive Chunking
Axowl
Primary purpose
Maximize retrieval accuracy on free text
Reproducible retrieval with cryptographic integrity
Chunk boundary
Method × metric grid, selected per document
Deterministic — fixed-size or natural-boundary chunks
Storage format
Free text plus embedding vectors
Hash-chained chunks with deterministic byte layout
Integrity guarantee
None at the storage layer
Merkle root verified in constant-time comparison
Retrieval mechanism
Embedding cosine similarity
Lexical full-text search with deterministic ranking
Reproducibility across time
Depends on embedding model version
Same input always yields the same Merkle root and the same result
Provenance of result
Not preserved at the retrieval layer
Cryptographic proof attached to every retrieved item
Operational cost profile
Scales with corpus × embedding rate × re-embeddings
I/O-bound; AI cost is per-query, not per-document
05 · Observations
Three structural observations
These are not criticisms of RAG — they are properties of the value function it optimizes. Each observation explains a question RAG was not designed to answer.
Retrieval accuracy and cryptographic integrity are not the same metric
Adaptive Chunking's Reference Error metric measures whether internal cross-references survive the chunking process. It does not measure whether the chunk content itself remains as it was at the time of writing. A retrieval pipeline returning a tampered or silently re-edited chunk is, by its own metrics, still functioning correctly. Cryptographic integrity is a property the layer was never asked to provide.
Per-document method selection introduces a kind of non-determinism
Selecting the best chunking method per document is well-motivated for retrieval accuracy. It does mean, however, that the same document may be chunked differently across time as the method or metric pool evolves. For use cases where a question of the form "what did this dataset look like at time t , in what units" must yield a single canonical answer — reconciliations, historical comparisons, defensible exports, versioned archives — this kind of evolution is incompatible with the underlying reproducibility guarantee. Axowl resolves the conflict by treating chunking as a deterministic operation by construction.
Semantic coherence and cryptographic proof share a word, not a definition
Adaptive Chunking's Block Integrity metric describes structural coherence of formatted content — code blocks, tables, and lists not broken across chunks. Axowl's integrity describes byte-identity preserved across time under cryptographic sealing. Both are reasonable, both are useful — and they answer questions in different parts of the stack.
06 · Honest Limitation
Axowl does not perform semantic retrieval — by design
Within the value function Axowl optimizes — reproducible retrieval with cryptographic integrity — "similar meaning" is not a property that can be guaranteed across model versions. The appropriate retrieval metric is lexical precision, not semantic recall.
Axowl's retrieval engine therefore uses lexical full-text matching exclusively. For datasets with stable terminology — which describes most enterprise data — lexical retrieval matches user intent precisely, and term expansion (§07) handles ordinary variation in synonyms and morphology. Where paraphrase recall over open-ended natural-language queries is the dominant requirement, RAG is the appropriate tool; that boundary is documented in §09.
07 · Where AI Is Used
Exactly one location: query-time term expansion
AI participates in one place in the Axowl retrieval pipeline. When a user enters a search query, an LLM proposes synonym candidates, which are then folded into a lexical full-text query. The proposed terms are surfaced in the UI for the user's confirmation. The chunking path, the sealing path, the retrieval engine, and the integrity-verification path are entirely AI-free.
Tier-stratified term expanders allow the integration to be substituted by an organization's policy: a local synonym dictionary at the Standard tier, and a no-op expander (pure lexical) at the Defense and Iron tiers. Disabling the AI module does not affect the correctness of the system; it only reduces synonym recall in the query.
User query │ ▼ [ Term Expander ─ LLM (General) │ Local dict (Standard) │ Noop (Iron / Defense) ] │ ▼ [ Postgres FTS tsquery ] │ ▼ [ Retrieval engine → result + Merkle proof ]
Query strings — not document bodies — are the only payload that ever leaves the trust boundary, and only when the LLM expander is enabled. Document content remains within the sealed perimeter at every tier.
08 · Architecture (Optional)
Dual-index pattern — for organizations with existing RAG investment
New deployments typically consolidate on Axowl as the single retrieval layer. The dual-index pattern is optional and reserved for environments where paraphrase recall is required alongside the deterministic baseline.
Data │ ┌──────────┴──────────┐ ▼ ▼ Primary chain Semantic index Merkle · chunked Embedding · vectors Axowl default RAG niche only │ │ └──────────┬──────────┘ │ Retrieval surface ( query routed by intent )
The primary chain is the authoritative record. Chunk boundaries are deterministic; the Merkle root seals the chunk; verification is constant-time. The primary chain is never rewritten.
The semantic index, where deployed, is built from the same data but optimized for paraphrase recall and meaning-based queries on the niche subset of queries that requires it (§09). Boundaries are method-selected (Adaptive Chunking or any compatible method); the engine is a vector store; results are tagged with a back-reference to the primary chain, so the canonical bit-identical content is one lookup away.
The routing decision — which index to consult for a given query — can be automatic (intent classification), explicit (the user picks a tab), or policy-driven (regulated queries always go to the primary chain). For most enterprise deployments, the routing rule is trivial: everything goes to the primary chain; the semantic index is omitted entirely.
09 · Choosing
When to keep RAG, and when to consolidate on Axowl
The selection criterion is the value function of the query. The left column names the small set of query patterns where RAG is the appropriate primary tool. Everything else — and it is most enterprise data — is handled by Axowl as the default.
RAG · Narrow niche
Cross-document summarization where paraphrase recall is the primary metric
Concept discovery — retrieving items conceptually related to a query without lexical overlap
External general-knowledge Q&A (e.g. "what are the trends in this field?") is the domain of LLMs themselves, not of retrieval — and is outside this comparison.
Axowl · Enterprise default
The majority of enterprise retrieval workloads — datasets with stable terminology, regulatory exposure, reproducibility requirements, or integrity constraints
Knowledge bases, runbooks, internal documentation, and code-base navigation
Versioned document archives where bit-identity matters — policy, contracts, technical specifications, internal IP
Append-only event streams of any kind — telemetry, ledgers, configuration history, access logs
Retrieval that needs to be defensible — to a regulator, an auditor, opposing counsel, or a future version of yourself
Long-horizon archives where embedding-model churn would otherwise change the answer over time
10 · Further Reading
Citations
RAG Lewis, P., Perez, E., Piktus, A., et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. Advances in Neural Information Processing Systems 33 (NeurIPS 2020).
Adaptive Chunking Adaptive Chunking for Document-Level Retrieval. LREC 2026 (Language Resources and Evaluation Conference).
Merkle Tree Merkle, R. C. (1987). A Digital Signature Based on a Conventional Encryption Function. Advances in Cryptology — CRYPTO '87.
Axowl Axowl Technical Whitepaper — available on request to architecture and data platform teams.
When to keep RAG. When to consolidate on Axowl.
Our architecture team reviews the query mix, terminology stability, and reproducibility profile of each deployment to identify the RAG niche (if any) and the Axowl default. Whitepaper and reference architectures available on request.
Talk to architecture team Request reference architectures