The methodology prioritises clarity, consistency, and transferability. Design decisions are evaluated based on system behaviour, not individual item performance.
Core principles
-
Assessment before content
Question structure and intent are defined before item writing. -
Diagnostic signal over scores
Incorrect responses are treated as data, not noise. -
Constraints drive clarity
Specifications, language, and mark schemes are treated as design inputs. -
Scalability by default
Frameworks are evaluated for behaviour at cohort and system scale.
Diagnostic-first design
Rather than optimising for discrimination between correct and incorrect responses, the methodology focuses on why an incorrect response is selected.
This results in structural patterns such as:
-
two-tier question designs separating selection from reasoning
-
distractors mapped to specific misconceptions
-
explicit separation of recall and explanation
These structures allow incorrect responses to be categorised meaningfully, preserving diagnostic value when deployed at scale.
Retrieval as architecture
Retrieval is treated as an architectural feature of the system rather than a standalone activity. The emphasis is on how retrieval sequences interact across time and content boundaries.
Key considerations include:
-
cumulative checking across units and concepts
-
threshold concepts as anchoring points
-
spacing and reappearance patterns that preserve signal
Language and specification constraints
In regulated assessment environments, language precision is structural rather than cosmetic. Small variations in phrasing can alter interpretation and invalidate comparisons.
The methodology therefore treats:
-
specification wording
-
mark scheme phrasing
-
command terms
as fixed constraints rather than flexible stylistic choices.
Domain and scope
GCSE Science is used as the working domain because it is highly standardised, assessment-dense, and sensitive to language and structure. These characteristics make it suitable for stress-testing assessment frameworks.
The underlying principles are intended to generalise beyond this domain.
Status and use
The methodology is documented through working frameworks, examples, and exploratory artefacts. Items are published when they clarify system behaviour, not when they are finalised for deployment.
SciencePass should be read as an evolving design record, not a finished specification.