NOETRAIL TECHNICAL SPECIFICATION v1.0

Технічна специфікація відкритого стандарту машинозчитуваних епістемічних політик

Версія: 1.0
Статус: нормативна специфікація
Мова цієї редакції: українська
Проєкт: Noetrail
Тип документа: Open Technical Standard
Дата редакції: 2026

0. Статус документа

Цей документ визначає нормативну технічну специфікацію Noetrail v1.0.

Noetrail є відкритим science-specific стандартом для машинозчитуваного представлення:

• 
  епістемічних станів;

• 
  епістемічних політик;

• 
  профілів перевірки політик;

• 
  записів методологічних рішень.

Специфікація визначає:

1. 
   основні поняття;

2. 
   core data model;

3. 
   нормативні поля;

4. 
   правила ідентичності та версіонування;

5. 
   семантику prospectivity та challenge;

6. 
   базовий vocabulary epistemic actions;

7. 
   правила conformance;

8. 
   interoperability boundaries;

9. 
   validation requirements;

10. 
    governance constraints v1.0.

Ця специфікація не визначає універсально найкращу наукову методологію.

Вона визначає спосіб представлення різних методологічних policy у спільному форматі.

1. Нормативна термінологія

У документі використовуються нормативні слова:

MUST — ПОВИНЕН / ПОВИННА / ПОВИННО

Абсолютна вимога стандарту.

Якщо implementation її порушує, implementation не може вважатися повністю conformant відповідному рівню Noetrail.

MUST NOT — НЕ ПОВИНЕН

Абсолютна заборона.

SHOULD — СЛІД

Сильна рекомендація.

Відхилення допускається лише тоді, коли implementation має обґрунтовану причину.

SHOULD NOT — НЕ СЛІД

Дію слід уникати, якщо немає обґрунтованої причини.

MAY — МОЖЕ

Опційна можливість.

Implementation може підтримувати або не підтримувати відповідну функцію.

2. Мета стандарту

2.1. Основна мета

Noetrail має забезпечити спільну machine-readable representation для правила виду:

«За поточного стану знання яку епістемічну дію слід запропонувати наступною?»

Таке правило в Noetrail називається:

EpistemicPolicy

2.2. Основна проблема

У наукових системах methodological decision rules часто існують як:

• 
  prose;

• 
  prompt;

• 
  hidden agent logic;

• 
  software code;

• 
  workflow branching;

• 
  researcher intuition;

• 
  institutional procedure.

Через це важко однозначно встановити:

• 
  яке правило використовувалося;

• 
  яка його версія;

• 
  для якого scope воно призначене;

• 
  яка implementation його реалізувала;

• 
  чи було воно змінено;

• 
  чи пройшло воно prospective challenge;

• 
  який evidence підтримує його status.

Noetrail стандартизує ці аспекти.

3. Що Noetrail стандартизує

Noetrail v1.0 визначає чотири core object types:

EpistemicState

EpistemicPolicy

ChallengeProfile

DecisionRecord

Їх концептуальний зв’язок:

EpistemicState

      ↓

EpistemicPolicy

      ↓

EpistemicAction

      ↓

Evidence

      ↓

Updated EpistemicState

Окремо:

Incumbent Policy

      +

Challenger Policy

      ↓

ChallengeProfile

      ↓

Evaluation

      ↓

DecisionRecord

4. Що Noetrail НЕ стандартизує

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

• 
  універсальну theory of truth;

• 
  один scientific method;

• 
  один reward function;

• 
  один benchmark;

• 
  одну statistical framework;

• 
  одну AI architecture;

• 
  одну ontology всіх scientific claims;

• 
  один central global registry;

• 
  один agent transport protocol;

• 
  один provenance protocol.

Noetrail також не замінює:

• 
  A2A;

• 
  MCP;

• 
  RO-Crate;

• 
  DOI infrastructure;

• 
  preregistration systems;

• 
  workflow systems;

• 
  scholarly repositories.

5. Основні design principles

5.1. Minimal Core

Core стандарту ПОВИНЕН залишатися невеликим.

Noetrail не повинен перетворюватися на повну ontology науки.

Domain-specific requirements СЛІД реалізовувати через profiles та extensions.

5.2. Explicit Identity

Кожна EpistemicPolicy ПОВИННА мати:

id

version

Комбінація:

(policy_id, version)

ПОВИННА однозначно визначати конкретну semantic version policy.

5.3. Version Immutability

Semantic contents опублікованої policy version НЕ ПОВИННІ змінюватися непомітно.

Якщо behavior або normative semantics policy змінюються, version ПОВИННА бути змінена.

Наприклад:

risk-directed:1.0

та

risk-directed:1.1

є різними policy objects.

6. EpistemicState

6.1. Визначення

EpistemicState — це machine-readable representation релевантного стану знання, uncertainty, evidence та constraints, у якому відбувається methodological decision.

EpistemicState не повинен розглядатися як повна model of reality.

Він містить лише information, необхідну для відповідного policy context.

6.2. Мінімальна логічна структура

EpistemicState МОЖЕ містити:

id

version

objective

claims

evidence

uncertainty

dependencies

constraints

active_policy

challengers

provenance

6.3. Ідентичність

EpistemicState ПОВИНЕН мати:

type

id

version

Приклад:

{

  "type": "EpistemicState",

  "id": "state-001",

  "version": "1.0"

}

7. Objective

Поле objective описує epistemic objective.

Наприклад:

{

  "objective": "Evaluate whether the observed effect generalizes across populations"

}

Objective МОЖЕ бути:

• 
  текстовим;

• 
  структурованим;

• 
  reference на external object.

8. Claims

Поле claims МОЖЕ містити:

• 
  hypotheses;

• 
  research questions;

• 
  causal claims;

• 
  measurement claims;

• 
  model claims;

• 
  theory claims.

Noetrail v1.0 не визначає універсальну formal language для claims.

Це свідоме design-рішення.

9. Evidence

Evidence МОЖЕ бути представлене:

• 
  inline metadata;

• 
  DOI reference;

• 
  dataset identifier;

• 
  research object;

• 
  URL;

• 
  RO-Crate reference;

• 
  repository artifact.

Наприклад:

{

  "evidence": [

    {

      "id": "doi:10.xxxx/example",

      "type": "article"

    }

  ]

}

10. Uncertainty

EpistemicState МОЖЕ представляти декілька типів uncertainty.

Наприклад:

{

  "uncertainty": {

    "parameter": "low",

    "model": "high",

    "measurement": "moderate",

    "external_validity": "high"

  }

}

Noetrail не вимагає єдиної numerical scale.

Domain profile МОЖЕ вимагати конкретну representation.

11. Evidence Dependencies

Evidence objects можуть бути статистично або процедурно залежними.

Наприклад:

• 
  той самий dataset;

• 
  та сама laboratory;

• 
  та сама measurement instrument;

• 
  common software pipeline;

• 
  common funding source;

• 
  overlapping samples.

Тому EpistemicState МОЖЕ містити dependencies.

Приклад:

{

  "dependencies": [

    {

      "type": "shared_dataset",

      "members": ["study-1", "study-2"]

    }

  ]

}

Noetrail не визначає universal dependency graph semantics у v1.0.

12. Constraints

Policy selection МОЖЕ залежати не лише від information value.

Constraints можуть включати:

cost

time

ethics

safety

legal

computational

sample_availability

resource_availability

Наприклад:

{

  "constraints": {

    "budget": "low",

    "time": "30 days",

    "human_subject_risk": "minimal"

  }

}

13. EpistemicPolicy

13.1. Визначення

EpistemicPolicy — це версійоване правило, procedure, software component або agent policy, що відображає EpistemicState в одну або кілька proposed EpistemicActions.

Формально:

π: E → Δ(A)

де:

E = EpistemicState

A = set of EpistemicActions

π = EpistemicPolicy

13.2. Мінімальні normative fields

EpistemicPolicy ПОВИННА містити:

type

id

version

title

scope

input_profile

output_contract

actions

artifact_hash

Рекомендовано також:

implementation

license

provenance

authors

created_at

14. Policy ID

id ПОВИНЕН бути стабільним.

Наприклад:

risk-directed

або URI-like identifier:

https://example.org/policies/risk-directed

Після public release змінювати policy ID без необхідності НЕ СЛІД.

15. Version

Version ПОВИННА бути machine-readable string.

Рекомендований формат:

MAJOR.MINOR.PATCH

Наприклад:

1.0.0

Semantic meaning:

MAJOR — incompatible semantic change;

MINOR — backward-compatible extension;

PATCH — correction без зміни intended behavior.

16. Scope

Policy ПОВИННА явно описувати scope.

Наприклад:

{

  "scope": {

    "domain": "model inadequacy detection",

    "data_type": "one-dimensional synthetic observations"

  }

}

Policy НЕ ПОВИННА автоматично трактуватися як universal лише тому, що її schema valid.

17. Input Profile

input_profile описує, які EpistemicState properties policy очікує.

Наприклад:

{

  "input_profile": {

    "requires": [

      "uncertainty",

      "evidence",

      "constraints"

    ]

  }

}

Implementation ПОВИННА або:

• 
  отримати required fields;

• 
  або повідомити, що policy cannot be applied.

18. Output Contract

Policy ПОВИННА визначити, що вона повертає.

Мінімально:

recommended_action

Policy МОЖЕ також повертати:

confidence

rationale

alternatives

expected_value

cost_estimate

uncertainty

provenance

19. EpistemicAction

EpistemicAction є machine-readable representation запропонованої knowledge-producing action.

У v1.0 визначаються 13 core action classes.

20. Core Action Vocabulary

20.1. experiment

Отримання нових evidence через intervention або planned observation.

20.2. direct_replication

Максимально близьке повторення попереднього study design.

20.3. conceptual_replication

Перевірка того самого theoretical claim через іншу operationalization.

20.4. adversarial_test

Спеціально створений test, спрямований на пошук failure conditions або discrimination між explanations.

20.5. measurement_audit

Перевірка:

• 
  reliability;

• 
  validity;

• 
  calibration;

• 
  measurement invariance;

• 
  instrumentation.

20.6. causal_identification

Дія, спрямована на покращення causal identification.

20.7. reanalysis

Повторний analysis existing evidence із використанням іншої defensible analytical procedure.

20.8. boundary_search

Пошук conditions, за яких claim або model перестає працювати.

20.9. model_criticism

Пошук systematic inadequacy current model family.

20.10. model_generation

Створення new candidate model або model family.

20.11. evidence_synthesis

Об’єднання evidence із multiple sources.

20.12. random_exploration

Epistemic action, selection якої частково або повністю незалежний від current greedy optimization objective.

20.13. stop_defer

Зупинка або відкладення research action.

Це ПОВИННО вважатися legitimate epistemic action.

Система НЕ ПОВИННА бути змушена завжди рекомендувати new experiment.

21. Protected Exploration

EpistemicPolicy МОЖЕ визначати мінімальну exploration allocation.

Наприклад:

{

  "exploration": {

    "protected": true,

    "minimum_probability": 0.30

  }

}

Protected exploration означає, що greedy/adaptive component НЕ МОЖЕ повністю усунути exploration нижче заданої межі.

Noetrail v1.0 не встановлює universal exploration floor.

22. Policy implementation

Поле implementation МОЖЕ містити reference на:

• 
  source repository;

• 
  package;

• 
  container;

• 
  API;

• 
  executable;

• 
  human procedure;

• 
  agent endpoint.

Наприклад:

{

  "implementation": {

    "type": "python",

    "repository": "https://github.com/example/policy"

  }

}

23. Policy ≠ Implementation

Policy identity ПОВИННА бути логічно відокремлена від конкретної software implementation.

Це дозволяє:

• 
  multiple implementations;

• 
  cross-language implementations;

• 
  clean-room reproduction;

• 
  conformance testing.

Наприклад:

Policy:

risk-directed:1.0

Implementation A:

Python

Implementation B:

R

Implementation C:

AI Agent Service

можуть представляти ту саму policy semantics.

24. Artifact Hash

Policy artifact СЛІД ідентифікувати cryptographic hash.

Рекомендований algorithm v1.0:

SHA-256

Приклад:

{

  "artifact_hash": {

    "algorithm": "sha256",

    "value": "b6e49e..."

  }

}

Hash забезпечує identity.

Hash не гарантує scientific validity.

25. ChallengeProfile

25.1. Визначення

ChallengeProfile описує machine-readable evaluation contract для comparison однієї або кількох EpistemicPolicies.

25.2. Основні поля

ChallengeProfile ПОВИНЕН містити:

id

incumbent

challenger

metrics

prospective

locked

Рекомендовано:

benchmark

gates

development_exclusions

seed_protocol

artifacts

created_at

26. Incumbent

incumbent — policy, яка має active status у конкретному evaluation context.

Incumbent status НЕ ОЗНАЧАЄ:

universally best

27. Challenger

challenger — policy, яка оцінюється відносно incumbent або іншої reference policy.

Challenger МОЖЕ програти без втрати registry identity.

Negative challenge result ПОВИНЕН зберігатися як evidence, якщо registry підтримує evaluation history.

28. Prospectivity

ChallengeProfile ПОВИНЕН явно містити:

prospective: true

або:

prospective: false

Це нормативно важливе поле.

29. Prospective Challenge

prospective = true МОЖНА встановлювати лише тоді, коли evaluation criteria були визначені до availability relevant outcomes.

30. Retrospective Challenge

Якщо criteria були сформульовані після того, як relevant outcomes стали відомими:

prospective = false

ПОВИННО бути використано.

31. Заборона post-hoc promotion

Implementation НЕ ПОВИННА представляти retrospective challenge як prospective promotion evidence.

Наприклад:

prospective = false

decision = promote

НЕ МОЖЕ трактуватися як prospectively validated promotion.

Це один із core semantic invariants Noetrail v1.0.

32. Locked Challenge

locked = true означає, що relevant evaluation specification було зафіксовано до evaluation.

Lock МОЖЕ підтримуватися:

• 
  repository commit;

• 
  hash;

• 
  timestamp;

• 
  preregistration;

• 
  DOI;

• 
  transparency log;

• 
  signed artifact.

Noetrail v1.0 не вимагає єдиного locking service.

33. Metrics

ChallengeProfile ПОВИНЕН явно визначити evaluation metrics.

Наприклад:

{

  "metrics": [

    "mean_detection",

    "false_alarm_rate",

    "worst_family_detection"

  ]

}

34. Gates

ChallengeProfile МОЖЕ визначати gates.

Наприклад:

{

  "metric": "mean_detection_advantage",

  "operator": ">=",

  "threshold": 0.05

}

Gates ПОВИННІ бути machine-readable, якщо використовуються для automated DecisionRecord.

35. Development Exclusions

ChallengeProfile СЛІД дозволяти вказати data/worlds/tasks, використані для development.

Наприклад:

{

  "development_exclusions": [

    "LocalBump",

    "Step",

    "Wave"

  ]

}

Це допомагає відокремити:

development

від:

confirmatory evaluation

36. DecisionRecord

36.1. Визначення

DecisionRecord — це persistent machine-readable record evaluation outcome.

36.2. Мінімальні поля

DecisionRecord ПОВИНЕН містити:

id

challenge_profile_id

decision

timestamp

Рекомендовано:

metrics

gate_results

selected_policy

failures

artifact_hashes

evaluator

provenance

37. Decision values

Noetrail v1.0 визначає базові decision values:

promote

retain

demote

inconclusive

38. Inconclusive

inconclusive є повноцінним normative outcome.

Implementation НЕ ПОВИННА примушувати кожне evaluation до визначення winner.

39. Приклад retrospective comparison

{

  "type": "DecisionRecord",

  "id": "decision-risk-vs-anneal",

  "challenge_profile_id": "challenge-002",

  "decision": "inconclusive",

  "reason": "Direct promotion criterion was not prospectively locked"

}

Це дозволяє зберегти:

RiskDirected мав вищу observed performance,

без неправдивого твердження:

RiskDirected prospectively пройшов promotion gate.

40. Основний semantic invariant

Noetrail v1.0 встановлює:

Observed superiority НЕ Є автоматично тотожною prospectively validated policy promotion.

Це одне з центральних правил стандарту.

41. Conformance model — попередній огляд

Noetrail реалізація може мати декілька рівнів conformance.

Попередньо:

Level 1 — Structural Conformance

Implementation правильно читає та створює core objects.

Level 2 — Semantic Conformance

Implementation виконує core semantic invariants.

Level 3 — Interoperability Conformance

Implementation може передавати objects іншій implementation без втрати core semantics.

Level 4 — Governance Conformance

Implementation зберігає version identity, challenge history і decision provenance.

Повні normative requirements ми сформулюємо в наступній частині Technical Specification.

42. Machine-readability principle

Noetrail object ПОВИНЕН бути:

machine-readable

і СЛІД, щоб він залишався:

human-inspectable.

Тобто:

не потрібно створювати binary proprietary format, якщо та сама функція може бути реалізована відкритим structured text format.

43. Recommended serialization

Для v1.0 normative reference serialization:

JSON

Сумісна schema system:

JSON Schema Draft 2020-12

Future versions МОЖУТЬ підтримувати:

• 
  JSON-LD;

• 
  YAML representation;

• 
  RDF mapping;

• 
  CBOR;

• 
  protocol-native representations.

Але canonical semantics мають залишатися незалежними від serialization.

44. Інтероперабельність як принцип

Noetrail повинен бути:

transport-agnostic.

Тобто той самий EpistemicPolicy object МОЖЕ бути переданий через:

• 
  HTTP;

• 
  file;

• 
  A2A;

• 
  MCP;

• 
  message queue;

• 
  repository;

• 
  local process.

Noetrail не визначає transport protocol.

45. Перше нормативне резюме

Noetrail v1.0 уже можна звести до восьми фундаментальних правил:

N1. EpistemicPolicy ПОВИННА мати explicit identity та version.

N2. Опублікована policy version НЕ ПОВИННА silently change semantics.

N3. Policy ПОВИННА описувати scope.

N4. ChallengeProfile ПОВИНЕН зберігати prospective/retrospective status.

N5. Retrospective evaluation НЕ ПОВИННА masquerade as prospective promotion.

N6. DecisionRecord ПОВИНЕН дозволяти inconclusive.

N7. Schema validity НЕ ПОВИННА інтерпретуватися як scientific validity.

N8. Noetrail ПОВИНЕН залишатися незалежним від конкретного agent/tool transport.

Частина II — Нормативна модель даних, життєвий цикл та conformance

46. Загальна структура canonical object

Кожен core object Noetrail v1.0 ПОВИНЕН бути JSON object.

Canonical top-level structure:

{

  "type": "EpistemicPolicy",

  "id": "risk-directed",

  "version": "1.0.0",

  "created_at": "2026-09-26T12:00:00Z",

  "provenance": {},

  "extensions": {}

}

Усі core object types ПОВИННІ використовувати однакові базові принципи identity, versioning та extension handling.

47. Core Object Types

Noetrail v1.0 визначає рівно чотири normative core object types:

EpistemicState

EpistemicPolicy

ChallengeProfile

DecisionRecord

Registry та vocabulary objects є supporting objects, але не входять до мінімального чотириоб’єктного semantic core.

48. Поле type

Кожен core object ПОВИНЕН містити поле:

"type": "EpistemicPolicy"

Допустимі значення v1.0:

EpistemicState

EpistemicPolicy

ChallengeProfile

DecisionRecord

Значення type є case-sensitive.

Отже:

EpistemicPolicy

і

epistemicpolicy

НЕ є еквівалентними.

49. Поле id

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

id визначає logical identity object.

Приклад:

"id": "risk-directed"

або:

"id": "https://noetrail.org/policies/risk-directed"

49.2. Вимоги до ID

ID ПОВИНЕН:

• 
  бути непорожнім;

• 
  бути стабільним для тієї самої logical entity;

• 
  не містити semantic version;

• 
  не змінюватися лише через зміну implementation language.

Наприклад:

risk-directed

може мати версії:

1.0.0

1.1.0

2.0.0

але ID залишається:

risk-directed

49.3. URI-based identifiers

Для публічних глобальних objects СЛІД використовувати globally resolvable identifier.

Рекомендований формат:

https://domain.example/policies/risk-directed

або persistent identifier:

doi:10.xxxx/xxxxx

Noetrail v1.0 не вимагає DOI для кожної policy.

50. Composite Identity

Повна machine identity versioned object визначається парою:

(id, version)

Наприклад:

risk-directed + 1.0.0

це інший object, ніж:

risk-directed + 1.1.0

51. Поле version

Noetrail v1.0 рекомендує Semantic Versioning-подібну структуру:

MAJOR.MINOR.PATCH

Наприклад:

1.0.0

51.1. MAJOR

MAJOR ПОВИНЕН збільшуватися, якщо змінюється:

• 
  core semantic behavior;

• 
  interpretation fields;

• 
  compatibility expectations;

• 
  decision logic у спосіб, що може змінити output для того самого input.

Наприклад:

1.4.2 → 2.0.0

51.2. MINOR

MINOR МОЖЕ збільшуватися, якщо додається:

• 
  backward-compatible metadata;

• 
  новий optional field;

• 
  підтримка нового action subtype;

• 
  additional implementation, яка не змінює intended semantics.

51.3. PATCH

PATCH використовується для:

• 
  typo correction;

• 
  documentation fix;

• 
  metadata repair;

• 
  non-semantic packaging changes.

PATCH НЕ ПОВИНЕН змінювати intended policy behavior.

52. created_at

Object СЛІД містити:

"created_at": "2026-09-26T12:00:00Z"

Рекомендований формат:

ISO 8601 / RFC 3339-compatible timestamp

Час СЛІД зберігати в UTC, якщо немає сильної причини використовувати локальний offset.

53. updated_at

Mutable registry metadata МОЖЕ мати:

"updated_at": "2026-09-27T10:30:00Z"

Але immutable versioned policy artifact НЕ ПОВИНЕН silently змінювати content із оновленням лише updated_at.

54. Canonical Serialization

Для hashing та reproducibility однаковий semantic JSON object повинен мати reproducible serialization.

Noetrail v1.0 визначає reference canonicalization rules.

Перед hashing implementation ПОВИННА:

1. 
   використовувати UTF-8;

2. 
   сортувати object keys lexicographically;

3. 
   не включати insignificant whitespace;

4. 
   зберігати array order;

5. 
   використовувати JSON null, true, false у стандартній формі;

6. 
   не змінювати numbers без semantic necessity.

Reference conceptual form:

canonical_json(object)

55. Hash Calculation

Reference hash v1.0:

SHA-256

Процес:

Object

   ↓

Canonical JSON

   ↓

UTF-8 bytes

   ↓

SHA-256

   ↓

artifact_hash

56. Hash Object

Рекомендована representation:

"artifact_hash": {

  "algorithm": "sha256",

  "value": "..."

}

Поле algorithm ПОВИННО бути explicit.

57. Self-referential hash problem

Object НЕ ПОВИНЕН включати власне поле artifact_hash.value у content, яке саме використовується для розрахунку того ж hash.

Тому canonical hashing profile ПОВИНЕН або:

варіант A

виключати top-level artifact_hash;

або:

варіант B

hash зберігається поза hashed payload.

Reference Noetrail v1.0 використовує:

artifact_hash не входить у hashed payload самого object.

58. Hash Scope

Object МОЖЕ окремо містити hashes:

policy hash

implementation hash

benchmark hash

result hash

dataset hash

Їх НЕ СЛІД змішувати в одне значення без explicit manifest.

59. Manifest

Для compound artifact СЛІД використовувати manifest.

Наприклад:

{

  "files": [

    {

      "path": "policy.json",

      "sha256": "abc..."

    },

    {

      "path": "implementation.py",

      "sha256": "def..."

    }

  ]

}

60. EpistemicState — normative object model

Reference structure:

{

  "type": "EpistemicState",

  "id": "state-001",

  "version": "1.0.0",

  "objective": "...",

  "claims": [],

  "evidence": [],

  "uncertainty": {},

  "dependencies": [],

  "constraints": {},

  "active_policy": null,

  "challengers": [],

  "provenance": {},

  "extensions": {}

}

61. Required EpistemicState fields

У Noetrail v1.0 ПОВИННІ бути:

type

id

version

objective

Інші поля є optional core fields.

62. objective

objective ПОВИНЕН бути або:

• 
  string;

• 
  structured object;

• 
  reference object.

Приклад:

"objective": {

  "text": "Evaluate whether the observed effect replicates",

  "class": "replication_assessment"

}

63. claims

claims ПОВИНЕН бути array, якщо використовується.

Приклад:

"claims": [

  {

    "id": "claim-1",

    "text": "Treatment A reduces outcome Y"

  }

]

64. evidence

Evidence entry МОЖЕ бути:

{

  "id": "doi:10.xxxx/example",

  "type": "article"

}

або:

{

  "id": "dataset-01",

  "type": "dataset",

  "uri": "https://..."

}

Noetrail v1.0 НЕ ПОВИНЕН вимагати копіювання entire evidence content inline.

65. uncertainty

Uncertainty object МОЖЕ бути open dictionary.

Приклад:

{

  "parameter": 0.2,

  "model": "high",

  "measurement": "moderate"

}

Domain profile МОЖЕ обмежити допустиму representation.

66. dependencies

Dependency entry МОЖЕ містити:

type

members

strength

evidence

Приклад:

{

  "type": "shared_dataset",

  "members": ["study-a", "study-b"]

}

67. constraints

Constraints СЛІД представляти окремо від uncertainty.

Наприклад:

{

  "budget": {

    "currency": "USD",

    "maximum": 5000

  },

  "time_days": 30,

  "ethics": {

    "human_subjects": true

  }

}

68. active_policy

EpistemicState МОЖЕ містити reference:

"active_policy": {

  "id": "anneal30",

  "version": "0.3.0"

}

Це НЕ означає, що policy universal incumbent.

Вона active лише для цього context.

69. challengers

Може містити:

"challengers": [

  {

    "id": "risk-directed",

    "version": "1.0.0"

  }

]

70. EpistemicPolicy — normative object model

Reference structure:

{

  "type": "EpistemicPolicy",

  "id": "risk-directed",

  "version": "1.0.0",

  "title": "RiskDirected",

  "scope": {},

  "input_profile": {},

  "output_contract": {},

  "actions": [],

  "exploration": {},

  "implementation": {},

  "artifact_hash": {},

  "license": "Apache-2.0",

  "provenance": {},

  "extensions": {}

}

71. Required EpistemicPolicy fields

v1.0 вимагає:

type

id

version

title

scope

input_profile

output_contract

actions

artifact_hash

72. title

Title призначений для human readability.

Наприклад:

"title": "Risk-Directed Audit Policy"

Title МОЖЕ змінюватися лише в PATCH/MINOR update, якщо semantic identity не змінена.

73. scope

Scope МОЖЕ включати:

domain

task

population

data_types

assumptions

limitations

exclusions

Наприклад:

{

  "domain": "model inadequacy detection",

  "task": "audit location selection",

  "limitations": [

    "not validated for temporal dependence"

  ]

}

74. Scope requirement

Policy із невизначеним scope НЕ СЛІД публікувати як production-grade Noetrail policy.

Reference validator МОЖЕ дозволити broad textual scope, але governance layer СЛІД позначати його низькою specificity.

75. input_profile

Input profile описує minimum state features.

Наприклад:

{

  "required_fields": [

    "evidence",

    "uncertainty"

  ]

}

76. Input mismatch

Якщо required field відсутній, conformant implementation ПОВИННА:

• 
  повернути structured error;

• 
  або повернути not_applicable.

Implementation НЕ ПОВИННА silently invent missing scientific data.

77. output_contract

Minimum output contract:

{

  "required": [

    "recommended_action"

  ]

}

Можливе розширення:

{

  "required": [

    "recommended_action"

  ],

  "optional": [

    "confidence",

    "rationale",

    "alternatives"

  ]

}

78. Policy output object

Рекомендована representation:

{

  "recommended_action": "measurement_audit",

  "confidence": 0.74,

  "rationale": "Measurement uncertainty exceeds model uncertainty"

}

79. Confidence semantics

Якщо policy повертає confidence, вона ПОВИННА документувати meaning.

Наприклад:

• 
  posterior probability;

• 
  calibrated score;

• 
  heuristic score;

• 
  ordinal level.

Число 0.9 без semantics НЕ СЛІД інтерпретувати як probability.

80. Action list

Поле:

"actions": [

  "measurement_audit",

  "model_criticism"

]

визначає action classes, які policy МОЖЕ рекомендувати.

Output НЕ ПОВИНЕН містити action поза declared action set, якщо extension mechanism явно цього не дозволяє.

81. Custom actions

Custom action ПОВИНЕН мати namespace.

Наприклад:

org.example:construct_validation

а не:

construct_validation

якщо action не входить у core vocabulary.

82. Action Namespace

Core Noetrail actions мають implicit namespace:

noetrail:

Отже conceptual full form:

noetrail:experiment

noetrail:measurement_audit

Short form МОЖНА використовувати в canonical v1.0 JSON.

83. exploration object

Reference structure:

{

  "protected": true,

  "minimum_probability": 0.30

}

minimum_probability ПОВИННА бути числом:

0 <= p <= 1

84. Exploration invariant

Якщо:

protected = true

і:

minimum_probability = p

implementation НЕ ПОВИННА в declared policy context зменшувати exploration probability нижче p, якщо немає explicit exception condition.

85. Exceptions

Policy МОЖЕ визначити:

"exploration": {

  "protected": true,

  "minimum_probability": 0.30,

  "exceptions": [

    "safety_constraint"

  ]

}

Safety constraints МОЖУТЬ override exploration floor.

86. ChallengeProfile — normative object model

Reference:

{

  "type": "ChallengeProfile",

  "id": "challenge-001",

  "version": "1.0.0",

  "incumbent": {},

  "challengers": [],

  "benchmark": {},

  "metrics": [],

  "gates": [],

  "development_exclusions": [],

  "prospective": true,

  "locked": true,

  "lock_reference": {},

  "seed_protocol": {},

  "artifact_hash": {}

}

87. One or multiple challengers

v1.0 ПОВИНЕН підтримувати:

• 
  one challenger;

• 
  multiple challengers.

Тому canonical field:

challengers

є array.

88. Incumbent optionality

incumbent МОЖЕ бути null, якщо challenge не є incumbent-vs-challenger comparison.

Наприклад:

benchmark tournament

може оцінювати кілька policies без incumbent.

89. Benchmark reference

Benchmark МОЖЕ бути:

• 
  embedded;

• 
  URI;

• 
  DOI;

• 
  repository artifact;

• 
  manifest;

• 
  challenge service.

Приклад:

"benchmark": {

  "id": "noetrail-bench-2026-01",

  "version": "1.0.0",

  "sha256": "..."

}

90. Metrics object

Recommended:

{

  "name": "mean_detection",

  "direction": "maximize",

  "unit": "proportion"

}

Direction МОЖЕ бути:

maximize

minimize

target

91. Gate object

Normative example:

{

  "metric": "mean_detection_advantage",

  "operator": ">=",

  "threshold": 0.05

}

Supported core operators v1.0:

>

>=

<

<=

==

92. Compound gates

Multiple gates за замовчуванням інтерпретуються:

AND

якщо ChallengeProfile явно не визначає іншу logical aggregation.

93. Gate aggregation

Optional:

"gate_logic": "all"

Core values:

all

any

custom

Якщо custom, profile ПОВИНЕН документувати logic.

94. prospective

Boolean:

"prospective": true

або:

"prospective": false

Поле ПОВИННО бути present.

95. locked

Boolean:

"locked": true

або:

"locked": false

Поле ПОВИННО бути present.

96. Lock reference

Якщо:

locked = true

ChallengeProfile СЛІД містити:

lock_reference

Наприклад:

{

  "type": "git_commit",

  "value": "abc123..."

}

або:

{

  "type": "sha256",

  "value": "..."

}

97. Lock semantics

locked = true означає:

relevant evaluation definition was fixed before execution according to the declared lock mechanism.

Це НЕ означає automatically:

trusted third-party preregistration.

98. Challenge lifecycle

Noetrail v1.0 визначає states:

draft

locked

running

completed

void

Conceptual lifecycle:

draft

  ↓

locked

  ↓

running

  ↓

completed

Alternative:

draft

  ↓

void

або:

locked

  ↓

void

якщо evaluation скасовано.

99. Draft

У draft:

• 
  fields МОЖНА змінювати;

• 
  gates МОЖНА змінювати;

• 
  benchmark МОЖНА змінювати.

Draft НЕ ПОВИНЕН використовуватися як confirmatory evidence.

100. Locked

Після transition:

draft → locked

normative fields challenge НЕ ПОВИННІ змінюватися.

Якщо змінюються:

потрібно створити нову version ChallengeProfile.

101. Running

У running evaluation уже почалась.

Normative parameters НЕ ПОВИННІ змінюватися.

102. Completed

completed означає, що challenge має result artifact і DecisionRecord або explicit no-decision result.

103. Void

void означає:

• 
  technical invalidation;

• 
  protocol violation;

• 
  corrupted run;

• 
  invalid benchmark;

• 
  evaluation cancelled.

Void НЕ дорівнює failure challenger.

104. DecisionRecord — normative object model

Reference:

{

  "type": "DecisionRecord",

  "id": "decision-001",

  "version": "1.0.0",

  "challenge_profile_id": "challenge-001",

  "decision": "promote",

  "metrics": {},

  "gate_results": [],

  "selected_policy": {},

  "failures": [],

  "evaluator": {},

  "artifact_hashes": {},

  "timestamp": "...",

  "provenance": {}

}

105. Decision values

Normative core:

promote

retain

demote

inconclusive

Domain profile МОЖЕ додати additional statuses.

106. promote

promote означає:

challenger набуває declared active/incumbent status у конкретному governance context.

Це НЕ означає global scientific superiority.

107. retain

retain означає:

incumbent зберігає active status.

Це НЕ означає, що challenger «спростовано» у загальному сенсі.

108. demote

demote означає:

policy втрачає active status без обов’язкового automatic promotion іншої policy.

109. inconclusive

inconclusive ПОВИНЕН використовуватися, коли:

• 
  evidence insufficient;

• 
  gates mixed;

• 
  challenge retrospective;

• 
  protocol incomplete;

• 
  uncertainty too high.

110. Gate Results

Reference:

{

  "metric": "mean_detection_advantage",

  "observed": 0.0706,

  "operator": ">=",

  "threshold": 0.05,

  "passed": true

}

111. Decision consistency

Якщо DecisionRecord має:

decision = promote

і ChallengeProfile має:

prospective = false

implementation ПОВИННА або:

• 
  reject record;

• 
  або mark record as non-conformant.

112. Promotion consistency

Для normative prospective promotion v1.0 СЛІД вимагати:

prospective = true

locked = true

challenge status = completed

all required promotion gates = passed

113. Retrospective evidence

Retrospective result МОЖЕ бути збережений.

Він МОЖЕ:

• 
  motivate future challenge;

• 
  change confidence;

• 
  generate challenger;

• 
  support research discussion.

Він НЕ ПОВИНЕН masquerade as prospective confirmation.

114. Policy lifecycle

Noetrail v1.0 рекомендує такі registry statuses:

draft

experimental

challenger

incumbent

deprecated

retired

superseded

115. Draft Policy

Policy ще не stable.

НЕ СЛІД використовувати як production reference without warning.

116. Experimental

Implementation stable enough for testing, але evidence limited.

117. Challenger

Policy активно розглядається як candidate relative to defined context.

118. Incumbent

Policy має active status у конкретному context.

Registry ПОВИНЕН вказувати context, якщо статус може бути ambiguous.

119. Deprecated

Policy ще може використовуватися, але нове використання НЕ РЕКОМЕНДУЄТЬСЯ.

120. Retired

Policy більше не повинна використовуватися для нових decisions.

121. Superseded

Policy має explicit replacement.

Наприклад:

{

  "status": "superseded",

  "superseded_by": {

    "id": "risk-directed",

    "version": "2.0.0"

  }

}

122. Registry

Noetrail registry — це index policy metadata.

Minimum entry:

{

  "policy_id": "anneal30",

  "version": "0.3.0",

  "title": "Anneal30",

  "status": "incumbent",

  "artifact": "https://..."

}

123. Registry uniqueness

Registry НЕ ПОВИНЕН містити дві різні semantic artifacts з однаковою парою:

(policy_id, version)

124. Registry is not authority

Registry entry НЕ ОЗНАЧАЄ:

• 
  endorsement;

• 
  truth;

• 
  universal validity.

Registry лише забезпечує:

• 
  discovery;

• 
  identity;

• 
  metadata;

• 
  evidence links.

125. Federated Registries

Noetrail v1.0 дозволяє multiple registries.

Наприклад:

registry.noetrail.org

psychology.example.edu/noetrail

lab.example.org/policies

No single registry є normative global authority.

126. Registry federation

Federated registry МОЖЕ посилатися на external registry entries.

Reference:

{

  "external_registry": "https://example.org/registry",

  "policy_id": "policy-x",

  "version": "1.0.0"

}

127. Extension Mechanism

Noetrail v1.0 передбачає:

"extensions": {}

Custom fields СЛІД розміщувати всередині extensions.

128. Namespace rule

Extension key ПОВИНЕН бути namespaced.

Наприклад:

"extensions": {

  "org.example.psychology": {

    "construct_validity": "high"

  }

}

НЕ СЛІД:

"extensions": {

  "validity": "high"

}

через collision risk.

129. Core field collision

Extension НЕ ПОВИНЕН переозначувати semantics core field.

Наприклад extension не може змінити meaning:

prospective

або:

version

130. Domain Profiles

Domain Profile — це додатковий specification layer поверх core Noetrail.

Приклад:

Noetrail Psychology Profile 1.0

МОЖЕ визначати:

• 
  required fields;

• 
  extra actions;

• 
  domain-specific vocabulary;

• 
  validation constraints.

131. Profile declaration

Object МОЖЕ містити:

"profiles": [

  "https://example.org/noetrail/psychology/1.0"

]

132. Profile compatibility

Profile НЕ ПОВИНЕН порушувати core Noetrail semantics.

Наприклад profile НЕ МОЖЕ дозволити:

retrospective challenge = prospective confirmed promotion.

133. Validation levels

Reference validator v1.0 МОЖЕ повертати:

VALID

VALID_WITH_WARNINGS

INVALID

134. INVALID

Object ПОВИНЕН бути INVALID, якщо:

• 
  required field missing;

• 
  type invalid;

• 
  version malformed under declared profile;

• 
  duplicate immutable identity;

• 
  semantic invariant violated.

135. VALID_WITH_WARNINGS

Може використовуватися, якщо:

• 
  scope занадто broad;

• 
  provenance missing;

• 
  optional implementation unavailable;

• 
  no lock_reference despite locked=true, якщо profile не робить це hard error.

136. Structured Errors

Validator СЛІД повертати machine-readable errors.

Наприклад:

{

  "code": "NTRL-E102",

  "field": "artifact_hash",

  "message": "Required field missing"

}

137. Core Error Codes

Recommended v1.0 classes:

NTRL-E1xx — structural errors

NTRL-E2xx — identity/version errors

NTRL-E3xx — semantic errors

NTRL-E4xx — challenge lifecycle errors

NTRL-E5xx — registry errors

NTRL-E6xx — extension/profile errors

138. Example Errors

NTRL-E101

Missing required field

NTRL-E201

Duplicate policy identity

NTRL-E301

Retrospective promotion violation

NTRL-E401

Locked challenge modified

NTRL-E501

Registry duplicate entry

NTRL-E601

Extension namespace collision

139. Conformance Levels

Noetrail v1.0 визначає чотири reference conformance levels.

140. Level 1 — Structural Conformance

Implementation ПОВИННА:

• 
  parse JSON;

• 
  validate core schemas;

• 
  preserve unknown permitted extensions;

• 
  reject invalid required fields.

141. Level 2 — Semantic Conformance

Implementation additionally ПОВИННА:

• 
  enforce identity/version semantics;

• 
  enforce prospective/retrospective distinction;

• 
  reject false post-hoc promotion;

• 
  preserve inconclusive;

• 
  enforce protected exploration semantics when declared.

142. Level 3 — Interoperability Conformance

Implementation additionally ПОВИННА:

• 
  export canonical Noetrail objects;

• 
  import another conformant implementation’s objects;

• 
  preserve core semantics;

• 
  preserve IDs, versions and hashes;

• 
  not silently discard unknown extensions.

143. Level 4 — Governance Conformance

Implementation additionally ПОВИННА:

• 
  maintain immutable version history;

• 
  maintain ChallengeProfile lifecycle;

• 
  maintain DecisionRecords;

• 
  preserve negative results;

• 
  preserve provenance links;

• 
  support policy status transitions.

144. Claiming conformance

System НЕ ПОВИННА просто писати:

Noetrail compatible

без level.

Рекомендована форма:

Noetrail v1.0 — Level 2 Semantic Conformant

або:

Noetrail v1.0 — Level 3 Interoperability Conformant

145. Partial conformance

System МОЖЕ заявити:

Noetrail Schema Compatible

якщо вона лише читає JSON schemas.

Але НЕ ПОВИННА називати себе:

Fully Noetrail Conformant

без semantic requirements.

146. Core invariants checklist

Будь-яка Level 2+ implementation ПОВИННА виконувати такі invariants:

I1. (id, version) визначає immutable semantic identity.

I2. Retrospective evaluation не стає prospective через пізніший metadata edit.

I3. promote не може бути valid prospective decision за prospective=false.

I4. inconclusive є допустимим outcome.

I5. Policy scope не дорівнює universal applicability.

I6. Schema validity не дорівнює scientific validity.

I7. Custom extensions не змінюють semantics core fields.

I8. Unknown valid extensions не повинні silently знищуватися під час round-trip.

147. Round-trip preservation

Для Level 3 implementation:

import(object)

↓

export(object)

ПОВИННО зберігати:

• 
  core values;

• 
  IDs;

• 
  version;

• 
  extension data;

• 
  artifact references.

Formatting МОЖЕ змінитися.

Semantics НЕ ПОВИННІ.

148. Unknown Fields

Unknown top-level field outside extensions:

validator МОЖЕ:

• 
  reject;

• 
  warn;

залежно від declared strictness profile.

Reference strict profile:

custom fields СЛІД розміщувати тільки в extensions.

149. Strict vs permissive validation

Implementation МОЖЕ мати:

strict

permissive

mode.

Strict:

• 
  unknown fields rejected.

Permissive:

• 
  unknown fields preserved з warning.

150. Recommended production mode

Для registries та signed releases СЛІД використовувати:

strict

Для exploratory development:

permissive

може бути зручнішим.

151. Policy Applicability

Implementation ПОВИННА мати механізм відрізнити:

policy applicable

від:

policy not applicable

Не кожна valid policy підходить до every EpistemicState.

152. Suggested applicability result

{

  "applicable": false,

  "reason": "Required field measurement_uncertainty missing"

}

153. Scientific validity boundary

Noetrail validator НЕ ПОВИНЕН видавати:

scientifically valid

лише на основі schema conformance.

Допустимо:

structurally valid

semantic conformance passed

154. No automatic truth certification

DecisionRecord НЕ ПОВИНЕН трактуватися як:

certificate of truth.

Він є:

record of policy evaluation under declared conditions.

155. Evidence scope

Metric result ПОВИНЕН бути interpreted within challenge scope.

Наприклад:

RiskDirected > Anneal30

у конкретному benchmark НЕ ПОВИННО автоматично трансформуватися в:

RiskDirected > Anneal30 everywhere

156. Benchmark leakage metadata

ChallengeProfile СЛІД дозволяти:

{

  "benchmark_exposure": {

    "used_in_development": false,

    "known_to_policy_author": false,

    "known_to_implementation_author": true

  }

}

Це optional v1.0 metadata, але рекомендується для serious evaluation.

157. Contamination declaration

Для AI-agent evaluations profile МОЖЕ містити:

possible_training_contamination

або:

unknown_training_exposure

Noetrail v1.0 не може технічно перевірити model training history, але може дозволити declaration.

158. Negative result retention

Governance-conformant registry НЕ ПОВИНЕН видаляти failed challenge лише через negative result.

Допустимі причини видалення:

• 
  legal requirement;

• 
  sensitive data;

• 
  corruption;

• 
  invalid artifact.

У такому випадку SHOULD залишитися tombstone/metadata record.

159. Tombstone record

Приклад:

{

  "id": "challenge-017",

  "status": "withdrawn",

  "reason": "corrupted benchmark artifact",

  "superseded_by": "challenge-018"

}

160. Freeze principle

Після v1.0 release core schemas НЕ ПОВИННІ змінюватися без version increment.

Noetrail v1.0 означає стабільний semantic contract.

161. Backward compatibility

Patch release:

1.0.0 → 1.0.1

НЕ ПОВИНЕН ламати valid v1.0.0 objects.

Minor:

1.0 → 1.1

СЛІД зберігати compatibility, якщо можливо.

Major:

1.x → 2.0

МОЖЕ бути incompatible.

162. Deprecation before removal

Core field СЛІД спочатку:

deprecated

і лише в наступному MAJOR release може бути removed.

163. Deprecated field metadata

Documentation СЛІД вказувати:

deprecated_since

replacement

removal_target

164. Noetrail Core Philosophy

У technical terms Noetrail v1.0 можна звести до такого принципу:

Policies evolve; identities, evidence status and decision history must remain auditable.

Українською:

Політики можуть змінюватися; їхня ідентичність, доказовий статус та історія рішень повинні залишатися простежуваними.

165. Нормативне резюме Частини II

Після цієї частини Noetrail v1.0 уже визначає:

Identity

id + version

Integrity

canonicalization + hash

Scientific context

EpistemicState

Decision rule

EpistemicPolicy

Evaluation contract

ChallengeProfile

Evaluation result

DecisionRecord

Discovery

Registry

Extensibility

Extensions + Profiles

Validation

Schemas + semantic invariants

Conformance

Levels 1–4

166. Найважливіші нормативні правила після запуску 2

Тепер маємо вже не 8, а 16 core rules:

N1. Policy має explicit ID.

N2. Policy має explicit version.

N3. (id, version) є immutable semantic identity.

N4. Policy має scope.

N5. Missing required state data не можна silently invent.

N6. Policy output має відповідати declared action set.

N7. Protected exploration не можна silently optimize away.

N8. ChallengeProfile має explicit prospective status.

N9. ChallengeProfile має explicit lock status.

N10. Retrospective comparison не є prospective promotion.

N11. DecisionRecord може бути inconclusive.

N12. Failed challenges повинні зберігатися.

N13. Schema validity не є scientific validity.

N14. Extension не може змінити core semantics.

N15. Registry не є authority of truth.

N16. Transport та implementation не визначають policy identity.

167. Загальний принцип інтероперабельності

Noetrail v1.0 ПОВИНЕН залишатися:

transport-agnostic

agent-framework-agnostic

programming-language-agnostic

repository-agnostic

Це означає, що один і той самий EpistemicPolicy object МОЖЕ передаватися через різні transport layers без зміни core semantics.

Наприклад:

Noetrail Object

      |

      +--> local file

      |

      +--> HTTP API

      |

      +--> A2A

      |

      +--> MCP resource/tool

      |

      +--> repository

      |

      +--> message queue

168. Transport НЕ визначає policy identity

Policy:

risk-directed:1.0.0

залишається тією самою policy незалежно від того, чи вона передана:

• 
  як JSON file;

• 
  через REST API;

• 
  через A2A;

• 
  через MCP;

• 
  із repository.

Transport НЕ ПОВИНЕН змінювати:

id

version

scope

semantic meaning

artifact identity

169. A2A interoperability

Noetrail МОЖЕ інтегруватися з Agent-to-Agent protocol через reference на policy у agent metadata.

Conceptual mapping:

A2A Agent

   |

   +--> identity

   +--> capabilities

   +--> skills

   +--> endpoints

   +--> Noetrail EpistemicPolicy reference

170. A2A Agent Card extension

Agent Card МОЖЕ містити extension на кшталт:

{

  "extensions": {

    "noetrail": {

      "policies": [

        {

          "id": "risk-directed",

          "version": "1.0.0",

          "uri": "https://example.org/policies/risk-directed/1.0.0"

        }

      ]

    }

  }

}

Це лише reference pattern.

Noetrail v1.0 НЕ ПОВИНЕН вимагати modification core A2A specification.

171. Capability ≠ EpistemicPolicy

Agent capability:

run_experiment

не є EpistemicPolicy.

Capability означає:

агент уміє це виконати.

EpistemicPolicy означає:

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

Це фундаментальна distinction.

172. MCP interoperability

Noetrail МОЖЕ використовувати MCP як tool/resource layer.