Why explore PageIndex?

Most traditional RAG systems ask a narrow question: Which chunks are closest to the query?

PageIndex asks a different question: Where would a knowledgeable reader look inside this document?

That difference matters.

A vector retriever may find passages that sound similar to the query, but similar does not always mean useful. PageIndex’s own technical blog calls out this problem directly: vector-based RAG assumes that the most semantically similar text is also the most relevant text, but that assumption can fail when the user’s query expresses intent rather than exact content.

For example, a user might ask: What was the total deferred asset value?

A traditional retriever may look for chunks containing “deferred,” “asset,” and “value.” But the actual answer might live in a table, appendix, or referenced section that does not closely match the wording of the query. A human would not search only by phrase similarity. A human would scan the table of contents, inspect likely sections, follow references, and check whether the evidence is sufficient.
PageIndex tries to make retrieval behave more like that.

What makes this promising?

1. It preserves document structure

Many documents are not just text. They are organised knowledge objects.
A financial report has statements, notes, tables, appendices, and page references. A legal contract has clauses, schedules, definitions, and exceptions. A technical manual has chapters, diagrams, warnings, and troubleshooting sections.
Chunk-based RAG can flatten that structure. PageIndex keeps the hierarchy visible.
That is promising because users often do not only need an answer. They need to know where the answer came from.

2. It may reduce the “similar but wrong” retrieval problem

One of the biggest practical issues in RAG is retrieving content that appears related but does not actually answer the question.
PageIndex’s blog argues that semantic similarity is not the same as true relevance, especially in domain-specific documents where many passages may sound similar but differ in meaning or importance.
That framing is useful. It suggests that better retrieval may require more than better embeddings. It may require a retrieval strategy that understands the shape of the document.

3. It can follow references more naturally

​Long documents often say things like:

Traditional vector retrieval may miss the referenced section if the referenced content does not share the same wording as the original query. PageIndex’s blog highlights this as a weakness of conventional vector RAG and argues that a ToC-based or hierarchical retrieval system can follow those references more like a human reader.
This is one of the strongest reasons to explore PageIndex for document-heavy workflows.

4. It makes retrieval more explainable
A vector result can be hard to explain. The system says, in effect: This chunk was mathematically close to the query.
A PageIndex-style system can say: I inspected the financial statements section, then followed a reference to Appendix G, then retrieved the relevant table.​
That retrieval path is easier to audit.
The PageIndex GitHub page specifically lists better explainability and traceability as core features, including page and section references.

What we are learning?

Learning 1: PageIndex is less about replacing vectors & more about the retrieval question

The easy headline is “vectorless RAG.” But the more useful insight is that PageIndex reframes retrieval.
Traditional RAG asks: What text is similar?
PageIndex asks: Where should we look?
That distinction is subtle but important. It moves retrieval closer to reasoning, planning, and evidence gathering.

Learning 2: Structure matters more than we often admit

A lot of RAG work focuses on embeddings, chunk size, reranking, and prompt design. Those are important. But PageIndex reminds us that document structure itself is a powerful signal.
For structured documents, the table of contents, section hierarchy, appendix layout, page numbers, table captions, and references are not metadata decorations. They are part of the meaning.
Ignoring that structure can make retrieval weaker than it needs to be.

Learning 3: Chunking is not neutral

Chunking sounds like a preprocessing detail, but it can change what the model is able to understand.
PageIndex’s blog criticises hard chunking because fixed-size chunks can split sentences, paragraphs, sections, or logical units of meaning. 
That is an important learning: chunking is not just a technical step. It is an information design choice.
When chunks break the natural structure of a document, retrieval can become noisy, incomplete, or misleading.

Learning 4: Reasoning-based retrieval has trade-offs

PageIndex is promising, but it is not magic.
The PageIndex documentation notes that LLM-based tree search can be slower because it requires LLM reasoning. It also notes that selecting nodes based only on summaries can lose details from the original content.
That means PageIndex-style retrieval may be strongest when accuracy, traceability, and structured navigation matter more than raw speed.
For low-latency FAQ search, traditional vector RAG may still be simpler and cheaper. For complex document analysis, reasoning-based retrieval may be worth the extra cost.

Learning 5: Hybrid retrieval may be the practical middle ground

The PageIndex docs describe both LLM Tree Search and Hybrid Tree Search. Hybrid Tree Search combines LLM reasoning with vector database techniques. 
This feels like an important practical direction.
Rather than framing the decision as: vectors vs. no vectors
A better framing may be: when should vectors help, and when should reasoning take over?

A strong production architecture might use vector or keyword search to identify candidate documents quickly, then use PageIndex-style reasoning to navigate within the most relevant documents.

Where PageIndex seems especially useful

PageIndex looks most interesting for documents where:
​
- answers are buried inside long reports
- page-level citations matter
- tables and appendices are important
- internal references need to be followed
- users ask multi-step questions
- the document has a strong section hierarchy

Examples include:
- financial filings
- legal contracts
- policy documents
- insurance documents
- academic papers
- technical manuals
- compliance reports

In these cases, retrieval is not just about finding text. It is about finding evidence.

Open questions we would want to test

Because this is exploratory, the right next step is not to declare PageIndex “better.” The right next step is to test it against specific retrieval problems.
​
The questions worth testing are:

1. Does PageIndex retrieve the correct evidence more often than vector RAG?
2. Does it improve citation accuracy?
3. How much latency does tree search add?
4. How much does the quality of the document tree affect results?
5. Does it work equally well on messy PDFs, scanned PDFs, and poorly structured documents?
6. When does hybrid retrieval outperform pure tree search?
7. How does it perform on multi-document questions?

​These are the questions that would determine whether PageIndex is a better fit for a specific RAG system.

Final reflection

PageIndex is interesting because it challenges one of the default assumptions in RAG: that better retrieval mainly means better similarity search.
It suggests a different path.
For long, structured documents, retrieval may need to become more like reading. The system should understand the document map, inspect likely sections, follow references, and verify whether the evidence is enough.

That is the real learning from exploring PageIndex:
​
The future of RAG may not be only about retrieving the closest text. It may be about teaching systems where to look, why to look there, and how to know when they have found enough evidence.

PageIndex is one approach pointing in that direction. Whether it becomes the right choice for a given system depends on the documents, the latency budget, the need for citations, and the complexity of the questions. But as an idea, it is worth exploring because it moves RAG from passive similarity matching toward active document reasoning.

By Nkosinathi Sangweni

The real value of AI is not replacing engineers. It is multiplying the effectiveness of engineers who already understand what good engineering looks like.
​
That’s the important distinction.

1. AI accelerates the known
f you already understand the architecture, constraints, and trade-offs, AI removes a huge amount of mechanical work:

• boilerplate,
• scaffolding,
• repetitive transformations,
• syntax lookup,
• test generation,
• documentation drafts.

The thinking still comes from the engineer. The implementation loop just becomes dramatically faster.

2. AI expands what individual engineers can do
One of the biggest practical changes is that experienced engineers can now move across domains faster than before.
A backend engineer can prototype frontend flows. A systems engineer can draft data pipelines in unfamiliar tooling. An infrastructure engineer can move faster in application code.
AI lowers the friction of crossing technical boundaries.
That’s incredibly valuable because many senior engineers already know what they want to build — they just may not have deep fluency in every framework or language.

3. AI improves exploration
AI is also useful as a thinking companion.
Not because it “knows better,” but because it helps accelerate exploration.
Questions like:

• “What failure modes am I missing?”
• “What are the trade-offs here?”
• “How else could this architecture evolve?”
• “What operational concerns should exist?”

- can surface useful angles much faster than thinking alone. It’s basically high-speed rubber ducking with broad context.

4. AI shrinks feedback loops
Fast generation means fast validation.
You can prototype an idea in minutes instead of hours. That changes how engineers experiment.
Good engineers benefit enormously from tighter feedback loops because they can quickly evaluate:

• whether something is maintainable,
• whether it scales,
• whether it introduces risk,
• and whether the approach is fundamentally sound.

The key skill is still judgment. Not generation.
​
AI is certainly a powerful force multiplier. But only in the hands of someone who already knows what good looks like.

By Nkosinathi Sangweni.

At Kaleidocode, we spend a lot of our time in real delivery environments.

That means real deadlines, real distributed systems, and real production failures. Not the clean kind that sit nicely in one service with one owner, but the messy kind: the same class of failure surfacing across subsystems, half-useful traces, repeated edge cases, and engineers burning hours to confirm what the logs already suggested.
​
That was the pattern we wanted to break.

As a consultancy, our value is not in having senior engineers repeatedly perform the first 80% of incident work by hand. Our value is in solving the harder problems: the failures that are genuinely new, the architecture decisions that need judgment, and the product work clients are actually paying us to move forward. Kaleidocode already operates as a full-service software consultancy across software delivery, testing, DevOps and AI systems, so the gap was obvious to us: too much high-value engineering time was being spent on repeatable production triage.

So we built a workflow that starts where the pain starts: in the logs.

We connected our logging and operational tooling into an agentic flow built around specialized subagents. One agent reads recent production failures and groups them into meaningful error clusters. Another ranks them by frequency, subsystem and urgency. Another investigates the likely cause by pulling in the surrounding code path, recent changes and known failure patterns. When the issue is narrow enough and the fix is bounded, a resolution agent generates a patch. A validation step checks the change. Then the workflow opens a pull request and produces a triage report that shows what was fixed, what is pending, and what still needs human eyes.

The important part is that this is not one giant prompt pretending to be a platform.
It is a sequence of narrow responsibilities. Triage is not investigation. Investigation is not resolution. Resolution is not validation. We found that once each step had a defined role, the system stopped behaving like a clever demo and started behaving like an engineering workflow.

One report made the value obvious. In a single 24-hour window, the workflow processed 173 production errors across six subsystems. One issue alone accounted for 63% of the total. The system identified it, classified it, generated the relevant fix path, and surfaced the exact items that still needed human handling. Instead of asking an engineer to spend the morning reading through repeated failures, the workflow reduced the problem to a reviewable set of actions.

That changed the conversation inside the team.
We were no longer asking, “Who is free to go through these logs?”
We were asking, “Which of these items actually deserves an engineer?”

That distinction matters in consulting.

Clients do not benefit when strong developers spend large parts of the week rewriting the same defensive fixes or producing the same summary by hand from production noise. They benefit when those developers are available for the work that requires judgment: reshaping an unreliable flow, solving a client-specific integration problem, challenging assumptions in the design, or delivering the next piece of roadmap value.

The agentic workflow gave us a way to protect that time without pretending every production issue can be automated.

Some errors still need people. Missing tracebacks, unclear ownership, infrastructure-level failures, or anything with broader architectural impact still gets escalated. 

The workflow does not try to be brave where it should be cautious. It takes away the repetitive operational drag, and lets us get on with the real engineering work. 

Fraxses is powering data-driven audit transformation at a state owned utility.

For more then 10 years Fraxses has proved its versatility across industries, solving data challenges regardless of scale, complexity or how messy and scattered the underlying information may be. The platform has been tested across a wide range of use cases and has consistently delivered the solutions customers need.

Alongside its versatility, Fraxses has shown the potential to transform specific domains, one of the most promising of these being the world of audit. Since 2022 we argued Fraxses could be a game-changer for the audit profession, publishing a white paper The Transformation of Internal Audit and an accompanying article to outline that vision.

In the intervening three years, the Fraxses platform has advanced considerably. The recent addition of the Data Intelligence module, with its ontology-driven common data models and embedded rules, has made Fraxses an even more powerful audit tool. And importantly, we have a series of compelling real-world use cases that demonstrate our long-held contention that Fraxses presents the audit profession with a solution like no other.

Fraxses is being used to great effect in several major engagements across the world, including key public sector audits. In this articel, the first in a two-part series, we turn the spotlight on one of the most significant of these engagements, now in its fourth year: the audit of a national utility.

Partnering for a New Approach

In 2022, a global professional services firm, having recognised the platform’s potential in the audit space, partnered with Intenda to integrate Fraxses into its audit strategy for the utility. The project centres on recalculating usage charges and addresses the long-standing challenge of validating billing accuracy by reconciling financial data from SAP with readings from multiple operational systems.

The scale of this audit is extraordinary: more than eight billion records ingested, recalculated and validated by a core team of just three people. Traditional methods could not handle this volume of data, nor could they provide the confidence or meet the required timeframes for such a critical audit. With the implementation of Fraxses, a data challenge that previously seemed insurmountable was swiftly overcome.

By virtualising access to the utility’s financial and operational datasets, Fraxses enabled Audit teams to run full-population recalculations in place without copying or moving data. Automated substantive tests and reusable control frameworks reduced duplicated effort, while cross-functional access ensured that audit requirements were met from a single source of truth.

Efficiency, Cost and Scale

In year one the recalculation ran 40% over schedule due to sheer data complexity, however, after the first year of the audit Fraxses quickly began to deliver compounding benefits. In the second year the full audit was completed 15-20% ahead of projections, and in year three quarterly runs were completed in just two to four weeks.

These improvements translated into full-population coverage that gave auditors and stakeholders high levels of assurance, along with significant cost savings through reuse of prior-year work and faster onboarding for new team members and clients. Cross-source reconciliation delivered consistent, reliable results, while the professional services firm’s Audit team gained quicker access to the data than through the utility itself.

As demonstrated by these remarkable gains, Fraxses delivers improved efficiency and raises the bar for audit, enabling large-scale, data-driven engagements that combine speed, assurance and accountability with reduced cost and effort.

Laying the Foundation for the Future

With this engagement now in its fourth cycle, Fraxses has demonstrated its capacity to transform not only public sector audits but the audit profession at large. Planned next steps include expanding the use of Fraxses within the professional services firm, standardising it as the preferred platform for complex large-enterprise audits, building AI models on top of the Data Intelligence module to automate compliance and regulatory reporting, and developing audit solution templates with reusable control libraries and automation workflows.

Together, these advances highlight how Fraxses equips the audit profession with the technology and tools to move beyond sampling and manual reconciliation, towards a digital future where accuracy, assurance and scale come as standard. 

Kaleidocode's CEO, Rory Clarke, will be joining a panel discussion at Emeris’ (Varsity College) 2025 Client Connect November event titled “Supporting Students and Graduates in the AI Era: Staying Relevant in a Rapidly Evolving Workplace” — exploring how education, industry, and employers can better prepare young professionals for a world being reshaped by AI.

At Kaleidocode, we see firsthand how practical, experience-based learning helps bridge the gap between academic study and the demands of modern software development. Looking forward to sharing insights and learning from others doing incredible work in this space.

📅 November 2025

#AI #FutureOfWork #SkillsDevelopment #Apprenticeships #DigitalTransformation

Artificial Intelligence (AI) is no longer a fringe technology, it’s quickly moving into the heart of enterprise systems. But for many corporate leaders, the question isn’t simply “Should we adopt AI?” but rather “How can we adopt AI in a way that delivers real value?”

A recent MIT-led study of enterprise generative-AI pilots reported that only approximately 5% of initiatives delivered measurable business or profit-and-loss impact. In other words: roughly 95% of pilots failed to move beyond experimentation into genuine business benefit. 

This stark finding underscores that AI isn’t a plug-and-play silver bullet. It demands discipline, effective integration, clear focus and business alignment. The good news is that those companies that treat AI as a systems integration and change-management exercise rather than simply a model build project can see meaningful outcomes.

Lets explore some realistic strategic benefits of corporate AI systems and then set out five critical keys for leaders to keep in mind when evaluating AI implementation projects.

The Strategic Value of Intelligent Systems

Despite the cautionary findings, AI and intelligent systems still hold significant strategic potential when approached correctly.

Enhanced Decision-Making. AI systems now analyse large, diverse data sets and surface actionable insight faster than conventional BI tools. Whether forecasting demand, identifying customer churn or optimising resource allocation, the advantage lies in accelerating decision-making and not just automating it.

Intelligent Automation. Beyond rule-based automation, AI enables workflows that adapt, learn and respond intelligently, e.g. natural language processing, document understanding, image recognition and human-in-the-loop decision support. This enables operational scale-up without proportionate cost increases.

Predictive & Analytical Systems. Predictive models shift the enterprise from reactive to proactive: anticipating anomalies, optimising supply-chains, identifying risks before they materialise. In industries such as finance, logistics and manufacturing, this repositions systems from “data record repositories” to “insight engines”.

Scalable, Learn-able Architecture. The most compelling intelligent systems do more than “run once” repeatedly, rather they evolve. Incorporating feedback loops, continuously refined models and architecture, a business can embed intelligence as part of the business. This is where many AI pilots fall short (as the MIT study shows), systems stall when they fail to adapt or embed iteratively into business workflows.  

Five Critical Considerations for Corporate IT Executives

So, if there is so much value on offer, what should leaders be aware of when evaluating AI-enabled systems. As a primer, here are five considerations to guide strategy and decision-making.

1. Integration with Existing Systems
One of the major lessons from the MIT research is that failure is rarely due to the AI model itself, more often it’s due to poor integration into enterprise workflows and legacy systems. 
What should I be considering:

• Conduct an architectural assessment to understand how new AI components will interact with existing ERP, CRM or data-warehouse systems.
• Define clear APIs, data pipelines and interfaces to these systems rather than creating standalone bolt-on pilots disconnected from core systems.
• Treat AI as an extension of your current platform, not a separate experiment, service or dataset entirely.

​
2. Data Readiness and Governance
AI’s value is only as strong as the data it learns from. Many companies underestimate the work required to bring structured, clean, contextualised data into play.
What should I be considering:

• Build data-governance frameworks (data lineage, quality, anonymisation, consent) early.
• Catalogue and inventory data sources, identify siloes, establish integration points.
• Recognise that data preparation often takes longer and costs more than the model build itself.

3. Security, Compliance and Ethical Use
As pilots move into production new risks emerge, e.g. model bias, “black box” decision making, regulatory non-compliance, sensitive data leakage. The MIT study found that many generative-AI efforts can stumble on governance rather than technology. 
What should I be considering:

• Make sure your AI systems can explain how they make decisions, keep clear records of what they do, and include people in the process to review or approve important outcomes.
• Align data and AI use with privacy laws and sector regulation (POPIA, GDPR, etc.).
• Involve risk, legal and compliance teams from the start.

4. Skills, Change Management and Organisational Culture
AI initiatives fail or under achieve not because of technology alone but because organisations aren’t ready for the shift. The MIT research calls out a “learning gap” where the enterprise struggles to adapt existing tools and workflows to AI-driven ways of working. 
What should I be considering:

• Create cross-functional teams combining business domain experts, data scientists, engineers and business owners.
• Invest in internal literacy, invest in educating business users on AI capabilities and limitations.
• Define roles and governance that embeds AI into business processes, and not silo it in a lab or POC process.

5. Measuring Business Value and Defining Success
Too many AI pilots never translate into measurable commercial impact. The reportedly high failure rate is in large part due to inadequate measurement frameworks or unclear business objectives. 
What should I be considering:

• Define KPIs or goals aligned with measurable business outcomes e.g. cost reduction, time-to-decision, error rate, revenue uplift.
• Set realistic timelines and scope: many successful AI programmes focus on one specific use-case, execute well and then scale gradually. 
• Use pilot results to decide whether to scale, pivot or stop. Don’t into the “pilot-forever” trap that dies off slowly.

Balancing Innovation with Governance
The MIT study serves as useful balance in the current environment; AI enthusiasm alone does not guarantee results. Leaders who treat AI as a strategic system change rather than a one-off project are far more likely to see sustained value. Successful approaches embed AI, data, people and processes in an integrated way, aligning with business goals, measuring outcomes, and evolving governance.

Choosing the right use-case/s connected to real commercial value and building organisation readiness are what distinguish the AI initiatives that succeed from the remainder.

The next phase of intelligent systems will be defined by those companies that see AI not as a novelty, but as a core part of their digital fabric. That’s where the real value lies.