The Same Control Problem, Twice

Most AI safety in education is retrofitted. A general-purpose model is selected for its fluency, a product is built around it, and then, late in the process and usually under procurement pressure, a layer of filtering and disclaimer is applied to the output. This is why such systems fail in the places nobody anticipated: the safety layer was designed against an imagined set of failures rather than against the architecture that actually produces them.

LearnerFlow, an AI tutoring platform for Grade 4 to Grade 12 learners built by HBS Software Solutions, offers a different arrangement, and it is the arrangement rather than the product that deserves scrutiny.

The claim is this. The framework used to govern how the platform was built is the same framework that governs what the platform does to learners, because these are the same control problem observed at two timescales. The auditability a school would demand of an automated marker is not a feature added to LearnerFlow at the end. It is a byproduct of the discipline under which the code was written.

That is a structural claim, and unlike an assurance of good intent it can be examined.

Brandon Dickens, founder of HBS Software Solutions and of LearnerFlow, brings more than three decades of technology experience, spanning education, software architecture and senior technology leadership. He built the platform using the Zanetti AI Framework™ as part of the development process.

The risk he describes in development is familiar to anyone who has run a long AI-assisted build: drift away from the original architecture, decisions made early and silently contradicted later, context lost between sessions, and work that becomes progressively harder to audit as it grows.

Now state the risk a school takes on when it deploys an AI tutor: a system that wanders off-curriculum, forgets what it established with a learner last session, and produces marking that nobody can explain to a parent.

These are the same four failures. Drift, lost decisions, broken context, unauditable output. The only difference is the timescale over which they accumulate and who is harmed when they do.

Simone Zanetti, founder of the Zanetti AI Institute, frames the framework's purpose in terms that apply to both readings at once.

The Zanetti AI Framework™ gives serious builders a control system for working with AI. In a long development process, the risk is drift, lost decisions, broken context and work that becomes hard to audit. LearnerFlow shows what changes when control is designed into the AI workflow from the start.

- Simone Zanetti, founder, Zanetti AI Institute

Zanetti also identifies why the case is worth documenting: “Brandon is not new to software. That is exactly why this project matters.” The framework was not compensating for inexperience. It was imposing discipline on someone who already knew what discipline looked like and wanted it enforced structurally rather than by memory.

Dickens states the requirement from the product side.

LearnerFlow needed more than fast code generation. It needed a controlled AI layer, clear curriculum boundaries and a development process I could trust over time. The Zanetti AI Framework™ helped structure that process so the AI remained useful without taking over the judgement required to build the product properly.

- Brandon Dickens, founder, HBS Software Solutions

The framework organises around three pillars, capability, context and control. For HBS Software Solutions the most important was control. In a field where the dominant conversation is a capability conversation, that ordering is the finding.

HBS's methodology documentation maps named methodologies to specific mechanisms in the platform across four layers. Set out individually, the mapping shows what “applying a framework” concretely meant. The correspondence noted above, between build-time and run-time discipline, is visible in almost every entry.

AgentNitro™ - the tutor as a governed agent. Rather than a prompt calling a model, the tutor is constructed as a governed agent composed of system instructions, playbooks and reference packs. The agent's behaviour is defined in reviewable documents that exist independently of any single session, which is precisely what makes it possible to change tutor behaviour deliberately rather than by prompt-tinkering.

PrimeFusion™ - curriculum boundaries as structure. Structured system prompts combined with CAPS scope validation keep tutor reasoning on-curriculum. This is the mechanism that distinguishes a curriculum-locked tutor from a general model that happens to have been asked about Grade 9 mathematics. The boundary is enforced, not requested.

MemLock™ - durable decisions. Reviewed answer keys are locked into a structured tree and reused across sessions rather than regenerated on demand. The build-time analogue is the preservation of key architectural decisions across long AI-assisted coding sessions. In both cases the principle is identical: something that has been reviewed by a human should not be silently regenerated by a model.

MissionChain™ - staged interaction. The tutoring interaction runs as a staged chain, diagnostic through teaching, practice and quiz, rather than as open-ended conversation. Multi-pass extraction and merge operate on the same principle. A learner is not left to negotiate the shape of their own lesson with a chatbot.

FloLock™ - determinism where determinism belongs. Ingestion and marking run as deterministic pipelines with a rule-based fallback. This is a significant design decision: the parts of the system that touch a learner's marks are the parts least willing to rely on generative behaviour.

ComplianceGate™ - the human gate. Per-call token logging, tolerant parsing against database constraints, and human review before Activate. Nothing generated by a model becomes an active artefact that other learners encounter until a person has approved it.

IrisGate™ - structured source material. Memorandum PDFs are parsed into a structured answer-key schema capturing topic, marks, method and accuracy. Official memoranda enter the system as data with defined fields, not as text a model is asked to interpret afresh each time.

OrionCompass™ - analytics as direction. Topic-mastery and method-mark analytics drive next-step guidance, turning marking output into a decision about what the learner should do next.

DeepFlo™ - presentation for recall. Results are turned into next-step direction and presented in a form intended to support retention rather than merely to report a score.

Running vertically through all four layers in the HBS documentation is a human layer. It is drawn as a spine rather than as a footnote, and given the above, that is not decoration.

Beneath the named methodologies sits a three-stage assurance system that reads equally as an engineering practice and as a product guarantee.

Observability asks what happened, implemented as per-call token logging on every AI-marked step. Validation asks whether it was right, implemented as tolerant parsing and normalisation against database constraints. Audit asks whether it can be proven, implemented as human review before activation with step-level marking rationale retained.

A school evaluating an automated marker is entitled to ask exactly these three questions. So is a developer reviewing six weeks of AI-assisted work. The documentation does not distinguish between the two readings, and that is the point of this article.

One feature exercises the whole framework end to end, and it is also the platform's clearest pedagogical position.

Learners answer past-paper questions and receive feedback against the official memorandum, including marks for correct working even when the final answer is wrong. The flow runs through six governed stages: memorandum text extraction into a canonical answer-key dataset (IrisGate™), locked multi-pass ingestion and marking (FloLock™ with MissionChain™), schema-constrained reasoning for marking (PrimeFusion™), validation followed by a human review gate before activation (ComplianceGate™), storage of the activated key as a durable reusable artefact (MemLock™), and conversion of results into next-step direction (OrionCompass™ with DeepFlo™).

The pedagogical argument for method-aware marking stands on its own. A binary correct-or-incorrect response to a multi-step question discards most of the diagnostic information available. A learner who sets up the correct equation and then makes an arithmetic slip has a fundamentally different problem from one who selected the wrong method, and telling both “incorrect” helps neither. Method-aware feedback helps learners see where marks were earned, where they were lost, and how to improve their reasoning before the next assessment.

What the framework adds is that this marking is defensible. Every step is logged, structurally validated, and human-approved before it reaches a learner.

LearnerFlow addresses a specific South African condition. Many learners need more individual support than schools can realistically provide, while private tutoring remains unaffordable for many families. The platform gives learners a way to revise, practise and ask questions in their own time, aligned to the CAPS and IEB syllabuses.

It is built on .NET 8, React/TypeScript and PostgreSQL, with AI tutoring and marking supported by Anthropic Claude and voice support delivered through Azure neural text-to-speech. The platform is hosted in South Africa and designed with POPIA-conscious data handling.

The argument above concerns architecture. It is worth stating plainly what it does not reach.

It does not establish efficacy. A governance framework demonstrates that a system is controllable, inspectable and answerable. It says nothing about whether learners using it perform better than learners who do not. That question requires controlled study across at least a full academic cycle and across schools with differing resource profiles, and no claim in this article should be read as anticipating its result. The trustworthiness of the architecture must not be allowed to do the work of an efficacy finding.

Nor does it settle the teacher relationship. LearnerFlow is positioned as a supplement to classroom teaching rather than a substitute for it, and the human layer running through the architecture is consistent with that positioning. Whether the positioning survives deployment pressure, particularly in under-resourced settings where a tutoring system is most tempting to treat as a stopgap, is a question for implementation research rather than for developers.

What the case does establish is narrower and still unusual. It is possible to build an AI education product under an explicit governance discipline; doing so is compatible with shipping; the resulting auditability is structural rather than retrofitted; and an experienced developer, given the choice, ranked control above capability.

For a sector that has been asked to adopt AI largely on faith, a builder who can show the control system is a more useful precedent than one who can show the output.

Methodology names referenced in this article are the work of Simone Zanetti and the Zanetti AI Institute. Suggested citation for the methodology: Zanetti, S. (2026). Zanetti AI AgentNitro™ Builder - Claude Edition. Zanetti AI Institute.