Executive summary

Within a single intensive week, with AI used as a force-multiplier, we moved a production educational analytics product from a flat, tab-heavy interface toward a layered decision-support workspace. The work covered the full cycle: UX and interface trend research, a timed key-user scenario, functional information architecture, a formal coverage matrix, stakeholder confirmation, visual direction, and migration of the working product onto the new UX.

The redesign is part of a larger transition. The first version was built in Streamlit and proved the analytical model, but the framework was becoming a constraint for the next stage of the product. The new interface is being implemented as a React workspace, providing considerably more control over interaction, information hierarchy and progressive disclosure.

The original baseline came from direct work in Moodle: a teacher’s group performance review took roughly 40 minutes of navigating the LMS gradebook, reports and individual activity logs. The product goal has always been to bring that down to 5–10 minutes with explainable analytics.

The central UX idea is not simply “fewer tabs”. It is a shorter feedback loop: what is happening → where is the problem → what data confirms it? The new interface is organised around this loop. Overview establishes the state of the group; Problems identify what deserves attention; Data provides the evidence and detailed indicators needed to verify and investigate it.

This post is the design and product companion to the earlier technical write-ups: Lightweight BI system for university, part I and part II (how the analytics is built) . Those posts describe the data model, the rule-based engine and the original nine-tab Streamlit surface. Here the focus is on why and how the interaction model and technical surface are changing.

The design problem: from analytics terminal to decision support

The first version already solved an important technical problem: it collected a large amount of educational data and turned it into structured, explainable findings. The remaining problem was interaction.

A teacher does not normally approach an analytics system with the question “which dashboard should I open?” The natural sequence is closer to:

1. What is happening?
2. Where is the problem?
3. What data confirms or explains it?

In the original interface these three jobs were distributed across several equally weighted tabs. The user had to assemble the relationship between overview, finding and supporting data mentally.

The redesign therefore does not primarily optimise the number of screens. It optimises the feedback loop between interpretation and evidence.

The intended interaction is:

Overview → Problems → Evidence in Data → back to the decision

This creates a natural progressive-disclosure model. The system does not expose its full analytical depth immediately. It reveals the next level when the user has a reason to ask for it.

Where UX of data-heavy apps actually went

Before redesigning anything, we re-checked the broader trajectory of professional interface design over the last 15 years — not as a sequence of visual fashions, but as a gradual shift in what the interface is expected to organise.

• From chrome to content. One of the first decisive moves was rejecting heavy decorative frames and treating the interface itself as secondary. The data, the task and the user's context should come first; surrounding chrome should recede. This established a simple principle: the interface exists to support the work, not to compete with it.
• From individual screens to systems. Material Design and parallel design systems then brought a more systematic approach: shared components, predictable structure, consistent hierarchy and reusable interaction patterns. This improved coherence across large products, although it also created a new temptation to treat the component library itself as the centre of the design.
• From visual hierarchy to information hierarchy. The next wave became quieter: less decoration, less visual noise, less motion, and more emphasis on legibility, progressive disclosure and task efficiency. The important question increasingly became not “What can we put on this screen?” but “What does the user need to understand or do at this point?”
• From information hierarchy to decision flow. For data-heavy applications, this leads to a more fundamental shift. The interface does not have to expose analytical instruments as the primary navigation model. It can instead structure the user's reasoning: what is happening → where is the problem → what data confirms it → what should I decide? Dashboards and detailed analytical views do not disappear; they become evidence and working instruments inside a larger decision-support flow.

This is the direction that matters for educational analytics. A teacher does not naturally think in terms of dashboards or analytical modules. The practical question is closer to: what is happening in my course, where should I pay attention, and what evidence supports that conclusion?

So the goal is not to build another analytical terminal. It is to provide a calm, hierarchical surface that supports this reasoning loop: orient first, identify the problem, verify it with data, and then decide — without forcing the teacher to reconstruct the analytical model of the system for every weekly review.

The old design — what we started from

The first production surface was a Streamlit dashboard with a global sidebar and nine specialised tabs:

• Themes (level-1 “flower” overview)
• Questions
• Student
• Insights
• Risk group
• Trends
• Score structure
• Deadlines / attempts / effort
• Attendance and activity

It already delivered the analytical model: rule-based findings with evidence, hypothesis, alternatives, recommendations and limits; theme map as orientation anchor; and full coverage of the ТЗ queries.

Strengths we kept: complete analytical coverage, explainable (non-LLM) findings, a solid incremental engine, and the theme map as the central orientation device.

Pain points that still stood in the way of the 5–10 minute target:

• Flat information architecture. Nine equally weighted tabs forced constant context reconstruction.
• Cognitive overload. Dense tables and uniform visual weight made the tool feel closer to a terminal than to decision support.
• Weak progressive disclosure. Findings and full BI lived on the same mental plane; the weekly path had no privileged short route.
• Context reconstruction. Moving between tabs could feel like starting over; filters lived in a sidebar that was easy to forget.
• Technology constraint. Streamlit was useful for validating the analytical concept and getting the first working product running quickly. As the interaction model became more sophisticated, however, it provided less flexibility and control than the product required for the next stage.

The ~40-minute baseline itself was measured in direct work with Moodle (gradebook, reports, activity logs), not on this first dashboard. The Streamlit surface was already an attempt to shrink that time; the UX redesign removes the remaining interaction friction while the technology migration provides the flexibility needed to implement the new model properly.

Key user scenario broken down by timing

The primary job is a weekly (or post-control) performance review. The original cost was measured in Moodle; the first product version reduced part of that cost; the redesign targets the remaining friction so the intended path fits the 5–10 minute band.

Baseline — direct work in Moodle (~40 minutes)

1. 0–10 min. Open course, gradebook and multiple reports; locate the relevant group and period.
2. 10–25 min. Cross-check topic results, individual attempts, attendance and activity logs; open students individually where needed.
3. 25–40 min. Mentally synthesise what needs attention — which topics, which students, which items to simplify or repeat — and form an action list.

First product version — structured, but still flat

Nine flat tabs and sidebar filters already replaced raw Moodle navigation with structured panels and explainable findings. Orientation and cross-referencing, however, still cost time: the user had to reconstruct “what is still relevant for this slice” after every tab switch.

After redesign — the intended 5–10 minute path

1. 0–30 sec. Global context shows the active slice (course › theme › student › work type). Three KPI cards and the theme map answer: “What is the state of the group?”
2. 30 sec – 3 min. Open Problems (Findings). Prioritised signals show severity, a short rationale and “Подробнее”. The user does not need to hunt across several analytical tabs.
3. 3–7 min. Open one or two findings into full xAI cards: hypothesis, evidence, alternatives, recommendations and limits. Drill into a theme or student while the global context remains intact.
4. 7–10 min. If a specific indicator or additional confirmation is required, move to Data and open the corresponding panel. Every ТЗ query still has an address, but the default path does not require visiting all of them.

The time saving is therefore not simply “fewer screens”. It comes from shortening the feedback loop and separating three jobs that previously competed on the same flat surface: orient → identify the problem → verify with data .

Functional design & information architecture

The redesign does not delete capability. It re-sequences it around the teacher's decision process.

• Global context (course › theme › topic › student + work type) is always visible and never silently reset.
• Overview establishes what is happening.
• Problems / Findings identifies where attention is required.
• Data / Analytics provides the evidence and detailed indicators needed to confirm, investigate or challenge the finding.
• Theme map (“цветочки”) remains the central orientation device on Overview.
• Every ТЗ query 1–14 has an explicit address under Data (Performance / Learning process / Assessment / Students).

The resulting UX contract is deliberately simple:

Overview tells me what is happening.
Problems tell me where to look.
Data tells me what confirms it.

This is the core of the redesign. The three layers are not merely different navigation categories; they form a single analytical feedback loop on the same data slice.

Functional wireframe of the Overview layer (global context + KPIs + theme map):

Figure 1. Functional design — Overview. Context is persistent; colour of theme cards follows thresholds (green / yellow / red).

Layer responsibilities:

Coverage matrix — requirements ↔ new UX

A formal matrix was produced so stakeholders could verify that a navigation change does not equal functional loss. Two independent acceptance criteria were kept separate:

• UX coverage — is the 30-second / 2-minute / 5–10-minute path comfortable?
• Requirement coverage — where does each US / ТЗ item live physically?

This distinction matters. A simpler interface is not a successful redesign if it achieves simplicity by hiding or removing required analytical capabilities.

Excerpt (US → UX location in IA v3):

Current → Proposed mapping of the nine Streamlit surfaces was also documented: themes → Overview flowers; insights → Problems; remaining tabs → Data groups; sidebar → global context.

The principle communicated to stakeholders was simple: “navigation changed, requirements not lost.”

From Streamlit to React

The UX redesign also exposed a technology decision. The first version was intentionally built in Streamlit because it provided a fast route from analytical code to a working interface. That was appropriate for validating the product concept.

As the product evolved, however, the interface itself became part of the engineering problem. Persistent context, layered navigation, progressive disclosure, richer interactions and precise control over the visual hierarchy required more flexibility than the original framework comfortably provided.

The product is therefore moving from Streamlit to React. This is not a cosmetic technology replacement. It is a migration from a rapid analytical surface to a UI architecture capable of supporting the intended interaction model.

The migration is already more than halfway complete. The remaining Data layer is deliberately not being redesigned from scratch: its role is primarily to bring the existing first-version dashboards into the new information architecture. This keeps the migration focused on the parts where UX change creates the greatest value.

In other words, the new architecture changes the route through the analytics without requiring the analytical depth itself to be rebuilt.

Applying the new design — current product

The new workspace is already implemented for the main interaction path. The visible outcomes are:

• Calm, modern visual system — content before chrome, without unnecessary decoration.
• Persistent global context + three clear layers: Overview / Problems / Data.
• Theme map retained as the orientation anchor.
• Findings list established as the attention layer.
• xAI cards with hypothesis, evidence, alternatives, recommendations and limits remain first-class.
• The full analytical catalogue remains accessible through the Data layer.
• Core weekly review path is designed around a 5–10 minute target, against a ~40-minute Moodle baseline.

Overview — what is happening?

Figure 2. Production Overview: KPI strip + colour-coded theme map.

Problems — where is the problem?

Figure 3. Problems layer: prioritised findings with severity and short rationale.

Finding detail — why does the system think this is a problem?

Figure 4. Full xAI card: hypothesis, evidence, alternatives, recommendations and limits.

Data — what confirms it?

Figure 5. Data layer: Performance, Learning process, Assessment quality, Students — full coverage without forcing a findings-first workflow.

The Data layer shown here is currently a design concept. Its implementation is the remaining major part of the UX migration and is expected to reuse the existing first-version dashboards rather than introduce another analytical redesign.

Value delivered

The product is moving from a dense analytical terminal toward a decision-support environment built around a much more natural sequence of work:

• What is happening? Overview provides fast orientation.
• Where is the problem? Problems prioritises the signals that deserve attention.
• What confirms it? Data provides the underlying indicators and detailed evidence.

This preserves the analytical depth of the original product while reducing the amount of mental work required to use it.

• Respects limited attention through progressive disclosure.
• Keeps every requirement reachable (the coverage matrix provides the traceability).
• Builds trust through transparent, rule-based xAI findings.
• Preserves analytical depth while making the default path short.
• Provides a clear route from observation to problem to evidence.
• Moves the UI from Streamlit to React to support the required interaction model and future product development.

The target is a focused 5–10 minute weekly review, starting from a ~40-minute Moodle baseline. This is a design and product target, not yet a post-redesign user-test result.

The redesign therefore is not simply a visual refresh. It is a change in the interaction model of the product: orient → identify → verify → decide.

The remaining work is intentionally narrower than the redesign already completed: migrate the existing analytical dashboards into the Data layer and complete the React migration. The main UX architecture and decision-support path are already in place.

Prepared with assistance from ChatGPT and Grok.

Related publications

Lightweight BI system for university, part I
Lightweight BI system for university, part II: how the analytics is built
Broad vs Narrow specialisation

Executive summary

Part I described the constraints of the project, the synthetic LMS dataset, and the overall shape of a lightweight BI system for university instructors: reduce group review from roughly 40 minutes to 5–10 minutes, without black-box LLMs for educational decisions, and with explainable AI (xAI) as a hard requirement.

This part focuses on how analytics is actually constructed — not on another catalogue of charts, but on the path from raw LMS facts to findings that an instructor can accept, reject, or act on.

The system separates two concerns that are often mixed in “AI dashboards”:

• Visual panels — the same kinds of facts that already live in Moodle-like systems, organised for teaching decisions (themes, questions, scores, trends, effort, attendance);
• Rule-based insights — findings with evidence, hypotheses, alternative explanations, confidence, limitations, and recommended interventions.

Analytics runs in a dedicated analytics-engine: incremental batches over changed topics, snapshot rules on topic metrics, trend rules on time series, student-risk signals, and persisted explanations. The Streamlit dashboard is mostly a reader of facts and of the latest completed analytics run.

The dashboard exposes nine tabs. Together they cover level-1 “flower” overviews and level-2 panels aligned with LMS queries (scores, dynamics, score structure, deadlines and attempts, difficulty extremes, attendance and activity), plus an insights layer and an at-risk group report.

Roughly thirty finding types and a separate student-risk signal set implement the extraction logic. Listing every rule would turn this post into a reference manual. The value is in the extraction pattern. Below, that pattern is shown end-to-end, then illustrated with non-trivial rules and with three screenshots from a live run on synthetic Economics data.

The design principle stays the same as in part I: the system supports judgment; it does not replace the instructor.

Relation to part I

For context on constraints, synthetic generation, and the first version of the UI, see Lightweight BI system for university, part I.

Architectural principle: visualisation vs interpretation

Instructors do not need another dump of averages. They need a short path from observation to possible intervention.

Rules are thresholds + logic, not generative models. Thresholds can be calibrated per course (YAML, optional admin UI) without rewriting rules. Empty insights are not always a defect: if every submission is on time, deadline rules correctly stay silent; if a topic spans only two weeks, decline-streak rules may not fire.

How the analytics engine works

Incremental batch

1. Read unprocessed changes (topics, results, assignments, activity, …).
2. Resolve an impact set of topic ids.
3. Hydrate state for those topics (results, attempts, attendance, activity, students).
4. Compute: metrics → snapshot rules → trend rules → enrich → explanations → student metrics → risk flags.
5. Persist a new analytics run; acknowledge changes.

Only touched topics are recomputed. A pipeline lock avoids concurrent writers.

Three families of logic

Every topic finding is expected to carry evidence (metric values). The explanation layer adds hypothesis, alternatives, recommended actions, and limitations.

What the engine deliberately does not do

• It does not invent causal certainty (“this student failed because of X”).
• It does not replace the Moodle gradebook.
• It does not call an LLM to invent recommendations for production educational decisions (customer constraint described in part I).

From metrics to a finding: the extraction pattern

Regardless of which of the ~30 finding types fires, the path is the same:

1. Aggregate raw rows into a metric row (topic or student).
2. Evaluate a pure rule: thresholds + boolean conditions + minimum sample size.
3. Attach evidence strings that a human can check against the dashboard tables.
4. Render a fixed explanation schema: observation → hypothesis → alternatives → recommendations → limitations.

The non-trivial part is rarely the inequality accuracy < 0.5. It is choosing which combinations of signals change the instructor’s next action, and forcing the system to show alternatives when several stories fit the same numbers.

Non-trivial rules (worked examples)

Trivial rules (“accuracy is low”) are necessary, but they are not where the design effort sits. The following three families are more characteristic of the system.

1. Deadline versus understanding

LMS attempts carry both a score and an on-time flag (and often duration). Two different teaching problems produce similar “weak result” charts:

• Missed deadline — share of on-time submissions is low, but accuracy is still in an “acceptable” band → time management / workload / cutoff design;
• Did not understand — submissions are mostly on time, accuracy is weak, often with many attempts → content, prerequisites, or item design.

Related variants include on-time submission with very few attempts and a weak score (shallow engagement) and a long single attempt with a weak score (stuck without recovery). On the current synthetic set, almost all attempts are marked on time, so missed deadline correctly does not fire. That is a data property, not a missing rule.

2. Multi-signal student risk

Topic findings answer “what is wrong with the theme”. Risk answers “who needs attention, with a short rationale”.

A student enters the risk set only when several independent signals co-occur (weak accuracy across topics, low average score, absences, attempt patterns, engagement extremes, late rate, …), above a minimum answer count. Severity is derived from how deep accuracy falls and how many signals stack. Justification text is assembled from the same signals so the instructor can audit the row without opening a black box.

In the run shown above, the report lists 25 students, 22 of them at high severity, with mean success around 45%. Each line combines weak topics, accuracy, average score, missed sessions, and median attempts. That is the “summary report on the risk group with rationale” from the original requirements — not a single red flag on one metric.

3. Score structure as a bridge to intervention

Before recommending a seminar on a topic, the instructor needs to see how far that topic pulls the cohort below the slice average. The score-structure panel ranks themes by result and by delta to the overall mean (descriptive gap, not a causal “contribution” claim).

Elasticity sits at roughly 2% with a −52 percentage-point gap to the slice average. Production Costs, Firm Theory, and Monetary Policy follow with smaller negative deltas. The same numbers feed snapshot findings; the table is the visual counterpart of “what to open first on Insights”.

4. Insights card: full xAI schema on a hard theme

When a theme such as Elasticity collapses to ~2% accuracy with full completion, a low-accuracy (or none-solved) rule is expected. The product value is not the label; it is the structured card the instructor actually reads.

The card separates:

• Hypothesis — possible teaching meaning, including the hardest items (Q06, Q03, …);
• Observation / evidence — the pattern and the supporting rate;
• Alternatives — poor item wording, weak prerequisites, overly hard control materials (so “bad students” is not the only story);
• Recommendations — concrete seminar focus, drills on logical errors, checks of basic concepts;
• Limits — e.g. missing instructional context (what was taught that week).

That structure is applied across finding types. Adding a new rule means implementing the same contract, not inventing a new prose style per metric.

The nine tabs

Global sidebar filters (group, student, assignment type, period) apply across the visual tabs. Insights and risk read the latest completed analytics run.

1. Themes (level-1 “flowers”)

Question: where does the cohort struggle by topic?
Performance and error structure (logical / arithmetic / terminology). Snapshot rules on accuracy, error dominance, pressure, all/none solved continue on the Insights tab.

2. Questions

Question: which items are too hard or too easy?
Item-level success rates; question rules such as almost nobody / almost everybody solved support simplify / complicate recommendations.

3. Student

Question: how is one student doing across topics?
Drill-down in the current filter slice. Multi-signal problems surface on Risk group.

4. Insights

Question: what stands out, and what might I do?
Main surface for topic and question findings after explanation generation — the “intelligent assistant” layer, not a second gradebook.

5. Risk group

Question: who needs attention, and why?
Named students with severity and justification. Complements Insights (theme problems versus people).

6. Trends

Question: is mastery rising or falling over time?
Score and attempts over periods. Trend findings (decline, improve, effort up with flat score, volatility) need a long enough series per topic; short sequential courses may yield few hits.

7. Score structure

Question: what pulls the observed result down?
Descriptive ranking and deltas (screenshot above). Exploration first; Insights still carry formal findings.

8. Deadlines, attempts, and effort

Question: did they run out of time, or fail to understand?
On-time rate, median attempts, time-on-task, score side by side — the metric surface for the deadline-versus-understanding rules.

9. Attendance and activity

Question: do absences or empty LMS activity explain weak results?
Attendance and engagement crossed with scores; topic-level patterns and student-risk signals (e.g. high engagement with low results, low attendance with low results).

Cross-cutting behaviour

• Empty insights are not always a bug. Rules fire on patterns present in the facts.
• Insights ≠ all nine tabs. Tabs 1–3 and 6–9 are exploration; 4–5 carry structured conclusions.
• Human remains responsible. Alternatives and limitations are part of the product.
• Production data path (forward-looking): Moodle primary → isolated replica → ETL into the AI database → engine → dashboard. Applications do not connect to the LMS primary.

What this implies for “AI in education” dashboards

A large share of educational “AI” demos still jumps from a chart to a paragraph of model-generated advice. This prototype takes the opposite route: measurable indicators first, rule matches second, prose last — and only inside a fixed schema.

That is slower to market as a feature list, but it matches the customer constraint (no LLM for graded educational decisions) and matches how instructors already argue in staff meetings: numbers, competing explanations, then a concrete next step.

Next steps

• Deep-links from a finding to the matching visual tab with filters preserved;
• Instructor auth / RBAC before wide production use;
• Calibration of thresholds on real course extracts once the replica + ETL path is live;
• Richer synthetic (or real) patterns for rare rules — e.g. late submissions, long per-topic time series.

Related publications

Lightweight BI system for university, part I
Lightweight BI system for university, part III: UX redesign targeting 5–10 minute weekly review
Artificial Intelligence in Education and Management

Summary

The Russian healthcare system faces not merely a question of the current number of physicians.

A more fundamental question is this:

Is the healthcare system capable of independently reproducing sufficient medical capacity amidst demographic shifts in the population, the aging of the physician corps, the retirement of senior generations, changes in the attractiveness of medical education, and the rise of alternatives for young specialists?

This question is fundamentally different from "How many doctors does Russia need?"

The number of physicians is only one variable. For system sustainability, the following factors are simultaneously important:

• physician numbers;
• age structure;
• specialty;
• region;
• actual employment;
• professional longevity;
• influx of new specialists;
• residency completion;
• retention of physicians in the profession;
• working conditions;
• income relative to alternative professions;
• productivity;
• digitalization;
• preservation of institutional medical experience.

In 2026, signals emerged that warrant separate analysis.

On one hand, the Ministry of Health reports that for 20,000 budget‑funded residency positions, 39,000 applications were submitted, and therefore considers it premature to speak of a systemic shortfall.

On the other hand, major medical universities reported hundreds of unfilled budget‑funded residency positions and announced additional enrollment. As of mid‑August, vacancies were reported at Pirogov Russian National Research Medical University, Sechenov First Moscow State Medical University, the Russian Medical Academy of Continuing Professional Education, and other institutions.

These observations do not contradict each other. Overall competition may remain high, while simultaneously individual regions, specialties, or targeted positions may experience candidate shortages.

This is precisely why what is needed is not a single competition statistic, but a dynamic model of medical workforce reproduction.

It is proposed to create a Medical Workforce Capacity Model (MWCM).

Its task is not to provide a "precise forecast through 2045," but to determine:

• which parameters determine the sustainability of the medical system;
• which of them are most sensitive;
• where shortages emerge first;
• what effect each individual parameter change produces;
• what the delay is between a policy decision and its result;
• which measures compensate for demographic decline;
• where the boundary lies between temporary shortage and self‑sustaining workforce crisis.

What the Model Does NOT Do

To avoid misinterpretation, it is essential to state clearly what MWCM is not:

• It is not a demographic forecast of the total number of physicians in 2045.
• It is not a detailed workforce plan for the entire country.
• It is not a justification for indiscriminately increasing or decreasing budget‑funded places without considering specialty and region.
• It is not a substitute for clinical expertise or evidence‑based medicine.
• It is not an excuse to lower training standards or quality of care.
• It is not a crystal ball — it is a tool for exploring dependencies, comparing scenarios, and identifying leverage points.

The model is useful precisely because it makes visible the trade‑offs and time lags that are otherwise hidden in aggregated statistics.

1. The Problem

Traditional workforce planning often relies on metrics such as:

• physicians per 10,000 population;
• number of graduates;
• number of budget‑funded places;
• number of vacancies;
• number of applications;
• average physician age.

These indicators are necessary but insufficient.

For example, a system can simultaneously have a large number of students, high competition for medical schools, physician shortages in regions, an excess of candidates for some specialties, unfilled positions in others, a large number of older physicians, growing workload, and increasing healthcare expenditures.

This is not a contradiction. It is the result of different parts of the system moving at different speeds.

2. Core Idea of the Model

It is proposed to distinguish between the number of physicians \(D_t\) and effective medical capacity \(EC_t\).

Effective capacity is determined not only by the number of physicians:

where:

• \(D_t\) — number of physicians;
• \(A_t\) — actual availability of physicians for clinical work (share of working time spent on direct patient care);
• \(P_t\) — productivity per physician (e.g., number of consultations or procedures per unit of clinical time).

A 10% increase in the number of physicians does not necessarily mean a 10% increase in medical capacity. If at the same time bureaucratic burden has grown, actual employment has decreased, or patients have become more complex, the effect may be substantially smaller. Conversely, automation of part of the work may increase effective capacity with an almost unchanged number of physicians.

3. Reproduction of the Physician Corps

The number of physicians changes as a stock affected by flows:

where:

• \(N_t\) — new physicians entering practice;
• \(I_t\) — immigration inflow;
• \(R_t\) — exit from the profession due to age;
• \(L_t\) — other losses: leaving clinical medicine, career change, emigration, transition to administrative roles, etc.

This yields the first key indicator — the physician reproduction rate:

Interpretation:

• \(RR > 1\) — generation is reproducing;
• \(RR = 1\) — approximate equilibrium;
• \(RR < 1\) — the physician stock begins to structurally contract.

What matters is not only the national \(RR\), but also \(RR\) by region and specialty.

4. Why Generational Change Is a Separate Problem

The physician corps has an age structure. Therefore, it is necessary to model age groups: 25–29, 30–34, 35–39, 40–44, 45–49, 50–54, 55–59, 60–64, 65–69, 70+.

This allows us to see not only the current shortage, but also the future wave of attrition. Particularly important is the situation where the younger generation is smaller than the older generation approaching retirement. In this case, the problem becomes partially predetermined.

4.5. Regional Heterogeneity as a Separate Risk

National averages mask deep regional disparities. Even if the national \(RR = 1\), individual regions may have \(RR = 0.6\) while others have \(RR = 1.4\).

• National aggregates hide crisis points;
• Physician mobility between regions is limited;
• Solutions must be tailored to specific regional and specialty contexts.

Therefore, the model should output a map of \(RR\) by region and specialty, not a single national number.

5. Loss of Experience — A Separate Component of Risk

The departure of a physician means the loss of not just one working unit. In some cases, along with the physician, the system loses accumulated clinical experience, the ability to recognize rare cases, knowledge of local processes, mentoring skills, informal problem‑solving approaches, and institutional memory.

Therefore, capacity loss ≠ numerical loss. In some specialties, capacity loss significantly exceeds numerical loss.

This is precisely where this model connects with the previously proposed concept of Digital Memory of Medical Institutions — the preservation and reuse of accumulated clinical experience. The concept envisions creating an infrastructure layer atop existing medical information systems that transforms documented practice into structured, traceable, and reusable institutional memory.

6. The Educational Pipeline

A physician does not appear in the system immediately after the state decides to increase the number of budget‑funded places. Simplistically:

where \(S_t\) — potential applicant pool; \(M_t\) — admitted; \(G_t\) — graduates; \(O_t\) — those completing required specialization; \(N_t\) — entering practice.

Thus, a budget‑funded place ≠ a future physician. There are several filters between them.

7. A Young Person's Choice of Medicine

The number of potential physicians depends not only on demography. Simplistically:

where \(C_t\) — probability of choosing a medical career. It depends on expected income, duration of training, working conditions, professional autonomy, prestige, legal liability, emotional burden, career advancement opportunities, geographic mobility, residency conditions, and alternative careers.

8. The Price of Alternatives

For a young person, medicine does not compete with "nothing." It competes with IT, engineering, finance, entrepreneurship, management, applied science, and other high‑skilled professions.

Therefore, it is necessary to account for the opportunity cost of choosing medicine (\(OC\)): alternative income + flexibility + mobility + speed to income + career opportunities.

Even a high absolute physician salary may be insufficient if the relative attractiveness of alternatives is growing faster.

9. Working Conditions

The attractiveness of the profession is determined not only by income. Simplistically:

What is particularly important is that some parameters affect multiple stages simultaneously: working conditions → admission → residency → entry into the profession → retention.

Therefore, improving working conditions may have a greater systemic effect than simply increasing the number of budget‑funded places.

10. Medical Demand

It is also necessary to model the other side of the system:

where Population — population size; AgeIntensity — intensity of medical care depending on age; Morbidity — disease structure; MedicalIntensity — intensity of medical technology use.

Therefore, a decline in population does not necessarily mean a decline in demand for medical care. Population aging may compensate for or exceed the effect of population decline.

11. Technology as a Multiplier of Workforce Capacity

In the model, technology should not be viewed solely as a way to "replace a physician." It is more useful to view it as a multiplier \(EC_t = D_t \times A_t \times P_t\), where \(P_t\) can increase through documentation automation, AI, clinical decision support systems, telemedicine, automation of routine operations, improved information exchange, task redistribution, and digital memory of the medical organization.

11.5. Quality as a Multiplier

Increasing the number of physicians does not automatically preserve or improve quality. If numerical growth is achieved by lowering admission standards, reducing clinical training, or overburdening mentors, the effective capacity may actually decline.

Therefore, we introduce a quality coefficient \(Q_t\) — the fraction of physicians who meet clinical competency standards.

\(Q_t\) can be estimated via certification results, peer reviews, or patient outcomes. It ensures that policy makers do not equate "more doctors" with "better care."

12. Digital Memory as an Element of Workforce Sustainability

If a specialist's practical experience is preserved only in their memory, then the specialist's departure leads to a loss of experience. If the experience is structured and accessible to the next generation, the specialist's departure leads to partial transfer of experience.

Therefore: \(\text{KnowledgeRetention} \rightarrow \text{Productivity} \rightarrow \text{EffectiveCapacity}\).

At the same time, digital memory should not replace the physician, clinical guidelines, evidence‑based medicine, or medical responsibility. Documented practice must be distinguished from proven causal effect.

13. Controllable Parameters of the Model

The main practical purpose of the model is not forecasting for its own sake. It should answer the question: which parameter must be changed to obtain a specific result?

Key levers:

Note that \(Q\) is now an explicit lever, reinforcing that quality is not automatic.

14. How the Model Can Be Used for Management

This is a fundamental part of the model. The goal is to turn analysis into a decision‑making tool of the form: goal → parameter → magnitude of change → delay → expected effect → side effects.

14.1. Goal 1. Rapidly Increase Available Medical Capacity

The fastest levers: \(A\uparrow\) and \(P\uparrow\). That is, reducing bureaucracy, automating documentation, redistributing tasks, improving scheduling, eliminating downtime, digital tools.

Advantage: results can appear significantly sooner than a new physician completes training.

14.2. Goal 2. Reduce Future Workforce Shortages

The main lever is \(N\uparrow\). But \(N\) can be increased in several ways:

• Option A: increase the number of students → effect through the duration of the educational cycle;
• Option B: increase the proportion of graduates who continue training (\(O\uparrow\));
• Option C: increase the proportion of graduates who remain in the profession (\(Retention\uparrow\)).

In most cases, B and C may be cheaper than endlessly increasing the input flow.

14.3. Goal 3. Stop Generational Decline

The main indicator: \(RR = \text{New Physicians} / \text{Departing Physicians}\). To achieve \(RR \ge 1\), both sides can be influenced.

Increase the numerator:

• increase input;
• improve residency;
• improve working conditions;
• increase retention of young specialists;
• attract immigration.

Decrease the denominator:

• make continued work by senior physicians more attractive;
• reduce administrative burden;
• create part‑time employment;
• use the experience of senior physicians as a mentoring resource.

This is far more rational than trying to solve everything solely by increasing enrollment.

14.4. Goal 4. Reduce Regional Shortages

Here, changing the national \(D\) may achieve almost nothing. It is necessary to influence \(RR\) by region and specialty.

Main levers: regional salary, housing, career trajectory, educational infrastructure, possibility of returning to a major center after mandatory service, remote support, access to expert experience from leading centers.

If a physician is in a region but gains access to institutional experience from a leading center, the effective capacity of the regional system can grow without the physical relocation of the physician.

14.5. Goal 5. Maintain Quality as the Physician Corps Ages

Main parameter: \(K = \text{KnowledgeRetention}\). It can be enhanced through mentoring, structured experience transfer, digital memory, case‑based learning, documentation of complex cases, connecting leading centers with peripheral institutions.

Additionally, \(Q\) must be monitored — older physicians may have deep experience but also may face cognitive decline or outdated practices. The model should allow for differential \(Q\) by age group.

14.6. Goal 6. Increase Effective Capacity Without Proportional Growth in Numbers

This is the most technological path: \(P\uparrow\). If the number of physicians is unchanged (\(D = const\)), but \(A\uparrow\) or \(P\uparrow\), then \(EC\uparrow\).

This is precisely why automation, AI, and work organization improvements should be viewed not as a separate digital program, but as part of workforce policy.

15. Model Sensitivity and a Realistic Example

For a first approximation, it is convenient to use relative changes. If \(EC = D \times A \times P \times Q\), then for small changes:

This means that a 10% increase in effective capacity can be achieved through various combinations of smaller improvements.

Illustrative Example Based on Real Data

We use data from a photo‑timing study of abdominal surgeons at City Clinical Hospital No. 6 in Penza (RMANPO, 2024–2026). The study measured actual working time allocation.

• Direct patient care (clinical work): 62.3% for daytime surgeons, 67.8% for on‑call surgeons.
• Documentation and administrative tasks: ~9–12%.
• Auxiliary processes (transfers, waiting): ~18–20%.

For our example, we take a conservative \(A = 0.62\) (62% of working time spent on direct clinical activity). This is a midpoint between daytime and on‑call values. Note that this value applies to this specific group; for other specialties or regions, \(A\) may differ significantly (e.g., primary care physicians may have lower \(A\) due to higher documentation burden).

Assume a department with \(D = 100\) surgeons, \(P = 1.0\) (baseline productivity), and \(Q = 1.0\) (all meet quality standards).

Current effective capacity: \[ EC = 100 \times 0.62 \times 1.0 \times 1.0 = 62 \]

To increase \(EC\) by 10% (to 68.2), we compare three strategies:

All three yield the same gain, but the time horizons are drastically different. A combined approach (\(D+3.3\%,\ A+3.3\%,\ P+3.3\%\)) also gives ~10.2% gain (\(1.033^3 \approx 1.102\)) with moderate efforts on each front.

Important caveat: The \(A=0.62\) value is specific to the studied surgeons. In regions with higher administrative burden (as reported by the Audit Chamber, up to 50% of working time lost to non‑clinical tasks), \(A\) could be as low as 0.50. Therefore, the model must be calibrated locally.

Also, the study did not capture 36‑hour on‑call shifts (which exist in practice but were not measured). Such extended shifts may reduce effective \(A\) due to fatigue, but they are not reflected in the data. This underlines the need for further empirical work.

16. Why This Changes the Policy Approach

Suppose it is necessary to increase effective capacity by 15%. There are four fundamentally different strategies.

Strategy 1 — education only: \(D +15\%\). Results appear in years.

Strategy 2 — productivity only: \(P +15\%\). Results may appear significantly faster.

Strategy 3 — work organization: \(A +15\%\). Part of the effect may be achieved even faster.

Strategy 4 — combined: \(D +5\%,\ A +5\%,\ P +5\%\).

In first approximation: \(1.05 \times 1.05 \times 1.05 \approx 1.158\) — that is, about 15.8% additional effective capacity.

This is not a forecast of a specific medical effect. It is a demonstration of the model's principle: several moderate changes can yield greater results than attempting to radically change a single parameter.

17. The Most Important Constraint: Delay

Parameters have different speeds of impact.

Fast:

• work organization;
• reduction of administrative burden;
• automation;
• FTE changes;
• part of immigration decisions.

Medium:

• physician retention;
• workload redistribution;
• mentoring;
• digital memory.

Slow:

• change in professional attractiveness;
• change in educational flow;
• training of new specialists;
• demographic structure.

Therefore, a rational strategy must use a portfolio of levers with different time horizons.

17.5. Sustainability Buffer

A simple but powerful derived indicator is the buffer \(B_t\):

where \(D_{min}\) is the minimum number of physicians required to provide essential care (estimated from demand models).

• \(B < 0.1\) — the system is in the danger zone;
• \(B < 0\) — critical deficit.

This helps distinguish between "shortage" and "crisis" and provides an early warning signal that is easy to communicate.

18. Scenarios 2026–2045

The scenarios presented are purely illustrative and serve to demonstrate the system's sensitivity to parameter changes. They are not forecasts and do not claim quantitative accuracy.

Scenario A — Demographic Stress. Assumes a decline in the number of young cohorts, high physician workload, continued retirement of older generations, weak improvement in conditions, low productivity growth. Result: \(RR < 1\) over a prolonged interval. The system enters self‑sustaining deficit.

Scenario B — Inertial. Gradual increase in training, moderate salary increases, moderate digitalization, maintaining the current system structure. Result: shortage does not necessarily become catastrophic, but remains chronic. This is the most dangerous scenario due to its external appearance of stability.

Scenario C — Improved Attractiveness. Changes: income↑, autonomy↑, conditions↑, administrative burden↓, career flexibility↑. Result appears with delay, since first the young person's choice changes, then education, then residency, then entry into the profession.

Scenario D — Productivity First. Physician numbers grow moderately. But \(P\uparrow\) through automation, AI, clinical information systems, task redistribution, digital memory, process improvement. This scenario allows partial compensation of demographic pressure without proportional growth in physician numbers.

Scenario E — Systemic Transformation. Simultaneously \(N\uparrow,\ Retention\uparrow,\ A\uparrow,\ P\uparrow,\ KnowledgeRetention\uparrow\), and targeted management of Region × Specialty × Age. This is the most sustainable scenario.

19. What the Model Should Actually Show Decision‑Makers

The output should answer not "In 2045 there will be 720 thousand physicians," but:

• What medical capacity is needed?
• What capacity will we obtain under current policy?
• Where does the gap arise?
• Which parameter is the main constraint?
• What happens if we change only this parameter?
• In how many years will the effect appear?
• What is the cost of changing the parameter?
• What risks arise when changing it?

This transforms the model from an analytical report into a decision‑making tool.

20. Recommended Early Warning Indicators

It is proposed to regularly track:

• Reproduction rate \(RR = \text{New Physicians} / \text{Departing Physicians}\);
• Transition rate from graduates to practice \(TCR\);
• Retention rate \(R_5\);
• Age risk — proportion of physicians above a given threshold;
• Clinical employment share \(A = \text{Clinical time} / \text{Total working time}\);
• Productivity \(P\);
• Quality coefficient \(Q\);
• Buffer \(B\);
• Knowledge loss index — proportion of critical competencies associated with physicians approaching retirement;
• Regional \(RR\) for each region‑specialty combination.

21. What Decisions the Model Allows Comparison Of

The model should allow questions such as:

• What gives more effect: +10% budget‑funded places or reducing administrative burden by 10%?
• What is more effective: increasing salary or increasing professional longevity?
• What effect will automating 20% of administrative work have?
• How many additional physicians can we avoid training if productivity grows by 5%?
• Which specialties require enrollment increases, and which primarily require condition improvements?
• What happens if the retirement of the older generation accelerates by five years?
• How will the system change if retention of young physicians increases by 10 percentage points?

These are precisely the questions that have direct value for state policy.

22. Model Limitations

22.1. "All Models Are Wrong, but Some Are Useful"

Any model is a simplification of reality. Therefore, "All models are wrong, but some are useful" is not a decorative caveat, but a principle for interpreting this document.

MWCM should not be used as a machine that produces the "true number of physicians for 2045." Its purpose is different:

• identify dependencies;
• compare scenarios;
• detect sensitive parameters;
• identify early signals;
• assess delays;
• test the robustness of decisions.

If data or assumptions change, the model results should change with them.

22.2. Data Limitations

A full‑fledged model requires data not presented in this conceptual document in a unified form: physician age, specialty, region, actual FTE, departure from the profession, transition between public and private sectors, graduate and resident trajectories, actual workload, productivity, medical demand by age groups.

Therefore, numerical scenarios should be viewed as sensitivity scenarios, not as an official demographic forecast.

22.3. Causality Limitation

Correlation does not imply causation. For example, salary growth does not guarantee increased enrollment because working conditions, prestige, alternative professions, educational requirements, and regional mobility may change simultaneously. Therefore, model parameters must be empirically validated.

22.4. Generality of the Example

The illustrative example in Section 15 is based on a specific study of abdominal surgeons in Penza. It should not be extrapolated to other specialties or regions without local calibration. The model is designed to be adaptable, but the numbers are not universal.

23. Author's Limitations

The author is not a physician, health economist, or specialist in Russian healthcare organization. Therefore, this document is not an expert medical opinion.

Nevertheless, the author has experience directly useful for framing the proposed task.

Author's Strengths

The author has worked for over 15 years as an independent software engineer, involved in software systems development, system architecture, R&D, complex system modeling, information security, analytical systems construction, information systems integration, knowledge management, AI application and automation, and research on the relationship between technology and productivity.

The author's previous work "How many software engineers the economy could support?" addressed a similar framing: not simply estimating the number of specialists, but modeling the economic capacity of a system to support a certain number of high‑skilled workers, accounting for productivity, feedback, implementation time, and other parameters.

That work also uses the principle that changing one system parameter can substantially change its steady state. This approach is transferred to the present model.

Missing Experience

The author lacks practical experience as a physician, clinical practice, healthcare facility management experience, access to restricted healthcare workforce statistics, or full‑scale expertise in health economics.

Therefore, medical specialists, demographers, health economists, and representatives of regional healthcare systems should be considered mandatory participants in the next stage of model development.

The strength of the present work is the systemic problem framing and model architecture, not a claim that the author possesses medical expertise.

24. Related Research by the Author

Below are publications directly related to the methodology and problem framing of the present model.

1. How many software engineers the economy could support?
October 2025. This work is the direct methodological predecessor of the present model. It examines base economic capacity, supporting population, productivity, feedback, implementation time, success of product creation, exports, automation, and the possibility of expanding the natural limit of the system through productivity growth.

Link: https://gelassen.github.io/2025/10/09/how-many-sofware-engineers-the-economy-could-support.html

2. Bridging gaps in economy, politics, diplomacy and warfare: review and next steps, Part II
February 2026. This work describes the development of the author's systems approach to complex system analysis: network dependencies, multi‑level causal relationships, scenario thinking, and working with uncertainty. These methods are used in the present document when constructing the medical workforce reproduction model.

Link: https://gelassen.github.io/2026/02/03/bridging-gaps-in-economy-politics-diplomacy-warfare-review-part-II.html

3. Digital Memory of Medical Institutions: Turning Clinical Experience into a System Asset
August 2026. This work examines the creation of digital memory of medical institutions as an infrastructure layer that transforms accumulated clinical practice into structured and traceable institutional knowledge. In the context of the workforce model, this can be viewed as one mechanism: KnowledgeRetention → Productivity → EffectiveCapacity.

Link: https://gelassen.github.io/2026/08/18/digital-memory-of-medical-institutions.html

This set of publications demonstrates a consistent methodological line: from modeling the capacity of a system for high‑skilled human capital — through systems and scenario analysis — to applying these methods directly to healthcare and preservation of medical experience.

It is important to emphasize: medical expertise should come from the Ministry of Health, physicians, demographers, and health economists. The author's competence is system architecture, modeling, technology, and complex system analysis.

25. Proposed Pilot

To transform the concept into a working tool, it is proposed to begin not by building a massive state information system, but with an analytical pilot.

The pilot should include:

• 3–5 regions with different demographic situations;
• 5–10 specialties;
• several large medical organizations;
• medical universities;
• residency programs;
• data on physician age structure.

It is desirable to reconstruct dynamics for at least 2015–2026 and build scenarios for 2026–2045.

26. What the First Prototype Should Deliver

The first prototype should answer at least five questions:

• Where does \(RR < 1\) already exist?
• Which specialties are most sensitive to the departure of the older generation?
• Which regions will be unable to reproduce their own workforce stock?
• Which parameter has the greatest impact on effective capacity?
• Which measures yield results most quickly?

Concrete pilot question

"In Sverdlovsk Oblast, for the surgery specialty, 40% of surgeons are older than 55, and residency enrollment is only 60% of the target. What is the effect of increasing retention of young surgeons by 10 percentage points compared to increasing enrollment by 20%?"

The model should be able to simulate both scenarios and compare them in terms of time, cost, and impact on \(RR\) and \(EC\).

The pilot is considered successful if it allows ranking 3–5 specific measures by the ratio of "effect / lag / cost" for selected specialties and regions.

27. Desired Outcome

The final result should not be a single number. What is needed is a map of workforce sustainability: Region × Specialty × Generation × Scenario.

Such a format is far more useful than a single indicator like "Russia is short by N physicians."

28. Main Conclusion

The Russian healthcare workforce problem should be viewed not as a task to "train more physicians."

A more precise formulation is: "ensure the reproduction of sufficient effective medical capacity amidst demographic changes in the population and physician generations."

To achieve this, it is necessary to simultaneously manage: quantity + age + specialty + geography + retention + conditions + productivity + technology + quality + knowledge.

29. Strategic Principle

If a shortage arises today, a solution through increasing student numbers may come too late.

If the older generation is retiring today, training a new specialist will not compensate for it immediately.

If a physician spends a significant portion of working time not on clinical activity, increasing headcount may be less effective than eliminating organizational losses.

If unique experience disappears with the physician, a new diploma alone is insufficient to fully replace the lost capability of the system.

Therefore, workforce policy must simultaneously operate on three horizons:

• Today: \(A\uparrow,\ P\uparrow\) — increase the effective capacity of the existing corps.
• 3–7 years: \(Retention\uparrow,\ KnowledgeRetention\uparrow,\ Q\uparrow\) — preserve people, quality, and experience.
• 7–15+ years: \(N\uparrow,\ RR \ge 1\) — ensure generational reproduction.

30. Conclusion

The most dangerous mistake would be to wait until statistics show an obvious nationwide physician shortage. By that time, a significant part of the process will already be irreversible: the younger generation will have chosen other professions, the age structure of the physician corps will have shifted, specialists will have retired, and the educational cycle will no longer allow rapid replenishment of the deficit.

Therefore, a transition from reactive workforce policy to an early warning system is necessary.

The proposed model does not claim to be able to precisely predict the state of Russian healthcare in 2045. It proposes something else: to make visible the parameters on which that future depends.

If the model shows that to achieve a specific goal it is sufficient to change a certain parameter by a certain magnitude, this creates a foundation for rational choice between alternative state measures.

This is precisely why the ultimate goal should not be maximizing the number of physicians.

Goal: maximize sustainable effective medical capacity

while maintaining quality of care, patient safety, professional responsibility of physicians, accessibility of care, institutional memory, and the system's ability to reproduce itself across generations.

It is proposed to consider the Medical Workforce Capacity Model as a conceptual foundation for further joint research with medical specialists, demographers, health economists, educational organizations, and regional healthcare authorities.

Executive Summary

Most discussions about Artificial Intelligence in manufacturing start with technology: large language models, computer vision, predictive analytics, or digital twins. The usual sequence is familiar — first choose a technology, then look for problems it might solve.

This analysis takes the opposite approach.

It starts with real production problems observed across Russian and international manufacturing enterprises. Only after identifying the most persistent and costly problems does it examine where digital tools and AI can actually help.

The central finding is straightforward:

The majority of recurring operational problems in manufacturing are not caused by the absence of modern AI models. They are caused by the absence of an effective system for capturing, storing, searching, and reusing production knowledge — what can be called the digital memory of the enterprise.

The working hypothesis is therefore:

The primary constraint on effective AI adoption in industry today is not the maturity of the models themselves, but the lack of high-quality, structured, and accumulated production knowledge. AI can significantly improve operational efficiency only when it has something real to work with.

Recommended sequence:

• Build a unified digital knowledge base (the enterprise’s digital memory).
• Establish reliable data accumulation and documentation practices.
• Deploy intelligent services on top of that foundation (semantic search, recurring failure analysis, recommendations, automated documentation, prediction).

This post is a preliminary analysis based on open sources. The hypothesis requires field verification through interviews on actual production sites.

A whole document is available by link

Why a Roadmap for AI Cannot Start with Technology

A serious roadmap for AI in manufacturing should not begin with model selection, platforms, or infrastructure.

It should begin with a more fundamental question:

Which production problems actually need to be solved?

Skipping this step produces collections of fashionable digital initiatives that have little measurable impact on productivity.

The principle used here is simple:

First — real production problems. Then — analysis of their causes. Then — evaluation of existing digital tools. Only then — the role of Artificial Intelligence.

This is the approach used by leading industrial research centres and is the only reliable way to avoid technology for technology’s sake.

Methodology

Sources and priorities

The analysis prioritised materials closest to primary sources:

The review covered Russian enterprises as well as material from Germany, the United States, Japan, China, Fraunhofer studies, ethnographic research of production processes, and maintenance organisation literature.

The goal was not statistical representativeness, but identification of patterns that appear independently of country, industry, and level of digitalisation.

Use of AI tools

Modern AI tools were used for search, aggregation, structuring, and preliminary analysis of open sources. This expanded the volume of material examined and accelerated pattern detection.

At the same time, the limitations are clear: possible incomplete sampling, interpretation errors, data quality issues, and publication bias. All conclusions remain preliminary working hypotheses that require verification through direct interviews on industrial sites.

Research limitations

A full AI roadmap cannot be built from internet sources alone. Field research is required.

A minimally representative sample would include at least ten enterprises from one industry, with interviews across the full range of roles: machine operators, maintenance engineers, repair teams, shift supervisors, process engineers, quality specialists, IT staff, production managers, and plant leadership.

Only such a sample can reliably identify systemic problems, quantify economic impact, and determine which digitalisation directions deliver the highest return.

Map of Recurring Production Problems

Despite large differences in countries, automation levels, and IT landscapes, the most frequently reported problems show a striking degree of consistency. Most of them have little to do with the absence of AI.

Workforce-related

• Loss of production knowledge when experienced employees leave or retire
• Shortage of qualified specialists
• Long onboarding time for new engineers
• Dependence on a small number of key experts

Information-related

• Time spent searching for information before equipment repair
• Missing or incomplete repair history
• Absence of a unified knowledge base
• Knowledge scattered across paper journals, Excel files, email, shared folders, and individual memory
• Difficulty finding similar past cases
• Outdated or incomplete technical documentation

Organisational

• Information transfer between shifts
• Heavy manual documentation burden
• Loss of information in handovers
• Duplication of records

Operational

• Long fault diagnosis times
• Repetition of previously known errors
• Insufficient time for preventive maintenance
• Extended equipment downtime

Causal model

Experienced specialists leave
            ↓
Loss of production knowledge
            ↓
Absence of a unified digital memory
            ↓
Long information search  ·  Repeated errors  ·  Slow onboarding
            ↓
Lost time and money

Virtually all of the most common problems are downstream effects of one root cause: the lack of an effective system for accumulating and using production knowledge.

Why This Matters Now

Knowledge management problems have existed for decades. Several converging factors make them critical today.

Aging engineering workforce

A significant share of the most experienced specialists is approaching retirement. Simultaneously, enterprises face a shortage of younger engineers. When 20–25 % of the workforce over 55 leaves, undocumented knowledge leaves with them.

Increasing equipment complexity

Modern machines require deeper and more specialised knowledge for operation and maintenance.

Accumulation of digital data

Enterprises already hold large volumes of electronic documentation, repair logs, photos, and other records. Most of this material remains fragmented and underused.

Maturity of language models

For the first time, modern language models can work effectively with large volumes of internal enterprise documentation in natural language — provided that knowledge has first been captured and structured.

Proposed Direction: Digital Memory of the Enterprise

The working hypothesis follows directly from the problem map:

The main constraint on AI adoption in industry is not the insufficient maturity of AI models, but the shortage of high-quality, structured, and accumulated production knowledge.

If confirmed by field research, the first stage of digital transformation should be the creation of a unified digital memory of the enterprise.

Such a system should bring together:

• technical documentation
• repair history
• photos and video
• diagnostic results
• work instructions
• engineer recommendations
• shift logs
• accumulated practical operating experience

Once this foundation exists, AI becomes a natural next step rather than an isolated project. Typical uses include:

• intelligent (semantic) search
• analysis of recurring failures
• detection of operating patterns
• recommendations for engineers
• support for new employees (onboarding)
• automated documentation
• analysis of accumulated statistics
• prediction of potential equipment failures

In short, AI starts working on the enterprise’s own experience instead of generic internet knowledge.

Recommended sequence

Stage 1 — Unified production knowledge base
Object-oriented digital card for every equipment unit. Integration with existing ERP, MES, CMMS, and file stores (a layer on top of current systems, not a replacement).

Stage 2 — Reliable data accumulation and documentation culture
Simplified input (mobile, voice, photo), incentives for staff, data quality control, versioning.

Stage 3 — Intelligent services
Semantic search with source citations, recurring failure analysis, recommendations, automated documentation, prediction.

Organisational conditions for success

Technology alone is insufficient. Critical conditions include:

• dedicated time and incentives for documentation (otherwise data entry remains formal)
• interfaces designed for shop-floor reality (mobile devices, gloves, noise)
• data quality control
• integration with the existing system landscape rather than creation of another silo
• ability to operate in a closed contour (on-prem / private cloud), compliance with critical information infrastructure requirements, and use of domestic language models or the ability to fine-tune them

Practical Example: Manufacturing Knowledge Management System (MKMS)

One possible implementation of the approach described above is the Manufacturing Knowledge Management System (MKMS).

MKMS is positioned as the first infrastructural layer of digital transformation, not as a complete AI solution. Its primary purpose is to form the digital memory of the enterprise by giving every equipment unit its own digital card that consolidates documentation, repair history, media, and engineer comments.

This creates the foundation on which intelligent search, analysis, and decision-support services can later be built.

• Case Study
• Project documentation
• Source code

What digital memory does not solve

Creating a digital memory of the enterprise does not eliminate:

• physical wear of equipment
• lack of investment
• design errors
• capacity shortages
• the need for genuine engineering expertise

It does, however, substantially reduce the time and knowledge losses that occur at almost every stage of the equipment life cycle, and it creates the necessary conditions for effective subsequent use of AI.

Next Step: Field Verification

The logical next stage is verification of the working hypothesis on a representative sample of industrial enterprises (for example, in Moscow) through structured interviews conducted directly on production sites.

Objectives:

• confirm or adjust the problem map and priorities
• assess current maturity of production knowledge management
• collect quantitative data (search time, share of documented repairs, onboarding cost)
• formulate a grounded AI roadmap based on real needs rather than technology expectations

A minimum sample of 8–12 enterprises from one or two priority industries, with interviews covering the full range of roles listed earlier, would provide a solid empirical base.

Conclusion

Discussion of Artificial Intelligence in manufacturing should not begin with models, platforms, or computing infrastructure.

The primary task is to create the conditions under which enterprise knowledge becomes accessible, accumulated, structured, and suitable for analysis.

Production knowledge should be treated as a strategic asset of the enterprise — alongside equipment, technology, people, and intellectual property.

Artificial Intelligence does not create this asset. It only makes it possible to use the knowledge the enterprise has already accumulated (or managed to preserve) far more effectively.

The next step is field verification of this hypothesis. Only after such verification will it be possible to construct a justified AI roadmap grounded in the real needs of modern manufacturing rather than in technological expectations.

Building the digital memory of the enterprise is therefore a necessary preparatory stage for any serious application of AI in industry.

Related Publications

Executive summary

This project demonstrates the development of a lightweight Business Intelligence system for a university Learning Management System (LMS), designed to help instructors identify learning patterns, detect at-risk students, and reduce the time required to review student performance.

The primary objective is to decrease manual analysis of a student group from approximately 40 minutes to 5–10 minutes by providing explainable analytics instead of relying on black-box AI models. Because the customer prohibits the use of Large Language Models (LLMs) for educational decision-making, the solution follows Explainable AI (xAI) principles, where every recommendation is accompanied by evidence, alternative interpretations, confidence levels, and known limitations.

The project was implemented under several practical constraints, including limited development time, restricted access to the production LMS, and strict personal data protection requirements. To overcome these limitations, a synthetic data generator was developed to reproduce the structure and statistical characteristics of the real LMS database while avoiding the use of sensitive student information.

The resulting system consists of four major components:

• a synthetic LMS data generator for development and testing;
• an incremental analytics engine that processes only changed data instead of recomputing the entire dataset;
• an explainable rule-based analytics pipeline that transforms raw LMS events into actionable educational insights;
• an interactive Streamlit dashboard for visual exploration of student performance, engagement, risks, and recommendations.

Unlike traditional BI dashboards that primarily display aggregated metrics, the system focuses on decision support. It combines quantitative indicators with structured explanations, helping instructors understand not only what happened, but also why, how confident the system is, and which interventions should be considered.

The current prototype processes synthetic datasets representing a single faculty for period of one year and was designed with asynchronous architecture and incremental data processing for future scaling.

Although the current implementation covers only part of the requested functionality, it establishes a modular architecture that can be extended with additional analytical models, visualization capabilities, and educational recommendations without fundamental redesign. The fundamental objective is to support user in his\her decision making.

About the customer

My current customer is a group of university professors and lectors whose initiative is to apply the power of AI to simplify their work.

The idea is to help them to analyze the data from their LMS - reduce time on group's work review from 40 minutes to 5 - 10 minutes.

Currently, the customer uses LMS system to manage the students' work and grades. The LMS provides dashboards with basic analytical data. Review of such work takes time and could potentially reduced by applying AI and BI tools.

LLM usage is prohibited there, the results should be explainable, therefore principles of xAI should be used here.

System should be able to:

• visualize of the distribution of responses by chapters, topics and questions
• identifies topics with low (<50%) and high (>80%) performance
• classifies error types
• generates natural language output with specific recommendations
• show total scores and trends
• show completion time, attempts, deadlines
• show task difficulty thresholds
• show attendance and activity
• comparison of different metrics (performance ↔ time ↔ attempts)
• identification of tasks that no one has solved/that everyone has solved
• generating recommendations (simplify/complicate)
• automatic report on at-risk students
• personalized recommendations on topics and tasks
• a summary report on the risk group with rationale
• recommendations for interventions (what to repeat, who to focus on)

Discovery

Despite on new business domain and technology discovery phase has been concisely skipped or better to say scattered among the whole project.

Limited budget and tight schedule push me and customer to agreed on R&D form ow work when results are not strictly aligned to time constraints in the favor of maximum project's velocity.

Ethical constraints and system limitations

As the engineer designing this system, I have to assume that users will rely on its outputs when making real-world decisions. In practice, this means they delegate part of their cognitive work to the system. If the analytical process is flawed or the conclusions are misleading, the resulting harm extends far beyond a single incorrect prediction.

There is currently no algorithm capable of modelling the full complexity of the real world. Every analytical model is necessarily incomplete and operates under assumptions and uncertainty. Consequently, fully autonomous machine analytics cannot be considered universally correct by design. An important responsibility of the system is therefore to make its own limitations visible rather than creating an illusion of certainty.

Based on these principles, the reporting model was designed together with a Large Language Model (LLM) to support human reasoning rather than replace it. The objective is not to generate authoritative answers but to provide transparent, evidence-based analytical assistance. This design philosophy is consistent with the direction taken by several state-of-the-art analytical platforms while introducing explicit mechanisms for uncertainty and alternative explanations.

The proposed architecture intentionally follows an evidence-first approach instead of a traditional LLM-first workflow. Rather than allowing the language model to generate conclusions directly from raw data, the system first derives measurable indicators, produces findings supported by evidence, estimates confidence, records alternative explanations, and only then formulates recommendations. This preserves transparency, improves auditability, and ensures that responsibility for the final decision always remains with the human expert.

Solution

Existing LMS data model

Before to start the development of the BI system, I have to understand the existing LMS data model.

Time budget for this project is quite limited and I have been using LLM to speed up my work here. It is quite risky, because instead of working directly with LMS I use a mediator which almost always lead to distortion of information. Moreover LLMs are known for making mistakes, therefore such mistakes *might* go into the system.

Limited time and restrict direct access to organization's LMS system makes LLMs usage here as a reasonable choice.

Actual data under GDRP like policy

Russia has its own analog of GDRP like policy to secure personal data of its citizens. Right on the private life and privacy of the personal information is a fundamental constitutional right. Violation of this is strictly prohibited.

The form of my current contract allows to send me this data, but personal circumstances will result to the actual data breach without any malicious intentions from my side. In such situation, I usually inform my customer about this risks by email before to go forward.

This issue and general bureaucracy of the current organization makes me use a workaround with synthetic data model to simulate the actual data.

Synthetic data model as a workaround

To address data protection constraints and enable rapid development, I implemented a synthetic data generator that mimics the structure and statistical properties of real LMS data.

Generator architecture:

• Built with Python using Pandas, NumPy, and Pydantic for data validation
• Configurable random seed (42) ensures reproducible results
• Generates 9 interconnected tables matching the LMS data model

Student profiles:

Five student categories with distinct academic characteristics:

• Excellent (15%): mean 97, σ=2.0 — minimal attempts, near-perfect scores
• Strong (25%): mean 86, σ=5.0 — rare 2nd attempts
• Average (35%): mean 68, σ=9.5 — 1-3 attempts
• Weak (15%): mean 48, σ=11.5 — up to 4 attempts
• Risk (10%): mean 28, σ=13.5 — low engagement, high variance

Data generation logic:

• 12 topics in Economics with difficulty coefficients (0.10-0.87) and target means (37-94)
• 24 assignments (2 per topic) with realistic due dates
• 100 students with ID format ST0001-ST0100
• Attempts: scores depend on profile, topic difficulty, and attempt number
• 10 questions per attempt with error type classification (logical, terminology, arithmetic)
• Attendance rates: 38-97% based on student profile
• Weekly activity metrics: forum posts, resource views, quiz launches

Anomaly injection:

To test outlier detection algorithms, the generator applies deliberate anomalies:

• Easy assignments → inflated scores (98/100)
• Hard assignments → deflated scores (5/100)
• Specific students: weak student scoring high on easy tasks, top student scoring low on hard tasks
• Question-level patterns: all correct for easy assignments, all incorrect for hard assignments

Output format:

9 CSV files fully compatible with the target BI dashboard, enabling immediate testing of all analytical features without exposing real student data.

Visualization layer

The BI system uses Streamlit as the visualization framework, providing an interactive dashboard for exploring student performance data. The visualization layer is organized into several functional tabs, each serving a specific analytical purpose.

Streamlit is chosen for its rapid development capabilities. Until this moment it has been sufficient, but further complexity of BI insights will initiate migration for more rich solutions like Tableau or others.

Technology stack:

• Streamlit — rapid UI development without frontend complexity
• Plotly — interactive charts with zoom, hover, and selection capabilities
• Pandas — data manipulation and aggregation
• Async SQLAlchemy — asynchronous database access for performance

Dashboard structure:

1. Sidebar (Global Filters)

• Group filter — select one or multiple student groups
• Student filter — individual student analysis or "All students" mode
• Assignment type filter — filter by homework, quiz, or exam types
• Date range picker — time period selection with min/max boundaries
• Quick metrics — total questions, correct answers, average success rate

2. Themes Tab

• Theme performance chart — bar chart showing average scores by topic with color gradient (red-yellow-green)
• Error distribution chart — error rates per topic with red gradient for problem areas
• Detailed table — sortable data frame with avg_score, total_questions, correct_count, correct_rate, and error_rate

3. Student Profile Tab

• Profile badge — displays student's academic category (excellent/strong/average/weak/risk)
• Performance heatmap — topic-by-topic success visualization with color coding
• Interactive bar chart — student's best performance per topic with color mapping

4. Questions Tab

• Topic selector — dropdown to choose specific topic for drill-down
• Question accuracy chart — percentage of correct answers per question (Q01-Q10)
• Smart filtering — prompts to select individual student when dataset exceeds 500 rows for performance

5. Insights Tab

• Intelligent report generation — structured findings organized by topic
• Metrics table — accuracy, difficulty, total questions, completion rate, error breakdown by type (logical, arithmetic, terminology)
• Finding cards — each finding includes:
• Hypothesis — explanatory statement about observed pattern
• Observation — formatted evidence with pattern detection (low/high accuracy)
• Evidence list — supporting metrics with automatic percentage formatting
• Alternatives — alternative explanations for the finding
• Recommendations — actionable suggestions for instructors
• Limitations — interpretation boundaries and confidence constraints

Data flow:

1. Repository layer — async queries to PostgreSQL via SQLAlchemy
2. Dataset builder — merges 5+ tables (students, topics, assignments, attempts, question_results) into a single denormalized DataFrame
3. Filter service — applies sidebar filters to the dataset
4. Analytics service — computes aggregations (theme_stats, question_stats, student_heatmap)
5. Chart service — generates Plotly figures with consistent styling
6. UI Presenter — formats evidence text, translates metrics to Russian, handles null values gracefully

Key design decisions:

• Separation of concerns — services handle business logic, presenters manage UI formatting
• Async architecture — non-blocking database calls for responsive UI
• Type safety — dataclasses and DTOs enforce contract between layers
• Graceful degradation — user-friendly messages when data is missing or filters yield empty results
• Russian localization — all UI labels, metrics, and findings are localized for the target audience

Performance optimizations:

• @st.cache_data — caches the base dataset to avoid repeated database queries
• Smart filtering — prompts student selection when data volume exceeds 500 rows
• Aggregated computations — pre-computed metrics in analytics database for fast retrieval

BI analytics

The analytics engine is an asynchronous Python application that processes LMS data through a pipeline architecture, transforming raw question results into actionable insights with explainable AI principles.

Core components:

1. Data Ingestion Layer

• Database Repository — async SQLAlchemy queries for topics, assignments, question results, and activity data
• Changes Repository — tracks unprocessed entity changes (topics, assignments, question results, students, activity) for incremental processing
• Pipeline Lock Repository — ensures only one pipeline instance runs at a time using PostgreSQL advisory locks

2. State Builder

• Hydration Repository — resolves topic IDs from changed entities (e.g., maps question_results → assignments → topics)
• Analytics State Builder — assembles a complete AnalyticsState object containing all data needed for a batch (topics, assignments, question results, activity)

3. Processing Pipeline

• Metrics Engine — computes 11 metrics per topic: accuracy, error distribution (logical/arithmetic/terminology), average score, completion rate, difficulty, pressure, and engagement
• Rule Engine — evaluates 7 rules (LowAccuracy, LogicalError, ArithmeticError, TerminologyError, HighPressure, EngagementMismatch, StableHighPerformance) against each topic's metrics
• Explanation Engine — generates human-readable reports with hypotheses, severity levels, confidence scores, alternative explanations, and recommended actions

4. Persistence Layer

• Saves all results atomically in a single transaction: metrics → findings → evidence → explanations → alternative explanations → recommended actions → uncertainty notes → limitations → missing context
• Creates an AnalyticsRun record to track each execution
• Marks processed changes as acknowledged

Execution flow:

1. Scheduler runs periodically (default: 300 seconds)
2. Acquire lock — prevent concurrent runs
3. Load changes — fetch unprocessed entity changes
4. Build impact — resolve affected topic IDs from changes
5. Hydrate state — load all data for impacted topics
6. Compute metrics — aggregate question results by topic
7. Apply rules — detect patterns and anomalies
8. Generate explanations — create human-readable reports
9. Persist results — save to database atomically
10. Acknowledge changes — mark as processed
11. Release lock — allow next run

Key design decisions:

• Incremental processing — processes only changed data using the changed_entities table, avoiding full recomputation
• Batch isolation — each batch runs in its own transaction with rollback on failure
• Separation of concerns — metrics, rules, and explanations are independent modules
• Explainable AI (xAI) — outputs are human-readable with hypotheses, evidence, alternatives, and uncertainty notes — no black-box LLMs
• Confidence scoring — each finding includes a confidence level (high/medium/low) based on rule score
• Uncertainty tracking — limitations and missing context are stored alongside each finding

Data model:

• Topics — core domain entity with difficulty and target_mean
• Assignments — linked to topics, each with type, max_score, due_date
• Question Results — per-question scores with error_type classification
• Activity Weekly — forum posts, resource views, quiz launches for engagement calculation

Output artifacts:

• topic_metrics — 11 numerical indicators per topic
• findings — detected patterns with severity and confidence
• finding_evidence — raw metrics supporting each finding
• explanations — human-readable hypotheses with confidence
• alternative_explanations — other possible interpretations
• recommended_actions — actionable suggestions for instructors
• uncertainty_notes — limitations and missing context

Docker orchestration

Each part of the BI system is packed into docker container and orchestrated by docker-compose. This allows to run the system on any machine with docker installed without any additional configuration.

Incremental analytics

The system implements an incremental batch processing approach to avoid full recomputation of analytics on every data change. Instead of recalculating all topics, it detects which entities have changed, resolves the affected topics, and recomputes only those topics.

How it works:

1. Change tracking — database triggers register every INSERT/UPDATE/DELETE on source tables (topics, assignments, question_results, activity_weekly) into the changed_entities table
2. Impact resolution — the pipeline resolves which topic IDs are affected by each changed entity (e.g., question_result → assignment → topic)
3. State hydration — loads only the data needed for impacted topics
4. Computation — runs metrics, rules, and explanation engines on the hydrated subset
5. Acknowledgment — marks changed entities as processed after successful persistence

Comparison with industry approaches:

Where our approach sits:

• vs. Full recomputation — significantly faster (topics scale ~10x better), avoids redundant processing of unchanged data
• vs. Stream processing — simpler to implement and debug, no complex state management; trade-off is higher latency (minutes vs. milliseconds)
• vs. Materialized views — more flexible because we can run arbitrary Python logic (rules, explanations, uncertainty notes), not just SQL aggregations
• vs. Lambda — intentionally minimal; one batch pipeline is sufficient for the domain

Key differentiators:

• Explainability built-in — every incrementally computed finding includes hypothesis, evidence, alternatives, and confidence
• Transactional integrity — each batch runs in a database transaction; rollback on failure prevents partial results
• Deadlock safety — pipeline locks ensure only one run executes at a time
• Idempotent processing — each change is processed exactly once (processed flag)
• Auditable — every run is stored in analytics_runs with source snapshot and status

Limitations and future improvements:

• No real-time updates — 5-minute batch interval is acceptable for education analytics but not for live dashboards
• Simple impact resolution — topic-level granularity; fine-grained (student-level or question-level) recomputation would reduce work further
• No windowing — changes accumulate; a sliding time window would allow purging old changes from the queue
• Observability — currently lacks monitoring of queue size, processing time, and failure rates

The incremental batch approach is a pragmatic choice that balances complexity, performance, and maintainability. It fits the educational analytics domain perfectly — where near-real-time insights with explainable AI are more valuable than sub-second latency.

Next steps

Only part of the requirements has been implemented. Next steps would require further extension to meet with all current requirements from stakeholders.

Related publications

Lightweight BI system for university, part II: how the analytics is built
Lightweight BI system for university, part III: UX redesign targeting 5–10 minute weekly review
Case study: developing forecast sales system for a major airline

Executive Summary

Rising interests of the government to apply AI to the public administration is a case behind creating this publication based on my previous works. To keep it short and simple I emphasize 3-4 key ideas that should give maximum outcome. AI could strengthen governance as well as make it worse, it is important to understand and mitigate such risks which had been covered in my others publications pointed out in the references

Most discussions about Artificial Intelligence in the public sector focus on automating paperwork, accelerating administrative procedures, or replacing routine tasks performed by civil servants.

While these applications are valuable, they overlook a much larger opportunity. AI makes it possible to rethink government itself—not merely as an organization that processes information, but as a system capable of continuously learning from its own decisions.

Instead of treating Artificial Intelligence as another digital service, it can become the foundation of a self-learning model of public administration, where knowledge is accumulated rather than forgotten, analyzed rather than archived, and reused rather than rediscovered.

"The twentieth century gave governments computation. The twenty-first century should give governments the ability to learn."

Why This Matters

Public administration is becoming exponentially more complex.

Governments must simultaneously process increasing volumes of information, rapidly evolving legislation, interconnected policy challenges, technological change, and growing societal expectations.

Yet the prevailing model of governance remains largely reactive. Similar problems are repeatedly analyzed from scratch, while valuable institutional knowledge remains scattered across documents, departments, and individual experts.

When projects conclude or experienced personnel leave, much of this knowledge disappears with them.

As a consequence, governments often repeat previous analyses, revisit familiar debates, and occasionally reproduce the same mistakes.

The Central Idea

The primary role of Artificial Intelligence should not be the automatic generation of documents or the replacement of public officials.

Its strategic purpose should be to transform government into a self-learning system.

Every policy decision should become a source of new knowledge.

Every completed project should improve future decision-making.

Every managerial failure should become institutional experience rather than institutional memory loss.

In other words, governments should learn in the same way successful organizations continuously improve through accumulated experience.

Key Components of a Learning Government

1. Personalized Continuous Learning

AI can continuously analyze each civil servant's responsibilities, legislative updates, completed work, and emerging professional challenges.

Based on this information, the system generates a personalized daily learning program lasting approximately 20 to 60 minutes.

Learning becomes an integrated part of everyday work rather than an occasional training event.

2. Scenario Modeling

Before important policy decisions are considered, AI automatically constructs several alternative development scenarios.

Each scenario evaluates:

• possible consequences;
• associated risks;
• required resources;
• estimated probability;
• cross-sector impacts.

This shifts decision-making from reactive governance toward proactive strategic management.

3. Intelligent Decision Support

Before reviewing a policy issue, decision-makers receive an analytical briefing generated automatically by the system.

The briefing includes:

• historical precedents;
• reasons behind previous decisions;
• observed outcomes;
• alternative approaches;
• stakeholder analysis;
• identified risks;
• international experience;
• projected future consequences.

AI does not replace human judgment. Instead, it provides decision-makers with the broadest possible informational foundation.

4. Institutional Memory

Perhaps the most important function of such a system is preserving organizational knowledge.

Years after a decision has been made, government should still be able to reconstruct:

• why a particular decision was adopted;
• which alternatives were considered;
• what constraints existed;
• what forecasts were made;
• what outcomes were ultimately achieved.

Institutional memory should no longer depend upon individual careers, organizational restructuring, or the survival of isolated documents.

Beyond Large Language Models

Building a learning government requires considerably more than deploying a single language model.

The objective should be the creation of a comprehensive AI infrastructure, of which language models represent only one component.

Such an infrastructure would include:

• AI foundation models;
• secure computing infrastructure;
• knowledge platforms;
• semantic search technologies;
• vector databases;
• agent-based systems;
• standardized integration with existing governmental information systems.

A modular architecture also allows individual components to evolve independently without redesigning the entire system.

Expected Benefits

A learning model of public administration could:

• reduce the time required to prepare policy decisions;
• improve decision quality;
• support continuous professional development of civil servants;
• reduce dependence on individual personnel;
• preserve institutional knowledge across generations;
• increase the reuse of accumulated managerial experience;
• establish the technological foundation for future AI-enabled governance.

The Broader Perspective

The fundamental question is not how governments should introduce Artificial Intelligence into existing administrative procedures.

The more important question is whether AI can help governments become organizations that continuously learn from their own experience.

Throughout history, governments have accumulated power, territory, institutions, and information. In the coming decades, their comparative advantage may increasingly depend on something different: the ability to systematically accumulate knowledge, transform it into better decisions, and continuously improve through experience.

If computation defined the digital state of the twentieth century, learning may define the intelligent state of the twenty-first.

Related Publications

Executive summary

This week I finished work on a minimum viable product (MVP) for a manufacturing company that aims to reduce machine downtime and therefore cut losses.

It addresses the following pain point: "We have a machine. Where is all the information about it, and how can we ensure that this knowledge doesn't disappear when employees leave?". According to available statistics, the depreciation rate of fixed assets in the manufacturing industry is about 50% (Russia). This means that these assets require continuous maintenance to extend their service life. Although my personal experience is limited to a single manufacturing company, it confirms that old machines make up a significant share of physical assets and that engineers often struggle to find documentation and accumulated knowledge about how to repair them developed over the years.

The concept is straightforward: every machine gets a QR code. An engineer scans it and instantly receives access to:

• Technical documentation and service manuals
• List of breakdowns over the years
• Who repaired the machine, when it was repaired, and what was done.

Tech stack:
Kotlin backend, React/TS web client, mobile web client, Postgres, Docker Compose.

Github repository

Web site

Market research

Market capacity

Rosstat reported:

• The depreciation rate of fixed assets in the manufacturing industry is approximately 50%;
• Machinery and equipment are depreciated at approximately 50–52%;
• Approximately 18–20% of machinery and equipment are completely worn out.

The situation with machinery assets in the rest of the world doesn't make a big difference:

The next interesting metric is the number of manufacturing enterprises with sufficiently complex and aging equipment where undocumented knowledge causes downtime, onboarding issues, and dependence on key personnel.

The ballpark formula and estimate are as follows:
Target factories = Manufacturing enterprises × % with multi-machine operations × % suffering from knowledge fragmentation

Competitor analysis

Product Category	Examples	Problems Solved	Weaknesses for This Use Case
Generic Wiki / Documentation Systems	Confluence, BookStack, MediaWiki	Documentation management, procedures, onboarding, knowledge sharing	Not machine-centric; no equipment inventory; no breakdown history; QR workflows must be built manually.
CMMS (Maintenance Systems)	openMAINT, MaintainX, UpKeep	Work orders, preventive maintenance, asset tracking, maintenance scheduling	Optimized for maintenance execution rather than preserving institutional knowledge; documentation is usually secondary.
MES (Manufacturing Execution Systems)	OpenMES, IMES	Production tracking, work orders, routing, scheduling, shop-floor execution, documentation attached to operations	Documentation is process-centric rather than machine-centric; historical repair knowledge and troubleshooting experience are usually not first-class entities.
ERP + MES + QMS Platforms	Carbon	Production planning, inventory management, quality control, business processes, manufacturing operations	Broad enterprise scope increases implementation complexity and deployment cost; preserving repair knowledge is only a small subset of the platform.
Enterprise EAM Platforms	IBM Maximo, SAP Asset Management	Enterprise asset management, maintenance planning, analytics, integrations	Expensive; complex deployment; excessive for many SMEs; long implementation cycles.
File Shares and Network Drives	SharePoint, NAS, shared folders	Central storage of manuals and drawings	No machine context; poor searchability; no repair history; knowledge remains fragmented.
Paper Documentation	Binders near machines	Immediate local availability	Easily outdated; difficult to search; impossible to aggregate organizational knowledge.
Human Memory ("Ask Sergey")	Experienced maintenance personnel	Tacit knowledge and undocumented troubleshooting experience	Single point of failure; knowledge disappears with retirement or employee turnover.

Available open-source solutions

Available commercial solutions

Capability comparison

Existing solutions tend to optimize one of three concerns: documentation management, maintenance execution, or production execution. Small and medium manufacturers frequently need something simpler: a machine-centric knowledge repository that can be deployed quickly, accessed directly from the shop floor via QR codes, and preserve historical maintenance knowledge that would otherwise remain locked inside individual engineers' heads.

Potential market fit

The strongest signal of market fit is not the absence of competitors, but rather the fragmentation of partial solutions. Existing systems typically solve adjacent problems: documentation (wikis), maintenance execution (CMMS), production tracking (MES), or enterprise asset management (EAM). However, none of them treats the machine itself as the central knowledge entity that accumulates operational history over time.

In practice, most manufacturing companies operate in a hybrid state:

• formal maintenance systems exist but are underused or partially implemented;
• documentation is stored in shared folders or paper binders;
• critical knowledge remains in the heads of a small number of technicians;
• production and maintenance systems are disconnected.

This creates a consistent operational gap: information exists, but it is not accessible in the context where it is needed (at the machine, during failure, under time pressure).

The proposed system is positioned to fill this gap by unifying three layers:

• static knowledge (manuals, procedures, documentation),
• historical operational knowledge (breakdowns, repairs, patterns),
• contextual access layer (QR-based retrieval directly at the machine).

This combination is particularly relevant in environments with:

• heterogeneous equipment fleets (different generations and vendors),
• limited digital integration between systems,
• high dependency on experienced technicians,
• cost-sensitive production where downtime is still expensive but not digitized away.

From a geographic perspective, these conditions are not confined to a single region. They are common across Eastern Europe, parts of Western Europe (notably SME manufacturing sectors), the United States industrial mid-market, and rapidly industrializing economies in Asia.

The most promising segment is not the most advanced factories, but rather the “in-between” segment: companies that are large enough to suffer from knowledge fragmentation, but too small or too fragmented to justify heavy enterprise systems such as SAP or IBM Maximo.

In this sense, the product does not compete directly with MES or ERP systems. Instead, it operates as a lightweight layer above them — or alongside them — focused exclusively on preserving and operationalizing machine-level knowledge.

A practical indicator of product-market fit would be the moment when maintenance teams stop asking:

“Where is the manual for this machine?”

and instead begin asking:

“What has historically been done when this machine failed in this way?”

That shift represents a transition from documentation-centric behavior to knowledge-centric behavior, which is the core value proposition of the system.

Finally, the adoption curve is likely to follow a bottom-up pattern. Initial usage is driven by a single workshop, production line, or maintenance team. Once the value of reduced downtime and faster troubleshooting becomes visible, the system can expand horizontally across the factory and vertically across multiple sites.

How much to charge for this product to stay attractive for the customer?

Knowledge management systems are somewhat unusual products because they are difficult to evaluate in isolation. Customers do not buy documentation, QR codes, or a searchable wiki. They buy fewer hours of stopped production, less dependence on individual experts, and faster recovery when something eventually breaks.

Therefore, pricing should not be benchmarked against generic wiki software such as Confluence or SharePoint. It should be benchmarked against the financial impact of equipment downtime.

A simple ROI model can be expressed as:

            Annual benefit =
                downtime reduction
            + reduced time spent searching for information
            + faster onboarding of engineers
            + avoided losses from knowledge leaving the company
        

Consider a small factory:

• 100 machines;
• 6 maintenance technicians;
• 15 significant breakdowns per year;
• 2 hours saved per incident;
• Downtime cost: €2,000 per hour.

Downtime savings alone are:

            15 × 2 × €2,000 = €60,000 per year
        

If the system also saves engineers twenty minutes per day previously spent searching for manuals, drawings, and historical repair information, the labour savings can easily exceed another €10,000–15,000 annually.

Even conservative assumptions quickly produce annual benefits in the range of €50,000–100,000 for a medium-sized factory.

As a rule of thumb, industrial software remains an easy purchasing decision when its annual cost is below 10% of the measurable value it creates.

This leads to an interesting conclusion. Although the product itself is technically simple, its value proposition is not. A system that saves a factory €50,000 per year should not be sold for €200 simply because it is "only a documentation system".

A more reasonable pricing strategy might look as follows:

Regional purchasing power should also be taken into account.

The pricing model should probably scale with the customer's complexity: number of machines, number of users, or number of production sites. Such metrics are easy to understand and correlate reasonably well with the value generated by the system.

The product is better described as a form of insurance against knowledge loss and expensive production downtime. If a factory believes the system can prevent even a single serious incident per year, paying several thousand euros annually becomes a rational business decision.

Architecture

High-Level Flow:

User (operator/technician on shop floor) → opens Web Client (React/TS) on mobile/desktop.

Presses Scan → uses device camera (rear preferred) to read QR/Barcode on equipment.

Frontend calls Backend → GET /api/v1/machine/barcode/{barcode}.

Backend returns machine data or redirects to /machines/{id}.

Machine Card shows: documentation, maintenance history, solutions to past issues, attachments (PDFs, videos, schemas).

Deployment View (Docker Compose)

• Services:
  • web / web-prod → React frontend (port 3000)
  • server → Kotlin Spring Boot backend (port 8080 + Swagger)
  • database → PostgreSQL
• Profiles: prod and dev
• All self-hosted, easy one-command deploy.

Strengths

• Mobile-first with strong Android/Chrome focus.
• Simple, maintainable stack.
• QR-driven navigation = core differentiator for shop-floor use.

Market entry strategy

This section describes a rough vision of how the product is expected to enter the market and evolve from early validation to scalable sales.

Phase 1 — Validation

• Landing page with clear product positioning and use cases
• Public GitHub repository (transparency + trust for technical buyers)
• 1–3 pilot factories for real-world testing
• Manual outreach to maintenance engineers and plant managers
• No or minimal paid advertising

Goal: validate that the system is actually used in real workflows and that a full usage loop exists (scan → find knowledge → solve problem → repeat usage).

Phase 2 — Proof of value

• Derive at least one concrete case study from a pilot factory
• Refine positioning based on real feedback from technicians and managers
• Improve onboarding and first-time setup experience
• Introduce first paying customers, even at small scale

Goal: confirm willingness to pay and validate that the product is perceived as economically valuable, not just “useful software”.

Phase 3 — Early scaling

• Targeted advertising to specific industrial niches (not broad marketing)
• Outbound outreach via LinkedIn and industry networks
• Initial reseller or sales partners, but only after messaging is stable and proven

Goal: establish a repeatable acquisition channel that can consistently generate new customers without relying on founder-led sales alone.

Phase 4 — Sales expansion

• Hire regional sales representatives
• Expand into EU and US industrial markets
• Build localized sales and onboarding processes

Goal: transition from founder-driven distribution to a structured sales organization capable of scaling across regions and industries.

Pricing model

Right now open source version (free) and custom extension by customer demand (paid) are available right now. SaaS option and technical support are possible as one of the offerings in future.

The product follows a hybrid distribution model combining open-source self-hosting with a potential paid SaaS offering and optional enterprise services. This structure is designed to maximize adoption in early stages while enabling sustainable monetization in environments where reliability, integration, and operational support are critical.

1. Open-source (self-hosted) model

• Free and open-source core product
• Full access to source code and deployment configuration
• Self-hosted deployment on customer infrastructure (on-premise or private cloud)
• No licensing fees or vendor lock-in
• Community-driven or internal support responsibility

This model is intended to enable fast adoption and low-friction evaluation in real production environments. It is particularly suitable for companies with internal IT capacity and a preference for infrastructure control.

The open-source version includes the core functionality: machine registry, QR-based access to documentation, and basic maintenance history tracking.

2. SaaS (managed platform) model

• Fully hosted and managed deployment
• Automated updates, monitoring, and backups
• Operational support and maintenance included
• Secure access management and system administration

The SaaS version is not only a hosting alternative, but an operational layer designed for production environments where uptime, simplicity, and reduced internal IT burden are critical.

In addition to the core features, the SaaS platform may include capabilities that are difficult to replicate in self-hosted deployments, such as:

• Multi-site synchronization across factories
• Centralized administration of distributed equipment fleets
• Audit logs and operational traceability
• Advanced backup and disaster recovery mechanisms

Pricing is based on operational scale (number of machines, users, or sites) and level of service.

3. Enterprise support and integration services

• Onboarding and guided deployment in production environments
• Integration with existing MES, ERP, or CMMS systems
• Data migration from legacy documentation systems
• Technical support tailored to operational requirements

This layer addresses the reality of industrial environments where adoption often depends not only on software, but on successful integration into existing processes and infrastructure.

4. Customisation and extension model

The platform is designed to be extensible to accommodate specific workflows, machine types, and organizational needs. Customisation typically includes:

• Custom feature development on top of the core system
• Specialized UI/UX adaptations for shop-floor usage
• Integration with proprietary systems or internal tools
• Private extensions maintained for individual customers

Customisation is handled on a project basis and is priced individually depending on scope, complexity, and long-term maintenance requirements.

5. Product evolution perspective

The pricing structure reflects an expected evolution of the product over time.

In early stages, value is primarily delivered through ease of adoption and transparency via the open-source core. As deployments mature, value shifts toward operational reliability, integration depth, and cross-site coordination.

In later stages, the product is expected to evolve from a documentation and access layer into a machine-centric operational knowledge system, where higher-value capabilities such as pattern recognition, recurring failure analysis, and decision support become increasingly important.

This progression allows the product to remain accessible for small deployments while gradually increasing monetization potential as organizational dependency on the system grows.

Summary

• Open-source core ensures fast adoption and trust-building
• SaaS monetizes operational convenience and reliability
• Enterprise services cover integration and deployment complexity
• Customisation enables adaptation to real-world industrial variability

The model is intentionally designed to start as an accessible tool and evolve into a critical operational layer in manufacturing environments where knowledge retention and downtime reduction have direct financial impact.

Executive Summary

This week I prepared a document to establish a strategic framework for the use of Artificial Intelligence (AI) in educational and managerial processes and to identify the key systemic risks associated with its adoption.

Initially prepared to facilitate AI adoption within Financial University (Russia), you are welcome to use it as a foundation to facilitate discussions in your own workspace.

This is not merely about improving individual processes through technology. AI has the potential to fundamentally transform education, work, and knowledge management.

The Core Thesis

Artificial Intelligence has already ceased to be merely an auxiliary tool.

It is becoming:

• a factor of productivity;
• a factor of competitiveness;
• a factor of organizational and governmental management;
• a factor influencing the structure of the labor market.

In practice, AI is increasingly acting as a universal amplifier of intellectual activity, comparable in significance to previous technological revolutions.

Practical Observation: The Effect Is Already Visible

Even without making long-term predictions, several changes can already be observed:

• significant acceleration of knowledge work;
• lower costs of performing intellectual tasks;
• the ability of one person to perform work that previously required a team;
• faster learning and acquisition of new competencies.

The difference between people who use AI and those who do not is already becoming a significant productivity gap.

Similarly, access to stronger and weaker AI models creates persistent competitive inequalities.

Strategic Implications

Artificial Intelligence is gradually becoming a strategic resource that influences:

• economic resilience;
• technological development;
• educational outcomes;
• the pace of scientific progress;
• the competitiveness of organizations and states.

At the same time, access to AI should not be confused with technological independence from it.

Technological Sovereignty and Dependency

In the context of AI, technological sovereignty cannot be reduced to the formal use of a domestic product.

The real question is different:

Does the solution provide genuine technological autonomy, or does it merely localize the interface on top of a global technological dependency?

In practice, most modern solutions:

• use external models;
• depend on the global open-source ecosystem;
• or combine both approaches.

Full independence in advanced AI remains extremely limited because it requires simultaneous control over:

• computing infrastructure;
• models;
• data;
• research talent.

Even the world's leading players rarely possess complete autonomy across all of these layers.

The Systemic Risk of Dependency

The use of external AI services creates a new form of technological dependency:

• dependency on model providers;
• dependency on infrastructure providers;
• dependency on access rules and restrictions;
• dependency on data processing policies.

This is not an abstract concern. It is a structural property of the current AI ecosystem.

Building a fully autonomous national AI stack requires resources of such magnitude that it becomes an exceptionally difficult and long-term task.

AI as a Factor in the Redistribution of Power and Knowledge

AI affects not only productivity but also:

• the distribution of knowledge;
• access to expert interpretation of information;
• decision formation;
• the speed of decision-making.

Control over AI infrastructure is therefore becoming a source of influence comparable to control over energy or industrial resources in previous eras.

Risks of Using AI in Education

In education, AI creates not only opportunities but also systemic risks.

Risk #1. Cognitive Degradation Through Improper Use

Excessive reliance on AI may result in:

• reduced ability to solve problems independently;
• weakened analytical and synthesis skills;
• loss of the ability to formulate conclusions;
• delegation of thinking responsibility to an external system.

In such a scenario, education risks partially losing its fundamental mission: the development of independent thinking.

Risk #2. Errors and the Illusion of Authority

Modern AI models:

• can confidently generate incorrect answers;
• do not possess an intrinsic mechanism of truth;
• may create an illusion of expertise.

This becomes particularly dangerous when users cannot independently verify the results.

Risk #3. Informational and Behavioral Constraints

AI models are not neutral systems.

• they contain embedded constraints;
• they shape acceptable forms of response;
• they may influence the user's reasoning process.

This creates a risk of information bias without explicit awareness of the process itself.

Risk #4. Loss of Control Over Intellectual Data

The use of cloud AI services raises several questions:

• where and how data is used;
• whether it can be utilized for model training;
• who controls future use of the results.

This creates the potential loss of full control over the outcomes of intellectual work.

Approaches to Risk Mitigation

Risks do not imply that AI should be rejected.

They imply the need for controlled adoption.

Principle #1. Augmentation Rather Than Replacement

AI should be used as:

• a tool for amplifying thinking;
• a tool for feedback and validation;
• a learning instrument.

It should not become:

• a replacement for thinking;
• a replacement for learning;
• a replacement for responsibility in decision-making.

Principle #2. Separation of Usage Levels

Different categories of information should be treated differently:

• critical data — local processing;
• working data — controlled cloud services;
• educational data — acceptable use of external models.

Principle #3. Multi-Model Strategy

Dependency can be reduced through:

• using multiple models;
• comparing outputs;
• avoiding critical dependence on a single provider.

Principle #4. The Role of the Teacher Is Strengthened

With proper adoption:

• teachers are not replaced;
• they become stronger as mentors and experts.

Their role increasingly shifts toward:

• problem formulation;
• interpretation of results;
• development of thinking;
• quality control of reasoning.

Conclusion

Artificial Intelligence is simultaneously a technology that:

• dramatically increases productivity;
• changes the structure of knowledge and work;
• creates new forms of dependency;
• requires reconsideration of educational and management approaches.

The key conclusion is straightforward:

The adoption of AI should be viewed not as a local digitalization initiative but as a strategic transformation of education and intellectual work.

At the same time, it is critically important to preserve a balance between:

• leveraging the opportunities created by AI;
• preserving the human capacity to think, learn, and make decisions independently.

Related Publications

• Cognitive risks of using AI and how to mitigate them (December, 2025)
• The modern education and place of AI here (July, 2024)