On 29 September 2026, Romania’s National Cyber Security Directorate (DNSC) issued the first ever penalty under GEO no. 155/2024, the national transposition of NIS2. The fine is 50,000 lei, roughly 10,000 euro, and it went to a legal person described as a specialised body of the central public administration, covered by sector 10, Public administration, in Annex no. 1 to the ordinance. The legal basis cited by DNSC is art. 60 para. (1) letter o).
The press release, published on 30 September and carried by the national news agency, says the entity „failed to observe the notification obligation within the legal deadline”. Part of the press rendered that as a failure to report incidents. The text of the law says something else, and the difference matters for every entity in scope.
What letter o) actually says
„failure by entities in the sectors listed in Annexes no. 1 and 2 to comply with the notification obligation under art. 18 para. (2) within the indicated deadline”
The cross-reference is to art. 18 para. (2), which sits in Chapter IV, titled „Registration”. That article requires entities in the Annex 1 and Annex 2 sectors to notify DNSC for the purpose of registration in the register of entities, within 30 days of the ordinance entering into force, or of the date on which its provisions become applicable to them.
Incident reporting lives in a different chapter and a different article: art. 15, with 24 hours for the early warning, 72 hours for the incident notification and one month for the final report. Failing those obligations is penalised under other letters of art. 60 para. (1), not under letter o).
Romania’s first NIS2 fine is therefore not a fine for an undeclared incident. It is a fine because an entity did not register with the authority in time.
The two notifications people confuse
Criterion
Registration notification
Incident notification
Legal basis
art. 18 para. (2)
art. 15
When
once, on entering scope, plus updates
for every incident with significant impact
Deadline
30 days
24 hours, 72 hours, final report at one month
Where
the NIS2@RO platform, or e-mail or filing at the DNSC office
DNSC, through the incident reporting channels
Offence
art. 60 para. (1) letter o)
other letters of art. 60 para. (1)
Why 50,000 lei
The amount is neither arbitrary nor maximal. Art. 60 para. (2) sets different ranges depending on the letter breached and on the status of the entity. For letter o), the ranges are:
important entities: from 1,000 to 300,000 lei;
essential entities: from 1,500 to 500,000 lei.
The sanctioned entity is a central public administration institution. Under art. 5 para. (1) letter a), central public administration entities listed in Annex no. 1 are essential entities regardless of size. The applicable range is therefore 1,500 to 500,000 lei, and 50,000 lei is about one tenth of the ceiling.
The contrast with the other ranges in the same article is worth keeping in mind. For breaches treated as serious, art. 60 para. (2) letters a) and b) reach up to 7,000,000 euro or 1.4 per cent of total worldwide annual turnover for important entities, and 10,000,000 euro or 2 per cent for essential ones, whichever is higher. Failure to register sits on the lower tier. That is not where the real financial exposure is.
Who establishes the offence
Art. 61 para. (2), as amended by Law no. 124/2025, splits the competences. For offences under letters o) to dd), the offence is established by DNSC and the penalty is applied by decision of the DNSC director. For other letters, control staff of the sectoral competent authorities may also establish the offence.
That explains the wording in the press release, a „decision establishing the offence and applying the penalty”. It is not an inspection report drawn up by a sectoral inspector, it is an act of the head of the authority.
What this means for everyone else
The ordinance entered into force on 31 December 2024. For entities already in scope at that date, the 30 day deadline expired on 30 January 2025. For an entity entering scope later, because it crosses a size threshold, changes its activity or is identified under art. 9, the deadline runs from the date on which the provisions become applicable to it.
Two practical consequences, frequently ignored:
The obligation does not lapse when the deadline passes. An entity that failed to notify in January 2025 has not escaped the obligation. It still has it, and the delay remains punishable.
The authority does not come looking for you first. Scope is self-assessed. The law provides for no list that the authority sends out to companies, and until the registration decision arrives, the entity is the one that has to know its own status.
The first fine went to a public institution. That is not a sign that the private sector is less exposed. It is, most likely, a sign of where the authority has immediate visibility.
What to check this week
Whether your organisation operates in one of the sectors in Annex no. 1 or no. 2 to GEO no. 155/2024.
Whether the registration notification was actually sent, and whether you hold the acknowledgement from DNSC. Do not assume: ask for the document.
Whether the data submitted is still current. Changes to identification information must be communicated within two weeks of the change.
Whether the entity has enrolled on the NIS2@RO platform, if the initial notification was made by e-mail or on paper.
Whether the officer responsible for the security of networks and information systems has been appointed, within 30 days of DNSC communicating the registration decision.
Whether an internal incident reporting procedure exists, and whether someone can trigger it within 24 hours, including at night and at weekends.
Where we can help
If you are not certain whether you fall within the scope of the ordinance, the CysNis platform walks through the scoping criteria step by step and separates legal obligations from technical recommendations.
If you are in scope and want to know how far you are from the requirements, the starting point is a NIS2 compliance analysis with a remediation plan, built on evidence rather than statements. ProDefence is a cyber security auditor accredited by DNSC. For organisations with no one to appoint internally, the role can be covered through an outsourced NIS2 officer.
Sources
GEO no. 155/2024, published in the Official Gazette no. 1332 of 31 December 2024, consolidated text on the Romanian Legislative Portal. Art. 5, 15, 18, 60 and 61.
Law no. 124/2025 approving GEO no. 155/2024, published in the Official Gazette no. 638 of 7 July 2025, text on the Legislative Portal.
DNSC, press release of 30 September 2026 on the first penalty for failure to comply with the notification obligation, dnsc.ro.
Order of the DNSC director no. 1/2025 on the requirements for the registration notification, Official Gazette no. 776 of 20 August 2025, the requirements.
This material is informative and does not constitute legal advice. The amount of the fine and the status of the sanctioned entity come from the DNSC press release as carried by the national news agency. DNSC did not publish the name of the entity. Quotations from the ordinance are working translations of the Romanian text.
Frequently asked questions
What was Romania’s first NIS2 fine issued for?
For failing to comply with the notification obligation for registration in the register of entities, set out in art. 18 para. (2). The penalty is grounded in art. 60 para. (1) letter o), which refers expressly to that article. The fine is 50,000 lei and was applied on 29 September 2026 to a specialised body of the central public administration.
Is the fine about an unreported incident?
No. Incident reporting is governed by art. 15, with deadlines of 24 hours, 72 hours and one month, and breaches of it are penalised under other letters of art. 60 para. (1). Letter o), cited by DNSC, concerns only the registration notification.
How large can the fine be for failing to register with DNSC?
Under art. 60 para. (2), from 1,000 to 300,000 lei for important entities and from 1,500 to 500,000 lei for essential entities. The 50,000 lei fine falls in the second range, because central public administration entities listed in Annex no. 1 are essential entities regardless of size under art. 5 para. (1) letter a).
We missed the 30 day registration deadline. What now?
The obligation does not lapse when the deadline passes. The notification should still be filed, through the NIS2@RO platform or, if the platform is unavailable, through the other channels set out in Order of the DNSC director no. 1/2025. The delay remains punishable, but a notification filed on your own initiative is a better position than one established during an inspection.
Who establishes the offence and how is it challenged?
For offences under letters o) to dd), the offence is established by DNSC and the penalty applied by decision of the DNSC director, under art. 61 para. (2). Challenges follow the general regime for administrative offences; the remedy, the deadline and the competent court are stated in the decision itself.
How do I know whether my organisation has to register?
Scope is self-assessed, based on the sector listed in Annexes no. 1 and 2 and the size thresholds in art. 8, which refer to Law no. 346/2004. Some entities are in scope regardless of size, under art. 9. The authority does not send out a list of the companies concerned.
Romania’s National Cyber Security Directorate (DNSC) is preparing an act that changes how the management training obligation in GEO no. 155/2024 should be read: a draft decision approving the cybersecurity training standard for the management bodies of essential and important entities, together with the list of recognised cybersecurity certifications.
One clarification belongs in the first paragraph: the document analysed here is a draft, watermarked DRAFT on every page. It is not a legal act in force, it produces no legal effects yet, and it may change before publication in the Official Gazette. We analyse it because it shows, in unusual detail, what the authority will expect from directors and executives, and organisations that understand the logic early arrive prepared without emergency spending.
In short
The draft defines a single training role: Executive Manager in Cybersecurity Governance, at strategic management level.
The standard has 6 competence units, all about governance and oversight, not technical execution.
Assessment is proposed as 50% crisis simulation and 50% governance portfolio, plus a multiple choice test.
The curriculum is open: NIST CSF 2.0, ENISA ECSF, NIST SP 800-34 Rev. 1, ENISA Threat Landscape and national legislation.
Where the obligation comes from and why a standard appears now
Government Emergency Ordinance no. 155/2024, approved with amendments by Law no. 124/2025, provides in art. 14 that the management bodies of essential and important entities approve cybersecurity risk management measures, supervise their implementation and are liable for breaches of those obligations. The same article requires members of management bodies to follow periodic training enabling them to identify risks and assess risk management practices.
Until now the legal text had no minimum content attached to that training. In practice, “management training” has meant anything from a forty minute presentation to a serious governance programme. The draft decision fills exactly that gap: it states which competences must be demonstrated, at what level, and how they are verified.
The legal basis invoked in the draft is art. 5 letter b) and art. 7 paragraphs (3) and (4) of GEO no. 104/2021 establishing DNSC, approved by Law no. 11/2022, together with art. 14 paragraphs (2) and (4) of GEO no. 155/2024. In its draft form, the act is to be published in the Official Gazette, Part I.
The role the training targets
Annex no. 1 defines a single role, Executive Manager in Cybersecurity Governance, placed at strategic and executive management level. The wording matters, because it draws a clear line around what is and is not asked of a director or CEO.
The role assumes no technical execution skills. It assumes the ability to govern: to set the organisation’s risk appetite, approve policies, allocate resources, supervise and control. The most concrete element in the whole annex is the executive’s duty to formally designate the person responsible for the security of networks and information systems under art. 14 paragraphs (3) and (4) of GEO no. 155/2024, a role the document calls CISO.
The distinction the draft repeats in several places is between responsibility, meaning execution, which belongs to the designated officer, and accountability, which stays with executive management. The function can be delegated; the accountability cannot.
The six competence units
Unit
What it actually requires
CU1. Assuming the legal liability framework
Identifying the entity’s legal status, essential or important; interpreting due diligence obligations, separating clearly what may be delegated from what may not under art. 14; integrating an all-hazards perspective. The document speaks of moving from assumed ignorance to informed diligence and refers to the sanctions regime.
CU2. Setting the context and strategy for cyber risk governance
Drafting a risk appetite statement, cost-benefit analysis of measures including ROSI, documented risk acceptance decisions and policy approval. Aligned to the GOVERN function of NIST CSF 2.0.
CU3. Organisation, delegation and resource allocation
Job description and KPIs for the designated officer, reporting lines that keep that officer independent from the IT function, the formal appointment decision, budgeting based on ROI and ROSI, supply chain security clauses and periodic audit of critical suppliers.
CU4. Compliance oversight and threat literacy
Executive understanding of relevant threats: ransomware with double extortion, CEO fraud and business email compromise, deepfakes. Out-of-band verification procedures, risk indicators that are more than technical statistics, phishing test results, audit trail.
CU5. Resilience and business continuity management
Separating business continuity, an executive responsibility, from disaster recovery, a technical one. Approving the plan with manual fallbacks, the crisis cell, the implications of paying a ransom, crisis communication, and incident reporting: early warning within 24 hours and a report within 72 hours under art. 15 of GEO no. 155/2024. Methodological reference: NIST SP 800-34 Rev. 1.
CU6. Auditability and documented compliance
Formalising risk acceptance, including decisions not to implement a measure for cost or operational reasons, periodic signing of the risk register, minutes of board meetings on security topics, archiving audit reports, evidence of training attendance, supervising registration in the entity register and the accuracy of information submitted to the authority.
Read together, the six units describe a set of evidence rather than a set of knowledge. Almost every competence element translates into a signed document, a dated decision or a set of minutes. That is the most useful information for an organisation preparing now: management training will be verified through paperwork, not through diplomas.
How assessment is proposed
The assessment section is what sets this standard apart from a classic course. Two methods are proposed, weighted equally.
Crisis simulation, wargaming style, 50%. The candidate receives a scenario such as ransomware triggered just before financial close and must decide under pressure: do we stop production, do we go public, do we switch to the manual procedure. Executive reasoning is assessed, not the technical fix.
Governance portfolio and audit trail, 50%. Real or constructed documents are presented: the risk appetite statement, the RACI delegation matrix separating the board’s role from the designated officer’s, and the minutes of a risk review meeting.
A multiple choice test is added to verify baseline knowledge.
The practical consequence is simple. A director who attended training but has no signed risk register, no appointment decision and no meeting minutes has nothing to submit for the portfolio half. Documentation is built over time, not in the week before assessment.
An open curriculum, with no dependence on commercial standards
The draft explicitly chooses an open curricular approach, based solely on public standards and national legislation, so that executive training is accessible nationwide. The indicated resources are:
NIST Cybersecurity Framework 2.0, focused on the GOVERN function and the GV.OC, GV.RM, GV.RR, GV.PO, GV.SC and GV.OV categories;
ENISA European Cybersecurity Skills Framework, the CISO profile;
NIST SP 800-34 Rev. 1, for continuity planning;
ENISA Threat Landscape, for the threat literacy component;
applicable national legislation.
The document states that this choice does not exclude commercial, ISO or European standards, and that the same competences may also be acquired through certified individual training programmes. That is an important sentence for organisations that already run an information security management system and do not want to start over.
Annex 2: the list of 61 recognised certifications
The second annex contains the list of recognised cybersecurity certifications, grouped by issuing body. We reproduce it for orientation, noting again that it belongs to a draft and may change.
The list is relevant mainly for the person designated as responsible for the security of networks and information systems, not for every board member. A CEO does not need a CISSP in order to govern risk; they need the decisions and documents described in the competence units.
What the draft does not say
Three limits are worth keeping in mind, so that no false expectations are built.
It is a draft. Numbering, deadlines and application details may change before publication in the Official Gazette.
It does not turn any certification in Annex 2 into a compliance condition for the entity. Compliance is measured against the measures in GEO no. 155/2024 and the DNSC orders issued under it, not against diplomas.
It does not replace the organisation’s own risk assessment. The standard describes what management must know, not which technical measures are sufficient in a given context.
What can be done now, whatever the final form
Every item required in the governance portfolio is a document an entity within the scope of GEO no. 155/2024 needs anyway. A reasonable order of work is the following.
Confirm your classification. Essential or important, on what criterion, in which sector. Everything else follows from this.
Issue the appointment decision for the officer responsible for the security of networks and information systems, with duties, reporting line and indicators.
Approve the risk appetite statement and the security policy, dated and signed.
Build the RACI matrix separating board accountability from execution responsibility.
Write down the incident reporting procedure, with the 24 hour and 72 hour deadlines.
Schedule a risk review meeting and keep the minutes. It is the cheapest portfolio item and the one most often missing.
For the first step, the CysNis platform walks through the classification criteria step by step and separates legal obligations from technical recommendations, so the board discussion starts from a clear status rather than an assumption.
For steps two to six, the documents do not have to be invented from scratch. The NIS2 documentation packages contain the editable templates for decisions, policies, registers and procedures that make up precisely the portfolio described in the draft standard. If the organisation prefers to establish the real distance to the requirements first, the starting point is a NIS2 compliance assessment with a remediation plan, carried out on evidence rather than declarations. ProDefence is a NIS auditor accredited by DNSC.
Where the organisation has no internal person to carry the process and face the authority, the role can be covered through an outsourced NIS2 officer, accountable for deadlines, documentation and the relationship with DNSC. The duty to appoint this officer falls on essential and important entities alike, a point analysed at length in the article on the NIS2 officer at important entities. Which of the three approaches fits best, in-house, consultant or outsourced role, is discussed at length in the article on implementing NIS2 requirements in Romania, three routes.
Frequently asked questions
Is the draft decision binding now?
No. The document is watermarked DRAFT and is not a legal act in force. The obligation to train management bodies already exists, however, under art. 14 of GEO no. 155/2024, approved by Law no. 124/2025.
Must the CEO obtain one of the 61 certifications?
The draft provides nothing of the sort. The Annex 2 list concerns professional cybersecurity competences, relevant mainly for the designated officer. For management, the standard describes governance competences, evidenced through decisions and documents.
What does assessment by simulation mean?
Half of the proposed assessment is a crisis exercise in which decisions are taken under pressure, for example in a ransomware scenario. Executive reasoning is what is examined, not the technical solution.
What is the difference between accountability and responsibility here?
Execution responsibility belongs to the officer responsible for the security of networks and information systems, designated by management. Accountability stays with the management body and cannot be delegated.
Which documents make up the governance portfolio?
The risk appetite statement, the RACI delegation matrix between the board and the designated officer, and the minutes of a risk review meeting. The rest of the standard adds the signed risk register, the appointment decision and evidence of training.
Which incident reporting deadlines are mentioned?
An early warning within 24 hours and an incident report within 72 hours, under art. 15 of GEO no. 155/2024.
The document analysed is a draft decision of the National Cyber Security Directorate approving the cybersecurity training standard for the management bodies of essential and important entities and the list of cybersecurity certifications. It is watermarked DRAFT on every page and is not a legal act in force. The analysis above is informative and does not constitute legal advice.
Romania’s public administration scored 2.07 out of 5 on CyFun® control ID.IM-03.7, which requires independent teams to evaluate the organisation’s processes, best practices and technology solutions for protecting critical systems and assets. DNSC’s conclusion is unusually blunt: in general, public administration entities do not carry out independent evaluations of their own processes and IT infrastructure, exposing themselves unnecessarily to cyber risk.
The wording leaves no room for interpretation. This is not a level that could be improved; it is a type of verification that largely does not take place.
What was measured
The data comes from the PNRR 184 project “Creating new cybersecurity competencies for society and the economy”. A total of 1,599 beneficiaries from the public and private sectors assessed their own maturity on the SecureRO platform, using the CyberFundamentals (CyFun®) framework of the Centre for Cybersecurity Belgium.
The methodological irony is worth noting: the lowest score on independent evaluation comes from a self-assessment. Organisations that are not checked from outside acknowledged, by themselves, that they are not checked from outside.
What “independent” means
The control’s objective is to strengthen protection of critical systems and assets through objective evaluation of the organisation’s processes, practices and technologies. DNSC adds a note for operational technology environments: independent evaluations help identify vulnerabilities, reduce bias and support continuous improvement of resilience and safety.
“Reducing bias” is the heart of the control. The team that designed a system cannot evaluate it objectively, however competent it may be, not out of bad faith, but because it tests exactly the assumptions it used when building it. Independence can be achieved three ways: an internal structure separate from the one operating the system, a team from another institution, or an external evaluator. In local administration, the first two are rarely realistic.
An independent evaluation is also not an automated vulnerability scan. That covers technology. The control asks for evaluation of processes and practices: how access rights are granted and revoked, how changes are managed, how suppliers are verified, how continuity plans are tested.
Why it matters more in the public sector
A public institution has several traits that magnify the effect of missing external verification. Systems are old and interconnected, because they were added in successive layers through projects with different funding. Knowledge of them often sits with a single person. The suppliers who built them retain remote access, sometimes under contracts signed years ago. And the data administered belongs to citizens, who have no alternative to the service.
In those conditions, the absence of objective evaluation means nobody has ever verified whether the things assumed to work actually do. Backup restoration, revocation of former employees’ access, isolation of the operational network, all remain assumptions until first tested.
What the law says
Public authorities and institutions fall within the scope of GEO no. 155/2024, approved with amendments by Law no. 124/2025, under the conditions the ordinance sets. The core obligations are the same: notification for registration within 30 days under art. 18 para. (2), risk level assessment using the ENIRE@RO tool, the maturity self-assessment submitted annually to DNSC under art. 12 para. (4), and reporting of significant incidents within the deadlines of art. 15 para. (7): 24 hours, 72 hours, one month.
Art. 14 is the most uncomfortable for institutional leadership: management bodies approve the risk management measures, oversee their implementation and are liable for breaches, without prejudice to the rules on the liability of public institutions and civil servants. Para. (2) requires members of management to complete accredited professional training.
Through Order no. 3 of 27 November 2025, the DNSC director approved the rules on supervising, verifying and enforcing compliance with the ordinance, together with the risk-based prioritisation methodology. Institutions with a high risk level and no documentation reach the authority’s attention first.
What can be done on an institutional budget
The first independent evaluation does not have to cover everything. Choose the public service with the greatest impact on citizens and evaluate the chain supporting it: systems, data, access, suppliers, procedures and the recovery plan. The result is a report with findings, priorities and estimates, a document that serves simultaneously as evidence for DNSC, as justification for budget and as input for future procurement specifications.
The second step, cheaper than it looks, is writing the right of independent evaluation into contracts with system suppliers. Without that clause, verification of the most exposed component depends on the goodwill of the party being evaluated.
A third step, equally inexpensive, is setting a fixed interval for repeating the evaluation. A check carried out once, under deadline pressure, produces a report that ages within months as new systems appear and suppliers change. A check repeated at a known interval becomes a process, and processes are what an inspection looks for, not isolated documents.
Next steps
Scope is established first, because it determines the level of obligations. The CysNis platform walks through the criteria step by step, with references to the legal text.
The independent evaluation itself means a NIS2 compliance analysis with a remediation plan, built on evidence by NIS auditors accredited by DNSC, exactly the type of verification control ID.IM-03.7 calls for. Institutions without an internal owner for the process can cover the role through an outsourced NIS2 officer, including annual deadlines and the relationship with the authority. The full range of services is in the cybersecurity services register.
A 2.07 out of 5 on independent evaluation describes a situation repaired by a single administrative decision, not by an investment. The first evaluation is also the one that shows what the rest will cost.
Romania’s digital infrastructure sector scored 4.79 out of 5 on CyFun® control RC.CO-04.2, which requires the designation of a public relations officer to manage public communication during recovery from a cybersecurity incident. DNSC rated the result as advanced maturity in handling public communication.
It is a good score on a control most sectors treat as a formality. It is worth understanding why this sector takes it seriously, and where the protection it offers nonetheless ends.
What was measured
The result comes from the PNRR 184 project “Creating new cybersecurity competencies for society and the economy”, in which 1,599 public and private beneficiaries self-assessed on the SecureRO platform using the CyberFundamentals (CyFun®) framework of the Centre for Cybersecurity Belgium.
The control’s objective, as DNSC frames it, is for public communication during recovery to be handled professionally, accurately and in line with the organisation’s confidentiality and integrity standards. Designating a trained individual aims to maintain trust, protect reputation and meet legal and regulatory requirements.
Why digital infrastructure is ahead here
Hosting providers, data centres, network operators and domain registries share a particular trait: their incidents are visible instantly, from outside, without them announcing anything. An unavailable service shows up in client monitoring within minutes. Out of necessity, the sector learned to keep a status page, prepared messages and a person who publishes them.
The second explanation is contractual. Service level agreements usually contain communication obligations with their own deadlines, and clients invoke them. Commercial pressure produced maturity that other sectors had no reason to develop.
What the law requires beyond a spokesperson
Voluntary public communication and statutory reporting are two different flows, with different recipients, deadlines and content. Confusing them is the most frequent mistake of an incident’s first hours.
Art. 15 para. (7) of GEO no. 155/2024, approved by Law no. 124/2025, sets the calendar towards the national incident response team: an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours including an initial assessment of severity, impact and indicators of compromise where available, an interim report on request, and a final report within one month of the notification.
Separately, the ordinance requires service recipients to be informed about significant incidents and threats, together with the measures they can take. An incident is considered significant under art. 15 para. (6) if it has caused or may cause severe operational disruption or financial loss to the entity, or has affected or may affect other persons by causing considerable damage.
For a digital infrastructure provider, the second condition is met almost always: clients are themselves entities with their own reporting obligations. What you communicate, and how quickly, determines whether they can meet their own deadlines.
What a good communication setup is missing
A high score on designating the person does not cover the whole chain. The elements that turn out to be missing at the first real incident:
the trigger criterion, who decides the event has become public, and at what threshold;
texts prepared for the first two hours, when nothing is known yet but silence is already being interpreted;
the rule against confirming technical details that help an attacker still inside the network;
a communication channel independent of the affected infrastructure, including a status page hosted elsewhere;
coordination between the public message, client notification and the report to the authority, so the three do not contradict each other;
a backup person, for incidents that start at night or during leave.
The last point looks minor until it happens. Most major incidents begin outside working hours.
Reputation is lost on coherence, not on the incident
Clients of an infrastructure provider generally accept that incidents happen. What they do not accept are contradictory messages, minimisation followed by retraction, and a gap between what was said publicly and what ended up in the official report. A final report describing greater impact than was communicated to clients creates a problem separate from the incident itself.
For that reason, crisis communication and compliance cannot be prepared separately. The same facts, the same timeline, three formulations adapted to their audiences.
The one-hour exercise that shows the truth
Pick a plausible scenario, compromise of an administrative account affecting several clients, and convene, without prior warning, the people who would be involved. Time three things: how long it takes to decide the event is significant, who drafts the first public message, and who sends the early warning to the national response team.
In most organisations the first thing to stall is the decision. Nobody wants to declare a significant incident on incomplete information, and the 24-hour deadline runs from becoming aware, not from achieving clarity. A threshold written in advance and approved by management removes that hesitation from the equation.
The second thing to stall is coherence: the public message says “limited impact” while the report describes something else. Both leave the same organisation on the same day.
Next steps
Scope and level determine the volume of obligations. The CysNis platform walks through the criteria with references to the legal text.
For the notification procedure, the response scenarios and the documentation presented at an inspection, the supervision and control rules were approved by DNSC Order no. 3 of 27 November 2025, the next step is a NIS2 compliance analysis with a remediation plan, carried out by NIS auditors accredited by DNSC. Providers who do not want the administrative side landing on the operations team can cover the role through an outsourced NIS2 officer. The full range of services is in the cybersecurity services register.
A 4.79 out of 5 shows a sector that has learned to communicate under pressure. The rest of the road runs through synchronising that capability with the reporting obligations, two flows that start from the same facts and are not allowed to say different things.
Every screenshot is real, produced by running the instrument. The data in them is the illustrative example the calculator opens with, not any client’s data. The interface is in English.
What it is, in two sentences
The calculator is the digital instrument that accompanies the whitepaper “HumanAI and OrgAI: A Relational Framework for AI-Mediated Human and Organizational Capacity”. It turns the relationships defined there into an assessment record you complete for a concrete situation, one process, one team, one observation period, and which someone else can then verify, challenge and repeat.
A single HTML file. No installation, no account, no server, and no network request of any kind.
What it looks like when you open it
Figure 1. The opening screen. Action bar at the top, results strip beneath it, module navigation on the left.
It opens with a worked example, the illustrative case from the whitepaper, so you can see immediately how it behaves rather than facing an empty form. The “Reset example” button brings it back at any time.
Three zones, from top to bottom:
The action bar: the switch between working modes, resetting the example, importing a record, printing and copying the record.
The results strip: the four figures that summarise the assessment, the epistemic gap, propagation exposure, the organisational threshold and maturity. They stay visible whichever module is open.
The workspace: module navigation on the left, the active module on the right.
Navigation: eight modules and a diagnostic
Figure 2. The navigation column. The orange dot marks a module that has something to resolve.
The modules are a sequence rather than a menu. Module 02 consumes the result of 01. Module 06 depends on 03. The classification worksheet, module 00, can stop everything else if the situation is not a HumanAI case.
The orange dots next to modules are a status signal: an incomplete record, conditions declared without evidence, a single dimension marked relevant, active diagnostic flags. You do not have to enter every module to find out where you still owe something.
At the bottom sit the canonical sources with the DOIs of the whitepaper and of the instrument, plus the note explaining the relationship between the current version and section 11.5 of the whitepaper.
Two working modes
The distinction between exploring and assessing is explicit, because mixing the two is the usual way results are produced that look like an assessment without being one.
Figure 3. Exploration mode: results are marked illustrative, export is disabled.
In exploration mode you can move every value freely to see how the relationships behave. Evidence references are not required, and the record cannot be exported. Someone who only wants to understand the formula is not forced to complete a full record; in exchange, they cannot accidentally produce an artefact that looks like an assessment.
Figure 4. The action bar in exploration mode: the copy button is inactive.
Clear the checkbox and the instrument becomes demanding.
The record: what must be declared before any number
The whitepaper imposes a minimum reporting convention: any claim about HumanAI or OrgAI must identify the unit analysed, the task, the context, the AI configuration, the observation period, the validation method and the limit of responsibility. The instrument turns that into an operating condition.
Figure 5. Missing fields are highlighted. The counter shows 7 of 9 completed.Figure 6. The banner states how many fields are missing and that results remain provisional.
For as long as something is missing, export stays blocked and results are marked provisional. The modules keep calculating, so you can work, but you cannot produce a record that claims more than you know.
Figure 7. The complete record: the copy button becomes active.
The record also carries an identifier of its own. If you keep it when reassessing the same unit six months later, the two records form a comparable series instead of being two unrelated assessments.
Module 00: classification, before measurement
The first question is not “how much” but “what are we assessing”. The ten questions of the membership test establish whether the situation is a HumanAI case and whether it meets the conditions for OrgAI.
Figure 8. The ten questions. Each has a state and a field for the expected evidence.
Each question has three possible states, demonstrated, not satisfied and unknown, and a field in which you write the evidence, with a suggested example in place of the text (“catalogue, owners, provenance, validity”). The unknown state never counts as demonstrated.
One question alone stops the record: if you declare that the AI contribution is not material, the case is not HumanAI for that episode and the measurement modules no longer apply. Beneath the questions sits the list of cases the whitepaper excludes: an ignored suggestion, an automation with no AI component, several licences used independently.
Module 01: the gap between access and validation
This is where the central idea of the framework sits. You enter three numbers: how many tasks are in the declared set, for how many AI produced a usable answer, and for how many the accountable person could produce a verified justification.
Figure 9. Module 01 at 140 tasks: 126 with a usable answer, 95 with a verified justification.
You enter counts, not estimated percentages. The reason is disciplinary: “about 90%” cannot be verified, “126 out of 140” can. And only counts allow the confidence of the result to be computed.
Compare the two screenshots. In the first, 0.22 over 140 tasks, with an interval of [0.13 – 0.31], gap demonstrated. In the second, a larger gap, 0.25, but over 12 tasks:
Figure 10. The same module at 12 tasks: the interval crosses zero, the verdict becomes “not demonstrated”.
The interval is [-0.08 – 0.53], so it includes zero, and the verdict becomes “Not demonstrated”, not demonstrated at this task volume. A larger gap, poorly measured, supports less than a smaller one measured well. The instrument does not hide that difference behind the same two-decimal number.
The verdict is “not demonstrated”, not “no gap”. The distinction matters: absence of evidence is not evidence of absence, and the instrument’s wording respects that.
Below the result, a positive gap does not end with a number: the module displays the seven mitigation measures from the whitepaper as a selectable list, and what you tick there feeds the next module.
Module 02: what happens to an error in the flow
A gap in an isolated process is a local problem. In a process where the result is reused, it is amplified. The module models that amplification with two factors, the reuse rate and the criticality of the consequence, and computes two states: now, and after the controls you declare.
Figure 11. Current exposure and the target after controls, on the same scale.
The comparison is the argument, not the value on its own. The instrument shows the reduction as a percentage and flags separately the case in which the target would reduce exposure by cutting access rather than raising validation. Both lower the number, but they are entirely different decisions.
Module 03: the organisational architecture, with evidence
Six constitutive conditions: authorised knowledge, processes, roles and authority, governance, security, traceability. All six, otherwise the threshold is not demonstrated.
Figure 12. One criterion: the condition description, the evidence field, the evidence type and the state.
Each criterion has three fields instead of a checkbox: the state, an evidence reference and its type. The rule that changes the nature of the instrument is simple: a criterion marked “demonstrated” without an evidence reference appears as declared, undocumented, and the field is highlighted. It does not count towards the threshold.
The counter becomes a pair: “5/6 declared · 4/6 documented”. The second number is the one that counts, and the difference between them shows exactly the distance between what an organisation believes about itself and what it can show.
Below the six, separated by a line, sits the seventh component, validated learning. It is part of the architecture but not of the minimum threshold: it conditions the M5 level only. The distinction belongs to the framework, and the instrument shows it rather than hiding it.
Module 04: the profile, not the score
The AI contribution is assessed across seven dimensions at once: quality, time, error, calibration, autonomy, learning and risk exposure. It is material if it exceeds the declared threshold on at least one relevant dimension.
Figure 13. The profile. The dotted line is the baseline without AI, the solid line the assessed configuration, the grey band the threshold.
The chart shows what a single score would hide: in the illustrative example, quality and time improve, but autonomy and risk exposure worsen. The verdict is not compressed into a figure, it reads “material on 3 of 5 relevant dimensions”, with the difference and the direction for each.
Data is entered through one card per dimension:
Figure 14. The card for one dimension. The threshold is declared first, before the results.
The order of the fields is not accidental: the threshold appears before the two results, because the whitepaper requires it to be declared before the assessment, otherwise classification becomes opportunistic. If you change it after entering the results, the instrument records that in the record.
Figure 15. A dimension not marked relevant collapses to its title: it stays visible, but empty.
A dimension that cannot be measured credibly is not filled with zero and not reported as “n/a”. It is left out of the decision, and the card collapses.
Module 05: synergy, with declared thresholds
Synergy is not assumed and is not a maturity level. It is demonstrated: the configuration must exceed every relevant comparator on the same task, and every declared risk threshold must be satisfied.
Figure 16. The four risk gates. Each has a declared threshold and an observed value.
The gates are not checkboxes. Each requires a declared threshold and an observed value, and a gate without a declared threshold stays “undeclared” and blocks synergy just as a failed one does. You cannot demonstrate compliance with a threshold you never set.
The result names the comparator that binds the conclusion explicitly: “margin +0.06 over Human + AI (0.76)”. An anonymous margin would hide the decisive information: beating a person working alone and beating the best existing process are very different claims. The instrument also flags a weak comparator set.
Module 06: maturity, per domain
A level is assigned to a bounded domain and a process, not to an organisation. The whitepaper is explicit: the same company can be at M1 in one domain, M4 in another, and prohibit AI in a third.
Figure 17. Each domain has a name, a process, progression states and an “AI prohibited” option.
You add as many domains as you need. Each gets its own progression states and can inherit the threshold from module 03 or override it locally. A domain in which AI is prohibited is recorded as such and appears without a level, not as M0, because a governance decision is not a maturity shortfall.
Above it, a compact matrix shows every domain at once. Below it, the M0 to M5 levels with the minimum evidence and the limit of each: for M3, “connectivity does not demonstrate governance”; for M4, “learning may remain manual”; for M5, “adaptation does not demonstrate synergy”.
Module 07: what the architecture produces
The threshold says the architecture exists. This module says what it produces: nine dimensions of organisational assessment, each with its value and its evidence.
Figure 18. The organisational profile. Dimensions not marked relevant stay dimmed.
Two dimensions correlate with other modules, propagation with the exposure indicator from module 02, validation with V from module 01, and a large gap between them is itself a finding: it points to verification that is formal only.
The diagnostic
Across every module runs a detector that reads the configuration as a whole and looks for contradictions between what was declared in one place and what was measured in another.
Figure 19. The state with no flags. The wording avoids suggesting that an absence of signals means everything is fine.
Eight patterns from the whitepaper plus two internal consistency checks. When a flag is raised, it shows what triggered it, with the concrete values from the record, and the correction the framework prescribes. It can be annotated, and the annotation enters the record.
Flags do not change any result and do not add up into a risk indicator: that would reintroduce exactly the anti-pattern the instrument avoids in module 04.
What comes out of the instrument
The record
Figure 20. The record, visible in the page and copyable to the clipboard.
It contains the version of the instrument and of the whitepaper with their DOIs, every input, the computed values, the evidence references, the flags with their annotations, the record identifier, the generation timestamp and the limitation statement. It is copied to the clipboard rather than downloaded, because a page-initiated download does not work in every hosting context, and a button that does nothing is worse than no button.
Import
Figure 21. Import accepts a pasted record. Records from v1.0.0 and v1.1.0 are migrated.
A record can be reloaded. That makes periodic reassessment possible: you reopen the same record six months later, change the period, recount, and compare. Records from earlier versions are migrated, with an explicit note of what could not be recovered.
The printed record
Figure 22. The first page of the printed record: the header with the minimum reporting convention.
Printing produces the document an auditor or a client receives: a header with the nine fields of the record, the identifier, the state and the date, then each module with its values rendered as text rather than as a form. Roughly 17 pages for a complete record. The JSON record is not printed, so the document is not duplicated.
Properties
Property
State
Installation
None. One HTML file opened in any modern browser
Network requests
None. Fonts are embedded; it works on an isolated network
Browser persistence
None. No localStorage, no cookies
Account, database, analytics
None exist
Security policy
Restrictive CSP in the self-hosted variant, with connect-src “none”
Themes
Light, dark and the system theme
Verification
29 automated tests that extract the logic from the delivered file
The last two deserve a look. The instrument follows the system theme with no setting:
Figure 23. The same module in the dark theme.
And the tests do not hold a copy of the formulas: they extract them from the shipped file, between two markers in the code, so they cannot drift from it. A passing run is a statement about the file in your hand, not about a laboratory version.
Limits
Results are interpretive. They do not constitute empirical validation, certification, legal advice or a compliance determination.
The instrument verifies nothing: every value remains a claim by the assessor until it is tied to the evidence it points to.
The propagation indicator is conceptual; without local calibration it does not estimate real probabilities.
Thresholds are declared by the user, according to domain and risk. The instrument does not calibrate them.
The “unknown” state never counts as demonstrated, at any step.
The instrument cannot be the sole basis of a consequential decision.
The last two remain permanently visible in the interface, not only in the documentation.
Citation and licence
The framework: Angheluș, A. (2026). HumanAI and OrgAI: A Relational Framework for AI-Mediated Human and Organizational Capacity, v1.5. Zenodo. DOI 10.5281/zenodo.22295278
The instrument: Angheluș, A. (2026). HumanAI and OrgAI Framework Calculator, v1.2.0. Zenodo. DOI 10.5281/zenodo.22884721
What does the guided tour of the calculator cover?
It walks screen by screen through the eight modules of the HumanAI and OrgAI Framework Calculator, plus the diagnostic, with 23 real screenshots: what you see, what you enter and what you get at each step.
What is the difference between exploration mode and assessment mode?
In exploration mode you can move values freely to see how the relationships behave; evidence references are not required, results are marked illustrative and export is disabled. In assessment mode the record becomes mandatory, and export unlocks only when it is complete.
Why are counts entered instead of percentages?
Because “about 90 per cent” cannot be verified, while “126 out of 140” can. Only counts allow the confidence interval that shows whether the gap is demonstrated at the assessed task volume.
What happens if a condition is marked demonstrated without evidence?
It appears as declared, undocumented, the field is highlighted, and it does not count towards the constitutive threshold. The counter shows two numbers, declared and documented, and the difference between them shows the distance between what an organisation believes about itself and what it can show.
What does the instrument produce at the end?
Three things from the same record: the on-screen assessment, a printed record of about 17 pages with the minimum reporting convention in its header, and a JSON record containing the inputs, computed values, evidence references and the limitation statement.
Can an assessment be repeated six months later?
Yes. The JSON record is copied, archived and re-imported, including from earlier versions. If you keep the record identifier, the two assessments form a comparable series instead of two unrelated ones.
Romania’s financial market infrastructure scored 4.83 out of 5 on CyFun® control PR.DS-11.1, the strongest result in the entire DNSC series. The control requires business-critical data to be backed up and stored on a system separate from the one holding the original data, precisely so that it survives loss, system failure and ransomware.
The score is no surprise. This is the only sector in the series where separate backups were already a regulatory requirement rather than a good practice. The useful question is not how the sector reached 4.83, but what remains to be demonstrated beyond this control.
What was measured
The data comes from the PNRR 184 project “Creating new cybersecurity competencies for society and the economy”, under which 1,599 public and private beneficiaries self-assessed on the SecureRO platform using the CyberFundamentals (CyFun®) framework of the Centre for Cybersecurity Belgium. DNSC’s conclusion: the high level indicates a good capacity to protect critical data through secure, separate backups, supporting operational resilience and rapid recovery.
The difference between holding copies and being able to return
Control PR.DS-11.1 verifies that copies exist and are separated. It does not verify restoration. That distinction decides, in real incidents, between an outage of hours and one of days. The questions a 4.83 leaves open:
when the last full restoration was performed on a separate system, timed and recorded;
how long the service itself takes to return, not how long files take to copy, including rebuilding dependencies and verifying data integrity;
whether a copy exists that is unreachable from the network and immutable, surviving an attacker holding administrative rights;
whether the encryption keys for the copies are held somewhere other than the protected system;
whether the person able to run the restoration is available outside working hours, and whether the procedure works without them;
whether suppliers hosting parts of the service keep verified copies of their own, with a contractual duty to prove it.
A documented restoration exercise, run at least annually, turns a declared score into evidence. Without it, the figure remains an intention.
Which legal regime actually applies
Here the financial sector has a particularity the others do not. The NIS2 Directive provides that where a sector-specific EU act imposes at least equivalent requirements, that act applies instead of the general regime. For financial entities, that act is Regulation (EU) 2022/2554 on digital operational resilience, applicable since January 2025, covering ICT risk management, incident reporting, resilience testing and oversight of critical third-party providers.
The practical consequence is that an entity in the financial market infrastructure should not assume automatically that the GEO no. 155/2024 regime applies to it in full, nor assume the opposite. The perimeter is established by entity type and by the activities carried out, and groups with mixed activities may sit under both regimes simultaneously for different components. Establishing the perimeter correctly is the first deliverable, not a formality.
Where the general regime does apply, the administrative obligations are the familiar ones: notification for registration within 30 days under art. 18 para. (2), risk level assessment using ENIRE@RO, the annual maturity self-assessment under art. 12 para. (4), and the incident reporting deadlines of art. 15 para. (7): 24 hours, 72 hours, one month.
Where the advantage is lost
Organisations with high technical maturity rarely fail on the technical side. They fail on demonstration: the policy approved by the management body is missing or outdated, the responsibility matrix no longer matches the org chart, the incident register contains only the large events, and the evidence of accredited management training required by art. 14 para. (2) does not exist.
Through Order no. 3 of 27 November 2025, the DNSC director approved the rules on supervising, verifying and enforcing compliance with the ordinance, together with the risk-based prioritisation methodology. Verification starts from documents. An impeccable backup system, without the documentation describing it and the record of its tests, presents badly in exactly the place where it should be strongest.
The exercise that validates the score
A serious restoration test is not announced a month in advance and is not run on a conveniently chosen file. Pick a real service, assume the original system no longer exists, and time the whole path: identifying the correct copy, obtaining the keys, rebuilding the environment, verifying data integrity, restarting the service and confirming that the data is what was expected, not merely present.
The result is compared against the declared recovery time and maximum data loss objectives. The gap between the two is the only honest measure of resilience, and recording it, with date, participants, problems encountered and remediation actions, is precisely the evidence an inspection asks for.
A second, shorter exercise concerns third parties: ask a supplier hosting part of the service for evidence of its last restoration test. The answer, or the absence of one, says more about real resilience than any questionnaire completed at contract signature.
Next steps
The first step is delimitation: what applies to the entity and at what level. The CysNis platform walks through the qualifying criteria with references to the legal text.
For evidence-based verification of the measures and the documentation presented at an inspection, including restoration scenarios, the next step is a NIS2 compliance analysis with a remediation plan, carried out by NIS auditors accredited by DNSC. Entities that prefer not to load their internal team with compliance work can cover the role through an outsourced NIS2 officer. The full range of services is in the cybersecurity services register.
A 4.83 out of 5 is a real advantage. It turns into demonstrable compliance only when it comes with proof: recorded tests, approved policies, assigned roles and a clear delimitation of the applicable regime.
Romanian energy sector entities scored 2.15 out of 5 on CyFun® control GV.SC-07.2, which requires a documented list of all critical suppliers, vendors and partners who could be involved in a major incident, established, kept up to date and available both online and offline. DNSC rated the result as low.
Two words in the control text explain both the low score and why it matters: “updated” and “offline”. The first is missed for lack of process. The second is missed because nobody pictures the day the systems do not come back up.
The figure in context
The measurement comes from the PNRR 184 project “Creating new cybersecurity competencies for society and the economy”, in which 1,599 public and private beneficiaries assessed their own maturity on the SecureRO platform using the CyberFundamentals (CyFun®) framework of the Centre for Cybersecurity Belgium. DNSC’s conclusion for energy: records and updates concerning critical suppliers and partners need strengthening, to support a rapid and coordinated response to major incidents.
The list is not a supplier table
Every energy company has a supplier list, in its procurement system. The control asks for something else: a record of those third parties whose unavailability or compromise would affect the service, with the information needed to reach them and work with them mid-incident. The difference shows up in the columns:
what service or equipment they supply and what stops without it;
the technical contact, not the commercial one, with a direct number and a named backup;
actual availability hours and the contractual response time;
the type of access they hold in your infrastructure, remote, permanent, through a dedicated account or a shared one;
their own notification obligations in case of an incident on their side, and the deadline for informing you;
the alternative, if one exists, and the time needed to switch to it.
In an energy company, the list must also cover industrial control system integrators, equipment manufacturers with remote maintenance, communications providers carrying telemetry and the data centre operators hosting supporting systems. These are, as a rule, the ones missing from existing records.
Why “offline” is not a formality
The scenario in which the list is most needed is exactly the scenario in which it cannot be reached: the network has been isolated as a precaution, the directory service is compromised, e-mail is down, work phones are locked because authentication runs through the affected system. A record living only on the intranet or in a cloud service tied to company accounts becomes unusable in precisely the hour it mattered.
The offline version means a printed copy or separate media, kept in known locations, under confidentiality controls, the list contains information that, in the wrong hands, describes the organisation’s weak points exactly. The control says explicitly that the record is kept “with due regard to confidentiality and security”.
What the law requires beyond the control
Art. 11 para. (1) of GEO no. 155/2024, approved by Law no. 124/2025, requires essential and important entities to take proportionate and appropriate measures to identify, assess and manage risks affecting the networks and information systems they use, and to reduce the effects of incidents on the recipients of their services and on other services. That final phrase covers propagation through the supply chain directly.
In energy, this effect has a dimension other sectors lack: interdependence. An incident at a supplier shared by several operators does not produce nine separate problems but one, simultaneous, with immediate public pressure. The ordinance’s preamble cites exactly such a case from another sector, the first quarter of 2024, when 26 hospitals were affected through the same managed service provider.
To this are added the reporting deadlines of art. 15 para. (7): early warning within 24 hours, incident notification within 72 hours, final report within one month. When the cause sits with a third party, the first hours go into finding out whose and what, or they do not, if the record exists.
A simple test
Pick a critical supplier and ask, without warning, for three pieces of information: the name of the technical contact, the contractual response time and the type of access they hold in your infrastructure. If the answer takes more than an hour and involves opening the procurement system, control GV.SC-07.2 is not met, however good the self-assessment looks.
Second test: ask who maintains the list and when it was last reviewed. A record without a designated owner and a review interval is a document, not a control.
Next steps
The volume of measures depends on the risk level produced by the ENIRE@RO assessment and validated by DNSC. Before anything else, scope is established: the CysNis platform walks through the criteria with references to the legal text.
For the critical supplier record, the contractual security clauses and the documentation required at an inspection, the next step is a NIS2 compliance analysis with a remediation plan, carried out by NIS auditors accredited by DNSC. Operators without a dedicated internal role can cover it through an outsourced NIS2 officer, including the annual self-assessment required by art. 12 para. (4). The full range of services is in the cybersecurity services register.
There is one more effect operators underestimate: the critical supplier list is also a negotiating instrument. Once you know exactly what stops without each third party and how quickly, the conversation about security clauses, notification deadlines and audit rights is held with arguments rather than boilerplate. Suppliers who refuse those clauses identify themselves, and that, in itself, is risk information.
A group of employees using the same AI model does not constitute organizational capacity. The difference between the two is not one of scale but of architecture, and the HumanAI / OrgAI framework makes it visible, measurable and auditable.
Alexandru Angheluș · September 2026 · Based on “HumanAI and OrgAI: A Relational Framework for AI-Mediated Human and Organizational Capacity”, version 1.5, DOI 10.5281/zenodo.22295278, licensed CC BY-ND 4.0.
The question a licence count cannot answer
AI adoption is usually reported through product names, licence counts or automation volumes. Those figures show that the technology is available. They do not show which capacity has been created, where knowledge resides, how results are validated, or who holds authority.
The same interface may support a competent professional, induce uncalibrated dependence, or propagate an error throughout an organization. The central confusion is between individual AI use and organizational capacity. Without authorized sources, roles, validation, traceability, security and controlled memory, the result is aggregated use rather than governed capacity.
For a security or compliance officer the consequence is immediate and practical: in a supervisory enquiry, an audit or a risk assessment, a licence count is not an answer. It does not say which sources produced the conclusion, who verified it, who is accountable for it, or how it can be reconstructed.
Two constructs, two units of analysis
HumanAI
HumanAI denotes a situated person–AI–task–context configuration in which an AI system materially changes a person’s performance, judgment, learning or vulnerability, while the human role and decision authority remain identifiable.
The contribution may be positive, neutral or negative. Overreliance, error or skill erosion do not remove a case from the category, they describe its outcome profile. The configuration is episodic when it concerns a bounded task, and becomes stable when repeated use changes the person’s practice, trust, competence, autonomy or validation behaviour.
OrgAI
OrgAI denotes the organizational socio-technical configuration in which HumanAI episodes, AI systems, authorized institutional knowledge, roles, workflows, validation, traceability, security and control jointly mobilize a distributed capacity that cannot be attributed to a single user or model.
OrgAI is not a product, a model, an agent or a document repository. It is a property of the organizational configuration.
Reading rule: HumanAI and OrgAI describe configurations, not outcomes. A configuration may produce good, poor or unsafe results. Category membership and outcome quality are separate judgments.
Excluded cases
An ignored AI suggestion with no material effect does not constitute HumanAI in that episode.
A deterministic automation without an AI component is not included merely because it is complex.
Multiple independently used AI licences do not constitute OrgAI.
A chatbot connected to unverified documents does not demonstrate authorized organizational knowledge.
A system-only decision without identifiable authority and accountability does not satisfy the governed framework.
The membership test
Classification is not established by declaration but through seven questions applied to a bounded configuration.
Test
HumanAI
OrgAI
Identifiable unit
person, system, task and context
organizational process, actors, systems and knowledge
AI contribution
materially changes execution or judgment
is integrated into institutional capacity
Authority
human role and decision can be attributed
roles, approvals and escalations are defined
Knowledge
relevant sources can be delimited
sources are authorized, versioned and owned
Validation
the person can verify in proportion to risk
validation is independent and institutionalized
Traceability
the episode can be reconstructed
the workflow and decision can be audited
Learning
effects on the person can be tracked
validated feedback updates memory in a controlled manner
Table 1. Membership and boundary criteria.
The constitutive threshold: why OrgAI is not the sum of episodes
The relationship between the two levels is one of conditional integration. Individual episodes provide local contributions. Organizational architecture selects, authorizes, coordinates, validates and retains only those contributions that can become part of institutional capacity.
OrgAI ≠ Σ HumanAIᵢ
Iorg = 1[Korg ∧ P ∧ R ∧ G ∧ S ∧ T]
The Iorg indicator expresses the minimum conceptual threshold: Korg is authorized institutional knowledge, P are processes and control points, R are roles and accountability, G is governance with validation, contestability and audit, S is security and data protection, and T is configuration and decision traceability.
If any of these components is missing, the configuration may represent connected or aggregated AI use, but it does not demonstrate governed OrgAI. Controlled learning is required for the cumulative form, not for the minimum threshold.
The transformation mechanism
An actor performs a task within a delimited HumanAI configuration.
The output is accompanied by sources, configuration, interventions and confidence level.
A competent role validates or rejects the contribution in proportion to risk.
The decision is attributed and integrated into a controlled organizational process.
Accepted conclusions may update memory only through a separate adjudication workflow.
Outcomes and errors are monitored, and access or rules can be withdrawn or corrected.
Epistemic decoupling: the risk that appears in no control catalogue
Epistemic decoupling is the gap between the range of claims, interpretations or options that AI makes accessible and the demonstrated capacity of the accountable actor to validate them.
Δepi(T; X, t) = A(T; X, t) − V(T; X, t)
Across a declared task set T, A is the proportion of tasks for which the system provides a usable response, and V is the proportion for which the accountable actor can produce a verified justification. The difference is calculated within the same domain and ranges from −1 to 1. A high positive value shows that access has outpaced validation.
The distinction matters for governance because it separates three questions that practice routinely conflates: what the system can generate or retrieve, what the competent actor can validate, and who is authorized to decide or execute. Access to a claim does not automatically produce justified knowledge, and technical validation does not automatically confer decision authority.
Observable signals
Responses are accepted faster than their sources can be checked.
Citations, explanations or calculations cannot be reproduced independently.
The same output is reused across processes without reassessing context.
Reported confidence rises while error-detection rates decline.
Organizational memory is updated with unadjudicated outputs.
Authority is formally assigned to a person, but practical constraints make contestation impossible.
Mitigation measures
Limit the domain and state the unknowns.
Cite and verify primary sources.
Require independent validation for high-impact outputs.
Separate generation from approval and execution.
Test trust calibration and error detection.
Control reuse and memory updates.
Preserve the right to contest, to stop, and to return to the unassisted process.
Propagation: how a local error becomes systemic risk
Ωprop = max(0, Δepi) × ρ × κ
ρ is the rate at which an output is reused or diffused, and κ is consequence criticality. Without local calibration the formula does not estimate real-world probabilities. Its role is different: it makes visible why a small error, reused frequently in a critical process, may become a major organizational risk, and why reducing decoupling has a multiplicative rather than linear effect.
Five use scenarios
7.1. Analysis and research
An analyst uses AI to identify themes, synthesize documents and formulate hypotheses. The configuration is HumanAI when the intervention materially changes the scope or speed of analysis. The corpus must be bounded, citations verified, inferences labelled as such, and the analyst’s decision retained.
The configuration becomes part of OrgAI only when sources, rights, methodology, validation and reuse are integrated into an institutional process. The dominant risk is that a plausible but unverified synthesis becomes organizational fact.
7.2. Creation, communication and marketing
AI can expand the space of concepts, audiences and creative variants. Each creator–model–brief relationship is HumanAI. OrgAI requires authorized data, asset rights, approval criteria, versions, performance evaluation and controlled feedback. Abundance does not demonstrate relevance and may produce narrative convergence or homogenized expression.
7.3. Cybersecurity
A security operations analyst uses AI to correlate alerts, formulate hypotheses and propose investigative steps. HumanAI describes the analyst–model–telemetry episode. OrgAI emerges when identities, data classification, chain of custody, sources, approval roles, logging and response procedures are integrated.
Automatic execution of proposed commands, contamination of memory with unverified indicators, or exposure of investigative data are cases in which speed has overtaken control. Destructive operations require explicit confirmation, separation of duties and rollback capability.
7.4. Compliance and evidence evaluation
AI can map requirements to policies, controls and evidence. At HumanAI level the assessor receives suggestions and syntheses. At OrgAI level the organization manages control owners, periods, versions, exceptions, approvals and evidence lineage. The existence of a document does not establish control operation, and an automated score does not demonstrate compliance.
7.5. Organizational memory and strategic decision-making
An organization connects AI to policies, projects, lessons learned and prior decisions. Retrieval is useful only if sources have status, version, owner and scope. The cumulative form emerges when validated conclusions update memory without self-confirmation and obsolete information can be withdrawn. Strategic decisions remain attributable to authorized roles.
Scenario
HumanAI unit
Threshold for OrgAI
Dominant risk
Analysis
analyst, model, corpus, question
institutional sources and validation
unverified citations and conclusions
Creation
creator, model, brief, audience
rights, approval, controlled feedback
convergence and unauthorized use
Security
analyst, telemetry, hypothesis
chain of custody, roles, audit
incorrect execution and contamination
Compliance
assessor, requirement, evidence
owners, periods, adjudication
apparent compliance
Memory
user, question, internal sources
validity and validated learning
propagation of obsolete information
Table 2. Scenario summary.
Demonstrative case study: assessing an incident
Status: this case is hypothetical and explanatory. The values are illustrative, not empirical findings, and do not represent the performance of any real product or organization.
An organization must assess a potential cyber incident. Inputs include alerts, logs, internal procedures, threat intelligence and prior reports. A wrong conclusion may interrupt services, destroy evidence, or cause a real incident to be missed.
The HumanAI episode
The analyst asks the model for a timeline, hypotheses and validation steps. AI reduces triage time and expands the hypothesis space, so its contribution is material. The analyst verifies events in primary sources, marks inferred claims, and retains authority over classification. The configuration remains HumanAI even when some suggestions are rejected.
Aggregated use that is not OrgAI
Several analysts use the same model independently and copy its answers into tickets. There is no source catalogue, configuration version, adjudication role or rule for updating memory. This is aggregated AI use. Activity volume does not compensate for missing architecture.
The governed OrgAI configuration
Sources are classified, owned and filtered before retrieval according to analyst identity.
Retrieved content is treated as untrusted data and cannot introduce executable instructions.
The model produces hypotheses linked to primary events and states missing data.
A separate validator adjudicates critical claims, while the decision-maker approves the operational response.
Commands are denied by default and require confirmation, logging and target-domain validation.
Only adjudicated conclusions can update case memory; rejected indicators are withdrawn and remain auditable.
Illustrative decoupling calculation
Initial: A = 0.92; V = 0.68; Δepi = 0.24
After controls: A = 0.92; V = 0.88; Δepi = 0.04
Access has not been reduced, but validation capacity has increased through primary sources, adjudication and traceability. If the reuse rate ρ is 0.80 and criticality κ is 0.90, the conceptual propagation indicator falls from 0.173 to 0.029. The values only explain the relationship among variables.
The practical observation for a security officer is that the fix was not to restrict access to the tool, the usual reflex, but to raise validation capacity. Restricting access would have lowered A, and with it the utility, without addressing the underlying problem.
Maturity: six states, none of them mandatory
The maturity model describes observable states of integration, not an obligation to reach the highest level. For some tasks, a managed HumanAI configuration is more appropriate than the cumulative form. A level is assigned to a bounded domain and process, not to an organization in the abstract.
Level
Description
Minimum evidence
Boundary
M0 Exploratory
occasional use without stable practice
inventory of uses or experiment
does not demonstrate stable HumanAI
M1 Episodic HumanAI
AI materially changes bounded tasks
artifacts and task comparator
the effect is not institutionalized
M2 Managed HumanAI
practice is repeatable and governed locally
guidance, measurement, validation, owner
more users do not imply OrgAI
M3 Connected OrgAI
models access organizational sources and workflows
The status of synergy: “Synergistic OrgAI” is an outcome label, not an M6 level. It applies only to a configuration and task for which comparators and risk thresholds have been evaluated explicitly.
An organization may operate at M1 in one domain, at M4 in another, and prohibit AI use in a third. Applying a single level to a whole organization is itself an assessment error.
Governance: roles, incompatible shortcuts and threats
Governance is not a separate chapter of the framework but the element that constitutes the category. Removing authority, validation or traceability does not weaken an OrgAI configuration, it moves it out of the category.
Role
Primary responsibility
Incompatible shortcut
Process owner
defines purpose, scope and acceptance criteria
delegating purpose to the vendor or model
Knowledge owner
authorizes sources, validity and withdrawal
treating every accessible document as authoritative
User or operator
performs the task and records interventions
copying output without review
Validator
tests claims against criteria and evidence
validating one’s own high-impact output without controls
Decision-maker
accepts consequences and authorizes action
assigning responsibility to AI
Security and privacy
controls access, isolation, retention and incidents
relying solely on vendor terms
Audit or oversight
tests reconstruction, exceptions and effectiveness
treating policy existence as operating evidence
Table 4. Roles and separation of duties.
Threat
Mechanism
Minimum controls
Prompt injection
retrieved content manipulates model behaviour
separate instructions from data, sanitize, constrain tools, test adversarially
identity propagation, least privilege, target checks, deny by default
Hallucinated authority
plausible output is treated as an approved decision
source verification, status labels, validator and decision-maker
Memory contamination
unverified feedback becomes institutional truth
staging, adjudication, provenance, rollback and withdrawal
Automation bias
human review becomes formal rather than effective
error-detection tests, time allocation, independent evidence, contestability
Common-mode failure
one defect propagates across downstream uses
diverse sources, dependency mapping, monitoring and kill switch
Table 5. Threat model and minimum controls.
What the framework does not demonstrate
Much of the framework’s practical value lies in what it refuses to confirm.
Anti-pattern
Why it is incorrect
Correction
AI as authority
output is treated as the decision
retain a decision-maker, validation and contestability
Nominal human in the loop
a person approves without time, competence or evidence access
measure actual detection and intervention capacity
OrgAI by licence count
account numbers are confused with integration
evaluate sources, roles, workflows and controls
Memory without adjudication
all feedback becomes institutional truth
separate raw feedback from approved updates
Single score
trade-offs and risks are hidden
report dimensional profiles and thresholds
Convenient comparator
gain is measured against a weak baseline
include the best realistically available process
Irreversible automation
a suggestion triggers action without control
deny by default, confirm, log and support rollback
Compliance label
the concept is treated as legal or audit evidence
demonstrate obligations and control effectiveness separately
Table 6. Anti-patterns and corrections.
Six explicit clarifications follow: HumanAI does not mean that a person becomes AI or that a system acquires human status; HumanAI is not synonymous with success; OrgAI is not the name of a model or a commercial package; access to an internal corpus does not demonstrate provenance, validation or authority; automation does not transfer accountability to AI; and using the term OrgAI does not make an organization mature, safe or compliant.
The regulatory boundary
The framework supports analysis and control design but does not establish legal compliance. Systems with material effects on rights, safety, employment, finance, health, security or public services require domain-specific legal assessment, data protection analysis, competent human oversight, contestability, separation of duties and evidence preservation. The HumanAI or OrgAI labels do not replace applicable obligations.
From framework to implementation
Stage
Activity
Exit criterion
1. Delimitation
select process, tasks and consequences
approved scope, owner and exclusions
2. Baseline
measure the process without the new configuration
comparator, thresholds and task set
3. Controlled HumanAI
pilot with users, rules and validation
documented material contribution and risk profile
4. Knowledge
catalogue and authorize sources
owners, validity, access and withdrawal
5. OrgAI threshold
integrate roles, workflow, audit and security
Iorg test satisfied with evidence
6. Operational pilot
test normal, boundary, adversarial and unavailable states
approved acceptance criteria and residual risk
7. Controlled learning
introduce adjudicated feedback and withdrawal
updatable, auditable, reversible memory
8. Monitoring
track profiles, changes and incidents
periodic review and stop conditions
Table 7. Implementation pathway.
Stop conditions
Implementation must stop or return to the previous state when data exposure, loss of decision attribution, degradation in error detection, unauthorized access, memory contamination, inability to reproduce critical results, or an unvalidated configuration change occurs.
The computational companion
The HumanAI and OrgAI Framework Calculator is the separately versioned digital companion to the framework. It operationalizes six relationships defined in the whitepaper: epistemic decoupling, propagation exposure, the constitutive OrgAI threshold, material contribution, synergy and maturity classification.
It should be used only after defining the unit of analysis, task, context, observation period, comparator, materiality threshold and evidence standard. Every organizational condition must be supported by evidence, and an unknown state never counts as demonstrated. The local release calculates in the browser and can export a JSON assessment for reproducibility and audit. Exported values remain user-entered claims until linked to evidence; results are not empirical validation, certification, legal advice or a compliance determination.
The framework’s value does not depend on who first used the HumanAI notation, nor on the absolute absence of a similar expression for OrgAI. It depends on definitional clarity, on the separation of constructs from outcomes, on the relational model, and on the ability to make accountability, validation, authority and risk visible.
In practice, the decisive question is not whether an organization uses AI. It is whether the organization can demonstrate which capacity it has created, in which domain, from which sources, through which roles, with what validation, and within which limits. HumanAI makes the person’s configuration visible. OrgAI makes visible the institutional architecture that can turn it into controlled collective capacity.
For security and compliance professionals the operational consequence is that assessment applies to a bounded configuration rather than to a model, and that validation, not access, remains the central problem between the availability of technology and real capacity.
Source
Angheluș, A. (2026). HumanAI and OrgAI: A Relational Framework for AI-Mediated Human and Organizational Capacity. Version 1.5, 4 September 2026. DOI: 10.5281/zenodo.22295278. Licensed under Creative Commons Attribution-NoDerivatives 4.0 International.
HumanAI, also written HumanAI, denotes a situated person, AI system, task and context configuration in which the system materially changes a person’s performance, judgement, learning or vulnerability, while the human role and decision authority remain identifiable.
What is OrgAI?
OrgAI denotes the organisational socio-technical configuration in which HumanAI episodes, AI systems, authorised institutional knowledge, roles, workflows, validation, traceability and security together mobilise a distributed capacity. It is not a product, a model or a document store, but a property of the configuration.
What is the difference between HumanAI and OrgAI?
It is not a difference of scale but of architecture. OrgAI is not the sum of HumanAI episodes. The constitutive threshold requires, cumulatively, authorised knowledge, processes, roles and accountability, governance with validation and contestability, security and traceability. If any is missing, the result is aggregated use, not governed capacity.
What is epistemic decoupling?
It is the distance between the range of claims AI makes accessible and the demonstrated capacity of the accountable actor to validate them, computed as the difference between the proportion of tasks with a usable answer and the proportion with a verified justification, over the same declared task set.
Do multiple AI licences amount to OrgAI?
No. Multiple licences used independently are aggregated use. A seat count demonstrates no authorised sources, roles, independent validation, traceability or controlled memory, and under audit a licence count answers no supervisory question.
What maturity levels does the framework define?
Six observable states, from M0 explorer to M5 cumulative OrgAI. A level is assigned to a bounded domain and process, not to an organisation in the abstract. The same organisation can be at M1 in one domain, M4 in another, and prohibit AI in a third.
Does the framework establish legal compliance?
No. It supports analysis and control design, but does not replace domain-specific legal assessment, data protection analysis, competent human oversight or separation of duties. The HumanAI and OrgAI labels do not replace applicable obligations.
Romania’s postal and courier sector scored 2.00 out of 5 on CyFun® control GV.OC-03.2, the weakest result in the entire DNSC series. The control requires legal, regulatory and contractual obligations relating to information security to be managed continuously, so that they remain accurate, up to date and effectively applied.
Put more directly: the control measures whether the organisation knows what the law requires of it and keeps pace with changes. A 2.00 out of 5 on that question, in a sector under new regulation, describes the problem precisely.
What was measured
The data comes from the PNRR 184 project “Creating new cybersecurity competencies for society and the economy”, in which 1,599 public and private beneficiaries self-assessed on the SecureRO platform using the CyberFundamentals (CyFun®) framework of the Centre for Cybersecurity Belgium. DNSC’s conclusion for the postal sector points to the need to strengthen processes for monitoring and continuously updating legal and regulatory requirements.
How many obligations a postal operator actually carries
On the cybersecurity side alone, the applicable framework has changed four times in two years:
GEO no. 155/2024, published on 30 December 2024, replacing the regime of Law no. 362/2018;
Law no. 124/2025, of 7 July 2025, approving the ordinance with amendments and additions;
DNSC director’s Order no. 1/2025, on the requirements of the registration notification process;
Order no. 2/2025, with the criteria and thresholds for determining the degree of service disruption and the methodology for assessing entity risk level;
Order no. 3 of 27 November 2025, with the supervision, verification and control rules and the risk-based prioritisation methodology.
Added to these are the instruments DNSC publishes and updates, NIS2@RO for notification, ENIRE@RO for risk level assessment, the maturity self-assessment tools for the three levels, each with its own version number. Anyone not tracking the authority’s pages systematically is working with outdated forms.
What is lost when nobody tracks
The consequences are not theoretical. Art. 18 para. (2) requires notification to DNSC for registration within 30 days of the moment the provisions become applicable to the entity. Para. (8) of the same article requires changes to registration data to be communicated within two weeks for some categories and three months for others. A change of registered office or contact person, left unreported, is a breach in itself.
Art. 12 para. (4) adds an obligation that repeats year after year: essential and important entities carry out and submit to DNSC an annual self-assessment of the maturity of their risk management measures. It is the kind of deadline that is missed quietly, because nobody has it in a calendar.
The contractual side of the control matters just as much. A courier operator has contracts with e-commerce platforms, last-mile subcontractors and parcel tracking providers. The security clauses in those contracts age: they remain written against the old regime, contain no notification obligations matching current deadlines and grant no right of verification.
The sector with the greatest public exposure
Postal and courier services have a particular feature: their names are used intensively in fraud campaigns even when their own systems have not been touched. Messages about held parcels or unpaid delivery fees circulate constantly, and recipients attribute them to the operator. The obligation to inform service recipients about significant threats does not disappear because the attack occurred outside the operator’s own infrastructure.
The obligations register therefore has to include the communication side too: who decides, within what time, through which channels and with what message. Improvisation here is visible to the public.
The three deadlines most often missed
First: the 30 days for registration notification, counted from the moment the provisions become applicable, including when they become applicable following growth in turnover or headcount.
Second: the two weeks for reporting changes to core registration data. A change of contact person is an HR operation for the organisation and a legal obligation towards DNSC, and the two do not talk to each other unless someone connects them.
Third: the annual maturity self-assessment. Being annual, it occurs to nobody at the right moment. In an obligations register with deadlines and an owner, it does.
What a working process looks like
An obligations register, kept as a living document, covers most of this control. Each row holds the legal act or contract, the applicable article, the obligation in the organisation’s own words, the deadline, the internal owner and the evidence that demonstrates fulfilment. The register is reviewed at fixed intervals and after every legislative change, and the outcome of each review reaches the management meeting.
Such a register needs no expensive tooling. It needs a designated owner with allocated time and a duty to monitor the sources, which, in practice, is exactly the missing part. Penalties under the ordinance reach EUR 7,000,000 or 1.4% of net turnover for important entities and EUR 10,000,000 or 2% for essential ones, whichever is higher.
Where to start
The first check is scope and level. The CysNis platform walks through the criteria step by step and separates legal obligations from technical recommendations.
To build the obligations register, the deadline calendar and the documentation presented at an inspection, the next step is a NIS2 compliance analysis with a remediation plan, carried out by NIS auditors accredited by DNSC. Where nobody’s job description includes tracking legislation, the practical answer is an outsourced NIS2 officer who keeps the calendar and the relationship with the authority. The remaining services are in the cybersecurity services register.
A 2.00 out of 5 on knowing your own obligations is not a technical problem. It is a problem of assigned responsibility: as long as tracking the legal framework appears in nobody’s job description, it belongs to everyone, which means to no one. The first thing that changes is not a system but a line in a job description.
Version 1.2.0 of the HumanAI and OrgAI Framework Calculator is publicly available at no cost. It is a single HTML file that runs entirely in the browser: no installation, no account, and no network request of any kind. It opens unchanged on a machine with no internet connection.
The instrument accompanies the whitepaper “HumanAI and OrgAI: A Relational Framework for AI-Mediated Human and Organizational Capacity”, and turns the relationships defined there into an assessment record you complete for a concrete situation: one process, one team, one observation period.
In short
What it is: the digital instrument that operationalises the HumanAI and OrgAI framework, also written HumanAI and OrgAI.
How it runs: one HTML file, in the browser, no installation, no account, no network requests, no localStorage.
What it contains: eight modules and an anti-pattern detector.
What it produces: an on-screen assessment, a printed record of about 17 pages, and a re-importable JSON record.
Licence: code under MIT, conceptual framework under CC BY-ND 4.0.
Every organisation that has introduced AI into a process eventually faces the same question: does it work?
The usual answer rests on two observations: people are visibly faster, and nobody has complained. Both may be true. Neither answers the question.
The difficulty is that “does it work” conflates things that must be measured separately: what the system can produce, what the accountable person can validate, who is authorised to decide, and what happens to a wrong conclusion once it enters the workflow. The framework separates them. The calculator makes them computable.
The central distinction is epistemic decoupling: the gap between the range of answers AI makes accessible and the demonstrated capacity of the accountable actor to validate them. When access grows faster than validation, an organisation produces claims it cannot support, and then reuses them.
What it looks like
Figure 1. The opening screen. The calculator starts from a worked example rather than an empty form.
Eight modules and a diagnostic panel. The modules are a sequence rather than a menu: module 02 consumes the result of 01, module 06 depends on 03, and the classification worksheet can stop everything else if the situation does not belong to the construct.
Module
What it establishes
00. Classification
Whether the situation is a HumanAI case, through a ten-question membership test
01. Epistemic decoupling
The gap between access and validation, with a confidence interval
02. Propagation exposure
How an unvalidated error is amplified by reuse, now and after declared controls
03. OrgAI threshold
Whether the six constitutive conditions are demonstrated or merely declared
04. Contribution profile
On which dimensions AI changes the outcome, in which direction, and what is lost
05. Synergy test
Whether the result exceeds the relevant comparators with declared risk thresholds satisfied
06. Maturity
The M0 to M5 level for each bounded domain separately
07. OrgAI profile
What the organisational architecture actually produces, not merely that it exists
What changed since version 1.0.0
This release began from an uncomfortable finding: in four places, the calculator contradicted its own whitepaper.
Material contribution was evaluated on a single dimension chosen from a dropdown, although the whitepaper defines a seven-dimension profile and explicitly forbids compressing it into a score.
The exported record carried none of the seven fields of the minimum reporting convention, and so was not citable under the framework’s own rule.
Access and validation were entered as slider values, although they are proportions over a declared task set, which manufactured an apparent precision with nothing behind it.
Validated organisational learning appeared disconnected from the architecture it belongs to.
All four are fixed. No formula defined in the whitepaper was altered, and the six assertions of the original test suite pass unchanged.
On top of the repairs, the missing constructs were added: the classification worksheet, an evidence reference for every organisational condition, exposure compared before and after controls, the nine-dimension organisational profile, maturity assessed per domain, the anti-pattern detector, and a JSON schema that can be re-imported.
Three things worth seeing
A profile, not a score
Figure 2. The contribution profile across five relevant dimensions. The data come from a demonstrative case.
In the example above, AI made security alert triage significantly faster and moderately better. At the same time, confidence calibration, analyst autonomy and risk exposure all worsened, each beyond the declared threshold.
A composite score would have summed the five values and reported a gain. The result would have been technically correct and entirely misleading: part of the speed came from reduced validation. The instrument refuses to produce that number, not because of a technical constraint, but because the whitepaper forbids compressing the profile, and a single score hides exactly the trade-off that matters.
A number without a volume says nothing
Figure 3. A gap of 0.22 measured over 140 tasks: interval [0.13 – 0.31], gap demonstrated.Figure 4. A larger gap, 0.25, but over 12 tasks: the interval crosses zero and the verdict becomes “not demonstrated”.
Access and validation are entered as counts, how many tasks out of how many, not as estimated percentages. The counts produce a confidence interval, and when that interval includes zero the instrument says “not demonstrated at this task volume”, not “no gap”.
A larger gap, poorly measured, supports less than a smaller one measured well. The instrument does not hide that difference behind the same two-decimal number.
A claim is not evidence
Figure 5. The constitutive threshold. A condition marked without an evidence reference is highlighted and does not count towards the threshold.
Each of the six organisational conditions requires an evidence reference and its type, not a checkbox. A condition marked “demonstrated” without a reference appears as declared, undocumented, and does not count towards the threshold. The counter becomes a pair, declared and documented, and the difference between the two numbers shows the distance between what an organisation believes about itself and what it can show.
Figure 6. The anti-pattern detector: each flag shows the values that triggered it and the correction prescribed by the framework.
Across all modules runs a detector that reads the configuration as a whole and looks for contradictions between what was declared in one place and what was measured in another. It is the only component that tells the assessor something they did not know on the way in.
Properties
Property
State
Installation
None. One HTML file opened in any modern browser
Network requests
None. Fonts are embedded; it works on an isolated network
Browser persistence
None. No localStorage, no cookies
Account, database, analytics
None exist
Security policy
Restrictive CSP in the self-hosted variant, with connect-src “none”
Verification
29 automated tests that extract the logic from the delivered file
The last line deserves an explanation. The tests do not hold a copy of the formulas: they extract them from the shipped file, between two markers in the code. A passing run is a statement about the file in your hand, not about a laboratory version.
Where to get it
The instrument is deposited on Zenodo with a citable DOI: 10.5281/zenodo.22884721, version 1.2.0. The record contains the source archive and the ready-to-use index.html. No unpacking is needed: the file opens directly in the browser.
What is the HumanAI and OrgAI Framework Calculator?
It is the digital instrument that operationalises the relationships defined in the HumanAI and OrgAI whitepaper. You complete it for a bounded situation, one process, one team and one period, and it produces a reproducible assessment record with eight modules and an anti-pattern detector.
How do I get it, and why does it need no installation?
It is a single HTML file, deposited on Zenodo with DOI 10.5281/zenodo.22884721. It opens directly in any modern browser. It has no account, database or server and makes no network request, so it behaves identically on a machine with no internet connection.
Why does it not produce a single score?
Because the whitepaper forbids compressing the contribution profile into one figure. A composite score can hide speed obtained by reducing validation. The instrument reports a profile across dimensions, with the direction and size of each change.
What does the verdict “not demonstrated” mean in epistemic decoupling?
It means that, at the declared task volume, the confidence interval of the gap includes zero. It does not mean there is no gap, only that the available data do not support one. Absence of evidence is not evidence of absence.
What is the licence and how should it be cited?
The code is licensed under MIT, while the conceptual framework, the definitions and the interpretive text remain under CC BY-ND 4.0. When you rely on the definitions or the interpretation, cite both: the whitepaper, DOI 10.5281/zenodo.22295278, and the instrument, DOI 10.5281/zenodo.22884721.
Can the results be used as evidence of compliance?
No. Results are interpretive and do not constitute empirical validation, certification, legal advice or a compliance determination. The instrument verifies nothing: values remain claims by the assessor until they are tied to the evidence they point to.
The framework, the definitions, the variables, the formulas and the interpretive model were developed by Alexandru Angheluș, an independent and self-funded author. Artificial intelligence and automation tools were used selectively for software development, structural organisation, drafting and verification activities. Responsibility for the conceptual model and for the software remains entirely with the author.
We use cookies and similar technologies to store and access information on your device, for statistics and for the operation of this site. You can accept, decline, or choose by category. Declining may limit some features.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
