Whoever creates a training project uploads the documents. The system generates the path, calibrates the quizzes where needed, reformulates the explanations in the style that works for each learner. A single system serves three distinct audiences: companies training their own employees, professionals preparing for exams and certifications, students studying on their own materials.
The founding principle of AYXZA Tutor is simple: whoever creates a training project uploads the manuals, and the system does the rest. From the uploaded documents the artificial intelligence generates a proposal for a structured learning path, which the creator validates. End users walk the modules with explanations generated from the corpus, quizzes that focus where they get it wrong and reformulations calibrated on the approach that works for them. Companies get completion tracking and certificates; individuals get a personal tutor that knows them.
Three different needs coexist in the same system. The content and the context change, not the engine. This is the platform's first economic advantage: a single engineering practice serves markets that normally require separate products.
Onboarding, internal procedures, compliance (for example safety or anti-money-laundering material as non-certified internal training), updates on one's own products and services. The company uploads its manuals and trains its employees on its real material.
Qualifying exams, technical certifications, public competitions. The professional uses a project from the official catalogue or uploads their own materials and builds a tailored path, with quizzes that insist where they are weakest.
The student uploads their own notes and books and has the path built for them: explanations drawn from their material, scheduled review of wrongly-answered concepts, an available tutor that answers only on what has been uploaded.
The training project is the central entity. From uploading the documents to issuing the certificate, the path goes through a precise sequence. The system generates the learning proposal; approval always stays with a person.
A guarantee constraint, not a detail: no project goes into delivery without human validation of the syllabus. The machine proposes, the person responsible for the content approves. It is the safeguard that holds together the promise of automation with training responsibility.
The platform is organised on a four-level hierarchy. The colour identifies the role throughout the interface: slate for the superuser, petrol for the company or the individual, ochre for the end user. An intermediate level (the reseller) is present in the system but stays dormant in this version, ready to activate an indirect channel with no rework.
| Level | Who they are | What they can do |
|---|---|---|
| L4 · Superuser | AYXZA | Manages the entire platform: the L2s, the catalogue of official projects, the global analytics, the AI engine console, the enabling of permissions per individual company. |
| L3 · Reseller | Dormant | No interface in this version. It is present in the system: every L2 is already attached to a default reseller. Opening the indirect channel will require no structural work. |
| L2 · Company / Individual | Client company, or the single professional/student | Manages its own L1s (companies only), creates internal training projects, activates and assigns official-catalogue projects, sees completion reporting, enables or disables personal creation for its users. |
| L1 · End user | Employee, professional, student | Has their own login and a personal learning history. Walks the assigned projects and, if enabled, creates personal projects. |
A professional or a student registers on their own and lives the experience as an ordinary single account. Underneath, the system creates in a single operation an “individual” L2 and an L1 within it. The interface never shows employee management, group reporting or company permissions. This choice has a precise reason: a single path in the code for permissions, quotas and billing. Billing is always to the L2, whatever it is.
Every project has an owner, a visibility perimeter and a lifecycle. The underlying rule is clear: only the creator modifies. A company does not touch another company's projects or those of the official catalogue; it uses them. A catalogue project activated by a company stays AYXZA property: the company assigns it, does not modify it.
Every enabled level: the superuser for the official catalogue, the company for its own internal paths, the end user for their own (if the company allows it; for individuals it is always allowed).
The creator uploads the source documents. Technical requirement: the files must contain extractable text. Image-scans are rejected on upload with a clear message and guidance on how to obtain a text document.
The system analyses the corpus and proposes modules, topics and learning objectives, mapping every topic to the sections of the manuals it derives from.
The creator reviews the proposal: renames, reorders, merges, deletes, adds modules. Approval is explicit and mandatory.
New manuals, syllabus revision, new version. Users' progress on previous versions stays archived and is not lost.
| Created by | Visibility | Example |
|---|---|---|
| L4 | Official catalogue: companies activate it and assign it to their users | “State-exam preparation”, “Basic IT security” |
| L2 company | Only its own users | “Onboarding new hires”, “Internal quality procedures” |
| L1 | Only themselves | The student uploads the university course notes |
Personal creation by employees is governed by a permission, off by default in companies and always on for individuals. When it is on, an employee's personal projects live within the company perimeter but their content is not visible to the company: the company knows they exist and how much space they occupy, not what they contain. It is the principle of proportionality applied to data.
The explanations are generated from the project's manuals, navigable by topic. The user can ask free questions on the module and receives answers grounded in the uploaded material; below a confidence threshold, the system declares it cannot answer from that material instead of inventing.
Multiple choice, true/false with justification, short open questions assessed by the AI. The pass threshold is configurable by the creator (seventy per cent by default). Every question is verified against the sources before being administered.
Once the threshold is passed, the module is completed and the next one unlocks, with a recorded date. On completing all modules: final project outcome and, where provided, certificate.
Adaptivity is not a label. It takes two concrete forms, both based on fine tracking of every answer, traced back to the syllabus concept it belongs to.
The generator draws or produces more questions on the concepts where the user has a history of errors, fewer on the consolidated ones. Wrongly-answered concepts return in the quizzes of later modules days apart: a scheduled review, simple but effective.
When the error recurs on the same concept, the system reformulates the explanation with an alternative approach: practical example, formal definition, analogy, step-by-step procedure. It records which approach preceded success. The effective-style profile, learned per person, guides reformulations across all their projects. An explicit guard in the prompts prevents the reformulation from being a mere paraphrase: it must change the approach, not the words.
The reporting is deliberately asymmetric, and this asymmetry is a guarantee offered to the end user, not a limit. The separation is enforced at the level of data querying, not just the interface: the individual learning datum is not reachable by the company by construction.
The anonymisation threshold (five users minimum per aggregate) prevents the “group” datum from becoming a way to trace back to the single person. The signal the company obtains stays valuable: if a concept puts the whole group in difficulty, the material is often lacking or badly explained, and that is where it is worth intervening.
On successful completion the system generates a PDF document with the person's data, the project, the syllabus version, the date, the outcome, a verification hash and the platform's digital signature. It counts as internal evidence and corporate documentation. It is not a certification of regulated mandatory training: the possible route to that recognition passes through partnerships with accredited bodies, and is outside the perimeter of this version.
Training is born from the company's real procedures, not from generic courses. Completion tracking and certificates ready for internal audit. Respect for the person: no surveillance of individual errors, an element that eases adoption and labour relations.
Preparation focuses where one is weak and reviews wrongly-answered concepts at the right time. The explanations change form until one works. Study time goes where it is needed, not evenly spread over what one already knows.
The student uploads notes and texts and gets a structured path, with assessment and review. The tutor answers only on what has been uploaded: no off-syllabus hallucinations, no content extraneous to the course.
No instructional designer is needed to build the path: the system proposes it from the documents, and a person validates it. The human work shifts from writing to review, far faster.
The same platform serves companies, professionals and students. No product fragmentation, a single system to maintain and evolve, economies of scale that reflect on the price.
An honest product declares what it does not do. The limits that follow are partly technical constraints of the current version, partly deliberate design choices. Knowing them beforehand avoids disappointed expectations.
The manuals must contain extractable text. Image-scans are rejected on upload. A share of real corporate material is made of scanned documents: for those cases a text PDF must be obtained first.
They count as internal evidence, they do not replace certified mandatory training (for example that required by safety law) nor do they grant credits from professional bodies.
Anyone expecting a control dashboard on the single employee will not find it: it is a choice, not a shortcoming. To a manager used to individual measurement it may seem a limit; for the organisation it is a protection.
On disordered or incomplete material the syllabus proposal can be weak. Human validation is the safeguard for this, but it remains real review work: it is not “zero effort”.
Every question passes a verification against the sources and the user can report an error, which enters a review queue for the creator. The residual risk exists, as in every generative system, and must be overseen by human review.
The AI functions rely on external language-model providers, under the relevant processing agreements. For companies with stringent requirements a dedicated profile is available (see the technical part).
Errors, question sessions and learning profile are accessible only to the person concerned, never to the company. The separation is enforced at the level of data querying.
Traffic encrypted at the edge, secure cookies, protection against forged requests in restrictive mode, passwords stored with a robust hashing algorithm.
For employees the data controller is the company and AYXZA is the processor; for individuals AYXZA is the controller. Export and total deletion per organisation are provided.
For those who cannot accept that content transits a shared infrastructure, a dedicated-instance profile is available: same platform, a single client.
The architecture favours stability and reuse over novelty. It deliberately takes up the patterns of another AYXZA system already in service, so as to rest on tested skills and operational procedures instead of reinventing them.
| Area | Choice |
|---|---|
| Application | FastAPI with Jinja2 templates, server-side rendering, no single-page application. A light and robust interface. |
| Database | PostgreSQL with the pgvector extension for semantic search. A dedicated database with separate schemas for the domain and the AI engine. |
| Authentication | Robust password hashing, server-side session, role re-read from the database on every request, password change on first access, anti-forgery protection in restrictive mode. |
| AI engine | AYXZA Relay as an in-process dependency. All AI functions pass through the engine as versioned prompts; no direct calls to providers from the application. |
| Multi-tenancy | Logical isolation: the scope of every operation is derived from the server-side session, never from the payload sent by the client. The dedicated profile is the same codebase with a single client. |
Every intelligent function is a versioned prompt on the engine, with a validated output schema where needed. The most commercially sensitive risk, a quiz with a wrong answer, is overseen by a double pass.
| Function | How it is built |
|---|---|
| Syllabus generation | Multi-step chain: structure extraction, topic grouping, module proposal, objective definition. Output in structured, validated format. |
| Explanations and free questions | Query of the project's knowledge base (RAG), with declared confidence; below threshold the system admits it cannot answer from the material. |
| Quiz generation | Prompt with output schema (question, options, correct answer, concept, error explanation). Double pass: a critic prompt verifies every question against the sources before administration. |
| Open-answer evaluation | Evaluator prompt with a rubric, returning score and feedback. |
| Explanation reformulation | Prompt with an approach parameter and per-user approach history, with an explicit guard against paraphrase. |
The data core is designed so that tomorrow's adaptivity does not require reworking the schema. Every answer is recorded with the concept, the type of error, the module, the instant and the explanation approach served: the granularity that today feeds adaptivity, and that tomorrow will enable a deeper diagnosis of causes.
| Entity | Role |
|---|---|
| progetto_formativo | The central entity: title, status, creator, current version, code that attaches the knowledge base. |
| sillabo_versione | Immutable snapshot of the approved syllabus, with reference to the original AI proposal for traceability. |
| avanzamento | Per person and project: current module, status, final outcome and completion date. |
| evento_apprendimento | The granular log of every learning interaction. It is the basis of adaptivity and future diagnosis. |
| profilo_didattico | Per person: the explanation approach that proved effective, and the style statistics. |
| attestato | The document generated on completion, with a verification hash and the platform's signature. |
The platform is offered as a multi-tenant service, with logical isolation of clients. For organisations with stringent confidentiality requirements a dedicated-instance profile is available: the same codebase, a single client, no sharing of infrastructure with others. The choice between the two profiles does not change functionality, it changes the boundary on which the data lives.