Prepared for academic collaborators
Artificial intelligence has made software tool-building faster. Speed alone does not make a tool useful in practice. A tool should reduce friction in human work, improve the quality of the task, and leave the user more capable than before.
Artificial intelligence has changed the cost, speed, and practical reach of software development. A single builder can now move from an observed problem to a working prototype in a fraction of the time previously required. Faster building creates opportunity, but speed alone does not make a useful tool.
AI-assisted tool development should begin with the human problem rather than the technical possibility. A tool built with AI should support the user, not replace the user. Human-centred support means reducing avoidable work, improving the quality or reliability of an output, saving time, reducing frustration, and helping the user complete the task with greater confidence.
The Five E Framework is Dr Dangor's developing framework for building such tools. The framework brings five elements together: Ethics, Economics, Engineering, Education, and Entrepreneurship. The route begins with a problem worth solving, moves through AI-assisted building and user education, and remains governed by ethical judgement.
The conceptual working paper will evolve as the framework is tested, criticised, and refined. Reader comments are welcome and may be sent directly to mohammed.dangor@wits.ac.za.
The paper first defines what counts as a tool, states the aim and scope, and then presents the Five E Framework. The later sections position the framework beside existing work, explain the platform operator model, and show how the framework applies to the first public examples.
A tool is a designed intervention for reducing friction in a process, improving the quality or reliability of the work output, and increasing the user's ability to complete a task with less avoidable frustration.
A prompt, chatbot response, generated interface, or software feature becomes useful only when the builder connects the output to a clearly defined problem and a real human workflow. The practical test is simple: the user should complete the task with less wasted effort and with a better result.
The definition limits the role of automation. Some tasks can be automated. Other tasks need explanation, judgement, supervision, communication, or learning. The framework treats AI as a way to build supportive tools for human activity and improve people's ability to act, understand, decide, practise, or manage their responsibilities.
The paper aims to introduce the Five E Framework for AI-assisted tool development and to describe the platform data access model as one operational implication of tools built under the framework.
The paper makes three limited contributions. The conceptual contribution is the definition of the Five E Framework. The practical contribution is a route from problem definition to AI-assisted development, user education, feedback, and support. The boundary-setting contribution is the distinction between tool operation, collaborator link-sharing, and later research use.
The paper does not validate the framework across fields, provide legal advice, replace research approval processes, or make ordinary public tool use equivalent to research participation. The limits keep the paper in the correct genre: a first conceptual account able to develop as further tools, user feedback, and academic outputs become available.
The Five E Framework has five elements: Ethics, Economics, Engineering, Education, and Entrepreneurship. Ethics guides the whole route. Economics defines the problem, Engineering builds the tool, Education teaches use and gathers feedback, and Entrepreneurship asks whether the tool can be supported over time.
Economics is used in the development-economics sense of understanding and measuring a problem before an intervention is built. Strong economics improves engineering because the builder works from an informed problem definition rather than a guess.
Engineering uses AI-assisted development for rapid prototyping and iteration. Generative AI can produce different outputs from similar prompts, and variation lets the builder explore alternatives quickly. Human judgement remains necessary because the builder must compare outputs, test behaviour, reject weak solutions, and refine the tool in response to the defined problem.
Education is communication and learning. Users need to understand what the tool does, why it matters, and how to use it correctly. Feedback matters because every stable system needs it. Real use shows where the problem was misunderstood, where engineering must change, or where the explanation failed.
Entrepreneurship asks whether users, institutions, or partners value the tool enough to support continued development. The question is one of support rather than sales. A tool needs a route to remain alive after the first build when the tool saves time, reduces frustration, improves quality, or creates useful records.
Figure 1 arranges the framework as a feedback system. Ethics governs the cycle. Feedback returns the work to Economics when the problem needs sharper definition and returns the work to Engineering when the tool needs a better build. Table 1 gives the working definition of each element.
Define and measure the problem before building.
Use AI-assisted development to build, test, and refine possible solutions.
Explain the tool to users and learn from how they use it.
Ask whether the tool is valued enough to support continued development.
Real use compares intended output with actual output. User feedback can return the work to problem definition, engineering, or communication before weak assumptions become permanent design choices.
Scroll sideways to view the full table on small screens.
| Element | Working definition | Question for the builder |
|---|---|---|
| Ethics | Ethics checks whether the tool supports human purpose, explains itself clearly, handles data responsibly, reduces harm, and improves human work. | Can the tool be explained, defended, and handled responsibly? |
| Economics | Economics defines and measures the problem before the tool is built. | Who experiences the problem, what friction exists, and what evidence would show improvement? |
| Engineering | Engineering uses AI-assisted development to build, test, compare, and refine possible solutions quickly. | Which solution can be built, tested, and improved because the problem is clear? |
| Education | Education explains the tool to users and turns user experience into feedback for future development. | Can a lay user understand the tool, its benefit, and the correct way to use it? |
| Entrepreneurship | Entrepreneurship asks whether users, institutions, or partners value the tool enough to support its continued development. | Does the tool matter enough for continued support? |
| Table note. The definitions above record the working version of the framework. | ||
The framework sits beside existing work in design thinking, lean startup methods, human-centred design, and AI ethics guidance. The framework gives the related concerns a specific route for AI-assisted tool development.
Brown's work on design thinking places value on understanding users and framing problems before solutions are built. Ries's lean startup method emphasises iteration, learning, and testing under uncertainty. ISO 9241-210 gives guidance for designing interactive systems around users, tasks, and contexts of use. The OECD AI Principles and the UNESCO Recommendation on the Ethics of Artificial Intelligence place attention on human-centred values, transparency, accountability, human oversight, and data governance.
The Five E Framework draws from the wider field while making a narrower claim. AI-assisted tool development needs a route holding problem measurement, rapid engineering, user communication, feedback, continued support, and ethics together.
Some tools become platforms because people access the tool through a public or private link. Platform use can create analytics. The data access model explains how analytics can become platform records and how platform records may later become research data.
A platform is a hosted tool available through a public or private link.
A platform operator is the organisation or vehicle responsible for building, deploying, maintaining, and improving a platform. The operator may be a private company, university unit, non-profit, research group, or other entity.
Ordinary platform use means using the platform for the purpose the platform was built to serve, such as practising, learning, playing, completing a task, or improving a workflow.
Analytics are measurements created during platform use, such as answers, timing, scores, difficulty levels, events, settings, or system activity.
Platform records are records created from analytics when the platform is used for the platform's ordinary purpose.
Research use means using platform records to answer a defined research question, prepare an academic output, or support a research dataset.
A research-ready dataset is an existing platform dataset potentially suitable for review. Research readiness does not approve analysis.
Institutional approval is the approval required by the researcher's university or institution before platform records may be used as research data.
An approved research extract is the specific field-limited dataset or summary released after a defined request, required institutional approval, platform-operator access approval, and agreed data-sharing terms.
Collaborator link-sharing means sharing official public links without collecting names, scores, consent forms, screenshots, contact details, or side records.
A side dataset is a separate record created outside the platform, such as a list of names, scores, screenshots, contact details, or consent forms collected by a collaborator.
Platform records are not research data by default and are created from analytics when the platform is used for its ordinary purpose. Researchers may be granted access to platform records to be used as research data after a defined study has received the required institutional approval and the platform operator has released an approved research extract.
Sharing an official public link does not make a collaborator a data collector. Collaborators should not collect names, scores, screenshots, consent forms, contact details, or side records unless a separate approved study is in place.
Figure 2 places the platform and research stages in order. The order matters because tool improvement is the primary reason platform records are created. Research publication is a later use dependent on a defined study, institutional approval, platform-operator approval, and data-sharing terms.
The platform operator deploys the tool and manages notices, rules, and records.
Platform records support maintenance, difficulty setting, quality checks, and user support.
A researcher defines a study and requests a field-limited extract from existing platform records.
Institutional approval, platform-operator approval, and data-sharing terms are agreed where required.
The approved research extract may support analysis, a paper, a presentation, or a dataset citation.
Jonga, Admin Slayer, and Pay Me Bro show how the framework can be applied to different kinds of tools. The examples are early cases, not validation of the framework across fields.
Jonga is an AI-agent research platform. In Jonga, a denizen is an AI agent inside the platform world. The platform studies agent behaviour rather than treating ordinary human use as the research object.
Economics defines the need to observe agent behaviour, Engineering builds the public platform, Education explains the platform limits, and Ethics separates denizen records from human activity.
Admin Slayer is an arithmetic and mental-maths tool. The tool turns arithmetic practice into play and gives learners a clearer sense of progress, feedback, and challenge.
Economics defines the learning problem, Engineering builds the game, Education explains the tool through use, and Ethics shapes notices, privacy, and prize-contact handling.
Pay Me Bro addresses administrative time and workflow pressure in academic settings. The tool supports work otherwise consuming time needed for teaching, supervision, research, and student support.
Economics defines the administrative problem, Engineering builds workflow support, Education explains the workflow, and Entrepreneurship asks whether users and institutions value continued support.
Table 2 gives collaborators the practical comparison. The table keeps sharing status separate from research status and points readers to the correct platform-specific page for further detail.
Scroll sideways to view the full table on small screens.
| Platform or setting | Current status | Platform record position | Collaborator action now |
|---|---|---|---|
| Jonga | Ready to share. | Platform-specific records and research limits are described on the Jonga public research page. | Share the public link and direct questions to the Jonga research page. |
| Admin Slayer normal use | Ready to share. | Normal local-first use does not create platform records from practice, marks, Academy progress, or browser autosave. | Share the official public tool link as an optional resource. |
| Admin Slayer tournament mode | Ready to share when the relevant rules and notices are available. | Official tournament mode can create platform records from performance, score, answer, timing, and difficulty analytics. | Share tournament links only with the relevant rules, notices, and prize-age conditions. |
| Pay Me Bro | Illustrative case. | A platform dataset already exists. Research access is not open yet. | Use the about page for tool context. Do not request or circulate data. |
| Table note. Public platform use can include visitors outside a collaborator's institution. Prize rules, age conditions, and platform-specific notices sit with the relevant platform. | |||
The Five E Framework remains under development. Future versions will be refined through further tools, user feedback, collaborator criticism, platform-specific pages, and later approved research outputs.
The current document does not claim framework validation across fields. The current tools show early applications of the framework in AI-agent research, arithmetic practice, and administrative workflow support. Future versions may add platform-specific data summaries, fuller references, formal research questions, approved research extracts, and journal papers.
Platform-specific pages should remain the source for platform notices, field lists, data-handling rules, and research access processes. The conceptual working paper records the shared framework and the general model.
The Five E Framework gives AI-assisted tool development a route from problem definition to tool-building, user education, feedback, and continued support. The framework begins with a simple ethical premise: AI should be used to build supportive tools for human work. The tool should make the user more able, not less necessary.
The platform data access model defines the boundary between ordinary link-sharing and later research use. Collaborators may review the framework and share official public links where appropriate. Researchers need a defined study, institutional approval, and an approved research extract before platform records can be used as research data.
The next stage is to strengthen the framework through criticism, clearer platform-specific pages, and later approved research outputs. The current paper serves as a first public conceptual account of the Five E Framework and the data access model following from platform-based tools.
The references below position the conceptual working paper beside design thinking, lean startup methods, human-centred design, and AI ethics guidance.