Prompt Server Evaluation Plan

Статус: planned capability.

1. Цель оценки

Качество будущего Prompt Server означает:

  • published-only access действительно соблюдается;

  • render остаётся deterministic;

  • API contract стабилен и предсказуем;

  • delivery runtime не размывает authoring boundaries.

Главные риски:

  • accidental draft access;

  • inconsistent render behavior;

  • weak parameter validation;

  • contract drift;

  • security boundary violations.

2. Измерения качества

Оцениваемые измерения:

  • access boundary correctness Может ли сервис увидеть или вернуть draft data.

  • render reproducibility Даёт ли одинаковый вход одинаковый output.

  • API contract stability Насколько предсказуемы inputs, outputs и errors.

  • validation strictness Насколько последовательно сервис отвергает invalid requests.

3. Критерии приёмки

Capability будет считаться проходящей проверку, если:

  • published-only access enforced;

  • same input yields same render output;

  • parameter validation predictable and testable;

  • draft data не доступны через runtime paths;

  • service clearly fail-closed on repository problems.

4. Стратегия датасета

Нужно использовать:

  • representative published assets;

  • valid and invalid parameter sets;

  • not-found cases;

  • forbidden/draft-access attempts;

  • replay наборы для deterministic render.

5. Offline evaluation

Нужно проводить:

  • contract tests;

  • deterministic render replay;

  • boundary tests на published-only access;

  • validation tests для required and invalid params;

  • compatibility checks при изменении API shape.

6. Ручная проверка

До go-live нужны:

  • architecture review;

  • security review;

  • review published-only policy;

  • review failure behavior under degraded conditions.

7. Пороговые значения и правило решения

Go, только если:

  • published-only boundary доказана тестами;

  • service не может access drafts;

  • deterministic render replay стабилен;

  • validation behavior предсказуем.

No-Go, если:

  • сервис может читать drafts;

  • output меняется без изменения inputs;

  • parameter validation двусмысленна;

  • degradation leads to unsafe fallback.

8. Политика регрессий

Регрессией считается:

  • broken access boundary;

  • changed deterministic output for same inputs;

  • weakened validation;

  • contract instability for clients.

9. Post-release review

После будущего запуска нужно:

  • track access boundary incidents;

  • review compatibility after API changes;

  • collect client-facing error cases;

  • separately audit any attempt to reach draft data.