Methodology

UNIQ²Me is a reporting and comparison method for cybersecurity assessment. It connects an agreed question to an evidence-based judgment, preserves that answer in a fixed position, and lets different readers check the requirements relevant to their decisions. A failed requirement can then be traced back to its question, evidence, and assessor's reasons.

This section teaches the method: how to define questions, assess evidence, resolve judgments, encode answers, and interpret requirement checks. The separate catalog describes the concrete organization of sets, factors, and questions. Use Scoring Factor Sets to explore the areas and question sets to inspect their positions. Learning the process and browsing a particular catalog are separate activities; every assessment needs both a method and an identified catalog.

The problem the method addresses

A purchaser, operator, developer, and assessor may read the same assessment for different reasons. The purchaser needs to know whether acceptance conditions are met. The operator needs to locate work to do. The assessor needs to reconstruct how the evidence supported a finding. Later system changes can invalidate an earlier answer.

A total score can hide these distinctions. Two systems may satisfy the same number of questions but fail different mandatory requirements. UNIQ²Me retains each question's identity within a compact profile and links the answers to detailed records. Stakeholders can select different requirements from the same assessment when the definitions, scope, and evidence period are compatible.

A question, a set, and a catalog

An SF asks about one condition in plain language and allows a yes/no answer. The question is limited to 512 characters, and a positive answer means that the stated condition is satisfied. Supporting explanations define terms, applicability, timing, acceptable alternatives, and the evidence criterion. A set is a container for sixteen such questions; a security-area heading alone is not an SF.

Both set and question indices run from 0 to 9, then A to F. Index A means decimal 10, the eleventh position. The catalog fixes what each position means. Structural completeness does not establish that its definitions are reviewed or that its questions have been assessed. A smaller requirement selection is a mask over this catalog. See terms and notation for identities, states and named SFS/SF positions.

Authors define conditions; assessors examine actual evidence

An authoring record defines a reusable question before anyone assesses a particular system. Authors and content reviewers establish its wording, explanations, references, assessment rule, and position. Their approval means that the definition has been reviewed. It does not mean that a service satisfies the condition.

For example:

Has the required recovery test succeeded during the review period?

The author must explain which service is in scope, which dates count, what success means, and which records demonstrate it. A canonical solution can describe one way to implement and verify recovery. Equivalent implementations can also qualify under the same rule.

The assessor then examines evidence from the actual service and records a judgment with reasons. A successful restoration record can support a positive answer; a completed test showing failure can support a negative answer. A backup schedule alone does not demonstrate a successful restore. Missing or contradictory records require clarification under the evidence rule.

The proposed authoring structure leaves judgments and resultScore unfilled. A null field means unfilled, not failure. The full operational assessment schema and validation rules remain to be finalized. Question records explains the authoring design, and evidence and interpretation explains how observations support an assessment.

From questions to records

Questions → Evidence → One or three assessors resolve judgments
          → Bits → Hexadecimal profile → Mask outcome → Linked records

1. Define each question and its evidence rule. Identify the catalog edition, SF and SFS positions, applicability, service boundary, and acceptance condition.
2. Gather and reference the evidence. Record the actual system, review period, observations, and any missing or conflicting information.
3. Record and resolve judgments from one assessor or three assessors, each signing their judgment and giving reasons. Three ordinary judgments resolve by majority. Marked judgments such as 0+ and 1+ receive the specified priority; opposing marked judgments are broken by the third ordinary judgment. Only the resolved 0 or 1 proceeds to encoding. See assessment and validation for the complete rules.
4. Place the resolved bits in their assigned positions. 1 means satisfied and 0 means not satisfied. SF 0 is the leftmost bit; SF F is the rightmost. Position does not assign security importance.
5. Encode each sixteen-bit set as four hexadecimal digits, keeping leading zeros. A complete sixteen-set profile retains all positions in order, separated by colons. The hexadecimal value encodes individual answers rather than adding them. See encoding.
6. Choose a compatible catalog mask, SFS mask or individual-SF mask. A mask bit of 1 selects a required positive answer; 0 excludes that question from this check. For resolved answers S and mask M, the check passes when (S AND M) = M. The unmet requirements are (S AND M) XOR M. Retain the selected scope: an SFS or individual-SF check does not become a complete assessment. See requirement masks and the MASKS library.
7. Retain and retrieve the linked records. Keep the exact catalog identity, language and edition, mask, system boundary, evidence period, evidence references, individual judgments, and resolution reasons. A gap points to a question whose record explains the finding and supports follow-up work.

Pending findings remain outside the binary encoding until resolved. Pending is a workflow state, not a third bit value. Missing evidence must not be silently turned into 0, and an unresolved position must not be removed in a way that shifts other question positions. Keep incomplete findings explicit in the accompanying records.

A bounded recovery example

Suppose a hypothetical SFS starts with these four questions. The accepted evidence demonstrates a failed restoration test and satisfactory results for the other three conditions.

For the arithmetic illustration, assume the other twelve answers are resolved zeros. These are explicit example assumptions, not placeholders for pending evidence. The first four bits are 1011, giving assessment B000. Mask F000 selects all four recovery questions and excludes the remaining twelve.

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

R = S AND M = B000
D = R XOR M = 4000

B000 differs from F000, so this check fails. 4000 identifies SF 1, the restoration-test question. When a later test succeeds and the assessor accepts evidence meeting the same criterion, the updated assessment is F000; its unmet result is 0000, and it passes this mask.

This conclusion concerns only the four selected conditions under the recorded scope and evidence period. The example illustrates recovery concerns discussed in the manuscript; it is not a completed assessment, a released catalog assignment, a compliance certificate, or a risk estimate. See worked examples for the evidence and reassessment context.

Preserve meaning across assessments

An answer must remain attached to the definition that gave it meaning. The manuscript identifies a catalog as author/language/YYe, where the final letter is the ordinal edition within that author's language namespace and year. Publication dates, assessment dates, and evidence periods are separate metadata. groupa/en/26a is an illustrative release designation.

Before comparing profiles or applying a mask, establish compatible question definitions, ordering, system scope, and evidence periods. Changed meanings, positions, or translations may require reviewed mappings. Keep earlier assessment records so a reviewer can distinguish a changed service from a revised question. Catalog versions explains these annotations.

Scope and current status

The method reports resolved judgments and checks selected requirements. A larger hexadecimal value does not demonstrate better security. The calculation does not establish the correctness of the evidence or assessor decisions, measure attack likelihood or loss, or guarantee control effectiveness. Its practical benefits require studies of assessor agreement, reader understanding, and evidence-maintenance effort.

The manuscript describes a prepared complete catalog and canonical reference solutions. The reviewed 256-question catalog and its guidance will accompany the finished paper, together with compatible reviewed MASKS. Development placeholders and draft arithmetic masks remain distinct from that publication. The final release manifest will identify the publishing namespace, exact artifacts, locations and licenses. The version-1 mask format and deterministic comparison are implemented; the complete SF-authoring and operational assessment contracts need further implementation and validation.

Model training and assessment assistance remain ongoing work. No published trained model or measured performance gains are claimed here. An assistant could propose evidence-based judgments and corrective guidance; accepted outcomes would still pass through assessor resolution and deterministic encoding. Read AI-assisted assessment, the FAQ, and resources for further context.