QUALIFICATION WEB PROTOCOL

QWP Conformance Test Suite v1.0 Candidate

Статус: Candidate Conformance Test Suite
Цільовий стандарт: QWP v1.0 Candidate
Призначення: перевірка незалежних реалізацій Qualification Web Protocol

1. Призначення

QWP Conformance Test Suite визначає стандартний набір тестів, за допомогою якого можна перевірити, чи програмна реалізація правильно виконує нормативні вимоги QWP v1.0.

Test Suite перевіряє:

• 
  структуру даних;

• 
  ідентифікатори;

• 
  посилання;

• 
  semantics;

• 
  qualification decision logic;

• 
  uncertainty handling;

• 
  authority;

• 
  identity assurance;

• 
  process assurance;

• 
  human judgment;

• 
  versioning;

• 
  extensions;

• 
  межу між academic conformance та legal recognition.

2. Що означає проходження Test Suite

Проходження QWP Conformance Test Suite означає:

реалізація правильно виконує визначену частину QWP protocol.

Воно не означає:

• 
  що assessment є психометрично валідним;

• 
  що qualification legally recognized;

• 
  що система акредитована;

• 
  що будь-який реальний decision є правильним;

• 
  що software є безпечним для high-stakes use без додаткової перевірки.

3. Conformance Classes

Test Suite перевіряє чотири основні класи.

QWP Data Conformant

QWP Validator Conformant

QWP Evaluator Conformant

QWP Full Conformant

4. Data Conformant

Перевіряється:

• 
  core object representation;

• 
  required identifiers;

• 
  canonical machine values;

• 
  version fields;

• 
  stable semantics.

5. Validator Conformant

Додатково перевіряється:

syntax

schema

identifier uniqueness

reference integrity

basic semantic constraints

6. Evaluator Conformant

Додатково:

• 
  requirement states;

• 
  PASS;

• 
  FAIL;

• 
  INDETERMINATE;

• 
  Decision Rules;

• 
  Human Review;

• 
  compensation logic;

• 
  integrative requirements;

• 
  Decision Trace;

• 
  Gap Report.

7. Full Conformant

Додатково:

• 
  profiles;

• 
  authority;

• 
  identity assurance;

• 
  process assurance;

• 
  version handling;

• 
  extensions;

• 
  audit metadata;

• 
  REST/API semantics;

• 
  recognition boundary.

8. Test Case Model

Кожний test case має:

id

category

conformanceClass

profile

specification

proof

expectedTechnicalStatus

expectedDecision

expectedRequirementStates

expectedErrors

expectedWarnings

notes

9. Pass criterion

Implementation проходить конкретний test, якщо її normative output відповідає expected result.

Дозволяється різне:

• 
  formatting;

• 
  порядок JSON fields;

• 
  human-readable explanation;

• 
  внутрішня architecture.

Не дозволяється змінювати normative meaning.

10. Категорії тестів

Test Suite містить:

A. Positive Cases

B. Negative Cases

C. Indeterminate Cases

D. Invalid Proof Cases

E. Boundary Cases

F. Human Judgment Cases

G. Authority Cases

H. Identity Assurance Cases

I. Process Assurance Cases

J. Versioning Cases

K. Extension Cases

L. Recognition Boundary Cases

M. Provider Neutrality Cases

N. Adversarial Cases

O. API Behaviour Cases

11. A01 — Basic PASS

Мета: перевірити найпростішу позитивну qualification evaluation.

Умова:

Mandatory R1 = SUPPORTED

Mandatory R2 = SUPPORTED

Очікується:

technicalStatus = VALID

decision = PASS

12. A02 — PASS with compensable requirement

Умова:

Mandatory R1 = SUPPORTED

Compensable R2 = SUPPORTED

Expected:

PASS

13. A03 — PASS with explicit Human Judgment

Integrative requirement має:

HumanJudgmentEvent = SUPPORTED

Expected:

Requirement = SUPPORTED

Decision = PASS

якщо всі інші mandatory requirements підтримані.

14. B01 — Mandatory NOT_SUPPORTED

Умова:

R1 type = MANDATORY

R1 status = NOT_SUPPORTED

Expected:

FAIL

15. B02 — Integrative NOT_SUPPORTED

Integrative Requirement = NOT_SUPPORTED

Expected:

FAIL

16. B03 — Compensable threshold failure

Наприклад:

3 compensable requirements

supported = 1

not_supported = 2

minimum supported ratio = 0.67

maximum not supported = 1

Expected:

FAIL

17. B04 — Negative Validity Argument

Evidence існує, але:

ValidityArgument = NOT_SUPPORTED

Expected requirement status:

NOT_SUPPORTED

Не:

SUPPORTED

18. C01 — Missing Evidence

Mandatory claim не має evidence.

Expected:

Requirement =

INSUFFICIENT_EVIDENCE

Decision =

INDETERMINATE

19. C02 — Evidence without Validity Argument

Evidence існує.

Validity Argument відсутній.

Expected:

INSUFFICIENT_EVIDENCE

а не:

SUPPORTED

20. C03 — Contested Evidence

Validity arguments містять material disagreement.

Expected:

CONTESTED

Final:

INDETERMINATE

для mandatory requirement.

21. C04 — Human Review Pending

Requirement:

HUMAN_REVIEW

Expected qualification decision:

INDETERMINATE

22. D01 — Duplicate Identifier

Proof містить два normative objects з:

id = evidence:001

Expected:

technicalStatus =

INVALID_PROOF

Expected error:

QWP_DUPLICATE_IDENTIFIER

23. D02 — Missing Required Field

QualificationProof не має:

subject

Expected:

INVALID_PROOF

24. D03 — Wrong Object Type

type = EvidenceObject

для document, який заявлений як QualificationProof.

Expected:

INVALID_PROOF

25. D04 — Dangling Claim Reference

Evidence:

supports = claim:not-existing

Expected:

INVALID_PROOF

26. D05 — Specification Mismatch

Proof:

qualificationSpecification = QS-A

але evaluator отримує:

QS-B

Expected:

INVALID_PROOF

27. D06 — Invalid requirement type

requirementType = OPTIONAL_MANDATORY

Expected validation error.

28. E01 — Empty Evidence Array

Empty evidence array є syntactically valid.

Але якщо mandatory requirements існують:

Expected:

VALID

+

INDETERMINATE

Не:

INVALID_PROOF

якщо структура документа коректна.

29. E02 — Empty Qualification Requirements

Specification має:

requirements = []

Expected:

INVALID_SPECIFICATION

або equivalent schema validation error.

30. E03 — All requirements supported

Немає compensable requirements.

Усі mandatory та integrative requirements:

SUPPORTED

Expected:

PASS

31. E04 — One unresolved compensable requirement

За rules:

minimum supported ratio = 1.0

один compensable requirement:

INSUFFICIENT_EVIDENCE

Expected:

INDETERMINATE

32. F01 — Required integrative review absent

Profile:

QWP-HIGH-STAKES

Requirement:

INTEGRATIVE

HumanJudgmentEvent відсутній.

Expected:

HUMAN_REVIEW

і:

INDETERMINATE

33. F02 — Human judgment supported

Judgment:

SUPPORTED

Expected requirement:

SUPPORTED

34. F03 — Human judgment deferred

DEFERRED

Expected:

HUMAN_REVIEW

35. F04 — Conflicting human judgments

Reviewer A:

SUPPORTED

Reviewer B:

NOT_SUPPORTED

Reference behaviour:

CONTESTED

або explicit adjudication-required state defined by the profile.

Implementation MUST NOT silently choose one reviewer.

36. G01 — Valid Authority

Assessor has:

AuthorityRecord.status = ACTIVE

Scope matches requirement.

Date valid.

Expected:

authority check = satisfied

37. G02 — Revoked Authority

AuthorityRecord.status = REVOKED

Expected:

HUMAN_REVIEW

або corresponding unresolved authority state.

Must not:

PASS

solely on that assessment.

38. G03 — Expired Authority

Evaluation date exceeds:

validUntil

Expected authority failure.

39. G04 — Wrong Authority Scope

Assessor authorized for:

statistics

but requirement needs:

clinical-practice

Expected:

ASSESSOR_AUTHORITY_UNVERIFIED

40. G05 — Distinct IDs, same assessor not proven independent

Two assessors:

assessor:01

assessor:02

але identity independence не підтверджена.

System MUST NOT infer:

independent panel

лише через different identifiers.

41. H01 — Identity Assurance sufficient

Profile:

QWP-RPL

minimum:

IA-2

Candidate:

IA-2

Expected identity constraint satisfied.

42. H02 — Identity Assurance insufficient

Profile requires:

IA-3

Candidate has:

IA-1

Expected:

HUMAN_REVIEW

or equivalent unresolved state.

43. H03 — Identifier does not prove identity

Candidate:

candidate:123

але IdentityAssurance відсутня.

High-stakes evaluator MUST NOT treat identifier existence as identity verification.

44. I01 — Process Assurance sufficient

Profile:

QWP-HIGH-STAKES

requires:

PA-3

Assessment has:

PA-3

Expected process condition satisfied.

45. I02 — Process Assurance insufficient

Assessment:

PA-1

Requirement:

PA-3

Expected:

HUMAN_REVIEW

46. I03 — Strong identity, weak process

IA-4

PA-1

Expected:

Process Assurance remains insufficient.

System MUST NOT allow high identity assurance to compensate automatically for weak process assurance.

47. I04 — Strong process, weak identity

IA-1

PA-4

Expected:

Identity Assurance remains insufficient where profile requires higher identity assurance.

48. J01 — Supported QWP version

Document:

qwpVersion = 1.0

Engine:

1.x

Expected normal processing.

49. J02 — Compatible minor version

Example:

document = 1.1

engine supports 1.x compatible subset

Implementation MAY process compatible core.

It MUST disclose version handling.

50. J03 — Unknown major version

Document:

2.0

Engine:

1.x

Expected:

QWP_UNSUPPORTED_MAJOR_VERSION

No authoritative evaluation.

51. J04 — Historical specification

Decision created against:

Specification 1.0

Current specification:

2.0

System MUST NOT silently reinterpret old decision as if evaluated under 2.0.

52. K01 — Unknown non-critical extension

Proof contains unknown extension:

critical = false

Expected:

• 
  core processing may continue;

• 
  extension may be ignored;

• 
  warning MAY be produced.

53. K02 — Unknown critical extension

critical = true

Evaluator does not understand it.

Expected:

INDETERMINATE

or technical refusal to issue authoritative decision.

Must not:

PASS

54. K03 — Known domain extension

Implementation declares support.

Expected:

extension semantics applied according to profile.

55. L01 — PASS does not imply Award

Input:

AcademicConformance = PASS

Expected output must not automatically contain:

Award = TRUE

56. L02 — Award does not imply Recognition

Proof includes valid Award record.

No RecognitionRecord.

Expected:

Recognition = NOT_EVALUATED

or equivalent unknown state.

57. L03 — Recognition does not imply licence

Recognition exists:

FOR_STUDY

Expected:

Professional Authorization remains separate.

58. L04 — Same framework level

Qualification A:

Level 7

Qualification B:

Level 7

Expected:

equivalence = NOT_DETERMINED

not:

equivalent = true

59. M01 — Provider neutrality matched pair

Create two candidates:

Candidate A:

University pathway

Candidate B:

Self-directed pathway

All qualification-relevant evidence, assessment, authority and assurance are identical.

Expected:

Decision A =

Decision B

60. M02 — Different provider, different evidence

Provider differs and evidence also differs.

Different decisions MAY be correct.

Provider neutrality does not require identical decisions when qualification-relevant facts differ.

61. M03 — Prestige must not substitute for evidence

Candidate A:

prestigious university

weak evidence

Candidate B:

unknown provider

strong evidence

QWP evaluator must operate from normative evidence chain.

Institutional prestige MUST NOT be inserted as undocumented support for requirement status.

62. N01 — Hidden AI assumption

Artifact contains no AI disclosure.

System cannot prove whether AI was used.

Expected:

Do not infer AI_NOT_USED.

Where process authenticity is critical and insufficient:

HUMAN_REVIEW

may be appropriate.

63. N02 — AI disclosed, capability independently verified

Artifact:

AI_ALLOWED_DISCLOSED

Candidate also completes:

• 
  oral defence;

• 
  transfer task;

• 
  independent assessment.

Expected:

AI disclosure alone must not cause FAIL.

64. N03 — AI-generated artifact alone

Only evidence:

AI-assisted artifact

No independent capability verification.

Expected:

INSUFFICIENT_EVIDENCE

or:

HUMAN_REVIEW

depending profile.

65. N04 — Fake authority identifier

AuthorityRecord points to an unverified issuer.

Expected:

identifier existence alone does not prove authority.

66. N05 — Revoked evidence

Evidence status:

REVOKED

Evaluator must not use it as active supporting evidence.

67. N06 — Contradictory evidence

Positive evidence and material counter-evidence coexist.

Expected:

CONTESTED

or explicit human review.

68. N07 — Replay attack

Same credential reused for another candidate where subject binding does not match.

Expected:

evidence cannot support the second candidate without valid binding.

69. N08 — Duplicate nested identifier

Duplicate ID exists deeply inside nested objects.

Expected:

INVALID_PROOF

Validator must not only inspect top-level IDs.

70. N09 — Manipulated version

Proof claims:

version = 1.1

but hash/audit metadata correspond to 1.0.

High-assurance profile should flag integrity problem.

71. N10 — Missing critical external service

Authority status must be checked externally.

Service unavailable.

Expected conservative behaviour:

INDETERMINATE

or:

HUMAN_REVIEW

not automatic positive assumption.

72. O01 — API success with PASS

HTTP transaction succeeds.

QWP:

decision = PASS

Expected HTTP success.

73. O02 — API success with INDETERMINATE

QWP:

decision = INDETERMINATE

Expected:

normal successful API response.

Do not convert ordinary epistemic uncertainty to:

HTTP 500

74. O03 — Invalid request

Malformed JSON.

Expected transport or request validation error.

This differs from:

Qualification FAIL

75. O04 — Invalid proof

Syntactically valid request contains invalid QWP Proof.

Expected API response should clearly indicate:

technicalStatus = INVALID_PROOF

76. O05 — API truth consistency

REST endpoint:

evaluate

та agent interface:

qualification.evaluate

must return normatively equivalent QWP decision for identical input.

77. O06 — Explain does not rewrite decision

If engine returns:

INDETERMINATE

explain output MUST NOT transform it into:

«almost passed»

as an official status.

78. O07 — Gaps after PASS

If:

decision = PASS

Gap Report should contain no unresolved mandatory qualification gaps.

Warnings MAY remain.

79. O08 — Gaps after INDETERMINATE

Must identify at least one unresolved cause where such cause is known.

80. Canonical machine format for tests

Recommended:

{

"id": "QWP-C01",

"category": "INDETERMINATE",

"class": "Evaluator",

"profile": "QWP-CORE",

"expected": {

"technicalStatus": "VALID",

"decision": "INDETERMINATE",

"requirementResults": {

"req:research":

"INSUFFICIENT_EVIDENCE"

}

}

}

81. Test manifest

Root manifest:

{

"suite":

"QWP Conformance Test Suite",

"version":

"1.0-candidate",

"protocol":

"QWP 1.0",

"categories": [

"positive",

"negative",

"indeterminate",

"invalid",

"boundary",

"human-judgment",

"authority",

"identity",

"process",

"versioning",

"extensions",

"recognition-boundary",

"provider-neutrality",

"adversarial",

"api"

]

}

82. Recommended directory structure

qwp-conformance-tests/

|

+-- manifest.json

|

+-- data/

+-- validator/

+-- evaluator/

+-- authority/

+-- assurance/

+-- versioning/

+-- extensions/

+-- recognition/

+-- neutrality/

+-- adversarial/

+-- api/

|

+-- expected/

|

+-- runner/

|

+-- README.md

83. Test Runner Interface

A test runner should conceptually support:

qwp-test

--implementation URL_OR_COMMAND

--class Evaluator

--profile QWP-CORE

84. Required comparison

Runner compares:

actual technical status

actual decision

actual requirement statuses

actual errors

actual warnings

with:

expected normative output

85. Human text is generally not compared verbatim

For example:

"Недостатньо доказів"

та:

"Evidence is insufficient"

may both be acceptable.

Normative machine code must match:

INSUFFICIENT_EVIDENCE

86. Strict mode

For certification-like testing:

STRICT

mode may require exact:

• 
  required fields;

• 
  decision codes;

• 
  error codes;

• 
  profile behaviour.

87. Compatibility mode

For experimental implementations:

COMPATIBILITY

may accept equivalent non-normative metadata differences.

88. Core pass threshold

A conformance class should require:

100% mandatory normative tests

for that class.

There is no concept:

«90% conformant»

for mandatory protocol semantics.

89. Optional tests

Optional extensions may report:

PASS

FAIL

NOT_IMPLEMENTED

without affecting core conformance.

90. Data Conformance minimum set

Recommended mandatory tests:

A01

D02

D03

D06

J01

J03

plus serialization tests.

91. Validator Conformance minimum set

Additionally:

D01

D04

D05

D08-like nested duplicate test

E01

92. Evaluator Conformance minimum set

Additionally:

A01–A03

B01–B04

C01–C04

E03–E04

F01–F04

93. Full Conformance minimum set

Additionally all:

G

H

I

J

K

L

M

N

O

applicable tests.

94. Conformance report

Recommended output:

{

"implementation":

"Example QWP Engine",

"implementationVersion":

"1.2.0",

"testedAgainst":

"QWP v1.0 Candidate",

"conformanceClass":

"QWP Evaluator Conformant",

"profile":

"QWP-CORE",

"mandatoryTests": 42,

"passed": 42,

"failed": 0,

"result":

"CONFORMANT"

}

95. Failure report

{

"result":

"NOT_CONFORMANT",

"failedTests": [

{

"id":

"C02",

"expected":

"INSUFFICIENT_EVIDENCE",

"actual":

"SUPPORTED"

}

]

}

96. Особливо небезпечні failures

Деякі failures мають особливе значення.

False Acceptance

Implementation видає:

PASS

коли normative result:

FAIL

або:

INDETERMINATE

97. False Rejection

Implementation видає:

FAIL

коли normative result:

PASS

98. Uncertainty Collapse

Implementation перетворює:

INDETERMINATE

на:

PASS

або:

FAIL

без нормативної підстави.

99. Authority Escalation

Implementation трактує:

academic PASS

як:

legal recognition

100. Semantic Collapse

Implementation змішує:

Evidence

Claim

Credential

Qualification

Recognition

в один concept.

101. High-Severity Test Failures

До critical failures належать:

false acceptance

authority escalation

identity bypass

critical extension bypass

recognition boundary violation

revoked evidence accepted

102. Adversarial score

Для research purposes може бути показано:

Adversarial Detection:

9/10

Але це не замінює binary conformance result.

103. Provider-neutrality paired testing

Matched pair structure:

Pair P-001

Candidate A:

provider = university

Candidate B:

provider = self-directed

All relevant proof fields equal.

Expected:

same decision

104. Provider-neutrality failure

Якщо evaluator повертає:

A = PASS

B = FAIL

лише через provider identity, implementation fails provider-neutrality test.

105. Real-world validity remains separate

Навіть якщо:

100% Conformance Tests passed

не можна стверджувати:

«QWP доведено правильно оцінює реальних людей».

Test Suite перевіряє:

чи software правильно реалізує protocol.

106. Regression use

Кожна нова QWP implementation version повинна повторно проходити suite.

Наприклад:

Engine 1.0

→ tests pass

Engine 1.1

→ rerun all tests

107. Protocol revision use

Якщо:

QWP 1.1

змінює normative behaviour, Test Suite також отримує нову version.

108. Test immutability

Опублікований test case MUST NOT тихо змінювати expected result.

Якщо semantic correction потрібна:

new test version

або:

published erratum

109. Public test repository

Conformance Test Suite SHOULD бути відкритим.

Це дозволяє:

• 
  незалежне тестування;

• 
  audit;

• 
  regression;

• 
  конкурентні implementations.

110. Hidden tests

Formal certification process MAY додавати private tests, щоб implementations не hard-code public cases.

Але hidden tests повинні перевіряти ті самі published normative rules.

111. Anti-hardcoding principle

Implementation не вважається якісною лише тому, що впізнає:

test case ID

і повертає expected output.

Tests повинні мати parameterized variants.

112. Mutation tests

Наприклад із одного PASS case автоматично генеруються variants:

remove evidence

revoke authority

lower IA

lower PA

change version

break reference

Expected result має відповідно змінюватися.

113. Property-based testing

Можна перевіряти загальні invariants.

Наприклад:

If mandatory requirement = NOT_SUPPORTED

then final decision != PASS

114. Invariant 1

Mandatory NOT_SUPPORTED

→

Decision MUST NOT be PASS

115. Invariant 2

Invalid Proof

→

Academic evaluation MUST NOT produce normal PASS

116. Invariant 3

Unknown critical extension

→

Authoritative PASS MUST NOT occur

117. Invariant 4

Academic PASS

→

Legal Recognition MUST NOT be inferred automatically

118. Invariant 5

Same Level

→

Equivalence MUST NOT be inferred automatically

119. Invariant 6

Evidence Exists

→

SUPPORTED does not follow automatically

120. Invariant 7

Different Identifier

→

Different Identity does not follow automatically

121. Invariant 8

Strong Identity Assurance

→

Strong Process Assurance does not follow automatically

122. Invariant 9

Verifiable Credential

→

Competence does not follow automatically

123. Invariant 10

Unknown

!=

False

124. Reference Implementation baseline

Official QWP Reference Implementation SHOULD itself run the complete relevant suite.

Its passing result provides:

baseline implementation behaviour.

Але reference implementation MUST NOT override written normative specification if a discrepancy is discovered.

125. Conflict hierarchy

Якщо виникає розбіжність:

Reference Code

vs

Normative Specification

пріоритет має:

Normative Specification

поки protocol governance не виправить standard.

126. Test source hierarchy

Recommended authority order:

1. QWP Normative Specification

2. Published normative errata

3. Conformance Test Suite

4. Reference Implementation

5. Human-readable guides

127. Test Suite release metadata

Кожний release повинен мати:

version

date

target protocol version

checksum

change log

128. Suggested release identifier

QWP-CTS-1.0.0-candidate

129. Conformance badge

Реалізація, яка пройшла formal suite, MAY заявляти:

QWP v1.0 Evaluator Conformant

або:

QWP v1.0 Full Conformant

відповідно до фактично протестованого класу.

130. Badge must include version

Неправильно:

QWP Certified

без specification version та class.

131. Conformance expiration

Conformance claim MAY бути прив’язаний до:

• 
  software version;

• 
  protocol version;

• 
  test suite version.

Оновлення software може вимагати retesting.

132. Security testing boundary

Conformance Test Suite не замінює:

• 
  penetration testing;

• 
  dependency scanning;

• 
  cryptographic audit;

• 
  infrastructure security review.

133. Privacy testing boundary

Окремі privacy profiles можуть додати tests щодо:

• 
  minimum disclosure;

• 
  access control;

• 
  retention;

• 
  selective disclosure.

134. Future test profiles

Можливі:

QWP-CTS-RPL

QWP-CTS-HIGH-STAKES

QWP-CTS-RESEARCH

QWP-CTS-SELECTIVE-DISCLOSURE

QWP-CTS-SIGNED-PROOF

135. Мінімальний automatic runner pseudocode

for test in test_suite:

load specification

load proof

actual =

implementation.run(

test.operation,

specification,

proof,

test.profile

)

compare actual with expected

record PASS / FAIL

136. Comparison rules

Runner MUST compare:

technicalStatus

decision

requirement statuses

required error codes

Runner SHOULD NOT require identical:

• 
  property ordering;

• 
  whitespace;

• 
  prose explanations.

137. Example executable test vector

{

"id": "C02",

"operation": "evaluate",

"profile": "QWP-CORE",

"input": {

"specification":

"fixtures/spec-basic.json",

"proof":

"fixtures/proof-evidence-no-validity.json"

},

"expected": {

"technicalStatus":

"VALID",

"decision":

"INDETERMINATE",

"requirementResults": {

"req:R1":

"INSUFFICIENT_EVIDENCE"

}

}

}

138. Example adversarial vector

{

"id": "N05",

"operation": "evaluate",

"profile": "QWP-HIGH-STAKES",

"mutation": {

"evidenceStatus":

"REVOKED"

},

"expected": {

"decision":

"INDETERMINATE"

},

"forbidden": {

"decision":

"PASS"

}

}

139. Forbidden-output concept

Certain tests SHOULD explicitly declare outcomes that MUST NOT occur.

Example:

{

"forbiddenDecisions": [

"PASS"

]

}

Це особливо корисно для safety-oriented tests.

140. Result categories

Test runner може класифікувати failures:

STRUCTURAL

SEMANTIC

DECISION_LOGIC

ASSURANCE

AUTHORITY

BOUNDARY

INTEROPERABILITY

SECURITY_RELEVANT

141. Final conformance condition

Implementation має право заявити конкретний QWP conformance class лише якщо:

1. 
   пройдені всі mandatory tests цього класу;

2. 
   немає unresolved critical failures;

3. 
   вказані exact:
   

   • 
     implementation version;

   • 
     QWP version;

   • 
     Test Suite version;

5. результат може бути відтворений.

142. Кінцевий принцип Test Suite

Specification defines the rules. Test Suite makes those rules executable as expectations.

143. Значення для Qualification Web

Поява Conformance Test Suite переводить QWP ще на один рівень зрілості:

Specification

+

Machine-readable model

+

Reference implementation

+

Conformance Test Suite

Тепер зовнішній розробник може не лише прочитати QWP, а й:

перевірити, чи його власна незалежна реалізація поводиться правильно.

144. Статус

QWP Conformance Test Suite v1.0 Candidate

Основні test families:

Positive

Negative

Indeterminate

Invalid

Boundary

Human Judgment

Authority

Identity

Process Assurance

Versioning

Extensions

Recognition Boundary

Provider Neutrality

Adversarial

API

145. Завершення

QWP Conformance Test Suite встановлює основу для:

• 
  незалежних implementations;

• 
  regression testing;

• 
  conformance claims;

• 
  interoperability challenges;

• 
  майбутнього certification process.

Його центральна вимога:

Незалежні QWP implementations можуть бути різними всередині, але не повинні суперечити одна одній у нормативному значенні однакових вхідних даних.