Niche Clever Interactive: rebuilding a WordPress knowledge interface

A question interface built for one professional portfolio became a reusable WordPress product, then was rebuilt around a complete free Core and a separate Premium companion.

Niche Clever Interactive did not begin as an attempt to make a generic AI plugin.

The starting problem was more particular. The Interactive Professional Portfolio had accumulated a substantial body of professional evidence, chronology and project material. A conventional website could only anticipate a limited set of questions about it. The question interface offered another route: a visitor could ask something in ordinary language and receive an answer grounded in material that had been prepared and governed elsewhere.

That distinction has held through three versions of the work. The interface can make a knowledge base easier to explore, but it does not make the underlying material trustworthy. Source selection, authority, privacy and publication remain separate responsibilities.

The product story is therefore partly about software and partly about learning where software should stop.

Current position

The story is easiest to follow as three versions of Niche Clever Interactive: Version 1, Version 2 and Version 3. They are reader-facing generations of one continuing product problem. They are not version numbers in the software sense, and they do not describe one codebase carried forward. Version 3, the current product, was built as an independent rebuild; it is not Version 2 under a new name.

Versions 1 and 2 are earlier generations. Version 3, made up of a free Core and a separate Premium companion, is the current product direction and is built and tested locally. No WordPress.org approval, directory listing or public download for Core has been recorded, and Premium is not publicly available.

01 / Version 1: the interface emerges inside the portfolio

The first version was inseparable from the problem the Interactive Professional Portfolio was trying to solve.

The portfolio was becoming less like a conventional CV and more like a structured professional archive. It held projects, chronology, source evidence and later interpretation, with explicit concern for provenance and for the difference between what could be established and what was only inferred. Once that material existed, a new question followed: could a visitor explore it by asking questions, rather than navigating only through pages written in advance?

Version 1 became the practical WordPress layer for that experiment. The useful step was not that a model could produce an answer. It was that the site could connect an ordinary visitor question to a prepared body of material, while editorial responsibility for the corpus stayed separate.

The interface then had to become a real product surface. Public question panels, administrator controls, profile behaviour, response presentation, access decisions and local validation all grew up around what had started as one feature of a wider portfolio system.

This first version established the central idea: conversation can be a way of moving through knowledge, but it should not become the authority for that knowledge.

02 / Version 2: a reusable product

Version 2 made the interaction layer legible as a product in its own right.

The record shows a good deal of work that is easy to miss when the product is described only as a chatbot. The visitor panel was refined. Administrator conversations and settings were separated from the public experience. Packaging, PHP and JavaScript checks, PHPUnit tests, local installation, rollback precautions and release validation became part of the routine. Help material, support language, directory assets and licensing documentation were prepared as the project moved toward a distributable WordPress plugin.

Version 2 was also used in real Niche Clever work: configured around the professional portfolio, connected to local project surfaces and carried through Free and Premium candidates. Premium work added authored questions, collections and profile-oriented administration, which made the product less dependent on one open-ended text box and more useful as a publishing interface.

That experience clarified what was reusable and what was still too tightly coupled.

It also taught a more prosaic lesson, that names, packaging and distribution constraints matter. A naming problem raised during WordPress.org review became the immediate reason to reconsider the product identity. The work that followed did more than change a label; it opened the way to reconsidering the architecture that had grown around the first product line.

03 / Version 3: an independent rebuild around a complete Core

Version 3 begins with a stronger architectural boundary.

Core is meant to be useful on its own. It owns the public request path, provider transport, secret handling, connection testing, limits and the basic question-and-answer experience. It is not a deliberately incomplete edition waiting to be unlocked by another plugin.

The foundation work from 12 October established the new repository and its control documents, then built the security and runtime foundations, the administrator workspace and the public panel. Retrieval was introduced behind a bounded interface, first in mock form and then through a local live File Search canary. Budget, privacy and abuse controls were treated as implementation concerns, not documentation alone.

One decision is revealing. An approved-evidence mapping and public citation feature had appeared in the Core candidate, and it was deliberately removed. Evidence links belonged in the separately governed companion rather than being left half-owned by the free plugin.

That is a small example of the larger rebuild. Capability was not kept merely because it had once existed. The question became which component should be responsible for it, and what could leave Core without making Core incomplete.

Core went on to add response guidance, model and resource controls, optional conversation history, retention and cleanup behaviour, diagnostics, revised administrator assets and the extension seams a separate companion would need.

The record also contains corrections rather than a smooth progression. While work on public request limits was under way, testing found that the intended budget gate had been supplied at the wrong boundary and was not being enforced by the earlier candidates. The wiring was corrected and a regression test added. A safeguard does not become real because the documentation says it exists.

04 / Core and Premium: separate ownership, one coherent experience

Separating Premium in code created a design problem of its own: how to avoid making the administrator feel that two unrelated products had been bolted together.

The answer was not to collapse the repositories again. Core instead acquired bounded hosting and compatibility seams through which the companion could add capabilities, while Core stayed responsible for the public route, secrets and transport.

Premium was then developed against those seams. The record covers multiple knowledge profiles, per-profile access rules, additional placements, approved evidence links, verified chronology, earlier-turn context, cached answers, authored questions and collections, conversation export, retention and erasure controls, audit behaviour and finer panel appearance controls.

At the same time, the two codebases were brought back together at the level people actually see. Core-hosted administration gained shared profile and settings surfaces, Premium screens adopted the same visual language, and profile switching and site-level navigation were refined so that the component boundary stayed an engineering fact rather than an everyday usability burden.

This part of the story matters. Modularity is only worth having if it improves responsibility without passing needless complexity on to the person using the software.

05 / Testing the boundaries rather than merely describing them

A recurring theme across all three versions is that the interesting failures happen at boundaries.

Can an unknown profile silently fall back to another corpus? It must not. Can a restricted profile leak through a public route? It should fail closed. Can an old cached answer survive a material configuration change? Its identity rules have to make that invalidation explicit. Can a settings screen claim that a connection works without exercising the relevant path? The product needs an administrator-visible connection test.

The implementation record therefore holds more than feature additions. It holds package comparisons, source and runtime checks, WordPress test-site installations, PHP and JavaScript tests, local provider exercises, responsive corrections, nonce and permission repairs, and repeated work on failure behaviour.

The later Premium acceptance work exercised the companion’s capability areas in WordPress with a live OpenAI connection on 17 October. That supports a meaningful local software-acceptance claim. It is not a WordPress.org approval, a production deployment or a commercial release, and this case study keeps those states apart.

06 / Jacob’s role

Jacob’s role sits across product definition, information architecture, governance, testing and direction of the implementation.

He set out the original problem through the Interactive Professional Portfolio: how to make a substantial body of professional material open to questions without treating generated prose as a new source of truth. As the interface became reusable, he made the product decisions that separated corpus authority from question delivery, shaped the visitor and administrator experience, and decided which capabilities belonged in the free product and which needed a separately governed companion.

The later rebuild was heavily agent-assisted. Coding agents implemented substantial parts of the source, tests and technical documentation. Jacob’s part was to define the objective and its constraints, decide where each responsibility sat, review intermediate behaviour, challenge mismatches between documentation and runtime behaviour, direct corrections, and judge when a state was good enough to move to the next gate.

The repositories, progress records, test receipts and handoffs matter because they make that collaboration inspectable. They help separate a product decision from the code that carried it out, a locally verified behaviour from a release claim, and a later interpretation of the work from what was actually present at a given point.

07 / What the project demonstrates

Across the three versions the software becomes more capable. The more important development is that its responsibilities become clearer.

The project keeps several things apart:

• the knowledge base from the interface used to question it;
• evidence authority from generated answers;
• a complete free product from optional companion capabilities;
• code ownership from a coherent user experience;
• documentation of a safeguard from verification that the safeguard works;
• local acceptance from publication, deployment and commercial availability.

That makes Niche Clever Interactive a useful example of AI-assisted product development in which the hard part is not adding a model call. It is deciding what the model may see, what the software is responsible for, what stays a human editorial decision, and how those boundaries survive as the product changes.

The three versions also show why product history matters. Version 1 supplied the first working context. Version 2 tested what happened when the interface became a reusable product. Version 3 could then be rebuilt with a much clearer idea of which responsibilities needed to stay separate. The newer architecture carries that learning forward without pretending the history was one uninterrupted rewrite.

The Interactive Professional Portfolio is the governed professional record from which the original question interface emerged. Niche Clever Interactive is a different system: reusable WordPress software for asking questions of a knowledge base that its owner has prepared separately. The Core product page describes what the plugin does and does not do.