Версія: 1.0
Статус: нормативний документ
Пов’язаний стандарт: Noetrail Technical Specification v1.0
Мова: українська
Тип документа: Conformance and Testing Specification
Цей документ визначає, як перевіряється відповідність software system, agent, registry, library або іншої implementation стандарту Noetrail v1.0.
Документ встановлює:
рівні conformance;
обов’язкові tests;
test identifiers;
input fixtures;
expected behavior;
правила PASS/FAIL;
error expectations;
interoperability tests;
governance tests;
формат conformance report.
Conformance не означає:
«система науково правильна».
Conformance означає:
система правильно реалізує нормативні семантичні правила Noetrail.
Тому можливе:
Noetrail conformant
but scientifically poor
і навпаки:
scientifically useful
but not Noetrail conformant
Conformance target може бути:
validator;
policy engine;
scientific agent;
registry;
API;
command-line utility;
workflow engine;
software library;
institutional platform.
Об’єкт тестування надалі називається:
Noetrail v1.0 визначає чотири рівні.
Рівень
Назва
Що доводить
L1
Structural
implementation правильно читає core objects
L2
Semantic
implementation правильно виконує core semantics
L3
Interoperability
objects можна переносити між systems
L4
Governance
зберігаються version/history/challenge semantics
Вищий рівень включає всі нижчі.
Тобто:
L4 includes L3 + L2 + L1
Implementation НЕ ПОВИННА заявляти просто:
Noetrail compliant
Рекомендована форма:
Noetrail v1.0
Level 2 Semantic Conformant
Кожен test має результат:
PASS
FAIL
SKIP
NOT_APPLICABLE
Очікувана поведінка отримана.
Нормативна вимога порушена.
Test не виконаний.
SKIP НЕ рахується як PASS.
Test не стосується declared implementation type.
Щоб отримати певний conformance level:
усі mandatory tests цього рівня та всіх нижчих рівнів повинні мати PASS.
Один mandatory FAIL означає:
claimed level NOT PASSED.
Reference fixture:
{
"test_id": "NTRL-C001",
"input": {},
"expected": {
"result": "VALID"
}
}
Conformance tests використовують namespace:
NTRL-Cxxx
Errors:
NTRL-Exxx
Перевірити, що implementation приймає valid core EpistemicState.
{
"type": "EpistemicState",
"id": "state-001",
"version": "1.0.0",
"objective": "Evaluate robustness of claim A"
}
VALID
Implementation приймає object без structural error.
{
"type": "EpistemicPolicy",
"id": "policy-001",
"version": "1.0.0",
"title": "Example Policy",
"scope": {
"domain": "example"
},
"input_profile": {},
"output_contract": {
"required": ["recommended_action"]
},
"actions": [
"experiment"
],
"artifact_hash": {
"algorithm": "sha256",
"value": "EXAMPLE"
}
}
Expected:
VALID
Input:
{
"type": "ChallengeProfile",
"id": "challenge-001",
"version": "1.0.0",
"incumbent": {
"id": "policy-a",
"version": "1.0.0"
},
"challengers": [
{
"id": "policy-b",
"version": "1.0.0"
}
],
"metrics": [],
"prospective": true,
"locked": true
}
Expected:
VALID
{
"type": "DecisionRecord",
"id": "decision-001",
"version": "1.0.0",
"challenge_profile_id": "challenge-001",
"decision": "inconclusive",
"timestamp": "2026-09-26T12:00:00Z"
}
Expected:
VALID
Input policy без:
artifact_hash
Expected:
INVALID
Рекомендований error:
NTRL-E101
Input:
{
"type": "SuperScientificPolicy"
}
Expected:
INVALID
Input:
{
"version": ""
}
Expected:
INVALID
Наприклад:
{
"actions": [
"magically_prove_truth"
]
}
без namespace extension.
Expected:
INVALID
або в permissive mode:
VALID_WITH_WARNING
але strict conformance testing вимагає:
INVALID
Implementation отримує:
Level 1 Structural Conformance
якщо пройдено:
C001–C008
Це найважливіший рівень для Noetrail.
L1 перевіряє JSON.
L2 перевіряє сенс.
Registry already contains:
policy-x:1.0.0
hash = AAA
New submission:
policy-x:1.0.0
hash = BBB
Expected:
REJECT
Error:
NTRL-E201
Existing:
policy-x:1.0.0
hash = AAA
New object identical.
Expected:
IDENTICAL / ALREADY_REGISTERED
Не conflict.
Existing:
policy-x:1.0.0
New:
policy-x:1.1.0
Expected:
ACCEPT
як separate version.
Challenge:
{
"prospective": false,
"locked": false
}
Decision:
{
"decision": "promote"
}
Expected:
REJECT
Error:
NTRL-E301
Це один із центральних tests Noetrail.
Challenge:
prospective = false
Decision:
inconclusive
Expected:
ACCEPT
Challenge:
prospective = true
locked = true
completed = true
all required gates = passed
Decision:
promote
Expected:
ACCEPT
Challenge має:
required gates = 3
passed = 2
failed = 1
Decision:
promote
Expected:
REJECT
Input:
decision = inconclusive
Expected:
VALID
Implementation НЕ ПОВИННА вимагати winner.
Policy requires:
measurement_uncertainty
State не має цього field.
Expected:
NOT_APPLICABLE
або structured error.
Implementation НЕ ПОВИННА invent value.
Policy declares:
experiment
measurement_audit
Output:
model_generation
Expected:
REJECT
Policy declares:
protected = true
minimum_probability = 0.30
Runtime attempts:
exploration_probability = 0.10
Expected:
REJECT
якщо немає declared exception.
Policy:
minimum exploration = 0.30
але:
safety_constraint = true
і policy explicitly declares safety exception.
Expected:
ALLOW_OVERRIDE
із recorded reason.
Policy validated for:
synthetic model inadequacy detection
Implementation НЕ ПОВИННА автоматично re-label її:
universal scientific policy
Expected:
scope preserved
Valid policy object.
Implementation output must NOT automatically be:
scientifically_valid = true
Conformance system має використовувати формулювання на кшталт:
structurally_valid = true
Policy output:
experiment
Expected:
implementation НЕ ПОВИННА автоматично трактувати цей факт як execution authorization, якщо execution layer має separate authorization requirement.
Для:
Noetrail v1.0 Level 2 Semantic Conformance
обов’язково:
C001–C008
+
C101–C115
усі mandatory tests мають PASS.
Перевірити, що:
Noetrail object створений системою A правильно читається системою B.
Це критично.
Інакше маємо просто ще один proprietary JSON format.
System A export:
EpistemicPolicy
System B import → export.
Expected:
ID preserved;
version preserved;
scope preserved;
actions preserved;
hash preserved.
Input:
{
"extensions": {
"org.example.future": {
"unknown_field": 42
}
}
}
System не знає extension.
Після import/export:
unknown_field = 42
ПОВИНЕН залишитися.
Extension:
org.example:test
намагається redefine:
prospective = true
коли core:
prospective = false
Expected:
core wins.
Extension НЕ МОЖЕ override.
Object передано через:
file
і:
HTTP
Core semantics повинні бути identical.
Input A:
{"id":"x","version":"1.0.0"}
Input B:
{
"version": "1.0.0",
"id": "x"
}
Semantic interpretation:
same
System A registry export.
System B import.
Expected:
identities preserved;
status preserved;
context preserved;
evidence links preserved.
ChallengeProfile передається між systems.
System B повинна зберегти:
prospective
locked
metrics
gates
benchmark reference
DecisionRecord round-trip.
Expected:
не втрачено:
decision
gate_results
timestamp
challenge reference
Hash:
sha256:ABC
до transfer.
Після transfer:
sha256:ABC
Дві implementations отримують invalid retrospective promotion.
Обидві повинні classify:
non-conformant
Текст error message може відрізнятися.
Semantic result — ні.
Потрібні:
L1 PASS
L2 PASS
C201–C210 PASS
Перевірити не лише current object, а:
чи правильно system поводиться з історією policy.
Registry:
policy-x:1.0.0
Після появи:
policy-x:2.0.0
v1.0.0 НЕ ПОВИННА зникнути.
Challenger програв.
Expected:
ChallengeProfile та DecisionRecord зберігаються.
System НЕ ПОВИННА auto-delete failure.
Policy transition:
incumbent
→ deprecated
History повинна бути доступною.
Old policy:
status = superseded
і:
superseded_by = policy-y:2.0.0
Expected:
relationship preserved.
Policy artifact v1:
hash = AAA
System replaces same (id, version) with:
hash = BBB
Expected:
REJECT
Valid:
draft
→ locked
→ running
→ completed
Expected:
PASS.
Challenge:
status = locked
User changes gate threshold.
Expected:
REJECT
або require new ChallengeProfile version.
Challenge may transition:
locked
→ void
якщо technical invalidation documented.
Expected:
challenge remains in history.
Removed registry object.
Expected:
minimal record remains, якщо legal/privacy constraints дозволяють.
Наприклад:
withdrawn
reason
date
New DecisionRecord НЕ ПОВИНЕН overwrite old DecisionRecord.
History must remain reconstructable.
Policy може бути:
incumbent
у context A
і:
experimental
у context B.
System повинна зберігати context.
Given policy ID, system повинна мати можливість reconstruct:
versions
challenges
decisions
status changes
для retained history.
Потрібні:
L1 PASS
L2 PASS
L3 PASS
C301–C312 PASS
Noetrail Core v1.0 не є security standard, тому ці tests рекомендовані, але не всі є mandatory для базового conformance.
Expected:
INTEGRITY_ERROR
Same identity, different hash.
Expected:
CONFLICT
Extension contains executable payload.
Expected:
implementation не executes automatically.
System receives retired policy.
Expected:
warning або rejection відповідно до governance profile.
Provenance URL unavailable.
Core object MAY remain parseable.
Implementation НЕ ПОВИННА silently invent missing provenance content.
Conformance package СЛІД містити щонайменше:
valid/
invalid/
semantic/
interop/
governance/
security/
Наприклад:
tests/
valid/
state.json
policy.json
challenge.json
decision.json
invalid/
missing-hash.json
invalid-type.json
semantic/
retrospective-promotion.json
protected-exploration.json
Для tests із deterministic output МОЖНА використовувати:
golden files
тобто expected normalized output.
Test suite НЕ ПОВИННА вимагати reference implementation internals.
Інакше alternate implementation фактично змушена копіювати reference code.
Tests повинні перевіряти:
behavior.
Не:
architecture.
Noetrail implementation може бути написана:
Python
R
JavaScript
Rust
Java
Go
other
Conformance однакова.
Для deterministic policy output можна тестувати exact result.
Для stochastic policy:
test НЕ ПОВИНЕН вимагати однакової sequence random choices, якщо specification цього не визначає.
Тестувати слід:
declared distribution;
bounds;
constraints;
seeds, якщо вони normative.
Якщо conformance test перевіряє probability:
p = 0.30
через sampling, потрібен tolerance.
Наприклад:
expected range:
0.27–0.33
за достатнього sample size.
Але точні statistical tolerances мають бути визначені конкретним fixture.
Рекомендований формат:
NOETRAIL CONFORMANCE REPORT
Standard:
Noetrail v1.0
Implementation:
ExampleEngine
Implementation Version:
2.4.1
Claimed Level:
Level 3 — Interoperability
Test Suite:
Noetrail Conformance Suite 1.0
Tests:
L1: 8/8 PASS
L2: 15/15 PASS
L3: 10/10 PASS
Overall:
PASS
Рекомендований JSON:
{
"standard": "Noetrail",
"standard_version": "1.0",
"implementation": "ExampleEngine",
"implementation_version": "2.4.1",
"claimed_level": 3,
"result": "PASS"
}
Conformance report СЛІД містити:
test_suite_version
date
environment
implementation_hash
test_results
Report МОЖЕ містити:
sha256
для exact test bundle.
Це дозволяє пов’язати claim із конкретними artifacts.
Якщо implementation тестує власний author/team:
evaluation_type:
self_conformance
Якщо інша codebase:
evaluation_type:
cross_implementation
Лише зовнішня independent organization:
evaluation_type:
external
Self-test PASS НЕ СЛІД називати:
independently certified
Cross-implementation PASS у тому самому project НЕ СЛІД називати:
external institutional validation
Noetrail v1.0 наразі не визначає formal certification authority.
Отже правильне формулювання:
Passed Noetrail v1.0 Level 2 Conformance Suite
а не:
Officially certified by Noetrail.
Якщо test fail:
{
"test_id": "NTRL-C104",
"result": "FAIL",
"expected": "REJECT",
"observed": "ACCEPT",
"error": "Retrospective promotion accepted"
}
Якщо implementation проходить:
L1 PASS
L2 FAIL
дозволений claim:
Noetrail v1.0 Level 1 Structural Conformant
Не Level 2.
Conformance Suite також ПОВИННА мати version.
Наприклад:
1.0.0
Зміна expected semantics потребує нової suite version.
Якщо test suite суперечить Technical Specification:
Technical Specification має нормативний пріоритет.
Test suite повинна бути виправлена.
Якщо implementation використовує alternate UI label, це допустимо.
Machine semantics повинні залишатися canonical.
Наприклад UI:
«Перевірка вимірювання»
Machine value:
measurement_audit
Requirement
L1
L2
L3
L4
Core object parsing
✓
✓
✓
✓
Schema validation
✓
✓
✓
✓
Version semantics
✓
✓
✓
Prospectivity
✓
✓
✓
Protected exploration
✓
✓
✓
Cross-system exchange
✓
✓
Extension preservation
✓
✓
Policy history
✓
Negative result retention
✓
Registry lifecycle
✓
Для реальної Noetrail implementation найнижчий змістовно сильний рівень:
Level 2 Semantic Conformance.
Бо Level 1 фактично доводить переважно:
JSON structure works.
Public agent/tool, який заявляє повну підтримку Noetrail, СЛІД прагнути мінімум:
Level 3 Interoperability Conformance.
Public Noetrail registry СЛІД прагнути:
Level 4 Governance Conformance.
Reference implementation повинна проходити ту саму suite, що й сторонні implementations.
Вона НЕ ПОВИННА отримувати special exemption.
Noetrail застосовує власну ідею до себе:
reference implementation must be challengeable by the same requirements it imposes on others.
У майбутньому бажано, щоб хоча б одна стороння команда створила:
independent conformance runner.
Це покаже, що standard не залежить від одного validator.
Formal certification має сенс лише після:
external implementations;
stable adoption;
clear governance;
independent testing bodies.
Для v1.0 це передчасно.
Implementation має право називати себе:
Noetrail v1.0 Level X Conformant
якщо:
1. пройдено всі mandatory tests відповідного level;
2. пройдено всі lower-level tests;
3. зафіксовано implementation version;
4. зафіксовано test-suite version;
5. доступний test report;
6. немає known core semantic violation.
Цей документ перетворює твердження:
“ми підтримуємо Noetrail”
на перевірюване твердження:
“Noetrail v1.0 Level 3 tests C001–C210 пройдено; ось report і artifact hash.”
Саме це відрізняє технічний стандарт від простої conceptual proposal.
Noetrail conformance — це не оцінка істинності scientific policy, а перевірка того, що implementation правильно представляє, зберігає, передає та інтерпретує policy відповідно до нормативної семантики Noetrail.