Worked examples

UNIQ²Me records the answers to specific assessment questions and lets readers check the requirements relevant to a decision. These examples show how to connect a profile to its questions, evidence, and follow-up actions. For the underlying operations, see assessment encoding and requirement masks.

Recovery and a NIS2-related benchmark

Consider four recovery questions in a hypothetical Scoring Factor Set (SFS). They illustrate conditions related to the business-continuity and backup concerns of NIS2 Article 21(2)(c).

For this worked example, the remaining twelve questions have resolved answers of 0. Questions run from position 0 on the left to position F on the right, so the assessment is B000. The mask F000 selects the first four questions and excludes the other twelve from this check.

Assessment S: 1011 0000 0000 0000 = B000
Mask       M: 1111 0000 0000 0000 = F000

R = S AND M                 = B000
D = R XOR M                 = 4000
Selected requirements met?  R = M: no

The unmet mask 4000 identifies SF 1: the restoration-test condition. The other selected questions are satisfied. A backup schedule alone would not establish that a restore succeeded; the assessor needs a successful test record meeting the stated scope and review period.

After the test succeeds and the assessor accepts its evidence, the updated set value passes this requirement check:

Updated S                   = F000
R = S AND F000              = F000
D = R XOR F000              = 0000
Selected requirements met?  R = M: yes

Retain the catalog version, mask, system boundary, evidence period, test record, and assessor's reasons with both snapshots. This makes the change traceable to an accepted finding.

This is an illustrative requirement check, not a legal compliance determination. The four questions cover selected recovery conditions; NIS2 compliance also depends on applicable national law, implementing acts, and obligations outside this mask. Excluding a question from a mask does not create a legal exemption.

Comparing agents on the same evidence

Two assessment agents can use the same SF identifiers to report their proposed judgments. A fair comparison gives both agents identical evidence, the same catalog and criteria, the same system scope and evidence period, and the same requirement mask.

Suppose their resolved set values for the recovery example are B000 and F000. To locate disagreements among the selected questions, mask the XOR of those values:

Agent A                     = B000
Agent B                     = F000
Mask M                      = F000
Disagreements = (A XOR B) AND M
                            = 4000

They disagree on one of the four selected questions and agree on three: a matching proportion of 3/4, or 75%. This measures agreement, not correctness. Both agents could agree on an unsupported answer, and a larger hexadecimal value does not identify the better agent.

An independently adjudicated reference is needed to measure accuracy, unsupported positive judgments, and missed satisfied requirements. Reviewers should examine the disputed SF and cited evidence. If the restoration record is incomplete or contradictory, the finding remains pending until resolved rather than being forced into a profile bit.

In an operational workflow, an agent could help collect evidence, identify unanswered questions, and prepare findings for review. Dated assessments could then track remediation or a later regression. A changed bit points to a question worth investigating; it does not explain the cause. See LLM Training and Assessment Assistance for the proposed model workflow and evaluation plan.

Defining a reproducible password-resistance question

The manuscript proposes this illustrative SF:

Did the stored password hashes pass the defined 24-hour password-recovery test without any password being recovered?

A password-auditing tool such as John the Ripper could perform the test using specified wordlists and guessing rules. The example has no assigned catalog position and reports no actual test result.

The proposed computing baseline is the best available single server for this workload at the catalog's UTC reference date. A cloud provider such as AWS could supply it, but the selection is not limited to AWS. Hardware names, prices, or nominal specifications alone do not establish equivalent performance.

To make an edition reproducible, its definition would need to freeze:

• The UTC cutoff, reference machine, provider coverage, and workload-specific selection evidence.
• Software versions, configuration, hash algorithms, cost parameters, wordlists, and guessing rules.
• A procedure for demonstrating equivalent computing power on another machine.
• The account population or declared sample, whether 24 hours applies to the collection or each hash, and the evidence-validity period.

These details remain to be finalized. An assessment would record the tested accounts, actual resources, evidence period, completed work, and recovery count. A missing or incomplete test remains pending. Zero recoveries would support only the defined test condition; it would not prove resistance to every recovery method.

A later catalog edition could raise the hardware baseline while preserving the earlier edition's procedure. Compare results only with their reference definitions in view; see Versioning and Validation of Scoring Factors.