QUALIFICATION WEB PROTOCOL

QWP v1.0

Нормативна технічна специфікація

Статус документа: Candidate Normative Specification
Мова: українська
Версія: 1.0 Candidate
Система: Qualification Web
Протокол: Qualification Web Protocol
Скорочення: QWP

1. Статус специфікації

Цей документ визначає нормативну архітектуру Qualification Web Protocol (QWP) — відкритого протоколу представлення, перевірки та пояснення доказової основи кваліфікаційних рішень.

QWP призначений для систем, які повинні визначати:

чи підтримує конкретний набір доказів твердження про відповідність конкретної особи конкретній версії Qualification Specification.

QWP не є:

• 
  освітньою програмою;

• 
  університетом;

• 
  системою акредитації;

• 
  державним органом;

• 
  системою професійного ліцензування;

• 
  цифровим дипломом;

• 
  універсальним реєстром усіх освітніх даних.

QWP є:

нормативним evidence-to-qualification conformance protocol.

2. Нормативна мова

У цьому документі слова:

MUST
MUST NOT
REQUIRED
SHOULD
SHOULD NOT
RECOMMENDED
MAY
OPTIONAL

мають нормативне значення відповідно до BCP 14, RFC 2119 та RFC 8174 лише тоді, коли вони написані великими літерами.

Українські пояснення біля них є інформаційними.

Наприклад:

Qualification Proof MUST містити точний ідентифікатор версії Qualification Specification.

означає обов’язкову вимогу.

Натомість:

реалізація може відображати додаткову довідкову інформацію

не є нормативною вимогою, якщо MAY не використано як нормативне слово.

3. Мета QWP

Метою QWP є створення interoperable способу представлення обґрунтування кваліфікаційного рішення.

Протокол повинен дозволяти відповісти на питання:

1. 
   Яку qualification перевіряють?

2. 
   За якою версією вимог?

3. 
   Які claims мають бути доведені?

4. 
   Який evidence представлено?

5. 
   Як evidence було отримано?

6. 
   Хто його оцінював?

7. 
   Чи мав evaluator необхідні повноваження?

8. 
   Чому evidence підтримує конкретний claim?

9. 
   Де було необхідне human judgment?

10. 
    Який результат випливає з усієї структури?

11. 
    Які requirements залишаються непідтвердженими?

12. 
    Що система не може визначити?

4. Базовий принцип

Нормативна модель QWP ґрунтується на такій послідовності:

Qualification Specification

        ↓

Requirement

        ↓

Claim

        ↓

Evidence

        ↓

Assessment

        ↓

Validity Argument

        ↓

Authority / Assurance

        ↓

Qualification Proof

        ↓

Conformance Decision

Юридичні процеси знаходяться після цього ланцюга:

Conformance Decision

        ↓

Authorized Award

        ↓

Recognition

        ↓

Professional Authorization

QWP MUST NOT трактувати ці чотири поняття як синоніми.

5. Основний нормативний інваріант

Для QWP діє:

Academic Conformance ≠ Legal Award ≠ Recognition ≠ Professional Authorization

Це одна з головних вимог протоколу.

Реалізація MUST NOT робити висновок про legal award лише на основі AcademicConformance = PASS.

Реалізація MUST NOT робити висновок про professional authorization лише на основі academic qualification.

Реалізація MUST NOT оголошувати qualification legally recognised у певній jurisdiction без відповідного external recognition basis.

6. Scope

QWP визначає правила для:

• 
  Qualification Specifications;

• 
  Qualification Requirements;

• 
  Claims;

• 
  Evidence Objects;

• 
  Assessment Designs;

• 
  Assessment Events;

• 
  Validity Arguments;

• 
  Identity Assurance;

• 
  Authority Records;

• 
  Process Assurance;

• 
  Human Judgment Events;

• 
  Conflict Records;

• 
  Qualification Proofs;

• 
  Conformance Decisions;

• 
  Decision Traces;

• 
  Gap Reports;

• 
  versioning;

• 
  provenance;

• 
  validation;

• 
  conformance.

7. Out of Scope

QWP v1.0 не визначає:

• 
  єдину світову освітню програму;

• 
  єдину глобальну qualification framework;

• 
  curriculum для всіх disciplines;

• 
  універсальну державну accreditation system;

• 
  юридичні правила всіх jurisdictions;

• 
  загальну identity infrastructure;

• 
  глобальну payment system;

• 
  blockchain consensus;

• 
  єдину систему student records;

• 
  автоматичне професійне ліцензування.

Інші systems MAY інтегрувати ці функції з QWP.

Але вони не є обов’язковими компонентами самого протоколу.

8. Design Principle 1 — Мінімальна нова інфраструктура

QWP SHOULD використовувати існуючі відкриті стандарти там, де вони вже вирішують відповідну проблему.

Зокрема реалізації SHOULD розглядати:

• 
  JSON / JSON-LD для representation;

• 
  JSON Schema для structural validation;

• 
  RDF-compatible semantics;

• 
  SHACL для graph constraints;

• 
  W3C PROV-compatible provenance;

• 
  W3C Verifiable Credentials для verifiable credential envelopes;

• 
  існуючі competency та qualification vocabularies.

QWP SHOULD NOT створювати власний несумісний формат лише тому, що функціональність можна реалізувати локально.

9. Design Principle 2 — Evidence Before Prestige

QWP MUST NOT використовувати prestige educational provider як автоматичну заміну qualification evidence.

Provider identity MAY бути релевантним metadata.

Provider identity MAY бути нормативно важливим, якщо конкретна Qualification Specification цього обґрунтовано вимагає.

Але:

PrestigiousProvider = true

MUST NOT автоматично означати:

Requirement = SUPPORTED

10. Design Principle 3 — Provider Neutrality

Якщо два Qualification Proofs є еквівалентними щодо всіх qualification-relevant properties, learning provider сам по собі MUST NOT змінювати academic conformance decision.

У спрощеній формі:

Equivalent relevant evidence

+

Equivalent assessment conditions

+

Equivalent assurance

=

Equivalent conformance result

Цей принцип не означає context blindness.

Якщо context є частиною requirement, система MUST його враховувати.

Наприклад:

supervised clinical practice

не може бути замінено reading activity, якщо supervision і direct practice є частиною target construct.

11. Design Principle 4 — Authenticity Is Not Validity

QWP MUST розділяти:

authenticity / integrity

та:

validity of inference.

Якщо Evidence Object cryptographically authentic, це означає лише, що відповідні authenticity conditions виконані.

Це MUST NOT автоматично означати, що Evidence Object достатньо підтримує target Claim.

Наприклад:

EvidenceAuthenticity = VERIFIED

може співіснувати з:

ClaimSupport = INSUFFICIENT_EVIDENCE

12. Design Principle 5 — Unknown Is Not False

QWP MUST відрізняти:

evidence показує, що requirement не виконано

від:

evidence недостатньо для визначення результату.

Тому protocol MUST підтримувати стан:

INDETERMINATE

Система MUST NOT перетворювати відсутність evidence на негативний факт, якщо Specification прямо не встановлює таке правило.

13. Design Principle 6 — Human Judgment Is Explicit

QWP MUST NOT маскувати human judgment як machine-generated certainty.

Якщо рішення потребує expert review:

• 
  факт review MUST бути зафіксований;

• 
  reviewer MUST бути ідентифікований відповідно до applicable assurance rules;

• 
  criteria MUST бути доступні;

• 
  result MUST бути записаний;

• 
  rationale SHOULD бути доступним для high-stakes decisions.

14. Design Principle 7 — Explainability

Кожне final machine-assisted conformance decision MUST мати Decision Trace.

Decision Trace повинен дозволяти відновити щонайменше:

Qualification

→ Requirement

→ Claim

→ Evidence

→ Assessment

→ Authority

→ Validity / Review

→ Decision

Opaque score без explanation MUST NOT бути єдиним нормативним output QWP.

15. Design Principle 8 — Version Everything That Changes Meaning

Об’єкти, зміна яких може змінити decision semantics, MUST бути versioned.

Це включає щонайменше:

• 
  QWP specification;

• 
  Qualification Specification;

• 
  Decision Rules;

• 
  machine schemas;

• 
  applicable benchmark profiles.

Evaluation MUST бути прив’язаний до exact version.

16. Design Principle 9 — Replayability

Machine-derived decision SHOULD бути reproducible за однакових:

• 
  inputs;

• 
  specification versions;

• 
  rule versions;

• 
  engine version;

• 
  relevant evaluation time.

У спрощеній формі:

same input

+

same normative versions

+

same relevant time state

=

same machine decision

Human Judgment Events залишаються recorded inputs і не повинні штучно представлятися deterministic.

17. Design Principle 10 — Conservative High-Stakes Decisions

У high-stakes context реалізація SHOULD надавати перевагу:

INDETERMINATE

або:

HUMAN_REVIEW

замість необґрунтованого позитивного рішення.

Система MUST NOT підвищувати рівень certainty без supporting evidence.

18. Core Entity Model

QWP v1.0 визначає такі core entity classes:

QualificationSpecification

QualificationRequirement

Claim

EvidenceObject

AssessmentDesign

AssessmentEvent

ValidityArgument

IdentityAssurance

AuthorityRecord

ProcessAssurance

ConflictRecord

HumanJudgmentEvent

QualityAssuranceRecord

QualificationProof

ConformanceDecision

DecisionTrace

GapReport

RecognitionRecord

Ці entity classes формують мінімальну нормативну ontology протоколу.

19. QualificationSpecification

QualificationSpecification є versioned нормативним описом qualification target.

Він MUST містити щонайменше:

id

version

title

requirements

decisionRules

Він SHOULD містити:

description

field

level

frameworkAlignment

effectiveFrom

effectiveUntil

maintainer

provenance

Приклад:

id: qw:qualification:example-master

version: 1.0

title: Example Master-Level Qualification

level: 7

20. QualificationRequirement

QualificationRequirement представляє конкретну умову qualification.

Кожна requirement MUST мати:

id

title

requirementType

mandatoryStatus

Вона SHOULD мати:

description

claims

assessmentConstraints

evidenceConstraints

21. Requirement Types

QWP v1.0 визначає щонайменше:

MANDATORY

COMPENSABLE

INTEGRATIVE

MANDATORY

Невиконання requirement може спричинити FAIL.

COMPENSABLE

Decision Rules можуть дозволяти compensation іншими requirements.

INTEGRATIVE

Requirement перевіряє здатність інтегрувати декілька competencies.

Реалізація MUST NOT автоматично перетворювати всі integrative requirements на просту суму microclaims.

22. Claim

Claim є твердженням про candidate, яке повинно бути підтримане evidence.

Приклад:

Candidate can independently select and defend an appropriate research methodology.

Claim MUST бути пов’язаний щонайменше з однією Qualification Requirement.

Claim MUST NOT вважатися supported лише через факт enrollment або attendance, якщо Specification прямо не визначає attendance як relevant evidence.

23. EvidenceObject

EvidenceObject є інформаційним або performance object, що потенційно підтримує Claim.

Приклади:

• 
  exam result;

• 
  code;

• 
  research report;

• 
  oral defence record;

• 
  project;

• 
  simulation;

• 
  professional observation;

• 
  dataset;

• 
  verified credential;

• 
  portfolio artifact.

Evidence Object MUST бути distinguishable від Claim.

Тобто:

«Candidate is competent»

не може одночасно бути доказом самого себе без external supporting basis.

24. Перша фундаментальна нормативна формула

QWP використовує:

Evidence != Claim

і:

Authenticity(Evidence) != Validity(Inference)

та:

AcademicConformance != LegalRecognition

Ці три відмінності є фундаментальними для всього протоколу.

25. Conformance Classes

QWP визначатиме декілька рівнів conformance.

У v1.0 плануються щонайменше:

QWP Data Conformant

Система правильно представляє QWP data model.

QWP Validator Conformant

Система правильно виконує structural validation.

QWP Evaluator Conformant

Система реалізує normative conformance rules.

QWP Full Reference Conformant

Система підтримує complete required protocol behaviour.

Детальні requirements будуть визначені в наступних частинах цієї специфікації.

26. Мінімальна філософія conformance

Виробник software MUST NOT називати implementation повністю QWP-conformant лише тому, що вона може читати один QWP JSON document.

Conformance означає виконання конкретних normative requirements і проходження applicable Conformance Test Suite.

27. Architecture Boundary

QWP закінчується там, де закінчується technical/academic conformance authority.

Тобто:

QWP

|

+-- represents evidence

+-- validates structure

+-- evaluates defined requirements

+-- explains result

|

X

|

+-- does not invent legal authority

+-- does not self-grant accreditation

+-- does not create professional licence

Ця boundary MUST зберігатися в усіх conforming implementations.

28. Резюме частини 1

Перша частина QWP v1.0 встановлює:

• 
  scope протоколу;

• 
  normative language;

• 
  базові design principles;

• 
  межу між conformance та legal recognition;

• 
  provider neutrality;

• 
  validity/integrity separation;

• 
  uncertainty handling;

• 
  human judgment rules;

• 
  versioning;

• 
  replayability;

• 
  core entity model;

• 
  основи conformance classes.

Наступна частина визначить нормативну модель:

Evidence → Assessment → Validity → Authority → Assurance → Human Judgment → Qualification Proof

і точні стани підтримки кожної requirement.

QUALIFICATION WEB PROTOCOL

QWP v1.0 — Нормативна технічна специфікація

Частина 2. Evidence, Assessment, Validity, Authority та Human Judgment

29. Загальний доказовий ланцюг

QWP MUST представляти qualification conformance як ланцюг обґрунтування, а не як необґрунтоване числове значення.

Базова модель:

QualificationRequirement

↓

Claim

↓

EvidenceObject

↓

AssessmentEvent

↓

ValidityArgument

↓

AuthorityRecord

↓

Assurance

↓

HumanJudgment, where required

↓

RequirementDecision

Кожний перехід MUST бути доступним для audit або reconstruction.

Реалізація MUST NOT дозволяти final PASS, якщо неможливо встановити, які evidence підтримують mandatory requirements.

30. EvidenceObject

EvidenceObject є об'єктом, подією або записом, що потенційно підтримує один або декілька Claims.

EvidenceObject MUST мати:

id

type

subject

createdAt OR observedAt

provenance

status

EvidenceObject SHOULD мати:

creator

source

format

hash

issuer

verificationMethod

relatedAssessment

accessPolicy

31. Типи Evidence

QWP v1.0 визначає щонайменше такі класи:

ARTIFACT

PERFORMANCE

OBSERVATION

ASSESSMENT_RESULT

CREDENTIAL

PUBLICATION

DATASET

SOFTWARE

PORTFOLIO

PROFESSIONAL_RECORD

RESEARCH_CONTRIBUTION

OTHER

Implementations MAY розширювати список.

Extension MUST NOT змінювати normative semantics core classes.

32. Evidence Provenance

Кожний EvidenceObject, що використовується для high-stakes decision, MUST мати достатню provenance information.

Provenance SHOULD дозволяти встановити:

• 
  хто створив evidence;

• 
  коли;

• 
  за яких умов;

• 
  чи evidence змінювався;

• 
  хто його спостерігав;

• 
  з яких попередніх objects він походить;

• 
  які transformations було застосовано.

QWP SHOULD використовувати W3C PROV-compatible representation, коли RDF/Linked Data використовується в implementation. PROV-O є стабільною W3C Recommendation для representation provenance.

33. Evidence Integrity

Evidence Integrity стосується питання:

Чи є evidence тим об'єктом, за який його видають?

Стани:

VERIFIED

PARTIALLY_VERIFIED

UNVERIFIED

INVALID

REVOKED

VERIFIED MUST NOT означати:

Claim = SUPPORTED

Воно означає лише, що applicable integrity checks пройдені.

34. Verifiable Credentials

QWP MAY використовувати W3C Verifiable Credentials для evidence або credential envelopes.

W3C VC Data Model 2.0 є Recommendation з 15 травня 2025 року та визначає machine-verifiable модель issuer-holder-verifier для credentials.

QWP MUST NOT дублювати cryptographic credential layer, якщо existing standard задовольняє вимоги implementation.

Водночас:

VC cryptographically verified

MUST NOT автоматично означати:

educational claim valid

35. Evidence Admissibility

Не все справжнє evidence є admissible для кожної requirement.

Qualification Specification MAY встановлювати:

• 
  допустимий тип evidence;

• 
  максимальний age evidence;

• 
  minimum observation duration;

• 
  identity assurance level;

• 
  supervision requirements;

• 
  assessor requirements;

• 
  required independence;

• 
  required process assurance.

Приклад:

Requirement:

Advanced clinical interviewing

Admissible:

Observed supervised performance

Not sufficient alone:

Multiple-choice examination

36. Evidence Freshness

Для competencies, що можуть деградувати або швидко змінюватися, Specification SHOULD визначати freshness rule.

Наприклад:

evidenceMaxAge = 36 months

QWP MUST NOT вводити глобальний universal expiration period для всіх competencies.

Freshness є domain-specific property.

37. Evidence Reuse

Один EvidenceObject MAY підтримувати декілька Claims.

Проте реалізація MUST NOT автоматично вважати один evidence sufficient для всіх пов'язаних claims.

Кожний relationship:

EvidenceObject supports Claim

MUST мати власну justification або посилання на applicable ValidityArgument.

38. AssessmentDesign

AssessmentDesign визначає, як створюється evidence для перевірки певного construct.

AssessmentDesign MUST містити:

id

version

targetClaims

assessmentType

decisionCriteria

Для high-stakes use він SHOULD також містити:

constructDefinition

taskModel

scoringModel

assessorRequirements

identityRequirements

processRequirements

fairnessConsiderations

appealMechanism

39. Assessment Type

Core assessment types:

EXAMINATION

PROJECT

PORTFOLIO

ORAL_DEFENCE

OBSERVED_PERFORMANCE

SIMULATION

PRACTICAL_TASK

RESEARCH_ASSESSMENT

STRUCTURED_INTERVIEW

PEER_REVIEW

EXPERT_REVIEW

TRANSFER_TASK

COMPOSITE

COMPOSITE використовується, коли qualification claim потребує кількох complementary assessment forms.

40. Assessment Event

AssessmentEvent є конкретним застосуванням AssessmentDesign до candidate.

AssessmentEvent MUST містити:

id

assessmentDesign

candidate

date

evidenceGenerated

status

Для high-stakes assessment також MUST бути доступні:

assessor OR assessmentPanel

authorityReference

identityAssurance

processAssurance

41. Assessment ≠ Learning Activity

QWP MUST розрізняти:

LearningActivity

та:

AssessmentEvent

Факт:

Candidate completed course X

MUST NOT автоматично трактуватися як:

Candidate demonstrated all competencies associated with course X.

Якщо course completion itself є admissible evidence, Specification MUST визначити умови такого inference.

42. Construct

Кожний high-stakes AssessmentDesign SHOULD явно визначати target construct.

Наприклад:

Construct:

Ability to independently design and defend an advanced empirical study.

Construct SHOULD NOT бути сформульований як:

Ability to pass this test.

якщо qualification claim стосується ширшої competence.

43. Construct-Irrelevant Variance

Assessment SHOULD мінімізувати фактори, які впливають на result, але не є частиною target construct.

Приклади:

• 
  language complexity, якщо language proficiency не оцінюється;

• 
  unnecessary time pressure;

• 
  inaccessible interface;

• 
  unrelated technical knowledge.

QWP не визначає повну psychometric methodology, але conforming high-stakes profile SHOULD мати explicit fairness considerations.

44. ValidityArgument

ValidityArgument є центральним QWP object.

Він відповідає:

Чому observable evidence дозволяє підтримати конкретний Claim?

ValidityArgument MUST містити:

id

targetClaim

supportingEvidence

inference

status

Для high-stakes use SHOULD містити:

construct

assessmentBasis

assumptions

limitations

counterEvidence

reviewStatus

45. Validity States

QWP v1.0 визначає:

SUPPORTED

PARTIALLY_SUPPORTED

NOT_SUPPORTED

INSUFFICIENT_BASIS

CONTESTED

Ці states стосуються validity argument.

Вони не є автоматично final qualification decision.

46. Золоте правило валідності

Conforming implementation MUST NOT виконувати таке скорочення:

Evidence exists

→

Claim supported

Необхідний принаймні один explicit або inherited validity relation:

Evidence

+

Assessment

+

Inference

→

Claim support

47. Negative Evidence

QWP MAY представляти evidence, яке суперечить Claim.

Наприклад:

Claim:

Candidate can independently perform statistical analysis.

Evidence A:

Successful project.

Evidence B:

Failed supervised transfer task.

System MUST NOT приховувати material counter-evidence.

Decision Rules MUST визначати, як contradictory evidence обробляється.

48. AuthorityRecord

AuthorityRecord описує, чому конкретна особа або body має право робити певний assessment judgment.

AuthorityRecord MUST містити:

id

holder

scope

issuer

status

Він SHOULD містити:

validFrom

validUntil

jurisdiction

qualificationBasis

qualityAssuranceReference

revocationReference

49. Scope of Authority

Authority MUST бути scoped.

Наприклад:

Assessor A

Authorized:

Advanced quantitative methods

Not automatically authorized:

Clinical practice assessment

QWP MUST NOT припускати universal assessor authority.

50. Authority Status

Core states:

ACTIVE

EXPIRED

SUSPENDED

REVOKED

UNVERIFIED

High-stakes positive decision MUST NOT залежати від REVOKED authority.

Якщо authority status є UNVERIFIED, applicable Requirement SHOULD переходити до:

HUMAN_REVIEW

або:

INSUFFICIENT_EVIDENCE

залежно від Decision Rules.

51. IdentityAssurance

IdentityAssurance відповідає на питання:

Наскільки обґрунтовано система знає, хто саме є candidate або assessor?

Core levels:

IA-0 UNKNOWN

IA-1 SELF_ASSERTED

IA-2 BASIC_VERIFIED

IA-3 STRONG_VERIFIED

IA-4 HIGH_ASSURANCE

QWP v1.0 не визначає єдиного глобального identity provider.

External identity systems MAY бути використані.

52. Identifier ≠ Identity

Нормативний принцип:

DifferentIdentifier

!=

ProvenDifferentPerson

Conforming system MUST NOT вважати двох assessors незалежними лише тому, що вони мають різні textual IDs.

Якщо qualification rule вимагає independent assessors, required IdentityAssurance MUST бути визначений.

53. Candidate Identity

Якщо evidence має доводити особисту capability candidate, його attribution MUST мати достатній identity basis.

Наприклад:

portfolio file exists

не доводить:

candidate personally performed relevant work

якщо provenance та attribution недостатні.

54. ProcessAssurance

ProcessAssurance описує надійність умов, за яких evidence було отримано.

Core states:

PA-0 UNKNOWN

PA-1 SELF_REPORTED

PA-2 DOCUMENTED

PA-3 INDEPENDENTLY_OBSERVED

PA-4 CONTROLLED_HIGH_ASSURANCE

55. Що може підвищувати ProcessAssurance

Приклади:

• 
  authenticated session;

• 
  independent observation;

• 
  controlled environment;

• 
  supervised task;

• 
  signed process record;

• 
  oral defence;

• 
  time-bounded unseen task;

• 
  recorded practical performance.

QWP MUST NOT вимагати максимально високий level для кожного evidence.

Required level є proportional to risk.

56. AI-Assisted Evidence

QWP v1.0 визначає чотири базові режими:

AI_PROHIBITED

AI_RESTRICTED

AI_ALLOWED_DISCLOSED

AI_NATIVE

57. AI_PROHIBITED

AI assistance не допускається для конкретного assessment.

Якщо material AI assistance доведена відповідно до valid process:

AssessmentEvent MAY бути invalidated.

Проте mere suspicion MUST NOT автоматично дорівнювати proven violation.

58. AI_RESTRICTED

AI дозволений лише для визначених функцій.

Наприклад:

allowed:

grammar correction

not allowed:

method selection

analysis generation

AssessmentDesign MUST визначити дозволені й заборонені categories достатньо чітко для practical enforcement.

59. AI_ALLOWED_DISCLOSED

AI assistance дозволена за умови disclosure.

Сам факт AI використання MUST NOT автоматично знижувати result.

Assessment має перевіряти target human competence.

60. AI_NATIVE

AI use є нормальною частиною construct.

Наприклад:

candidate can responsibly supervise AI-assisted analysis.

Тут заборона AI могла б зменшувати construct validity.

61. Artifact Authorship Principle

QWP встановлює:

Artifact authorship ≠ Human competence

AI-generated або heavily assisted artifact MAY бути evidence context.

Але для claims про особисту capability Specification SHOULD вимагати independent corroboration.

Наприклад:

• 
  defence;

• 
  transfer task;

• 
  live explanation;

• 
  correction task;

• 
  unseen problem.

62. Hidden AI Use

Якщо AI use не observable із доступних даних, QWP MUST NOT вимагати від engine «вгадати» прихований факт.

System MAY повернути:

PROCESS_ASSURANCE_INSUFFICIENT

якщо authorship або attribution є critical.

Це принципово сильніше за необґрунтоване probabilistic accusation.

63. Capability Verification Principle

Для high-stakes qualification QWP SHOULD надавати перевагу:

direct verification capability

над:

attempt to infer tool absence.

Формула:

Verify capability

>

Guess authorship conditions

де це practically possible.

64. ConflictRecord

ConflictRecord описує потенційний або підтверджений conflict of interest.

Core categories:

NONE_DECLARED

FINANCIAL

SUPERVISORY

PERSONAL

ORGANIZATIONAL

SELF_ASSESSMENT

IDENTITY_OVERLAP

OTHER

UNKNOWN

65. Conflict Handling

Material unresolved conflict для high-stakes assessment MUST NOT бути silently ignored.

Possible results:

REASSESSMENT_REQUIRED

SECOND_REVIEW_REQUIRED

HUMAN_REVIEW

ASSESSMENT_INVALID

Applicable policy MUST визначати consequence.

66. Assessor Independence

Якщо Requirement вимагає N independent assessors, system MUST перевіряти не лише:

count(distinct assessor IDs)

а applicable independence conditions.

Це може включати:

• 
  identity assurance;

• 
  organizational independence;

• 
  conflict declarations;

• 
  panel composition rules.

67. HumanJudgmentEvent

HumanJudgmentEvent представляє expert decision.

Він MUST містити:

id

reviewer OR panel

target

decision

date

Для high-stakes use SHOULD містити:

criteria

evidenceReviewed

rationale

dissent

conflicts

authorityReferences

68. Human Judgment States

Core states:

SUPPORTED

NOT_SUPPORTED

CONTESTED

DEFERRED

REASSESSMENT_REQUIRED

69. Expert Disagreement

Якщо independent experts disagree, implementation MUST NOT автоматично усереднювати categorical judgment без applicable decision rule.

Specification MAY вимагати:

third reviewer

panel adjudication

consensus

majority

external review

Disagreement MUST залишатися auditable.

70. Human Review Trigger

System MUST підтримувати explicit trigger:

HUMAN_REVIEW

Його можна використовувати, коли:

• 
  evidence ambiguous;

• 
  authority uncertain;

• 
  validity contested;

• 
  material conflict unresolved;

• 
  holistic judgment required;

• 
  recognition issue виходить за scope engine;

• 
  applicable rule expressly requires expert review.

71. QualityAssuranceRecord

QualityAssuranceRecord представляє information про систему, process або organization, яка забезпечує якість assessment.

Він MAY містити:

scheme

auditor

standard

auditDate

status

scope

findings

QWP MUST NOT ототожнювати quality assurance scheme із legal accreditation, якщо такого status немає.

72. Requirement Support States

Для кожної QualificationRequirement QWP MUST підтримувати щонайменше:

SUPPORTED

NOT_SUPPORTED

INSUFFICIENT_EVIDENCE

CONTESTED

HUMAN_REVIEW

73. SUPPORTED

SUPPORTED означає:

наявний evidence та applicable assessment/validity/authority conditions достатньо підтримують requirement за current Specification.

Це не означає absolute truth.

Це protocol-level decision.

74. NOT_SUPPORTED

NOT_SUPPORTED означає:

available admissible evidence достатньо підтримує негативний decision відповідно до applicable rules.

Воно MUST NOT використовуватися лише тому, що evidence відсутній, якщо specification не встановлює такого правила.

75. INSUFFICIENT_EVIDENCE

Означає:

evidence недостатньо для позитивного або негативного conclusion.

Це один із core uncertainty states.

76. CONTESTED

Означає:

існує material conflict між evidence, assessors або validity arguments, який не розв'язано applicable rule.

77. HUMAN_REVIEW

Означає:

machine layer не має повноваження або достатнього basis для final requirement decision.

78. QualificationProof

QualificationProof є central aggregate object QWP.

Він MUST містити:

id

subject

qualificationSpecification

specificationVersion

requirements

evidence

assessmentRecords

decisionContext

Він SHOULD містити:

validityArguments

authorityRecords

identityAssurance

processAssurance

humanJudgments

conflicts

provenance

79. Proof Completeness

QualificationProof MUST NOT вважатися complete лише через наявність великої кількості evidence.

Completeness визначається coverage applicable requirements.

Приклад:

500 evidence objects

+

1 missing mandatory requirement

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

FAIL

або:

INDETERMINATE

залежно від rules.

80. QualificationProof Is Not a Credential

QualificationProof і Credential — різні objects.

QualificationProof:

містить/посилається на justification.

Credential:

представляє issued claim.

Після valid award система MAY видати Verifiable Credential, який посилається на QualificationProof або його allowed summary.

81. Privacy Boundary

Full QualificationProof SHOULD NOT автоматично бути public.

Implementation MUST підтримувати principle of data minimization.

Verifier SHOULD отримувати лише information, necessary for legitimate verification purpose.

82. Sensitive Evidence

Evidence, що містить:

• 
  medical information;

• 
  client data;

• 
  confidential professional records;

• 
  protected research data;

• 
  personal identifiers,

MUST NOT бути exposed лише тому, що воно входить до QualificationProof.

System SHOULD підтримувати:

• 
  redaction;

• 
  references;

• 
  derived attestations;

• 
  selective disclosure;

• 
  access controls.

83. Proof Status

QualificationProof MUST мати status.

Core values:

DRAFT

READY_FOR_EVALUATION

VALIDATED

EVALUATED

SUPERSEDED

REVOKED

INVALID

84. Proof Immutability and Revision

QWP SHOULD NOT вимагати physical immutability усіх records.

Замість цього revisions MUST бути traceable.

Якщо evaluated proof змінено materially:

• 
  old version MUST залишатися identifiable;

• 
  new version MUST мати new version/reference;

• 
  prior decision MUST NOT silently переноситися на changed proof.

85. Revocation

Evidence або AuthorityRecord MAY бути revoked після evaluation.

Якщо revocation material to previous decision, implementation SHOULD мати mechanism:

RE_EVALUATION_REQUIRED

QWP v1.0 не визначає universal re-evaluation frequency.

86. Structural Validation

Перед semantic evaluation QualificationProof MUST пройти structural validation.

Structural errors включають:

• 
  duplicate IDs;

• 
  dangling references;

• 
  invalid required types;

• 
  unsupported specification version;

• 
  impossible data structure;

• 
  required field absence.

87. Graph Validation

Для RDF-compatible implementation graph constraints MAY бути представлені через SHACL.

SHACL є стабільною W3C Recommendation для опису і validation RDF graph constraints.

QWP не робить SHACL mandatory для всіх implementations.

Але normative semantic constraints MUST бути еквівалентно забезпечені.

88. Duplicate Identifier Rule

У межах одного QualificationProof:

id

для normative objects MUST бути unique у визначеному identifier scope.

Duplicate normative identifier MUST спричинити:

INVALID_PROOF

а не ambiguous evaluation.

89. Evaluation Preconditions

QCE MUST NOT переходити до final conformance evaluation, якщо:

StructuralValidation = FAILED

або якщо critical specification version unavailable.

90. Principle of Observability

QWP engine MUST робити decisions лише з:

• 
  available evidence;

• 
  referenced external trusted state;

• 
  explicit rules;

• 
  recorded human judgments.

Engine MUST NOT представляти unobserved facts як verified facts.

91. Principle of Explicit Assumptions

Якщо decision залежить від assumption, яка не є безпосередньо verified, assumption SHOULD бути represented.

Наприклад:

Assumption:

Assessor independence accepted based on external institutional attestation.

Це забезпечує auditability.

92. Мінімальний доказовий інваріант

Для positive support mandatory requirement повинна існувати реконструйована послідовність:

Requirement

↓

Claim

↓

Evidence

↓

Assessment basis

↓

Validity basis

↓

Required authority/assurance

↓

SUPPORTED

Якщо required link відсутній:

SUPPORTED MUST NOT бути assigned.

93. Чого QWP навмисно не автоматизує

QWP v1.0 MUST NOT вимагати fully automated judgment щодо:

• 
  doctoral originality;

• 
  professional wisdom;

• 
  ethical maturity;

• 
  artistic quality;

• 
  complex holistic capability,

якщо відповідна Qualification Specification визначає human expert judgment.

Протокол стандартизує representation decision, а не примусову automated replacement expert.

94. Резюме частини 2

Друга частина QWP v1.0 встановлює нормативну модель:

Evidence

→ Assessment

→ Validity

→ Authority

→ Identity Assurance

→ Process Assurance

→ Human Judgment

→ Qualification Proof

а також:

• 
  evidence integrity;

• 
  admissibility;

• 
  provenance;

• 
  AI-assisted evidence;

• 
  conflict handling;

• 
  assessor independence;

• 
  human review;

• 
  privacy;

• 
  revocation;

• 
  proof status;

• 
  structural validation;

• 
  requirement support states.

Головний принцип:

QWP не намагається зробити кожний висновок автоматичним. Він вимагає, щоб кожний важливий висновок був обґрунтованим і простежуваним.

QUALIFICATION WEB PROTOCOL

QWP v1.0 — Нормативна технічна специфікація

Частина 3. Механізм перевірки відповідності, рішення та пояснення

95. Призначення механізму перевірки

QWP Conformance Engine (QCE) — це механізм, який перевіряє, чи відповідає конкретний доказовий пакет конкретній версії специфікації кваліфікації.

QCE не визначає:

• 
  чи є кандидат «хорошим фахівцем» у загальному сенсі;

• 
  чи має кандидат право на професійну діяльність;

• 
  чи визнає держава відповідний ступінь;

• 
  чи є заклад освіти акредитованим;

• 
  чи буде роботодавець задоволений кандидатом.

QCE виконує вужче завдання:

перевіряє відповідність наданих доказів формально визначеним вимогам кваліфікації.

96. Базова функція QCE

Спрощено механізм можна подати так:

QCE(

QualificationProof,

QualificationSpecification,

DecisionRules,

EvaluationTime

)

→

ConformanceDecision

де:

• 
  QualificationProof — доказовий пакет кандидата;

• 
  QualificationSpecification — версія вимог кваліфікації;

• 
  DecisionRules — правила ухвалення рішення;

• 
  EvaluationTime — момент перевірки;

• 
  ConformanceDecision — результат перевірки.

97. Обов’язкові операції

Система, що заявляє підтримку базового QWP Evaluator, MUST реалізовувати щонайменше чотири основні операції:

validate

evaluate

explain

gaps

98. Операція validate

validate відповідає на питання:

Чи є доказовий пакет структурно придатним для подальшої перевірки?

Вона MUST перевіряти щонайменше:

• 
  наявність обов’язкових полів;

• 
  унікальність нормативних ідентифікаторів;

• 
  цілісність внутрішніх посилань;

• 
  доступність версії специфікації;

• 
  сумісність типів об’єктів;

• 
  наявність обов’язкових зв’язків;

• 
  коректність формату даних.

99. Результати validate

Базові результати:

VALID

INVALID_PROOF

Розширена реалізація MAY повертати детальніший перелік помилок.

Наприклад:

INVALID_PROOF

Reason:

Duplicate identifier

Object:

evidence:project-17

або:

INVALID_PROOF

Reason:

Dangling reference

Reference:

authority:A-144

100. Заборона оцінювання некоректного пакета

Якщо:

validate = INVALID_PROOF

QCE MUST NOT виконувати звичайне кваліфікаційне оцінювання.

Некоректна структура не повинна автоматично перетворюватися на FAIL.

Правильний статус:

INVALID_PROOF

101. Операція evaluate

evaluate визначає стан кожної вимоги кваліфікації, а потім формує загальне рішення.

Процес:

Specification

↓

Requirements

↓

Claim support

↓

Evidence admissibility

↓

Assessment validity

↓

Authority / Assurance

↓

Human review

↓

Requirement decisions

↓

Qualification decision

102. Порядок перевірки вимоги

Для кожної вимоги QCE SHOULD виконувати логіку приблизно в такій послідовності:

1. 
   Чи існує вимога?

2. 
   Чи визначені твердження, які її представляють?

3. 
   Чи надані докази?

4. 
   Чи допустимі ці докази?

5. 
   Чи автентичні вони настільки, наскільки це потрібно?

6. 
   Чи є оцінювання придатним для потрібного висновку?

7. 
   Чи достатньо сильне обґрунтування валідності?

8. 
   Чи має оцінювач належні повноваження?

9. 
   Чи достатньо підтверджено особу?

10. 
    Чи достатньо підтверджено умови процесу?

11. 
    Чи є нерозв’язані конфлікти інтересів?

12. 
    Чи потрібне експертне рішення людини?

13. 
    Який стан вимоги випливає з усієї сукупності?

103. Стани окремої вимоги

QWP MUST підтримувати:

SUPPORTED

NOT_SUPPORTED

INSUFFICIENT_EVIDENCE

CONTESTED

HUMAN_REVIEW

104. SUPPORTED

SUPPORTED означає:

достатні допустимі докази підтримують відповідну вимогу за чинною версією правил.

Рішення SUPPORTED MUST мати простежуваний доказовий шлях.

105. NOT_SUPPORTED

NOT_SUPPORTED означає:

наявні допустимі дані достатньо підтримують негативний висновок.

Наприклад:

• 
  кандидат не пройшов обов’язкове оцінювання;

• 
  незалежне оцінювання виявило відсутність необхідної компетентності;

• 
  обов’язковий інтегративний компонент оцінено негативно.

106. INSUFFICIENT_EVIDENCE

INSUFFICIENT_EVIDENCE означає:

недостатньо даних для позитивного або негативного висновку.

Це не рівнозначно FAIL.

Приклад:

кандидат не надав доказу кількісного аналізу.

Це може означати:

INSUFFICIENT_EVIDENCE

а не:

NOT_SUPPORTED

якщо відсутність доказу не є сама по собі негативним результатом.

107. CONTESTED

CONTESTED використовується, якщо:

• 
  експерти суттєво не погоджуються;

• 
  різні докази суперечать один одному;

• 
  існує нерозв’язаний конфлікт оцінок;

• 
  обґрунтування валідності суттєво оскаржується.

108. HUMAN_REVIEW

HUMAN_REVIEW означає:

автоматизована частина системи не повинна ухвалювати остаточне рішення.

Цей стан застосовується, зокрема, коли:

• 
  потрібне цілісне експертне судження;

• 
  доказ неоднозначний;

• 
  питання виходить за межі формальних правил;

• 
  специфікація прямо вимагає експертної перевірки;

• 
  наявне суттєве невирішене питання валідності або повноважень.

109. Типи вимог

QWP використовує щонайменше:

MANDATORY

COMPENSABLE

INTEGRATIVE

110. Обов’язкова вимога — MANDATORY

Якщо обов’язкова вимога має стан:

NOT_SUPPORTED

загальне рішення SHOULD бути:

FAIL

якщо специфікація прямо не передбачає іншу процедуру.

Якщо обов’язкова вимога має:

INSUFFICIENT_EVIDENCE

або:

HUMAN_REVIEW

загальне рішення SHOULD бути:

INDETERMINATE

доки невизначеність не усунуто.

111. Компенсована вимога — COMPENSABLE

COMPENSABLE означає, що слабший результат в одному компоненті може бути компенсований сильнішими результатами в інших, якщо це дозволяє специфікація.

Але правила компенсації MUST бути визначені наперед.

QCE MUST NOT самостійно вигадувати ваги після перегляду результатів кандидата.

112. Приклад компенсації

Наприклад:

Requirement A weight = 30

Requirement B weight = 30

Requirement C weight = 40

Minimum total = 70

Minimum each requirement = 40%

У такій моделі:

A = 80

B = 65

C = 75

може відповідати кваліфікації.

Але:

A = 95

B = 10

C = 95

може не відповідати, якщо B нижче мінімального порогу.

113. Заборона прихованої компенсації

Реалізація MUST NOT дозволяти високі результати в одній сфері автоматично компенсувати критичний провал в іншій, якщо специфікація цього не передбачає.

Наприклад:

високий рівень статистики

не повинен автоматично компенсувати:

провал етичної компетентності.

114. Інтегративна вимога — INTEGRATIVE

INTEGRATIVE перевіряє не суму дрібних елементів, а їх поєднання.

Приклад:

кандидат здатний самостійно спроєктувати, виконати, критично оцінити й захистити складний дослідницький проєкт.

Цю вимогу MUST NOT автоматично вважати виконаною лише тому, що окремі мікрокомпоненти мають позитивний статус.

115. Integrative Capstone

Для рівнів, де необхідна автономна інтегрована компетентність, специфікація SHOULD включати окремий інтегративний компонент.

Він може перевіряти одночасно:

knowledge

+

method

+

judgment

+

ethics

+

communication

+

autonomy

116. Загальні рішення кваліфікації

QWP MUST підтримувати щонайменше три основні результати:

PASS

FAIL

INDETERMINATE

Додатково технічна реалізація MAY використовувати:

INVALID_PROOF

як окремий статус до початку змістовного оцінювання.

117. PASS

PASS означає:

усі необхідні умови специфікації задоволені відповідно до чинних правил.

PASS MUST NOT означати:

• 
  юридичне присудження ступеня;

• 
  державне визнання;

• 
  професійну ліцензію;

• 
  автоматичну еквівалентність іншій кваліфікації.

118. FAIL

FAIL означає:

одна або більше вимог мають негативний стан, який за правилами специфікації унеможливлює відповідність.

QCE MUST пояснювати, які саме вимоги призвели до FAIL.

119. INDETERMINATE

INDETERMINATE означає:

на цей момент немає достатньої підстави для обґрунтованого PASS або FAIL.

Причини можуть включати:

• 
  недостатність доказів;

• 
  незавершений human review;

• 
  невизначеність повноважень;

• 
  суперечливі дані;

• 
  недостатню надійність процесу;

• 
  відсутність критичної інформації.

120. Принцип обережності

Для високоризикових рішень QCE SHOULD надавати перевагу:

INDETERMINATE

замість необґрунтованого:

PASS

якщо критична невизначеність не усунена.

121. DecisionRules

DecisionRules визначають, як requirement-level decisions перетворюються на загальний результат.

Вони MUST бути:

• 
  версіонованими;

• 
  доступними для аудиту;

• 
  застосованими однаково до всіх кандидатів у межах однакового контексту;

• 
  встановленими до оцінювання конкретного кандидата.

122. Мінімальна структура DecisionRules

id

version

qualificationSpecification

mandatoryRules

compensationRules

integrativeRules

humanReviewRules

failureRules

indeterminateRules

123. Заборона постфактумного переписування правил

Правила MUST NOT змінюватися після перегляду результатів конкретного кандидата лише для отримання бажаного результату.

Якщо правила змінено:

• 
  створюється нова версія;

• 
  старе рішення залишається пов’язаним зі старою версією;

• 
  нове оцінювання MAY виконуватися окремо.

124. Операція explain

explain повертає обґрунтування рішення.

Система MUST бути здатна пояснити щонайменше:

• 
  яка вимога перевірялася;

• 
  які докази використані;

• 
  яке оцінювання враховане;

• 
  які правила застосовані;

• 
  де застосоване експертне рішення;

• 
  яка причина кінцевого стану.

125. Приклад пояснення

Requirement:

Advanced quantitative reasoning

Status:

INSUFFICIENT_EVIDENCE

Evidence found:

Course certificate

Project report

Missing:

Independent assessment demonstrating

the candidate's own quantitative capability

Result:

Requirement not yet supportable

126. Explainability ≠ розкриття всіх даних

Вимога пояснюваності MUST NOT автоматично означати повне розкриття конфіденційних доказів.

Система SHOULD підтримувати пояснення на рівні:

що було перевірено і чому прийнято рішення

без розкриття зайвих персональних або конфіденційних даних.

127. DecisionTrace

Кожне кінцеве машинно підтримане рішення MUST мати DecisionTrace.

Мінімальний ланцюг:

Qualification

→ Requirement

→ Claim

→ Evidence

→ Assessment

→ Validity basis

→ Authority / Assurance

→ Requirement status

→ Final decision

128. Властивості DecisionTrace

DecisionTrace MUST бути:

• 
  простежуваним;

• 
  пов’язаним із версіями;

• 
  відтворюваним настільки, наскільки це стосується машинних правил;

• 
  незмінно пов’язаним із конкретним рішенням;

• 
  достатнім для незалежного аудиту логіки.

129. Операція gaps

gaps визначає, чого саме бракує для відповідності кваліфікації.

Gap Report SHOULD бути орієнтований на дію.

Він не повинен просто повідомляти:

не пройдено.

Він SHOULD пояснювати:

що саме потрібно додати, повторно оцінити або підтвердити.

130. GapReport

Мінімальна структура:

qualification

currentStatus

missingRequirements

insufficientEvidence

pendingHumanReview

invalidEvidence

recommendedNextEvidenceType

131. Приклад Gap Report

Target:

Master-Level Psychology

Current status:

INDETERMINATE

Gap:

Advanced quantitative reasoning

Reason:

No independently assessed evidence

Acceptable next step:

Complete an admissible quantitative

analysis task with independent assessment

132. Gap Report не є навчальною програмою

QWP MUST NOT автоматично трактувати Gap Report як повну навчальну рекомендацію.

Система може сказати:

чого бракує для доказу,

але це не тотожно:

як саме людина повинна навчитися цього.

133. Повторне оцінювання

Після додавання нового evidence кандидат MAY подати оновлену версію QualificationProof.

Нове оцінювання MUST мати:

• 
  новий evaluation record;

• 
  timestamp;

• 
  посилання на нову версію proof;

• 
  точну версію DecisionRules.

134. Replayability

Для машинної частини повторна перевірка SHOULD давати однаковий результат за однакових:

Proof version

Specification version

DecisionRules version

Engine version

Relevant external state

Evaluation time

135. Час як частина рішення

Час MAY змінювати результат.

Наприклад:

• 
  строк дії повноважень оцінювача минув;

• 
  evidence стало застарілим;

• 
  credential відкликано;

• 
  змінився статус зовнішнього джерела.

Тому Evaluation Time MUST бути записаний для високоризикових рішень.

136. Детермінованість

QCE SHOULD бути детермінованим щодо формалізованих правил.

Тобто:

same inputs

+

same rules

+

same relevant external state

=

same machine output

137. Людське рішення не є детермінованим правилом

Якщо результат залежить від HumanJudgmentEvent, QCE MUST трактувати його як зафіксований вхід, а не вдавати, що людське судження було згенероване алгоритмом.

138. Повторний перегляд human judgment

Human judgment MAY бути:

• 
  переглянуте;

• 
  оскаржене;

• 
  замінене рішенням апеляції;

• 
  доповнене третім оцінювачем.

Такі зміни MUST залишати audit trail.

139. Апеляція

QWP не визначає універсальну процедуру апеляції для всіх систем.

Але високоризиковий профіль SHOULD мати:

• 
  спосіб оскарження;

• 
  фіксацію подання;

• 
  фіксацію рішення;

• 
  посилання на нове або змінене рішення;

• 
  збереження попереднього стану для аудиту.

140. Оцінювання за кількома специфікаціями

Один і той самий QualificationProof MAY бути оцінений щодо кількох різних специфікацій.

Наприклад:

Proof P

→ Qualification A v1.0

Proof P

→ Qualification B v2.1

Результати MUST зберігатися окремо.

141. Заборона автоматичної еквівалентності

Якщо Candidate отримав:

PASS for Qualification A

це MUST NOT автоматично означати:

PASS for Qualification B

навіть якщо обидві кваліфікації мають однаковий рівень.

142. Рівень ≠ еквівалентність

Наприклад:

Qualification A = Level 7

Qualification B = Level 7

не означає:

Qualification A = Qualification B

Спільний рівень може показувати приблизну складність або рівень автономності, але не однаковість:

• 
  змісту;

• 
  результатів навчання;

• 
  практики;

• 
  дослідницьких вимог;

• 
  правових наслідків.

143. Порівняння кваліфікацій

Система MAY мати окремий Compare Layer.

Він може порівнювати:

• 
  рівні;

• 
  галузі;

• 
  вимоги;

• 
  research components;

• 
  professional practice;

• 
  assessment constraints;

• 
  framework alignment.

Але Compare Layer MUST NOT видавати юридичну еквівалентність без відповідного зовнішнього рішення.

144. Межа академічної відповідності

QCE завершує свою основну роботу на:

AcademicConformanceDecision

Після цього можуть починатися інші процеси:

Awarding

Recognition

ProfessionalAuthorization

Вони знаходяться поза основною нормативною компетенцією QCE.

145. Authorized Award

AuthorizedAward означає, що організація або інший уповноважений суб’єкт юридично присудив qualification.

QWP MUST NOT генерувати AuthorizedAward = TRUE лише через академічний PASS.

146. Recognition