Question records

A useful Scoring Factor begins with a clear condition. JSON gives people and software a common record of that condition, its explanations, and its identifiers.

The structure below is the manuscript's proposed authoring design. The excerpt illustrates selected fields; it is not a complete validated schema or an operational assessment record.

Write one assessable question

A binary question should:

Ask about one condition and allow a yes/no answer.
Use plain language and stay within 512 characters.
Make a positive answer mean that the stated condition is satisfied.
Refer to an evidence rule that resolves scope, timing, and ambiguous terms.

For example, "Are backups secure and regularly tested?" combines multiple conditions. A recovery question can instead ask:

Has the required recovery test succeeded during the review period?

Its explanation must define "required", "succeeded", and "review period".

Field groups

Field group	Purpose
`identity`	Names the catalog edition, SFS, and SF position.
`question`	Holds the binary question, plain explanation, technical description, keywords, and assistance prompt.
`assessmentRule`	Defines applicability, service boundary, evidence period, required evidence, pass/fail criteria, missing-evidence handling, and acceptable alternatives.
`clarificationQuestion`, `wikiLinks`	Clarify terms and link to the sources behind the criterion.
`openSourceApproach`, `glacierWiki`	Describe and link a reference implementation.
`meta` and publishing links	Support readable presentation and access to the structured definition.
`generation`, `review`	Record provenance and review of the definition.
`signatures`, `resultScore`	Remain unfilled in authoring records; actual judgments belong to an assessment instance.

The plain and technical explanations must express the same condition. A technical reader may need more detail, but should not be assessing a different requirement.

An illustrative authoring excerpt

{
  "schemaVersion": "0.1-draft",
  "recordType": "sf-authoring",
  "identity": {
    "releaseLabel": "groupa/en/26a",
    "sfsId": "2",
    "sfId": "1"
  },
  "question": {
    "shortBinaryQuestion": "Has the required recovery test succeeded during the review period?"
  },
  "review": {
    "status": "pending",
    "approvals": []
  },
  "resultScore": null
}

This reproduces the manuscript's partial example. The full explanations, assessment rule, references, and publishing metadata must be supplied before it can serve as a complete definition. The release label is illustrative.

Explicit sfsId and sfId names avoid ambiguity about index order. Each index is limited to 0 through F.

Make the evidence rule explicit

For the recovery question, the author must settle:

Rule element	What the definition must specify
Service boundary	Which service, data, and dependencies must be restored.
Review period	Which dates determine whether a test is current.
Required evidence	Which test records and observations establish the outcome.
Success criterion	What must work and which recovery objectives must be met.
Failure criterion	Which observed outcomes demonstrate that the condition is unsatisfied.
Missing evidence	How clarification and pending review are handled.
Alternatives	Which equivalent restoration methods can meet the same criterion.

A backup schedule alone does not demonstrate a successful restoration. An absent uploaded report also does not prove that no successful test occurred; the assessment needs clarification.

Preserve unfilled values

An authoring record describes a question before it is assessed. Its signer votes, names, timestamps, explanations, and resultScore are null until an operational assessment supplies them.

Null means unfilled, not failure. An unused isBiased: false template value does not express confidence, and recording a person's name does not implement a cryptographic signature.

Content approval belongs under review. It approves the wording and evidence rule, not an organization's control implementation.

Document a canonical solution

A canonical solution is one selected reference approach based on open-source software or openly documented techniques. It should identify its assumptions, software and documentation versions, configuration steps, verification procedure, and expected evidence.

Equivalent implementations remain acceptable when they satisfy the same rule. A named tool, library, or framework is not itself evidence that a requirement passed.

See AI-assisted assessment for how these references could support training, retrieval, and remediation guidance.

Link the frozen definition

A release-specific link and QR code should identify the same frozen record. A latest-version link helps readers discover newer content without changing what an earlier assessment meant.

The proposed key glacerQRcode retains its existing spelling for compatibility. Layout and navigation fields do not change the assessment criterion.

Review before publication

Check required fields and value types, the question-length limit, valid indices, unique positions, complete sixteen-question sets, and consistent release references. Then review meaning: clarity, evidence quality, acceptable alternatives, topic overlap, and source provenance.

Structural validity cannot establish that a question is correct or consistently understandable. The complete operational schema and validation rules remain work to finalize.

Continue with assessment and validation or catalog versions.

Evidence and interpretation Assessment and validation